[k8s]시작하세요! 도커/쿠버네티스(kubernetes) - 보안을 위한 인증과 인가(ServiceAccount, RBAC, role, rolebinding, kubeconfig)

여러 명의 개발자가 쿠버네티스에 접근할 수 있고, 각 개발자가 kubectl 같은 명령어를 통해 애플리케이션을 동시에 배포할 수 있어서 보안이 매우 중요합니다.

자주 사용되는 것은 RBAC(Role Based Access Control)를 기반으로 하는 서비스 어카운트 기능입니다. 서비스 어카운트는 사용자 또는 애플리케이션 하나에 해당하며, RBAC라는 기능을 통해 특정 명령을 실행할 수 있는 권한을 서비스 어카운트에 부여합니다. 권한을 부여받은 서비스 어카운트는 해당 권한에 해당하는 기능만 사용할 수 있습니다.

지금까지 kubectl 명령어를 사용해왔던 권한은 사실 최상위에 해당하는, 마치 리눅스의 root 사용자와 같은 권한을 가지고 있습니다. 쿠버네티스의 API에 접근하는 애플리케이션을 운영 환경에 배포하거나, 여러 명의 사용자가 동시에 쿠버네티스를 사용해야 한다면 최상위 권한을 사용하지 않는 것이 좋습니다. 사용자에게 필요한 권한만을 최소한으로 부여함으로써 실행할 수 있는 기능을 제한하는 것이 바람직합니다.

이번 블로깅에서는 서비스 어카운트(ServiceAccount) 및 RBAC를 사용하기 위한 롤(Role), 클러스터 롤(ClusterRole) 등을 먼저 사용해본 뒤, 사용자를 추상화한 유저 및 그룹 OIDC(Open ID Connect)에 대해서 공부해봅니다.

쿠버네티스의 권한 인증 과정

kubectl apply 명령어를 사용해 쿠버네티스의 기능을 실행하면 내부에서는 아래의 그림과 같은 절차를 거치게 됩니다.

가장 먼저 kubectl 명령어는 쿠버네티스 API 서버의 HTTP 핸들러에 요청을 전송합니다. API 서버는 해당 클라이언트가 쿠버네티스의 사용자가 맞는지(Authentication), 해당 기능을 실행할 권한이 있는지(Authorization) 확인합니다. 인증과 인가에는 서비스 어카운트 외에도 서드파티 인증(Open ID Connect: OAuth), 인증서 등과 같이 다양한 방법이 사용될 수 있습니다. 그 뒤에는 Admission Controller라는 별도의 단계를 거친 뒤 비로소 요청 받는 기능을 수행합니다.

kubectl이 관리자 권한을 갖는 이유는 설치 도구를 사용해서 쿠버네티스를 설치할 때 설치 도구가 자동으로 kubectl이 관리자 권한을 갖도록 설정해 두기 때문인데, 그러한 설정은 ~/.kube/config라는 파일에서 확인할 수 있습니다.

kubectl을 사용할 때는 기본적으로 ~/.kube/config라는 파일에 저장된 설정을 읽어 들여 쿠버네티스 클러스터를 제어합니다. 이 파일에 저장된 내용 중에서 users라는 항목에는 인증을 위한 데이터가 설정돼 있습니다. client-certificate-data와 client-key-data에 설정된 데이터는 base64로 인코딩된 인증서인데, 이 키 쌍은 쿠버네티스에서 최고 권한(cluster-admin)을 갖습니다.

기본적으로 설정된 ~/.kube/config 파일에서는 인증서 키 쌍을 사용해 API 서버에 인증하지만, 이 인증 방법은 비교적 절차가 복잡하고 관리하기가 어렵기 때문에 자주 사용하는 방법은 아닙니다. 다른 여러 가지 방법을 사용하여 인증할 수 있는데 그 중 하나가 서비스 어카운트(ServiceAccount)입니다.

서비스 어카운트와 롤(Role), 클러스터 롤(Cluster Role)

서비스 어카운트는 한 명의 사용자나 애플리케이션에 해당한다고 볼 수 있습니다.

$ kubectl get sa

kubectl create, delete를 통해 서비스 어카운트를 생성, 삭제할 수 있습니다.

$ kubectl create sa ihp001

새로만든 서비스 어카운트를 이용해 kubectl 명령어를 사용해 보겠습니다. --as 옵션을 사용해 임시로 특정 서비스 어카운트를 사용합니다.

$ kubectl get service
$ kubectl get service --as system:serviceaccount:default:ihp001

--as 옵션에 사용된 system:serviceaccount는 인증을 위해 서비스 어카운트를 사용한다는 것을 나타내며, default:ihp001은 default 네임스페이스의 ihp001 서비스 어카운트를 의미합니다.

ihp001 서비스 어카운트로 서비스의 목록을 조회했더니 API 서버로부터 에러가 반환됐습니다. 이 서비스 어카운트는 default 네임스페이스에서 서비스 목록을 조회할 수 있는 권한이 아직 부여가 안됐기 때문입니다.

쿠버네티스에서 권한을 부여하는 방법은 크게 두 가지가 있습니다. 롤(Role)과 클러스터 롤(Cluser Role)을 이용해 권한을 설정하는 것입니다.

롤과 클러스터 롤은 부여할 권한이 무엇인지를 나타내는 쿠버네티스 오브젝트입니다. 그 중에 롤은 네임스페이스에 속하는 오브젝트이므로 디플로이먼트나 서비스처럼 네임스페이스에 속하는 오브젝트들에 대한 권한을 정의할 때 쓰입니다.

클러스터 롤은 말 그대로 클러스터 단위의 권한을 정의할 때 사용합니다. 네임스페이스에 속하지 않는 오브젝트뿐만 아니라 클러스터 전반에 걸친 기능을 사용하기 위해서도 클러스터 롤을 정의할 수 있으며, 여러 네임스페이스에서 반복적으로 사용되는 권한을 클러스터 롤로 만들어 재사용하는 것도 가능합니다.

$ kubectl get role 
$ kubectl get clusterrole

클러스터 롤은 쿠버네티스 컴포넌트가 사용하는 권한도 포함하기 때문에 꽤 많은 수의 클러스터 롤이 미리 생성돼 있습니다. 쿠버네티스에서 관리자 권한으로 모든 기능을 사용할 수 있는 cluster-admin이라는 클러스터 롤도 있습니다.

롤을 생성해서 실습을 진행해봅시다.

# vi service-reader-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: service-reader
rules:
- apiGroups: [""]
  resources: ["services"] # ["...", "...", ...]는 YAML 파일에서 배열처럼 활용할 수 있는 기능임
  verbs: ["get", "list"]

다른 항목들은 지금까지 많이 학습을 했고, rules 항목의 내용을 보겠습니다.

• apiGroups : 어떤 API 그룹에 속하는 오브젝트에 대해 권한을 지정할지 설정합니다. API 그룹은 쿠버네티스의 오브젝트가 가지는 목적에 따라 분류되는 일종의 카테고리입니다. ""로 설정했는데 이건 포드나 서비스 등이 포함된 코어 API 그룹을 의미합니다. kubectl get-resources에서 APIGROUP이 v1인게 코어 API그룹입니다.
• resources : 어떤 쿠버네티스 오브젝트에 대해 권한을 정의할 것인지 입력합니다. kubectl api-resources에 출력되는 오브젝트의 이름을 활용합니다.
• verbs : 이 롤을 부여받은 대상이 resources에 지정된 오브젝트들에 대해 어떤 동작을 수행할 수 있는지 정의합니다. get, list 동작을 명시했으므로 개별 서비스의 정보를 가져오거나 모든 서비스 목록을 확인할 수 있도록 권한이 부여됩니다.

$ kubectl apply -f service-reader-role.yaml
$ kubectl get roles

롤은 특정 기능에 대한 권한만을 정의하는 오브젝트이기 때문에 롤을 생성하는 것만으로는 서비스 어카운트나 사용자에게 권한이 부여되지 않습니다. 이 롤을 특정 대상에게 부여하려면 롤 바인딩이라는 오브젝트를 통해 특정 대상과 롤을 연결해야 합니다. 서비스 어카운트에 롤에 정의된 권한을 부여하려면 다음과 같은 롤 바인딩을 생성합니다.

# vi rolebinding-service-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: service-reader-rolebinding
  namespace: default
subjects:
- kind: ServiceAccount
  name: ihp001
  namespace: default
roleRef:
  kind: Role
  name: service-reader
  apiGroup: rbac.authorization.k8s.io

롤 바인딩에서는 어떤 대상을 어떠한 롤에 연결할 것인지 정의합니다. subjects 항목에 ihp001이라는 서비스 어카운트를, roleRef 항목에 service-reader 롤을 지정했습니다. 이렇게 되면 ihp001 서비스 어카운트는 service-reader롤에 정의된 권한을 사용할 수 있게 됩니다.

$ kubectl apply -f rolebinding-service-reader.yaml
$ kubectl get svc --as system:serviceaccount:default:ihp001
$ kubectl get deploy --as system:serviceaccount:default:ihp001

서비스의 목록을 확인할 수 있는 권한을 부여받았기 때문에 정상적으로 kubectl get svc 명령어를 사용할 수 있습니다. 그러나 서비스 어카운트에 부여되지 않은 다른 기능들은 여전히 사용할 수 없는 상태입니다.

롤 바인딩 및 롤, 서비스 어카운트는 모두 1:1 관계가 아니라는 점에 유의해야 합니다. 하나의 롤은 여러 개의 롤 바인딩에 의해 참조될 수 있고, 하나의 서비스 어카운트는 여러 개의 롤 바인딩에 의해 권한을 부여받을 수 있습니다.

롤이나 클러스터 롤에서 사용되는 verbs 항목에는 get, list, watch, create, update, patch, delete 등에서 선택해 사용할 수 있지만, 와일드카드를 의미하는 *을 사용할 수도 있습니다. 또한, 특정 리소스에 한정된 기능을 사용할 때는 서브 리소스를 명시해야 할 수도 있습니다. 예를 들어 kubectl exec 명령어로 포드 내부에 들어가기 위한 권한을 생성하려면 포드의 하위 리소스인 pod/exec을 resources 항목에 정의해야 합니다.

...
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]
...

롤 vs 클러스터롤

롤은 포드, 서비스, 디플로이먼트 등과 같이 네임스페이스에 한정된 오브젝트에 대한 권한을 정의하기 위해 사용할 수 있습니다. 클러스터 롤은 네임스페이스 포함 네임스페이스에 종속되지 않는 노드, 퍼시스턴트 볼륨 등과 같은 오브젝트에 대한 권한을 정의하기 위해 사용합니다.

# node, 모든 네임스페이스의 서비스 출력 안됨
$ kubectl get node --as system:serviceaccount:default:ihp001
$ kubectl get svc --as system:serviceaccount:default:ihp001 --all-namespaces

클러스터 롤은 클러스터 단위의 리소스에 대한 권한을 정의하기 위해 사용합니다. 아래의 내용의 YAML 파일을 작성합니다.

# vi nodes-reader-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  namespace: default
  name: nodes-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list"]

YAML 파일은 롤의 내용과 비슷합니다.

$ kubectl apply -f nodes-reader-clusterrole.yaml
$ kubectl describe clusterrole nodes-reader

롤을 사용할 때와 마찬가지로 클러스터 롤을 특정 대상에게 연결하려면 클러스터 롤 바인딩이라고 하는 쿠버네티스 오브젝트를 사용해야 합니다.

# vi clusterrolebinding-nodes-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: nodes-reader-clusterrolebinding
  namespace: default
subjects:
- kind: ServiceAccount
  name: ihp001
  namespace: default
roleRef:
  kind: ClusterRole
  name: nodes-reader
  apiGroup: rbac.authorization.k8s.io

$ kubectl apply -f clusterrolebinding-nodes-reader.yaml
$ kubectl get nodes --as system:serviceaccount:default:ihp001

클러스터 롤과 서비스 어카운트가 잘 연결 됐고, 노드의 목록을 확인할 수 있습니다.

여러 개의 클러스터 롤을 조합해서 사용하기

자주 사용되는 클러스터 롤이 있다면 다른 클러스터 롤에 포함시켜 재사용할 수 있는데, 이를 클러스터 롤 애그리게이션이라고 합니다. 이 기능 테스트를 위한 클러스터롤을 만들겠습니다.

# vi clusterrole-aggregation.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: parent-clusterrole
  labels:
    rbac.authorization.k8s.io/aggregate-to-child-clusterrole: "true"
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: child-clusterrole
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-child-clusterrole: "true"
rules: [] # 어떤 권한도 정의하지 않음
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: node-reader-test
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: parent-clusterrolebinding
subjects:
- kind: ServiceAccount
  name: node-reader-test
  namespace: default
roleRef:
  kind: ClusterRole
  name: child-clusterrole
  apiGroup: rbac.authorization.k8s.io

aggregationRule.clusterRoleSelectors라는 항목을 사용하는데 클러스터 롤에 포함시키고자 하는 다른 클러스터 롤을 matchLabels의 라벨 셀렉터로 선택하면 하위 클러스터 롤에 포함돼 있는 권한을 그대로 부여받을 수 있습니다.

위의 YAML 파일에서는 child-clusterrole에 아무런 권한도 부여하지 않았지만 parent-clusterrole의 권한을 그대로 물려받았으므로 child-clusterrole에서 nodes에 대한 get, list 권한을 가질 수 있습니다.

$ kubectl apply -f clusterrole-aggregation.yaml
$ kubectl get no --as system:serviceaccount:default:node-reader-test

클러스터 롤 애그리게이션을 사용하면 여러 단계의 클러스터 롤 권한 상속 구조를 만들 수 있습니다. 기본적으로 존재하는 클러스터 롤에서도 클러스터 롤 애그리세이션 기능이 있는데, 자동으로 생성돼 있는 admin, edit, view라는 이름의 클러스터 롤의 내용을 확인해보면 view → edit → admin순으로 권한이 전파되는 것을 알 수 있습니다.

이렇게 되면 view 클러스터 롤에 권한을 부여시에 자동으로 admin에도 권한이 적용됩니다.

쿠버네티스 API 서버에 접근

서비스 어카운트의 시크릿을 이용해 쿠버네티스 API 서버에 접근

쿠버네티스의 API 서버는 HTTP 요청을 통해 쿠버네티스의 기능을 사용할 수 있도록 REST API를 제공하고 있습니다. 쿠버네티스의 REST API에 접근하기 위한 엔드포인트는 자동으로 개방되고, 별도의 설정을 하지 않아도 API 서버에 접근할 수 있습니다.

kubeadm의 경우 쿠버네티스의 마슨터 IP와 6443 포트로, GKE나 kops의 경우 443 포트로 접근하면 API 서버에 연결할 수 있습니다. 쿠버네티스 API 서버는 기본적으로 HTTPS 요청만 처리하도록 설정돼 있으며, 기본저긍로 보안 연결을 위해 self-signed 인증서를 사용합니다.

$ curl https://localhost:6443 -k
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "forbidden: User \"system:anonymous\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {},
  "code": 403
}%

이렇게 요청을 하면 401에러와 함께 API 요청이 실패합니다. 401 메시지는 일반적으로 인증되지 않은 사용자(Unauthenticated)를 의미합니다.

API 서버에 접근하려면 별도의 인증 정보를 HTTP 페이로드에 포함시켜 REST API 요청을 전송해야 합니다.

이를 위해 쿠버네티스는 서비스 어카운트를 위한 인증 정보를 시크릿에 저장합니다. 서비스 어카운트를 생성하면 이에 대응하는 시크릿이 자동으로 생성되며, 해당 시크릿은 서비스 어카운트를 증명하기 위한 수단으로 사용됩니다. 시크릿의 목록을 출력해 보면 서비스 어카운트의 이름으로 시작하는 시크릿을 볼 수 있습니다.

$ kubectl get secrets
default-token-t5h2t            kubernetes.io/service-account-token   3      8d
ihp001-token-r6s8q             kubernetes.io/service-account-token   3      3d
node-reader-test-token-4vj6c   kubernetes.io/service-account-token   3      27h

default 서비스 어카운트에 대응하는 default-token-~~ 시크릿도 있습니다. kubectl describe 명령어를 통해 서비스 어카운트의 자세한 정보를 조회하여 어떤 시크릿이 서비스 어카운트에 연결돼 있는지 확인할 수 있습니다.

$ kubectl describe sa ihp001
Name:                ihp001
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   ihp001-token-r6s8q
Tokens:              ihp001-token-r6s8q
Events:              <none>

서비스 어카운트와 연결된 시크릿에는 ca.crt, namespace, token 총 3개의 데이터가 저장돼 있습니다. 이 중 ca.crt는 쿠버네티스 클러스터의 공개 인증서를, namespace는 해당 서비스 어카운트가 존재하는 네임스페이스를 저장하고 있습니다.

$ kubectl describe secrets ihp001-token-r6s8q

token 데이터는 쿠버네티스 API 서버와의 JWT(JSON Web Token) 인증에 사용됩니다. 따라서 API 서버의 REST API 엔드포인트로 요청을 보낼 때 token의 데이터를 함께 담아서 보내면 인증을 할 수 있습니다.

이젠 token 데이터를 가져와야되는데 시크릿의 데이터는 기본적으로 base64로 인코딩되어 있습니다. 따라서 시크릿의 token 데이터를 base64로 디코딩 한 다음, 임시로 셸 변수에 저장해 두겠습니다.

$ export secret_name=ihp001-token-r6s8q
$ export decoded_token=$(kubectl get secrets $secret_name -o jsonpath='{.data.token}' | base64 -d)
$ echo $decoded_token

디코드 된 token 데이터를 HTTP 페이로드의 Bearer 헤더에 담아서 다시 API 요청을 보내 보면 정상적으로 응답이 반환됩니다.

$ curl https://localhost:6443/apis --header "Authorization: Bearer $decoded_token" -k

kubectl에서 사용할 수 있는 기능은 모두 REST API에서도 동일하게 사용할 수 있습니다. 예를 들면 /api/v1/namespaces/default/services 경로로 요청을 보내면 default 네임스페이스에 존재하는 서비스의 목록을 가져올 수 있습니다. kubectl get svc 명령어와 같습니다.

$ curl https://localhost:6443/api/v1/namespaces/default/services \
-k --header "Authorization: Bearer $decoded_token"

/logs, /metrics 같은 몇몇 경로들은 서비스 어카운트가 접근할 수 없도록 제한돼 있습니다. 이 때도 클러스터 롤을 사용하면 위의 경로에도 접근할 수 있도록 권한을 부여할 수 있습니다.

# vi nonresource-url-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: api-url-access
rules:
- nonResourceURLs: ["/metrics", "/logs"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: api-url-access-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: api-url-access
subjects:
- kind: ServiceAccount
  name: ihp001 # 본인의 서비스 어카운트 이름
  namespace: default

$ curl https://localhost:6443/logs -k --header "Authorization: Bearer $decoded_token"
$ curl https://localhost:6443/metrics -k --header "Authorization: Bearer $decoded_token"

클러스터 내부에서 kubernetes 서비스를 통해 API 서버에 접근

이번 섹션에서는 쿠버네티스 클러스터 내부에서 실행되는 애플리케이션이 어떻게 API 서버에 접근하고 인증을 수행하는지 알아보겠습니다.

Nginx 인그레스 컨트롤러는 인그레스의 생성을 동적으로 감지해 Nginx의 라우팅 규칙을 업데이트했습니다. 이렇기 때문에 Nginx 인그레스 컨트롤러는 인그레스 규칙이 생성, 삭제될 때마다 알림을 받을 수 있도록 쿠버네티스의 API 서버에 Watch APi를 걸어둬야 하며, 해당 API 서버에 접근하기 위한 적절한 권한을 부여받아야 합니다.

이를 위해서 쿠버네티스는 클러스터 내부에서 API 서버에 접근할 수 있는 서비스 리소스를 미리 생성해 놓습니다. kubectl get svc에서 항상 나왔던 kubernetes 서비스가 바로 클러스터 내부에서 API 서버에 접근하기 위한 서비스입니다.

$ kubectl get svc

포드 내부에서 kubernetes라는 이름의 서비스에 접근한다고 해서 특별한 권한이 따로 주어지는 것은 아닙니다. 이전에 API 서버에 접근했던 방식과 동일하게 서비스 어카운트에 부여되는 시크릿의 토큰을 HTTP 요청에 담아 kubernetes 서비스에 전달해야 인증 및 인가를 할 수 있습니다.

쿠버네티스는 포드를 생성할 때 자동으로 서비스 어카운트의 시크릿을 포드 내부에 마운트합니다. 따라서 포드 내부에서 API 서버에 접근하기 위해 시크릿의 데이터를 일부러 포드 내부로 가져오지 않아도 됩니다.

포드를 생성하기 위한 YAML 스펙에 아무런 설정을 하지 않으면 자동으로 default 서비스 어카운트의 시크릿을 포드 내부에 마운트합니다. 간단한 포드를 생성한 다음 kubectl describe 명령어로 확인해보겠습니다.

# vi deployment-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-nginx
  template:
    metadata:
      name: my-nginx-pod
      labels:
        app: my-nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.10
        ports:
        - containerPort: 80

$ kubectl apply -f deployment-nginx.yaml
$ kubectl get deploy
$ kubectl get po
$ kubectl describe po my-nginx-deployment-~~~~   # 3개 중 아무거나

그래서 포드 내부에서 API 서버에 접근해야 한다면 token 파일에 저장된 내용을 읽어와 사용하면 됩니다. 해당 경로의 파일을 확인해보면 시크릿의 데이터가 각각 파일로 존재합니다. 만약 포드 내부에서 API 서버에 접근하는 경우라면 token 파일에 저장된 내용을 읽어와 사용하면 서버에 정상적으로 접근이 가능할 것 입니다.

$ kubectl exec my-nginx-deployment-6b4b7f7cdc-54vhr -- \
ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
token

$ kubectl exec my-nginx-deployment-6b4b7f7cdc-54vhr -- \
cat /var/run/secrets/kubernetes.io/serviceaccount/token
eyJhbGciOiJSUz...

포드를 생성하는 YAML 파일에 아무런 설정을 하지 않으면 자동으로 default 서비스 어카운트의 시크릿을 마운트하지만, serviceAccountName 항목을 YAML 파일에서 별도로 지정하면 특정 서비스 어카운트의 시크릿을 마운트 할 수 있습니다.

# vi sa-deploy-nginx.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      name: my-webserver
      labels:
        app: webserver
    spec:
      serviceAccountName: ihp001
      containers:
      - name: my-webserver
        image: alicek106/rr-test:echo-hostname
        ports:
        - containerPort: 80

이런식으로 포드를 생성할 때 serviceAccountName 항목에 특정 서비스 어카운트의 이름을 명시하면 포드 내부로 들어가 해당 서비스 어카운트 토큰을 볼 수 있기 때문에 신뢰할 수 있는 사용자에게만 포드를 생성할 수 있는 권한을 부여 하는 것이 좋습니다.

쿠버네티스 SDK를 이용해 포드 내부에서 API 서버에 접근

포드 내부에서 실행되는 애플리케이션이라면 특정 언어로 바인딩 된 쿠버네티스 SDK를 활용하는 프로그래밍 방식을 더 많이 사용할 것입니다.

서비스 어카운트의 시크릿과 쿠버네티스 SDK를 이용해 API 서버에 접근하는 흐름은 아래와 같습니다.

롤과 롤 바인딩을 통해 특정 서비스 어카운트에 권한이 부여돼 있어야 합니다. 저는 ihp001이라는 이름의 서비스 어카운트를 사용했습니다. (위의 YAML 파일 참고)

$ kubectl create sa ihp001
$ kubectl apply -f service-reader-role.yaml
$ kubeCtl apply -f rolebinding-service-reader.yaml
# 위에서 이미 다 만든 sa, role, rolebinding

YAML 파일에 serviceAccoutnName 항목을 명시적으로 지정해 포드를 생성합니다.

# vi sa-pod-python-sdk.yaml
apiVersion: v1
kind: Pod
metadata:
  name: k8s-python-sdk
spec:
  serviceAccountName: ihp001
  containers:
  - name: k8s-python-sdk
    image: alicek106/k8s-sdk-python:latest

$ kubectl apply -f sa-pod-python-sdk.yaml

포드 내부에서 파이썬 코드를 돌려 쿠버네티스 API를 사용하는 테스트를 해보겠습니다.

# vi list-service-and-pod.py
from kubernetes import client, config

# 포드 내부에 마운트된 서비스 어카운트의 토큰과 인증서 파일을 읽어 들여 인증 및 인가를 진행하는 함수
config.load_incluster_config()

try:
    print('Trying to list service..')

    # 특정 네임스페이스의 서비스 목록을 출력
    result = client.CoreV1Api().list_namespacED_service(namespace='default')

    for item in result.items:
        print('-> {}'.format(item.metadata.name))

except client.rest.ApiException as e:
    print(e)

print('-------')

try:
    print('Trying to list pod..')

    # 특정 네임스페이스의 포드 목록을 출력
    result = client.CoreV1Api().list_namespaced_pod(namespace='default')

    for item in result.items:
        print(item.metadata.name)

except client.rest.ApiException as e:
    print(e)

API의 용도와 종류에 따라 코어 API 그룹에 해당하는 포드나 서비스는 client.CoreV1Api() 함수를 사용하고, 디플로이먼트는 apps라는 이름의 API 그룹에 속하고 client.AppsV1Api() 함수를 사용합니다.

$ python3 list-service-and-pod.py

포드의 목록을 출력할 수 있는 권한은 부여 받지 않아서 에러를 반환합니다.

서비스 어카운트에 이미지 레지스트리 접근을 위한 시크릿 설정

디플로이먼트나 포드의 YAML 파일마다 docker-registry 타입의 시크릿 이름을 정의하지 않고, 비공개 레지스트리 접근을 위한 시크릿을 서비스 어카운트 자체에 설정할 수 있습니다.

docker-registry 타입의 시크릿을 하나 생성합니다.

$ kubectl create secret docker-registry registry-auth-ihp001 --docker-username=ihp001 --docker-password=1234 --docker-email=inhyopark122@gmail.com

서비스 어카운트를 정의합니다. 여기에 docker-registry 타입의 시크릿을 설정합니다.

# vi vi sa-reg-auth.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: reg-auth-ihp001
  namespace: default
imagePullSecrets:
- name: registry-auth-ihp001

YAML 파일을 실행하여 describe 명령어로 자세히 보면 Image pull secrets 정보가 추가된 것을 알 수 있습니다.

포드를 생성하는 YAML 파일에서 serviceAccountName 항목에 reg-auth-ihp001 서비스 어카운트를 지정해 성성하면 자동으로 imagePullSecrets 항목이 포드 스펙에 추가됩니다.

YAML 파일에서 serviceAccountName 항목을 정의하지 않았을 때는 기본적으로 default 서비스 어카운트의 시크릿이 포드에 마운트됩니다. 따라서 default 서비스 어카운트에 imagePullSecrets 항목을 추가하면 아무런 설정을 하지 않았을 때에도 사설 레지스트리 인증을 기본적으로 수행하도록 설정할 수 있습니다.

kubeconfig 파일에 서비스 어카운트 인증 정보 설정

쿠버네티스를 설치하면 kubeconfig 파일에는 기본적으로 클러스터 관리자 권한을 가지는 인증서 정보가 저장되며, 아무런 제한 없이 쿠버네티스를 사용할 수 있습니다.

여러 명의 개발자들이 kubectl 명령어를 사용해야 한다면 권한이 제한된 서비스 어카운트를 통해 kubectl 명령어를 사용하도록 kubeconfig에서 설정할 수 있습니다. 즉, 서비스 어카운트와 연결된 시크릿의 token 데이터를 kubeconfig에 명시함으로써 kubectl 명령어의 권한을 제한할 수 있습니다.

kubeconfig 파일은 일반적으로 ~/.kube/config 경로에 있으며, 필요에 따라 KUBECONFIG 셸 환경 변수로 경로를 직접 설정할 수 있습니다. kubectl은 기본적으로 kubeconfig의 설정 정보에서 API 서버의 주소와 사용자 인증 정보를 로드합니다. kubeconfig는 크게 3가지 파트로 나누어져 있습니다.

• clusters : 쿠버네티스 API 서버의 접속 정보 목록. 원격도 가능
• users : 사용자 인증 정보 목록. 서비스 어카운트의 토큰 등
• contexts : clusters 항목과 users 항목에 정의된 값을 조합해 최종적으로 사용할 쿠버네티스 클러스터의 정보를 설정. 예를 들어 clusters 항목에 클러스터 A, B가 정의돼 있고, users 항목에 사용자 a, b가 정의돼 있다면 cluster A + user a를 조합해 'cluster A에 user a로 인증해 쿠버네티스를 사용한다'라는 새로운 컨텍스트를 정의할 수 있음

clusters 항목에는 kubernetes라는 이름의 클러스터가, users 항목에는 kubernetes-admin이라는 사용자가 정의돼 있습니다. 그리고 contexts 항목에서는 kubernetes 클러스터와 kubernetes-admin 사용자를 조합해 kubernetes-admin@kubernetes라는 이름의 컨텍스트를 만들어 냈습니다. 여러 개의 클러스터 접속 정보와 사용자의 인증 정보를 clusters와 users 항목에 각각 정의한 다음, 이를 개별적으로 조합해 컨텍스트라는 개념으로 사용합니다.

이런 원리를 이용하면 로컬 개발 환경의 쿠버네티스 컨텍스트, AWS 운영 환경의 쿠버네티스 컨텍스트 등 여러 개의 쿠버네티스 클러스터를 유동적으로 선택해 kubectl 명령어를 사용하는 것도 가능합니다. 현재 어떤 컨텍스트를 사용하고 있는지는 kubeconfig 파일의 current-context 항목에서 확인 할 수 있습니다.

users 항목에 서비스 어카운트의 token 데이터를 새롭게 등록함으로써 해당 서비스 어카운트로 클러스터에 접근 및 인증하는 실습을 해봅시다. 다음 명령어로 이전에 생성해 뒀던 서비스 어카운트에 연결된 시크릿으로부터 token 데이터를 가져옵니다.

$ kubectl get secrets # ihp001-token-zq2rw 토큰 존재
$ export secret_name=ihp001-token-zq2rw
$ export decoded_token=$(kubectl get secrets $secret_name -o jsonpath='{.data.token}' | base64 -d)

kubectl config 명령어를 사용하면 좀 더 쉽게 kubeconfig 파일을 수정할 수 있습니다.

# ihp001 사용자 추가
$ kubectl config set-credentials ihp001 --token=$decoded_token
$ cat ~/.kube/config

다음 현재 kubeconfig 파일의 clusters 항목에 등록된 클러스터의 목록을 확인한 다음, 클러스터의 이름과 ihp001 사용자를 조합해 새로운 컨텍스트를 생성합니다. kubernetes 클러스터의 API 서버 접근 정보와 ihp001 사용자의 인증 정보를 이용해 my-new-context라는 이름의 컨텍스트를 새롭게 생성합니다.

$ kubectl config get-clusters
$ kubectl config set-context my-new-context --cluster=kubernetes --user=ihp001
$ cat ~/.kube/config

새롭게 등록된 컨텍스트를 확인한 다음 kubectl이 사용할 컨텍스트를 해당 컨텍스트로 변경해 봅시다.

$ kubectl config get-contexts
$ kubectl config use-context my-new-context

이전에 ihp001 서비스 어카운트에 서비스의 목록만을 읽을 수 있도록 롤을 부여해서 kubectl get svc를 제외한 다른 명령어는 모두 실패합니다.

# 다시 이전에 사용하던 컨텍스트로 변경하자. 
$ kubectl config use-context kubernetes-admin@kubernetes

유저(User)와 그룹(Group)의 개념

YAML 파일의 Kind 속성 값에 ServiceAccount 대신 User나 Group을 사용할 수 있습니다.

...
subjects:
- kind: User
  name: ihp001
...

...
subjects: 
- kind: Group
  name: devops-team
...

user, group은 kubectl get 명령어를 사용할 수 없습니다.

$ kubectl get svc --as system:serviceaccount:default:ihp001

위에서 'system:serviceaccount:default:ihp001'는 서비스 어카운트를 지칭하는 고유한 유저 이름입니다. 즉, 서비스 어카운트를 생성하면 system:serviceaccount:<네임스페이스>:<서비스 어카운트>이라는 유저 이름으로 서비스 어카운트를 지칭할 수 있습니다. 따라서 롤 바인딩을 생성할 때 아래와 같이 YAML 파일을 작성해 생성해도 서비스 어카운트에 롤이 정상적으로 부여됩니다.

subjects: 
- kind: User
  name: system:serviceaccount:default:ihp001
  namespace: default
roleRef: 
kind: Role

그룹은 이러한 유저를 모아 놓은 집합입니다. 쿠버네티스에서 사용할 수 있는 대표적인 그룹은 서비스 어카운트의 집합인 system:serviceaccounts로 시작하는 그룹입니다. 이 그룹은 모든 네임스페이스에 속하는 모든 서비스 어카운트가 속해 있는 그룹입니다. 따라서 네임스페이스에 상관없이 모든 서비스 어카운트에 권한을 부여하려면 롤 바인딩의 YAML 파일에서 kind에 Group을 명시하고 위 그룹을 명시합니다.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata: 
  name: service-reader-rolebinding
subjects: 
- kind: Group
  name: system:serviceaccounts
roleRef: 
  kind: ClusterRole
  name: service-reader
  apiGroup: rbac.authorization.k8s.io

다른 그룹의 이름으로는 네임스페이스를 붙여 system:serviceaccounts:<네임스페이스 이름> 특정 네임스페이스의 모든 서비스 어카운트를 카르킬 수 있습니다. 이 외에도 API 서버의 인증에 성공한 그룹을 의미하는 system:authenticated, 인증에 실패한 그룹을 의미하는 system: unauthenticated 및 인증에 실패한 유저를 의미하는 system:anonymouns 등이 있습니다.

다양한 인증 방법에서의 USer와 Group

kubeconfig 파일에 기본적으로 설정돼 있던 인증 방법은 쿠버네티스에서 자체적으로 지원하는 인증 방법인 x509 인증서이고, 그 뿐만 아니라 별도의 인증 서버를 사용하면 깃허브 계정, 구글 계정, LDAP 데이터 등을 쿠버네티스 사용자 인증에 사용할 수도 있습니다.

x509 인증서를 이용한 사용자 인증

쿠버네티스는 보안 연결을 위해 자체적으로 사인한 루트 인증서를 사용합니다. 이 루트 인증서는 쿠버네티스를 설피할 때 자동으로 생성되며, kubeadm의 경우 기본적으로 쿠버네티스 마스터의 /etc/kubernetes/pki 디렉터리에 저장돼 있습니다.

ca.crt가 루트 인증서에 해당하며, ca.key는 이 인증서에 대응한느 비밀키입니다. 그 외의 apiserver.crt와 같은 인증서 파일들은 이 루트 인증서로부터 발급된 하위 인증서입니다. 이러한 하위 인증서들은 쿠버네티스 핵심 컴포넌트들이 서로 보안 연결을 수립하는 데 사용합니다.

쿠버네티스의 루트 인증서로부터 발급된 하위 인증서를 사용하면 쿠버네티스 사용자를 인증할 수 있습니다. 쿠버네티스를 설치하면 기본적으로 설정되는 kubeconfig 파일에 저장돼 있던 인증 정보 또한 x509 인증서를 이요한 인증 방법입니다.

kubeconfig에 설정돼 있던 기본 인증서가 아닌, 루트 인증서로부터 하위 인증서를 직접 생성해 API 서버에 인증해 볼 수도 있습니다.

# 밑에 쭉 같은 경로에서 진행
$ openssl genrsa -out ihp001.key 2048
$ openssl req -new -key ihp001.key \ 
-out ihp001.csr -subj "/O=ihp001-org/CN=ihp001-cert"

하위 인증서를 사용자 인증에 사용할 때는 인증서의 CN(Common Name)이 유저(User)로, O(Organization)가 그룹(Group)으로 취급됩니다. 따라서 위처럼 인증서를 생성하면 롤 바인딩 등에서 ihp001-cert라는 이름의 유저에게 권한을 부여해야 합니다.

kubeconfig 파일에 기본적으로 설정된 인증서는 Org가 system:masters로 설정돼 있습니다. 쿠버네티스를 설치하면 system:masters 그룹에 cluster-admin 클러스터 롤이 부여되기 때문에 문제가 없었습니다. system:masters 그룹에 cluster-admin 권한을 부여하는 클러스터 바인딩 롤은 cluster-admin에 설정돼 있습니다.

$ kubectl describe clusterrolebinding cluster-admin

이젠 쿠버네티스의 비밀키로 ihp001.csr 파일에 서명을 해야되는데 이를 위해서 openssl 명령어를 직접 사용해도 되지만 그럴려면 쿠버네티스의 비밀키에 직접 접근해야 되서 보안에 취약할 수 있습니다. 이러한 경우를 위해 쿠버네티스는 인증서 사인 요청(.csr) 파일에 간접적으로 서명하는 기능을 API로 제공합니다.

# ihp001-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: ihp001-csr
spec:
  groups:
  - system:authenticated
  request: <CSR>
  signerName: kubernetes.io/kube-apiserver-client
  usages:
  - digital signature
  - key encipherment
  - client auth

CertificateSigningRequest라는 처음보는 오브젝트를 정의했습니다. 이 오브젝트의 spec.request 항목에 .csr 파일의 내용을 base64로 인코딩해 넣은 뒤 CertificateSigningRequest 리소스를 생성하면 쿠버네티스에서 내부적으로 루트 인증서의 비밀키로 서명해 반환합니다. 즉, 간접적으로 루트 인증서의 비밀키를 사용할 수 있습니다.

$ export CSR=$(cat ihp001.csr | base64 | tr -d '\n')
$ sed -i -e "s/<CSR>/$CSR/g" ihp001-csr.yaml
$ kubectl apply -f ihp001-csr.yaml
$ kubectl get csr 

CONDITION 항목이 Pending인 것을 확인 할 수 있습니다. 지금은 사용자 입장에서 CertificateSigningRequest를 생성함으로써 서명 요청을 제출했으니, 다은 단계는 관리자 입장에서 해당 서명 요청을 승인해야 합니다.

$ kubectl certificate approve ihp001-csr
$ kubectl get csr

인증서 서명 요청의 상태가 Approved, Issued로 변경되었습니다. 이젠 리소스로부터 하위 인증서를 추출합니다.

$ kubectl get csr ihp001-csr -o jsonpath='{.status.certificate}' | base64 -d > ihp001.crt

이젠 인증서 파일과 비밀키로 kubeconfig에 새로운 사용자를 등록하고, 사용자를 기반으로 컨텍스트를 만듭니다.

$ kubectl config set-credentials ihp001-x509-user \
  --client-certificate=ihp001.crt --client-key=ihp001.key
$ kubectl config get-clusters
$ kubectl config set-context ihp001-x509-context \
  --cluster kubernetes --user ihp001-x509-user
$ kubectl config use-context ihp001-x509-context
$ kubectl get svc

컨텍스트를 변경한 다음 kubectl로 API를 요청해보면 권한이 없다는 에러가 출력될 것 입니다. 그룹이 ihp001-org, 유저가 ihp001-cert로 설정되어 있어서 이 그룹이나 유저에 롤 및 클러스터 롤을 할당해야 합니다.

# x509-cert-rolebinding-user.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: service-reader-rolebinding-user
  namespace: default
subjects:
- kind: User
  name: ihp001-cert
roleRef:
  kind: Role
  name: service-reader # 위에서 만든 롤
  apiGroup: rbac.authorization.k8s.io

롤 바인딩을 생성해서 하위 인증서에 권한을 부여해보겠습니다. 지금의 컨텍스트는 아무런 권한이 없기 때문에 --context 옵션으로 마스터 컨텍스트를 임시로 사용할 수 있습니다.

$ kubectl config get-contexts
$ kubectl apply -f x509-cert-rolebinding-user.yaml --context kubernetes-admin@kubernetes
$ kubectl get svc

ihp001-cert라는 유저를 위한 롤 바인딩을 생성했기 때문에 서비스 목록을 정상적으로 출력할 수 있습니다.

출처
시작하세요! 도커/쿠버네티스(용찬호 저, 위키북스)