1. 인증 이해
- API서버가 요청을 받으면 인증 플러그인 목록을 거치며, 인증 처리가 진행된다.
- 각각의 인증 플러그인은 요청을 검사해 보낸 사람이 누구인지 밝혀내려 시도한다.
- 요청 정보를 통해 사용자 이름, 사용자 ID, 사용자 그룹을 찾아내는 플러그인은 해당 정보를 API서버 코어에 반환한다.
- API 서버는 나머지 인증 플러그인 호출을 중지한다
- 인가 단계를 진행한다
인증 플러그인이 클라이언트 ID 얻는 방법
- 클라이언트의 인증서
- HTTP 헤더로 전달된 인증 토큰
- 기본 HTTP 인증
- 기타
1.1 사용자와 그룹
[Techplayon] Security in Kubernetes – Service Account
사용자
쿠버네티스는 API 서버에 접속하는 클라이언트를 두 종류로 구분한다.
- 실제 사람(사용자)
- SSO(Single Sign On)과 같은 외부 시스템에 의해 관리
- Pod (Pod내부에서 실행되는 애플리케이션)
- Service Account라는 메커니즘을 사용
그룹
- 실제 사람(사용자)와 Service Account는 하나 이상의 그룹에 속할 수 있다.
- 인증 플러그인 반환 값
- 사용자 이름
- 사용자 ID
- 사용자 그룹
- 내장된(built-in) 그룹
| 내장된(built-in) 그룹 | 설명 |
| system:unauthenticated | 인증되지 않은 사용자를 나타냅니다. 이 그룹에 속한 사용자는 클러스터 리소스에 액세스할 수 없습니다. |
| system:authenticated | 인증된 사용자를 나타냅니다. 이 그룹에 속한 사용자는 클러스터 리소스에 액세스할 수 있습니다. |
| system:serviceaccounts | 클러스터 내부에서 실행되는 ServiceAccount에 대한 권한을 제어하는 그룹입니다. |
| system:serviceaccounts:<namespace> |
특정 네임스페이스에서 실행되는 ServiceAccount에 대한 권한을 제어하는 그룹입니다. |
1.2 서비스어카운트 소개
- 각 파드는 딱 하나의 서비스어카운트와 연결
- 여러 파드가 같은 서비스어카운트를 사용가능
- 같은 네임스페이스의 서비스어카운트만 사용가능
서비스어카운트가 인가와 어떻게 밀접하게 연계되는지 이해하기
- 파드에 서비스어카운트 할당
- 명시적 - Pod 매니페스트에 서비스어카운트 이름 지정
- 묵시적 - 명시적으로 할당하지 않으면 default 서비스어카운트를 사용함
[medium] Kubernetes Tips : How Service Account operates
- API 서버가 인증 토큰이 있는 요청을 수신
- API 서버는 토큰을 사용해 요청을 보낸 클라이언트를 인증한다
- 관련 서비스어카운트가 요청된 작업을 수행할 수 있는지 여부를 결정
1.3 서비스어카운트 생성
- kubectl describe를 이용해 Service Accout 검사하기
- 사용자 정의 토큰 시크릿 생성 > Service Account와 연계
- kubectl describe secret foo-token-qzq7j
- Mountable secrets 이란?
- secret을 환경변수, 파일시스템 경로 등으로 Pod내 Application에게 secret을 안전하게 전달하는 기능
- secret을 포함하는 볼륨을 Pod에 Mount 가능
- Mountable secret을 사용하는 이유
- 보안강화 : 특정 Service Account에 대해 마운트할 수 있는 Secret을 제한 > 최소한의 Secret만 부여
- 원하는 Secret만 Mount가능
- Service Account의 Image Pull Secret 이란?
- 프라이빗 이미지 레포지터리에서 컨테이너 이미지를 가져오는데 필요한 자격증명을 가지고 있는 Secret
- Mountable Secret과는 약간 다르게 동작
- Service Account에 Image Pull Secret 추가하면, 모든 파드에 특정 Image Pull Secret을 자동으로 추가한다.
1.4 파드에 서비스어카운트 할당
- spec.serviceAccountName
- Pod에 Service Account를 할당
2. 역할 기반 액세스 제어로 클러스터 보안
- 쿠버네티스 1.6.0 이전 버전 - 클러스터 보안
- 파드 중 하나에서 인증 토큰 획득 > 해당 토큰으로 클러스터에서 어떤 작업이든 수행할 수 있었다.
- path traversal or directory traversal 취약점 공격 > 토큰 획득이 가능했었다.
- 쿠버네티스 1.8.0 버전에서 RBAC 인가 플러그인이 GA로 승격 > 클러스터에서 기본적으로 활성화
- RBAC 권한이 없는 사용자는 클러스터 상태 조회 및 수정이 불가능해졌다.
- Default ServiceAccount는 추가 권한을 부여하지 않는 한 클러스터 상태 조회 및 수정이 불가능하다.
2.1 RBAC 인가 플러그인 소개
- 쿠버네티스 API서버는 인가(Authorization) 플러그인을 사용해 사용자의 Action에 대한 권한 검사가 가능하다.
- 사용자는 요청에 자격증명(인증토큰, ID, PW, 클라이언트 인증서)를 포함시켜 자신을 인증(Authentication)한다.
Action이란?
- 클라이언트는 GET, POST, PUT, DELETE 및 기타 유형의 HTTP 요청을 쿠버네티스 API 서버로 전송한다.
- Action 예시
- 파드 가져오기 Get
- 서비스 생성하기 Create
- 시크릿 업데이트 Update
- 기타 등등
RBAC 플러그인 이해
- User Role
- RBAC 인가 플러그인의 핵심요소
- 사용자가 액션을 수행할 수 있는지 여부를 결정하는 기준
- 주체(사용자, ServiceAccount, 그룹)는 하나 이상의 Role과 연계(Association)돼 있으며, 각 롤은 특정 리소스에 특정 동사를 수행할 수 있다.
- AWS IAM Role개념과 유사하다.
2.2 RBAC 리소스 소개
- RBAC 인가 규칙은 4개의 리소스로 구성되며, 2개의 그룹으로 분류 가능하다.
| Role(수행할 수 있는 작업 정의) | Binding(누가 수행가능한지) |
| Role | RoleBinding |
| ClusterRole | ClusterRoloBinding |
- Role > AWS IAM Policy
- Binding > AWS IAM TrustRelationShip
2.3 롤과 롤바인딩 사용
- 롤 정의
- 롤 생성
- ServiceAccount에 Role 바인딩
- RoleBinding - 다른 네임스페이스의 ServiceAccount 포함하기
2.4 클러스터롤과 클러스터롤바인딩 사용하기
- ClusterRole, ClusterRoleBinding은 네임스페이스를 지정하지 않는다.
ClusterRole, ClusterRoleBinding이 필요한 이유
- Role, RoleBinding은 동일한 네임스페이스만 액세스 가능
- 만약, 다른 네임스페이스의 리소스가 액세스하기 위해서는 해당 네임스페이스마다 Role, RoleBinding을 만들어야 한다.
- 모든 네임스페이스에 엑세스가 필요한 경우, 모든 네임스페이스마다 동일한 Role, RoleBinding을 생성해야 한다.
- 특정 리소스는 전혀 네임스페이스를 지정하지 않는다 (노드, 퍼시스턴트볼륨, 네임스페이스 등)
- 클러스터 수준 리소스의 액세스 허용을 쉽게 관리하기 위해서 ClusterRole, ClusterRoleBinding이 필요하다.
Cluster 수준 리소스에 액세스 허용
- RoleBinding으로 ClusterRole 바인딩 시도
- 클러스터 수준 리소스에 액세스 권한을 부여하기 위해서는 ClusterRoleBinding을 사용해야 된다.
2.5 디폴트 클러스터롤과 클러스터롤바인딩의 이해
2.6 인가 권한을 현명하게 부여하기
[tistory - 악분] [CKS] 클러스터 보안 - pod의 serviceaccount token
[medium] Kubernetes Tips : How Service Account operates
[Techplayon] Security in Kubernetes – Service Account
