Hello,
apparmor_parser -q /etc/apparmor.d/frontend
This command does not prevent the /internal/ page from being displayed, even though this is what is expected. Why is this?
apparmor_parser takes the apparmor definition file and makes it available to apparmor. But your pods don’t automatically respect the new definition; you need to make a particular pod use apparmor, by adding the needed annotation to it.
So the proposed correction is not complete, if I understand correctly.
What do you mean by “the proposed correction”? You register the apparmor file using the command; you add an annotation to a pod to “opt in” to that code.
Sorry, I should have used the term “solution” instead of “correction”. The solution does not mention the addition of the annotation in the Pod definition.
Where are you looking? The annotation is mentioned in the correction/solutions screen of the mock exam, and is also mentioned in the solutions page of the CKS repo.
From the End of Exam page:
annotations:
container.apparmor.security.beta.kubernetes.io/nginx: localhost/restricted-frontend #Apply profile 'restricted-fronend' on 'nginx' container
This is not the case in the solution after the end of the exam, during the scoring phase.
No, it’s definitely in there. Scroll down a bit; I looked at this today, and the text I copied is from exactly there.
Hello, I am taking my exam in May this year. In the Kubernetes docs (which are for 1.30 version) apparmor has a dedicated spec field now under the appArmorProfile under the securityContext. As far as I know the exam is on Kubernetes 1.29 . How can I use the annotation , would you suggest?
Guessing what LF will do with CKS is something of a fool’s game. The safest approach is to know the 1.29 based annotation approach, and the 1.30 based securityContext. appArmorProfile.type approach. I’m not sure if the annotation approach will even work with 1.30, so if you have the opportunity to test this on a 1.30 system, you should do so.
Hello. Thanks for the response. I have a test cluster with 1.30. I might try it , not really interested though:) cause I found a link Well-Known Labels, Annotations and Taints | Kubernetes
Just one last thing .Watch out for the workload types using replicas spec. Mind you annotation is for the “metadata” template, therefore goes under spec.template.metadata.annotations