CKAD course labs-PSP

Kubernetes
#1

In the Q4 of the lab it makes you to check if the PodSecurityPolicy admission controller is enabled. It tells to use the command of kube-apiserver -h but when executing it the controller appears in enabled and disabled at the same time. How to know what’s happening indeed?

root@controlplane ~ ➜  k exec -n kube-system kube-apiserver-controlplane -- kube-apiserver -h | grep -i admission-plugins | grep -i podsecurity
      --admission-control strings              Admission is divided into two phases. In the first phase, only mutating admission plugins run. In the second phase, only validating admission plugins run. The names in the below list may represent a validating plugin, a mutating plugin, or both. The order of plugins in which they are passed to this flag does not matter. Comma-delimited list of: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. (DEPRECATED: Use --enable-admission-plugins or --disable-admission-plugins instead. Will be removed in a future version.)
      --disable-admission-plugins strings      admission plugins that should be disabled although they are in the default enabled plugins list (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
      --enable-admission-plugins strings       admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyEscalatingExec, DenyExecOnPrivileged, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.
#2

Hi @hyakunin

You have executed kube-apiserver -h above, which is short for kube-apiserver --help

However, the k8s documentation states that whatever is in the help for --enable-admission-plugins is the list of plugins that are enabled by default.

If you want to turn off any of the default plugins, then you specify one or more of these with --disable-admission-plugins which is why the lists are the same.

So, to thin out the amount of data returned, just tune the greps a bit

kubectl exec -n kube-system kube-apiserver-controlplane -- kube-apiserver -h | \
  grep -v admission-control | \
  grep enable-admission-plugins | \
  grep PodSecurityPolicy
#3

hi @Alistair_KodeKloud ,

when executing your command or mine the result is that the psp is listed as enabled. However, in the question the psp had to be enabled in the kube-apiserver.yaml. So despite being in the documentation and in the lab as a way to check the admission controller is or not enabled, it’s not a valid metho. Seems as checking the manifest is the way to go

#4

Hi,

Checking the help output should tell you what is enabled by default - anything added to the manifest should be additional plugins.
Also what is enabled by default varies from version to version.

However if the lab is asking for you to explicitly enable it, then the validation script will test the manifest for the presence of it in --enable-admission-plugins. It will be more about “can you edit the manifest to add a plugin successfully”.

#5

well, it shows as enabled by default in the -h option. However, in the exercise the PSP has to be added in the kube-apiserver. This is why looking at the -h option is not a valid method to know if the PSP is now enabled.

#6

Not in the context of this question, no - you are simply explicitly enabling a plugin that’s already enabled by default.
It is no more than an exercise in editing the kube-apiserver manifest.

If you were deploying a new custom admission webhook, then there would be a bunch of manifests to apply (CRDs and a deployment for the webhook’s container), then it would need enabling with --enable-admission-plugins

1 Like