4.7 KiB
Coconut Security
Coconut's security concepts are inspired by UNIX's security model in addition to AWS's IAM system.
Personas
Coconut'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, Coconut attempts to choose smart defaults that encourage best practices like defense in depth and the 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.
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, Roles, and/or other Groups that are granted a set of permissions in bulk.
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.
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:
- An
administrators
Group with full permissions to everything in the Cluster. - An
administrator
User assigned to theadministrators
Group. - A
developers
Group with full permissions to the entire set of the Stack's Services. - A
developer
User assigned to thedevelopers
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, 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)
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.
Authentication
TODO(joe): enforced credential rotations.
TODO(joe): articulate how the mapping between Coconut identity and cloud-provider identity works.
Secrets
TODO(joe): configuration/secrets; see https://github.com/docker/docker/issues/13490.
Auditing
TODO(joe): describe the auditing capabilities of the platform.