Authorizing pods in your cluster to IBM Cloud services with IAM trusted profiles

Virtual Private Cloud Classic infrastructure Satellite

Give application pods that run in your Red Hat® OpenShift® on IBM Cloud® cluster access to IBM Cloud services by creating a trusted profile in IBM Cloud Identity and Access Management (IAM).

You can enable IAM trusted profiles by running the ibmcloud oc cluster master refresh command.

In IAM: Start by creating an IAM trusted profile. Then, link the trusted profile with your Red Hat OpenShift on IBM Cloud compute resource by selecting conditions to match with your clusters, including a Kubernetes namespace and service account in the clusters. Finally, assign access policies to the IBM Cloud services that you want your apps to use.
In your cluster: Through Kubernetes service account token volume projection, the apps that run in your linked cluster's Kubernetes namespace and use the namespace's service account can exchange the service account public key to get an IBM Cloud IAM access token. Your app can use this access token to authenticate API requests to IBM Cloud services, such as databases, Watson, or VPC infrastructure. Through the access policies of the trusted profile, you control what actions the token lets the app perform.

Prerequisites

To use IBM Cloud IAM identities for pods in your cluster, verify that you meet the prerequisites.

Minimum required permissions

Viewer platform access role and the Writer service access role for the cluster in IBM Cloud IAM for Kubernetes Service.
The iam-identity.profile.create and iam-identity.profile.linkToResource actions for the IAM identity service.

Creating an IAM trusted profile for your cluster in the API

As an account administrator, create a trusted profile in IBM Cloud Identity and Access Management. For more information, see the IAM documentation.

Before you begin: Verify that you meet the prerequisites.

Access your Red Hat OpenShift cluster.

Create an IAM trusted profile in IBM Cloud Identity and Access Management. Note the uuid (profile ID) in the output.
- Replace <access_token> with your IBM Cloud token. To get this token from the command line, log in and run ibmcloud iam oauth-tokens.
- Enter a <profile_name> and optional <description> for the IAM trusted profile.
- Replace <account_id> with the ID of your IBM Cloud account. To get this ID from the command line, run ibmcloud account show.
```
curl -L -X POST 'https://iam.cloud.ibm.com/v1/profiles' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <access_token>' \
-H 'Content-Type: application/json' \
--data-raw '{
    "name": "<profile_name>",
    "description": "<description>",
    "account_id": "<account_id>"
}'
```
Link the IAM trusted profile to a Kubernetes namespace in your Red Hat OpenShift on IBM Cloud cluster.
1. Get your <profile-id> from the output of the first step. Or, you can run the following API command.
```
curl -L -X GET 'https://iam.cloud.ibm.com/v1/profiles/?account_id=<account_id>' \
-H 'Accept: application/json' \
-H 'Authorization: <access_token>' \
-H 'Content-Type: application/json' \
```
2. Get your cluster name and CRN by running the following API command.
```
curl --location --request GET 'https://containers.cloud.ibm.com/global/v1/clusters' \
--header 'Authorization: <access_token>'
```
3. Link the IAM trusted profile to your cluster.
  - For <link_name>, enter a name for the link between the trusted profile and the cluster.
  - Replace <profile-id>, <access_token>, <cluster_crn>, and <cluster_name> with the values that you previously retrieved.
  - For <ns>, enter the namespace in your cluster. You can list namespaces by logging in to the cluster and running oc get ns. The Kubernetes namespace that you enter does not have to exist already. Any future namespace with this name can establish trust.
```
curl -L -X POST 'https://iam.cloud.ibm.com/v1/profiles/<profile-id>/links' \
-H 'Accept: application/json' \
-H 'Authorization: Bearer <access_token>' \
-H 'Content-Type: application/json' \
--data-raw '{
    "name": "<link_name>",
    "cr_type": "<sa>",
    "link": {
        "crn": "<cluster_crn>",
        "namespace": "<ns>",
        "name": "<cluster_name>"
    }
}'
```
Assign the trusted profile to an access group with access policies to the IBM Cloud services that you want your apps to have access to.

Your clusters can now establish trust with IBM Cloud IAM. Next, your developers can configure their application pods to exchange the identity token for an IAM token to authenticate requests to IBM Cloud services.

Creating an IAM trusted profile for your cluster in the UI

As an account administrator, create a trusted profile in IBM Cloud Identity and Access Management. For more information, see the IAM documentation.

Before you begin: Verify that you meet the prerequisites.

Log in to the IBM Cloud IAM Trusted profiles console.
Click Create.
Give your trusted profile a name and click Continue.
For trust entity type, select Compute resources.
For compute service, select Kubernetes.
For compute resources, choose among the following options to determine which clusters or resources in the cluster can establish trust.
- All service resources: Any existing and future clusters. To link the trusted profile only to clusters under certain conditions, you can Add new condition +. For example, you might add conditions such as only clusters in a resource group, only clusters with a prod Kubernetes namespace, or only clusters with a trusted-profile Kubernetes service account.
- Specific resources: A particular cluster. Click Add another resource + to select a cluster and fill out conditions such as the Kubernetes namespace or Kubernetes service account that can establish trust.
- Click Continue.
The Kubernetes namespace and service account names that you enter don't have to exist already. Any future namespaces or service accounts with these names can establish trust. To list existing namespaces, log in to your cluster and run oc get ns. To list existing service accounts, log in to your cluster and run oc get sa -n <namespace>.
Grant the trusted profile any access policies to the IAM services and Account management that you want the pod in your cluster to be able to access.
- For example, you might grant access to All Identity and Access enabled services and All resources in those services, with the Editor platform, Writer service, and Viewer resource group access roles.
- Click Add + to add the policy to the profile, and continue adding as many policies as you want.
In the Summary pane, review the profile, trust, and access details. Then, click Create.

Configure your application pods to authenticate with IBM Cloud services

As a developer, you can configure your application pods to authenticate with IBM Cloud services in clusters that are linked to an IAM trusted profile set up.

Before you begin:

Access your Red Hat OpenShift cluster.
Make sure that your account administrator created an IAM trusted profile for your cluster.

To configure your application pods to authenticate with IBM Cloud services:

Design your pod configuration file to use service account token volume projection.
1. In the containers section, mount the identity token in the volumeMounts section.
```
...
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: sa-token
```
2. In the volumes section, set up the service account token volume projection.
  
  Modify the expirationSeconds field to control how long the token is valid for. To retrieve IAM tokens, the service account token expiration must be 1 hour or less.
```
...
volumes:
  - name: sa-token
    projected:
      sources:
      - serviceAccountToken:
          path: sa-token
          expirationSeconds: 3600
          audience: iam
...
```
Design your app to exchange the service account projected token for an IAM token that you can use for subsequent API calls to IBM Cloud services. Review the following example authentication request. Replace ${profile_id} with the ID of the trusted profile that the cluster is linked to. To list available profile IDs, you or the account administrator can use the ibmcloud iam tps command, the GET 'https://iam.cloud.ibm.com/v1/profiles/?account_id=<account_id>', or you can view the trusted profiles in the IAM console.
```
curl -s -X POST \
    -H "Content-Type: application/x-www-form-urlencoded" \
    -H "Accept: application/json" \
    -d grant_type=urn:ibm:params:oauth:grant-type:cr-token \
    -d cr_token=$(cat /var/run/secrets/tokens/sa-token) \
    -d profile_id=${profile_id} \
    https://iam.cloud.ibm.com/identity/token
```

Before your app is deployed, try the following example Kubernetes job to test the token exchange. In the following Kubernetes job, a curl pod makes an API request to IBM Cloud IAM to verify that the cluster's public key is exchanged for an IAM access token. Your app might call other IBM Cloud services that the trusted profile authorizes.

apiVersion: batch/v1
kind: Job
metadata:
  name: token-exchange-job
  namespace: default
spec:
  template:
    spec:
      containers:
      - name: curl
        image: curlimages/curl:7.77.0
        command: ["/bin/sh"]
        args: ["-c", "curl -s -H \"Content-Type: application/x-www-form-urlencoded\" -H \"Accept: application/json\" -d grant_type=urn:ibm:params:oauth:grant-type:cr-token -d cr_token=$(cat /var/run/secrets/tokens/sa-token) -d profile_id=<profile_id> https://iam.cloud.ibm.com/identity/token"]
        volumeMounts:
        - mountPath: /var/run/secrets/tokens
          name: sa-token
      restartPolicy: Never
      serviceAccountName: default
      volumes:
      - name: sa-token
        projected:
          sources:
          - serviceAccountToken:
              path: sa-token
              expirationSeconds: 3600
              audience: iam

Deploy the job.
```
kubectl apply -f exchange-job.yaml
```
Review the job details to verify it was successful.
```
oc describe job token-exchange-job
```
Review the output for the job completed and succeeded messages to verify the job was a success.
If the job succeeded, check your Activity Tracker global events in Frankfurt to verify the log line with details on the Trusted Profile request. If the job failed, review your configuration and try again.