I don’t get why the apparmor rule in the security context works only inside the containers definition.
The correct solution should be this:
apiVersion: v1
kind: Pod
metadata:
labels:
run: nginx
name: frontend-site
namespace: omni
spec:
securityContext:
appArmorProfile:
type: Localhost
localhostProfile: restricted-frontend
serviceAccountName: frontend-default #Use the service account with least privileges
containers:
- image: nginx:alpine
name: nginx
volumeMounts:
- mountPath: /usr/share/nginx/html
name: test-volume
volumes:
- name: test-volume
hostPath:
path: /data/pages
type: Directory
But the “/internal/” route is still not protected. Infact the exercise check gives error.
But even in the documentation, securityContext with AppArmor can be under spec, same level of containers:
Actually, it does work. Here’s what I think is going on in your case, however. When you save the YAML for frontend-site, it contains a line towards the bottom that says:
securityContext: {}
If you don’t delete this, this line will override the securityContext you created right after spec:. Which I think is what happened.
I used your securityContext exactly as you wrote it, but I commented out the securityContext lower in the file, and the dog in the blanket is gone, gone, gone. So very likely that’s what you did. Please note that until you remove the lower securityContext, the under-the-container version will work, but not the under-spec version.