I have a template built off of the built-in Kubernetes blue-green deployment step and I need to create a service account for each workload being deployed and specify that service account for the deployment.
I have a #{ServiceName} variable that sets the Deployment name and would like to use that for the service account name. When used for the Deployment name, it will add the -deployment-id suffix as expected. When using the variable for the Service Account to run the deployment as, it does not add the suffix, as desired. When creating the Service Account in the Custom Resources section, the variable used as the Service Account name does add the suffix, as expected but not as desired:
ServiceName = my-workload
Deployment => my-workload-deployment-1234
Deployment.Service Account => my-workload
Service Account => my-workload-deployment-1234 # This doesn’t match the above value
I additionally need the Service Account to not have the deployment suffix added to it as in GKE (Google Cloud), we’re configuring Workload Identity to map a GCP account to a specific namespace/service_account in Kubernetes to attach GCP permissions. I need to know and configure a static service account (without the deployment suffix) through separate company tooling (to facilitate security review) that configures GCP once.
I’ve even tried hard-coding the Service Account custom resource to a string matching one of the workload names and it appears to be adding the deployment suffix to everyname attribute of every resource.
I need some way to opt out of the suffix being appended for a specific resource.
(I could have a separate step that just creates the Service Account outside of the deployment step, but there are no multi-step templates so I can’t make sure that a user has both steps added and configured correctly).
I’ll work on reproducing this on my end and will let you know if I find a workaround or if there’s an issue to be raised here.
If you could please send through the Project’s JSON securely here, that will allow me to see exactly how the project has been configured and get to the bottom of this sooner.
Feel free to let me know if you have any questions, I’ll reach out if I need any further details.
Step and Deployment/Custom Resource YAML uploaded.
Looks like the behavior is that any name: field for a resource in a BlueGreen deployment will have the -deployment-XXX suffix added to it with no discernable way to opt out of that for a specific resource (generally it is desired to have that, but for this one ServiceAccount resource it isn’t.
Thank you for that, confirming I’ve received the files.
I think I have a good idea of what’s going on here but I’ll dive deeper into it and discuss it with the relevant teams. I’ll keep you posted with any updates and hopefully a workaround shortly.
I’ve finally managed to get to the bottom of this and should have a solution for you!
All custom resources defined as part of the ‘Deploy Kubernetes containers’ step are tightly coupled with that deployment. Unfortunately this isn’t likely to be changed however our documentation here does have a note about deploying resources that are not bound to the lifecycle of the Deployment resource, however this can definitely be improved!
To deploy a Service Account with a static name, try using a ‘Deploy Raw Kubernetes Yaml’ step before the ‘Deploy Kubernetes containers’ step to define the Service Account.
Feel free to let me know if you have any questions or run into any issues!
That was the multi-step option I mentioned at the end of the original post. That isn’t ideal as that scenario now requires that users know what selection of different step templates are required, in what order, and must configure redundant variables across those steps.
If there were multi-step templates (instead of needing to manually string together separate steps and configure them all correctly) then this would be a lot easier.
Apologies for missing that in the first post, I agree it’s not ideal to add extra complexity!
I’m sorry I don’t have a better answer but I do have some suggestions below for reducing the complexity.
I would recommend configuring Custom Step Templates for any commonly used steps to reduce redundancy. These can be configured with all required variables configured, reducing the need to constantly input the same values.
