Pod Security Standards and Pod Security Admissions

On the KEP 2579, new proposals were made to replace PSP (Pod Security Policy)

PSP has been replaced with PSA and PSS

For advanced security, we need to use krail, kyverno, opa etc.

Pod Security Admission (PSA)

It’s enabled by default and you may check that by this:

It’s applied at the namespace level.

So, to apply PSA to a namespace, we need to add label pod-security.kubernetes.io/<mode>

Here we applied PSA on the namespace payroll.

Same goes for other namespaces as well

But what is this <mode>=<security standards> mentioned here?

One of the goals of PSA was to make user privilege easier. So, we have 3 profiles available.

We can choose which security standard we want to choose from here.

Then talking about mode, it means what action a control plan should take if the policy is violated.

We can choose one from here.

For example, if we use enforce=Restricted that means mode enforce and policy Restricted, if there is any pod request within our namespace which has privilege different than Restricted, will be rejected.

Make sure to revise Authentication, Authorization, secrets, Namespace, security contexts, network policies

Audit Logging

To know what’s happening in kubernetes, we can check the events list given by kubernetes.

For example, when we want to create a pod, the request goes through kube-api server and passes to etcd. Once accepted, it sent a request to the allocated node’s kubelet to create a pod there.

In this stages, events are created. Each of these activities/stages can be recorded in events

But we don’t want to record every information as it might take a lot of storage. Let’s assume that our goal is to record events of a pod on a specific namespace.

Now, to get the audits from this pod, we will create a policy.

But we can exclude stages which we don’t want to record for our pods. Here RequestReceived was ommited. All the policies we want this policy to match is recorded in the rules section.

For example, assume that we want to record events if pods inside the prod namesapce are detected to specify the namespace within our policy.

Also we can specify which operation to audit. For example, here we want the delete operation to be audited.

if we don’t specify this, every operation like create, delete, update etc will be audited.

Also, now we have to specify the objects we want to observe for logging. For that, we need to provide api-group. Pods belong to the core api group which we mean by “ “. And for resources, we can mention pods.

If we want to track exactly one pod, like here we have webapp-pod, we can specify that now with resourceNames.

Lastly we end with level which has 4 values. The first one is None. If we set this as None, events won’t be logged for the rule. Meaning if the pod called webapp-pod us deleted in the namespace, no events will be logged .

If the value is Metadata, only the metadata such as timestamp, username, resources, verbs etc will be logged

If we use Request, we can get metadata and request body logged.

We can finally use RequestResponse to log the metadata, request body and response body.

So, finally we have our policy file ready with one rule that will record deletions in the prod namespace like this way.

Now assume that, alongside the logs of the pod, we want to see the secrets log from all of the resources. We just have to add this

As namespace is not specified for this secret logs, it will look for all of the namespace and add logs of secrets.

Note: Auditing is disabled by kubernetes and therefore we need to configure an audit backend.

In general ( v1.202), two types of backend is supported. One is log backend that stores audit events to a file on the master node and another one is a web hook backend that rises to a remote web book such as Falco service.

Let’s use the log backend. To do that make use of a specific file where we want to store the audit logs, we have pass in the audit log path flag to the command run by the kube-api server. For kubedm based setup, we need to add the flag in the static pod definition file like this

Here we provided the directory where the log will be written. To apply the policy, we need to apply the policy in this manner

But if kuberapi is running as a service, add like this

We can also set maximum days the audit should be recorded like this. Here 10 days are set.

Also, we can set the maximum number of audit files to be kept on the host using this one.

We can also set the maximum size in megabytes like this

Once done, we need to restart the kube-api server.