Kubernetes API: 서비스 계정을 사용자 정의하는 방법

지난 글에서, 나는 Kubeloge Exporter를 어떻게 개발하는지 보여 주었다. 이것은 POD에서 로그 데이터를 수집하는 도구이다.지금까지 내보내기는 로컬 .kubeconfig 파일을 사용하여 그룹에 대한 완전한 접근에 의존했다.그룹 내cron 작업으로 내보내기를 원한다면, 적절한 접근 권한이 필요합니다.처음에 나는cron 작업의 실현에 관한 글을 쓰고 싶었지만 Kubernetes 접근 권한을 연구하는 작업 방식이 매우 교육적인 의미를 가진다는 것을 발견했다.이것이 바로 왜 그것이 네가 지금 읽고 있는 문장이 되었는가 하는 것이다.
본문은 최초로 발표되었다my blog.

쿠베르네트스 기본 개념

Kubernetes 클러스터에서 Pod을 실행할 때 기본적으로 기본 설정과 보안 설정이 설정되어 있습니다.풍부한 Kubernetes API에 대한 접근권을 확인하기 위해 기본 자원은 ServiceAccount, Role와 RoleBindings를 포함한다.
cron이pod 로그를 읽는 작업 원리를 고려함으로써 이러한 개념을 이해할 수 있습니다.작업이 실행될 때, 이름 공간과pod에 대한 읽기 접근이 필요합니다.액세스는 Role 또는 ClusterRole에 정의됩니다.Role는 하나의 명칭 공간에만 한정되어 있기 때문에 우리는 ClusterRole을 사용할 것이다.pod를 만들면 K8S API에 액세스할 수 있는 기본 시스템 계정 및 기본 시스템 계정 토큰이 제공됩니다.그러나 이 계정은 필요한 접근 권한이 없기 때문에 사용자 정의 ServiceAccount 를 정의해야 합니다.마지막 블록은 RoleBinding 또는 ClusterRoleBinding: 연결ClusterRole과 ServiceAccount입니다.

K8S API: 직접 액세스

Kubernetes를 사용할 때 이러한 개념이 어떻게 응용되는지 알아보기 위해 저는 아래excellent article를 따랐습니다. 그 중에서 API는 curl를 통해 직접 방문했습니다.
창설api-explorerpod부터 다음 내용으로 파일을 작성api-explorer-pod.yaml하겠습니다.

apiVersion: v1
kind: Pod
metadata:
  name: api-explorer
spec:
  containers:
    - name: alpine
      image: alpine
      args: ['sleep', '3600']

그리고 용기를 만들고 시작하기를 기다립니다.

> kubectl create -f api-explorer-pod.yaml

pod/api-explorer created

그리고 우리는 용기에 뛰어들어 curl 가방을 설치했다.

> kubectl api-explorer -it sh
> apk add curl

Kubernetes API에 액세스하려면 항상 유효한 보안 토큰을 보내야 합니다.이 영패는pod내 위치/run/secrets/kubernetes.io/serviceaccount/token에 저장됩니다.이 영패가 있으면 우리는 API 요청을 보낼 수 있다.

> TOKEN=$(cat /run/secrets/kubernetes.io/serviceaccount/token)
> curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/namespaces/default/pods/ --insecure
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "pods is forbidden: User \"system:serviceaccount:default:default\" cannot list resource \"pods\" in API group \"\" in the namespace \"default\"",
  "reason": "Forbidden",
  "details": {
    "kind": "pods"
  },
  "code": 403
}

그러나 보시다시피 기본 서비스 계정에 정확한 접근 권한이 없기 때문에pod에 접근할 수 없습니다.

사용자 지정 서비스 계정 정의

따라서, Kubernetes API에 접근할 수 있도록 정확한 설정 ServiceAccount 이 필요합니다.
파일pod-read-access-service-account.yaml을 생성하고 정의ServiceAccount를 맨 위에 놓습니다.이 자원은 기본적으로 메타데이터일 뿐이다.

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: log-exporter-sa
  namespace: default
  labels:
    app: log-exporter
---

다음은 ClusterRole의 정의다.spec 블록에서 방문할 apiGroups와 resources를 정의합니다.핵심 API 그룹은 ""로 표시됩니다resources.마지막으로, 함수 pods 는 우리가 자원에 응용하고자 하는 동작을 확정했다. 우리의 예에서, 함수의 읽기와 목록이다.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: log-exporter-cr
  labels:
    app: log-exporter
rules:
  - apiGroups:
      - ''
    resources:
      - pods
      - pods/log
      - namespaces
    verbs:
      - get
      - list
---

마지막으로 우리는 verbs 자원을 만들어서 RoleBinding와 SeviceAccount를 조합한다.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: log-exporter-rb
roleRef:
  kind: ClusterRole
  name: log-exporter-cr
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount
    name: log-exporter-sa
    namespace: default
---

이제 우리는 모든 자원을 창조한다.

> kubectl create -f pod-read-access-service-account.yaml

serviceaccount/log-exporter-sa created
clusterrole.rbac.authorization.k8s.io/log-exporter-cr created
rolebinding.rbac.authorization.k8s.io/log-exporter-rb created

더 자세한 정보: 보시다시피 ClusterRole는 ServiceAccount 명칭 공간에서 현식으로 만들어졌습니다.주의 default 는 정의된 명칭 공간에서 인용해야 하기 때문에 ClusterRoleBinding 그렇지 않으면 정상적으로 작동할 수 없습니다.

K8S API: 사용자 지정 서비스 계정으로 액세스

새로 만든ServiceAccount을 사용하기 위해pod에서 새로운 캐릭터를 사용하도록 정의했습니다.ServiceAccount 파일로 돌아가서 새 설정 항목api-explorer-pod.yaml을 추가했습니다.

apiVersion: v1
kind: Pod
metadata:
  name: api-explorer
spec:
  serviceAccountName: log-exporter-sa
  containers:
    - name: alpine
      image: alpine
      args: ['sleep', '3600']

용기로 돌아가서, 우리는 영패를 잡고 요청을 했다. 그것은 성공했다.

curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/namespaces/default/pods/ --insecure
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "selfLink": "/api/v1/namespaces/default/pods/",
    "resourceVersion": "320995"
  },
  "items": [
    {
      "metadata": {
        "name": "api-explorer2",
        "namespace": "default",
        "selfLink": "/api/v1/namespaces/default/pods/api-explorer2",
        "uid": "343aaf7e-1be5-45da-aadb-e83ee329a7fd",
        "resourceVersion": "320976",
        "creationTimestamp": "2020-05-24T10:16:58Z"
      },
  ...

이제 개념의 최종 증명으로 서로 다른 이름 공간에서pod에서 로그를 읽어봅시다.우리는 spec.serviceAccountName명칭 공간에서 corednspod를 얻었다.

kb get pods -n kube-system

NAME                                      READY   STATUS    RESTARTS   AGE
metrics-server-6d684c7b5-6ww29            1/1     Running   7          8d
coredns-d798c9dd-pdswq                    1/1     Running   7          8d

이pod에 접근하는 URL은 다음과 같은 내용으로 구성됩니다: kube-system.따라서 이 요청이 효력을 발생하려면 정확한 명칭 공간과 정확한pod명칭이 필요합니다./api/v1/namespaces/{namespace}/pods/{name}/log 크레인으로 돌아가서 로그 파일을 보십시오.

> curl -H "Authorization: Bearer $TOKEN" https://kubernetes/api/v1/namespaces/kube-system/pods/coredns-d798c9dd-pdswq/log --insecure

[INFO] plugin/reload: Running configuration MD5 = 4665410bf21c8b272fcfd562c482cb82
   ______                ____  _   _______
  / ____/___  ________  / __ \/ | / / ___/ ~ CoreDNS-1.6.3
 / /   / __ \/ ___/ _ \/ / / /  |/ /\__ \  ~ linux/arm, go1.12.9, 37b9550
/ /___/ /_/ / /  /  __/ /_/ / /|  /___/ /
\____/\____/_/   \___/_____/_/ |_//____/

우리는 그것이 예상대로 운행하는 것을 보고 매우 기뻤다.

결론

본 논문에서, 우리는 모든 이름 공간에서 POD와 로그 파일에 접근하는 데 필요한 Kubernetes 자원을 이해했다.Aapi-explorer는 어떤 자원과 그 자원에 대해 어떤 행동을 취해야 하는지를 정의했다.이러한 접근 권한은 aClusterRole에서 aClusterRoleBinding까지의 제약을 받는다.그리고 우리는 이것ServiceAccount을 사용하여 ServiceAccount에 대한 접근 권한을 제공합니다.우리는 Pod 명령을 사용하여pod에서Kubernetes API에 접근하는 방법을 보여 주었다.다음 글은 이 서비스 계정을 사용하여 로그 파일을 내보내는cron 작업을 어떻게 하는지 보여 줍니다.