From cfb55db9cfeb2cd04f0fd7f394865323fe590560 Mon Sep 17 00:00:00 2001 From: bconfiden2 Date: Wed, 22 Feb 2023 14:47:57 +0900 Subject: [PATCH] [ko] Update outdated files in dev-1.26-ko.1 (M109-M110) --- .../service-accounts-admin.md | 422 ++++++++++++++---- .../command-line-tools-reference/_index.md | 2 +- .../secret/serviceaccount/mysecretname.yaml | 7 + 3 files changed, 338 insertions(+), 93 deletions(-) create mode 100644 content/ko/examples/secret/serviceaccount/mysecretname.yaml diff --git a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md index 85df22f037..d6cd18c4bc 100644 --- a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md +++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md @@ -11,110 +11,147 @@ weight: 50 -이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다. -독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다. +_서비스어카운트(ServiceAccount)_ 는 파드에서 실행되는 프로세스에 대한 식별자를 제공한다. -인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다. -서비스 어카운트를 더 잘 설명하기 위해, 때때로 미완성 기능이 언급될 수 있다. +파드 내부의 프로세스는, 자신에게 부여된 서비스 어카운트의 식별자를 사용하여 +클러스터의 API 서버에 인증할 수 있다. + +서비스 어카운트에 대한 소개는, [서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)를 참고한다. + +이 가이드는 서비스어카운트와 관련된 개념 중 일부를 설명하며, +서비스어카운트를 나타내는 토큰을 얻거나 취소하는 +방법에 대해서도 설명한다. +## {{% heading "prerequisites" %}} + +{{< include "task-tutorial-prereqs.md" >}} + +아래 내용들을 따라하기 위해서는 +`examplens`라는 네임스페이스가 필요하다. +없을 경우 다음과 같이 네임스페이스를 생성한다. + +```shell +kubectl create namespace examplens +``` + ## 사용자 어카운트와 서비스 어카운트 비교 쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을 구분한다. -- 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를 - 위한 것이다. -- 사용자 어카운트는 전역을 대상으로 고려된다. - 클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 서비스 어카운트는 네임스페이스에 할당된다. +- 사용자 어카운트는 사람을 위한 것이지만, 서비스 어카운트는 쿠버네티스의 경우 파드의 일부 컨테이너에서 실행되는 + 애플리케이션 프로세스를 위한 것이다. +- 사용자 어카운트는 전역적으로 고려되기 때문에, + 클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 어떤 네임스페이스를 확인하든지 간에, + 특정 사용자명은 해당 유저만을 나타낸다. + 쿠버네티스에서 서비스 어카운트는 네임스페이스별로 구분된다. 두 개의 서로 다른 네임스페이스는 + 동일한 이름의 서비스어카운트를 각자 가질 수 있다. - 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며, 여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다. - 서비스 어카운트 생성은 + 반면에 서비스 어카운트를 생성하는 경우는, 클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록 보다 가볍게 만들어졌다. -- 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다. + 실 사용자를 온보딩하는 단계와 서비스어카운트를 생성하는 단계를 분리하는 것은, + 워크로드가 최소 권한 원칙을 따르기 쉬워지게 한다. +- 사람과 서비스 어카운트에 대한 감사 고려 사항은 다를 수 있다. 이 둘을 따로 관리함으로써 + 더욱 쉽게 감사를 수행할 수 있다. - 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다. - 서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에 + 서비스 어카운트는 많은 제약없이 만들 수 있고 + 네임스페이스에 할당된 이름을 가질 수 있기 때문에 이러한 설정은 이식성이 좋다. -## 서비스 어카운트 자동화 - -서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다. - -- `ServiceAccount` 어드미션 컨트롤러 -- 토큰 컨트롤러 -- `ServiceAccount` 컨트롤러 - -### 서비스어카운트(ServiceAccount) 어드미션 컨트롤러 - -파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)라는 -플러그인을 통해 구현된다. -이것은 API 서버의 일부이다. -파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다. -이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다. - -1. 파드에 `ServiceAccount` 가 없다면, `ServiceAccount` 를 `default` 로 설정한다. -1. 이전 단계는 파드에 참조되는 `ServiceAccount` 가 있도록 하고, 그렇지 않으면 이를 거부한다. -1. 서비스어카운트 `automountServiceAccountToken` 와 파드의 `automountServiceAccountToken` 중 - 어느 것도 `false` 로 설정되어 있지 않다면, - API 접근을 위한 토큰이 포함된 `volume` 을 파드에 추가한다. -1. 이전 단계에서 서비스어카운트 토큰을 위한 볼륨이 만들어졌다면, - `/var/run/secrets/kubernetes.io/serviceaccount` 에 마운트된 파드의 각 컨테이너에 - `volumeSource` 를 추가한다. -1. 파드에 `imagePullSecrets` 이 없는 경우, - `ServiceAccount` 의 `imagePullSecrets` 이 파드에 추가된다. - -#### 바인딩된 서비스 어카운트 토큰 볼륨 +## 바인딩된 서비스 어카운트 토큰 볼륨 메커니즘 {#bound-service-account-token-volume} {{< feature-state for_k8s_version="v1.22" state="stable" >}} -서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 -시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다. +기본적으로, +쿠버네티스 컨트롤 플레인(구체적으로 말하자면 [서비스어카운트 어드미션 컨트롤러](#service-account-admission-controller))은 +[프로젝티드 볼륨](/ko/docs/concepts/storage/projected-volumes/)을 파드에 추가하며, +이 볼륨은 쿠버네티스 API에 접근할 수 있는 토큰을 포함한다. + +다음은 실행된 파드에서 해당 토큰이 어떻게 보이는지에 대한 예시이다. ```yaml -- name: kube-api-access- - projected: - defaultMode: 420 # 0644 - sources: - - serviceAccountToken: - expirationSeconds: 3607 - path: token - - configMap: - items: - - key: ca.crt - path: ca.crt - name: kube-root-ca.crt - - downwardAPI: - items: - - fieldRef: - apiVersion: v1 - fieldPath: metadata.namespace - path: namespace +... + - name: kube-api-access- + projected: + sources: + - serviceAccountToken: + path: token # 애플리케이션이 알고 있는 경로와 일치해야 한다. + - configMap: + items: + - key: ca.crt + path: ca.crt + name: kube-root-ca.crt + - downwardAPI: + items: + - fieldRef: + apiVersion: v1 + fieldPath: metadata.namespace + path: namespace ``` -프로젝티드 볼륨은 세 가지로 구성된다. +위의 매니페스트는 세 가지 정보로 구성된 프로젝티드 볼륨을 정의한다. +이 경우, 각 정보는 해당 볼륨 내의 단일 경로를 나타내기도 한다. 세 가지 정보는 다음과 같다. -1. `kube-apiserver`로부터 TokenRequest API를 통해 얻은 `서비스어카운트토큰(ServiceAccountToken)`. - 서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다. - 서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다. -1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 `컨피그맵(ConfigMap)`. -1. 파드의 네임스페이스를 참조하는 `DownwardAPI`. +1. `서비스어카운트토큰(serviceAccountToken)` 정보는 kubelet이 kube-apiserver로부터 취득한 토큰을 포함한다. + kubelet은 TokenRequest API를 통해 일정 시간 동안 사용할 수 있는 토큰을 발급 받는다. + 이렇게 취득한 토큰은 파드가 삭제되거나 지정된 수명 주기 이후에 만료된다(기본값은 1시간이다). + 이 토큰은 특정한 파드에 바인딩되며 kube-apiserver를 그 대상으로 한다. + 이 메커니즘은 시크릿을 기반으로 볼륨을 추가하던 이전 메커니즘을 대체한 것이다. + 해당 시크릿은 파드의 서비스어카운트를 나타냈었는데, 이는 토큰과는 달리 만료가 되지 않는 것이었다. +1. `컨피그맵(ConfigMap)` 정보는 인증 및 인가에 관한 번들을 포함한다. + 파드들은 이러한 인증서를 사용하여 해당 클러스터의 kube-apiserver(미들박스나 실수로 잘못 구성된 피어가 아닌) + 에 대한 연결을 확인할 수 있다. +1. `DownwardAPI` 정보는 파드가 포함된 네임스페이스를 검색하고, + 해당 정보를 파드 내부에서 실행 중인 애플리케이션에서 사용할 수 있도록 한다. -상세 사항은 [프로젝티드 볼륨](/ko/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다. +이러한 볼륨을 마운트한 컨테이너는 위의 정보들에 접근할 수 있다. + +{{< note >}} +TokenRequest를 통해 발급된 토큰을 무효화하는 메커니즘은 없다. +만약 파드에 바인딩된 서비스 어카운트 토큰을 더 이상 신뢰하지 못하게 된다면, 파드를 삭제한다. +파드를 삭제하면 바인딩 되어있던 서비스 어카운트 토큰 역시 만료된다. +{{< /note >}} + +## 서비스어카운트에 대해 수동으로 시크릿 관리하기 + +쿠버네티스 v1.22 이전의 버전들은 쿠버네티스 API에 접근하기 위한 자격 증명들을 자동으로 생성했다. +이러한 옛 메커니즘들은, 실행 중인 파드에 마운트 될 수 있는 +토큰 시크릿을 만드는 것에 기반을 두었다. + +쿠버네티스 v{{< skew currentVersion >}}을 포함한 최신 버전에서는, +API 자격 증명들은 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) API를 사용하여 +[직접 얻을 수 있으며](#bound-service-account-token-volume), +프로젝티드 볼륨을 사용하여 파드에 마운트할 수 있다. +이 방법으로 취득한 토큰은 시간 제한이 있으며, +마운트 되었던 파드가 삭제되는 경우 자동으로 만료된다. + +예를 들어 평생 만료되지 않는 토큰이 필요한 경우, 서비스 어카운트 토큰을 유지하기 위한 시크릿을 [수동으로 생성](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount)할 수 있다. + +한 번 시크릿을 수동으로 생성하여 서비스어카운트에 연결했다면, 쿠버네티스 컨트롤 플레인은 자동으로 해당 시크릿에 토큰을 채운다. + +{{< note >}} +장기간 사용할 서비스어카운트 토큰을 수동으로 생성하는 메커니즘이 존재하지만, +단기간 동안에만 사용할 토큰을 취득하는 경우 +[TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)를 사용하는 것이 권장된다. +{{< /note >}} + +## 컨트롤 플레인의 세부 사항들 ### 토큰 컨트롤러 -토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는, +토큰 컨트롤러는 `kube-controller-manager` 의 일부로써 실행되며, +비동기적으로 동작한다. -- 서비스어카운트 생성을 감시하고 API에 접근할 수 있는 해당 - 서비스어카운트 토큰 시크릿을 생성한다. -- 서비스어카운트 삭제를 감시하고 해당하는 모든 서비스어카운트 - 토큰 시크릿을 삭제한다. -- 서비스어카운트 토큰 시크릿 추가를 감시하고, 참조된 서비스어카운트가 - 존재하는지 확인하고, 필요한 경우 시크릿에 토큰을 추가한다. -- 시크릿 삭제를 감시하고 필요한 경우 해당 서비스어카운트에서 - 참조를 제거한다. +- 서비스어카운트에 대한 삭제를 감시하고, 해당하는 모든 서비스어카운트 + 토큰 시크릿을 같이 삭제한다. +- 서비스어카운트 토큰 시크릿에 대한 추가를 감시하고, 참조된 서비스어카운트가 + 존재하는지 확인하며, 필요한 경우 시크릿에 토큰을 추가한다. +- 시크릿에 대한 삭제를 감시하고, 필요한 경우 해당 서비스어카운트에서 + 참조 중인 항목들을 제거한다. 서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야 @@ -123,39 +160,240 @@ weight: 50 `kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다. -#### 추가적인 API 토큰 생성 +### 서비스어카운트 어드미션 컨트롤러 -컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다. -서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해 -서비스어카운트를 참조하는 어노테이션과 함께 -`kubernetes.io/service-account-token` 유형의 시크릿을 생성하면 -컨트롤러가 새로 생성된 토큰으로 갱신한다. +파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)라는 +플러그인을 통해 구현된다. +이것은 API 서버의 일부이며, +파드가 생성될 때 파드를 수정하기 위해 동기적으로 동작한다. +이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우, +어드미션 컨트롤러는 파드의 생성 시점에 다음 작업들을 수행한다. -다음은 시크릿에 대한 샘플 구성이다. +1. 파드에 `.spce.serviceAccountName` 항목이 지정되지 않았다면, 어드미션 컨트롤러는 + 실행하려는 파드의 서비스어카운트 이름을 `default`로 설정한다. +1. 어드미션 컨트롤러는 실행되는 파드가 참조하는 서비스어카운트가 존재하는지 확인한다. + 만약 해당하는 이름의 서비스어카운트가 존재하지 않는 경우, 어드미션 컨트롤러는 파드를 실행시키지 않는다. + 이는 `default` 서비스어카운트에 대해서도 동일하게 적용된다. +1. 서비스어카운트의 `automountServiceAccountToken` 또는 파드의 `automountServiceAccountToken` 중 + 어느 것도 `false` 로 설정되어 있지 않다면, + - 어드미션 컨트롤러는 실행하려는 파드에 + API에 접근할 수 있는 토큰을 포함하는 + {{< glossary_tooltip text="볼륨" term_id="volume" >}} 을 추가한다. + - 어드미션 컨트롤러는 파드의 각 컨테이너에 `volumeMount`를 추가한다. + 이미 `/var/run/secrets/kubernetes.io/serviceaccount` 경로에 볼륨이 마운트 되어있는 + 컨테이너에 대해서는 추가하지 않는다. + 리눅스 컨테이너의 경우, 해당 볼륨은 `/var/run/secrets/kubernetes.io/serviceaccount` 위치에 마운트되며, + 윈도우 노드 역시 동일한 경로에 마운트된다. +1. 파드의 spec에 `imagePullSecrets` 이 없는 경우, + 어드미션 컨트롤러는 `ServiceAccount`의 `imagePullSecrets`을 복사하여 추가된다. + +### TokenRequest API + +{{< feature-state for_k8s_version="v1.22" state="stable" >}} + +서비스어카운트의 하위 리소스인 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)를 사용하여 +일정 시간 동안 해당 서비스어카운트에서 사용할 수 있는 토큰을 가져올 수 있다. +컨테이너 내에서 사용하기 위한 API 토큰을 얻기 위해 이 요청을 직접 호출할 필요는 없는데, +kubelet이 _프로젝티드 볼륨_ 을 사용하여 이를 설정하기 때문이다. + +`kubectl`에서 TokenRequest API를 사용하고 싶다면, +[서비스어카운트를 위한 API 토큰을 수동으로 생성하기](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount)를 확인한다. + +쿠버네티스 컨트롤 플레인(구체적으로는 서비스어카운트 어드미션 컨트롤러)은 +파드에 프로젝티드 볼륨을 추가하고, kubelet은 컨테이너가 올바른 서비스어카운트로 인증할 수 있도록 +해당 볼륨이 토큰을 포함하는고 있는지 확인한다. + +(이 메커니즘은 시크릿을 기반으로 볼륨을 추가하던 이전 메커니즘을 대체한 것이다. +해당 시크릿은 파드의 서비스어카운트를 나타냈었는데, 이는 만료가 되지 않는 것이었다.) + +아래는 실행 중인 파드에서 어떻게 보이는지에 대한 예시이다. + +```yaml +... + - name: kube-api-access- + projected: + defaultMode: 420 # 8진수 0644에 대한 10진수 값 + sources: + - serviceAccountToken: + expirationSeconds: 3607 + path: token + - configMap: + items: + - key: ca.crt + path: ca.crt + name: kube-root-ca.crt + - downwardAPI: + items: + - fieldRef: + apiVersion: v1 + fieldPath: metadata.namespace + path: namespace +``` + +위의 매니페스트는 세 가지 정보로 구성된 프로젝티드 볼륨을 정의한다. + +1. `서비스어카운트토큰(serviceAccountToken)` 정보는 kubelet이 kube-apiserver로부터 취득한 토큰을 포함한다. + kubelet은 TokenRequest API를 통해 일정 시간 동안 사용할 수 있는 토큰을 발급 받는다. + 이렇게 취득한 토큰은 파드가 삭제되거나 지정된 수명 주기 이후에 만료된다(기본값은 1시간이다). + 이 토큰은 특정한 파드에 바인딩되며 kube-apiserver를 그 대상으로 한다. +1. `컨피그맵(ConfigMap)` 정보는 인증 및 인가에 관한 번들을 포함한다. + 파드들은 이러한 인증서를 사용하여 해당 클러스터의 kube-apiserver(미들박스나 실수로 잘못 구성된 피어가 아닌) + 에 대한 연결을 확인할 수 있다. +1. `DownwardAPI` 정보는 파드가 포함된 네임스페이스를 검색하고, + 해당 정보를 파드 내부에서 실행 중인 애플리케이션에서 사용할 수 있도록 한다. + +이러한 볼륨을 마운트한 컨테이너는 위의 정보들에 접근할 수 있다. + +## 추가적인 API 토큰 생성하기 {#create-token} + +{{< caution >}} +[토큰 요청](#tokenrequest-api) 메커니즘이 적합하지 않은 경우에만 수명이 긴 API 토큰을 생성한다. +토큰 요청 메커니즘은 시간 제한이 있는 토큰만을 제공하며, +토큰이 만료되기 때문에 보안에 대한 위험이 적다. +{{< /caution >}} + +서비스어카운트를 위한 만료되지 않는 API 토큰을 생성하려면, +해당 서비스어카운트를 참조하는 어노테이션을 갖는 `kubernetes.io/service-account-token` 타입의 시크릿을 생성한다. +그러면 컨트롤 플레인은 장기적으로 사용 가능한 토큰을 발급하여 +시크릿을 갱신할 것이다. + +아래는 시크릿을 위한 예제 매니페스트이다. + +{{< codenew file="secret/serviceaccount/mysecretname.yaml" >}} + +이 예제에 기반한 시크릿을 생성하려면, 아래의 명령어를 실행한다. + +```shell +kubectl -n examplens create -f https://k8s.io/examples/secret/serviceaccount/mysecretname.yaml +``` + +시크릿에 대한 자세한 사항을 확인하려면, 아래의 명령어를 실행한다. + +```shell +kubectl -n examplens describe secret mysecretname +``` + +결과는 다음과 같다. + +``` +Name: mysecretname +Namespace: examplens +Labels: +Annotations: kubernetes.io/service-account.name=myserviceaccount + kubernetes.io/service-account.uid=8a85c4c4-8483-11e9-bc42-526af7764f64 + +Type: kubernetes.io/service-account-token + +Data +==== +ca.crt: 1362 bytes +namespace: 9 bytes +token: ... +``` + +만약 `examplens` 네임스페이스에 새로운 파드를 실행한다면, 해당 파드는 방금 생성한 `myserviceaccount` +서비스 어카운트 토큰 시크릿을 사용할 수 있다. + +## 서비스어카운트 토큰 시크릿 삭제/무효화 {#delete-token} + +만약 제거하려는 토큰을 포함하는 시크릿의 이름을 알고 있다면, 아래 명령어를 실행한다. + +```shell +kubectl delete secret name-of-secret +``` + +그게 아니라면, 먼저 시크릿을 확인한다. + +```shell +# 아래 명령어는 'examplens' 네임스페이스가 존재한다고 가정한다. +kubectl -n examplens get serviceaccount/example-automated-thing -o yaml +``` + +결과는 다음과 같다. ```yaml apiVersion: v1 -kind: Secret +kind: ServiceAccount metadata: - name: mysecretname annotations: - kubernetes.io/service-account.name: myserviceaccount -type: kubernetes.io/service-account-token + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}} + creationTimestamp: "2019-07-21T07:07:07Z" + name: example-automated-thing + namespace: examplens + resourceVersion: "777" + selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing + uid: f23fd170-66f2-4697-b049-e1e266b7f835 +secrets: + - name: example-automated-thing-token-zyxwv ``` +이제 시크릿의 이름을 알았으니, 삭제한다. + ```shell -kubectl create -f ./secret.yaml -kubectl describe secret mysecretname +kubectl -n examplens delete secret/example-automated-thing-token-zyxwv ``` -#### 서비스 어카운트 토큰 시크릿 삭제/무효화 +컨트롤 플레인은 서비스어카운트에 시크릿이 누락되었음을 감지하고, +새로운 것으로 대체한다. ```shell -kubectl delete secret mysecretname +kubectl -n examplens get serviceaccount/example-automated-thing -o yaml ``` +```yaml +apiVersion: v1 +kind: ServiceAccount +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"example-automated-thing","namespace":"examplens"}} + creationTimestamp: "2019-07-21T07:07:07Z" + name: example-automated-thing + namespace: examplens + resourceVersion: "1026" + selfLink: /api/v1/namespaces/examplens/serviceaccounts/example-automated-thing + uid: f23fd170-66f2-4697-b049-e1e266b7f835 +secrets: + - name: example-automated-thing-token-4rdrh +``` + +## 정리하기 + +예제를 위해 `examplens` 네임스페이스를 생성했었다면, 아래의 명령어로 제거할 수 있다. + +```shell +kubectl delete namespace examplens +``` + +## 컨트롤 플레인의 세부 사항들 + ### 서비스어카운트 컨트롤러 -서비스어카운트 컨트롤러는 네임스페이스에 있는 서비스어카운트를 관리하고 -"default"라는 이름의 서비스어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다. +서비스어카운트 컨트롤러는 네임스페이스 내의 서비스어카운트들을 관리하며, +활성화된 모든 네임스페이스에 "default"라는 이름의 서비스어카운트가 존재하도록 한다. +### 토큰 컨트롤러 + +토큰 컨트롤러는 `kube-controller-manager`의 일부로써 실행되며, +비동기적으로 동작한다. + +- 서비스어카운트에 대한 생성을 감시하고, 해당 서비스어카운트 토큰 시크릿을 생성하여 + API에 대한 접근을 허용한다. +- 서비스어카운트에 대한 삭제를 감시하고, 해당하는 모든 서비스어카운트 + 토큰 시크릿을 같이 삭제한다. +- 서비스어카운트 토큰 시크릿에 대한 추가를 감시하고, 참조된 서비스어카운트가 + 존재하는지 확인하며, 필요한 경우 시크릿에 토큰을 추가한다. +- 시크릿에 대한 삭제를 감시하고, 필요한 경우 해당 서비스어카운트에서 + 참조 중인 항목들을 제거한다. + +서비스 어카운트 개인키 파일은 `--service-account-private-key-file` +플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야 +한다. 개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다. +마찬가지로 `--service-account-key-file` 플래그를 사용하여 해당 공개키를 +`kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을 +검증하는 데 사용될 것이다. + +## {{% heading "whatsnext" %}} + +- 자세한 내용은 [프로젝티드 볼륨](/ko/docs/concepts/storage/projected-volumes/)을 확인한다. diff --git a/content/ko/docs/reference/command-line-tools-reference/_index.md b/content/ko/docs/reference/command-line-tools-reference/_index.md index d975db37b1..17c1b4a0ff 100644 --- a/content/ko/docs/reference/command-line-tools-reference/_index.md +++ b/content/ko/docs/reference/command-line-tools-reference/_index.md @@ -1,4 +1,4 @@ --- title: 컴포넌트 도구 -weight: 60 +weight: 120 --- diff --git a/content/ko/examples/secret/serviceaccount/mysecretname.yaml b/content/ko/examples/secret/serviceaccount/mysecretname.yaml new file mode 100644 index 0000000000..a0a6062eb9 --- /dev/null +++ b/content/ko/examples/secret/serviceaccount/mysecretname.yaml @@ -0,0 +1,7 @@ +apiVersion: v1 +kind: Secret +type: kubernetes.io/service-account-token +metadata: + name: mysecretname + annotations: + kubernetes.io/service-account.name: myserviceaccount