인가 정책의 번역 확인

6문항. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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