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] Translate /docs/setup/best-practices/enforcing-pod-security-stan… #36726

Merged
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
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
---
# reviewers:
# - tallclair
# - liggitt
title: 파드 시큐리티 스탠다드 강제하기
weight: 40
---

<!-- overview -->

이 페이지는 [파드 시큐리티 스탠다드(Pod Security Standards)](/docs/concepts/security/pod-security-standards)를
강제(enforce)하는 모범 사례에 대한 개요를 제공한다.

<!-- body -->

## 내장된 파드 시큐리티 어드미션 컨트롤러 사용

{{< feature-state for_k8s_version="v1.23" state="beta" >}}

[파드 시큐리티 어드미션 컨트롤러(Pod Security Admission Controller)](/docs/reference/access-authn-authz/admission-controllers/#podsecurity)는
더 이상 사용되지 않는 파드시큐리티폴리시(PodSecurityPolicy)를 대체한다.

### 모든 클러스터 네임스페이스 구성

구성이 전혀 없는 네임스페이스는 클러스터 시큐리티 모델에서 심각한 틈으로 간주해야
한다. 시간을 들여 각 네임스페이스에서 발생하는 워크로드 유형을 분석하고,
파드 시큐리티 폴리시를 참조하여 각각에 적합한 수준을 결정하는 것을 권장한다.
레이블이 없는 네임스페이스는 아직 평가되지 않았음을 표시해야 한다.

모든 네임스페이스의 모든 워크로드에 동일한 보안 요구 사항이 있는 시나리오에서,
파드 시큐리티 레이블을 대량으로 적용할 수 있는 방법을 보여주는 [예시](/docs/concepts/security/pod-security-admission/#applying-to-all-namespaces)를
제공한다.

### 최소 권한 원칙 수용

이상적인 경우 모든 네임스페이스의 모든 파드가 `제한된` 정책의 요구 사항을 충족할
것이다. 그러나 일부 워크로드는 정당한 이유로 승격된 권한(elevated privilege)이 필요하므로 이는
불가능하거나 실용적이지 않다.

- `권한 있는(privileged)` 워크로드를 허용하는 네임스페이스는 적절한 액세스 제어를 설정하고 시행해야 한다.
- 허용되는 네임스페이스에서 실행되는 워크로드의 경우, 고유한 보안 요구 사항에
대한 문서를 유지 관리한다. 가능하다면 이러한 요구 사항을 어떻게 더 제한할 수
있는지 고려해야 한다.

### 다중 모드(multi-mode) 전략 채택

파드 시큐리티 스탠다드 어드미션 컨트롤러의 `감사(audit)` 및 `경고(warn)` 모드를 사용하면 기존 워크로드를
중단하지 않고 파드에 대한 중요한 보안 현황을 쉽게 이해할 수 있다.

이러한 모드들을 모든 네임스페이스에 `강제(enforce)`하려는 _원하는_ 수준 및 버전으로
설정하는 것이 좋다. 이 단계에서 생성된 경고 및 감사 어노테이션은 해당 상태로
안내할 수 있다. 워크로드 작성자가 원하는 수준에 맞게 변경을 수행할 것으로 예상되는 경우
`경고` 모드를 활성화한다. 감사 로그를 사용하여 원하는 수준에 맞게 변경 사항을
모니터링/구동하려는 경우 `감사` 모드를 활성화한다.

`강제` 모드를 원하는 값으로 설정한 경우 이러한 모드는 몇 가지 다른 방식으로도
유용할 수 있다.

- `경고`를 `강제`와 같은 수준으로 설정하면 클라이언트가 유효성 검사를
통과하지 못한 파드(또는 파드 템플릿이 있는 리소스)를 만들려고 할 때 경고를 받게 된다.
이렇게 하면 규정을 준수하도록 해당 리소스를 업데이트하는 데 도움이 된다.
- `강제`를 최신이 아닌 특정 버전에 고정하는 네임스페이스에서는 `감사` 및 `경고` 모드가
`강제`와 동일한 수준으로 설정되지만, `최신` 버전으로 고정하면 설정(setting) 정보를 볼 수 있다.
이는 이전 버전에서는 허용되지만 현재 모범 사례에서는 허용되지 않는다.

## 타사(third-party) 대안

{{% thirdparty-content %}}

쿠버네티스 에코시스템에서 보안 프로필을 적용하기 위한 다른 대안이
개발되고 있다.

- [Kubewarden](https://github.com/kubewarden).
- [Kyverno](https://kyverno.io/policies/).
- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper).

_내장_ 솔루션(예: 파드 시큐리티 어드미션 컨트롤러)과 타사 도구를
사용할지 여부는 전적으로 사용자의 상황에 달려 있다. 솔루션을 평가할 때
공급망의 신뢰가 중요하다. 궁극적으로 앞서 언급한 접근 방식 중
하나를 사용하는 것이 아무것도 하지 않는 것보다 낫다.