whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Second Korean l10n work for release-1.19

Browse Source 
- Fix issue with links to already translated documents (#23829)
- Update outdated files in the dev-1.19-ko.2 branch (#23827)
- Fix issue with links to already translated documents (#23999)
- Translate tasks/configure-pod-container/configure-persistent-volume-storage in Korean (#23867)
- Translate reference/access-authn-authz/service-accounts-admin/ into Korean (#23974)
- Translate reference/access-authn-authz/controlling-access/ into Korean (#23955)
- Translate tasks/job/automated-tasks-with-cron-jobs.md into Korean (#23543)
- Translate reference/access-authn-authz/authorization/ into Korean (#23989)
- Update Ko localization guide (#24023)
- Translate tasks/job/fine-parallel-processing-work-queue/ into Korean (#23841)
- Translate setup/production-environment/windows/intro-windows-in-kubernetes and reflect reviews (#23879)
- Translate tasks/debug-application-cluster/debug-pod-replication-controller in Korean (#23896)

Co-authored-by: seokho-son <shsongist@gmail.com>
Co-authored-by: jmyung <jesang.myung@gmail.com>
Co-authored-by: Jerry Park <jaehwa@gmail.com>
Co-authored-by: markruler <csu0414@gmail.com>
Co-authored-by: bluefriday <bluefriday86@gmail.com>
This commit is contained in:
Jerry Park
2020-09-12 17:00:03 +09:00
committed by seokho-son
parent a38e75406a
commit 9cb997ab15
65 changed files with 2220 additions and 586 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/ko/docs/reference/access-authn-authz/_index.md
+4
View File
@@ -0,0 +1,4 @@
---
title: API 접근하기
weight: 20
---
content/ko/docs/reference/access-authn-authz/authorization.md
+201
View File
@@ -0,0 +1,201 @@
---
title: 인가 개요
content_type: concept
weight: 60
---
<!-- overview -->
지원되는 인가 모듈을 사용하여 정책을 만드는 방법을 포함한
쿠버네티스 인가에 대해 자세히 알아보자.
<!-- body -->
쿠버네티스에서는 사용자의 요청이 인가(접근 권한을 부여) 받기 전에 사용자가 인증(로그인)되어야 한다.
인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)를
참고한다.
쿠버네티스는 REST API 요청에 공통적인 속성을 요구한다.
이는 쿠버네티스 인가가 쿠버네티스 API 이외에 다른 API를 처리할 수 있는
기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과
연동된다는 것을 의미한다.
## 요청 허용 또는 거부 결정
쿠버네티스는 API 서버를 이용하여 API 요청을 인가한다.
모든 정책과 비교하여 모든 요청 속성을 평가하고 요청을 허용하거나 거부한다.
계속 진행하려면 API 요청의 모든 부분이 일부 정책에 의해 반드시 허용되어야 한다.
이는 기본적으로 승인이 거부된다는 것을 의미한다.
(쿠버네티스는 API 서버를 사용하지만,
특정 오브젝트의 특정 필드에 의존하는 접근 제어 및 정책은
어드미션 컨트롤러에 의해 처리된다.)
여러 개의 인가 모듈이 구성되면 각 모듈이 순서대로 확인된다.
어느 인가 모듈이 요청을 승인하거나 거부할 경우, 그 결정은 즉시 반환되며 다른 인가 모듈이 참고되지 않는다.
모든 모듈에서 요청에 대한 평가가 없으면 요청이 거부된다.
요청 거부는 HTTP 상태 코드 403을 반환한다.
## 요청 속성 검토
쿠버네티스는 다음 API 요청 속성만 검토한다.
* **user** - 인증 중에 제공된 `user` 문자열.
* **group** - 인증된 사용자가 속한 그룹 이름 목록.
* **extra** - 인증 계층에서 제공하는 문자열 값에 대한 임의의 문자열 키 맵.
* **API** - 요청이 API 리소스에 대한 것인지 여부.
* **Request path** - `/api` 또는 `/healthz`와 같이 다양한 리소스가 아닌 엔드포인트의 경로.
* **API request verb** - `get`, `list`, `create`, `update`, `patch`, `watch`, `delete`, `deletecollection`과 같은 리소스 요청에 사용하는 API 동사. 리소스 API 엔드포인트의 요청 동사를 결정하려면 [요청 동사 결정](/docs/reference/access-authn-authz/authorization/#determine-the-request-verb)을 참고한다.
* **HTTP request verb** - `get`, `post`, `put`, `delete`처럼 소문자 HTTP 메서드는 리소스가 아닌 요청에 사용한다.
* **Resource** - 접근 중인 리소스의 ID 또는 이름(리소스 요청만 해당) -- `get`, `update`, `patch`, `delete` 동사를 사용하는 리소스 요청의 경우 리소스 이름을 지정해야 한다.
* **Subresource** - 접근 중인 하위 리소스(리소스 요청만 해당).
* **Namespace** - 접근 중인 오브젝트의 네임스페이스(네임스페이스에 할당된 리소스 요청만 해당)
* **API group** - 접근 중인 {{< glossary_tooltip text="API 그룹" term_id="api-group" >}}(리소스 요청에만 해당). 빈 문자열은 [핵심(core) API 그룹](/ko/docs/concepts/overview/kubernetes-api/)을 지정한다.
## 요청 동사 결정
**리소스가 아닌 요청**
`/api/v1/...` 또는 `/apis/<group>/<version>/...` 이외에 다른 엔드포인트에 대한 요청은
"리소스가 아닌 요청"으로 간주되며, 요청의 소문자 HTTP 메서드를 동사로 사용한다.
예를 들어, `/api` 또는 `/healthz`와 같은 엔드포인트에 대한 `GET` 요청은 `get`을 동사로 사용할 것이다.
**리소스 요청**
리소스 API 엔드포인트에 대한 요청 동사를 결정하려면
사용된 HTTP 동사와 해당 요청이 개별 리소스 또는 리소스 모음에 적용되는지 여부를
검토한다.
HTTP 동사 | 요청 동사
----------|---------------
POST | create
GET, HEAD | get(개별 리소스), list(전체 오브젝트 내용을 포함한 리소스 모음), watch(개별 리소스 또는 리소스 모음을 주시)
PUT | update
PATCH | patch
DELETE | delete(개별 리소스), deletecollection(리소스 모음)
쿠버네티스는 종종 전문 동사를 사용하여 부가적인 권한 인가를 확인한다. 예를 들면,
* [파드시큐리티폴리시(PodSecurityPolicy)](/ko/docs/concepts/policy/pod-security-policy/)
* `policy` API 그룹의 `podsecuritypolicies` 리소스에 대한 `use` 동사.
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
* `rbac.authorization.k8s.io` API 그룹의 `roles` 및 `clusterroles` 리소스에 대한 `bind` 동사.
* [인증](/docs/reference/access-authn-authz/authentication/)
* 핵심 API 그룹의 `users`, `groups`, `serviceaccounts`와 `authentication.k8s.io` API 그룹의 `userextras` 동사.
## 인가 모드 {#authorization-modules}
쿠버네티스 API 서버는 몇 가지 인가 모드 중 하나를 사용하여 요청을 승인할 수 있다.
* **Node** - 실행되도록 스케줄된 파드에 따라 kubelet에게 권한을 부여하는 특수 목적 인가 모드. Node 인가 모드 사용에 대한 자세한 내용은 [Node 인가](/docs/reference/access-authn-authz/node/)을 참조한다.
* **ABAC** - 속성 기반 접근 제어 (ABAC, Attribute-based access control)는 속성과 결합한 정책의 사용을 통해 사용자에게 접근 권한을 부여하는 접근 제어 패러다임을 말한다. 이 정책은 모든 유형의 속성(사용자 속성, 리소스 속성, 오브젝트, 환경 속성 등)을 사용할 수 있다. ABAC 모드 사용에 대한 자세한 내용은 [ABAC 모드](/docs/reference/access-authn-authz/abac/)를 참조한다.
* **RBAC** - 역할 기반 접근 제어(RBAC, Role-based access control)는 기업 내 개별 사용자의 역할을 기반으로 컴퓨터나 네트워크 리소스에 대한 접근을 규제하는 방식이다. 이 맥락에서 접근은 개별 사용자가 파일을 보거나 만들거나 수정하는 것과 같은 특정 작업을 수행할 수 있는 능력이다. RBAC 모드 사용에 대한 자세한 내용은 [RBAC 모드](/docs/reference/access-authn-authz/rbac/)를 참조한다.
* 지정된 RBAC(역할 기반 접근 제어)이 인가 결정을 위해 `rbac.authorization.k8s.io` API 그룹을 사용하면, 관리자가 쿠버네티스 API를 통해 권한 정책을 동적으로 구성할 수 있다.
* RBAC을 활성화하려면 `--authorization-mode=RBAC`로 API 서버를 시작한다.
* **Webhook** - WebHook은 HTTP 콜백이다(어떤 일이 일어날 때 발생하는 HTTP POST와 HTTP POST를 통한 간단한 이벤트 알림). WebHook을 구현하는 웹 애플리케이션은 특정한 일이 발생할 때 URL에 메시지를 POST 할 것이다. Webhook 모드 사용에 대한 자세한 내용은 [Webhook 모드](/docs/reference/access-authn-authz/webhook/)를 참조한다.
#### API 접근 확인
`kubectl`은 API 인증 계층을 신속하게 쿼리하기 위한 "auth can-i" 하위 명령어를 제공한다.
이 명령은 현재 사용자가 지정된 작업을 수행할 수 있는지 여부를 알아내기 위해 `SelfSubjectAccessReview` API를 사용하며,
사용되는 인가 모드에 관계없이 작동한다.
```bash
kubectl auth can-i create deployments --namespace dev
```
```
yes
```
```shell
kubectl auth can-i create deployments --namespace prod
```
```
no
```
관리자는 이를 [사용자 가장(impersonation)](/docs/reference/access-authn-authz/authentication/#user-impersonation)과
병행하여 다른 사용자가 수행할 수 있는 작업을 결정할 수 있다.
```bash
kubectl auth can-i list secrets --namespace dev --as dave
```
```
no
```
`SelfSubjectAccessReview`는 `authorization.k8s.io` API 그룹의 일부로서
API 서버 인가를 외부 서비스에 노출시킨다.
이 그룹의 기타 리소스에는 다음이 포함된다.
* `SubjectAccessReview` - 현재 사용자뿐만 아니라 모든 사용자에 대한 접근 검토. API 서버에 인가 결정을 위임하는 데 유용하다. 예를 들어, kubelet 및 확장(extension) API 서버는 자신의 API에 대한 사용자 접근을 결정하기 위해 해당 리소스를 사용한다.
* `LocalSubjectAccessReview` - `SubjectAccessReview`와 비슷하지만 특정 네임스페이스로 제한된다.
* `SelfSubjectRulesReview` - 사용자가 네임스페이스 안에서 수행할 수 있는 작업 집합을 반환하는 검토. 사용자가 자신의 접근을 빠르게 요약해서 보거나 UI가 작업을 숨기거나 표시하는 데 유용하다.
이러한 API는 반환된 객체의 응답 "status" 필드가 쿼리의 결과인
일반 쿠버네티스 리소스를 생성하여 쿼리할 수 있다.
```bash
kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
resourceAttributes:
group: apps
resource: deployments
verb: create
namespace: dev
EOF
```
생성된 `SelfSubjectAccessReview` 는 다음과 같다.
```
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
creationTimestamp: null
spec:
resourceAttributes:
group: apps
resource: deployments
namespace: dev
verb: create
status:
allowed: true
denied: false
```
## 인가 모듈에 플래그 사용
정책에 포함된 인가 모듈을 나타내기 위해
정책에 플래그를 포함시켜야 한다.
다음 플래그를 사용할 수 있다.
* `--authorization-mode=ABAC` 속성 기반 접근 제어(ABAC) 모드를 사용하면 로컬 파일을 사용하여 정책을 구성할 수 있다.
* `--authorization-mode=RBAC` 역할 기반 접근 제어(RBAC) 모드를 사용하면 쿠버네티스 API를 사용하여 정책을 만들고 저장할 수 있다.
* `--authorization-mode=Webhook` WebHook은 원격 REST 엔드포인트를 사용하여 인가를 관리할 수 있는 HTTP 콜백 모드다.
* `--authorization-mode=Node` 노드 인가는 kubelet이 생성한 API 요청을 특별히 인가시키는 특수 목적 인가 모드다.
* `--authorization-mode=AlwaysDeny` 이 플래그는 모든 요청을 차단한다. 이 플래그는 테스트에만 사용한다.
* `--authorization-mode=AlwaysAllow` 이 플래그는 모든 요청을 허용한다. API 요청에 대한 인가가 필요하지 않은 경우에만 이 플래그를 사용한다.
하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에
우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다.
## 파드 생성을 통한 권한 확대
네임스페이스에서 파드를 생성할 수 있는 권한을 가진 사용자는
해당 네임스페이스 안에서 자신의 권한을 확대할 가능성이 있다.
네임스페이스에서 자신의 권한에 접근할 수 있는 파드를 만들 수 있다.
사용자가 스스로 읽을 수 없는 시크릿에 접근할 수 있는 파드나
서로 다른/더 큰 권한을 가진 서비스 어카운트로 실행되는 파드를 생성할 수 있다.
{{< caution >}}
시스템 관리자는 파드 생성에 대한 접근 권한을 부여할 때 주의한다.
네임스페이스에서 파드(또는 파드를 생성하는 컨트롤러)를 생성할 수 있는 권한을 부여받은 사용자는
네임스페이스의 모든 시크릿을 읽을 수 있으며 네임스페이스의 모든 컨피그 맵을 읽을 수 있고
네임스페이스의 모든 서비스 어카운트를 가장하고 해당 어카운트가 취할 수 있는 모든 작업을 취할 수 있다.
이는 인가 모드에 관계없이 적용된다.
{{< /caution >}}
## {{% heading "whatsnext" %}}
* 인증에 대한 자세한 내용은 [쿠버네티스 API 접근 제어하기](/docs/reference/access-authn-authz/controlling-access/)에서 **인증**을 참조한다.
* 어드미션 제어에 대한 자세한 내용은 [어드미션 컨트롤러 사용하기](/docs/reference/access-authn-authz/admission-controllers/)를 참조한다.
content/ko/docs/reference/access-authn-authz/controlling-access.md
+162
View File
@@ -0,0 +1,162 @@
---
title: 쿠버네티스 API 접근 제어하기
content_type: concept
weight: 5
---
<!-- overview -->
이 페이지는 쿠버네티스 API에 대한 접근 제어의 개요를 제공한다.
<!-- body -->
사용자는 `kubectl`, 클라이언트 라이브러리
또는 REST 요청을 통해
[API에 접근한다](/docs/tasks/access-application-cluster/access-cluster/).
사용자와 쿠버네티스 서비스 어카운트 모두 API에 접근할 수 있다.
요청이 API에 도달하면,
다음 다이어그램에 설명된 몇 가지 단계를 거친다.
![Diagram of request handling steps for Kubernetes API request](/images/docs/admin/access-control-overview.svg)
## 전송 보안
일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다.
API 서버는 인증서를 제시한다.
이 인증서는 종종 자체 서명되기 때문에 일반적으로 사용자 머신의 `$USER/.kube/config`는
API 서버의 인증서에 대한 루트 인증서를 포함하며,
시스템 기본 루트 인증서 대신 사용된다.
`kube-up.sh`을 사용하여 클러스터를 직접 생성할 때
이 인증서는 일반적으로 `$USER/.kube/config`에 자동으로 기록된다.
클러스터에 여러 명의 사용자가 있는 경우, 작성자는 인증서를 다른 사용자와 공유해야 한다.
## 인증
TLS가 설정되면 HTTP 요청이 인증 단계로 넘어간다.
이는 다이어그램에 **1**단계로 표시되어 있다.
클러스터 생성 스크립트 또는 클러스터 관리자는
API 서버가 하나 이상의 인증기 모듈을 실행하도록 구성한다.
인증기는 [여기](/docs/reference/access-authn-authz/authentication/)에서 더 자세히 서술한다.
인증 단계로 들어가는 것은 온전한 HTTP 요청이지만
일반적으로 헤더 그리고/또는 클라이언트 인증서만 검사한다.
인증 모듈은 클라이언트 인증서, 암호 및 일반 토큰, 부트스트랩 토큰,
JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
여러 개의 인증 모듈을 지정할 수 있으며,
이 경우 하나의 인증 모듈이 성공할 때까지 각 모듈을 순차적으로 시도한다.
GCE에서는 클라이언트 인증서, 암호, 일반 토큰 및 JWT 토큰이 모두 사용 가능하다.
요청을 인증할 수 없는 경우 HTTP 상태 코드 401과 함께 거부된다.
이 외에는 사용자가 특정 `username`으로 인증되며,
이 username은 다음 단계에서 사용자의 결정에 사용할 수 있다.
일부 인증기는 사용자 그룹 관리 기능을 제공하는 반면,
이외의 인증기는 그렇지 않다.
쿠버네티스는 접근 제어 결정과 요청 기록 시 `usernames`를 사용하지만,
`user` 오브젝트를 가지고 있지 않고 usernames 나 기타 사용자 정보를
오브젝트 저장소에 저장하지도 않는다.
## 인가
특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다. 이는 다이어그램에 **2**단계로 표시되어 있다.
요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다. 기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우 요청이 인가된다.
예를 들어 Bob이 아래와 같은 정책을 가지고 있다면 `projectCaribou` 네임스페이스에서만 파드를 읽을 수 있다.
```json
{
"apiVersion": "abac.authorization.kubernetes.io/v1beta1",
"kind": "Policy",
"spec": {
"user": "bob",
"namespace": "projectCaribou",
"resource": "pods",
"readonly": true
}
}
```
Bob이 다음과 같은 요청을 하면 'projectCaribou' 네임스페이스의 오브젝트를 읽을 수 있기 때문에 요청이 인가된다.
```json
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "projectCaribou",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
}
}
}
```
Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`create` 또는 `update`) 요청을 하면 그의 인가는 거부된다. 만약 Bob이 `projectFish`처럼 다른 네임스페이스의 오브젝트 읽기(`get`) 요청을 하면 그의 인가는 거부된다.
쿠버네티스 인가는 공통 REST 속성을 사용하여 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 상호 작용할 것을 요구한다. 이러한 제어 시스템은 쿠버네티스 API 이외의 다른 API와 상호작용할 수 있으므로 REST 형식을 사용하는 것이 중요하다.
쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).
인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/docs/reference/access-authz/authorization/)를 참조한다.
## 어드미션 제어
어드미션 제어 모듈은 요청을 수정하거나 거부할 수 있는 소프트웨어 모듈이다.
인가 모듈에서 사용할 수 있는 속성 외에도
어드미션 제어 모듈은 생성되거나 수정된 오브젝트 내용에 접근할 수 있다.
어드미션 컨트롤러는 오브젝트를 생성, 수정, 삭제 또는 (프록시에) 연결하는 요청에 따라 작동한다.
어드미션 컨트롤러는 단순히 객체를 읽는 요청에는 작동하지 않는다.
여러 개의 어드미션 컨트롤러가 구성되면 순서대로 호출된다.
이는 다이어그램에 **3**단계로 표시되어 있다.
인증 및 인가 모듈과 달리,
어드미션 제어 모듈이 거부되면 요청은 즉시 거부된다.
어드미션 제어 모듈은 오브젝트를 거부하는 것 외에도
필드의 복잡한 기본값을 설정할 수 있다.
사용 가능한 어드미션 제어 모듈은 [여기](/docs/reference/access-authn-authz/admission-controllers/)에 서술되어 있다.
요청이 모든 어드미션 제어 모듈을 통과하면 유효성 검사 루틴을 사용하여 해당 API 오브젝트를 검증한 후
오브젝트 저장소에 기록(**4**단계)된다.
## API 서버 포트와 IP
이전의 논의는 (일반적인 경우) API 서버의 보안 포트로 전송되는 요청에 적용된다.
API 서버는 실제로 다음과 같이 2개의 포트에서 서비스할 수 있다.
기본적으로 쿠버네티스 API 서버는 2개의 포트에서 HTTP 서비스를 한다.
1. `로컬호스트 포트`:
- 테스트 및 부트스트랩을 하기 위한 것이며 마스터 노드의 다른 구성요소
(스케줄러, 컨트롤러 매니저)가 API와 통신하기 위한 것이다.
- TLS가 없다.
- 기본 포트는 8080이며, `--insecure-port` 플래그를 사용하여 변경한다.
- 기본 IP는 로컬호스트(localhost)이며, `--insecure-bind-address` 플래그를 사용하여 변경한다.
- 요청이 인증 및 인가 모듈을 **우회한다**.
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
- 호스트 접근 요구로부터 보호를 받는다.
2. `보안 포트`:
- 가능한 항상 사용하는 것이 좋다.
- TLS를 사용한다. `--tls-cert-file` 플래그로 인증서를 지정하고 `--tls-private-key-file` 플래그로 키를 지정한다.
- 기본 포트는 6443이며, `--secure-port` 플래그를 사용하여 변경한다.
- 기본 IP는 로컬호스트가 아닌 첫 번째 네트워크 인터페이스이며, `--bind-address` 플래그를 사용하여 변경한다.
- 요청이 인증 및 인가 모듈에 의해 처리된다.
- 요청이 어드미션 제어 모듈(들)에 의해 처리된다.
- 인증 및 인가 모듈을 실행한다.
GCE(구글 컴퓨트 엔진) 및 다른 클라우드 제공자에서 `kube-up.sh`로 클러스터를 생성하면
API 서버는 포트 443에서 서비스한다.
GCE에서는 외부 HTTPS가 API에 접근할 수 있도록 프로젝트에서 방화벽 규칙이 구성된다.
이외에 클러스터 설정 방법은 다양하다.
content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
+112
View File
@@ -0,0 +1,112 @@
---
title: 서비스 어카운트 관리하기
content_type: concept
weight: 50
---
<!-- overview -->
이것은 서비스 어카운트에 대한 클러스터 관리자 안내서다.
독자는 [쿠버네티스 서비스 어카운트 설정](/docs/tasks/configure-pod-container/configure-service-account/)에 익숙하다고 가정한다.
인증 및 사용자 어카운트에 대한 지원은 아직 준비 중이다.
가끔은 서비스 어카운트를 더 잘 설명하기 위해 준비 중인 기능을 참조한다.
<!-- body -->
## 사용자 어카운트와 서비스 어카운트 비교
쿠버네티스는 여러 가지 이유로 사용자 어카운트와 서비스 어카운트의 개념을
구분한다.
- 사용자 어카운트는 사람을 위한 것이다. 서비스 어카운트는 파드에서 실행되는 프로세스를
위한 것이다.
- 사용자 어카운트는 전역을 대상으로 고려된다.
클러스터의 모든 네임스페이스에 걸쳐 이름이 고유해야 하며, 향후 사용자 리소스는 네임스페이스에 할당되지 않는다.
서비스 어카운트는 네임스페이스에 할당된다.
- 일반적으로 클러스터의 사용자 어카운트는 기업 데이터베이스로부터 동기화될 수 있으며,
여기서 새로운 사용자 어카운트를 생성하려면 특별한 권한이 필요하며 복잡한 비즈니스 프로세스에 연결된다.
서비스 어카운트 생성은
클러스터 사용자가 특정 작업(즉, 최소 권한 원칙)을 위한 서비스 어카운트를 만들 수 있도록
보다 가볍게 만들어졌다.
- 사람과 서비스 어카운트에 대한 감사 항목은 다를 수 있다.
- 복잡한 시스템의 설정들은 그 시스템의 구성요소에 대한 다양한 서비스 어카운트 정의를 포함할 수 있다.
서비스 어카운트는 임시(ad-hoc)로 만들 수도 있고 네임스페이스에 할당된 이름을 가질 수도 있기 때문에
이러한 설정은 이식성이 좋다.
## 서비스 어카운트 자동화
서비스 계정 자동화를 구현하기 위해 세 가지 개별 요소가 협력한다.
- 서비스 어카운트 어드미션 컨트롤러
- 토큰 컨트롤러
- 서비스 어카운트 컨트롤러
### 서비스 어카운트 어드미션 컨트롤러
파드 수정은 [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)
라는 플러그인을 통해 구현된다. 이것은 apiserver의 일부이다.
파드가 생성되거나 수정될 때 파드를 수정하기 위해 동기적으로 동작한다.
이 플러그인이 활성 상태(대부분의 배포에서 기본값)인 경우 파드 생성 또는 수정 시 다음 작업을 수행한다.
1. 파드에 `ServiceAccount`가 없다면 `ServiceAccount`를 `default`로 설정한다.
1. 파드에 참조되는 `ServiceAccount`가 있도록 하고, 그렇지 않으면 이를 거부한다.
1. 파드에 `ImagePullSecrets`이 없는 경우 `ServiceAccount`의 `ImagePullSecrets`이 파드에 추가된다.
1. 파드에 API 접근 토큰이 포함된 `volume`을 추가한다.
1. `/var/run/secrets/kubernetes.io/serviceaccount`에 마운트된 파드의 각 컨테이너에 `volumeSource`를 추가한다.
v1.13부터 `BoundServiceAccountTokenVolume` 기능 게이트가 활성화되면 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 마이그레이션할 수 있다.
서비스 어카운트 토큰은 1시간 후에 만료되거나 파드가 삭제된다.
[프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)에 대한 자세한 내용을 참조한다.
### 토큰 컨트롤러
토큰컨트롤러는 컨트롤러 매니저의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
- 서비스 어카운트 생성을 지켜보고 API에 접근할 수 있는 시크릿을 생성한다.
- 서비스 어카운트 삭제를 지켜보고 해당하는 모든 서비스 어카운트 토큰 시크릿을 삭제한다.
- 시크릿 추가를 지켜보고 참조된 서비스 어카운트가 존재하는지 확인하고 필요한 경우 시크릿에 토큰을 추가한다.
- 시크릿 삭제를 지켜보고 필요한 경우 해당 서비스 어카운트에서 참조를 제거한다.
서비스 어카운트 개인키 파일은 `--service-account-private-key-file` 옵션을 사용하여 컨트롤러 매니저의 토큰 컨트롤러에 전달해야 한다.
개인키는 생성된 서비스 어카운트 토큰에 서명하는 데 사용될 것이다.
마찬가지로 `--service-account-key-file` 옵션을 사용하여 해당 공개키를 쿠버네티스 API 서버에 전달해야 한다.
공개키는 인증 과정에서 토큰을 검증하는 데 사용될 것이다.
#### 추가적인 API 토큰 생성
컨트롤러 루프는 API 토큰이 포함된 시크릿이 각 서비스 어카운트에 존재하도록 보장한다.
서비스 어카운트에 대한 추가적인 API 토큰을 생성하기 위해
서비스 어카운트를 참조하는 어노테이션과 함께 `ServiceAccountToken` 유형의 시크릿을 생성하면
컨트롤러가 새로 생성된 토큰으로 갱신한다.
secret.json:
```json
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "mysecretname",
"annotations": {
"kubernetes.io/service-account.name": "myserviceaccount"
}
},
"type": "kubernetes.io/service-account-token"
}
```
```shell
kubectl create -f ./secret.json
kubectl describe secret mysecretname
```
#### 서비스 어카운트 토큰 삭제/무효화
```shell
kubectl delete secret mysecretname
```
### 서비스 어카운트 컨트롤러
서비스 어카운트 컨트롤러는 네임스페이스에 있는 서비스 어카운트를 관리하고
"default"라는 이름의 서비스 어카운트가 모든 활성 네임스페이스에 존재하는지 확인한다.