A cloud native identity management system contains three principle aims:

• Enable the productivity of individuals within the organization to perform their day-to-day responsibilities. These include DB administrators, security officers, and developers.
• Enable machines that perform automated actions within the environment. These functions, applications, or machines are increasingly important as environments become larger.
• Enable users/consumers to securely connect to your public-facing services. This entails securing and authenticating your consumers' identities.

CSPs have well-developed IAM services (such as AWS IAM) that allow the creation of custom policies dictating what can be done within the cloud environment. These policies can be attached to groups, which aggregate the most restrictive interpretation of several policies into one administrative body. For each individual working within the environment, a user can be created with unique logins for console access and a unique key/secret for making API calls to the environment. Each interaction the user makes with the environment will be restricted to what is allowed in the policies attached to the group the user is placed in:

Policies can be used for both roles and groups. They can even be attached to specific users, though this is not best practice. Roles assigned to services and machines are able to implicitly gain access to other parts of the cloud landscape, enabling automation patterns.

When dealing with multiple cloud accounts and other SaaS platforms, it is best practice to provide your staff with a Single Sign On (SSO) solution. This makes the switching of user profiles across multiple cloud environments (for example Azure, AWS, GCP, Salesforce, and so on) easier and more secure. One of the principal human errors introduced as the IT estate sprawls over multiple vendors is the user managing multiple logins (usually for the same CSP environment), which can prove disastrous (or equally frustrating when logging in with the wrong profile).

Emphasis in a cloud native environment is always on automation engineering. Every IT shop should be focused on enabling machines to do their jobs, freeing up more time for the users to build more machines. In order to safely power this virtuous cycle, we need mechanisms to enable machines while restricting them from being exploited by bad actors. It should be noted that applications that utilize cloud services will use similar mechanisms, so this discussion is not just limited to IT environment management tools, but all applications programmatically interacting with the cloud.

The first option is the use of roles. Roles are given to services and machines with certain policies (these are the same policies we built for our groups/users). These roles broker abilities to the attached entities that are handled by the CSP. Keys are programmatically given to the machine and services when making the API calls.

For applications, the embedding of secrets in code is a dangerous vulnerability. Instead, we can utilize the second option, the use of token services that generate and share time-limited credentials to make API calls. This key expires at the end of a set time, upon which the application will need to make a new request to the token service. The AWS Security Token Service (STS) is a highly useful tool to accomplish the use of secrets in applications.