IAM Patterns

Identity and access management is the most critical pillar of cloud infrastructure, yet it is often implemented hastily without standardization and fine tuning. A proper implementation may seem daunting even in the smallest environment, but implementing or avoiding the patterns discussed below can increase the likelihood of success in the cloud.

Each cloud provider has their own tools and practices around IAM but the application of explicit policies to restrict access to resource groups under roles is universal.

Policies

Policies are one of the fundamental building blocks of cloud IAM and generally consist of statements allowing or denying an entity (a person, resource or specific service) the privilege to perform an action on a resource or service. Policies should be specific and avoid the use of wildcards unless appropriate in the context of a policy.

For example: a policy intended for database backup administrators would include the ability to trigger a backup routine on all database instances in an environment. It would be unwieldy and unnecessary to explicitly list every database instance in the environment, especially if instances are likely to be added or removed in the future. Remember, instant scalability is a major benefit of the cloud. A similar policy could also be constructed to allow database backup admins to store the backups in a specific storage bucket. In this case it would make sense to limit the write permissions of the policy to a single bucket, called out explicitly, rather than allowing writes to all buckets in an environment.

Roles

The other fundamental building block of cloud IAM is a role or ‘service account’ in the parlance of some cloud service providers. Roles are the glue that binds entities to policies. Much like a drivers license, a role allows the holder the privileges listed in the attached policies. Unlike a drivers license, however, an entity can be granted multiple roles, each with multiple policies attached. This many-to-many-to-many relationship presents its own hurdles as an organization grows beyond a handful of users and applications.

Enterprise Roles

A common pattern involves the deployment of a small set of “enterprise” wide roles which have been constructed and vetted to catch the broadest spectrum of use and compliance possible. In a sense, these are the “one size fits most” of IAM roles. This implementation can be effective in smaller organizations or widely homogeneous environments. At larger scales there tend to be significant inefficiencies. A change required for one team might violate another application’s compliance regimen, or break it entirely. Colloquially, this is referred to as “blast radius” and keen cloud practitioners will fight to keep it as small as possible.

Bespoke Roles

Alternatively, every application team, line of business, or admin can have their very own bespoke roles. Even with the requisite change control mechanism in place, this will rarely scale linearly and presents an often insurmountable challenge for compliance and general security teams. While the blast radius may be limited significantly or even completely, manageability and observability go out the window.

A Happy Medium

Luckily, cloud service providers have features that allow for a hybrid approach. Start by segmenting environments into logical units around business lines, teams, or applications. Arrange them in a hierarchy such that individual applications fall under their responsible teams which exist under a business line. Working in the other direction, apply controls from the top level down. These might be broad but bounded generalizations or more narrow service specific controls that trickle down the hierarchy where necessary. This pattern helps to simplify compliance while allowing for the greatest flexibility with a manageable amount of overhead.

“Go To Cloud” Strategy

At scale, any solution will require a non-trivial effort to implement. If you can automate just one aspect of your cloud infrastructure, make it identity and access management. Start by storing policy and role definitions in a revision control system. Use whatever the team is most comfortable with - implementation is less important than execution here.

Around this system, build a review and validation process that allows security and compliance stakeholders easy visibility into the controls being deployed in the environment. It should also not be so onerous that development is hindered. Document clear criteria for compliant/secure policies and have a review and exception process for special cases.

Finally, have a single conduit through which policies are deployed and attached to roles. This bottleneck is intentional and easily engineered around. Modern version control systems integrate nicely with deployment and provisioning tools, both cloud native and third party. Admins of a well architected IAM pipeline need only approve a pull request to set deployment in motion for their developers.

Conclusion

IAM is the glue that binds a cloud environment together. Take the time early on to plan out boundaries and permissions, promote a productive feedback loop, and automate away arduous and error-prone tasks. The security of your infrastructure depends on it.