Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

쿠버네티스 API 서버 보안 #11

Open
limecats0331 opened this issue Aug 23, 2024 · 0 comments
Open

쿠버네티스 API 서버 보안 #11

limecats0331 opened this issue Aug 23, 2024 · 0 comments

Comments

@limecats0331
Copy link
Collaborator

limecats0331 commented Aug 23, 2024

인증 이해

API 서버는 하나 이상의 인증 플러그인으로 구성할 수 있다.
API 서버가 요청을 받으면 인증 플러그인 목록을 거치면서 요청이 전달되고, 각각의 인증 플러그인이 요청을 검사해서 보낸 사람이 누군지 판별

  • 클라이언트의 인증서
  • HTTP 헤더의 전달된 인증 토큰
  • 기본 HTTP 인증
  • 기타

사용자와 그룹

사용자

쿠버네티스 API 서버에 접속하는 두 종류의 클라이언트를 구분한다.

  • 실제 사람(사용자)
  • 파드

그룹

휴먼 사용자와 서비스어카운트는 하나 이상의 그룹에 속할 수 있음
개별 사용자에게 권한을 부여하지 않고 한 번에 여러 사용자에게 권한을 부여하는데 사용

내장된 그룹은 특별한 의미를 가짐

  • system:unauthenticated : 어떤 플러그인에서도 인증할 수 없는 요청에 사용
  • system:authenticated : 성공적으로 인증된 사용자에 자동으로 할당
  • system:serviceaccounts : 시스템의 모든 서비스어카운트를 포함
  • system:serviceaccounts:<namespace> : 특정 네임스페이스의 모든 서비스어카운트 포함

서비스어카운트

/var/run/secrets/kubenetes.io/serviceaccount/token 파일로 인증하는 법을 다뤘었다.
모든 파드는 파드에서 실행중인 애플리케이션의 아이덴티티를 나타내는 서비스어카운트와 연계돼 있다.

이 토큰을 사용해서 API 서버에 접속하면 인증 플러그인이 서비스어카운트를 인증하고 서비스어카운트의 사용자 이름을 API 서버 코어로 전달한다.

이름은 다음과 같은 형식이다.
system:serviceaccount:<namespace>:<service account name>

API 서버는 설정된 인가 플러그인에 이 사용자 이름을 전달하며, 이 인가 플러그인은 애플리케이션이 수행하려는 작업을 서비스어카운트에서 수행할 수 있는지를 결정한다.

서비스어카운트는 파드 내부에서 실행되는 애플리케이션 API 서버에 자신을 인증하는 방법에 지나지 않는다.

서비스 어카운트 리소스

서비스 어카운트는 파드같은 리소스이며 개별 네임스페이스로 범위가 지정
각 네임스페이스마다 default 서비스아카운트가 자동으로 생성

역할 기반 엑세스 제어로 클러스터 보안

1.8.0 버전에서 RBAC 인가 플러그인이 GA로 승격됐었다.
RBAC는 권한이 없는 사용자가 클러스터 상태를 보거나 수정하지 못하게 함
default 서비스어카운트는 추가 권한을 부여하지 않는 한 클러스터 상태를 볼 수 없음

RBAC 인가 플러그인

API 서버는 인가 플러그인을 통해 액션을 요청하는 사용자가 액션을 수행할 수 있는지 점검하도록 설정할 수 있음
사용자는 요청에 자격증명을 포함시켜 자신을 인증

액션

HTTP 메서드 단일 리소스에 관한 동사 컬렉션에 관한 동사
GET, HEAD get (and watch for watching) list (and watch)
POST create n/a
PUT update n/a
PATCH patch n/a
DELETE delete deletecollection
권한 부여 동사와 HTTP 메서드 매핑

RBAC 플러그인 이해

사용자가 액션을 수행할 수 있는지 여부를 결정하는 요소로 사용자 롤을 사용
주체(사람, 서비스어카운트 등)는 하나 이상의 롤과 연계돼 있으며 각 롤은 특정 리소스에 특정 동사를 수행할 수 있음

네 가지 RBAC 관련 리소스를 생성하기만 하면 된다.

리소스
  • 롤, 클러스터롤 - 리소스에 수행할 수 있는 동사를 지정
  • 롤바인딩, 롤클러스터롤바인딩 - 롤을 특정 사용자, 그룹 또는 서비스어카운트에 바인딩

롤, 롤바인딩은 네임스페이스에 지정된 리소스
클러스터롤, 롤클러스터롤바인딩은 클러스터 수준의 리소스

  • 롤, 클러스터롤, 롤바인딩, 클러스터롤바인딩 조합에 관한 요약
접근 롤 타입 사용할 바인딩 타입
클러스터 수준 리소스(노드, 퍼시스트볼륨) 클러스터롤 클러스터롤바인딩
리소스가 아닌 URL(/api, /healthz, ...) 클러스터롤 클러스터롤바인딩
모든 네임스페이스의 네임스페이스로 지정된 리소스 클러스터롤 클러스터롤바인딩
특정 네임스페이스의 네임스페이스로 지정된 리소스(여러 네임스페이스에 동일한 클러스터 재사용) 클러스터롤 롤바인딩
특정 네임스페이스의 네임스페이스로 지정된 리소스(각 네임스페이스에 롤을 정의해야 함) 롤바인딩

인가 권한을 현명하게 부여하기

  • 각 파드를 위한 특정 서비스 어카운트 생성
  • 어플리케이션이 탈취될 가능성을 염두에 두기
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant