From 35aa2d624d2e1cd4009bc36ab8cbcf0a672bc446 Mon Sep 17 00:00:00 2001 From: WESTZERO115 Date: Wed, 5 Oct 2022 01:46:52 +0900 Subject: [PATCH] Update outdated files dev-1.25-ko.1 (M22-M33) --- .../resource-bin-packing.md | 6 +- .../topology-spread-constraints.md | 81 +- content/ko/docs/concepts/security/overview.md | 1 + .../concepts/security/pod-security-policy.md | 781 +----------------- .../security/pod-security-standards.md | 3 +- .../concepts/security/rbac-good-practices.md | 27 +- .../connect-applications-service.md | 19 +- .../services-networking/dns-pod-service.md | 3 +- .../services-networking/endpoint-slices.md | 4 +- .../services-networking/network-policies.md | 6 +- .../concepts/services-networking/service.md | 24 +- .../topology-aware-hints.md | 2 +- 12 files changed, 131 insertions(+), 826 deletions(-) diff --git a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md index 6ed35356597..fcabf42c3a3 100644 --- a/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/ko/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -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 diff --git a/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md b/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md index 668cf715156..b831f73f46c 100644 --- a/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md +++ b/content/ko/docs/concepts/scheduling-eviction/topology-spread-constraints.md @@ -48,7 +48,8 @@ weight: 40 ## `topologySpreadConstraints` 필드 -파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 예시는 다음과 같다. +파드 API에 `spec.topologySpreadConstraints` 필드가 있다. 이 필드는 다음과 같이 +쓰인다. ```yaml --- @@ -60,14 +61,18 @@ spec: # 토폴로지 분배 제약 조건을 구성한다. topologySpreadConstraints: - maxSkew: - minDomains: # 선택 사항이며, v1.24에서 알파 기능으로 도입되었다. + minDomains: # 선택 사항이며, v1.25에서 베타 기능으로 도입되었다. topologyKey: whenUnsatisfiable: labelSelector: + matchLabelKeys: # 선택 사항이며, 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개의 노드가 존재하기 전에는 고려가 되지 않을 것이다. + 이를 극복하기 위해, 파드 토폴로지 분배 제약 조건과 전반적인 토폴로지 도메인 집합에 대한 정보를 인지하고 동작하는 클러스터 오토스케일링 도구를 이용할 수 있다. diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md index 324fd1d4df2..bc9d9763de0 100644 --- a/content/ko/docs/concepts/security/overview.md +++ b/content/ko/docs/concepts/security/overview.md @@ -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/ | diff --git a/content/ko/docs/concepts/security/pod-security-policy.md b/content/ko/docs/concepts/security/pod-security-policy.md index 134d1eb249d..f30c57d79b3 100644 --- a/content/ko/docs/concepts/security/pod-security-policy.md +++ b/content/ko/docs/concepts/security/pod-security-policy.md @@ -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 >}} - -파드 시큐리티 폴리시를 사용하면 파드 생성 및 업데이트에 대한 세분화된 권한을 -부여할 수 있다. - - - -## 파드 시큐리티 폴리시란? - -_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: -rules: -- apiGroups: ['policy'] - resources: ['podsecuritypolicies'] - verbs: ['use'] - resourceNames: - - -``` - -그런 다음 `(Cluster)Role`이 승인된 사용자에게 바인딩된다. - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRoleBinding -metadata: - name: -roleRef: - kind: ClusterRole - name: - apiGroup: rbac.authorization.k8s.io -subjects: -# 네임스페이스의 모든 서비스 어카운트 승인(권장): -- kind: Group - apiGroup: rbac.authorization.k8s.io - name: system:serviceaccounts: -# 특정 서비스 어카운트 승인(권장하지 않음): -- kind: ServiceAccount - name: - namespace: -# 특정 사용자 승인(권장하지 않음): -- kind: User - apiGroup: rbac.authorization.k8s.io - 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:` (여기서 ``는 타겟 네임스페이스) 그룹을 사용하여 - 파드시큐리티폴리시를 전체 네임스페이스에만 바인드한다. 예시는 다음과 같다. - - ```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- <}} -이 방법은 권장하지 않는다! 선호하는 방법은 [다음 절](#다른-파드를-실행)을 -참고하길 바란다. -{{< /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- <}} - -다음은 권한이 없는 사용자로서의 실행을 필요로 하고, 루트로의 에스컬레이션(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/` - `/`에 있는 노드에서 파일을 프로파일로 - 지정한다. 여기서 ``는 Kubelet의 `--seccomp-profile-root` 플래그를 - 통해 정의된다. `--seccomp-profile-root` 플래그가 - 정의되어 있지 않으면, `` 이 `--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) 참조한다. - diff --git a/content/ko/docs/concepts/security/pod-security-standards.md b/content/ko/docs/concepts/security/pod-security-standards.md index 8100e5a1d51..13847be2f63 100644 --- a/content/ko/docs/concepts/security/pod-security-standards.md +++ b/content/ko/docs/concepts/security/pod-security-standards.md @@ -407,7 +407,7 @@ weight: 10

컨테이너는 ALL 능력을 내려놓아야 하며, - NET_BIND_SERVICE 능력을 다시 추가하기 위한 목적일 때만 허용되어야 한다. v1.25+에서는 리눅스 전용 정책이다.(spec.os.name != windows)

+ NET_BIND_SERVICE 능력을 다시 추가하기 위한 목적일 때만 허용되어야 한다. v1.25+에서는 리눅스 전용 정책이다.(spec.os.name != windows)

제한된 필드

    @@ -521,3 +521,4 @@ v1.24 이전 Kubelet은 파드 OS 필드를 필수로 요구하지 않으며, 추가적으로, 샌드박스 방식에 따라 샌드박스 워크로드에 대한 보호가 달라진다. 이와 같은 경우에는, 하나의 프로필만을 모든 샌드박스 워크로드에 대해 권장할 수 없다. + diff --git a/content/ko/docs/concepts/security/rbac-good-practices.md b/content/ko/docs/concepts/security/rbac-good-practices.md index 8a3da4033d6..024c898f44b 100644 --- a/content/ko/docs/concepts/security/rbac-good-practices.md +++ b/content/ko/docs/concepts/security/rbac-good-practices.md @@ -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/)를 참고한다. - diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md index 7bbdceff241..b0afada7b76 100644 --- a/content/ko/docs/concepts/services-networking/connect-applications-service.md +++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md @@ -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 ...

    Welcome to nginx!

    @@ -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/)를 더 자세히 알아본다. + + diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md index 59ed5efc577..760505b3c6b 100644 --- a/content/ko/docs/concepts/services-networking/dns-pod-service.md +++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md @@ -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/)에서 확인할 수 있다. diff --git a/content/ko/docs/concepts/services-networking/endpoint-slices.md b/content/ko/docs/concepts/services-networking/endpoint-slices.md index 9d3db08643d..0b2e98138ec 100644 --- a/content/ko/docs/concepts/services-networking/endpoint-slices.md +++ b/content/ko/docs/concepts/services-networking/endpoint-slices.md @@ -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)`는 엔드포인트가 종료되는지 여부를 나타내는 조건이다. 파드의 경우 삭제 타임 스탬프가 설정된 모든 파드이다. diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md index 94db199ed34..3f7af982b22 100644 --- a/content/ko/docs/concepts/services-networking/network-policies.md +++ b/content/ko/docs/concepts/services-networking/network-policies.md @@ -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` 도 정의된 경우에만 정의할 수 있다. * 두 포트 모두 숫자여야 한다. diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md index f87dcc42491..21bb82f9194 100644 --- a/content/ko/docs/concepts/services-networking/service.md +++ b/content/ko/docs/concepts/services-networking/service.md @@ -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 할당은 상위 대역에서 우선적으로 선택하며, diff --git a/content/ko/docs/concepts/services-networking/topology-aware-hints.md b/content/ko/docs/concepts/services-networking/topology-aware-hints.md index d596aaf69cc..4f11ff8dd32 100644 --- a/content/ko/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/ko/docs/concepts/services-networking/topology-aware-hints.md @@ -147,7 +147,7 @@ kube-proxy 구성요소는 엔드포인트슬라이스 컨트롤러가 설정한 준비되지 않은(unready) 노드는 무시한다. 이 때문에 많은 노드가 준비되지 않은 상태에서는 의도하지 않은 결과가 나타날 수도 있다. -* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 계산할 때 +* 엔드포인트슬라이스 컨트롤러는 각 존 내의 비율을 배포하거나 계산할 때 {{< glossary_tooltip text="톨러레이션" term_id="toleration" >}}은 고려하지 않는다. 서비스를 구성하는 파드가 클러스터의 일부 노드에만 배치되어 있는 경우, 이러한 상황은 고려되지 않을 것이다.