07-Labs-Validating-and-Mutating-Admission-Controllers.md

Lab - Validating and Mutating Admission Controllers

• Take me to the Lab

Solutions Lab - Validating and Mutating Admission Controllers:

• NamespaceAutoProvision- Mutating , NamespaceExists - Validating is correct for Mutating and validating admission controllers.

• First Mutating then Validating is the flow of invocation of admission controllers.

• Create a namespace webhook-demo where we will deploy webhook components.

  Run
  $ kubectl create ns webhook-demo
  

• Create TLS secret webhook-server-tls for secure webhook communication in webhook-demo namespace.

  Run
  $ kubectl -n webhook-demo create secret tls webhook-server-tls \
    --cert "/root/keys/webhook-server-tls.crt" \
    --key "/root/keys/webhook-server-tls.key"
  

• Create a webhook deployment

  Run
  $ kubectl create -f /root/webhook-deployment.yaml
  

• Create a webhook service

  Run
  $ kubectl create -f /root/webhook-service.yaml
  

• If we apply the configuration by adding MutatingWebhookConfiguration, which resources and actions would be affected

  Pod with CREATE operations
  

• Deploy MutatingWebhookConfiguration

  Run
  $ kubectl create -f /root/webhook-configuration.yaml
  

• Deploy a pod with no securityContext specified.

  Run
  $ kubectl apply -f /root/pod-with-defaults.yaml
  

• What are runAsNonRoot and runAsUser values for previously created pods securityContext?

  runAsNonRoot: true , runAsUser: 1234
  

• Deploy pod with a securityContext explicitly allowing it to run as root.

  Run
  $ kubectl apply -f /root/pod-with-override.yaml
  Then validate with
  $ kubectl get po pod-with-override -o yaml | grep -A2 " securityContext:"