-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New policy: Disallow Duplicate Deployment ServiceAccount #595
Comments
@Martin-Weiss, @raif-ahmed can you check the description of the policy to ensure it matches your requirements? |
@flavio Yes this is correct. |
@flavio - do we know if the applications we deliver with rancher already follow this rule (not to use the same service account for more than one deployment / daemon set / stateful set / jobs? And - would this policy not be required for all sets of "deployment / daemon set / stateful set / jobs"? One more thing - we might need a policy that denies the usage of the "default service account in any namespace" forcing applications to create their own, always... (in case someone does not specify a service account in the "deployment / daemon set / stateful set / jobs" at all) |
I don't know about that. We can deploy this policy in
Sorry, I didn't understand it. Can you elaborate a bit on that?
Is using the According to the official docs, the privileges given to it are really really thin:
If using the |
Maybe I misundestood as well - does the policy just look at deployments or at pods or even statefulset/daemonset/job as well? I understood that this policy seems to verify "service account in deployment A vs. service account in deployment B" - but it could also be "service account in deployment A vs. service account in statefulset C". -> so checking for "duplicate / multiple usage of the same service account might need to be done cross-<deployment/daemon-set/job/statefulset/pod> and not just vs
See above.
Similar to using the "default" namespace I would see "using separe service accounts" as a security recommendation similar to "do not share security accounts". This might be relevant from an auditing point of view - which process used which account do do x,y,z..? So a policy that denies the usage of the default service account might also improve security (but not sure what this will break :-))
What is "best" practice ;-) and what is the attach surface.. - IMO using a default user in general is not a good practice these days.. (root / administrator) ... |
You're right. The check was not going to be done across different Kubernetes types. I'll update the card.
I'm afraid many things would break by denying the usage of the settings:
deny_usage_of_default_service_account: true # false by default EDIT: I've updated the description of the issue to reflect the new requirements |
Thanks - and yes - I am sure that many things will break when we deny usage of default service account. From a security point if view I still think that "personalized service accounts" should be better than "default" - especially when looking into auditing... (bumpy road in front of us ;-) ) - but let users decide and I agree with the default "false".. |
Description
Policy to check if every Deployment is using a unique service account, and rejects if the deployment's service account is already in use by a existing deployment.
In the 1st iteration the policy ensures no duplicated Service Account are used between Deployment resources located inside of the same Namespace. Future iterations should also look for duplication between other workload related Kubernetes resources. For example, it should deny the creation of a Deployment/Pod that uses the Service Account assigned to a CronJob.
Configuration
The policy uses this configuration format:
By default, the policy allows the usage of the
default
Service Account that Kubernetes maintains inside of each Namespace. However, the Kubewarden administrator can prevent the usage of thedefault
namespace by settingdeny_usage_of_default_service_account
totrue
.Examples
Given the following Deployment is already defined:
The creation of the following Deployment is going to be accepted:
The creation is allowed because the
serviceAccountName
is different.The creation of the following Deployment is not going to be allowed:
The creation is rejected because the
nginx
service account is already in use by thenginx-deployment
resource.The creation of the following Deployment is going to be accepted:
The creation is allowed despite the workload using the
nginx
service account. That happens because this deployment is done inside of a different Namespace (staging
vsdefault
).Notes
This is going to be a context aware policy that requires access to the
Deployment
resourcesThe text was updated successfully, but these errors were encountered: