AppArmor v1.30 docs update

content/en/docs/concepts/security/cloud-native-security.md

@@ -143,7 +143,7 @@ To protect your compute at runtime, you can:
    Pods with different trust contexts are run on separate sets of nodes.
 1. Use a {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
    that provides security restrictions.
-1. On Linux nodes, use a Linux security module such as [AppArmor](/docs/tutorials/security/apparmor/) (beta)
+1. On Linux nodes, use a Linux security module such as [AppArmor](/docs/tutorials/security/apparmor/)
    or [seccomp](/docs/tutorials/security/seccomp/).
 
 ### Runtime protection: storage {#protection-runtime-storage}
@@ -223,4 +223,3 @@ logs are both tamper-proof and confidential.
 * [Network policies](/docs/concepts/services-networking/network-policies/) for Pods
 * [Pod security standards](/docs/concepts/security/pod-security-standards/)
 * [RuntimeClasses](/docs/concepts/containers/runtime-class)
-

content/en/docs/concepts/security/pod-security-admission.md

@@ -121,7 +121,7 @@ current policy level:
 - Any metadata updates **except** changes to the seccomp or AppArmor annotations:
   - `seccomp.security.alpha.kubernetes.io/pod` (deprecated)
   - `container.seccomp.security.alpha.kubernetes.io/*` (deprecated)
-  - `container.apparmor.security.beta.kubernetes.io/*`
+  - `container.apparmor.security.beta.kubernetes.io/*` (deprecated)
 - Valid updates to `.spec.activeDeadlineSeconds`
 - Valid updates to `.spec.tolerations`
 

content/en/docs/concepts/security/pod-security-standards.md

@@ -170,8 +170,21 @@ fail validation.
 		<tr>
 			<td style="white-space: nowrap">AppArmor</td>
 			<td>
-				<p>On supported hosts, the <code>runtime/default</code> AppArmor profile is applied by default. The baseline policy should prevent overriding or disabling the default AppArmor profile, or restrict overrides to an allowed set of profiles.</p>
+				<p>On supported hosts, the <code>RuntimeDefault</code> AppArmor profile is applied by default. The baseline policy should prevent overriding or disabling the default AppArmor profile, or restrict overrides to an allowed set of profiles.</p>
 				<p><strong>Restricted Fields</strong></p>
+				<ul>
+					<li><code>spec.securityContext.appArmorProfile.type</code></li>
+					<li><code>spec.containers[*].securityContext.appArmorProfile.type</code></li>
+					<li><code>spec.initContainers[*].securityContext.appArmorProfile.type</code></li>
+					<li><code>spec.ephemeralContainers[*].securityContext.appArmorProfile.type</code></li>
+				</ul>
+				<p><strong>Allowed Values</strong></p>
+				<ul>
+					<li>Undefined/nil</li>
+					<li><code>RuntimeDefault</code></li>
+					<li><code>Localhost</code></li>
+				</ul>
+				<hr />
 				<ul>
 					<li><code>metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]</code></li>
 				</ul>
@@ -532,4 +545,3 @@ kernel. This allows for workloads requiring heightened permissions to still be i
 
 Additionally, the protection of sandboxed workloads is highly dependent on the method of
 sandboxing. As such, no single recommended profile is recommended for all sandboxed workloads.
-

content/en/docs/concepts/security/security-checklist.md

@@ -177,10 +177,10 @@ Seccomp is only available on Linux nodes.
 
 #### AppArmor
 
-[AppArmor](https://apparmor.net/) is a Linux kernel security module that can
+[AppArmor](/docs/tutorials/security/apparmor/) is a Linux kernel security module that can
 provide an easy way to implement Mandatory Access Control (MAC) and better
-auditing through system logs. To [enable AppArmor in Kubernetes](/docs/tutorials/security/apparmor/),
+auditing through system logs. A default AppArmor profile is enforced on nodes that support it, or a custom profile can be configured.
-at least version 1.4 is required. Like seccomp, AppArmor is also configured
+Like seccomp, AppArmor is also configured
 through profiles, where each profile is either running in enforcing mode, which
 blocks access to disallowed resources or complain mode, which only reports
 violations. AppArmor profiles are enforced on a per-container basis, with an

content/en/docs/reference/labels-annotations-taints/_index.md

@@ -300,7 +300,7 @@ which is used by Kustomize and similar third-party tools.
 For example, Kustomize removes objects with this annotation from its final build output.
 
 
-### container.apparmor.security.beta.kubernetes.io/* (beta) {#container-apparmor-security-beta-kubernetes-io}
+### container.apparmor.security.beta.kubernetes.io/* (deprecated) {#container-apparmor-security-beta-kubernetes-io}
 
 Type: Annotation
 
@@ -309,7 +309,7 @@ Example: `container.apparmor.security.beta.kubernetes.io/my-container: my-custom
 Used on: Pods
 
 This annotation allows you to specify the AppArmor security profile for a container within a
-Kubernetes pod. 
+Kubernetes pod. As of Kubernetes v1.30, this should be set with the `appArmorProfile` field instead.
 To learn more, see the [AppArmor](/docs/tutorials/security/apparmor/) tutorial.
 The tutorial illustrates using AppArmor to restrict a container's abilities and access.
 

content/en/docs/tasks/debug/debug-cluster/_index.md

@@ -203,7 +203,7 @@ status:
     type: PIDPressure
   - lastHeartbeatTime: "2022-02-17T22:20:15Z"
     lastTransitionTime: "2022-02-17T22:15:15Z"
-    message: kubelet is posting ready status. AppArmor enabled
+    message: kubelet is posting ready status
     reason: KubeletReady
     status: "True"
     type: Ready
@@ -330,4 +330,3 @@ This is an incomplete list of things that could go wrong, and how to adjust your
 * Use `crictl` to [debug Kubernetes nodes](/docs/tasks/debug/debug-cluster/crictl/)
 * Get more information about [Kubernetes auditing](/docs/tasks/debug/debug-cluster/audit/)
 * Use `telepresence` to [develop and debug services locally](/docs/tasks/debug/debug-cluster/local-debugging/)
-

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

@@ -8,7 +8,7 @@ weight: 30
 
 <!-- overview -->
 
-{{< feature-state for_k8s_version="v1.4" state="beta" >}}
+{{< feature-state feature_gate_name="AppArmor" >}}
 
 
 [AppArmor](https://apparmor.net/) is a Linux kernel security module that supplements the standard Linux user and group based
@@ -54,7 +54,7 @@ Nodes before proceeding:
    Y
    ```
 
-   The Kubelet verifies that AppArmor is enabled on the host before admitting a pod with AppArmor
+   The kubelet verifies that AppArmor is enabled on the host before admitting a pod with AppArmor
    explicitly configured.
 
 3. Container runtime supports AppArmor -- All common Kubernetes-supported container
@@ -64,7 +64,7 @@ Nodes before proceeding:
 
 4. Profile is loaded -- AppArmor is applied to a Pod by specifying an AppArmor profile that each
    container should be run with. If any of the specified profiles are not loaded in the
-   kernel, the Kubelet will reject the Pod. You can view which profiles are loaded on a
+   kernel, the kubelet will reject the Pod. You can view which profiles are loaded on a
    node by checking the `/sys/kernel/security/apparmor/profiles` file. For example:
 
    ```shell
@@ -85,25 +85,26 @@ Nodes before proceeding:
 ## Securing a Pod
 
 {{< note >}}
-AppArmor is currently in beta, so options are specified as annotations. Once support graduates to
+Prior to Kubernetes v1.30, AppArmor was specified through annotations. Use the documentation version
-general availability, the annotations will be replaced with first-class fields.
+selector to view the documentation with this deprecated API.
 {{< /note >}}
 
-AppArmor profiles are specified *per-container*. To specify the AppArmor profile to run a Pod
+AppArmor profiles can be specified at the pod level or container level. The container AppArmor
-container with, add an annotation to the Pod's metadata:
+profile takes precedence over the pod profile.
 
 ```yaml
-container.apparmor.security.beta.kubernetes.io/<container_name>: <profile_ref>
+securityContext:
+  appArmorProfile:
+    type: <profile_type>
 ```
 
-Where `<container_name>` is the name of the container to apply the profile to, and `<profile_ref>`
+Where `<profile_type>` is one of:
-specifies the profile to apply. The `<profile_ref>` can be one of:
 
-* `runtime/default` to apply the runtime's default profile
+* `RuntimeDefault` to use the runtime's default profile
-* `localhost/<profile_name>` to apply the profile loaded on the host with the name `<profile_name>`
+* `Localhost` to use a profile loaded on the host (see below)
-* `unconfined` to indicate that no profiles will be loaded
+* `Unconfined` to run without AppArmor
 
-See the [API Reference](#api-reference) for the full details on the annotation and profile name formats.
+See the [API Reference](#api-reference) for the full details on the AppArmor profile API.
 
 To verify that the profile was applied, you can check that the container's root process is
 running with the correct profile by examining its proc attr:
@@ -115,14 +116,14 @@ kubectl exec <pod_name> -- cat /proc/1/attr/current
 The output should look something like this:
 
 ```
-k8s-apparmor-example-deny-write (enforce)
+cri-containerd.apparmor.d (enforce)
 ```
 
 ## Example
 
 *This example assumes you have already set up a cluster with AppArmor support.*
 
-First, load the profile you want to use onto your Nodes. This profile denies all file writes:
+First, load the profile you want to use onto your Nodes. This profile blocks all file write operations:
 
 ```
 #include <tunables/global>
@@ -197,9 +198,11 @@ apiVersion: v1
 kind: Pod
 metadata:
   name: hello-apparmor-2
-  annotations:
-    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-allow-write
 spec:
+  securityContext:
+    appArmorProfile:
+      type: Localhost
+      localhostProfile: k8s-apparmor-example-allow-write
   containers:
   - name: hello
     image: busybox:1.28
@@ -243,7 +246,7 @@ An Event provides the error message with the reason, the specific wording is run
 
 ### Setting up Nodes with profiles
 
-Kubernetes does not currently provide any built-in mechanisms for loading AppArmor profiles onto
+Kubernetes {{< skew currentVersion >}} does not provide any built-in mechanisms for loading AppArmor profiles onto
 Nodes. Profiles can be loaded through custom infrastructure or tools like the
 [Kubernetes Security Profiles Operator](https://github.com/kubernetes-sigs/security-profiles-operator).
 
@@ -270,29 +273,31 @@ logs or through `journalctl`. More information is provided in
 [AppArmor failures](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Failures).
 
 
-## API Reference
+## Specifying AppArmor confinement
 
-### Pod Annotation
+{{< caution >}}
+Prior to Kubernetes v1.30, AppArmor was specified through annotations. Use the documentation version
+selector to view the documentation with this deprecated API.
+{{< /caution >}}
 
-Specifying the profile a container will run with:
+### AppArmor profile within security context {#appArmorProfile}
 
-- **key**: `container.apparmor.security.beta.kubernetes.io/<container_name>`
+You can specify the `appArmorProfile` on either a container's `securityContext` or on a Pod's
-  Where `<container_name>` matches the name of a container in the Pod.
+`securityContext`. If the profile is set at the pod level, it will be used as the default profile
-  A separate profile can be specified for each container in the Pod.
+for all containers in the pod (including init, sidecar, and ephemeral containers). If both a pod & container
-- **value**: a profile reference, described below
+AppArmor profile are set, the container's profile will be used.
 
-### Profile Reference
+An AppArmor profile has 2 fields:
 
-- `runtime/default`: Refers to the default runtime profile.
+`type` _(required)_ - indicates which kind of AppArmor profile will be applied. Valid options are:
-  - Equivalent to not specifying a profile, except it still requires AppArmor to be enabled.
+	- `Localhost` - a profile pre-loaded on the node (specified by `localhostProfile`).
-  - In practice, many container runtimes use the same OCI default profile, defined here:
+	- `RuntimeDefault` - the container runtime's default profile.
-    https://github.com/containers/common/blob/main/pkg/apparmor/apparmor_linux_template.go
+	- `Unconfined` - no AppArmor enforcement.
-- `localhost/<profile_name>`: Refers to a profile loaded on the node (localhost) by name.
+
-  - The possible profile names are detailed in the
+`localhostProfile` - The name of a profile loaded on the node that should be used.
-    [core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications).
+The profile must be preconfigured on the node to work.
-- `unconfined`: This effectively disables AppArmor on the container.
+This option must be provided if and only if the `type` is `Localhost`.
 
-Any other profile reference format is invalid.
 
 ## {{% heading "whatsnext" %}}
 

content/en/examples/pods/security/hello-apparmor.yaml

@@ -2,10 +2,11 @@ apiVersion: v1
 kind: Pod
 metadata:
   name: hello-apparmor
-  annotations:
-    # Tell Kubernetes to apply the AppArmor profile "k8s-apparmor-example-deny-write".
-    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-example-deny-write
 spec:
+  securityContext:
+    appArmorProfile:
+      type: Localhost
+      localhostProfile: k8s-apparmor-example-deny-write
   containers:
   - name: hello
     image: busybox:1.28