How to set up access privileges in a development team.

One of my favorite IBM Cloud solution tutorials is about building a database-driven Slackbot. It’s a great example of integrating enterprise resources with an AI-backed user interface and utilizing serverless technology for the glue. 

Once you have created the chatbot, the next step is to share this project with coworkers—but how do you proceed? In this blog post, I am going to discuss how to set up privileges for team members so that they can access the project resources in different roles. You’ll learn about IBM Cloud IAM, access groups, and policies, and get some hands-on experience with IBM Cloud security:

Overview: Database-driven Slackbot

The solution tutorial introduces a chatbot that is integrated with Slack as user interface. IBM watsonx Assistant serves as an AI-powered dialog service and calls out to webhooks implemented as IBM Cloud Functions. The serverless actions perform SQL queries against Db2 to store and fetch enterprise data. You can use the same approach to integrate the chatbot with other data source—as simple as with Wikipedia (as shown in this tutorial) or full ERP systems.

In an abstraction, the chatbot consists of the dialog service, the integration layer, and a database system. In the following, we are going to learn how to assign access privileges to all three of these components.

Resource Access Management

On IBM Cloud, Identity and Access Management (IAM) enables the authentication of users and service IDs and the access control to cloud resources. Usually, there is a distinction between platform management and service access privileges (and, hence, roles). The former allow to operate the service instance (e.g., to see or change properties, bind the service, or generate credentials). The service access privileges control how a user can work with resources of that service instance (e.g., a user may only execute a function, but not modify it or create new).

For granting access, you can assign predefined access roles to either a user, a service ID, or to an access group. An access group can be created to organize a set of users and service IDs into a single entity. It makes it easy for you to assign access. You can assign a single policy to the group instead of assigning the same access multiple times per individual user or service ID.

In order to grant access to chatbot resources, you could create access groups for different development and administration roles. Not all users might need to modify (develop) the dialog—some might be in charge of developing the serverless actions and others of administrating the Db2 database. 

Access to chatbot components

To organize access to the chatbot components, we need to take a look at specific IAM capabilities on the service level.

watsonx Assistant

watsonx Assistant offers predefined Reader, Writer, and Manager roles. They allow the user to only see and to try out a skill with its chatbot dialog, or to create new skills and assistants, or to even see logging and other data. This means that you could share a chatbot skill for testing, but not allow modifications to it. When assigning access, it is possible to select only a specific skill and grant read-only access to it. This is shown in the following screenshot:

IBM Cloud Functions

IBM Cloud Functions uses IAM-controlled namespaces to manage actions, sequences, packages, and more. Therefore, service access roles for Functions deal with either being able to see objects and execute actions available in that namespace, create and modify objects, or even to modify and delete that namespace.

Db2 on Cloud

As a database system, IBM Db2 on Cloud is different from the previous services in terms of authorization. Most of the privileges are managed within the database itself. IAM only controls who has access to Db2 and whether it is as Administrator or User. In a recent blog, I discussed how to increase information security for Db2 on IBM Cloud be leveraging IAM features.

Define access groups

With knowledge of the service-specific privileges in place, you could define access groups related to how your team and development work is organized, following the best practices for assigning access. The following screenshot shows an access group defining Viewer privilege to all three chatbot components and the Reader role to the watsonx Assistant skill and the Functions namespace. It could be used for, e.g., quality testers who need to access the chatbot dialog and to execute all the code, but have no need to change anything:

Conclusions

By making use of IBM Cloud Identity and Access Management features, it is fairly easy and straight-forward to manage access to cloud resources. When you followed one of the solution tutorials, you can later share the created resources and experience with other users, as discussed in this blog. We did not discuss further enhancements, such as making use of custom roles or dynamic rules. 

To get started with with organizing your account and access to its resources, I recommend reading the following best practices guides:

• Best practices for setting up your account
• Best practices for assigning access
• Best practices for setting up an enterprise

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