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

content/ko/docs/tutorials/security/apparmor.md

@@ -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)에 설명되어 있다.