Open cameel opened 5 years ago
Update: Concent Cloud Admin needs to be able to use other service accounts after all.
Needed roles Concent Deployer:
Creating and deleting resources within a cluster (pods, services, config maps, etc.).
Kubernetes Engine Developer
consider not include secrets (container.secrets.*
)Creating and deleting schemas, tables and other items inside a PostgreSQL database on a Cloud SQL instance (but not the database or the instance itself).
Attaching storage to cluster pods.
Kubernetes Engine Developer
Configuring a load balancer inside the cluster and attaching a static IP to it.
Kubernetes Engine Developer
Pushing/pulling Docker images to/from Docker registry.
Storage Object Creator
, Storage Object Viewer
and custom rule with storage.bucket.get, storage.bucket.list
classes
orStorage Admin
https://cloud.google.com/container-registry/docs/access-control (recommended by documentation) add additional permissions to delete object from docker registry and create bucket for docker registry.
consider: the first case also does not work when the bucket is not created, so before the first push was made.Concent Cloud Admin:
compute.firewalls.*
) classService Account User
for Concent Deployer service account and service account that will be use for kubernetes nodesconcent_cloud_admin
I think this rules are exclude each other:
This service account also has permission to granting roles to specific instances but not in project level.
Kubernetes Engine Developer consider not include secrets (container.secrets.*)
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.
- Pushing/pulling Docker images to/from Docker registry.
Storage Object Creator
,Storage Object Viewer
and custom rule withstorage.bucket.get, storage.bucket.list
classes orStorage Admin
https://cloud.google.com/container-registry/docs/access-control (recommended by documentation) add additional permissions to delete object from docker registry and create bucket for docker registry. consider: the first case also does not work when the bucket is not created, so before the first push was made.
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
Compute Security Admin consider creating custom rule with only (compute.firewalls.*) class
Let's create a custom role. Compute Security Admin
has way too much permissions if we only need the firewall access.
concent_cloud_admin
I think this rules are exclude each other:
- Creating and deleting Google Compute Engine instances.
- not allowed Giving itself access to other Google Compute Engine instances.
Well, OK. I see there's no other way. Let's allow Concent Cloud Admin to do both.
This service account also has permission to granting roles to specific instances but not in project level.
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 Viewer
role also did not allow logging into arbitrary machines.
Lastly, please don't forget to document the privileges in the README
as stated in the issue.
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).