Support workload identity federation for config connector

[liubog2008]

Describe the feature or resource

Now it can only use static key.json to setup config connector. I hope to use workload identity federation to authenticate GCP API.

What I hope is deployed config connector in an external Kubernetes cluster and use it as an OIDC provider to exchange GCP token and then use this token to visit GCP API.

Importance

Links:

• https://cloud.google.com/iam/docs/using-workload-identity-federation#oidc_2
• https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection

[jcanseco]

Hi @liubog2008, thank you for the feature request. Can you elaborate on how this request might help you? And would you consider this a blocker, friction point, or nice-to-have?

I am admittedly not very familiar with the concept of Workload Identity Federation, but if I'm understanding it correctly, it's a feature that lets one use GKE Workload Identity on non-GKE clusters?

[liubog2008]

Can you elaborate on how this request might help you?

It has been supported in cnrm-controller-manager in fact. However, I have to modify sts after the controller is deployed by operator. What I need is support this authenticate method in ConfigConnector CRD.

Now only credentialSecretName and googleServiceAccount are supported.

And would you consider this a blocker, friction point, or nice-to-have?

I feel it's a blocker for me to use config connector in prod unless I choose to deploy controller manually.

it's a feature that lets one use GKE Workload Identity on non-GKE clusters?

Yes, and we also use it in GKE cluster. We use k8s cluster as an OIDC provider to authenticate GCP API. Pod can use the token which is signed by k8s to exchange a new token signed by GCP to visit GCP API.

There are some changes of cnrm-controller-manager(deployed by credentialSecretName: gsa-key). I'm not sure whether it is all what I need to change. Just for reference only.

cnrm-controller-manager sts.yaml

        env:
        - name: GOOGLE_APPLICATION_CREDENTIALS
          value: /var/secrets/google/key.json
        volumeMounts:
        - mountPath: /var/secrets/google
          name: gcp-service-account
        - mountPath: /var/run/secrets/gke
          name: gke-token
      volumes:
      - name: gke-token
        projected:
          defaultMode: 420
          sources:
          - serviceAccountToken:
              audience: test.com
              expirationSeconds: 7200
              path: token
      - name: gcp-service-account
        secret:
          defaultMode: 420
          secretName: gsa-key

key.json

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/{project_number}/locations/global/workloadIdentityPools/{pool}/providers/{provider}",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "credential_source": {
    "file": "/var/run/secrets/gke/token"
  },
  "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/test@{project_id}.iam.gserviceaccount.com:generateAccessToken"
}

[jcanseco]

Gotcha, thanks for elaborating @liubog2008. The examples are particularly helpful.

I agree that this sound useful. I'm afraid I don't see us being able to work on this any time soon though due to capacity constraints -- I just want to make sure those expectations are set clearly so you're not waiting on a feature that we can't deliver in a reasonable timeframe.

That said, we'll let you know when that changes.

To other customers: please also like this issue if you think this helps your use-case. It'll help us prioritize accordingly later.

[liubog2008]

Fine, I'll try to deploy controller manually.