@@ -382,27 +382,13 @@ If you do not want AppArmor to be available on your cluster, it can be disabled
382
382
```
383
383
384
384
When disabled, any Pod that includes an AppArmor profile will fail validation with a "Forbidden"
385
- error. Note that by default docker always enables the "docker-default" profile on non-privileged
386
- pods (if the AppArmor kernel module is enabled), and will continue to do so even if the feature-gate
387
- is disabled. The option to disable AppArmor will be removed when AppArmor graduates to general
388
- availability (GA).
389
-
390
- ### Upgrading to Kubernetes v1.4 with AppArmor
391
-
392
- No action is required with respect to AppArmor to upgrade your cluster to v1.4. However, if any
393
- existing pods had an AppArmor annotation, they will not go through validation (or PodSecurityPolicy
394
- admission). If permissive profiles are loaded on the nodes, a malicious user could pre-apply a
395
- permissive profile to escalate the pod privileges above the docker-default. If this is a concern, it
396
- is recommended to scrub the cluster of any pods containing an annotation with
397
- ` apparmor.security.beta.kubernetes.io ` .
398
-
399
- ### Upgrade path to General Availability
385
+ error.
400
386
401
- When AppArmor is ready to be graduated to general availability (GA), the options currently specified
402
- through annotations will be converted to fields. Supporting all the upgrade and downgrade paths
403
- through the transition is very nuanced, and will be explained in detail when the transition
404
- occurs. We will commit to supporting both fields and annotations for at least 2 releases, and will
405
- explicitly reject the annotations for at least 2 releases after that.
387
+ {{< note >}}
388
+ Even if the Kubernetes feature is disabled, runtimes may still enforce the default profile. The
389
+ option to disable the AppArmor feature will be removed when AppArmor graduates to general
390
+ availability (GA).
391
+ {{</ note >}}
406
392
407
393
## Authoring Profiles
408
394
@@ -415,10 +401,6 @@ tools to help with that:
415
401
* [ bane] ( https://github.com/jfrazelle/bane ) is an AppArmor profile generator for Docker that uses a
416
402
simplified profile language.
417
403
418
- It is recommended to run your application through Docker on a development workstation to generate
419
- the profiles, but there is nothing preventing running the tools on the Kubernetes node where your
420
- Pod is running.
421
-
422
404
To debug problems with AppArmor, you can check the system logs to see what, specifically, was
423
405
denied. AppArmor logs verbose messages to ` dmesg ` , and errors can usually be found in the system
424
406
logs or through ` journalctl ` . More information is provided in
@@ -441,9 +423,8 @@ Specifying the profile a container will run with:
441
423
- ` runtime/default ` : Refers to the default runtime profile.
442
424
- Equivalent to not specifying a profile (without a PodSecurityPolicy default), except it still
443
425
requires AppArmor to be enabled.
444
- - For Docker, this resolves to the
445
- [ ` docker-default ` ] ( https://docs.docker.com/engine/security/apparmor/ ) profile for non-privileged
446
- containers, and unconfined (no profile) for privileged containers.
426
+ - In practice, many container runtimes use the same OCI default profile, defined here:
427
+ https://github.com/containers/common/blob/main/pkg/apparmor/apparmor_linux_template.go
447
428
- ` localhost/<profile_name> ` : Refers to a profile loaded on the node (localhost) by name.
448
429
- The possible profile names are detailed in the
449
430
[ core policy reference] ( https://gitlab.com/apparmor/apparmor/wikis/AppArmor_Core_Policy_Reference#profile-names-and-attachment-specifications ) .
@@ -474,5 +455,3 @@ Additional resources:
474
455
475
456
* [ Quick guide to the AppArmor profile language] ( https://gitlab.com/apparmor/apparmor/wikis/QuickProfileLanguage )
476
457
* [ AppArmor core policy reference] ( https://gitlab.com/apparmor/apparmor/wikis/Policy_Layout )
477
-
478
-
0 commit comments