Skip to content

capg/image-builder: add extra role to be able to create gcp vms #2124

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

Merged
k8s-ci-robot merged 1 commit into from
Jun 4, 2021
Merged

capg/image-builder: add extra role to be able to create gcp vms #2124

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions infra/gcp/ensure-staging-storage.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -421,6 +421,7 @@ function staging_special_case__k8s_staging_cluster_api_gcp() {

ensure_services "${STAGING_PROJECT}" compute.googleapis.com
ensure_project_role_binding "${STAGING_PROJECT}" "serviceAccount:${serviceaccount}" "roles/compute.instanceAdmin.v1"
ensure_project_role_binding "${STAGING_PROJECT}" "serviceAccount:${serviceaccount}" "roles/iam.serviceAccountUser"
Copy link
Copy Markdown
Contributor

@spiffxp spiffxp Jun 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cpanato @ameukam So the issue I have with this is that it allows this service account to act as any other service account in this project. That's privilege escalation waiting to happen. Can we not constrain this binding to the actual service account that needs to be used?

Copy link
Copy Markdown
Contributor

@spiffxp spiffxp Jun 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the same comment I had here #2061 (comment)

Copy link
Copy Markdown
Member

@ameukam ameukam Jun 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spiffxp we could bind the service account to the default SA for the compute service.

gcloud iam service-accounts list --project k8s-staging-cluster-api-gcp | grep 'compute'
Compute Engine default service account                                         606075400249-compute@developer.gserviceaccount.com                               False

I'll investigate this week-end.

Copy link
Copy Markdown
Member Author

@cpanato cpanato Jun 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry for the delay to reply, i tried to be off this weekend

How can we fix that? I will try to create the same environment again and apply other roles to check.
but the comment from @ameukam is something that we can do?

Copy link
Copy Markdown
Contributor

@spiffxp spiffxp Jun 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically it would help to know what service account packer is trying to use, so we could apply this role just to that service account

Copy link
Copy Markdown
Member Author

@cpanato cpanato Jun 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the service account it is using is the one we set in the Job Config : https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes/wg-k8s-infra/trusted/image-builder/image-builder-periodics.yaml#L12

it is available in the container and packer uses that one.
This is my understanding, now I don't know if that is correct. :/

Copy link
Copy Markdown
Contributor

@spiffxp spiffxp Jun 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The service account that the job (and thus packer) runs as is what we set in the job config, correct. However packer's instructions [1] indicate that whatever is running packer needs the Service Account User role, meaning they expect packer to be able to impersonate a different service account [2]

I'm going to take a wild guess that this is to allow packer to attach the service account it's currently running as to any other instances it happens to create [4]. So probably narrow the binding to itself. I would hope that logs or the code could confirm the guess and allow us to narrow the binding's scope.

References:
[1]: https://www.packer.io/docs/builders/googlecompute#running-on-google-cloud
[2]: https://cloud.google.com/iam/docs/impersonating-service-accounts
[3]: https://cloud.google.com/iam/docs/impersonating-service-accounts#attaching-to-resources
[4]: https://cloud.google.com/compute/docs/access/service-accounts#associating_a_service_account_to_an_instance

ensure_staging_gcb_builder_service_account "cluster-api-gcp" "k8s-infra-prow-build-trusted"
}

Expand Down