Hello,
From my understanding in regards to Google Cloud services, the way that Workload Identity is implemented (#1223) is it takes the name from gcpServiceAccount field and creates a KSA with the same name. Unfortunately for us, our company has varied naming conventions and our gcpServiceAccount naming convention is different from our kubernetes service account naming convention.
If I have a workload identity set up where gcpServiceAccount is test-gcp-134-svc and the kubernetes service account is ksa-test-abc-svc the Workload Identity will not work as it will create a KSA named test-gcp-134-svc instead of ksa-test-abc-svc
Could an optional field be added that will take in the name of the KSA to create to allow for such scenarios?
Maybe added a kubernetesServiceAccount field to the GoogleCloudSourceAuth that when set will create the KSA with the name set in that field, otherwise create the KSA from the gcpServiceAccount field.
auth:
description:
type: object
properties:
serviceAccountKey:
description: Service account key used to authenticate the event source and allow it to interact with Google Cloud APIs. Only the JSON format is supported.
type: object
properties:
value:
description: Literal value of the service account key.
type: string
valueFromSecret:
description: A reference to a Kubernetes Secret object containing the service account key.
type: object
properties:
name:
type: string
key:
type: string
required:
- name
- key
oneOf:
- required: [value]
- required: [valueFromSecret]
gcpServiceAccount:
description: GCP Service account name to impersonate Identity and Access Management (IAM) service accounts to access Google Cloud services.
pattern: ^[a-z][a-z0-9-]+@[a-z0-9-]+\.[a-z]+\.[a-z]{2,63}$
type: string
kubernetesServiceAccount:
description: Kubernetes Service account name bound to the gcpServiceAccount to act as an IAM service account. Optional, by default the kubernetes service account will be created with the same names as gcpServiceAccount.
type: stringI can help contribute and work on adding this feature/change but might need some guidance. My initial thought was to add a string ServiceAccountName property to ServiceAccountProvider and set it to rcl.GetName() unless s.Spec.Auth.kubernetesServiceAccount is set.
Thanks!
Hello,
From my understanding in regards to Google Cloud services, the way that Workload Identity is implemented (#1223) is it takes the name from
gcpServiceAccountfield and creates a KSA with the same name. Unfortunately for us, our company has varied naming conventions and our gcpServiceAccount naming convention is different from our kubernetes service account naming convention.If I have a workload identity set up where gcpServiceAccount is
test-gcp-134-svcand the kubernetes service account isksa-test-abc-svcthe Workload Identity will not work as it will create a KSA namedtest-gcp-134-svcinstead ofksa-test-abc-svcCould an optional field be added that will take in the name of the KSA to create to allow for such scenarios?
Maybe added a
kubernetesServiceAccountfield to the GoogleCloudSourceAuth that when set will create the KSA with the name set in that field, otherwise create the KSA from thegcpServiceAccountfield.I can help contribute and work on adding this feature/change but might need some guidance. My initial thought was to add a string
ServiceAccountNameproperty to ServiceAccountProvider and set it torcl.GetName()unlesss.Spec.Auth.kubernetesServiceAccountis set.Thanks!