[ko] Update outdated files in dev-1.22-ko.2 (M42-M47)
Jihoon Seo
parent
2011e9af62
commit
91303e1a93
|
|
@ -1,4 +1,9 @@
|
|||
---
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
title: 인가 개요
|
||||
content_type: concept
|
||||
weight: 60
|
||||
|
|
@ -187,22 +192,33 @@ status:
|
|||
하나 이상의 인가 모듈을 선택할 수 있다. 모듈이 순서대로 확인되기 때문에
|
||||
우선 순위가 더 높은 모듈이 요청을 허용하거나 거부할 수 있다.
|
||||
|
||||
## 파드 생성을 통한 권한 확대
|
||||
## 워크로드 생성 및 수정을 통한 권한 확대 {#privilege-escalation-via-pod-creation}
|
||||
|
||||
네임스페이스에서 파드를 생성할 수 있는 권한을 가진 사용자는
|
||||
해당 네임스페이스 안에서 자신의 권한을 확대할 가능성이 있다.
|
||||
네임스페이스에서 자신의 권한에 접근할 수 있는 파드를 만들 수 있다.
|
||||
사용자가 스스로 읽을 수 없는 시크릿에 접근할 수 있는 파드나
|
||||
서로 다른/더 큰 권한을 가진 서비스 어카운트로 실행되는 파드를 생성할 수 있다.
|
||||
네임스페이스에서 파드를 직접, 또는 오퍼레이터와 같은 [컨트롤러](/ko/docs/concepts/architecture/controller/)를 통해 생성/수정할 수 있는 사용자는
|
||||
해당 네임스페이스 안에서 자신의 권한을 확대할 수 있다.
|
||||
|
||||
{{< caution >}}
|
||||
시스템 관리자는 파드 생성에 대한 접근 권한을 부여할 때 주의한다.
|
||||
네임스페이스에서 파드(또는 파드를 생성하는 컨트롤러)를 생성할 수 있는 권한을 부여받은 사용자는
|
||||
네임스페이스의 모든 시크릿을 읽을 수 있으며 네임스페이스의 모든 컨피그 맵을 읽을 수 있고
|
||||
네임스페이스의 모든 서비스 어카운트를 가장하고 해당 어카운트가 취할 수 있는 모든 작업을 취할 수 있다.
|
||||
이는 인가 모드에 관계없이 적용된다.
|
||||
시스템 관리자는 파드 생성/수정에 대한 접근 권한을 부여할 때 주의한다.
|
||||
[권한 확대 경로](#escalation-paths)에서 접근 권한이 잘못 사용되었을 때의 상세사항을 확인할 수 있다.
|
||||
{{< /caution >}}
|
||||
|
||||
### 권한 확대 경로 {#escalation-paths}
|
||||
- 네임스페이스 내의 임의의 시크릿을 마운트
|
||||
- 다른 워크로드를 위한 시크릿으로의 접근에 사용될 수 있음
|
||||
- 더 권한이 많은 서비스 어카운트의 서비스 어카운트 토큰 획득에 사용될 수 있음
|
||||
- 네임스페이스 내의 임의의 서비스 어카운트를 사용
|
||||
- 다른 워크로드인것처럼 사칭하여 쿠버네티스 API 액션을 수행할 수 있음
|
||||
- 서비스 어카운트가 갖고 있는 '권한이 필요한 액션'을 수행할 수 있음
|
||||
- 네임스페이스 내의 다른 워크로드를 위한 컨피그맵을 마운트
|
||||
- 다른 워크로드를 위한 정보(예: DB 호스트 이름) 획득에 사용될 수 있음
|
||||
- 네임스페이스 내의 다른 워크로드를 위한 볼륨을 마운트
|
||||
- 다른 워크로드를 위한 정보의 획득 및 수정에 사용될 수 있음
|
||||
|
||||
{{< caution >}}
|
||||
시스템 관리자는 위와 같은 영역을 수정하는 CRD를 배포할 때 주의를 기울여야 한다.
|
||||
이들은 의도하지 않은 권한 확대 경로를 노출할 수 있다.
|
||||
RBAC 제어에 대해 결정할 때 이와 같은 사항을 고려해야 한다.
|
||||
{{< /caution >}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ weight: 50
|
|||
defaultMode: 420 # 0644
|
||||
sources:
|
||||
- serviceAccountToken:
|
||||
expirationSeconds: 3600
|
||||
expirationSeconds: 3607
|
||||
path: token
|
||||
- configMap:
|
||||
items:
|
||||
|
|
|
|||
|
|
@ -165,8 +165,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
| `PreferNominatedNode` | `true` | 베타 | 1.22 | |
|
||||
| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 |
|
||||
| `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | |
|
||||
| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | |
|
||||
| `ProcMountType` | `false` | 알파 | 1.12 | |
|
||||
| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | |
|
||||
| `QOSReserved` | `false` | 알파 | 1.11 | |
|
||||
| `ReadWriteOncePod` | `false` | 알파 | 1.22 | |
|
||||
| `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 |
|
||||
|
|
@ -789,10 +789,6 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
플러그인의 등록을 중지한다.
|
||||
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
|
||||
완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다.
|
||||
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고
|
||||
[잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다.
|
||||
잡 컨트롤러는 완료된 파드를 추적하기 위해
|
||||
완료된 파드의 잡 상태 필드를 사용한다.
|
||||
- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로
|
||||
한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에
|
||||
`Scope` 와 `Namespace` 2개의 필드를 추가한다.
|
||||
|
|
@ -800,10 +796,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
비동기 조정을 허용한다.
|
||||
- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
|
||||
기능을 활성화한다.
|
||||
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아있는 파드에
|
||||
의존하지 않고 잡 완료를 추적할 수 있다.
|
||||
파드 finalizers는 잡 상태 필드와
|
||||
아직 구성되지 않은 파드를 추적할 수 있다.
|
||||
- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고
|
||||
[잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다.
|
||||
잡 컨트롤러는 완료된 파드를 추적하기 위해
|
||||
완료된 파드의 잡 상태 필드를 사용한다.
|
||||
- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서
|
||||
kubelet 구성을 로드할 수 있다.
|
||||
자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을
|
||||
|
|
@ -1012,19 +1008,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
|
|||
- `WatchBookmark`: 감시자 북마크(watch bookmark) 이벤트 지원을 활성화한다.
|
||||
- `WinDSR`: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다.
|
||||
- `WinOverlay`: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다.
|
||||
- `WindowsEndpointSliceProxying`: 활성화되면, 윈도우에서 실행되는 kube-proxy는
|
||||
엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여
|
||||
확장성과 성능을 향상시킨다.
|
||||
[엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.
|
||||
- `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다.
|
||||
- `WindowsHostProcessContainers`: 윈도우 HostProcess 컨테이너에 대한 지원을 사용하도록 설정한다.
|
||||
- `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서
|
||||
애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은
|
||||
[RunAsUserName 구성](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을
|
||||
참고한다.
|
||||
- `WindowsEndpointSliceProxying`: 활성화되면, 윈도우에서 실행되는 kube-proxy는
|
||||
엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여
|
||||
확장성과 성능을 향상시킨다.
|
||||
[엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.
|
||||
- `WindowsHostProcessContainers`: 윈도우 노드에서 `HostProcess`
|
||||
컨테이너 지원을 활성화한다.
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
|
@ -1,4 +1,6 @@
|
|||
---
|
||||
|
||||
|
||||
title: kubectl 개요
|
||||
content_type: concept
|
||||
weight: 20
|
||||
|
|
@ -69,6 +71,32 @@ kubectl [command] [TYPE] [NAME] [flags]
|
|||
|
||||
도움이 필요하다면, 터미널 창에서 `kubectl help` 를 실행한다.
|
||||
|
||||
## 클러스터 내 인증과 네임스페이스 오버라이드
|
||||
|
||||
기본적으로 `kubectl`은 먼저 자신이 파드 안에서 실행되고 있는지, 즉 클러스터 안에 있는지를 판별한다. 이를 위해 `KUBERNETES_SERVICE_HOST`와 `KUBERNETES_SERVICE_PORT` 환경 변수, 그리고 서비스 어카운트 토큰 파일이 `/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 있는지를 확인한다. 세 가지가 모두 감지되면, 클러스터 내 인증이 적용된다.
|
||||
|
||||
하위 호환성을 위해, 클러스터 내 인증 시에 `POD_NAMESPACE` 환경 변수가 설정되어 있으면, 서비스 어카운트 토큰의 기본 네임스페이스 설정을 오버라이드한다. 기본 네임스페이스 설정에 의존하는 모든 매니페스트와 도구가 영향을 받을 것이다.
|
||||
|
||||
**`POD_NAMESPACE` 환경 변수**
|
||||
|
||||
`POD_NAMESPACE` 환경 변수가 설정되어 있으면, 네임스페이스에 속하는 자원에 대한 CLI 작업은 환경 변수에 설정된 네임스페이스를 기본값으로 사용한다. 예를 들어, 환경 변수가 `seattle`로 설정되어 있으면, `kubectl get pods` 명령은 `seattle` 네임스페이스에 있는 파드 목록을 반환한다. 이는 파드가 네임스페이스에 속하는 자원이며, 명령어에 네임스페이스를 특정하지 않았기 때문이다. `kubectl api-resources` 명령을 실행하고 결과를 확인하여 특정 자원이 네임스페이스에 속하는 자원인지 판별한다.
|
||||
|
||||
명시적으로 `--namespace <value>` 인자를 사용하면 위와 같은 동작을 오버라이드한다.
|
||||
|
||||
**kubectl이 서비스어카운트 토큰을 관리하는 방법**
|
||||
|
||||
만약
|
||||
* 쿠버네티스 서비스 어카운트 토큰 파일이
|
||||
`/var/run/secrets/kubernetes.io/serviceaccount/token` 경로에 마운트되어 있고,
|
||||
* `KUBERNETES_SERVICE_HOST` 환경 변수가 설정되어 있고,
|
||||
* `KUBERNETES_SERVICE_PORT` 환경 변수가 설정되어 있고,
|
||||
* kubectl 명령에 네임스페이스를 명시하지 않으면
|
||||
kubectl은 자신이 클러스터 내부에서 실행되고 있다고 가정한다.
|
||||
kubectl은 해당 서비스어카운트의 네임스페이스(파드의 네임스페이스와 동일하다)를 인식하고 해당 네임스페이스에 대해 동작한다.
|
||||
이는 클러스터 외부에서 실행되었을 때와는 다른데,
|
||||
kubectl이 클러스터 외부에서 실행되었으며 네임스페이스가 명시되지 않은 경우
|
||||
kubectl은 `default` 네임스페이스에 대해 동작한다.
|
||||
|
||||
## 명령어
|
||||
|
||||
다음 표에는 모든 `kubectl` 작업에 대한 간단한 설명과 일반적인 구문이 포함되어 있다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue