Admission Plugins - how to view enabled plugins

Kubernetes
#1

How do I view which plugins are enabled on my apiserver?

When I run the below command and search for a specific plugin (ex PodSecurity) using the below command, I get a long text response and a lot of instances of “PodSecurity”.

How do I figure which list of plugins are the ones that are actually enabled.

Can anyone provide insight?

kubectl exec -n kube-system kube-apiserver-controlplane \
-- kube-apiserver -h | grep enable-admission

Response : --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, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. (DEPRECATED: Use --enable-admission-plugins or --disable-admission-plugins instead. Will be removed in a future version.)
–enable-admission-plugins strings admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.

#2

You’re using the correct procedure from the K8s docs, so those are indeed the “enabled by default” plugins. Unless you do something in addition to plugins in that list (i.e., enable or disable them), they’re on, including PodSecurity.

#3

Thanks Rob, but Im still a little confused:
Making the reply a little more human readable: I see 3x sections: with many duplicates of the same plugin, which section below is the list of the plugins actually enabled? Or am I missing something entirely??

Section 1:

RESPONSE: mission
      --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, ClusterTrustBundleAttest, 
        DefaultIngressClass, DefaultStorageClass, 
        DefaultTolerationSeconds, DenyServiceExternalIPs, 
        EventRateLimit, ExtendedResourceToleration, 
        ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, 
        LimitRanger, MutatingAdmissionWebhook, 
        NamespaceAutoProvision, NamespaceExists, 
        NamespaceLifecycle, NodeRestriction, 
        OwnerReferencesPermissionEnforcement, 
        PersistentVolumeClaimResize, PersistentVolumeLabel, 
        PodNodeSelector, PodSecurity, PodTolerationRestriction, 
        Priority, ResourceQuota, RuntimeClass, 
        SecurityContextDeny, ServiceAccount, 
        StorageObjectInUseProtection, TaintNodesByCondition, 
        ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. 
          (DEPRECATED: Use --enable-admission-plugins or --disable-admission-plugins instead. Will be removed in a future version.)

Section 2:

      --enable-admission-plugins strings       
        admission plugins that should be enabled in addition to default enabled ones 
        (
          NamespaceLifecycle, LimitRanger, 
          ServiceAccount, TaintNodesByCondition, 
          PodSecurity, Priority, 
          DefaultTolerationSeconds, DefaultStorageClass, 
          StorageObjectInUseProtection, PersistentVolumeClaimResize, 
          RuntimeClass, CertificateApproval, 
          CertificateSigning, ClusterTrustBundleAttest, 
          CertificateSubjectRestriction, DefaultIngressClass, 
          MutatingAdmissionWebhook, ValidatingAdmissionPolicy, 
          ValidatingAdmissionWebhook, ResourceQuota
        ).

Section 3:

        Comma-delimited list of admission plugins: 
          AlwaysAdmit, AlwaysDeny, 
          AlwaysPullImages, CertificateApproval, 
          CertificateSigning, CertificateSubjectRestriction, 
          ClusterTrustBundleAttest, DefaultIngressClass, 
          DefaultStorageClass, DefaultTolerationSeconds, 
          DenyServiceExternalIPs, EventRateLimit, 
          ExtendedResourceToleration, ImagePolicyWebhook, 
          LimitPodHardAntiAffinityTopology, LimitRanger, 
          MutatingAdmissionWebhook, NamespaceAutoProvision, 
          NamespaceExists, NamespaceLifecycle, 
          NodeRestriction, OwnerReferencesPermissionEnforcement, 
          PersistentVolumeClaimResize, PersistentVolumeLabel, 
          PodNodeSelector, PodSecurity, 
          PodTolerationRestriction, Priority, 
          ResourceQuota, RuntimeClass, 
          SecurityContextDeny, ServiceAccount, 
          StorageObjectInUseProtection, TaintNodesByCondition, 
          ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. 
          
          The order of plugins in this flag does not matter.
#4

That’s kind of a mess, isn’t it :sunglasses: I would say Section 2 is probably what the docs mean. Although you’d need software lawyer to be sure, I agree.

#5

The documentation tells you which are enabled by default. Add to that any that have been given on the api-server command line.

You can select kube version back to 1.25 with the version drop-down top right on the doc page.

#6

@Alistair_KodeKloud you’d think there’s be an API invocation that would indicate this. 'Tis like reading stereo instructions from the Handbook To The Recently Disceased, that doc page.

handbook-to-the-recently-disceased
handbook-to-the-recently-disceased474×617 41.8 KB

#7

OK - thanks guys, I believe my confusion comes from the fact that all the plugins that are suggested are in fact ENABLED, leading to a lot of duplication in the output. If I run into it on the test Ill just make my best guess.

Many thanks

#8

You would have thought so. There is an API which gets webhook admission controllers you may have installed, but not the enabled built-in ones.