Doubt on CKS challenge 1

Kubernetes
#1

I have couple of doubts. on the challenge 1 task

There are 6 images listed in the diagram on the right. Using Aquasec Trivy (which is already installed on the controlplane node), identify the image that has the least number of critical vulnerabilities and use it to deploy the alpha-xyz deployment.

Secure this deployment by enforcing the AppArmor profile called custom-nginx.

Expose this deployment with a ClusterIP type service and make sure that only incomings connections from the pod called middleware is accepted and everything else is rejected.

Doubt1: the task says Secure this deployment by enforcing the AppArmor profile called custom-nginx.
according to github answers the apparmor profile is applied at container level. Why can’t the profile custom-nginx applied at pod level. The task did not specify exclusively to apply at container level.

Doubt 2: only incomings connections from the pod called middleware is accepted and everything else is rejected.
I have applied 2 policies
Policy 1: default-deny-all. Below is the yaml format. Since it says everything else is rejected.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: alpha
spec:
podSelector: {}
policyTypes:

  • Ingress
  • Egress
    Policy 2: restrict-inbound. I have applied this for only the deployment pods using labels and selectors. Below is the yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-inbound
namespace: alpha
spec:
podSelector:
matchLabels:
app: alpha-xyz
policyTypes:

  • Ingress
    ingress:
  • from:
    • podSelector:
      matchLabels:
      app: middleware
      ports:
    • protocol: TCP
      port: 80

When clicked on check button, i am getting tasks not completed. When i delete default-deny-all network policy then only the tasks are showing completed.

Could you please let me know why default-deny-all can’t be applied here in this specific task?

Can someone please clarify?

#2

I’ll take a quick look at the trivy issue. One thing you can do as far as the AppArmor question goes: please use a

code block like this
  to preserve indentation
  and not corrupt special characters like ' or "

You can learn more about formatting by reading this page.

#3

  1. If I remember right, declaring appArmor support as a securityContext:.appArmorProfile: block (rather than as an annotation) came in as of v1.30, and it was a bit wonky – declaring it at the container level worked, but at the spec level, it did not work. This appears to be fixed in v1.31. So we implement it at the container level, and that’s what the grader checks. We probably could accept the spec level block as well now, but we currently do not.

  2. I believe that a single network policy targeting app=alpha-xyz allowing ingress from app=middleware suffices to solve the problem; the extra default deny policy is unneeded since you already have the one policy on the deployment’s pods.

#4

thank you so much for clarification rob. Appreciate your help here.