Authorization policy translation check

Istio 가 한 요청에 대해 인가 정책을 평가하는 순서로 맞는 것은?

• ALLOW 매치면 허용 → DENY 매치면 거부 → CUSTOM 이 거부하면 거부 → 그 밖은 모두 허용
• 정책이 만들어진 시각 순으로 하나씩 보고, 처음 매치한 정책의 action 을 그대로 따른다
• DENY 매치면 거부 → ALLOW 매치면 허용 → ALLOW 정책이 없으면 거부 → 마지막에 CUSTOM 확인
• CUSTOM 거부 → DENY 매치면 거부 → ALLOW 정책이 없으면 허용 → ALLOW 매치면 허용 → 나머지 거부

워크로드에 DENY paths:["/admin*"] 와 ALLOW methods:["GET"] 두 정책이 걸려 있다. POST / 는 어떻게 되는가?

• DENY 에 걸리지 않았으므로 허용된다
• ALLOW 정책은 GET 만 다루므로 POST 에는 정책이 없는 것으로 보고 허용된다
• DENY 에는 안 걸리지만 ALLOW 정책이 있는데 매치하지 않으므로 403 으로 거부된다
• 두 정책이 충돌하므로 istiod 가 둘 다 무시하고 허용한다

같은 워크로드에서 ALLOW 정책을 지우고 DENY /admin* 만 남겼다. POST / 가 앱에서 501 을 받았다. 이 결과를 만든 것은?

• DENY 필터가 POST 를 자기가 모르는 메서드로 보고 판정 없이 앱에 넘겼기 때문이다
• 워크로드에 ALLOW 정책이 없으면 ALLOW 필터가 생기지 않아, DENY 에 안 걸린 요청은 모두 통과하기 때문이다
• RBAC 필터는 정책이 없는 메서드를 거부할 때 403 대신 501 을 돌려주기 때문이다
• istiod 가 ALLOW 가 없는 워크로드에 모든 요청을 받는 기본 ALLOW 정책을 넣기 때문이다

DENY 필터와 ALLOW 필터의 순서를 바꿔(ALLOW 가 앞) 띄웠더니 네 요청의 결과가 그대로였다. 그 이유는?

• 각 필터는 넘기거나 거부할 뿐이라, 요청이 앱에 닿으려면 두 필터를 모두 통과해야 하기(AND) 때문이다
• Envoy 가 RBAC 필터를 이름의 사전순으로 다시 정렬해 실행하기 때문이다
• ALLOW 필터가 허용하면 DENY 필터는 건너뛰기 때문이다
• 두 필터가 같은 통계를 쓰므로 먼저 판정한 쪽이 나머지를 덮기 때문이다

DENY 정책에 istio.io/dry-run: "true" 를 붙였다. Envoy 쪽에서 일어나는 일로 맞는 것은?

• RBAC 필터가 빠지고 접근 로그에만 정책 이름이 찍힌다
• 정책이 rules 에 그대로 남고 거부 대신 경고 헤더를 붙인다
• 정책이 shadow_rules 로 들어가 평가는 되지만 거부하지 않고 shadow_denied 같은 통계만 오른다
• 정책이 ALLOW 로 뒤집혀 들어가 매치한 요청만 통과시킨다

action: DENY 에 paths 만 적은 정책을 TCP 포트도 여는 워크로드에 걸었다. istioctl 이 경고하는 이유와 권고는?

• TCP 요청에는 경로가 없으므로 DENY 가 적용되지 않아 무의미하다 — 정책을 지우라고 권한다
• DENY 는 요청에 없는 속성을 매치로 보므로 TCP 트래픽이 전부 거부된다 — ports 로 범위를 좁히라고 권한다
• paths 는 ALLOW 에서만 쓸 수 있다 — action 을 ALLOW 로 바꾸라고 권한다
• 경로에 별표를 쓰면 정규식이 되어 느려진다 — 정확한 경로를 쓰라고 권한다