2016-11-04 23:37:12 +01:00
|
|
|
# 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).
|
|
|
|
|
2016-11-05 00:06:53 +01:00
|
|
|
## Personas
|
|
|
|
|
|
|
|
Mu's architecture is flexible enough to describe a range of scenarios -- from single- to multi-tenant -- and team sizes
|
|
|
|
-- from small developer teams doing DevOps to large Enterprise organizations with dedicated IT operations departments.
|
|
|
|
Although the details for different points on this spectrum vary greatly, Mu attempts to choose smart defaults that
|
|
|
|
encourage best practices like [defense in depth](
|
|
|
|
https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) and the [principle of least privilege](
|
|
|
|
https://en.wikipedia.org/wiki/Principle_of_least_privilege).
|
|
|
|
|
|
|
|
That said, we see the following three personas emerging in modern cloud management:
|
|
|
|
|
|
|
|
* Application/service developer: A person who writes and deploys code into an existing cluster.
|
|
|
|
* Application/service ops: A person who performs operational activities against an existing cluster, including
|
|
|
|
provisioning or managing new or existing applications or services.
|
|
|
|
* IT ops: A person who performs operational activities on the cluster and underlying infrastructure itself.
|
|
|
|
|
|
|
|
Note that a single person may assume multiple personas. For instance, an ISV might choose to lump all developers into
|
|
|
|
the application/service developer and ops personas, but then have dedicated ops specialists who manage the
|
|
|
|
infrastructure. A large Enterprise, on the other hand, might want specialized members in each distinct persona.
|
|
|
|
|
2016-11-04 23:37:12 +01:00
|
|
|
## 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.
|
2016-11-06 18:51:23 +01:00
|
|
|
* **Groups**: A collection of Users, Roles, and/or other Groups that are granted a set of permissions in bulk.
|
2016-11-04 23:37:12 +01:00
|
|
|
|
2016-11-06 18:51:23 +01:00
|
|
|
Note that adding a Group B to another Group A essentially makes Group B a "child" of Group A, in that Group B inherits
|
|
|
|
the capabilities of A. If Group B itself has children, those too become "grandchildren" of Group A, and so forth.
|
2016-11-04 23:37:12 +01:00
|
|
|
|
2016-11-06 18:51:23 +01:00
|
|
|
These constructs can be used to create flexible security policies, ranging from very simple to very capable. To
|
|
|
|
illustrate two ends of the usage spectrum, let's look at two common "extremes."
|
|
|
|
|
|
|
|
First, consider a small team. This case, the default if no extra settings are chosen, pre-populates the following:
|
2016-11-04 23:37:12 +01:00
|
|
|
|
|
|
|
* 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.)
|
|
|
|
|
2016-11-06 18:51:23 +01:00
|
|
|
Second, consider 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.
|
|
|
|
|
|
|
|
## Rights and Access Controls (ACLs)
|
2016-11-04 23:37:12 +01:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2016-11-06 19:02:06 +01:00
|
|
|
## Authentication
|
|
|
|
|
|
|
|
TODO(joe): enforced credential rotations.
|
|
|
|
|
|
|
|
TODO(joe): articulate how the mapping between Mu identity and cloud-provider identity works.
|
|
|
|
|
2016-11-04 23:37:12 +01:00
|
|
|
## Secrets
|
|
|
|
|
|
|
|
TODO(joe): configuration/secrets; see https://github.com/docker/docker/issues/13490.
|
|
|
|
|
2016-11-06 18:51:23 +01:00
|
|
|
## Auditing
|
|
|
|
|
|
|
|
TODO(joe): describe the auditing capabilities of the platform.
|
|
|
|
|