Terraform, IBM Cloud App ID and IAM rules for simple, quick and secure project onboarding.

If you are like me, you sometimes run short-lived projects like workshops or hackathons. For these types of projects, you usually need to bring many people into an account at once and clean everything up after a few days. You typically have different roles, different privileges and different requirements. And you don’t have much time. Now, what to do? 

The obvious answer, of course, is to automate. Moreover, utilize the right cloud security concepts that allow quick and easy onboarding and offboarding while providing the needed level of security. 

In this post and a follow-up blog post, I am going to discuss and share the necessary code to easily and securely onboard participants to an IBM Cloud account. It includes Terraform code to set up an IBM Cloud App ID instance and create and configure either an IAM (Identity and Access Management) access group and/or Trusted Profile. I will also share a Python script to add a group of users with custom attributes all at once to the App ID Cloud Directory (bulk creation).

Overview

Short-lived projects like hackathons or workshops often have the following characteristics:

• Similar privileges for everyone on the project
• Only a few IAM (Identity and Access Management) roles like administrator or participant
• A preference for simple administration (setup, running it, clean up) over the tightest security
• Bulk onboarding and offboarding/cleanup

Additionally, over time, such projects are repeated with a similar setup, but different participants. So, how do you onboard them efficiently?

IBM Cloud Identity and Access Management (IAM) supports identification of users through different identities and identity providers, including the following:

• IBMid, an account for many IBM services, including IBM Cloud
• App ID user ID, a user managed within an instance of the IBM Cloud App ID service

The latter can be used as external Identity Provider (IdP) for IBM Cloud IAM. Thereby, users managed in App ID can authenticate against App ID and then log into IBM Cloud. Using the IAM concepts of Access Groups with dynamic rules or Trusted Profiles with conditions based on IdP data, App ID users can be assigned to access policies and their privileges set. 

The IBM Cloud document Best practices for organizing resources and assigning access has a comparison of access groups and trusted profiles. The main difference for our scenario is that when using an access group, users access the shared cloud account with their identity, whereas by utilizing a trusted profile, the profile itself (a single identity) would be used. Moreover, only individual users can easily work with the command line (CLI).

The setup is similar and we provide the code for both. In the following, we only discuss the setup based on access groups.

App ID for user management

The IBM Cloud App ID service provides easy user management and authentication to apps. It can serve as a wrapper around third-party identity services like Google and Facebook. App ID also has its own user management called Cloud Directory. For all users, regardless of their origin, App ID can maintain a profile. The profile can have attributes from their identity provider (like Cloud Directory, Facebook, etc.) and app-related attributes. It is possible to even pre-register profiles for future users with custom attributes.

For the onboarding and to assign privileges, we make use of these attributes. For a workshop, we could create and attach roles like admin(istrator), student or both to each user. These attributes could then later serve as conditions in the access group rules or for the trusted profiles:

As mentioned earlier, we want to use Terraform to create and configure an App ID instance. There are few resources to be deployed:

• Create a dedicated resource group to hold the App ID and possibly administrative resources
• Create a dedicated resource group for workshop resources
• Create the App ID instance as a IBM Cloud resource in that new administrative resource group
• Enable auditing for App ID events
• Configure the Cloud Directory so that users cannot sign up themselves, but use the self-service to reset their password
• Enable MFA (multi-factor authentication) for all users for enhanced security
• Disable the use of Google and Facebook for login
• Adapt the email templates (optional)
• Customize the App ID look and feel (optional)
• Configure the App ID token to include custom claims based on our custom attributes

With the above Terraform resources in place, they can be deployed. See the README in the cloud-project-onboarding-terraform repository for details on which commands to use.

Identity provider

Once, the App ID instance is available, the next step is to create an identity provider in the IBM Cloud IAM settings. It is a manual step in the IBM Cloud console. The screenshot shows the dialog to be completed. You need to provide a name, select the App ID instance and enable it for account login. If this is the only IdP, you can set it as the default:

Thereafter, you can also change the IdP URL to use an alias instead of your account ID. In the screenshot below, I changed the URL to use “workshop_hackathon” as alias. Later on, that URL needs to be used by your onboarded users to log in to IBM Cloud.

From the same page, remember the realm ID for the newly created IdP. It is necessary to set up the dynamic rule in the access group:

Access group with dynamic rules

Creating an IAM access group with a dynamic rule and access policies can be done in Terraform again. The sample code includes the resource definition for the access group itself. Then, a single policy allows read-only access for the targeted users to the workshop-related resource group. Most importantly, a rule that uses the IdP realm ID from above and a claim based on the App ID custom attributes.

Once deployed following the usage instructions, we can visit the access group and its dynamic rule in the IBM Cloud console. The condition checks that the “workshop_roles” contains “student”:

Conclusions

All that’s left is to add users to App ID. You can do this manually and also configure the custom attributes. Then, use your IdP URL (https://cloud.ibm.com/authorize/accountID-or-alias or https://cloud.ibm.com/authorize/accountID-or-alias/realmID) to login. In the follow-up post, “Bulk Creation of Users in IBM Cloud App ID,” we discuss how to perform a bulk upload of user records to App ID and how to maintain and reuse the IdP and App ID instance for additional workshops.

Visit the public GitHub repository for the sample code and additional information.

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik) or LinkedIn.