Learn how compute resources like your deployed, containerized app can be turned into a powerful tool with attached IAM privileges, thanks to trusted profiles.

Over the years, I have learned to use API keys in my automations for IBM Cloud. API keys for user IDs and service IDs allow you to log in and perform access-restricted, protected actions. Wouldn’t it be nice to deploy apps without the hassle of securely distributing and managing API keys for them? You can already do this today, thanks to trusted profiles and compute resources.

For this blog post, I took a look at them and wrote some code to see trusted profiles with compute resources in action. Read on to learn about my journey.

Overview

Identity and Access Management (IAM) controls access to resources. IBM Cloud uses the concept of IAM IDs to abstract from users and other identities. It also has service IDs, which are identities that can be seen as “technical users.” They can be used by cloud services or applications to perform tasks. Similar to regular user IDs, service IDs can create and own API keys. The latter is used to authenticate and turn them into IAM access tokens.

A newer concept is the trusted profile—another type of IAM ID. Similar to the other IAM identity types, trusted profiles are treated as a subject that is granted access in IAM policies. However, users of trusted profiles do not need to be members of the account. They can be brought in with an identity provider via federation or use an identified compute resource. Currently, the latter can be a virtual server instance in a virtual private cloud, or apps and services deployed to an IBM Cloud Kubernetes Service or Red Hat OpenShift on IBM Cloud cluster.

Using a trusted profile with a compute resource, you could run a containerized app in a Kubernetes cluster, let that app request to use the privileges granted to that profile, and perform protected administrative tasks. All that would be possible without creating any service ID, sharing API keys, etc. Too good to be true? I put that concept into action:

Trusted profile with a compute resource in action

IBM Cloud Kubernetes Service is one of the supported compute resources for a trusted profile and it offers a free cluster, which is great for testing my scenario. The steps to obtain an IAM access token through a compute resource are described as part of the trusted profile documentation and with more details for IBM Cloud Kubernetes Service clusters in “Authorizing pods in your cluster to IBM Cloud services with IAM trusted profiles.”

Basically, I need to perform the following steps. First, create a trusted profile. Then, add a compute resource for the trusted profile and either allow all IBM Cloud Kubernetes Service clusters or identify a specific resource by providing the cluster identity, Kubernetes namespace and service account. Next, I grant privileges to the trusted profile by adding it as member to access groups or directly configure access for the trusted profile.

With the trusted profile in place, the deployed app does the following:

• Read the service account token.
• Use the service account token with the name of the trusted profile to request the IAM access token.
• Perform the IAM-protected tasks.

For testing, the above steps can also be performed by providing a sample job or logging into the shell of the running container and manually issuing the necessary commands from the shell. I tested both options, then combined everything for simplicity and as the foundation for an actual administrative app.

The small Python app offers two API functions. The first verifies it is running appropriately, and the second API function accepts a trusted profile name as a parameter and tries to read the service account token, turn it into an IAM access token, then list resources in the account. All are combined with additional debug/educational output.

For the tests, I deployed the app to different namespaces in my IBM Cloud Kubernetes Service cluster. Then, I configured matching and non-matching compute resources for the trusted profile. Next, I ran tests like the ones shown in the screenshot below. After getting into the shell of the running container, I used curl to kick off different authorization flows. Depending on whether a trusted profile exists, there are different error messages when access is denied:

The last invocation is with the trusted profile and matching compute resource configured and is successful, returning a list of resources in the account and other debug output. The screenshot in the previous section shows an Activity Tracker log record of a compute resource login (“iam-identity.computeresource-token.login”).

As shown in my tests, getting from the app requesting the IAM access token to successfully receiving it involves the checks and possible error messages as depicted in the following diagram:

Conclusions

Trusted profiles are a type of IAM identity, and similar to other identities, they can have access privileges attached directly and can be members of IAM access groups. A difference is that the identity of trusted profiles can be assumed (i.e., users, apps or processes can operate under the identity of a trusted profile). One such way—which I blogged about in “Secure Onboarding for Your Workshops and Hackathons”—is through identity providers (e.g., App ID).

Another option to assume the identity of a trusted profile is through compute resources. In this blog, I showed that no API key or password needs to be made available to perform IAM-protected actions. Everything needed was just to specify as compute resource from where the app tries to obtain the IAM access token. This simplifies the process and, often, enhances security. As discussed and shown in this blog, my app itself, deployed in the designated namespace, serves as “turnkey” to be able to perform the work.

If you want to learn more about trusted profiles with compute resources, you can use my sample code as starter. If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik), Mastodon (@data_henrik@mastodon.social) or LinkedIn.