Mutate service token pod webhook

[dacappo]

Description

Introduces a new option remove-default for karydia.gardener.cloud/automountServiceAccountToken. When this option is configured for a namespace, all pods that do not explicitly require the default service account do not mount the default token. The mutating hook removes the default service account token volume mount for each container and pod definition.

Additionally, unit-tests for the existing options non-default and forbidden were implemented.

Adressing issue #55.

Checklist

Before submitting this PR, please make sure:

• [x] Your code builds clean with make test
• [x] You have added unit tests
• [x] You have documented new or changed features

[marwinski]

We have had a lengthy discussion on the automountServiceAccountToken issue today. It appears we might want something that we have not implemented and not thought of so far. Lets look at the automountServiceAccountToken setting which can be configured both on the service account and pod level. We have checked the non-obvious combinations and listed all of them in the table below:

#	service account	pod	token mounted
1	true	true	true
2	false	true	true
3	true	false	false
4	false	false	false
5	not defined	not defined	true
6	not defined	true	true
7	not defined	false	false
8	true	not defined	true
9	false	not defined	false

Service accounts are generally not problematic from a security point of view or evil but can be dead useful. There is however a certain danger of accidentally allowing attackers more privileges than they should have.

We can assume that users know what they are doing when they explicitly specify automountServiceAccountToken in their pod spec. This means that lines 1,2,6 should not be problematic. The service account token is not mounted in lines 3,4,7. This leaves lines 5,8,9 where in cases 5 and 8 the token could be accidentally mounted.

I would further assume that "accidents" mainly happen with the default service account (which is the default for pods). If a user specifies another service account mounting the token is probably desired and possible security implications might be addressed.

automountServiceAccountToken is not specified by default on the default service account so it will be mounted into pods if users do not specifically set the property to false.

Trying to forbid mounting the service account token will not work, see the Kubernetes documentation: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token. If automountServiceAccount token is forbidden user can easily create a secret and mount that into the pod.

Based on the discussion above I propose the following: Recocile an automountServiceAccountToken: false into all default service accounts unless the namespace specifies a particular annotation.