EKS: Edit the API's AdmissionController

0

Hi, with the release of EKS 1.23 and 1.24 we are moving ever closer to the full removal of the PodSecurityPolicy. To replace this the PodSecurity admission controller has been graduated to the beta branch and is now enabled by default. To enforce security we now need to add labels to namespaces, but Kubernetes also allows you to have full control over the AdmissionController's default settings or at least it should according to this article.

My question is: how do I edit the AdmissionController to change the default settings to be more or less restrictive? I am not a super advanced Kubernetes nerd yet, but I think this AdmissionController configuration is supposed to be done on the Kubernetes API server? If that's true, how do I edit it since EKS hides that from me.

Thanks

1 Answer
0

First, I would look into this blog post that explains how PSA/PSS is used on Amazon EKS. It is based on testing we did and publsihed in this GitHub repository. As far as customizing PSA settings, that should be done via namespace levels. As a general rule, Amazon EKS does not permit customizations at the API server level:

"In order to ensure operational stability and maintain our SLA, Amazon EKS does not allow custom configuration of API server settings. Amazon EKS will evaluate requests for custom configurations on a case by case basis, and may allow a setting to be configured if there is enough customer demand. As an example, the Amazon EKS API supports OIDC user authentication, which is then passed as API server flags when a cluster is started."

At this time, you cannot customize the API settings for PSA on Amazon EKS. The default settings come from cluster creation, and you can opt in to different PSS profiles and PSA modes via namespace labels. However, customization of PSA, such as exemptions, can be had, without needing to customize API server settings, using Policy-as-Code (PaC) solutions. In particular, Kyverno 1.8 offers new functionality to customize your PSA/PSS settings, with their new rule type validate.podSecurity :

  • Cluster-wide pod security defaults do not require updating the static configuration file
  • Namespace level pod security application does not require labels
  • Pod security checks are automatically applied to pod controllers (e.g. deployments)
  • Granular exemptions can be configured at a container image level
  • Violations are reported in an in-cluster report
  • Static validation and testing can be performed via the Kyverno CLI without requiring a cluster
profile picture
answered 18 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions