Skip to content
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.

Sign up for GitHub

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

Jump to bottom

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

Open
cameel opened this issue Mar 22, 2019 · 5 comments · May be fixed by #382
Open

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

cameel opened this issue Mar 22, 2019 · 5 comments · May be fixed by #382
Assignees
@bartoszbetka
Labels
build and deployment system chore not in pivotal

Comments

@cameel
Copy link
Contributor

cameel commented Mar 22, 2019 •
edited
Loading

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

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 cameel mentioned this issue Mar 22, 2019
Closed
@cameel
Copy link
Contributor Author

cameel commented Mar 26, 2019

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

@bartoszbetka
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

cameel commented Apr 25, 2019

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
Copy link
Contributor Author

cameel commented Apr 25, 2019

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.

@bartoszbetka bartoszbetka linked a pull request May 10, 2019 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bartoszbetka bartoszbetka

Labels
build and deployment system chore not in pivotal
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add information about privileges for service accounts golemfactory/concent-deployment
2 participants
@cameel @bartoszbetka