Update outdated files dev-1.25-ko.1 (M22-M33)
WESTZERO115
parent
e454944cfd
commit
35aa2d624d
|
|
@ -54,8 +54,8 @@ profiles:
|
|||
할당된 리소스의 구성된 기능에 따라 노드를 선호하게 한다. `NodeResourcesFit`점수 기능의
|
||||
`RequestedToCapacityRatio` 동작은 [scoringStrategy](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-ScoringStrategy)필드를
|
||||
이용하여 제어할 수 있다.
|
||||
`scoringStrategy` 필드에서 `requestedToCapacityRatioParam`와 `resources`라는 두 개의 파라미터를
|
||||
구성할 수 있다. `requestedToCapacityRatioParam`파라미터의
|
||||
`scoringStrategy` 필드에서 `requestedToCapacityRatio`와 `resources`라는 두 개의 파라미터를
|
||||
구성할 수 있다. `requestedToCapacityRatio`파라미터의
|
||||
`shape`를 사용하면 `utilization`과 `score` 값을 기반으로
|
||||
최소 요청 혹은 최대 요청된 대로 기능을 조정할 수 있게 한다.
|
||||
`resources` 파라미터는 점수를 매길 때 고려할 리소스의 `name` 과
|
||||
|
|
@ -77,7 +77,7 @@ profiles:
|
|||
weight: 3
|
||||
- name: intel.com/bar
|
||||
weight: 3
|
||||
requestedToCapacityRatioParam:
|
||||
requestedToCapacityRatio:
|
||||
shape:
|
||||
- utilization: 0
|
||||
score: 0
|
||||
|
|
|
|||
|
|
@ -48,7 +48,8 @@ weight: 40
|
|||
|
||||
## `topologySpreadConstraints` 필드
|
||||
|
||||
파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 예시는 다음과 같다.
|
||||
파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 이 필드는 다음과 같이
|
||||
쓰인다.
|
||||
|
||||
```yaml
|
||||
---
|
||||
|
|
@ -60,14 +61,18 @@ spec:
|
|||
# 토폴로지 분배 제약 조건을 구성한다.
|
||||
topologySpreadConstraints:
|
||||
- maxSkew: <integer>
|
||||
minDomains: <integer> # 선택 사항이며, v1.24에서 알파 기능으로 도입되었다.
|
||||
minDomains: <integer> # 선택 사항이며, v1.25에서 베타 기능으로 도입되었다.
|
||||
topologyKey: <string>
|
||||
whenUnsatisfiable: <string>
|
||||
labelSelector: <object>
|
||||
matchLabelKeys: <list> # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
|
||||
nodeAffinityPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
|
||||
nodeTaintsPolicy: [Honor|Ignore] # 선택 사항이며, v1.25에서 알파 기능으로 도입되었다.
|
||||
### 파드의 다른 필드가 이 아래에 오게 된다.
|
||||
```
|
||||
|
||||
`kubectl explain Pod.spec.topologySpreadConstraints` 명령을 실행하여 이 필드에 대해 좀 더 알아볼 수 있다.
|
||||
`kubectl explain Pod.spec.topologySpreadConstraints` 명령을 실행하거나 파드에 관한 API 레퍼런스의
|
||||
[스케줄링](/docs/reference/kubernetes-api/workload-resources/pod-v1/#scheduling) 섹션을 참조해서 이 필드에 대해 좀 더 알아볼 수 있다.
|
||||
|
||||
### 분배 제약 조건 정의
|
||||
|
||||
|
|
@ -81,10 +86,10 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
|
|||
|
||||
- `whenUnsatisfiable: DoNotSchedule`을 선택했다면,
|
||||
`maxSkew`는 대상 토폴로지에서 일치하는 파드 수와
|
||||
_전역 최솟값(global minimum)_ (토폴로지 도메인에서 레이블 셀렉터와 일치하는 최소 파드 수)
|
||||
_전역 최솟값(global minimum)_ (적절한 도메인 내에서 일치하는 파드의 최소 수, 또는 적절한 도메인의 수가 `minDomains`보다 작은 경우에는 0)
|
||||
사이의 최대 허용 차이를 나타낸다.
|
||||
예를 들어, 3개의 존에 각각 2, 4, 5개의 일치하는 파드가 있으면,
|
||||
전역 최솟값은 2이며 시스템은 이 숫자를 `maxSkew`와 비교한다.
|
||||
예를 들어, 3개의 존에 각각 2, 2, 1개의 일치하는 파드가 있으면,
|
||||
`maxSkew`는 1로 설정되고 전역 최솟값은 1로 설정된다.
|
||||
- `whenUnsatisfiable: ScheduleAnyway`를 선택하면,
|
||||
스케줄러는 차이(skew)를 줄이는 데 도움이 되는 토폴로지에 더 높은 우선 순위를 부여한다.
|
||||
|
||||
|
|
@ -93,9 +98,8 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
|
|||
도메인의 노드가 노드 셀렉터에 매치되면 그 도메인은 적합한 도메인이다.
|
||||
|
||||
{{< note >}}
|
||||
`minDomains` 필드는 1.24에서 추가된 알파 필드이다.
|
||||
이를 사용하려면 `MinDomainsInPodToplogySpread`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
|
||||
`minDomains` 필드는 1.25에서 기본적으로 사용하도록 설정된 베타 필드이다. 사용을 원하지 않을 경우
|
||||
`MinDomainsInPodToplogySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화한다.
|
||||
{{< /note >}}
|
||||
|
||||
- `minDomains` 값을 명시하는 경우, 이 값은 0보다 커야 한다.
|
||||
|
|
@ -108,10 +112,12 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
|
|||
이 값은 스케줄링에 영향을 미치지 않는다.
|
||||
- `minDomains`를 명시하지 않으면, 분배 제약 조건은 `minDomains`가 1이라고 가정하고 동작한다.
|
||||
|
||||
- **topologyKey** 는 [노드 레이블](#node-labels)의 키(key)이다.
|
||||
만약 두 노드가 이 키로 레이블이 지정되고 레이블이 동일한 값을 가진다면,
|
||||
스케줄러는 두 노드를 같은 토폴로지에 있는 것으로 여기게 된다.
|
||||
스케줄러는 각 토폴로지 도메인에 균형잡힌 수의 파드를 배치하려고 시도한다.
|
||||
- **topologyKey** 는 [노드 레이블](#node-labels)의 키(key)이다. 이 키와 동일한 값을 가진
|
||||
레이블이 있는 노드는 동일한 토폴로지에 있는 것으로 간주된다.
|
||||
토폴로지의 각 인스턴스(즉, <키, 값> 쌍)를 도메인이라고 한다. 스케줄러는
|
||||
각 도메인에 균형잡힌 수의 파드를 배치하려고 시도할 것이다.
|
||||
또한, 노드가 nodeAffinityPolicy 및 nodeTaintsPolicy의 요구 사항을 충족하는 도메인을
|
||||
적절한 도메인이라고 정의한다.
|
||||
|
||||
- **whenUnsatisfiable** 는 분산 제약 조건을 만족하지 않을 경우에 파드를 처리하는 방법을 나타낸다.
|
||||
- `DoNotSchedule`(기본값)은 스케줄러에 스케줄링을 하지 말라고 알려준다.
|
||||
|
|
@ -123,6 +129,54 @@ kube-scheduler가 어떻게 클러스터 내에서 기존 파드와의 관계를
|
|||
자세한 내용은
|
||||
[레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터)를 참조한다.
|
||||
|
||||
- **matchLabelKeys** 는 분배도(spreading)가 계산될 파드를 선택하기 위한 파드 레이블
|
||||
키 목록이다. 키는 파드 레이블에서 값을 조회하는 데 사용되며, 이러한 키-값 레이블은 `labelSelector`와 AND 처리되어 들어오는 파드(incoming pod)에 대해 분배도가 계산될 기존 파드 그룹의 선택에 사용된다. 파드 레이블에 없는 키는 무시된다. null 또는 비어 있는 목록은 `labelSelector`와만 일치함을 의미한다.
|
||||
|
||||
`matchLabelKeys`를 사용하면, 사용자는 다른 리비전 간에 `pod.spec`을 업데이트할 필요가 없다. 컨트롤러/오퍼레이터는 다른 리비전에 대해 동일한 `label`키에 다른 값을 설정하기만 하면 된다. 스케줄러는 `matchLabelKeys`를 기준으로 값을 자동으로 가정할 것이다. 예를 들어 사용자가 디플로이먼트를 사용하는 경우, 디플로이먼트 컨트롤러에 의해 자동으로 추가되는 `pod-template-hash`로 키가 지정된 레이블을 사용함으로써 단일 디플로이먼트에서 서로 다른 리비전을 구별할 수 있다.
|
||||
|
||||
```yaml
|
||||
topologySpreadConstraints:
|
||||
- maxSkew: 1
|
||||
topologyKey: kubernetes.io/hostname
|
||||
whenUnsatisfiable: DoNotSchedule
|
||||
matchLabelKeys:
|
||||
- app
|
||||
- pod-template-hash
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
`matchLabelKeys` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면
|
||||
`MatchLabelKeysInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
를 활성화시켜야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
- **nodeAffinityPolicy**는 파드 토폴로지의 스프레드 스큐(spread skew)를 계산할 때
|
||||
파드의 nodeAffinity/nodeSelector를 다루는 방법을 나타낸다. 옵션은 다음과 같다.
|
||||
- Honor: nodeAffinity/nodeSelector와 일치하는 노드만 계산에 포함된다.
|
||||
- Ignore: nodeAffinity/nodeSelector는 무시된다. 모든 노드가 계산에 포함된다.
|
||||
|
||||
옵션의 값이 null일 경우, Honor 정책과 동일하게 동작한다.
|
||||
|
||||
{{< note >}}
|
||||
`nodeAffinityPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면
|
||||
`NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
를 활성화시켜야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
- **nodeTaintsPolicy**는 파드 토폴로지의 스프레드 스큐(spread skew)를 계산할 때 노드 테인트(taint)를
|
||||
다루는 방법을 나타낸다. 옵션은 다음과 같다.
|
||||
- Honor: 테인트가 없는 노드, 그리고 노드가 톨러레이션이 있는 들어오는 파드(incoming pod)를 위한 테인트가 설정된
|
||||
노드가 포함된다.
|
||||
- Ignore: 노드 테인트는 무시된다. 모든 노드가 포함된다.
|
||||
|
||||
옵션의 값이 null일 경우, Ignore 정책과 동일하게 동작한다.
|
||||
|
||||
{{< note >}}
|
||||
`nodeTaintsPolicy` 필드는 1.25에서 추가된 알파 필드이다. 이 필드를 사용하려면
|
||||
`NodeInclusionPolicyInPodTopologySpread` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
|
||||
를 활성화시켜야 한다.
|
||||
{{< /note >}}
|
||||
|
||||
파드에 2개 이상의 `topologySpreadConstraint`가 정의되어 있으면,
|
||||
각 제약 조건은 논리 AND 연산으로 조합되며,
|
||||
kube-scheduler는 새로운 파드의 모든 제약 조건을 만족하는 노드를 찾는다.
|
||||
|
|
@ -557,6 +611,7 @@ profiles:
|
|||
예를 들어 노드 풀(또는 노드 그룹)이 0으로 스케일 다운되고,
|
||||
클러스터가 다시 스케일 업 되기를 기대하는 경우,
|
||||
해당 토폴로지 도메인은 적어도 1개의 노드가 존재하기 전에는 고려가 되지 않을 것이다.
|
||||
|
||||
이를 극복하기 위해, 파드 토폴로지 분배 제약 조건과
|
||||
전반적인 토폴로지 도메인 집합에 대한 정보를 인지하고 동작하는
|
||||
클러스터 오토스케일링 도구를 이용할 수 있다.
|
||||
|
|
|
|||
|
|
@ -58,6 +58,7 @@ IaaS 공급자 | 링크 |
|
|||
Alibaba Cloud | https://www.alibabacloud.com/trust-center |
|
||||
Amazon Web Services | https://aws.amazon.com/security/ |
|
||||
Google Cloud Platform | https://cloud.google.com/security/ |
|
||||
Huawei Cloud | https://www.huaweicloud.com/securecenter/overallsafety.html |
|
||||
IBM Cloud | https://www.ibm.com/cloud/security |
|
||||
Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
|
||||
Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
# reviewers:
|
||||
# - pweil-
|
||||
# - liggitt
|
||||
# - tallclair
|
||||
title: 파드 시큐리티 폴리시
|
||||
content_type: concept
|
||||
|
|
@ -11,770 +11,19 @@ weight: 30
|
|||
|
||||
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
|
||||
|
||||
{{< caution >}}
|
||||
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 v1.21부터 더 이상 사용되지 않으며, **v1.25에서 제거될 예정**이다.
|
||||
[파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/) 혹은 써드파티 어드미션 플러그인으로 대체하는 것을 권장한다.
|
||||
상세 가이드는 [파드시큐리티폴리시를 파드 시큐리티 어드미션 컨트롤러로 대체하기](/docs/tasks/configure-pod-container/migrate-from-psp/)를 참조한다.
|
||||
사용 중단에 대한 상세 사항은
|
||||
[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
|
||||
{{< /caution >}}
|
||||
|
||||
파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을
|
||||
부여할 수 있다.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 파드 시큐리티 폴리시란?
|
||||
|
||||
_Pod Security Policy_ 는 파드 명세의 보안 관련 측면을 제어하는 클러스터-레벨의
|
||||
리소스이다.
|
||||
[파드시큐리티폴리시](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 오브젝트는
|
||||
관련 필드에 대한 기본값뿐만 아니라 시스템에 적용하기 위해 파드가 실행해야만 하는
|
||||
조건 셋을 정의한다.
|
||||
관리자는 다음을 제어할 수 있다.
|
||||
|
||||
| 제어 측면 | 필드 이름 |
|
||||
| ----------------------------------------------------| ------------------------------------------- |
|
||||
| 특권을 가진(privileged) 컨테이너의 실행 | [`privileged`](#특권을-가진) |
|
||||
| 호스트 네임스페이스의 사용 | [`hostPID`, `hostIPC`](#호스트-네임스페이스) |
|
||||
| 호스트 네트워킹과 포트의 사용 | [`hostNetwork`, `hostPorts`](#호스트-네임스페이스) |
|
||||
| 볼륨 유형의 사용 | [`volumes`](#볼륨-및-파일시스템) |
|
||||
| 호스트 파일시스템의 사용 | [`allowedHostPaths`](#볼륨-및-파일시스템) |
|
||||
| 특정 FlexVolume 드라이버의 허용 | [`allowedFlexVolumes`](#flexvolume-드라이버) |
|
||||
| 파드 볼륨을 소유한 FSGroup 할당 | [`fsGroup`](#볼륨-및-파일시스템) |
|
||||
| 읽기 전용 루트 파일시스템 사용 필요 | [`readOnlyRootFilesystem`](#볼륨-및-파일시스템) |
|
||||
| 컨테이너의 사용자 및 그룹 ID | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#사용자-및-그룹) |
|
||||
| 루트 특권으로의 에스컬레이션 제한 | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#권한-에스컬레이션) |
|
||||
| 리눅스 기능 | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#기능) |
|
||||
| 컨테이너의 SELinux 컨텍스트 | [`seLinux`](#selinux) |
|
||||
| 컨테이너에 허용된 Proc 마운트 유형 | [`allowedProcMountTypes`](#allowedprocmounttypes) |
|
||||
| 컨테이너가 사용하는 AppArmor 프로파일 | [어노테이션](#apparmor) |
|
||||
| 컨테이너가 사용하는 seccomp 프로파일 | [어노테이션](#seccomp) |
|
||||
| 컨테이너가 사용하는 sysctl 프로파일 | [`forbiddenSysctls`,`allowedUnsafeSysctls`](#sysctl) |
|
||||
|
||||
|
||||
## 파드 시큐리티 폴리시 활성화
|
||||
|
||||
파드 시큐리티 폴리시 제어는 선택 사항인 [어드미션
|
||||
컨트롤러](/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)로 구현된다.
|
||||
[어드미션 컨트롤러를 활성화](/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)하면
|
||||
파드시큐리티폴리시가 적용되지만,
|
||||
정책을 승인하지 않고 활성화하면 클러스터에
|
||||
**파드가 생성되지 않는다.**
|
||||
|
||||
파드 시큐리티 폴리시 API(`policy/v1beta1/podsecuritypolicy`)는
|
||||
어드미션 컨트롤러와 독립적으로 활성화되므로 기존 클러스터의 경우
|
||||
어드미션 컨트롤러를 활성화하기 전에 정책을 추가하고 권한을
|
||||
부여하는 것이 좋다.
|
||||
|
||||
## 정책 승인
|
||||
|
||||
파드시큐리티폴리시 리소스가 생성되면 아무 것도 수행하지 않는다. 이를 사용하려면
|
||||
요청 사용자 또는 대상 파드의
|
||||
[서비스 어카운트](/docs/tasks/configure-pod-container/configure-service-account/)는
|
||||
정책에서 `use` 동사를 허용하여 정책을 사용할 권한이 있어야 한다.
|
||||
|
||||
대부분의 쿠버네티스 파드는 사용자가 직접 만들지 않는다. 대신 일반적으로
|
||||
컨트롤러 관리자를 통해
|
||||
[디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/),
|
||||
[레플리카셋](/ko/docs/concepts/workloads/controllers/replicaset/), 또는 기타
|
||||
템플릿 컨트롤러의 일부로 간접적으로 생성된다. 컨트롤러에 정책에 대한 접근 권한을 부여하면
|
||||
해당 컨트롤러에 의해 생성된 *모든* 파드에 대한 접근 권한이 부여되므로 정책을 승인하는
|
||||
기본 방법은 파드의 서비스 어카운트에 대한 접근 권한을
|
||||
부여하는 것이다([예](#다른-파드를-실행) 참고).
|
||||
|
||||
### RBAC을 통한 방법
|
||||
|
||||
[RBAC](/docs/reference/access-authn-authz/rbac/)은 표준 쿠버네티스 권한 부여 모드이며,
|
||||
정책 사용 권한을 부여하는 데 쉽게 사용할 수 있다.
|
||||
|
||||
먼저, `Role` 또는 `ClusterRole`은 원하는 정책을 `use` 하려면 접근 권한을 부여해야 한다.
|
||||
접근 권한을 부여하는 규칙은 다음과 같다.
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRole
|
||||
metadata:
|
||||
name: <role name>
|
||||
rules:
|
||||
- apiGroups: ['policy']
|
||||
resources: ['podsecuritypolicies']
|
||||
verbs: ['use']
|
||||
resourceNames:
|
||||
- <list of policies to authorize>
|
||||
```
|
||||
|
||||
그런 다음 `(Cluster)Role`이 승인된 사용자에게 바인딩된다.
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: <binding name>
|
||||
roleRef:
|
||||
kind: ClusterRole
|
||||
name: <role name>
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
subjects:
|
||||
# 네임스페이스의 모든 서비스 어카운트 승인(권장):
|
||||
- kind: Group
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
name: system:serviceaccounts:<authorized namespace>
|
||||
# 특정 서비스 어카운트 승인(권장하지 않음):
|
||||
- kind: ServiceAccount
|
||||
name: <authorized service account name>
|
||||
namespace: <authorized pod namespace>
|
||||
# 특정 사용자 승인(권장하지 않음):
|
||||
- kind: User
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
name: <authorized user name>
|
||||
```
|
||||
|
||||
`RoleBinding`(`ClusterRoleBinding` 아님)을 사용하는 경우, 바인딩과 동일한 네임스페이스에서
|
||||
실행되는 파드에 대해서만 사용 권한을 부여한다. 네임스페이스에서 실행되는 모든 파드에 접근 권한을
|
||||
부여하기 위해 시스템 그룹과 쌍을 이룰 수 있다.
|
||||
```yaml
|
||||
# 네임스페이스의 모든 서비스 어카운트 승인:
|
||||
- kind: Group
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
name: system:serviceaccounts
|
||||
# 또는 동일하게, 네임스페이스의 모든 승인된 사용자에게 사용 권한 부여
|
||||
- kind: Group
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
name: system:authenticated
|
||||
```
|
||||
|
||||
RBAC 바인딩에 대한 자세한 예는,
|
||||
[역할 바인딩 예제](/docs/reference/access-authn-authz/rbac#role-binding-examples)를 참고한다.
|
||||
파드시큐리티폴리시 인증에 대한 전체 예제는
|
||||
[아래](#예제)를 참고한다.
|
||||
|
||||
### 추천 예제
|
||||
|
||||
파드시큐리티폴리시는 새롭고 간결해진 `PodSecurity` {{< glossary_tooltip
|
||||
text="어드미션 컨트롤러" term_id="admission-controller" >}}로 대체되고 있다.
|
||||
이 변경에 대한 상세사항은
|
||||
[파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참조한다.
|
||||
다음 가이드라인을 참조하여 파드시큐리티폴리시를
|
||||
새로운 어드미션 컨트롤러로 쉽게 전환할 수 있다.
|
||||
|
||||
1. 파드시큐리티폴리시를
|
||||
[파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)에 의해 정의된 폴리시로 한정한다.
|
||||
|
||||
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
|
||||
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
|
||||
- {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
|
||||
|
||||
1. `system:serviceaccounts:<namespace>` (여기서 `<namespace>`는 타겟 네임스페이스) 그룹을 사용하여
|
||||
파드시큐리티폴리시를 전체 네임스페이스에만 바인드한다. 예시는 다음과 같다.
|
||||
|
||||
```yaml
|
||||
apiVersion: rbac.authorization.k8s.io/v1
|
||||
# 이 클러스터롤바인딩(ClusterRoleBinding)을 통해 "development" 네임스페이스의 모든 파드가 기준 파드시큐리티폴리시(PSP)를 사용할 수 있다.
|
||||
kind: ClusterRoleBinding
|
||||
metadata:
|
||||
name: psp-baseline-namespaces
|
||||
roleRef:
|
||||
kind: ClusterRole
|
||||
name: psp-baseline
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
subjects:
|
||||
- kind: Group
|
||||
name: system:serviceaccounts:development
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
- kind: Group
|
||||
name: system:serviceaccounts:canary
|
||||
apiGroup: rbac.authorization.k8s.io
|
||||
```
|
||||
|
||||
### 문제 해결
|
||||
|
||||
- [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)는
|
||||
보안 API 포트에 대해 실행되어야 하며 수퍼유저 권한이 없어야 한다.
|
||||
API 서버 접근 제어에 대한 자세한 내용은
|
||||
[쿠버네티스 API에 대한 접근 제어](/ko/docs/concepts/security/controlling-access)를 참고하길 바란다.
|
||||
컨트롤러 관리자가 신뢰할 수 있는 API 포트(`localhost` 리스너라고도 함)를
|
||||
통해 연결된 경우, 요청이 인증 및 권한 부여 모듈을 우회하고,
|
||||
모든 파드시큐리티폴리시 오브젝트가 허용되며 사용자는 특권을 가진 컨테이너를
|
||||
만들 수 있는 권한을 부여할 수 있다.
|
||||
|
||||
컨트롤러 관리자 권한 구성에 대한 자세한 내용은
|
||||
[컨트롤러 역할](/docs/reference/access-authn-authz/rbac/#controller-roles)을 참고한다.
|
||||
|
||||
## 정책 순서
|
||||
|
||||
파드 생성 및 업데이트를 제한할 뿐만 아니라 파드 시큐리티 폴리시를 사용하여
|
||||
제어하는 많은 필드에 기본값을 제공할 수도 있다. 여러 정책을
|
||||
사용할 수 있는 경우 파드 시큐리티 폴리시 컨트롤러는
|
||||
다음 기준에 따라 정책을 선택한다.
|
||||
|
||||
1. 기본 설정을 변경하거나 파드를 변경하지 않고 파드를 있는 그대로 허용하는 파드시큐리티폴리시가
|
||||
선호된다. 이러한 비-변이(non-mutating) 파드시큐리티폴리시의
|
||||
순서는 중요하지 않다.
|
||||
2. 파드를 기본값으로 설정하거나 변경해야 하는 경우, 파드를 허용할 첫 번째 파드시큐리티폴리시
|
||||
(이름순)가 선택된다.
|
||||
|
||||
파드시큐리티폴리시에 대해 파드의 유효성이 검증되면,
|
||||
파드시큐리티폴리시의 이름을 어노테이션 값으로 사용하는 [`kubernetes.io/psp` 어노테이션]이 파드에 추가된다.
|
||||
|
||||
{{< note >}}
|
||||
업데이트 작업 중(파드 스펙에 대한 변경이 허용되지 않는 동안) 비-변이 파드시큐리티폴리시만
|
||||
파드의 유효성을 검사하는 데 사용된다.
|
||||
파드시큐리티폴리시(PodSecurityPolicy)는 쿠버네티스 1.21 버전부터 [사용 중단(deprecated)](/blog/2021/04/08/kubernetes-1-21-release-announcement/#podsecuritypolicy-deprecation)되었으며,
|
||||
v1.25 버전 때 쿠버네티스에서 제거되었다.
|
||||
파드시큐리티폴리시를 사용하는 것 대신, 다음 중 하나를 사용하거나 둘 다 사용하여 파드에 유사한 제한을
|
||||
적용할 수 있다.
|
||||
|
||||
- [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
|
||||
- 직접 배포하고 구성할 수 있는 서드파티 어드미션 플러그인
|
||||
|
||||
마이그레이션에 관한 설명이 필요하다면 [파드시큐리티폴리시(PodSecurityPolicy)에서 빌트인 파드시큐리티어드미션컨트롤러(PodSecurity Admission Controller)로 마이그레이션](/docs/tasks/configure-pod-container/migrate-from-psp/)을 참고한다.
|
||||
이 API 제거에 대해 더 많은 정보가 필요하다면,
|
||||
[파드시큐리티폴리시(PodSecurityPolicy) 사용 중단: 과거, 현재, 미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)를 참고한다.
|
||||
|
||||
쿠버네티스 v{{< skew currentVersion >}} 이외의 버전을 실행 중이라면,
|
||||
해당 쿠버네티스 버전에 대한 문서를 확인한다.
|
||||
{{< /note >}}
|
||||
|
||||
## 예제
|
||||
|
||||
_이 예에서는 파드시큐리티폴리시 어드미션 컨트롤러가 활성화된 클러스터가 실행 중이고
|
||||
클러스터 관리자 권한이 있다고 가정한다._
|
||||
|
||||
### 설정
|
||||
|
||||
이 예제와 같이 네임스페이스와 서비스 어카운트를 설정한다.
|
||||
이 서비스 어카운트를 사용하여 관리자가 아닌 사용자를 조정한다.
|
||||
|
||||
```shell
|
||||
kubectl create namespace psp-example
|
||||
kubectl create serviceaccount -n psp-example fake-user
|
||||
kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user
|
||||
```
|
||||
|
||||
어떤 사용자로 활동하고 있는지 명확하게 하고 입력 내용을 저장하려면 2개의 별칭(alias)을
|
||||
만든다.
|
||||
|
||||
```shell
|
||||
alias kubectl-admin='kubectl -n psp-example'
|
||||
alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example'
|
||||
```
|
||||
|
||||
### 정책과 파드 생성
|
||||
|
||||
이는 특권있는 파드를 만들지 못하게 하는 정책이다.
|
||||
파드시큐리티폴리시 오브젝트의 이름은 유효한
|
||||
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names#dns-서브도메인-이름)이어야 한다.
|
||||
|
||||
{{< codenew file="policy/example-psp.yaml" >}}
|
||||
|
||||
그리고 kubectl로 생성한다.
|
||||
|
||||
```shell
|
||||
kubectl-admin create -f https://k8s.io/examples/policy/example-psp.yaml
|
||||
```
|
||||
|
||||
이제 권한이 없는 사용자로서 간단한 파드를 생성해보자.
|
||||
|
||||
```shell
|
||||
kubectl-user create -f- <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pause
|
||||
spec:
|
||||
containers:
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause
|
||||
EOF
|
||||
```
|
||||
|
||||
이것의 출력은 다음과 같을 것이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []
|
||||
```
|
||||
|
||||
**무슨 일이 일어났나?** 파드시큐리티폴리시가 생성되었지만, 파드의 서비스 어카운트나 `fake-user`는
|
||||
새 정책을 사용할 권한이 없다.
|
||||
|
||||
```shell
|
||||
kubectl-user auth can-i use podsecuritypolicy/example
|
||||
```
|
||||
|
||||
결과는 다음과 같다:
|
||||
|
||||
```
|
||||
no
|
||||
```
|
||||
|
||||
예제 정책에서 `fake-user`에게 `use` 동사를 부여하는 rolebinding을
|
||||
생성한다.
|
||||
|
||||
{{< note >}}
|
||||
이 방법은 권장하지 않는다! 선호하는 방법은 [다음 절](#다른-파드를-실행)을
|
||||
참고하길 바란다.
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
kubectl-admin create role psp:unprivileged \
|
||||
--verb=use \
|
||||
--resource=podsecuritypolicy \
|
||||
--resource-name=example
|
||||
```
|
||||
|
||||
```
|
||||
role "psp:unprivileged" created
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl-admin create rolebinding fake-user:psp:unprivileged \
|
||||
--role=psp:unprivileged \
|
||||
--serviceaccount=psp-example:fake-user
|
||||
```
|
||||
|
||||
```
|
||||
rolebinding "fake-user:psp:unprivileged" created
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl-user auth can-i use podsecuritypolicy/example
|
||||
```
|
||||
|
||||
```
|
||||
yes
|
||||
```
|
||||
|
||||
이제 파드 생성을 다시 시도하자.
|
||||
|
||||
```shell
|
||||
kubectl-user create -f- <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: pause
|
||||
spec:
|
||||
containers:
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause
|
||||
EOF
|
||||
```
|
||||
|
||||
이것의 출력은 다음과 같을 것이다.
|
||||
|
||||
```
|
||||
pod "pause" created
|
||||
```
|
||||
|
||||
예상대로 작동한다!
|
||||
새로 생성된 파드시큐리티폴리시에 대해서도 파드가 유효한지 검증한다:
|
||||
|
||||
```shell
|
||||
kubectl-user get pod pause -o yaml | grep kubernetes.io/psp
|
||||
```
|
||||
|
||||
결과는 다음과 같다:
|
||||
|
||||
```
|
||||
kubernetes.io/psp: example
|
||||
```
|
||||
|
||||
그러나 특권있는 파드를 만들려는 시도는 여전히
|
||||
거부되어야 한다.
|
||||
|
||||
```shell
|
||||
kubectl-user create -f- <<EOF
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: privileged
|
||||
spec:
|
||||
containers:
|
||||
- name: pause
|
||||
image: k8s.gcr.io/pause
|
||||
securityContext:
|
||||
privileged: true
|
||||
EOF
|
||||
```
|
||||
|
||||
이것의 출력은 다음과 같을 것이다.
|
||||
|
||||
```
|
||||
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
|
||||
```
|
||||
|
||||
계속 진행하기 전에 파드를 삭제하자.
|
||||
|
||||
```shell
|
||||
kubectl-user delete pod pause
|
||||
```
|
||||
|
||||
### 다른 파드를 실행
|
||||
|
||||
약간 다르게 다시 시도해보자.
|
||||
|
||||
```shell
|
||||
kubectl-user create deployment pause --image=k8s.gcr.io/pause
|
||||
```
|
||||
|
||||
```none
|
||||
deployment "pause" created
|
||||
```
|
||||
```shell
|
||||
kubectl-user get pods
|
||||
```
|
||||
|
||||
```
|
||||
No resources found.
|
||||
```
|
||||
|
||||
```shell
|
||||
kubectl-user get events | head -n 2
|
||||
```
|
||||
|
||||
```
|
||||
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
|
||||
1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request
|
||||
```
|
||||
|
||||
**무슨 일이 일어났나?** 우리는 이미 `fake-user`에 대해 `psp:unprivileged` 역할을 바인딩했는데,
|
||||
`Error creating: pods "pause-7774d79b5-" is
|
||||
forbidden: no providers available to validate pod request` 오류가
|
||||
발생하는 이유는 무엇인가? 그 답은 소스인 `replicaset-controller`에 있다. Fake-user가
|
||||
디플로이먼트를 성공적으로 생성했지만(레플리카셋을 성공적으로 생성했음), 레플리카셋이
|
||||
파드를 생성했을 때 podsecuritypolicy 예제를
|
||||
사용할 권한이 없었다.
|
||||
|
||||
이 문제를 해결하려면 `psp:unprivileged` 역할을 파드의 서비스 어카운트에 대신
|
||||
바인딩한다. 이 경우(지정하지 않았으므로) 서비스 어카운트는
|
||||
`default`이다.
|
||||
|
||||
```shell
|
||||
kubectl-admin create rolebinding default:psp:unprivileged \
|
||||
--role=psp:unprivileged \
|
||||
--serviceaccount=psp-example:default
|
||||
```
|
||||
|
||||
```none
|
||||
rolebinding "default:psp:unprivileged" created
|
||||
```
|
||||
|
||||
이제 다시 한번 해본다면 replicaset-controller가
|
||||
파드를 성공적으로 생성할 것이다.
|
||||
|
||||
```shell
|
||||
kubectl-user get pods --watch
|
||||
```
|
||||
|
||||
```none
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
|
||||
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
|
||||
pause-7774d79b5-qrgcb 0/1 ContainerCreating 0 1s
|
||||
pause-7774d79b5-qrgcb 1/1 Running 0 2s
|
||||
```
|
||||
|
||||
### 정리
|
||||
|
||||
네임스페이스를 삭제하여 대부분의 예제 리소스를 정리한다.
|
||||
|
||||
```shell
|
||||
kubectl-admin delete ns psp-example
|
||||
```
|
||||
|
||||
```
|
||||
namespace "psp-example" deleted
|
||||
```
|
||||
|
||||
`PodSecurityPolicy` 리소스는 네임스페이스에 포함되지 않으므로 별도로
|
||||
정리해야 한다.
|
||||
|
||||
```shell
|
||||
kubectl-admin delete psp example
|
||||
```
|
||||
|
||||
```
|
||||
podsecuritypolicy "example" deleted
|
||||
```
|
||||
|
||||
### 정책 예제
|
||||
|
||||
다음은 파드 시큐리티 폴리시 어드미션 컨트롤러를 사용하지 않는 것과 동일하게 만들 수 있는
|
||||
최소한의 제한 정책이다.
|
||||
|
||||
{{< codenew file="policy/privileged-psp.yaml" >}}
|
||||
|
||||
다음은 권한이 없는 사용자로서의 실행을 필요로 하고, 루트로의 에스컬레이션(escalation) 가능성을 차단하고,
|
||||
여러 보안 메커니즘을 사용을 필요로 하는 제한적
|
||||
정책의 예제이다.
|
||||
|
||||
{{< codenew file="policy/restricted-psp.yaml" >}}
|
||||
|
||||
더 많은 예제는
|
||||
[파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/#정책-초기화)을 본다.
|
||||
|
||||
## 정책 레퍼런스
|
||||
|
||||
### 특권을 가진
|
||||
|
||||
**Privileged** - 파드의 컨테이너가 특권 모드를 사용할 수 있는지 여부를 결정한다.
|
||||
기본적으로 컨테이너는 호스트의 모든 장치에 접근할 수 없지만
|
||||
"특권을 가진" 컨테이너는 호스트의 모든 장치에 접근할 수 있다. 이것은
|
||||
컨테이너가 호스트에서 실행되는 프로세스와 거의 동일한 접근을 허용한다.
|
||||
이것은 네트워크 스택 조작 및 장치 접근과 같은
|
||||
리눅스 기능을 사용하려는 컨테이너에 유용하다.
|
||||
|
||||
### 호스트 네임스페이스
|
||||
|
||||
**HostPID** - 파드 컨테이너가 호스트 프로세스 ID 네임스페이스를 공유할 수 있는지 여부를
|
||||
제어한다. ptrace와 함께 사용하면 컨테이너 외부로 권한을 에스컬레이션하는 데 사용할 수
|
||||
있다(ptrace는 기본적으로 금지되어 있음).
|
||||
|
||||
**HostIPC** - 파드 컨테이너가 호스트 IPC 네임스페이스를 공유할 수 있는지 여부를
|
||||
제어한다.
|
||||
|
||||
**HostNetwork** - 파드가 노드 네트워크 네임스페이스를 사용할 수 있는지 여부를 제어한다.
|
||||
이렇게 하면 파드에 루프백 장치에 접근 권한을 주고, 서비스는 로컬호스트(localhost)를 리스닝할 수 있으며,
|
||||
동일한 노드에 있는 다른 파드의 네트워크 활동을 스누핑(snoop)하는 데
|
||||
사용할 수 있다.
|
||||
|
||||
**HostPorts** - 호스트 네트워크 네임스페이스에 허용되는 포트 범위의 목록을
|
||||
제공한다. `min`과 `max`를 포함하여 `HostPortRange`의 목록으로 정의된다.
|
||||
기본값은 허용하는 호스트 포트 없음(no allowed host ports)이다.
|
||||
|
||||
### 볼륨 및 파일시스템
|
||||
|
||||
**Volumes** - 허용되는 볼륨 유형의 목록을 제공한다. 허용 가능한 값은
|
||||
볼륨을 생성할 때 정의된 볼륨 소스에 따른다. 볼륨 유형의 전체 목록은
|
||||
[볼륨 유형들](/ko/docs/concepts/storage/volumes/#볼륨-유형들)에서 참고한다.
|
||||
또한 `*`를 사용하여 모든 볼륨 유형을
|
||||
허용할 수 있다.
|
||||
|
||||
새 PSP에 허용되는 볼륨의 **최소 권장 셋** 은 다음과 같다.
|
||||
|
||||
- 컨피그맵
|
||||
- 다운워드API
|
||||
- emptyDir
|
||||
- 퍼시스턴트볼륨클레임
|
||||
- 시크릿
|
||||
- 프로젝티드(projected)
|
||||
|
||||
{{< warning >}}
|
||||
파드시큐리티폴리시는 `PersistentVolumeClaim`이 참조할 수 있는 `PersistentVolume`
|
||||
오브젝트의 유형을 제한하지 않으며 hostPath 유형
|
||||
`PersistentVolumes`은 읽기-전용 접근 모드를 지원하지 않는다. 신뢰할 수 있는 사용자만
|
||||
`PersistentVolume` 오브젝트를 생성할 수 있는 권한을 부여 받아야 한다.
|
||||
{{< /warning >}}
|
||||
|
||||
**FSGroup** - 일부 볼륨에 적용되는 보충 그룹(supplemental group)을 제어한다.
|
||||
|
||||
- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을
|
||||
기본값으로 사용한다. 모든 범위에 대해 검증한다.
|
||||
- *MayRunAs* - 하나 이상의 `range`를 지정해야 한다. 기본값을 제공하지 않고
|
||||
`FSGroups`을 설정하지 않은 상태로 둘 수 있다. `FSGroups`이 설정된 경우 모든 범위에 대해
|
||||
유효성을 검사한다.
|
||||
- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `fsGroup` ID의 지정도 허용한다.
|
||||
|
||||
**AllowedHostPaths** - hostPath 볼륨에서 사용할 수 있는 호스트 경로의 목록을
|
||||
지정한다. 빈 목록은 사용되는 호스트 경로에 제한이 없음을 의미한다.
|
||||
이는 단일 `pathPrefix` 필드가 있는 오브젝트 목록으로 정의되며, hostPath 볼륨은
|
||||
허용된 접두사로 시작하는 경로를 마운트할 수 있으며 `readOnly` 필드는
|
||||
읽기-전용으로 마운트 되어야 함을 나타낸다.
|
||||
예를 들면 다음과 같습니다.
|
||||
|
||||
```yaml
|
||||
allowedHostPaths:
|
||||
# 이 정책은 "/foo", "/foo/", "/foo/bar" 등을 허용하지만,
|
||||
# "/fool", "/etc/foo" 등은 허용하지 않는다.
|
||||
# "/foo/../" 는 절대 유효하지 않다.
|
||||
- pathPrefix: "/foo"
|
||||
readOnly: true # 읽기 전용 마운트만 허용
|
||||
```
|
||||
|
||||
{{< warning >}}
|
||||
호스트 파일시스템에 제한없는 접근을 부여하며, 컨테이너가 특권을 에스컬레이션
|
||||
(다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할
|
||||
수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다.
|
||||
|
||||
쓰기 가능한 hostPath 디렉터리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의
|
||||
호스트 파일시스템에 대한 통행을 허용하는 방식으로 컨테이너의 파일시스템 쓰기(write)를 허용한다.
|
||||
쿠버네티스 1.11 이상 버전에서 사용 가능한 `readOnly: true`는 지정된 `pathPrefix`에 대한
|
||||
접근을 효과적으로 제한하기 위해 **모든** `allowedHostPaths`에서 사용해야 한다.
|
||||
{{< /warning >}}
|
||||
|
||||
**ReadOnlyRootFilesystem** - 컨테이너는 읽기-전용 루트 파일시스템(즉, 쓰기 가능한 레이어 없음)으로
|
||||
실행해야 한다.
|
||||
|
||||
### FlexVolume 드라이버
|
||||
|
||||
flexvolume에서 사용할 수 있는 FlexVolume 드라이버의 목록을 지정한다.
|
||||
빈 목록 또는 nil은 드라이버에 제한이 없음을 의미한다.
|
||||
[`volumes`](#볼륨-및-파일시스템) 필드에 `flexVolume` 볼륨 유형이 포함되어
|
||||
있는지 확인한다. 그렇지 않으면 FlexVolume 드라이버가 허용되지 않는다.
|
||||
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
```yaml
|
||||
apiVersion: policy/v1beta1
|
||||
kind: PodSecurityPolicy
|
||||
metadata:
|
||||
name: allow-flex-volumes
|
||||
spec:
|
||||
# ... 다른 스펙 필드
|
||||
volumes:
|
||||
- flexVolume
|
||||
allowedFlexVolumes:
|
||||
- driver: example/lvm
|
||||
- driver: example/cifs
|
||||
```
|
||||
|
||||
### 사용자 및 그룹
|
||||
|
||||
**RunAsUser** - 컨테이너를 실행할 사용자 ID를 제어힌다.
|
||||
|
||||
- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을
|
||||
기본값으로 사용한다. 모든 범위에 대해 검증한다.
|
||||
- *MustRunAsNonRoot* - 파드가 0이 아닌 `runAsUser`로 제출되거나
|
||||
이미지에 `USER` 지시문이 정의되어 있어야 한다(숫자 UID 사용). `runAsNonRoot` 또는
|
||||
`runAsUser` 설정을 지정하지 않은 파드는 `runAsNonRoot=true`를 설정하도록
|
||||
변경되므로 컨테이너에 0이 아닌 숫자가 정의된 `USER` 지시문이
|
||||
필요하다. 기본값은 제공되지 않는다.
|
||||
이 전략에서는 `allowPrivilegeEscalation=false`를 설정하는 것이 좋다.
|
||||
- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `runAsUser`의 지정도 허용한다.
|
||||
|
||||
**RunAsGroup** - 컨테이너가 실행될 기본 그룹 ID를 제어한다.
|
||||
|
||||
- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을
|
||||
기본값으로 사용한다. 모든 범위에 대해 검증한다.
|
||||
- *MayRunAs* - `RunAsGroup`을 지정할 필요가 없다. 그러나 `RunAsGroup`을 지정하면
|
||||
정의된 범위에 속해야 한다.
|
||||
- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `runAsGroup`의 지정도 허용한다.
|
||||
|
||||
|
||||
**SupplementalGroups** - 컨테이너가 추가할 그룹 ID를 제어한다.
|
||||
|
||||
- *MustRunAs* - 하나 이상의 `range`를 지정해야 한다. 첫 번째 범위의 최솟값을
|
||||
기본값으로 사용한다. 모든 범위에 대해 검증한다.
|
||||
- *MayRunAs* - 하나 이상의 `range`를 지정해야 한다. `supplementalGroups`에
|
||||
기본값을 제공하지 않고 설정하지 않은 상태로 둘 수 있다.
|
||||
`supplementalGroups`가 설정된 경우 모든 범위에 대해 유효성을 검증한다.
|
||||
- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `supplementalGroups`의 지정도
|
||||
허용한다.
|
||||
|
||||
### 권한 에스컬레이션
|
||||
|
||||
이 옵션은 `allowPrivilegeEscalation` 컨테이너 옵션을 제어한다. 이 bool은
|
||||
컨테이너 프로세스에서
|
||||
[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt)
|
||||
플래그가 설정되는지 여부를 직접 제어한다. 이 플래그는 `setuid` 바이너리가
|
||||
유효 사용자 ID를 변경하지 못하게 하고 파일에 추가 기능을 활성화하지 못하게
|
||||
한다(예: `ping` 도구 사용을 못하게 함). `MustRunAsNonRoot`를 효과적으로
|
||||
강제하려면 이 동작이 필요하다.
|
||||
|
||||
**AllowPrivilegeEscalation** - 사용자가 컨테이너의 보안 컨텍스트를
|
||||
`allowPrivilegeEscalation=true`로 설정할 수 있는지 여부를 게이트한다.
|
||||
이 기본값은 setuid 바이너리를 중단하지 않도록 허용한다. 이를 `false`로 설정하면
|
||||
컨테이너의 하위 프로세스가 상위 프로세스보다 더 많은 권한을 얻을 수 없다.
|
||||
|
||||
**DefaultAllowPrivilegeEscalation** - `allowPrivilegeEscalation` 옵션의
|
||||
기본값을 설정한다. 이것이 없는 기본 동작은 setuid 바이너리를 중단하지 않도록
|
||||
권한 에스컬레이션을 허용하는 것이다. 해당 동작이 필요하지 않은 경우 이 필드를 사용하여
|
||||
기본적으로 허용하지 않도록 설정할 수 있지만 파드는 여전히 `allowPrivilegeEscalation`을
|
||||
명시적으로 요청할 수 있다.
|
||||
|
||||
### 기능
|
||||
|
||||
리눅스 기능은 전통적으로 슈퍼유저와 관련된 권한을 보다 세밀하게 분류한다.
|
||||
이러한 기능 중 일부는 권한 에스컬레이션 또는 컨테이너 분류에 사용될 수 있으며
|
||||
파드시큐리티폴리시에 의해 제한될 수 있다. 리눅스 기능에 대한 자세한 내용은
|
||||
[기능(7)](https://man7.org/linux/man-pages/man7/capabilities.7.html)을
|
||||
참고하길 바란다.
|
||||
|
||||
다음 필드는 대문자로 표기된 기능 이름 목록을
|
||||
`CAP_` 접두사 없이 가져온다.
|
||||
|
||||
**AllowedCapabilities** - 컨테이너에 추가될 수 있는 기능의 목록을
|
||||
제공한다. 기본적인 기능 셋은 암시적으로 허용된다. 비어있는 셋은
|
||||
기본 셋을 넘어서는 추가 기능이 추가되지 않는 것을
|
||||
의미한다. `*`는 모든 기능을 허용하는 데 사용할 수 있다.
|
||||
|
||||
**RequiredDropCapabilities** - 컨테이너에서 삭제해야 하는 기능이다.
|
||||
이러한 기능은 기본 셋에서 제거되며 추가해서는 안된다.
|
||||
`RequiredDropCapabilities`에 나열된 기능은 `AllowedCapabilities` 또는
|
||||
`DefaultAddCapabilities`에 포함되지 않아야 한다.
|
||||
|
||||
**DefaultAddCapabilities** - 런타임 기본값 외에 기본적으로 컨테이너에 추가되는 기능이다.
|
||||
도커 런타임을 사용할 때 기본 기능 목록은
|
||||
[도커 문서](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)를 참고한다.
|
||||
|
||||
### SELinux
|
||||
|
||||
- *MustRunAs* - `seLinuxOptions`을 구성해야 한다.
|
||||
`seLinuxOptions`을 기본값으로 사용한다. `seLinuxOptions`에 대해 유효성을 검사한다.
|
||||
- *RunAsAny* - 기본값은 제공되지 않는다. 어떠한 `seLinuxOptions`의 지정도
|
||||
허용한다.
|
||||
|
||||
### AllowedProcMountTypes
|
||||
|
||||
`allowedProcMountTypes`는 허용된 ProcMountTypes의 목록이다.
|
||||
비어 있거나 nil은 `DefaultProcMountType`만 사용할 수 있음을 나타낸다.
|
||||
|
||||
`DefaultProcMount`는 /proc의 읽기 전용 및 마스킹(masking)된 경로에 컨테이너 런타임
|
||||
기본값을 사용한다. 대부분의 컨테이너 런타임은 특수 장치나 정보가 실수로 보안에
|
||||
노출되지 않도록 /proc의 특정 경로를 마스킹한다. 이것은 문자열
|
||||
`Default`로 표시된다.
|
||||
|
||||
유일하게 다른 ProcMountType은 `UnmaskedProcMount`로, 컨테이너 런타임의
|
||||
기본 마스킹 동작을 무시하고 새로 작성된 /proc 컨테이너가 수정없이
|
||||
그대로 유지되도록 한다. 이 문자열은
|
||||
`Unmasked`로 표시된다.
|
||||
|
||||
### AppArmor
|
||||
|
||||
파드시큐리티폴리시의 어노테이션을 통해 제어된다. [AppArmor
|
||||
문서](/ko/docs/tutorials/security/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다.
|
||||
|
||||
### Seccomp
|
||||
|
||||
쿠버네티스 v1.19부터 파드나 컨테이너의 `securityContext` 에서
|
||||
`seccompProfile` 필드를 사용하여 [seccomp 프로파일 사용을
|
||||
제어](/docs/tutorials/security/seccomp/)할 수 있다.
|
||||
이전 버전에서는, 파드에 어노테이션을 추가하여 seccomp를 제어했다.
|
||||
두 버전에서 동일한 파드시큐리티폴리시를 사용하여
|
||||
이러한 필드나 어노테이션이 적용되는 방식을 적용할 수 있다.
|
||||
|
||||
**seccomp.security.alpha.kubernetes.io/defaultProfileName** - 컨테이너에
|
||||
적용할 기본 seccomp 프로파일을 지정하는 어노테이션이다. 가능한 값은
|
||||
다음과 같다.
|
||||
|
||||
- `unconfined` - 대안이 제공되지 않으면 Seccomp가 컨테이너 프로세스에 적용되지
|
||||
않는다(쿠버네티스의 기본값임).
|
||||
- `runtime/default` - 기본 컨테이너 런타임 프로파일이 사용된다.
|
||||
- `docker/default` - 도커 기본 seccomp 프로파일이 사용된다. 쿠버네티스 1.11 부터 사용 중단(deprecated)
|
||||
되었다. 대신 `runtime/default` 사용을 권장한다.
|
||||
- `localhost/<path>` - `<seccomp_root>/<path>`에 있는 노드에서 파일을 프로파일로
|
||||
지정한다. 여기서 `<seccomp_root>`는 Kubelet의 `--seccomp-profile-root` 플래그를
|
||||
통해 정의된다. `--seccomp-profile-root` 플래그가
|
||||
정의되어 있지 않으면, `<root-dir>` 이 `--root-dir` 플래그로
|
||||
지정된 `<root-dir>/seccomp` 기본 경로가 사용된다.
|
||||
|
||||
{{< note >}}
|
||||
`--seccomp-profile-root` 플래그는 쿠버네티스 v1.19부터 더 이상 사용되지
|
||||
않는다. 사용자는 기본 경로를 사용하는 것이 좋다.
|
||||
{{< /note >}}
|
||||
|
||||
**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 파드 seccomp
|
||||
어노테이션에 허용되는 값을 지정하는 어노테이션. 쉼표로 구분된
|
||||
허용된 값의 목록으로 지정된다. 가능한 값은 위에 나열된 값과
|
||||
모든 프로파일을 허용하는 `*` 이다.
|
||||
이 주석이 없으면 기본값을 변경할 수 없다.
|
||||
|
||||
### Sysctl
|
||||
|
||||
기본적으로 모든 안전한 sysctls가 허용된다.
|
||||
|
||||
- `forbiddenSysctls` - 특정 sysctls를 제외한다.
|
||||
목록에서 안전한 것과 안전하지 않은 sysctls의 조합을 금지할 수 있다.
|
||||
모든 sysctls 설정을 금지하려면 자체적으로 `*`를 사용한다.
|
||||
- `allowedUnsafeSysctls` - `forbiddenSysctls`에 나열되지 않는 한
|
||||
기본 목록에서 허용하지 않은 특정 sysctls를 허용한다.
|
||||
|
||||
[Sysctl 문서](/ko/docs/tasks/administer-cluster/sysctl-cluster/#파드시큐리티폴리시-podsecuritypolicy)를 참고하길 바란다.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- [파드시큐리티폴리시 사용 중단: 과거, 현재, 그리고
|
||||
미래](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)에서
|
||||
파드시큐리티폴리시의 미래에 대해 알아본다.
|
||||
|
||||
- 폴리시 권장 사항에 대해서는 [파드 보안 표준](/ko/docs/concepts/security/pod-security-standards/)을 참조한다.
|
||||
|
||||
- API 세부 정보는
|
||||
[파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -407,7 +407,7 @@ weight: 10
|
|||
<td>
|
||||
<p>
|
||||
컨테이너는 <code>ALL</code> 능력을 내려놓아야 하며,
|
||||
<code>NET_BIND_SERVICE</code> 능력을 다시 추가하기 위한 목적일 때만 허용되어야 한다. <em>v1.25+에서는 <a href="#policies-specific-to-linux">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em></p>
|
||||
<code>NET_BIND_SERVICE</code> 능력을 다시 추가하기 위한 목적일 때만 허용되어야 한다. <em>v1.25+에서는 <a href="#policies-specific-to-linux">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em>
|
||||
</p>
|
||||
<p><strong>제한된 필드</strong></p>
|
||||
<ul>
|
||||
|
|
@ -521,3 +521,4 @@ v1.24 이전 Kubelet은 파드 OS 필드를 필수로 요구하지 않으며,
|
|||
|
||||
추가적으로, 샌드박스 방식에 따라 샌드박스 워크로드에 대한 보호가 달라진다.
|
||||
이와 같은 경우에는, 하나의 프로필만을 모든 샌드박스 워크로드에 대해 권장할 수 없다.
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ weight: 60
|
|||
쿠버네티스 {{< glossary_tooltip text="RBAC" term_id="rbac" >}}는
|
||||
클러스터 사용자 및 워크로드가 자신의 역할을 수행하기 위해 필요한 자원에 대해서만
|
||||
접근 권한을 가지도록 보장하는 핵심 보안 제어 방식이다. 클러스터 관리자가 클러스터 사용자 권한을 설정할 시에는,
|
||||
보안 사고로 이어지는 과도한 접근 권한 부여의 위험을 줄이기 위해
|
||||
보안 사고로 이어지는 과도한 접근 권한 부여의 위험을 줄이기 위해
|
||||
권한 에스컬레이션 발생 가능성에 대해 이해하는 것이 중요하다.
|
||||
|
||||
여기서 제공하는 모범 사례는 [RBAC 문서](/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)
|
||||
|
|
@ -33,7 +33,7 @@ weight: 60
|
|||
- 와일드카드(wildcard)를 사용한 권한 지정을 할 시에는, 특히 모든 리소스에 대해서는 가능하면 지양한다.
|
||||
쿠버네티스는 확장성을 지니는 시스템이기 때문에,
|
||||
와일드카드를 이용한 권한 지정은 현재 클러스터에 있는 모든 오브젝트 타입뿐만 아니라
|
||||
추후에 생성될 오브젝트 타입에 대해서도 권한을 부여하게 된다.
|
||||
모든 오브젝트 타입에 대해서도 권한을 부여하게 된다.
|
||||
- 운영자는 `cluster-admin` 계정이 필수로 요구되지 않을시에는 사용을 지양한다.
|
||||
적은 권한을 가진 계정과
|
||||
[가장 (impersonation) 권한](/docs/reference/access-authn-authz/authentication/#user-impersonation)을
|
||||
|
|
@ -99,10 +99,13 @@ weight: 60
|
|||
|
||||
### 워크로드 생성
|
||||
|
||||
워크로드(파드 혹은 파드를 관리하는
|
||||
[워크로드 리소스](/ko/docs/concepts/workloads/controllers/))를 생성할 수 있는 사용자는
|
||||
[파드 시큐리티 스탠다드](/ko/docs/concepts/security/pod-security-standards/)에
|
||||
기반한 제한 사항이 없을 시에는 해당 노드에 대한 접근 권한을 부여받을 수 있다.
|
||||
네임스페이스에 워크로드(파드 혹은 파드를 관리하는
|
||||
[워크로드 리소스](/ko/docs/concepts/workloads/controllers/))를 생성할 수 있는 권한은
|
||||
파드에 마운트할 수 있는 시크릿, 컨피그맵 그리고 퍼시스턴트볼륨(PersistentVolume)과 같은 해당 네임스페이스의 다른 많은 리소스에 대한
|
||||
액세스 권한을 암묵적으로 부여한다. 또한 파드는 모든 [서비스어카운트](/ko/docs/reference/access-authn-authz/service-accounts-admin/)로
|
||||
실행할 수 있기 때문에, 워크로드 생성 권한을 부여하면
|
||||
해당 네임스페이스에 있는 모든 서비스어카운트의 API 액세스 수준도 암묵적으로
|
||||
부여된다.
|
||||
|
||||
특권 파드 실행 권한을 가지는 사용자는 해당 노드에 대한 권한을 부여받을 수 있으며,
|
||||
더 나아가 권한을 상승시킬 수 있는 가능성도 존재한다.
|
||||
|
|
@ -111,13 +114,10 @@ weight: 60
|
|||
이는 [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
|
||||
또는 다른 (서드 파티) 매커니즘을 통해 시행할 수 있다.
|
||||
|
||||
사용자의 특권을 가진 파드 생성 자격을 제한하기 위해,
|
||||
현재는 사용이 중지 된 [파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/)
|
||||
매커니즘도 사용할 수 있다. (주의 - 파드시큐리티폴리시는 1.25 버전 이후로 중지될 예정이다.)
|
||||
|
||||
사용자가 네임스페이스 내에서 워크로드를 생성하면, 해당 네임스페이스에 위치한 시크릿에 대한 간접적 접근 권한을 부여 받게 된다.
|
||||
사용자가 kube-system 또는 유사한 특권을 가진 네임스페이스에서 파드를 생성하게 되면,
|
||||
RBAC를 통해 직접적으로는 접근 권한을 가지지 못할 시크릿에 대한 권한도 부여받게 된다.
|
||||
이러한 이유로, 네임스페이스는 서로 다른 수준의 보안 또는 테넌시가 필요한 리소스들을 분리하는 데 사용해야
|
||||
한다. [최소 권한](#least-privilege) 원칙을 따르고 권한을 가장 적게 할당하는 것이
|
||||
바람직하지만, 네임스페이스 내의 경계는 약한 것으로 간주되어야
|
||||
한다.
|
||||
|
||||
### 퍼시스턴트 볼륨 생성
|
||||
|
||||
|
|
@ -186,4 +186,3 @@ CSR API를 통해 CSR에 대한 `create` 권한 및 `certificatesigningrequests/
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* RBAC에 대한 추가적인 정보를 얻기 위해서는 [RBAC 문서](/docs/reference/access-authn-authz/rbac/)를 참고한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -45,9 +45,10 @@ my-nginx-3800858182-kna2y 1/1 Running 0 13s 10.244.2.5
|
|||
파드의 IP를 확인한다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -l run=my-nginx -o yaml | grep podIP
|
||||
podIP: 10.244.3.4
|
||||
podIP: 10.244.2.5
|
||||
kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs
|
||||
POD_IP
|
||||
[map[ip:10.244.3.4]]
|
||||
[map[ip:10.244.2.5]]
|
||||
```
|
||||
|
||||
이제 클러스터의 모든 노드로 ssh 접속하거나 `curl`과 같은 도구를 사용하여 두 IP 주소에 질의를 전송할 수 있을 것이다. 컨테이너는 노드의 포트 80을 사용하지 *않으며* , 트래픽을 파드로 라우팅하는 특별한 NAT 규칙도 없다는 것을 참고한다. 이것은 동일한 `containerPort`를 사용하여 동일한 노드에서 여러 nginx 파드를 실행하는 것이 가능하고, 또한 서비스에 할당된 IP 주소를 사용하여 클러스터의 다른 파드나 노드에서 접근할 수 있다는 의미이다. 호스트 노드의 특정 포트를 배후(backing) 파드로 포워드하고 싶다면, 가능은 하지만 네트워킹 모델을 사용하면 그렇게 할 필요가 없어야 한다.
|
||||
|
|
@ -243,7 +244,6 @@ kubectl get secrets
|
|||
```
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
default-token-il9rc kubernetes.io/service-account-token 1 1d
|
||||
nginxsecret kubernetes.io/tls 2 1m
|
||||
```
|
||||
그리고 또한 컨피그맵:
|
||||
|
|
@ -290,7 +290,6 @@ kubectl get secrets
|
|||
```
|
||||
```
|
||||
NAME TYPE DATA AGE
|
||||
default-token-il9rc kubernetes.io/service-account-token 1 1d
|
||||
nginxsecret kubernetes.io/tls 2 1m
|
||||
```
|
||||
|
||||
|
|
@ -314,8 +313,12 @@ kubectl delete deployments,svc my-nginx; kubectl create -f ./nginx-secure-app.ya
|
|||
이 시점에서 모든 노드에서 nginx 서버에 연결할 수 있다.
|
||||
|
||||
```shell
|
||||
kubectl get pods -o yaml | grep -i podip
|
||||
podIP: 10.244.3.5
|
||||
kubectl get pods -l run=my-nginx -o custom-columns=POD_IP:.status.podIPs
|
||||
POD_IP
|
||||
[map[ip:10.244.3.5]]
|
||||
```
|
||||
|
||||
```shell
|
||||
node $ curl -k https://10.244.3.5
|
||||
...
|
||||
<h1>Welcome to nginx!</h1>
|
||||
|
|
@ -424,3 +427,5 @@ LoadBalancer Ingress: a320587ffd19711e5a37606cf4a74574-1142138393.us-east-1.el
|
|||
* [서비스를 사용해서 클러스터 내 애플리케이션에 접근하기](/ko/docs/tasks/access-application-cluster/service-access-application-cluster/)를 더 자세히 알아본다.
|
||||
* [서비스를 사용해서 프론트 엔드부터 백 엔드까지 연결하기](/ko/docs/tasks/access-application-cluster/connecting-frontend-backend/)를 더 자세히 알아본다.
|
||||
* [외부 로드 밸런서를 생성하기](/ko/docs/tasks/access-application-cluster/create-external-load-balancer/)를 더 자세히 알아본다.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -308,7 +308,7 @@ kubectl exec -it dns-example -- cat /etc/resolv.conf
|
|||
```
|
||||
출력은 다음과 같은 형식일 것이다.
|
||||
```
|
||||
nameserver fd00:79:30::a
|
||||
nameserver 2001:db8:30::a
|
||||
search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example
|
||||
options ndots:5
|
||||
```
|
||||
|
|
@ -344,6 +344,5 @@ kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화
|
|||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
DNS 구성 관리에 대한 지침은
|
||||
[DNS 서비스 구성](/ko/docs/tasks/administer-cluster/dns-custom-nameservers/)에서 확인할 수 있다.
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ endpoints:
|
|||
|
||||
#### 제공(Serving)
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
`serving`은 종료 상태를 고려하지 않는다는 점을 제외하면 `ready` 조건과 동일하다.
|
||||
엔드포인트슬라이스 API 컨슈머는 파드가 종료되는 동안 파드 준비 상태에 관심이 있다면
|
||||
|
|
@ -127,7 +127,7 @@ endpoints:
|
|||
|
||||
#### 종료(Terminating)
|
||||
|
||||
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
|
||||
`종료(Terminating)`는 엔드포인트가 종료되는지 여부를 나타내는 조건이다.
|
||||
파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다.
|
||||
|
|
|
|||
|
|
@ -195,7 +195,7 @@ SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip tex
|
|||
|
||||
## 포트 범위 지정
|
||||
|
||||
{{< feature-state for_k8s_version="v1.22" state="beta" >}}
|
||||
{{< feature-state for_k8s_version="v1.25" state="stable" >}}
|
||||
|
||||
네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다.
|
||||
|
||||
|
|
@ -228,10 +228,6 @@ spec:
|
|||
TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
|
||||
|
||||
이 필드를 사용할 때 다음의 제한 사항이 적용된다.
|
||||
* 베타 기능으로, 기본적으로 활성화되어 있다.
|
||||
클러스터 수준에서 `endPort` 필드를 비활성화하려면, 사용자(또는 클러스터 관리자)가
|
||||
API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을 이용하여
|
||||
`NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
|
||||
* `endPort` 필드는 `port` 필드보다 크거나 같아야 한다.
|
||||
* `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다.
|
||||
* 두 포트 모두 숫자여야 한다.
|
||||
|
|
|
|||
|
|
@ -287,7 +287,7 @@ DNS 레코드를 구성하고, 라운드-로빈 이름 확인 방식을
|
|||
낮거나 0이면 DNS에 부하가 높아 관리하기가
|
||||
어려워 질 수 있다.
|
||||
|
||||
본 페이지의 뒷 부분에서 다양한 kube-proxy 구현의 동작에 대해 읽을 수 있다.
|
||||
본 페이지의 뒷 부분에서 다양한 kube-proxy 구현이 동작하는 방식에 대해 읽을 수 있다.
|
||||
우선 알아두어야 할 것은, `kube-proxy`를 구동할 때, 커널 수준의 규칙이
|
||||
수정(예를 들어, iptables 규칙이 생성될 수 있음)될 수 있고,
|
||||
이는 때로는 리부트 전까지 정리되지 않을 수도 있다.
|
||||
|
|
@ -504,17 +504,17 @@ kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는
|
|||
지원한다.
|
||||
|
||||
예를 들어, TCP 포트 6379를 개방하고
|
||||
클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-master`는,
|
||||
클러스터 IP 주소 10.0.0.11이 할당된 서비스 `redis-primary`는,
|
||||
다음 환경 변수를 생성한다.
|
||||
|
||||
```shell
|
||||
REDIS_MASTER_SERVICE_HOST=10.0.0.11
|
||||
REDIS_MASTER_SERVICE_PORT=6379
|
||||
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
|
||||
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
|
||||
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
|
||||
REDIS_MASTER_PORT_6379_TCP_PORT=6379
|
||||
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11
|
||||
REDIS_PRIMARY_SERVICE_HOST=10.0.0.11
|
||||
REDIS_PRIMARY_SERVICE_PORT=6379
|
||||
REDIS_PRIMARY_PORT=tcp://10.0.0.11:6379
|
||||
REDIS_PRIMARY_PORT_6379_TCP=tcp://10.0.0.11:6379
|
||||
REDIS_PRIMARY_PORT_6379_TCP_PROTO=tcp
|
||||
REDIS_PRIMARY_PORT_6379_TCP_PORT=6379
|
||||
REDIS_PRIMARY_PORT_6379_TCP_ADDR=10.0.0.11
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -1325,15 +1325,15 @@ IP 주소를 정리한다.
|
|||
|
||||
#### `type: ClusterIP` 서비스의 IP 주소 범위 {#service-ip-static-sub-range}
|
||||
|
||||
{{< feature-state for_k8s_version="v1.24" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.25" state="beta" >}}
|
||||
그러나, 이러한 `ClusterIP` 할당 전략에는 한 가지 문제가 있는데,
|
||||
그것은 사용자 또한 [서비스의 IP 주소를 직접 고를 수 있기 때문이다](#choosing-your-own-ip-address).
|
||||
이로 인해 만약 내부 할당기(allocator)가 다른 서비스에 대해 동일한 IP 주소를 선택하면
|
||||
충돌이 발생할 수 있다.
|
||||
|
||||
`ServiceIPStaticSubrange`
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화하면,
|
||||
할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진
|
||||
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)는 v1.25 이상에서 기본적으로 활성화되며,
|
||||
이 때 사용하는 할당 전략은 `min(max(16, cidrSize / 16), 256)` 공식을 사용하여 얻어진
|
||||
`service-cluster-ip-range`의 크기에 기반하여 `ClusterIP` 범위를 두 대역으로 나누며,
|
||||
여기서 이 공식은 _16 이상 256 이하이며, 그 사이에 계단 함수가 있음_ 으로 설명할 수 있다.
|
||||
동적 IP 할당은 상위 대역에서 우선적으로 선택하며,
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ kube-proxy 구성요소는 엔드포인트슬라이스 컨트롤러가 설정한
|
|||
준비되지 않은(unready) 노드는 무시한다.
|
||||
이 때문에 많은 노드가 준비되지 않은 상태에서는 의도하지 않은 결과가 나타날 수도 있다.
|
||||
|
||||
* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 계산할 때
|
||||
* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 배포하거나 계산할 때
|
||||
{{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}은 고려하지 않는다.
|
||||
서비스를 구성하는 파드가 클러스터의 일부 노드에만 배치되어 있는 경우,
|
||||
이러한 상황은 고려되지 않을 것이다.
|
||||
|
|
|
|||
Loading…
Reference in New Issue