Expose Scan:: registry/token: Change istio authorization policies to allow traffic to the registry endpoints#5970
Conversation
[ci] Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
[ci] Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
[ci] Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
| throttleAcrossAllEndpointsAllIps: | ||
| maxRequestsBeforeHttp429: 0 | ||
| withinIntervalSeconds: 60 | ||
| tokenRegistry: |
There was a problem hiding this comment.
you're enabling a global cloud armor limit but cloud armor is disabled. I was expecting we try to solve this in istio for now, is that not an option?
There was a problem hiding this comment.
try setting the limit low enough that you can easily trigger it during testing and see that you trigger it
There was a problem hiding this comment.
Sure, will check in scratchnet with low limits.
I have a question about the scope:: As of now, we allow an endpoint to have either a per-IP token bucket (clientIp: true) or a global shared bucket. These two types are mutually exclusive. #5651 asks for both global limits and per-IP limits, AFAICU. Since Cloud Armor isn't available, we can't achieve both without refactoring the Pulumi rate limit logic to map two separate descriptors to a single route/path.
For this PR, should I stick to clientIp: true for all token endpoints (and hence no global limits), or just have global limits? or should I first refactor rate limiting logic to support both options for given end point? (sounds like different PR)
There was a problem hiding this comment.
can you check with Stephen when we expect cloud armor to be enabled? If the answer is soon we can maybe wait for that, if not then we do need to refactor our istio limits.
Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
Signed-off-by: pasindutennage-da <pasindu.tennage@digitalasset.com> Signed-off-by: Pasindu Tennage <pasindu.tennage@digitalasset.com>
Fix #5946