Istio
Hard
Security
A workload has AuthorizationPolicies with CUSTOM, DENY, and ALLOW actions. In what order does Istio check them?
Select your answer:
Show answer and explanation
Answer: CUSTOM, then DENY, then ALLOW
Explanation
Istio checks the layers in order CUSTOM, DENY, ALLOW, and a request that matches a denying policy in an earlier layer stops there. If no ALLOW policy applies to the workload, the request is allowed. If any ALLOW policy applies, at least one must match or the request is denied. That last rule is why adding a single ALLOW policy can block traffic it doesn't mention.
More hard Istio questions
- The mesh-wide PeerAuthentication in istio-system sets STRICT. The namespace has one that sets PERMISSIVE. A workload-specific policy sets portLevelMtls to DISABLE for port 8080. Which mode applies to port 8080 of that workload?
- An application in an Istio sidecar pod fails at startup because its first outbound calls happen before the Envoy sidecar is ready. Which setting fixes this?
- What is the purpose of Istio's WorkloadEntry resource?
- What is the purpose of Istio's WorkloadGroup resource?
- What is the purpose of Istio's 'consistentHash' load balancing in DestinationRule?
- How can you implement rate limiting in Istio?