Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ko] Update outdated files in dev-1.27-ko.1 (M51-M55) #43196

Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 29 additions & 10 deletions content/ko/docs/concepts/security/controlling-access.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,6 @@ weight: 50
<!-- overview -->
이 페이지는 쿠버네티스 API에 대한 접근 제어의 개요를 제공한다.


<!-- body -->
사용자는 `kubectl`, 클라이언트 라이브러리
또는 REST 요청을 통해
Expand All @@ -23,11 +22,15 @@ weight: 50

## 전송 보안

기본적으로 쿠버네티스 API 서버는 TLS에 의해 보호되는 첫번째 non-localhost 네트워크 인터페이스의 6443번 포트에서 수신을 대기한다. 일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다. 포트번호는 `--secure-port` 플래그를 통해, 수신 대기 IP 주소는 `--bind-address` 플래그를 통해 변경될 수 있다.
기본적으로 쿠버네티스 API 서버는 TLS에 의해 보호되는
첫번째 non-localhost 네트워크 인터페이스의 6443번 포트에서 수신을 대기한다.
일반적인 쿠버네티스 클러스터에서 API는 443번 포트에서 서비스한다.
포트번호는 `--secure-port` 플래그를 통해, 수신 대기 IP 주소는 `--bind-address` 플래그를 통해 변경될 수 있다.

API 서버는 인증서를 제시한다.
이러한 인증서는 사설 인증 기관(CA)에 기반하여 서명되거나, 혹은 공인 CA와 연결된 공개키 인프라스트럭처에 기반한다.
인증서와 그에 해당하는 개인키는 각각 `--tls-cert-file`과 `--tls-private-key-file` 플래그를 통해 지정한다.
인증서와 그에 해당하는 개인키는 각각 `--tls-cert-file`과
`--tls-private-key-file` 플래그를 통해 지정한다.

만약 클러스터가 사설 인증 기관을 사용한다면,
해당 CA 인증서를 복사하여 클라이언트의 `~/.kube/config` 안에 구성함으로써
Expand Down Expand Up @@ -65,9 +68,12 @@ JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.

## 인가

특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다. 이는 다이어그램에 **2**단계로 표시되어 있다.
특정 사용자로부터 온 요청이 인증된 후에는 인가되어야 한다.
이는 다이어그램에 **2**단계로 표시되어 있다.

요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다. 기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우 요청이 인가된다.
요청은 요청자의 username, 요청된 작업 및 해당 작업이 영향을 주는 오브젝트를 포함해야 한다.
기존 정책이 요청된 작업을 완료할 수 있는 권한이 해당 사용자에게 있다고 선언하는 경우
요청이 인가된다.

예를 들어 Bob이 아래와 같은 정책을 가지고 있다면 `projectCaribou` 네임스페이스에서만 파드를 읽을 수 있다.

Expand All @@ -83,7 +89,9 @@ JWT 토큰(서비스 어카운트에 사용됨)을 포함한다.
}
}
```
Bob이 다음과 같은 요청을 하면 'projectCaribou' 네임스페이스의 오브젝트를 읽을 수 있기 때문에 요청이 인가된다.

Bob이 다음과 같은 요청을 하면 `projectCaribou` 네임스페이스의
오브젝트를 읽을 수 있기 때문에 요청이 인가된다.

```json
{
Expand All @@ -99,14 +107,25 @@ Bob이 다음과 같은 요청을 하면 'projectCaribou' 네임스페이스의
}
}
```
Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에 쓰기(`create` 또는 `update`) 요청을 하면 그의 인가는 거부된다. 만약 Bob이 `projectFish`처럼 다른 네임스페이스의 오브젝트 읽기(`get`) 요청을 하면 그의 인가는 거부된다.

쿠버네티스 인가는 공통 REST 속성을 사용하여 기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 상호 작용할 것을 요구한다. 이러한 제어 시스템은 쿠버네티스 API 이외의 다른 API와 상호작용할 수 있으므로 REST 형식을 사용하는 것이 중요하다.
Bob이 `projectCaribou` 네임스페이스에 있는 오브젝트에
쓰기(`create` 또는 `update`) 요청을 하면 그의 인가는 거부된다.
만약 Bob이 `projectFish`처럼 다른 네임스페이스의 오브젝트 읽기(`get`) 요청을 하면 그의 인가는 거부된다.

쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다. 관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다. 인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고, 어느 모듈이 요청을 승인하면 요청을 진행할 수 있다. 모든 모듈이 요청을 거부하면 요청이 거부된다(HTTP 상태 코드 403).
쿠버네티스 인가는 공통 REST 속성을 사용하여
기존 조직 전체 또는 클라우드 제공자 전체의 접근 제어 시스템과 상호 작용할 것을 요구한다.
이러한 제어 시스템은 쿠버네티스 API 이외의 다른 API와 상호작용할 수 있으므로
REST 형식을 사용하는 것이 중요하다.

인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면 [인가 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참조한다.
쿠버네티스는 ABAC 모드, RBAC 모드, 웹훅 모드와 같은 여러 개의 인가 모듈을 지원한다.
관리자가 클러스터를 생성할 때 API 서버에서 사용해야 하는 인가 모듈을 구성했다.
인가 모듈이 2개 이상 구성되면 쿠버네티스가 각 모듈을 확인하고,
어느 모듈이 요청을 승인하면 요청을 진행할 수 있다.
모든 모듈이 요청을 거부하면 요청이
거부된다(HTTP 상태 코드 403).

인가 모듈을 사용한 정책 생성을 포함해 쿠버네티스 인가에 대해 더 배우려면
[인가 개요](/ko/docs/reference/access-authn-authz/authorization/)를 참조한다.

## 어드미션 제어

Expand Down
5 changes: 4 additions & 1 deletion content/ko/docs/concepts/security/pod-security-admission.md
Original file line number Diff line number Diff line change
Expand Up @@ -131,4 +131,7 @@ pod-security.kubernetes.io/<MODE>-version: <VERSION>
- [파드 시큐리티 스탠다드 적용하기](/ko/docs/setup/best-practices/enforcing-pod-security-standards)
- [기본 제공 어드미션 컨트롤러를 구성하여 파드 시큐리티 스탠다드 적용하기](/docs/tasks/configure-pod-container/enforce-standards-admission-controller)
- [네임스페이스 레이블로 파드 시큐리티 스탠다드 적용하기](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels)
- [파드시큐리티폴리시(PodSecurityPolicy)에서 내장 파드시큐리티어드미션컨트롤러(PodSecurity Admission Controller)로 마이그레이션](/docs/tasks/configure-pod-container/migrate-from-psp)

이전 버전의 쿠버네티스를 사용하고 있으며, 파드시큐리티폴리시를 포함하고 있지 않은 쿠버네티스 버전으로 업그레이드하고 싶다면,
[파드시큐리티폴리시(PodSecurityPolicy)에서 내장 파드시큐리티어드미션컨트롤러(PodSecurity Admission Controller)로 마이그레이션](/docs/tasks/configure-pod-container/migrate-from-psp)을
참고한다.
12 changes: 6 additions & 6 deletions content/ko/docs/concepts/security/pod-security-standards.md
Original file line number Diff line number Diff line change
Expand Up @@ -57,7 +57,7 @@ weight: 10
<tr>
<td style="white-space: nowrap">호스트 프로세스</td>
<td>
<p>윈도우 파드는 <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">호스트 프로세스 컨테이너</a>를 실행할 권한을 제공하며, 이는 윈도우 노드에 대한 특권 접근을 가능하게 한다. 기본 정책에서의 호스트에 대한 특권 접근은 허용되지 않는다. {{< feature-state for_k8s_version="v1.23" state="beta" >}}</p>
<p>윈도우 파드는 <a href="/docs/tasks/configure-pod-container/create-hostprocess-pod">호스트 프로세스 컨테이너</a>를 실행할 권한을 제공하며, 이는 윈도우 노드에 대한 특권 접근을 가능하게 한다. 기본 정책에서의 호스트에 대한 특권 접근은 허용되지 않는다. {{< feature-state for_k8s_version="v1.26" state="stable" >}}</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.windowsOptions.hostProcess</code></li>
Expand Down Expand Up @@ -152,7 +152,7 @@ weight: 10
<tr>
<td style="white-space: nowrap">호스트 포트</td>
<td>
<p>호스트 포트는 허용되지 않아야 하며, 또는 적어도 알려진 목록 범위내로 제한되어야 한다.</p>
<p>호스트 포트는 전부 금지되거나(추천), 또는 적어도 알려진 목록 범위내로 제한되어야 한다.</p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.containers[*].ports[*].hostPort</code></li>
Expand All @@ -162,7 +162,7 @@ weight: 10
<p><strong>허용된 값</strong></p>
<ul>
<li>Undefined/nil</li>
<li>Known list</li>
<li>(빌트인 <a href="/ko/docs/concepts/security/pod-security-admission/">파드 시큐리티 어드미션 컨트롤러</a>가 지원하지 않는) Known list</li>
<li><code>0</code></li>
</ul>
</td>
Expand Down Expand Up @@ -326,7 +326,7 @@ weight: 10
<tr>
<td style="white-space: nowrap">권한 상승(v1.8+)</td>
<td>
<p>권한 상승(예를 들어, set-user-ID 또는 set-group-ID 파일 모드를 통한)은 허용되지 않아야 한다. <em>v1.25+에서는 <a href="#policies-specific-to-linux">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em></p>
<p>권한 상승(예를 들어, set-user-ID 또는 set-group-ID 파일 모드를 통한)은 허용되지 않아야 한다. <em>v1.25+에서는 <a href="#os-specific-policy-controls">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em></p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.containers[*].securityContext.allowPrivilegeEscalation</code></li>
Expand Down Expand Up @@ -381,7 +381,7 @@ weight: 10
<tr>
<td style="white-space: nowrap">Seccomp(v1.19+)</td>
<td>
<p>Seccomp 프로필은 다음과 같은 값으로 설정되어야 한다.<code>Unconfined</code> 프로필 및 프로필의 <em>absence</em>는 금지되어 있다. <em>v1.25+에서는 <a href="#policies-specific-to-linux">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em></p>
<p>Seccomp 프로필은 다음과 같은 값으로 설정되어야 한다.<code>Unconfined</code> 프로필 및 프로필의 <em>absence</em>는 금지되어 있다. <em>v1.25+에서는 <a href="#os-specific-policy-controls">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em></p>
<p><strong>제한된 필드</strong></p>
<ul>
<li><code>spec.securityContext.seccompProfile.type</code></li>
Expand All @@ -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>
<code>NET_BIND_SERVICE</code> 능력을 다시 추가하기 위한 목적일 때만 허용되어야 한다. <em>v1.25+에서는 <a href="#os-specific-policy-controls">리눅스 전용 정책이다.</a><code>(spec.os.name != windows)</code></em>
</p>
<p><strong>제한된 필드</strong></p>
<ul>
Expand Down
16 changes: 14 additions & 2 deletions content/ko/docs/concepts/security/rbac-good-practices.md
Original file line number Diff line number Diff line change
Expand Up @@ -121,8 +121,20 @@ weight: 60

### 퍼시스턴트 볼륨 생성

[파드시큐리티폴리시](/ko/docs/concepts/security/pod-security-policy/#volumes-and-file-systems) 문서에서도 언급이 되었듯이,
퍼시스턴트볼륨 생성 권한은 해당 호스트에 대한 권한 에스컬레이션으로 이어질 수 있다.
누군가(또는 어떤 애플리케이션이) 임의의(arbitrary) 퍼시스턴트볼륨 생성 권한을 갖고 있다면,
그 권한은 `hostPath` 볼륨 생성 권한도 포함하며, 이는 곧 특정 파드가 해당 노드의 기저 호스트 파일시스템으로의 접근 권한을 가질 수도 있음을 의미한다.
이러한 권한을 주는 것은 보안 위협이다.

컨테이너가 호스트 파일시스템에 제약없이 접근할 수 있게 되면 상위 권한을 획득할 수 있으며,
여기에는 다른 컨테이너의 데이터를 읽거나, kubelet과 같은 시스템 서비스의 자격 증명을 악용하는 것도 포함된다.

다음과 같은 경우에만 퍼시스턴트볼륨 오브젝트 생성 권한을 주어야 한다.

- 이러한 권한이 업무상 필요하며, 신뢰할 수 있는 사용자(클러스터 운용자)
- 자동 프로비저닝을 위해 구성된 퍼시스턴트볼륨클레임을 바탕으로
퍼시스턴트볼륨을 생성하는 쿠버네티스 컨트롤 플레인 구성 요소.
이들은 주로 쿠버네티스 공급자 또는 운용자가 CSI 드라이버를 설치할 때 함께 설치된다.

퍼시스턴트 스토리지에 대한 권한이 필요할 시에는 신뢰 가능한 관리자를 통해 퍼시스턴트볼륨을 생성하고,
제한된 권한을 가진 사용자는 퍼시스턴트볼륨클레임을 통해 해당 스토리지에 접근하는 것이 바람직하다.

Expand Down