capg/image-builder: add extra role to be able to create gcp vms#2124
capg/image-builder: add extra role to be able to create gcp vms#2124k8s-ci-robot merged 1 commit intokubernetes:mainfrom
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
Little experimentation done here : kubernetes-sigs/image-builder#625 (comment) |
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ameukam, cpanato The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
approved
|
Running: |
|
|
||
| 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" |
There was a problem hiding this comment.
There was a problem hiding this comment.
This is the same comment I had here #2061 (comment)
There was a problem hiding this comment.
@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 FalseI'll investigate this week-end.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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. :/
There was a problem hiding this comment.
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
Revert of kubernetes#2124 which introduces an exposure to privilege escalation. Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Fix exposure to privilege escalation introduced in kubernetes#2124. Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
Fix exposure to privilege escalation introduced in kubernetes#2124. Signed-off-by: Arnaud Meukam <ameukam@gmail.com>
5 participants
Add extra role
"roles/iam.serviceAccountUser"for the service accountmore context: kubernetes-sigs/image-builder#625 (comment)
/assign @ameukam @spiffxp @dims