Kubernetes: Up and Running, 제3판

14장. Kubernetes를 위한 역할 기반 접근 제어

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

이 시점에서 거의 모든 Kubernetes 클러스터에는 역할 기반 액세스 제어(RBAC)가 활성화되어 있습니다. 따라서 이전에 RBAC를 접해 보셨을 것입니다. 아마도 처음에는 마법 같은 명령을 사용하여 사용자를 역할에 매핑하는 역할 바인딩을 추가하기 전까지는 클러스터에 액세스할 수 없었을 것입니다. RBAC를 어느 정도 접한 적이 있더라도, 그 용도와 사용 방법 등 Kubernetes에서 RBAC를 이해한 경험이 많지 않았을 수도 있습니다.

역할 기반 액세스 제어는 권한이 있는 사용자만 액세스하도록 하기 위해 Kubernetes API에 대한 액세스 및 작업을 모두 제한하는 메커니즘을 제공합니다. RBAC는 애플리케이션을 배포하는 Kubernetes 클러스터에 대한 액세스를 강화하고 (더 중요한 것은) 잘못된 네임스페이스에 있는 한 사람이 테스트 클러스터를 파괴한다고 생각하여 프로덕션을 실수로 다운시키는 예기치 않은 사고를 방지하는 데 중요한 구성 요소입니다.

참고

RBAC는 Kubernetes API에 대한 액세스를 제한하는 데 매우 유용할 수 있지만, Kubernetes 클러스터 내에서 임의의 코드를 실행할 수 있는 사람은 누구나 전체 클러스터에 대한 루트 권한을 효과적으로 얻을 수 있다는 점을 기억하는 것이 중요합니다. 이러한 공격을 더 어렵고 더 비싸게 만들기 위해 취할 수 있는 접근 방식이 있으며, 올바른 RBAC 설정은 이러한 방어의 일부입니다. 그러나 적대적인 멀티테넌트 보안에 초점을 맞추고 있다면, RBAC만으로도 충분히 보호할 수 있다. 효과적인 멀티테넌트 보안을 제공하려면 클러스터에서 실행 중인 파드를 격리해야 한다. 일반적으로 이는 하이퍼바이저 격리 컨테이너 또는 컨테이너 샌드박스를 사용하여 수행됩니다.

Kubernetes의 RBAC에 대해 자세히 알아보기 전에, 인증 및 권한 부여에 대한 일반적인 이해뿐만 아니라 개념으로서의 RBAC에 대해 높은 수준의 이해를 갖는 것이 중요합니다.

Kubernetes에 대한 모든 요청은 먼저 인증됩니다. 인증은 요청을 발행하는 호출자의 신원을 제공합니다. 인증은 요청이 인증되지 않았다고 말하는 것처럼 간단할 수도 있고, 플러그 가능한 인증 공급자(예: Azure Active Directory)와 긴밀하게 통합되어 해당 타사 시스템 내에서 신원을 설정할 수도 있습니다. 흥미롭게도 Kubernetes에는 기본 제공 ID 저장소가 없으며, 대신 자체 내에서 다른 ID 소스를 통합하는 데 중점을 둡니다.

사용자가 인증되면 권한 부여 단계에서 요청을 수행할 권한이 있는지 여부를 결정합니다. 권한 부여는 사용자의 신원, 리소스(사실상 HTTP 경로), 사용자가 수행하려는 동사 또는 작업의 조합입니다. 특정 사용자가 해당 리소스에 대해 해당 작업을 수행할 권한이 있는 경우 요청이 진행되도록 허용됩니다. ...