runtime serviceacount recommended policies are incorrectly formed about kubearmor-client HOT 8 OPEN

@daemon1024 We already the feature to create service account policy which allows only certain binaries in the Pod to access the token (based on the observability data from discovery-engine) - Ref.

The only addition I see in what you're saying is.. To also recommend a list of deployments which requires automountServiceAccountToken: false.

Correct me if I'm missing something here.

from kubearmor-client.

The only addition I see in what you're saying is.. To also recommend a list of deployments which requires automountServiceAccountToken: false.

Right! Not mounting at all is more secure than Blocking access to the mount.

from kubearmor-client.

@nyrahul The SA directories were selected based on the comment by @wazir-ahmed

The actual path k8s injects the SA is /var/run (Ref: https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#serviceaccount-admission-controller)
Ideally, applications should only access the /var/run SA path. But in Linux, since it is common to see the symlink /run --> /var/run, the process running in the pod might use the /run SA path.

from kubearmor-client.

Quick suggestion,

Since we have runtime visibility, why don't we do this the k8s way,

We suggest users to set automount for Service account tokens to false. And tell them in what pods they need to mount it. In addition to that tell them which binaries in the Pod need access to that. (KubeArmor policy)
https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server

WDYT?

from kubearmor-client.

Rather than asking the user to set automount to false, If we recommend a KubeArmor policy to deny/allow access to the serviceaccount based on runtime data (current scenario) will be better right?

from kubearmor-client.

@wazir-ahmed yes it is generated by recommend.createRuntimePolicy() @nyrahul asked to update the logic to show a deny serviceaccount policy if no process is accessing it

from kubearmor-client.

@wazir-ahmed yes it is generated by recommend.createRuntimePolicy() @nyrahul asked to update the logic to show a deny serviceaccount policy if no process is accessing it

@vishnusomank Yeah. I just checked the latest code.

from kubearmor-client.

The only addition I see in what you're saying is.. To also recommend a list of deployments which requires automountServiceAccountToken: false.

Right! Not mounting at all is more secure than Blocking access to the mount.

so it'll be printed as an info to the user rather than a block policy?

from kubearmor-client.