-
Notifications
You must be signed in to change notification settings - Fork 127
Eliminate the need for the IAM SA keys as Kubernetes secrets #250
Comments
Instead of using a dedicated node pool, could we use workload identity? https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity |
Workload identity sounds like an interesting idea. Would love to use it if it will solve not having to use a key. @kevensen FYI |
I like that idea. This feature is still in beta. I'd like to make an update to the terraform-google-kubernetes-engine module. Any concerns? |
I'm happy to look at a PR for Kubernetes. |
Okeedokee. I'll start there. |
Apologies, it looks like this was already added to the GKE module: terraform-google-modules/terraform-google-kubernetes-engine#234 You should be able to use it directly once the next module is released: https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/blob/master/CHANGELOG.md#added |
No worries. It was good practice. I'll look forward to the next release. |
@kevensen Was this addressed with the work for the GKE beta release? |
Yes |
It is a best practice not to use security key (whenever possible). But currently for Forseti on GKE, IAM service account key is obtained from GCP and added as a secret to kubernetes.
Per discussion with @kevensen, it is possible to create a dedicated Forseti nodepool in the cluster and bind the SA to the nodes, without using a key. i.e. "taint" these nodes as described above for the sole-use of Forseti.
The text was updated successfully, but these errors were encountered: