[ko] Update outdated files in dev-1.24-ko.1 M115-M138

2022-05-31 11:42:36 +09:00
parent 507491e619
commit 3ec9363bca
17 changed files with 306 additions and 242 deletions
@@ -136,7 +136,7 @@ minikube dashboard --url
    ```

 {{< note >}}
-`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/overview/)을 살펴보자.
+`kubectl` 명령어에 관해 자세히 알기 원하면 [kubectl 개요](/ko/docs/reference/kubectl/)을 살펴보자.
 {{< /note >}}

 ## 서비스 만들기
@@ -264,7 +264,7 @@ metadata:
 spec:
  containers:
  - name: hello
-    image: busybox
+    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
 EOF
 pod/hello-apparmor-2 created
@@ -350,7 +350,7 @@ Events:

 {{< note >}}
 파드시큐리티폴리시는 쿠버네티스 v1.21에서 사용 중단되었으며, v1.25에서 제거될 예정이다. 
-더 자세한 내용은 [파드시큐리티폴리시 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
+더 자세한 내용은 [파드시큐리티폴리시](/ko/docs/concepts/policy/pod-security-policy/) 문서를 참고한다.
 {{< /note >}}

 만약 파드시큐리티폴리시 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
@@ -381,28 +381,14 @@ apparmor.security.beta.kubernetes.io/allowedProfileNames: <profile_ref>[,others.
 --feature-gates=AppArmor=false
 ```

-비활성화되면 AppArmor 프로파일을 포함한 파드는 "Forbidden" 오류로 검증 실패한다.
-기본적으로 도커는 항상 비특권 파드에 "docker-default" 프로파일을 활성화하고(AppArmor 커널모듈이 활성화되었다면),
-기능 게이트가 비활성화된 것처럼 진행한다.
-AppArmor를 비활성화하는 이 옵션은
-AppArmor가 일반 사용자 버전이 되면 제거된다.
+비활성화되면, AppArmor 프로파일을 포함한 파드는 
+"Forbidden" 오류로 검증 실패한다.

-### AppArmor와 함께 쿠버네티스 1.4로 업그레이드 하기 {#upgrading-to-kubernetes-v1.4-with-apparmor}
-
-클러스터 버전을 v1.4로 업그레이드하기 위해 AppArmor쪽 작업은 없다.
-그러나 AppArmor 어노테이션을 가진 파드는 유효성 검사(혹은 파드시큐리티폴리시 승인)을 거치지 않는다.
-그 노드에 허용 프로파일이 로드되면, 악의적인 사용자가 허가 프로필을 미리 적용하여
-파드의 권한을 docker-default 보다 높일 수 있다.
-이것이 염려된다면 `apparmor.security.beta.kubernetes.io` 어노테이션이 포함된
-모든 파드의 클러스터를 제거하는 것이 좋다.
-
-### 일반 사용자 버전으로 업그레이드 방법 {#upgrade-path-to-general-availability}
-
-AppArmor는 일반 사용자 버전(general available)으로 준비되면 현재 어노테이션으로 지정되는 옵션은 필드로 변경될 것이다.
-모든 업그레이드와 다운그레이드 방법은 전환을 통해 지원하기에는 매우 미묘하니
-전환이 필요할 때에 상세히 설명할 것이다.
-최소 두 번의 릴리스에 대해서는 필드와 어노테이션 모두를 지원할 것이고,
-그 이후부터는 어노테이션은 명확히 거부된다.
+{{<note>}}
+쿠버네티스 기능이 비활성화되어 있어도, 런타임이 계속 기본 프로파일을 강제할 수도 있다. 
+AppArmor가 general availability (GA) 상태로 바뀌면 
+AppArmor 기능을 비활성화하는 옵션은 제거될 것이다.
+{{</note>}}

 ## 프로파일 제작 {#authoring-profiles}

@@ -415,10 +401,6 @@ AppArmor 프로파일을 만들고 올바르게 지정하는 것은 매우 까
 * [bane](https://github.com/jfrazelle/bane)은 단순화된 프로파일 언어를 이용하는 도커를 위한
  AppArmor 프로파일 생성기이다.

-개발 장비의 도커를 통해 애플리케이션을 실행하여
-프로파일을 생성하는 것을 권장하지만,
-파드가 실행 중인 쿠버네티스 노드에서 도구 실행을 금하지는 않는다.
-
 AppArmor 문제를 디버깅하기 위해서 거부된 것으로 보이는 시스템 로그를 확인할 수 있다.
 AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
 `journalctl`에서 볼 수 있다. 더 많은 정보는
@@ -441,9 +423,8 @@ AppArmor 로그는 `dmesg`에서 보이며, 오류는 보통 시스템 로그나
 - `runtime/default`: 기본 런타임 프로파일을 참조한다.
  - (기본 파드시큐리티폴리시 없이) 프로파일을 지정하지 않고
    AppArmor를 사용하는 것과 동등하다.
-  - 도커에서는 권한 없는 컨테이너의 경우는
-    [`docker-default`](https://docs.docker.com/engine/security/apparmor/) 프로파일로,
-    권한이 있는 컨테이너의 경우 unconfined(프로파일 없음)으로 해석한다.
+  - 실제로는, 많은 컨테이너 런타임은 동일한 OCI 기본 프로파일을 사용하며, 이는 
+    https://github.com/containers/common/blob/main/pkg/apparmor/apparmor_linux_template.go 에 정의되어 있다.
 - `localhost/<profile_name>`: 노드(localhost)에 적재된 프로파일을 이름으로 참조한다.
   - 가용한 프로파일 이름의 상세 내용은
     [핵심 정책 참조](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications)에 설명되어 있다.
@@ -16,7 +16,9 @@ weight: 10
 각 네임스페이스별로 `baseline` 파드 시큐리티 스탠다드를 강제(enforce)할 것이다.

 파드 시큐리티 스탠다드를 클러스터 수준에서 여러 네임스페이스에 한 번에 적용할 수도 있다. 
-이에 대한 안내는 [파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/)를 참고한다.
+이에 대한 안내는 
+[파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/)를 참고한다.
+
 ## {{% heading "prerequisites" %}}

 워크스테이션에 다음을 설치한다.
@@ -28,37 +30,41 @@ weight: 10

 1. 다음과 같이 `KinD` 클러스터를 생성한다.

-    ```shell
-    kind create cluster --name psa-ns-level --image kindest/node:v1.23.0
-    ```
+   ```shell
+   kind create cluster --name psa-ns-level --image kindest/node:v1.23.0
+   ```
+
   다음과 비슷하게 출력될 것이다.
-    ```
-    Creating cluster "psa-ns-level" ...
-     ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 
-     ✓ Preparing nodes 📦  
-     ✓ Writing configuration 📜 
-     ✓ Starting control-plane 🕹️ 
-     ✓ Installing CNI 🔌 
-     ✓ Installing StorageClass 💾 
-    Set kubectl context to "kind-psa-ns-level"
-    You can now use your cluster with:
+
+   ```
+   Creating cluster "psa-ns-level" ...
+    ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 
+    ✓ Preparing nodes 📦  
+    ✓ Writing configuration 📜 
+    ✓ Starting control-plane 🕹️ 
+    ✓ Installing CNI 🔌 
+    ✓ Installing StorageClass 💾 
+   Set kubectl context to "kind-psa-ns-level"
+   You can now use your cluster with:
    
-    kubectl cluster-info --context kind-psa-ns-level
+   kubectl cluster-info --context kind-psa-ns-level
    
-    Not sure what to do next? 😅  Check out https://kind.sigs.k8s.io/docs/user/quick-start/
-    ```
+   Not sure what to do next? 😅  Check out https://kind.sigs.k8s.io/docs/user/quick-start/
+   ```

 1. kubectl context를 새로 생성한 클러스터로 설정한다.
-    ```shell
-    kubectl cluster-info --context kind-psa-ns-level
-    ```
+
+   ```shell
+   kubectl cluster-info --context kind-psa-ns-level
+   ```
   다음과 비슷하게 출력될 것이다.
-    ```
-    Kubernetes control plane is running at https://127.0.0.1:50996
-    CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
+
+   ```
+   Kubernetes control plane is running at https://127.0.0.1:50996
+   CoreDNS is running at https://127.0.0.1:50996/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
    
-    To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
-    ```
+   To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
+   ```

 ## 네임스페이스 생성하기

@@ -67,7 +73,9 @@ weight: 10
 ```shell
 kubectl create ns example
 ```
+
 다음과 비슷하게 출력될 것이다.
+
 ```
 namespace/example created
 ```
@@ -78,63 +86,68 @@ namespace/example created
   이 네임스페이스에 파드 시큐리티 스탠다드를 활성화한다. 
   이 단계에서는 `latest` 버전(기본값)에 따라 `baseline(기준)` 파드 시큐리티 스탠다드에 대해 경고를 설정한다.

-    ```shell
-    kubectl label --overwrite ns example \
+   ```shell
+   kubectl label --overwrite ns example \
      pod-security.kubernetes.io/warn=baseline \
      pod-security.kubernetes.io/warn-version=latest
-    ```
+   ```

 2. 어떠한 네임스페이스에도 복수 개의 파드 시큐리티 스탠다드를 활성화할 수 있으며, 
   이는 레이블을 이용하여 가능하다. 
   다음 명령어는 최신 버전(기본값)에 따라, `baseline(기준)` 파드 시큐리티 스탠다드는 `enforce(강제)`하지만 
   `restricted(제한된)` 파드 시큐리티 스탠다드에 대해서는 `warn(경고)` 및 `audit(감사)`하도록 설정한다.

-    ```
-    kubectl label --overwrite ns example \
-      pod-security.kubernetes.io/enforce=baseline \
-      pod-security.kubernetes.io/enforce-version=latest \
-      pod-security.kubernetes.io/warn=restricted \
-      pod-security.kubernetes.io/warn-version=latest \
-      pod-security.kubernetes.io/audit=restricted \
-      pod-security.kubernetes.io/audit-version=latest
-    ```
+   ```shell
+   kubectl label --overwrite ns example \
+     pod-security.kubernetes.io/enforce=baseline \
+     pod-security.kubernetes.io/enforce-version=latest \
+     pod-security.kubernetes.io/warn=restricted \
+     pod-security.kubernetes.io/warn-version=latest \
+     pod-security.kubernetes.io/audit=restricted \
+     pod-security.kubernetes.io/audit-version=latest
+   ```

 ## 파드 시큐리티 스탠다드 검증하기

 1. `example` 네임스페이스에 최소한의 파드를 생성한다.

-    ```shell
-    cat <<EOF > /tmp/pss/nginx-pod.yaml
-    apiVersion: v1
-    kind: Pod
-    metadata:
-      name: nginx
-    spec:
-      containers:
-        - image: nginx
-          name: nginx
-          ports:
-            - containerPort: 80
-    EOF
-    ```
+   ```shell
+   cat <<EOF > /tmp/pss/nginx-pod.yaml
+   apiVersion: v1
+   kind: Pod
+   metadata:
+     name: nginx
+   spec:
+     containers:
+       - image: nginx
+         name: nginx
+         ports:
+           - containerPort: 80
+   EOF
+   ```
+
 1. 클러스터의 `example` 네임스페이스에 해당 파드 스펙을 적용한다.
-    ```shell
-    kubectl apply -n example -f /tmp/pss/nginx-pod.yaml
-    ```
+
+   ```shell
+   kubectl apply -n example -f /tmp/pss/nginx-pod.yaml
+   ```
   다음과 비슷하게 출력될 것이다.
-    ```
-    Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
-    pod/nginx created
-    ```
+
+   ```
+   Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "nginx" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "nginx" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "nginx" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
+   pod/nginx created
+   ```

 1. 클러스터의 `default` 네임스페이스에 해당 파드 스펙을 적용한다.
-    ```shell
-     kubectl apply -n default -f /tmp/pss/nginx-pod.yaml
-    ```
+
+   ```shell
+   kubectl apply -n default -f /tmp/pss/nginx-pod.yaml
+   ```
   다음과 비슷하게 출력될 것이다.
-    ```
-    pod/nginx created
-    ```
+
+   ```
+   pod/nginx created
+   ```

 파드 시큐리티 스탠다드는 `example` 네임스페이스에만 적용되었다. 
 동일한 파드를 `default` 네임스페이스에 생성하더라도 
@@ -149,11 +162,13 @@ namespace/example created
 - 다음의 모든 단계를 한 번에 수행하려면 
  [셸 스크립트](/examples/security/kind-with-namespace-level-baseline-pod-security.sh)를 
  실행한다.
+
  1. KinD 클러스터를 생성
  2. 새로운 네임스페이스를 생성
  3. `baseline` 파드 시큐리티 스탠다드는 `enforce` 모드로 적용하고 
     `restricted` 파드 시큐리티 스탠다드는 `warn` 및 `audit` 모드로 적용
  4. 해당 파드 시큐리티 스탠다드가 적용된 상태에서 새로운 파드를 생성
+
 - [파드 시큐리티 어드미션](/docs/concepts/security/pod-security-admission/)
 - [파드 시큐리티 스탠다드](/docs/concepts/security/pod-security-standards/)
- [파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/)
+- [파드 시큐리티 스탠다드를 클러스터 수준에 적용하기](/ko/docs/tutorials/security/cluster-level-pss/)
@@ -119,7 +119,7 @@ clusterip    ClusterIP   10.0.170.92   <none>        80/TCP    51s
 그리고 동일한 클러스터의 파드에서 `클러스터IP`를 치면:

 ```shell
-kubectl run busybox -it --image=busybox --restart=Never --rm
+kubectl run busybox -it --image=busybox:1.28 --restart=Never --rm
 ```
 출력은 다음과 같다.
 ```
@@ -442,7 +442,7 @@ datadir-zk-2   Bound     pvc-bee0817e-bcb1-11e6-994f-42010a800002   20Gi       R

 `스테이트풀셋`의 컨테이너 `template`의 `volumeMounts` 부분이 ZooKeeper 서버의 데이터 디렉터리에 퍼시스턴트볼륨 마운트하는 내용이다.

-```shell
+```yaml
 volumeMounts:
 - name: datadir
  mountPath: /var/lib/zookeeper
@@ -661,6 +661,8 @@ statefulset rolling update complete 3 pods at revision zk-5db4499664...
 kubectl rollout history sts/zk
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
 statefulsets "zk"
 REVISION
@@ -674,6 +676,8 @@ REVISION
 kubectl rollout undo sts/zk
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
 statefulset.apps/zk rolled back
 ```
@@ -742,14 +746,14 @@ zk-0      1/1       Running   1         29m
 `zk` `스테이트풀셋`에 파드 `template`에 활성도 검사를 명시한다.

 ```yaml
- livenessProbe:
-          exec:
-            command:
-            - sh
-            - -c
-            - "zookeeper-ready 2181"
-          initialDelaySeconds: 15
-          timeoutSeconds: 5
+  livenessProbe:
+    exec:
+      command:
+      - sh
+      - -c
+      - "zookeeper-ready 2181"
+    initialDelaySeconds: 15
+    timeoutSeconds: 5
 ```

 검사는 ZooKeeper의 `ruok` 4 글자 단어를 이용해서 서버의 건강을 테스트하는
@@ -773,7 +777,7 @@ kubectl get pod -w -l app=zk
 다른 창에서 `zk-0` 파드의 파일시스템에서 `zookeeper-ready` 스크립트를 삭제하기 위해 다음 명령어를 이용하자.

 ```shell
-kubectl exec zk-0 -- rm /usr/bin/zookeeper-ready
+kubectl exec zk-0 -- rm /opt/zookeeper/bin/zookeeper-ready
 ```

 ZooKeeper의 활성도 검사에 실패하면,
@@ -860,16 +864,16 @@ kubernetes-node-2g2d
 이는 `zk` `스테이트풀셋`의 파드에 `파드안티어피니티(PodAntiAffinity)`를 지정했기 때문이다.

 ```yaml
-      affinity:
-        podAntiAffinity:
-          requiredDuringSchedulingIgnoredDuringExecution:
-            - labelSelector:
-                matchExpressions:
-                  - key: "app"
-                    operator: In
-                    values:
-                    - zk
-              topologyKey: "kubernetes.io/hostname"
+affinity:
+  podAntiAffinity:
+    requiredDuringSchedulingIgnoredDuringExecution:
+      - labelSelector:
+          matchExpressions:
+            - key: "app"
+              operator: In
+              values:
+                - zk
+        topologyKey: "kubernetes.io/hostname"
 ```

 `requiredDuringSchedulingIgnoredDuringExecution` 필드는
@@ -926,6 +930,8 @@ kubectl get pods -w -l app=zk
 for i in 0 1 2; do kubectl get pod zk-$i --template {{.spec.nodeName}}; echo ""; done
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
 kubernetes-node-pb41
 kubernetes-node-ixsl
@@ -939,6 +945,8 @@ kubernetes-node-i4c4
 kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
 node "kubernetes-node-group-pb41" cordoned

@@ -971,15 +979,19 @@ zk-0      1/1       Running   0         1m
 `zk-1` 이 스케줄된 노드를 비워보자.

 ```shell
-kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned
+kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
+"kubernetes-node-ixsl" cordoned
 WARNING: Deleting pods not managed by ReplicationController, ReplicaSet, Job, or DaemonSet: fluentd-cloud-logging-kubernetes-node-ixsl, kube-proxy-kubernetes-node-ixsl; Ignoring DaemonSet-managed pods: node-problem-detector-v0.1-voc74
 pod "zk-1" deleted
 node "kubernetes-node-ixsl" drained
 ```

+
 `zk-1` 파드는 스케줄되지 않는데 이는 `zk` `StatefulSet`이 오직 2개 노드가 스케줄되도록 파드를 위치시키는 것을 금하는
 `PodAntiAffinity` 규칙을 포함하였기 때문이고 그 파드는 Pending 상태로 남을 것이다.

@@ -987,6 +999,8 @@ node "kubernetes-node-ixsl" drained
 kubectl get pods -w -l app=zk
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      1/1       Running   2          1h
@@ -1017,6 +1031,8 @@ zk-1      0/1       Pending   0         0s
 kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
 node "kubernetes-node-i4c4" cordoned

@@ -1060,6 +1076,8 @@ numChildren = 0
 kubectl uncordon kubernetes-node-pb41
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
 node "kubernetes-node-pb41" uncordoned
 ```
@@ -1070,6 +1088,8 @@ node "kubernetes-node-pb41" uncordoned
 kubectl get pods -w -l app=zk
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
 NAME      READY     STATUS    RESTARTS   AGE
 zk-0      1/1       Running   2          1h
@@ -1103,7 +1123,7 @@ zk-1      1/1       Running   0         13m
 kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
 ```

-출력은
+출력은 다음과 비슷할 것이다.

 ```
 node "kubernetes-node-i4c4" already cordoned
@@ -1121,6 +1141,8 @@ node "kubernetes-node-i4c4" drained
 kubectl uncordon kubernetes-node-ixsl
 ```

+출력은 다음과 비슷할 것이다.
+
 ```
 node "kubernetes-node-ixsl" uncordoned
 ```