Authenticating pods with short-term credentials - Working with pods | Nodes

Configuring short-term authentication for workloads
- Environment and user access requirements
Configuring GCP Workload Identity authentication for applications on GCP

Some OKD clusters use short-term security credentials for individual components that are created and managed outside the cluster. Applications in customer workloads on these clusters can authenticate by using the short-term authentication method that the cluster uses.

Configuring short-term authentication for workloads

To use this authentication method in your applications, you must complete the following steps:

Create a federated identity service account in the Identity and Access Management (IAM) settings for your cloud provider.
Create an OKD service account that can impersonate a service account for your cloud provider.
Configure any workloads related to your application to use the OKD service account.

Environment and user access requirements

To configure this authentication method, you must meet the following requirements:

Your cluster must use short-term security credentials.
You must have access to the OpenShift CLI (oc) as a user with the cluster-admin role.
In your cloud provider console, you must have access as a user with privileges to manage Identity and Access Management (IAM) and federated identity configurations.

Configuring GCP Workload Identity authentication for applications on GCP

To use short-term authentication for applications on a GCP clusters that use GCP Workload Identity authentication, you must complete the following steps:

Creating a federated GCP service account

You can use the Google Cloud console to create a workload identity pool and provider and allow an OKD service account to impersonate a GCP service account.

Prerequisites

Your GCP cluster uses GCP Workload Identity.
You have access to the Google Cloud console as a user with privileges to manage Identity and Access Management (IAM) and workload identity configurations.
You have created a Google Cloud project to use with your application.

Procedure

In the IAM configuration for your Google Cloud project, identify the identity pool and provider that the cluster uses for GCP Workload Identity authentication.
Grant permission for external identities to impersonate a GCP service account. With these permissions, an OKD service account can work as a federated workload identity.

For more information, see GCP documentation about allowing your external workload to access Google Cloud resources.

Creating an OKD service account for GCP

You create an OKD service account and annotate it to impersonate a GCP service account.

Prerequisites

Your GCP cluster uses GCP Workload Identity.
You have created a federated GCP service account.
You have access to the OpenShift CLI (oc) as a user with the cluster-admin role.
You have access to the Google Cloud CLI (gcloud) as a user with privileges to manage Identity and Access Management (IAM) and workload identity configurations.

Procedure

Create an OKD service account to use for GCP Workload Identity pod authentication by running the following command:
```
$ oc create serviceaccount <service_account_name>
```
Annotate the service account with the identity provider and GCP service account to impersonate by running the following command:
```
$ oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/workload-identity-provider": "projects/<project_number>/locations/global/workloadIdentityPools/<identity_pool>/providers/<identity_provider>"}}}'
```
Replace <project_number>, <identity_pool>, and <identity_provider> with the values for your configuration.

For <project_number>, specify the Google Cloud project number, not the project ID.
Annotate the service account with the email address for the GCP service account by running the following command:
```
$ oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/service-account-email": "<service_account_email>"}}}'
```
Replace <service_account_email> with the email address for the GCP service account.

GCP service account email addresses typically use the format <service_account_name>@<project_id>.iam.gserviceaccount.com
Annotate the service account to use the direct external credentials configuration injection mode by running the following command:
```
$ oc patch serviceaccount <service_account_name> -p '{"metadata": {"annotations": {"cloud.google.com/injection-mode": "direct"}}}'
```
In this mode, the Workload Identity Federation webhook controller directly generates the GCP external credentials configuration and injects them into the pod.
Use the Google Cloud CLI (gcloud) to specify the permissions for the workload by running the following command:
```
$ gcloud projects add-iam-policy-binding <project_id> --member "<service_account_email>" --role "projects/<project_id>/roles/<role_for_workload_permissions>"
```
Replace <role_for_workload_permissions> with the role for the workload. Specify a role that grants the permissions that your workload requires.

Verification

To verify the service account configuration, inspect the ServiceAccount manifest by running the following command:

$ oc get serviceaccount <service_account_name>

In the following example, the service-a/app-x OKD service account can impersonate a GCP service account called app-x:

Example output

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-x
  namespace: service-a
  annotations:
    cloud.google.com/workload-identity-provider: "projects/<project_number>/locations/global/workloadIdentityPools/<identity_pool>/providers/<identity_provider>" (1)
    cloud.google.com/service-account-email: "app-x@project.iam.googleapis.com"
    cloud.google.com/audience: "sts.googleapis.com" (2)
    cloud.google.com/token-expiration: "86400" (3)
    cloud.google.com/gcloud-run-as-user: "1000"
    cloud.google.com/injection-mode: "direct" (4)

1	The workload identity provider for the service account of the cluster.
2	The allowed audience for the workload identity provider.
3	The token expiration time period in seconds.
4	The `direct` external credentials configuration injection mode.

Deploying customer workloads that authenticate with GCP Workload Identity

To use short-term authentication in your application, you must configure its related pods to use the OKD service account. Use of the OKD service account triggers the webhook to mutate the pods so they can impersonate the GCP service account.

The following example demonstrates how to deploy a pod that uses the OKD service account and verify the configuration.

Prerequisites

Your GCP cluster uses GCP Workload Identity.
You have created a federated GCP service account.
You have created an OKD service account for GCP.

Procedure

To create a pod that authenticates with GCP Workload Identity, create a deployment YAML file similar to the following example:

Sample deployment

apiVersion: apps/v1
kind: deployment
metadata:
  name: ubi9
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ubi9
  template:
    metadata:
      labels:
        app: ubi9
    spec:
      serviceAccountName: "<service_account_name>" (1)
      containers:
        - name: ubi
          image: 'registry.access.redhat.com/ubi9/ubi-micro:latest'
          command:
            - /bin/sh
            - '-c'
            - |
              sleep infinity

1	Specify the name of the OKD service account.

Apply the deployment file by running the following command:
```
$ oc apply -f deployment.yaml
```

Verification

To verify that a pod is using short-term authentication, run the following command:

$ oc get pods -o json | jq -r '.items[0].spec.containers[0].env[] | select(.name=="GOOGLE_APPLICATION_CREDENTIALS")'

Example output

{   "name": "GOOGLE_APPLICATION_CREDENTIALS",   "value": "/var/run/secrets/workload-identity/federation.json" }

The presence of the GOOGLE_APPLICATION_CREDENTIALS environment variable indicates a pod that authenticates with GCP Workload Identity.

To verify additional configuration details, examine the pod specification. The following example pod specifications show the environment variables and volume fields that the webhook mutates.

Example pod specification with the direct injection mode:

apiVersion: v1
kind: Pod
metadata:
  name: app-x-pod
  namespace: service-a
annotations:
  cloud.google.com/skip-containers: "init-first,sidecar"
  cloud.google.com/external-credentials-json: |- (1)
    {
      "type": "external_account",
      "audience": "//iam.googleapis.com/projects/<project_number>/locations/global/workloadIdentityPools/on-prem-kubernetes/providers/<identity_provider>",
      "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
      "token_url": "https://sts.googleapis.com/v1/token",
      "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/app-x@project.iam.gserviceaccount.com:generateAccessToken",
      "credential_source": {
        "file": "/var/run/secrets/sts.googleapis.com/serviceaccount/token",
        "format": {
          "type": "text"
        }
      }
    }
spec:
  serviceAccountName: app-x
  initContainers:
  - name: init-first
    image: container-image:version
  containers:
  - name: sidecar
    image: container-image:version
  - name: container-name
    image: container-image:version
    env: (2)
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/gcloud/config/federation.json
    - name: CLOUDSDK_COMPUTE_REGION
      value: asia-northeast1
    volumeMounts:
    - name: gcp-iam-token
      readOnly: true
      mountPath: /var/run/secrets/sts.googleapis.com/serviceaccount
    - mountPath: /var/run/secrets/gcloud/config
      name: external-credential-config
      readOnly: true
  volumes:
  - name: gcp-iam-token
    projected:
      sources:
      - serviceAccountToken:
          audience: sts.googleapis.com
          expirationSeconds: 86400
          path: token
  - downwardAPI:
      defaultMode: 288
      items:
      - fieldRef:
          apiVersion: v1
          fieldPath: metadata.annotations['cloud.google.com/external-credentials-json']
        path: federation.json
    name: external-credential-config

1	The external credentials configuration generated by the webhook controller. The Kubernetes `downwardAPI` volume mounts the configuration into the container filesystem.
2	The webhook-injected environment variables for token-based authentication.