December 18, 2018 | Written by: Paul Hooton
Categorized: Hybrid Deployments | Integration
IBM Event Streams on IBM Cloud is now Identity and Access Management enabled
But, what does that mean?
Identity and Access Management (IAM) is the mechanism IBM Cloud uses to control access by Users or Applications to Resources on the cloud. The Enterprise plan of IBM Event Streams on IBM Cloud now takes advantage of IAM integration to provide flexible and fine-grained access control to your Kafka resources.
Identity and Access Management (IAM)
Let’s first do a quick overview of IAM concepts.
IAM boils down into three layers:
- Users and Applications: Subjects that require access to Resources.
- Resources: Things you want to gain access to.
- Access Policies: Sometimes referred to as Roles, these are rules that define how much access you give the Subjects to those Resources.
Let’s look at each in turn.
Users and Applications
You will notice from the diagram that IAM uses the User ID to represent a user. For an Application, IAM uses the concept called a Service ID to allow Applications to connect to Resources.
One of the cool things about a Service ID is that it allows an Application outside of IBM Cloud to access your IBM Cloud services.
The other thing to note from the diagram is the concept of an Access Group. An Access Group is a way to group User IDs and Service IDs together and grant them group-wide access rights. For example, you might want all users or Service IDs in the HR department to be in one HR Access Group.
Resources are artifacts that a User or Application wants to access. So, on IBM Cloud, a Resource might be an Instance of a service that your organisation has created. For example, an Instance of Event Streams.
Additionally, a Resource might be a more granular entity within a service, like a Topic in Event Streams. These are referred to as Service Resource Types.
Example 2: Isolating Event Streams resources to different departments
Tim (remember he’s the IT lead) wants to allow different departments to use Event Streams. One way to do this would be to ask Brenda to create different Event Streams Instances for different departments and then assign access rights to each department to the different instances.
That is great and ensures a good level of isolation, but Tim has the idea that one day the departments might want to cross-collaborate. For that reason, he decides on a single Event Streams Instance.
As Brenda previously granted Tim the Editor platform role, Tim can create a Service Instance of Event Streams.
He has three departments asking to use Event Streams: HR, Sales, and Marketing.
Tim creates an Access Group for each department and adds the User IDs of that department to the respective Access Group. At the same time, Service IDs can be created for each Department and added to the respective Access Groups to allow for Applications written by that department to use the Instance.
Tim now has a choice. He can either delegate all Resource management of the Event Streams Instance, delegate some Resource management of the Event Streams Instance, or keep control on the Instance himself.
Let’s show what Tim needs to grant to the access groups for the departments for each of these options:
- If he wants to delegate full control, Tim grants Manager role on the “Cluster” Resource to the department Access Groups.
- If he wants to restrict delegation of control to just Topics, he grants Reader role on the “Cluster” Resource and Manager role on the Resource type “Topic” to the department Access Groups.
- If he wants to keep control himself and not delegate, he grants only Reader role on the “Cluster” Resource to the department Access Groups.
Tim decides on the third option of keeping control himself, which means he will manage all Resources (such as Topic creation).
Tim then creates some Topics for each department:
- HR1, HR2, HR3
- Sales1, Sales2, Sales3
- Mark1, Mark2, Mark3
The Reader role allows a User to consume only, so to allow the specific departments the ability to both produce/consume to the Topics, Tim then assigns the following:
- Writer role to the HR Access Group for the HR “Topic” Resources only
- Writer role to the Sales Access Group for the Sales “Topic” Resources only
- Writer role to the Marketing Access Group for the Mark “Topic” Resources only
Each department now only has access to its own Topics—effectively their own slice of an Event Streams Instance.
Example 3: Sharing topics between departments
Time moves on (note: Time moves on, not Tim; he is still there), and the department lead for Marketing approaches Tim. They want to be able to consume some information that is stored in the Sales Topics. After an agreement with the Sales department, Tim is able to grant the Reader role to the Marketing Access group for the Sales Topics, “Sales1.”
This allows the Marketing group to consume events from that Topic but not produce messages to it.
Additionally, the Sales team wants to feed sales information into a Marketing Topic. So, Tim grants Writer role to the Sales Access Group for the Marketing Topic “Mark2.”
This allows sales to produce events to the Marketing Topic for consumption by the marketing team.
So, not only is isolation achievable, cross-collaboration can easily be enabled.
As you can see, the combination of Event Streams Resources and the rich IAM features of IBM Cloud allows for very fine-grained and flexible access control to your Event Streams Instances and Resources.
Learn more here.
Get started on Event Streams for IBM Cloud.