API Groups
클러스터와 관련해 kubectl 명령어나 REST API를 통해 어떤 작업을 했든 kube-api server와 상호작용해왔다.
쿠버네티스 API는 목적에 따라 여러 그룹으로 그룹화된다.
예를 들어, /metrics, /healthz, /version, /api, /apis, /logs 등이 있다.
/version API는 클러스터의 버전을 보기 위한 것이다.
/metrics와 /healthz API는 클러스터의 상태를 모니터하는 데 사용된다.
/logs는 타사 로그와 통합하는 데 사용된다.
이번 강의에서는 클러스터 기능을 책임지는 API에 초점을 맞춘다.
이 API는 core 그룹과 named 그룹 이렇게 2가지로 분리된다.
named 그룹 API는 좀 더 조직화되어 있고 새로운 기능들도 사용 가능하다.
맨 위에 있는 건 API Groups이고 맨 밑에 있는 건 해당 그룹의 Resources이다.
각 리소스는 관련 동작 모음(Verbs)을 가지고 있다.
쿠버네티스 API 참조 페이지는 각 개체에 대한 API 그룹을 알려준다.
kube-api server에 아무 경로 텍스트없이 접근하면 사용 가능한 API 그룹 리스트가 나온다.
/apis API에 접근해서 named API 그룹 내에서 짖원되는 모든 리소스 그룹을 확인할 수 있다.
curl 명령어를 통해 API에 직접 접근할 경우, apiVersion과 같은 정보를 제외하고는 접근할 수 없다.(Failure, forbidden)
모든 정보를 확인하기 위해서는 특정 인증 매커니즘(개인키, 인증서, ca)을 지정해서 인증서 파일을 이용해 API에 인증해야 한다.
또 다른 방법은 kubectl proxy 클라이언트를 시작하는 것이다.
kubectl proxy 명령을 실행해서 127.0.0.1:8001에서 동작하는 프록시 서비스를 실행한다.
클러스터 접근을 위해 kubeconfig 파일의 자격 증명과 인증서를 사용하기 때문에 curl 명령어에 인증 매커니즘을 지정하지 않아도 된다.
curl localhost:8001 명령어를 통해 kubectl proxy 서비스에 접근할 수 있다. kubectl proxy는 kubeconfig 파일의 자격 증명을 이용해 kube-api server로 요청을 전달한다. 루트에서 사용 가능한 모든 API를 나열한다.
kube proxy는 kubectl proxy가 아니다.
kube-proxy는 클러스터 내 다양한 노드에 걸쳐 파드와 서비스 간의 연결을 가능하게 하는 데 사용된다.
반면에, kubectl proxy는 HTTPS 프록시 서비스로 kubectl 유틸리티가 kube-api server에 접근하기 위해 만든 것이다.
요약하자면 쿠버네티스의 모든 리소스는 다른 API 그룹으로 그룹화되어 있다.
상단 레벨에는 cored API 그룹과 named API 그룹이 있다.
named API 그룹 아래에는 다양한 리소스가 있고 각 리소스엔 verbs라는 관련 작업 모음이 있다.
Authorization
접속해서 무엇을 할 수 있는지가 Authorization의 정의이다.
우리는 필요한 작업을 수행하기 위한 최소한의 접근만 제공하기를 바란다. 클러스터를 서로 다른 조직이나 팀으로 공유하기 위해 namespace를 이용해 논리적으로 분할하여 사용자에 대한 접근을 제한할 수 있다. 클러스터 내에서 Authorization(권한 부여)는 접근을 제한한다.
쿠버네티스가 지원하는 Authorization 메커니즘은 다양하다.
Node, ABAC(Attribute-Based Access Control), RBAC(Role-Based Access Control), Webhook이 있다.
kube-api server는 관리 목적으로 우리와 같은 사용자, 클러스터 내 노드의 kubelet에 의해 접근된다.
kubelet은 kube-api server에 접근하여 Services, Endpoints, Nodes, Pods에 관한 정보를 읽고 Node status, Pod status, events에 대한 정보를 보고한다.
이러한 kubelet의 요청은 특별한 승인자(Node Authorizer)에 의해 처리된다.
이전 강의에서 인증서에 관해 이야기 할 때, kubelet은 system:node 그룹의 일부이며 이름 앞에 'system:node'를 붙여야 했다. system:node 그룹의 일부로 사용자가 요청하면 Node Authorizer에 의해 승인되고 kubelet은 특권을 부여받는다.
이 것이 클러스터 내에서 접근할 경우 권한을 부여받는 방법이다.
kube-api server의 외부 접근에 대해 이야기해보자.
ABAC(Attribute-Based Access Control, 특성 기반 접근 제어)란 사용자나 사용자 그룹을 권한 모음으로 연결하는 것이다.
예를 들어, 개발자(dev-user)는 pod를 보고 생성하고 삭제할 수 있다.
이런 식으로 인접형식으로 정의된 Policy 파일을 생성하고 kube-api server에 이 파일을 넘겨야 한다.
각각의 사용자나 그룹에 대한 policy 정의 파일을 만들 수 있다.
보안을 추가하거나 변경해야 할 때마다 policy 파일을 수동으로 수정하고 kube-api server를 다시 시작해야 한다. 그래서 ABAC는 관리하기 어렵다
다음으로 RBAC(Role-Based Access Control, 역할 기반 접근 제어)이다.
RBAC는 사용자나 그룹을 권한 집합(policy)로 직접 연결하는 대신 역할을 정의한다.
요구되는 권한 집합으로 역할을 생성하고 해당 역할이 필요한 사용자에게 그 역할을 연결한다.
앞으로는 사용자의 접근 권한에 변화가 필요할 때마다 역할을 수정하기만 하면 된다. 그러면 모든 사용자에게 즉시 반영된다.
RBAC는 쿠버네티스 클러스터 내에서 접근 권한 관리에 좀 더 표준적인 접근법을 제공한다.
내장 메커니즘이 아닌 외부에서 접근 권한을 관리하고 싶을 수 있다.
가령, Open Policy Agent는 입장 통제와 승인을 도우며 접근 권한을 관리한다. 쿠버네티스는 사용자에 관한 정보와 요구 사항 접근 정보와 함께 Open Policy Agent에 API 통신을 할 수 있다. Open Policy Agent가 사용자의 허용 여부를 결정하게 하는 것이다. Open Policy Agent의 응답에 근거해 사용자는 접근 권한을 부여받는다.
그 외에도 AlwaysAllow와 AlwaysDeny 모드가 있다.
AlwaysAllow는 어떤 승인 확인도 없이 모든 요청을 허용한다.
AlwaysDeny는 항상 모든 요청을 거절한다.
kube-api 서버의 '--authorization-mode' 옵션을 통해 Authorization mode를 설정할 수 있다. 이 옵션을 지정하지 않으면 기본값으로 AlwaysAllow가 설정된다.
다양한 모드 목록을 쉼표로 표시할 수 있다.
다양한 모드를 설정한 경우, 지정된 순서대로 각각의 요청을 사용할 권한이 부여된다.
모듈의 요청이 거부될 때마다 체인의 다음 모듈로 전달된다. 모듈이 요청을 승인하는 순간 더는 확인하지 않고 사용자가 승인을 받는다.
Role Based Access Controls
이번 강의에서는 RBAC(Role-Based Access Control, 역할 기반 접근 제어)을 상세히 살펴보자.
Role 개체를 만들기 위해 Role 정의 파일을 작성해야 한다.
Role 정의 파일에는 rules 영역이 있다. rules 영역은 apiGroups, resources, verbs 이렇게 세 개의 섹션으로 나눠진다.
이전 강의에서 배웠듯이 core 그룹은 apiGroups 필드를 비워둘 수 있다.
역할 하나에 여러 규칙을 추가할 수 있다.
다음 단계는 사용자를 그 역할에 링크하는 것이다. Rolebinding 개체를 만들어서 사용자 개체를 Role에 연결한다.
subjects 영역은 사용자의 세부 정보를 지정하는 영역이다.
roleRef 영역은 우리가 만든 Role의 세부사항을 제공하는 영역이다.
kubectl create 명령어를 통해 RoleBinding 개체를 생성해야 한다.
Role과 RoleBinding은 네임스페이스의 범위 아래에 있다. 아래 예시에서는 namespace를 지정하지 않았기 때문에 기본 네임 스페이스에서 dev-user는 pod 및 configMap에 점근할 수 있다.
만약 다른 네임스페이스에서 역할을 제한하고 싶다면 Role과 RoleBinding 정의 파일의 metadata 영역의 namespace 필드를 다른 네임스페이스로 지정해야 한다.
생성된 Role, RoleBinding을 확인하는 명령어는 다음과 같다.
사용자가 특정 리소스에 접근할 수 있는 지 확인하는 명령어는 다음과 같다.
만약 관리자라면 '--as' 옵션을 지정하여 다른 유저를 사칭해 다른 유저의 권한을 확인할 수도 있다.
명령에서 네임스페이스를 지정할 수도 있다.
한 단계 더 내려가 특정 리소스에만 접근 권한을 부여할 수도 있다.
Role 정의 파일의 rules 영역에 resourceName 필드를 추가하고 특정 리소스의 이름을 명시하면 된다.
아래 예시의 경우, 사용자는 rules에 resourceName 필드를 추가하여 blue, orange 파드에만 접근할 수 있도록 제한하였다.
테스트 문제 정리
Inspect the environment and identify the authorization modes configured on the cluster. ( 클러스터에 구성된 인증 모드)
kubectl describe pod kube-apiserver-controlplane -n kube-system | grep authorization
Create the necessary roles and role bindings required for the dev-user to create, list and delete pods in the default namespace. (dev-user가 기본 네임스페이스에서 Pod를 생성, 나열 및 삭제하는 데 필요한 역할과 역할 바인딩을 생성)
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: developer
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["list", "create","delete"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: dev-user-binding
subjects:
- kind: User
name: dev-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: developer
apiGroup: rbac.authorization.k8s.ioAdd a new rule in the existing role developer to grant the dev-user permissions to create deployments in the blue namespace.(새 규칙을 추가하여 블루 네임스페이스 에서 deployments 를 생성할 수 있는 dev-user 권한을 부여)
kubectl edit role developer -n blue
아래의 내용추가
- apiGroups:
- apps
resources:
- deployments
verbs:
- create테스트 통과 완료
