Audited least privilege

*This article originally appeared in The News Stack on Thursday, May 2, 2024

‍

The principle of least privilege is a widely accepted security best practice where the aim is to minimize the access (or privilege) granted to identities across a number of dimensions:

• Minimalism: Level of access (e.g. admin > writer > reader > none)

• Minimalism: Scope of access (e.g. org > org unit / folder > account / project > resource > none)

• Ephemerality: Duration (e.g. forever > long-lived > short-lived > none)

‍

Generally identities within cloud platforms are created with a clean slate: no access to anything. This is a great starting point, and privileges are added via grants of a particular role (set of capabilities) at a particular Identity and Access Management (IAM) scope (ideally the exact resource those capabilities are needed to interact with).

Assuming everyone adheres to these ideals, least privilege is achieved. A good name for this model is Cooperative Least Privilege because it requires everyone participating in the access control model to work together to ensure least privilege is achieved (similar to cooperative multitasking).

‍

At Chainguard, we believe that any one security control is fallible, and employ a defense-in-depth model where we use multiple overlapping controls to have checks and balances that the overall system is working properly. It was in this vein that we began to ask ourselves how we check the assumptions of a cooperative least privilege model, and ensure that there is no untoward access of our resources.

‍

It is fairly typical to focus on the actor when reasoning about least privilege, as evidenced by our identity-centric visualization above, but what if we were to reorient around the atoms on the other side of the access grant arrows? What might a resource-centric view of least privilege look like?

However, due to the hierarchical nature of IAM models, the grants that allow access could be challenging to fully discover. So how can we ensure that our resources are only accessed in the ways we expect by the identities we expect to interact with them? The answer became pretty plain to see: IAM audit logs.

‍

The cornerstone of cooperative least privilege is very fine IAM access grants. When we flip things around the dual is very fine IAM audit log policies. A good name for this model is Audited Least Privilege.

‍

In the audited least privilege model, we pair each cloud resource that we provision with an IAM audit log alert policy that triggers whenever a resource is accessed outside of the expected minimum. This minimum is typically defined in terms of a set of IAM principals mapped to acceptable interactions (like in our diagram above). My pet name for these IAM alert policies has become the “laser grid” because it evokes the Hollywood heist visual of the priceless artifact surrounded in laser beams.

‍

I would argue that either of these models, sufficiently curated at a very fine grain, would satisfy the principle of least privilege, but audited least privilege is not intended as a replacement for cooperative least privilege, it is intended as a complementary overlapping security control that can be employed as part of a layered defense in depth strategy.