pulumi/docs/security.md

Security

Mu's security concepts are inspired by UNIX's security model in addition to AWS's IAM system.

Identity (Users, Roles, Groups)

There are three primary constructs:

• User: An account that may be logged into by a human.
• Roles: An account that is assumed by services and cannot be logged into directly.
• Groups: A collection of Users and/or Roles that are granted a set of permissions in bulk, based on membership.

This scheme supports a great degree of flexibility, although the degree to which it is used varies greatly. Smart defaults are chosen to encourage the principle of least privilege.

To illustrate two ends of the spectrum, let's look at two cases.

First, a small team. This case, the default if no extra settings are chosen, pre-populates the following:

• An administrators Group with full permissions to everything in the Cluster.
• An administrator User assigned to the administrators Group.
• A developers Group with full permissions to the entire set of the Stack's Services.
• A developer User assigned to the developers Group.
• One service Role per Stack, with read-only permissions to each of the Stack's Services.

In the small team case, any Cluster-wide operations must be performed by a User in the administrators Group. One such User, administrator, is available out-of-the-box to do just that. Any operations that are specific to a Stack, on the other hand, can be performed by someone in the developers Group, which has far fewer permissions. One such User, developer, is available out-of-the-box for this purpose. Lastly, by having a service Role per Stack, we ensure that code running in the live service cannot perform privileges operations against the Cluster or even the Stacks within it.

TODO(joe): having one Role per Stack sounds good in theory, but I suspect it will be difficult in practice due to shared resources. We do understand dependencies, and prohibit cycles, however, thanks to capabilities. So it's worth giving this a shot... (this is left as an exercise in the translation doc.)

Second, an Enterprise-wide, shared cluster. In this case, we expect a operations engineer to configure the identities with precision, defense-in-depth, and the principle of least privilege. It is unlikely that administrator versus developer will be fine-grained enough. For instance, we may want to segment groups of developers differently, such that they can only modify certain Stacks, or perform only certain operations on Stacks.

Access Controls (ACLs)

TODO(joe): we still need to figure out the ACL "language" to use. Perhaps just RWX for each Stack. It's unclear how this muddies up the IAM mappings, etc. however.

Secrets

TODO(joe): configuration/secrets; see https://github.com/docker/docker/issues/13490.