runtime serviceacount recommended policies are incorrectly formed

[nyrahul]

apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
  name: wordpress-wordpress-4-8-apache-block-serviceaccount-runtime
  namespace: wordpress-mysql
spec:
  action: Block
  file:
    matchDirectories:
    - dir: /var/run/secrets/kubernetes.io/serviceaccount/
      recursive: true
    - dir: /run/secrets/kubernetes.io/serviceaccount/
      recursive: true
  message: serviceaccount access blocked
  selector:
    matchLabels:
      app: wordpress
  severity: 1
  tags:
  - KUBERNETES
  - SERVICE ACCOUNT
  - RUNTIME POLICY

Why are there two directories for service account in the policy?

[vishnusomank]

@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.

[daemon1024]

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?

[vishnusomank]

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?

[wazir-ahmed]

@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.

[daemon1024]

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.

[vishnusomank]

@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

[wazir-ahmed]

@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.

[vishnusomank]

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?