Determine the minimal set of roles/privileges needed for the service accounts

[cameel]

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:

• Concent Deployer:
  • Creating and deleting resources within a cluster (pods, services, config maps, etc.).
  • 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.
  • Configuring a load balancer inside the cluster and attaching a static IP to it.
  • Pushing/pulling Docker images to/from Docker registry.
• Concent Cloud Admin:
  • Creating and deleting Google Compute Engine instances.
  • Creating and deleting Kubernetes clusters.
  • Creating and deleting Cloud SQL instances.
  • Creating and deleting PostgreSQL databases and roles in Cloud SQL.
  • Making Cloud SQL backups.
  • Creating and deleting disks.
  • Creating and deleting IPs.
  • Deleting images from Docker registry.
  • Changing firewall rules.
  • Assigning service accounts to newly created machines
    • Default service accounts for new instances and clusters
    • Service account used for concent builder
    • Service accounts used for existing Kubernetes clusters
      • See Service accounts > The Service Account Actor role.
      • See Service accounts > The Service Account User role.

Among the things the cloud admin should not be allowed to do are:

• Changing roles/privileges.
  • But should be able to give service accounts access to specific clusters.
• Giving itself access to other Google Compute Engine instances.

The goal of this task is to:

1. Determine which permissions or roles we need to implement these access levels. You can see most roles in Understanding Roles but you may also need to take look at docs of specific Google Cloud features/components.
   • Predefined roles are fine even if they give a bit more privileges than we need as long as it's not unreasonable. If there's no predefined role that fits our needs, create a custom role (see Creating and managing custom roles).
2. Document roles needed for each server in the README (or in a script/configuration file placed under cloud/ in the repository).

[cameel]

Update: Concent Cloud Admin needs to be able to use other service accounts after all.

[bartoszbetka]

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).

  • No additional rules are needed, postgreSQL user can do this.

• 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 or
  • Storage 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:

• Creating and deleting Google Compute Engine instances.
  • Compute Instance Admin
• Creating and deleting Kubernetes clusters.
  • Kubernetes Engine Admin
• Creating and deleting Cloud SQL instances.
  • Cloud SQL Admin
• Creating and deleting PostgreSQL databases and roles in Cloud SQL.
  • Cloud SQL Admin
• Making Cloud SQL backups.
  • Cloud SQL Admin
• Creating and deleting disks.
  • Compute Instance Admin
• Creating and deleting IPs.
  • Compute Network Admin
• Deleting images from Docker registry.
  • Storage Admin
• Changing firewall rules.
  • Compute Security Admin
    consider creating custom rule with only (compute.firewalls.*) class
• Additional rule to manage instances with different service account
  • Service Account User for Concent Deployer service account and service account that will be use for kubernetes nodes

[bartoszbetka]

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.

This service account also has permission to granting roles to specific instances but not in project level.

[cameel]

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 with storage.bucket.get, storage.bucket.list classes or
  • Storage 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?

[cameel]

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.