クイズ: RBAC

ClusterRole 을 RoleBinding 으로 연결하면 권한의 범위는?

• 그 RoleBinding 이 속한 네임스페이스에서만
• 그 ClusterRole 이 만들어진 네임스페이스에서만
• 역할과 바인딩의 종류가 어긋나 바인딩이 무시된다
• ClusterRole 이라 클러스터 전체 리소스에 적용된다

Role 규칙에서 파드를 다루려는데 권한이 먹지 않습니다. 가장 흔한 원인은?

• 네임스페이스에 라벨이 없다
• apiGroups 에 "v1" 을 적었다
• verbs 에 list 를 빠뜨렸다
• RoleBinding 이름이 잘못됐다

pods 에 대해 get·list 권한이 있는 주체가 kubectl logs 를 실행하면?

• pods/log 권한이 따로 필요해 거부된다
• 네임스페이스 관리자로 승격해야 로그를 볼 수 있다
• pods 권한에 서브리소스가 포함돼 성공한다
• 파드가 Running 상태일 때만 성공한다

kubectl auth can-i list pods --as=system:serviceaccount:rbac-lab:app-reader -n default 가 no 를 돌려주는 이유로 옳은 것은?

• default 네임스페이스는 RBAC 판정에서 특별 취급되기 때문
• app-reader 의 토큰이 이미 만료돼 인증에 실패했기 때문
• 서비스 어카운트에는 impersonation 을 쓸 수 없다
• RoleBinding 은 자기 네임스페이스에서만 유효하기 때문

verbs: ["*"] 를 쓰는 것이 위험한 이유로 가장 정확한 것은?

• 나중에 추가되는 동사나 리소스까지 자동으로 포함돼 권한이 조용히 넓어진다
• 와일드카드로 준 권한은 감사 로그에 리소스 이름이 남지 않는다
• * 가 들어간 역할에는 RoleBinding 을 만들 수 없다
• 요청마다 모든 동사를 대조해야 해서 인가 판정이 느려진다

노드 목록을 볼 수 있게 하려면?

• 네임스페이스에 Role + RoleBinding
• 클러스터 범위로 Role + ClusterRoleBinding
• ClusterRole + ClusterRoleBinding
• ServiceAccount 에 node-reader 라벨 추가

권한 감사에서 우선적으로 확인할 항목으로 가장 적절한 조합은?

• Service 타입, Ingress 호스트 규칙, PVC 스토리지클래스
• cluster-admin 바인딩, 와일드카드 역할, secrets 를 읽는 역할
• 네임스페이스별 파드 수, 노드 수, 컨테이너 이미지 태그 개수
• 이미지 태그 정책, 컨테이너 리소스 요청량, 파드 보안 라벨