-
Notifications
You must be signed in to change notification settings - Fork 8
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
Determine the minimal set of roles/privileges needed for the service accounts #368
Comments
Update: Concent Cloud Admin needs to be able to use other service accounts after all. |
Needed roles
Concent Cloud Admin:
|
This service account also has permission to granting roles to specific instances but not in project level. |
Read/write access to secrets (including deleting them) is fine for this role. The most sensitive part is actually reading anyway and we can't take that away. Being able to use the wrong passwords or delete passwords stored on the cluster is not the kind of damage we're worried about.
Let's go with the second option but with permissions only for specific buckets. So for now only the bucket that we use as a registry. We also want Bucket Policy Only
Let's create a custom role.
Well, OK. I see there's no other way. Let's allow Concent Cloud Admin to do both.
Why? Isn't it enough to be able to assign a service account to an instance? |
I see that it's hard to limit Concent Cloud Admin's privileges in a significant way. So let's focus on Concent Deployer. Limiting its access is actually more important because its has a much bigger attack surface. Please make sure that this service account by itself does not allow getting SSH access to any other machines. Also, it would be best if Lastly, please don't forget to document the privileges in the |
Currently service accounts in our Google Cloud project have broad privileges. This would allow someone who managed to break into our build or deployment server to take control not only over that server but also over many aspects of the whole Google Cloud project. To limit these privileges we first need to find out which ones we actually need.
On the provisioned machines we'll need two levels of access to the project: deployer access (can deploy and update a Concent cluster) and cloud admin access (can add/delete parts of the infrastructure and also do everything a deployer can). Both of these should be able to do less than the built-in
Editor
role.Basically, the deployer level should be enough for the build server (including Jenkins, implemented in #297). Cloud admin level is meant for the deployment server. These limitations are meant for actions that are automated via playbooks or shell scripts. Stuff that's not automated or needs to be performed from outside of Google Cloud infrastructure should rely on user's personal account.
Here are the specific actions we want to be able to perform at each of those levels:
Among the things the cloud admin should not be allowed to do are:
The goal of this task is to:
cloud/
in the repository).The text was updated successfully, but these errors were encountered: