This is an idea to maybe get a better reception for project Karydia: instead of generally forbidding the deployment of pods that don't have automountServiceAccountToken set to false wouldn't it better to just add a setting to do that, e.g. automountServiceAccountToken: false?
We could assume that users who set this property to true know what they are doing and leave the setting untouched. On the other hand one could add the (maybe non default) option to deny this:
The policy might then look like this:
apiVersion: karydia.gardener.cloud/v1alpha1
kind: KarydiaSecurityPolicy
metadata:
name: example-restrictive
spec:
pod:
# this would generally deny pods which try to get the token mounted
automountServiceAccountToken: "forbidden"
# this will automatically set the default in case nothing is specified
setDefaultAutomountServiceAccountToken: "false"
seccompProfile: "docker/default"
We might consider setting a default seccomp profile with setDefaultSeccompProfile? We could also have a list of allowed seccomp profiles?
The same could be done for a lot of other settings, some ideas:
hostIPC, hostNetwork, hostPID: those are false by default but we could explicitly forbid those:
Some Other candidates are from the security context or pod security context:
allowPrivilegeEscalation: this could be forbidden but changing its default is probably not needed () run as Privileged 2) has CAP_SYS_ADMIN)
capabilities: we could deny that a user is modifying these but apart from that I would not see further tasks
privileged: default is set to false (OK), we could deny it
runAsNonRoot: this could be set to true if not set. We can still forbid setting it to ' false'
runAsUser: default could be a non null value (e.g. 1000). We could assume that people who set this value explicitly know what they are doing but could deny this as described above.
Note: I am not sure about the impact of the fsGroup setting.
This would lead to the following settings in the security policy:
# this would generally deny pods which try to get the token mounted
automountServiceAccountToken: "forbidden"
# this will automatically set the default in case nothing is specified
setDefaultAutomountServiceAccountToken: "false"
# allowed seccomp profiles
allowedSeccompProfiles: ["a","b "]
# automatically set seccomp profile if not set
setDefaultSeccompProfile: "docker/default"
# deny hostPID, hostNetwork, hostIPC
hostPID: "forbidden"
hostNetwork: "forbidden"
hostIPC: "forbidden"
allowPrivilegeEscalation: "forbidden"
setCapabilites: "forbidden"
allowPrivileged: "forbidden"
allowRoot: "forbidden
setDefaultRunAsUser: 1000
runAsUser0: "forbidden"
That written, a lot of this is covered by pod security policies (the list above would need to be adapted. It may nevertheless be useful because it would not require a user to be restricted and the evaluation could be done by a (mutating) webhook with a resticted user (to not have a double implementation).
This is an idea to maybe get a better reception for project Karydia: instead of generally forbidding the deployment of pods that don't have
automountServiceAccountTokenset tofalsewouldn't it better to just add a setting to do that, e.g.automountServiceAccountToken: false?We could assume that users who set this property to
trueknow what they are doing and leave the setting untouched. On the other hand one could add the (maybe non default) option to deny this:The policy might then look like this:
We might consider setting a default seccomp profile with
setDefaultSeccompProfile? We could also have a list of allowed seccomp profiles?The same could be done for a lot of other settings, some ideas:
falseby default but we could explicitly forbid those:Some Other candidates are from the security context or pod security context:
trueif not set. We can still forbid setting it to ' false'Note: I am not sure about the impact of the fsGroup setting.
This would lead to the following settings in the security policy:
That written, a lot of this is covered by pod security policies (the list above would need to be adapted. It may nevertheless be useful because it would not require a user to be restricted and the evaluation could be done by a (mutating) webhook with a resticted user (to not have a double implementation).