IBM Cloud IAM Trusted Profiles: Removing Long-Lived API Keys from Compute Workloads

Desired Outcome: No Long-Lived Secrets in the Runtime Path

Applications running on IBM Cloud compute often carry a long-lived IAM API key in an environment variable, a container image layer, or a configuration file. That key is a standing exposure risk: it does not expire on its own, it is hard to rotate safely, and audit events attribute actions to a service ID rather than to the workload itself. A trusted profile replaces that pattern by letting the compute resource obtain a short-lived IAM token directly from the platform. The application never stores a credential, and authorization is audited under the trusted profile identity.

The target state is simple: the workload can call only the IBM Cloud APIs it needs, the token it uses expires automatically, and no API key remains in the process environment, image history, logs, or secret store.

Prerequisites and Assumptions

Before you start, confirm the following in the target account:

• You can create trusted profiles and IAM access policies, or you can request them from an account administrator.
• The workload runs on a compute resource that supports the trusted-profile flow in the target region. Support varies by resource type and region; verify current availability before production rollout.
• The IBM Cloud CLI or API version in use supports trusted-profile creation and the token exchange flow. Command names, flags, and endpoints are version-sensitive.
• You have inventoried every location where the current API key is used: CI variables, Kubernetes secrets, VSI user data, Code Engine secrets, and application configuration files.

Procedure: From API Key to Trusted Profile

The rollout has five stages: create the profile, bind it to the compute resource, grant least-privilege policies, deploy the application to use the platform token, and remove the old key from the runtime path.

1. Create the trusted profile

Run the IBM Cloud CLI from a workstation or jump host where you are already authenticated with sufficient IAM privileges. Replace the placeholders with your own values.

# Illustrative pattern; verify exact syntax against the current CLI reference
ibmcloud iam trusted-profile-create \
  --name app-compute-profile \
  --description "Trusted profile for production VSI workload"

Expected check: the command returns a profile ID. Record it; you will need it for the trust relationship and policy bindings.

2. Bind the profile to the compute resource

Associate the profile with the specific compute instance so the platform will issue tokens to that resource only. The example below shows a VPC virtual server instance; the resource type and command differ for other compute services.

# Illustrative pattern; verify exact syntax against the current CLI reference
ibmcloud is instance-update my-app-instance \
  --trusted-profile <trusted-profile-id>

Risk: binding a profile to the wrong instance grants that instance the ability to assume the profile identity. Double-check the instance identifier before applying the change.

3. Grant least-privilege access policies

Scope policies to the exact services, actions, and resources the application needs. Avoid account-wide roles such as Administrator or Viewer on the profile; they silently widen the blast radius.

Policy scope	Effect	Operational risk
Administrator, all resources	Full account control	High: a compromised instance can alter any resource
Viewer, all resources	Read everything	Medium: unnecessary data exposure
Reader on a single Cloud Object Storage bucket	Read objects in one bucket only	Low: matches the intended workload

# Illustrative pattern; verify exact syntax against the current CLI reference
ibmcloud iam service-policy-create <trusted-profile-id> \
  --roles Reader \
  --service-name cloud-object-storage \
  --resource <bucket-name>

Expected check: the policy appears in the profile's policy list and targets only the intended service and resource.

4. Deploy the application to use the platform token

Update the application so it retrieves the platform identity token from the compute resource's identity endpoint and uses that token as a bearer credential for IBM Cloud API calls. Do not hard-code the token endpoint or assume a fixed lifetime; treat identity plumbing as version-sensitive and read the endpoint from the platform at runtime.

Expected check: the application starts successfully with no API key in its environment, and its first intended API call returns a success response.

5. Remove the old API key from the runtime path

Delete the API key from every location identified in the inventory: environment variables, secret stores, image build arguments, and configuration files. If the key was ever committed to source control or exposed in logs, rotate or delete it immediately.

Expected check: a fresh deployment contains no reference to the old key in its process environment, image layers, or mounted secrets.

Expected Checks and Validation

Validate the new flow in a non-production account before production cutover:

1. Positive and negative authorization test. Confirm the workload can perform one intended action (for example, reading a specific bucket) and is denied when attempting an unintended action (for example, deleting that bucket).
2. Token lifetime. Inspect the token the application receives and confirm it is short-lived and expires without manual rotation.
3. Identity resolution. Check Activity Tracker events for the calls the workload made. The initiator should resolve to the trusted profile, not to a user or service ID API key.
4. Secret absence. Inspect the process environment, image history, application logs, and secret store to prove the old API key is gone from the normal runtime path.
5. Post-upgrade re-check. Repeat the validation after any CLI or platform upgrade, or after changing regions, because supported resources and endpoint names can move.

Recovery and Rollback

Because this procedure changes IAM state, plan the rollback path before you begin:

• Authentication failure. If the workload cannot obtain a token, restore a break-glass API key only inside a managed secret with a tight time-to-live and alerting on any use. Do not leave the old key enabled as a silent fallback.
• Emergency access cut. To immediately revoke the workload's access, remove the profile's access policies or delete the trusted profile. The compute resource will lose its ability to obtain tokens.
• Exposed credential. If any API key was exposed during migration, rotate or delete it and re-run the policy diff to restore least privilege.

Limitations and Version Sensitivity

Trusted profiles are not a universal replacement for API keys. External CI runners, developer laptops, and third-party systems that do not run on supported IBM Cloud compute still require a separate identity mechanism. Broad roles on the profile can widen the blast radius as easily as a leaked key. Finally, supported compute resources, profile claim rules, token endpoints, session policies, CLI command names, and regional availability can change across platform releases. Validate the exact flow in your target account before production and after any significant platform upgrade.