Kubernetes Prow Robot
GitHub
commit
a7c220cae9
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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/),
|
||||
at least version 1.4 is required. Like seccomp, AppArmor is also configured
|
||||
auditing through system logs. A default AppArmor profile is enforced on nodes that support it, or a custom profile can be 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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
general availability, the annotations will be replaced with first-class fields.
|
||||
Prior to Kubernetes v1.30, AppArmor was specified through annotations. Use the documentation version
|
||||
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
|
||||
container with, add an annotation to the Pod's metadata:
|
||||
AppArmor profiles can be specified at the pod level or container level. The container AppArmor
|
||||
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>`
|
||||
specifies the profile to apply. The `<profile_ref>` can be one of:
|
||||
Where `<profile_type>` is one of:
|
||||
|
||||
* `runtime/default` to apply the runtime's default profile
|
||||
* `localhost/<profile_name>` to apply the profile loaded on the host with the name `<profile_name>`
|
||||
* `unconfined` to indicate that no profiles will be loaded
|
||||
* `RuntimeDefault` to use the runtime's default profile
|
||||
* `Localhost` to use a profile loaded on the host (see below)
|
||||
* `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>`
|
||||
Where `<container_name>` matches the name of a container in the Pod.
|
||||
A separate profile can be specified for each container in the Pod.
|
||||
- **value**: a profile reference, described below
|
||||
You can specify the `appArmorProfile` on either a container's `securityContext` or on a Pod's
|
||||
`securityContext`. If the profile is set at the pod level, it will be used as the default profile
|
||||
for all containers in the pod (including init, sidecar, and ephemeral containers). If both a pod & container
|
||||
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.
|
||||
- Equivalent to not specifying a profile, except it still requires AppArmor to be enabled.
|
||||
- In practice, many container runtimes use the same OCI default profile, defined here:
|
||||
https://github.com/containers/common/blob/main/pkg/apparmor/apparmor_linux_template.go
|
||||
- `localhost/<profile_name>`: Refers to a profile loaded on the node (localhost) by name.
|
||||
- The possible profile names are detailed in the
|
||||
[core policy reference](https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications).
|
||||
- `unconfined`: This effectively disables AppArmor on the container.
|
||||
`type` _(required)_ - indicates which kind of AppArmor profile will be applied. Valid options are:
|
||||
- `Localhost` - a profile pre-loaded on the node (specified by `localhostProfile`).
|
||||
- `RuntimeDefault` - the container runtime's default profile.
|
||||
- `Unconfined` - no AppArmor enforcement.
|
||||
|
||||
`localhostProfile` - The name of a profile loaded on the node that should be used.
|
||||
The profile must be preconfigured on the node to work.
|
||||
This option must be provided if and only if the `type` is `Localhost`.
|
||||
|
||||
Any other profile reference format is invalid.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Reference in New Issue