You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Porter server needs to connect with an arbitrary number of GKE clusters using service account credentials. This sort of arbitrary service account switching is difficult -- there was a PR here that attempted to add this functionality using service account keys. As discussed in the issue, it doesn't make sense to implement this functionality using kubeconfig-based auth, and also doesn't make sense to download service account keys for each cluster and link the key files (for one, this would lead to a bunch of key files written in the container, which seems unsafe).
We'll need support for more idiomatic ways of connecting to clusters, and we'll likely have to drop the []byte storage of the kubeconfig in favor of non-kubeconfig based auth. The solution here is based on the following sources: [1], [2], [3]:
Attempt to infer the GCP project_id automatically. Query the user if the project_id is correct -- if it is not, or it is not possible to find a project_id, ask the user to input a project_id.
Create a service-account in that project using the iam admin package -- equivalent gcloud command:
gcloud iam service-accounts create porter-dashboard
Add policy binding to the service account using the iam package (will have to configure the roles differently depending on a provisioner/connector type) -- equivalent gcloud command:
The Porter server needs to connect with an arbitrary number of GKE clusters using service account credentials. This sort of arbitrary service account switching is difficult -- there was a PR here that attempted to add this functionality using service account keys. As discussed in the issue, it doesn't make sense to implement this functionality using
kubeconfig
-based auth, and also doesn't make sense to download service account keys for each cluster and link the key files (for one, this would lead to a bunch of key files written in the container, which seems unsafe).We'll need support for more idiomatic ways of connecting to clusters, and we'll likely have to drop the
[]byte
storage of the kubeconfig in favor of non-kubeconfig based auth. The solution here is based on the following sources: [1], [2], [3]:Attempt to infer the GCP
project_id
automatically. Query the user if theproject_id
is correct -- if it is not, or it is not possible to find aproject_id
, ask the user to input aproject_id
.Create a
service-account
in that project using the iam admin package -- equivalent gcloud command:Get the service account credentials and store them in the DB.
Do something like the following to generate the client config:
The text was updated successfully, but these errors were encountered: