Imagine arriving at a Hotel after a tiring day-long trip. You drag you bags into the lobby and you patiently wait in line to receive service. The desk attendant greets you with a smile and you feel genuinely welcomed. You give the attendant your name and they quickly find that you have a reservation. Before you know it, the attendant has given you two room keys, and lets you know the exact route to your room and how to access your room. You get to your room, you lie on your bed, and think to yourself, that was a such a seamless experience and exactly what you needed after a long, hard day of travel.
You may be surprised to know this but, using a IAM or Identity and Access Management tool can perfectly parallel that almost perfect hotel check-in experience for developers on your team. IAMs allow for developers to easily manage access and security to their services on the Cloud in one straightforward and easy to you use place, making application and service onboarding a breeze for developers on your team and help make service and application management more streamlined and secure.
What is IAM?
So what exactly is IAM, or Identity and Access Management?
Essentially, IAM enables developers to consistently control access and authentication to a cloud provider's platform services. This means that managing how users access services in the Cloud and how they connect to those services can now be managed all in one place.
This is a huge advantage to developers in the cloud. Now, instead of having to manually keep track of who has access to what and having to manage things like API keys in separate ways for every different services you have in the cloud, you now have one place to manage all of that at once.
So let's go back for a moment to the hotel desk attendant story I shared earlier. Think about what it would take for the desk attendant to quickly and seamlessly check if a guest is booked at the hotel and if that particular guest should have access to any given room and also create a key that would then give that guess access to a room in the hotel (or in other words, manage a particularly guests access to any given room). What it would take, is a centralized system that allows the desk attendant to have the ability to confirm a guest's identity and manage a guest's access to assets on the hotel's property.
Do you see where I'm going with all this?
The ability for a desk attendant to confirm identities and manage access in respect to hotel rooms is the exact parallel of what an IAM empowers a developer to do in respect to cloud services and applications.
How IAM works
So in order for a developer to truly leverage IAM, it's key for them to understand the basics and how it all works. So let's take a look at the how IBM Cloud implements IAM and how the different are concepts used.
NOTE: Though I will be using IBM Cloud to illustrate IAM concepts, most cloud providers that use IAM use very similar concepts and structures. For a breakdown on how IBM Cloud IAM concepts map to other cloud providers, check out this Mapping IBM Cloud IAM concepts to other providers link
So here's a look at how access managements works displayed in a visual diagram:
Source: IBM Cloud IAM Documentation
So at first glance, this diagram may look bit complicated but let me break it down to fill in the picture (Get it!😅) .
So every IAM begins at the Account Level. Any particular IAM Account can have many Users and Service IDs.
Users are the different people who may have access to the applications and services you have hosted in IBM Cloud. They are identified by IBMid, Softlayer, or AppID user IDS.
Service IDs are used to identify different applications and services. Service IDs can be used so that individual user credentials don't need to be used to access any particular application or service.
Users and Service IDs are all members of an Access Group and are assigned to a Policy.
Access Groups are a group of users and/or service IDs that can be all be assigned the same level of access to cloud resources. It allows a developer to streamline the access assignment process by literally "grouping access"
Policies are how Users, Service IDs and Access Groups are given permission to use, access, and interact with cloud resources in any particular Account. Policies allow you to assign Roles which help manage access levels for doing management tasks, working with service instances, and other actions.
Finally, Policies apply to Resource Groups and to Resources which are made up of Service Instances and ** Services**.
Resource Groups are just a group of IAM-enabled Resources within your Account and a Resource can be an IBM Cloud Service or an Service Instance, which is an individual deployment of a particular service cloud service that has been created.
In summary, within an Account, an account manager can manage Users and Service IDs access levels using Access Groups. These Access Groups use Policies* and **Roles to assign access levels to Resources and Resources Groups, which are made up of Service Instances and Services.
Why You Should Care
So imagine you are a developer of a ReactJS Application hosted in the cloud that allows users to check apartment rental prices in different regions of some country. Recently, you have been told, you need to add a new section to the website that allows viewing house rental prices in different regions as well. You find out that the data for this section of the website will be housed in a Cloudant NoSQL Database, hosted in IBM Cloud, and you will need to serve the data to your ReactJS frontend using a NodeJS server, that will also be hosted in the cloud.
So it is now your job to figure how to connect with the Cloudant NoSQL DB securely to your NodeJS application.
Without IAM, you would need someone who has direct access to Cloudant NoSQL DB, and they would need to create new security credentials or use existing security credentials and would need to "manually" configure your access level. If for some reason something changes in the database, they would need to again create new credentials and you would need to reconfigure you NodeJS server when that change happens.
With IAM, if you were not already a part of the Account, you would just need to be added as a User. Once added as a user of the IAM, you would just be added to the Access group that has the corresponding Policy that allows access to the Cloudant NoSQL DB. With that, you would be given the credentials you need to access ANY resources that Access Group has access to. So that means, if in the future, a new Database or service was added to the IBM Cloud account that you needed access to, the Account manager would just modify your Access Groups policy and you would immediately have access to those resources as well, without needing new credentials. Not only is there an ease of access from your point-of-view as a developer, but this guarantees an even more secure way of accessing resources, as all resources are managed and monitored in one central location.
If you have never had to manage, configure, or integrate with multiple services in a cloud environment, it may be hard to see the benefit from the outset of using IAM. But the benefit is huge. It saves time from both a management level and a user level. Now instead of juggling keys and maybe losing track of who has access to what, and what level of access, you now have control of all access and user information in one convenient place.
IAM Features
So let's take a quick look at some of the high-level features that you have access to when using an IAM with a cloud provider (NOTE: This is primarily based on IBM Cloud IAM but other cloud providers offer similar features):
User Management: Add and delete users in an account for both platform and classic infrastructure services. Using Access Groups makes it easy to add more than one user or service ID at a time.
Fine-grained Access Control: Access for users, service IDs, and access groups is defined by a policy. Policies determine the scope of access to a set of resources in a resource group, a single resource, or account management services. Roles can also be provided, which tailor the level of access that is granted in a policy to perform actions, whether it's platform management tasks within the account or accessing a service's UI or completing API calls.
Access Groups that Streamline Access Management: Quickly and easily assign access for a group or users or service IDs by Access Group. Access groups enable you to manage a minimal number of policies in your account.
API Keys for User Authentication: Create multiple API keys for a user to support key rotation scenarios, and the same key can be used for accessing multiple services. IBM Cloud API keys, in particular, enable users who use two-factor authentication or a federated ID to automate authentication to the console from the command line. Also, a user can have a single classic infrastructure API key that can be used to access classic infrastructure APIs.
Service IDs: A service ID identifies a service or application similar to how a user ID identifies a user. IDs can be used by applications to authenticate with an IBM Cloud service. Policies can be assigned to each service ID to control the level of access that is allowed by an application that uses the service ID, and an API key can be created to enable the authentication.
Multi-factor Authentication: You can require multi-factor authentication (MFA) for every user in the account or just users with non-federated IDs who do not use SSO.
Service-to-Service Authorizations: If you need to provide one service access to another, you can create a policy by using a service to service authorization.
As you can see, IAM offers a ton of features that help streamline the user management and security aspect of services and applications in the cloud. So just like a hotel desk attendant standing in front of a single computer that controls all things associated to guests and room access, IAM allows developers to manage user identities and standardize access controls to cloud applications and services. If you haven't already begun using IAMs in your cloud provider's ecosystems, I encourage you to investigate what they have to offer and to see how it can simplify your cloud resource access approach today.
If you are interested in learning more about IAMs, check out the documentation of IBM Clouds implementation of IAM: What is IBM Cloud Identity and Access Management?
If you are interested in trying out IAM concepts in the cloud, signup for your FREE IBM Cloud account here to check it out: IBM Cloud Signup
Thanks for checking out my Blog! Take it easy!
==== FOLLOW ME ON SOCIAL MEDIA ====
Twitter: Bradston Dev
Dev.to: @bradstondev
Youtube: Bradston YT
Top comments (0)