gocardless
[rbac-manager] Support workload identity
Hey folks 👋🏻
Hope you don't mind this contribution but we'd like to see theatre support workload identity in the rbac-manager instead of using service account keys. I've made the change such that if workload identity is not configured, the rbac-manager will fallback to using service account keys.
This is how we're currently using it with workload identity in our GKE cluster (after removing GOOGLE_APPLICATION_CREDENTIALS):
Same change on our fork: https://github.com/duffelhq/theatre/pull/3
# Config Connector CRDs
---
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicy
metadata:
name: theatre-workload-identity-user
annotations:
cnrm.cloud.google.com/project-id: duffel-prod
spec:
bindings:
- members:
- serviceAccount:duffel-prod.svc.id.goog[theatre-system/theatre-rbac-manager]
role: roles/iam.workloadIdentityUser
- members:
- serviceAccount:[email protected]
# Required so that the theatre service account can impersonate itself
role: roles/iam.serviceAccountTokenCreator
resourceRef:
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMServiceAccount
external: projects/duffel-prod/serviceAccounts/[email protected]
kubectl annotate serviceaccount theatre-rbac-manager \
--namespace theatre-system \
iam.gke.io/[email protected]
@vinayvinay I think you're the one left in GC that I know..
Any idea who would be best suited to review this? 😁
@mbfisher @bogvak @0x0013 Sorry for the direct tag but wanted to get this merged and saw that you folks have been recently active on this repo!
@mbfisher @bogvak @0x0013 Sorry for the direct tag but wanted to get this merged and saw that you folks have been recently active on this repo!
I'm a contributor so can't help I'm afraid, Core Infra own this so I'd raise a SPOC ticket with them to get a review
I'm a contributor so can't help I'm afraid, Core Infra own this so I'd raise a SPOC ticket with them to get a review
Thanks for letting me know! Unfortunately I'm no longer at GC so don't think I'd be able to do that 😅
@jace-ys it seems the container-builder hasn't built an image for this branch - perhaps it didn't receive the webhook at the time of your last push.
Could you generate a push event on this PR, for example, by pushing an empty commit, to see if it triggers a build? Thanks!
@jace-ys it seems the container-builder hasn't built an image for this branch - perhaps it didn't receive the webhook at the time of your last push.
Could you generate a push event on this PR, for example, by pushing an empty commit, to see if it triggers a build? Thanks!
Tried that but doesn't look like it triggered a build either! 🙁
Tried that but doesn't look like it triggered a build either! 🙁
@jace-ys thanks for trying, it looks like container-builder is still not picking it up. I assume this is because the head branch is external from GC.
I'll see if there's anything that can be done about it.
Hi @jace-ys ,
Thanks for reminder. It's been a bit hard to commit time to it, but we do have a fix for this issue, just awaiting proper review.
TLDR is that our container-builder, which also is (and should be) a required CI check, currently only acts on organisation-internal commits - which is good from the point of security (we don't want to run automated builds on arbitrary commits), but is obviously not ideal for accepting external contributions. So I've been trying to implement a way to manually trigger it after someone from GC evaluates the changes in the PR. Hopefully we have the reviews done this week.
Hi @jace-ys ,
Thanks for reminder. It's been a bit hard to commit time to it, but we do have a fix for this issue, just awaiting proper review.
TLDR is that our container-builder, which also is (and should be) a required CI check, currently only acts on organisation-internal commits - which is good from the point of security (we don't want to run automated builds on arbitrary commits), but is obviously not ideal for accepting external contributions. So I've been trying to implement a way to manually trigger it after someone from GC evaluates the changes in the PR. Hopefully we have the reviews done this week.
Thanks for looking into this, appreciate your time!
@jace-ys looks like container-builder is finally able to build the container and also return the status to GitHub CI check.
Could you please rebase this PR to master so we can test the resulting container image?
@jace-ys looks like container-builder is finally able to build the container and also return the status to GitHub CI check.
Could you please rebase this PR to
masterso we can test the resulting container image?
Thanks for doing this! I've rebased 👍🏻
@jace-ys it looks like there are some merge conflicts since the dependency updates we pushed yesterday. Could I ask you to rebase once again?
@jace-ys it looks like there are some merge conflicts since the dependency updates we pushed yesterday. Could I ask you to rebase once again?
Awesome, thanks for helping out with this. I've rebased now.
~~@0x0013 Side question, I noticed that the theatre image is still pointing to gcr.io when Google have deprecated Container Registry for Artifact Registry.~~
~~So wanted to know if GC have redirected all gcr.io to Artifact Registry, or should we publish our own image to Artifact Registry?~~
Edit: Nevermind, just realized the upstream image is not public