[ko] Update outdated files in dev-1.26-ko.1 (M109-M110)
bconfiden2
parent
60f9feccc3
commit
cfb55db9cf
|
|
@ -11,110 +11,147 @@ weight: 50
|
||||||
|
|
||||||
<!-- overview -->
|
<!-- overview -->
|
||||||
|
|
||||||
이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다.
|
_서비스어카운트(ServiceAccount)_ 는 파드에서 실행되는 프로세스에 대한 식별자를 제공한다.
|
||||||
독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다.
|
|
||||||
|
|
||||||
인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다.
|
파드 내부의 프로세스는, 자신에게 부여된 서비스 어카운트의 식별자를 사용하여
|
||||||
서비스 어카운트를 더 잘 설명하기 위해, 때때로 미완성 기능이 언급될 수 있다.
|
클러스터의 API 서버에 인증할 수 있다.
|
||||||
|
|
||||||
|
서비스 어카운트에 대한 소개는, [서비스 어카운트 구성하기](/docs/tasks/configure-pod-container/configure-service-account/)를 참고한다.
|
||||||
|
|
||||||
|
이 가이드는 서비스어카운트와 관련된 개념 중 일부를 설명하며,
|
||||||
|
서비스어카운트를 나타내는 토큰을 얻거나 취소하는
|
||||||
|
방법에 대해서도 설명한다.
|
||||||
|
|
||||||
<!-- body -->
|
<!-- body -->
|
||||||
|
|
||||||
|
## {{% heading "prerequisites" %}}
|
||||||
|
|
||||||
|
{{< include "task-tutorial-prereqs.md" >}}
|
||||||
|
|
||||||
|
아래 내용들을 따라하기 위해서는
|
||||||
|
`examplens`라는 네임스페이스가 필요하다.
|
||||||
|
없을 경우 다음과 같이 네임스페이스를 생성한다.
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl create namespace examplens
|
||||||
|
```
|
||||||
|
|
||||||
## 사용자 어카운트와 서비스 어카운트 비교
|
## 사용자 어카운트와 서비스 어카운트 비교
|
||||||
|
|
||||||
쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
|
쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
|
||||||
구분한다.
|
구분한다.
|
||||||
|
|
||||||
- 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
|
- 사용자 어카운트는 사람을 위한 것이지만, 서비스 어카운트는 쿠버네티스의 경우 파드의 일부 컨테이너에서 실행되는
|
||||||
위한 것이다.
|
애플리케이션 프로세스를 위한 것이다.
|
||||||
- 사용자 어카운트는 전역을 대상으로 고려된다.
|
- 사용자 어카운트는 전역적으로 고려되기 때문에,
|
||||||
클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 서비스 어카운트는 네임스페이스에 할당된다.
|
클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 한다. 어떤 네임스페이스를 확인하든지 간에,
|
||||||
|
특정 사용자명은 해당 유저만을 나타낸다.
|
||||||
|
쿠버네티스에서 서비스 어카운트는 네임스페이스별로 구분된다. 두 개의 서로 다른 네임스페이스는
|
||||||
|
동일한 이름의 서비스어카운트를 각자 가질 수 있다.
|
||||||
- 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
|
- 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
|
||||||
여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
|
여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
|
||||||
서비스 어카운트 생성은
|
반면에 서비스 어카운트를 생성하는 경우는,
|
||||||
클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록
|
클러스터 사용자가 최소 권한 원칙에 따라 특정 작업을 위한 서비스 어카운트를 만들 수 있도록
|
||||||
보다 가볍게 만들어졌다.
|
보다 가볍게 만들어졌다.
|
||||||
- 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
|
실 사용자를 온보딩하는 단계와 서비스어카운트를 생성하는 단계를 분리하는 것은,
|
||||||
|
워크로드가 최소 권한 원칙을 따르기 쉬워지게 한다.
|
||||||
|
- 사람과 서비스 어카운트에 대한 감사 고려 사항은 다를 수 있다. 이 둘을 따로 관리함으로써
|
||||||
|
더욱 쉽게 감사를 수행할 수 있다.
|
||||||
- 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
|
- 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
|
||||||
서비스 어카운트는 많은 제약없이 만들 수 있고 네임스페이스에 할당된 이름을 가질 수 있기 때문에
|
서비스 어카운트는 많은 제약없이 만들 수 있고
|
||||||
|
네임스페이스에 할당된 이름을 가질 수 있기 때문에
|
||||||
이러한 설정은 이식성이 좋다.
|
이러한 설정은 이식성이 좋다.
|
||||||
|
|
||||||
## 서비스 어카운트 자동화
|
## 바인딩된 서비스 어카운트 토큰 볼륨 메커니즘 {#bound-service-account-token-volume}
|
||||||
|
|
||||||
서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.
|
|
||||||
|
|
||||||
- `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` 이 파드에 추가된다.
|
|
||||||
|
|
||||||
#### 바인딩된 서비스 어카운트 토큰 볼륨
|
|
||||||
|
|
||||||
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
|
{{< feature-state for_k8s_version="v1.22" state="stable" >}}
|
||||||
|
|
||||||
서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에
|
기본적으로,
|
||||||
시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다.
|
쿠버네티스 컨트롤 플레인(구체적으로 말하자면 [서비스어카운트 어드미션 컨트롤러](#service-account-admission-controller))은
|
||||||
|
[프로젝티드 볼륨](/ko/docs/concepts/storage/projected-volumes/)을 파드에 추가하며,
|
||||||
|
이 볼륨은 쿠버네티스 API에 접근할 수 있는 토큰을 포함한다.
|
||||||
|
|
||||||
|
다음은 실행된 파드에서 해당 토큰이 어떻게 보이는지에 대한 예시이다.
|
||||||
|
|
||||||
```yaml
|
```yaml
|
||||||
- name: kube-api-access-<random-suffix>
|
...
|
||||||
projected:
|
- name: kube-api-access-<random-suffix>
|
||||||
defaultMode: 420 # 0644
|
projected:
|
||||||
sources:
|
sources:
|
||||||
- serviceAccountToken:
|
- serviceAccountToken:
|
||||||
expirationSeconds: 3607
|
path: token # 애플리케이션이 알고 있는 경로와 일치해야 한다.
|
||||||
path: token
|
- configMap:
|
||||||
- configMap:
|
items:
|
||||||
items:
|
- key: ca.crt
|
||||||
- key: ca.crt
|
path: ca.crt
|
||||||
path: ca.crt
|
name: kube-root-ca.crt
|
||||||
name: kube-root-ca.crt
|
- downwardAPI:
|
||||||
- downwardAPI:
|
items:
|
||||||
items:
|
- fieldRef:
|
||||||
- fieldRef:
|
apiVersion: v1
|
||||||
apiVersion: v1
|
fieldPath: metadata.namespace
|
||||||
fieldPath: metadata.namespace
|
path: namespace
|
||||||
path: namespace
|
|
||||||
```
|
```
|
||||||
|
|
||||||
프로젝티드 볼륨은 세 가지로 구성된다.
|
위의 매니페스트는 세 가지 정보로 구성된 프로젝티드 볼륨을 정의한다.
|
||||||
|
이 경우, 각 정보는 해당 볼륨 내의 단일 경로를 나타내기도 한다. 세 가지 정보는 다음과 같다.
|
||||||
|
|
||||||
1. `kube-apiserver`로부터 TokenRequest API를 통해 얻은 `서비스어카운트토큰(ServiceAccountToken)`.
|
1. `서비스어카운트토큰(serviceAccountToken)` 정보는 kubelet이 kube-apiserver로부터 취득한 토큰을 포함한다.
|
||||||
서비스어카운트토큰은 기본적으로 1시간 뒤에, 또는 파드가 삭제될 때 만료된다.
|
kubelet은 TokenRequest API를 통해 일정 시간 동안 사용할 수 있는 토큰을 발급 받는다.
|
||||||
서비스어카운트토큰은 파드에 연결되며 kube-apiserver를 위해 존재한다.
|
이렇게 취득한 토큰은 파드가 삭제되거나 지정된 수명 주기 이후에 만료된다(기본값은 1시간이다).
|
||||||
1. kube-apiserver에 대한 연결을 확인하는 데 사용되는 CA 번들을 포함하는 `컨피그맵(ConfigMap)`.
|
이 토큰은 특정한 파드에 바인딩되며 kube-apiserver를 그 대상으로 한다.
|
||||||
1. 파드의 네임스페이스를 참조하는 `DownwardAPI`.
|
이 메커니즘은 시크릿을 기반으로 볼륨을 추가하던 이전 메커니즘을 대체한 것이다.
|
||||||
|
해당 시크릿은 파드의 서비스어카운트를 나타냈었는데, 이는 토큰과는 달리 만료가 되지 않는 것이었다.
|
||||||
|
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`
|
서비스 어카운트 개인키 파일은 `--service-account-private-key-file`
|
||||||
플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야
|
플래그를 사용하여 `kube-controller-manager` 의 토큰 컨트롤러에 전달해야
|
||||||
|
|
@ -123,39 +160,240 @@ weight: 50
|
||||||
`kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을
|
`kube-apiserver` 에 전달해야 한다. 공개키는 인증 과정에서 토큰을
|
||||||
검증하는 데 사용될 것이다.
|
검증하는 데 사용될 것이다.
|
||||||
|
|
||||||
#### 추가적인 API 토큰 생성
|
### 서비스어카운트 어드미션 컨트롤러
|
||||||
|
|
||||||
컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스어카운트에 존재하도록 보장한다.
|
파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)라는
|
||||||
서비스어카운트에 대한 추가적인 API 토큰을 생성하기 위해
|
플러그인을 통해 구현된다.
|
||||||
서비스어카운트를 참조하는 어노테이션과 함께
|
이것은 API 서버의 일부이며,
|
||||||
`kubernetes.io/service-account-token` 유형의 시크릿을 생성하면
|
파드가 생성될 때 파드를 수정하기 위해 동기적으로 동작한다.
|
||||||
컨트롤러가 새로 생성된 토큰으로 갱신한다.
|
이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우,
|
||||||
|
어드미션 컨트롤러는 파드의 생성 시점에 다음 작업들을 수행한다.
|
||||||
|
|
||||||
다음은 시크릿에 대한 샘플 구성이다.
|
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-<random-suffix>
|
||||||
|
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: <none>
|
||||||
|
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
|
```yaml
|
||||||
apiVersion: v1
|
apiVersion: v1
|
||||||
kind: Secret
|
kind: ServiceAccount
|
||||||
metadata:
|
metadata:
|
||||||
name: mysecretname
|
|
||||||
annotations:
|
annotations:
|
||||||
kubernetes.io/service-account.name: myserviceaccount
|
kubectl.kubernetes.io/last-applied-configuration: |
|
||||||
type: kubernetes.io/service-account-token
|
{"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
|
```shell
|
||||||
kubectl create -f ./secret.yaml
|
kubectl -n examplens delete secret/example-automated-thing-token-zyxwv
|
||||||
kubectl describe secret mysecretname
|
|
||||||
```
|
```
|
||||||
|
|
||||||
#### 서비스 어카운트 토큰 시크릿 삭제/무효화
|
컨트롤 플레인은 서비스어카운트에 시크릿이 누락되었음을 감지하고,
|
||||||
|
새로운 것으로 대체한다.
|
||||||
|
|
||||||
```shell
|
```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/)을 확인한다.
|
||||||
|
|
|
||||||
|
|
@ -1,4 +1,4 @@
|
||||||
---
|
---
|
||||||
title: 컴포넌트 도구
|
title: 컴포넌트 도구
|
||||||
weight: 60
|
weight: 120
|
||||||
---
|
---
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,7 @@
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Secret
|
||||||
|
type: kubernetes.io/service-account-token
|
||||||
|
metadata:
|
||||||
|
name: mysecretname
|
||||||
|
annotations:
|
||||||
|
kubernetes.io/service-account.name: myserviceaccount
|
||||||
Loading…
Reference in New Issue