52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
|
# Security
|
||
|
|
|
||
|
|
Mu's security concepts are inspired by [UNIX's security model](https://en.wikipedia.org/wiki/Unix_security) in addition
|
||
|
|
to [AWS's IAM system](http://docs.aws.amazon.com/IAM/latest/UserGuide/id.html).
|
||
|
|
|
||
|
|
## 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](
|
||
|
|
https://en.wikipedia.org/wiki/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.
|
||
|
|
|