docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Clean up docs about resource sets

This commit is contained in:
Joao Fernandes 2018-05-14 16:55:10 -07:00 committed by Joao Fernandes
parent c32dd765f3
commit cd86f4bc2c
2 changed files with 30 additions and 78 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
ee/ucp/authorization/group-resources.md
View File

@ -7,53 +7,40 @@ redirect_from:
---
Docker EE enables access control to cluster resources by grouping resources
into *resource sets*. Combine resource sets with [grants](grant-permissions)
into **resource sets**. Combine resource sets with [grants](grant-permissions)
to give users permission to access specific cluster resources.
A resource set can be a UCP collection or a Kubernetes namespace, depending
on the orchestrator. Use collections for Swarm workloads, and use namespaces
for Kubernetes workloads.
A resource set can be:
## Kubernetes namespace
* A **Kubernetes namespace** for Kubernetes workloads.
* A **UCP collection** for Swarm workloads.
A
[namespace](https://v1-8.docs.kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
is a logical area for a Kubernetes cluster. Kubernetes comes with a `default`
namespace for your cluster objects (plus two more for system and public
resources). You can create custom namespaces, but unlike Swarm collections,
namespaces _cannot be nested_.
## Kubernetes namespaces
> Resource types that can be placed into a Kubernetes namespace include: Pods,
> Deployments, NetworkPolicies, Nodes, Services, Secrets, and many more.
A namespace allows you to group resources like Pods, Deployments, Services, or
any other Kubernetes-specific resources. You can then enforce RBAC policies
and resource quotas for the namespace.
Resources are placed into a namespace when you create a Kubernetes object. A
drop down displays all available namespaces and one must be selected.
Each Kubernetes resources can only be in one namespace, and namespaces cannot
be nested inside one another.
## Swarm collection
[Learn more about Kubernetes namespaces](https://v1-8.docs.kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/).
A collection is a directory of grouped resources, such as services, containers,
volumes, networks, and secrets. To authorize access, administrators create
grants against these directory branches.
## Swarm collections
A Swarm collection is a directory of cluster resources like nodes, services,
volumes, or other Swarm-specific resources.
![](../images/collections-and-resources.svg){: .with-border}
### Access label
Access to a collection is granted with a path defined in an access label.
For example, each user has a private collection with the path,
`/Shared/Private/<username>`. The private collection for user "molly" would have
the access label: `com.docker.ucp.access.label = /Shared/Private/molly`.
To deploy applications into a custom collection, you must define the collection
first. For an example, see [Deploy stateless app with RBAC](deploy-stateless-app.md).
When a user deploys a resource without an access label, Docker EE automatically
places the resource in the user's default collection.
Each Swarm resource can only be in one collection at a time, but collections
can be nested inside one another, to create hierarchies.
### Nested collections
You can nest collections. If a user has a grant against a collection, the grant
applies to all of its child collections.
You can nest collections inside one another. If a user is granted permissions
for one collection, they'll have permissions for its child collections,
pretty much like a directory structure..
For a child collection, or for a user who belongs to more than one team, the
system concatenates permissions from multiple roles into an "effective role" for
@ -63,6 +50,8 @@ the user, which specifies the operations that are allowed against the target.
Docker EE provides a number of built-in collections.
![](../images/collections-diagram.svg){: .with-border}
| Default collection | Description |
|:-------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `/` | Path to all resources in the Swarm cluster. Resources not in a collection are put here. |
@ -71,12 +60,6 @@ Docker EE provides a number of built-in collections.
| `/Shared/Private/` | Path to a user's private collection. |
| `/Shared/Legacy` | Path to the access control labels of legacy versions (UCP 2.1 and lower). |
This diagram shows the `/System` and `/Shared` collections created by Docker EE.
User private collections are children of the `/Shared/private` collection. Here,
the Docker EE administrator user created a `/prod` collection and a child
collection, `/webserver`.
![](../images/collections-diagram.svg){: .with-border}
### Default collections
@ -124,39 +107,6 @@ stack's resources in multiple collections. Resources are placed in the user's
default collection unless you specify an explicit `com.docker.ucp.access.label`
within the stack/compose file.
### Control access to nodes
The Docker EE Advanced license enables access control on worker nodes. Admin
users can move worker nodes from the default `/Shared` collection into other
collections and create corresponding grants for scheduling tasks.
Also, you can [isolate a Kubernetes workload](isolate-nodes.md##deploy-a-Kubernetes-application)
to specific worker nodes, based on a Kubernetes namespace.
In this example, an administrator has moved worker nodes to a `/prod`
collection:
![](../images/containers-and-nodes-diagram.svg)
When you deploy a resource with a collection, Docker EE sets a constraint
implicitly based on what nodes the collection, and any ancestor collections, can
access. The `Scheduler` role allows users to deploy resources on a node. By
default, all users have the `Scheduler` role against the `/Shared` collection.
When deploying a resource that isn't global, like local volumes, bridge
networks, containers, and services, the system identifies a set of "schedulable
nodes" for the user. The system identifies the target collection of the
resource, like `/Shared/Private/molly`, and it tries to find the parent that's
closest to the root that the user has the `Node Schedule` permission on.
For example, when a user with a default configuration runs `docker container run
nginx`, the system interprets this to mean, "Create an NGINX container under the
user's default collection, which is at `/Shared/Private/molly`, and deploy it on
one of the nodes under `/Shared`.
If you want to isolate nodes against other teams, place these nodes in new
collections, and assign the `Scheduler` role, which contains the `Node Schedule`
permission, to the team. [Isolate swarm nodes to a specific team](isolate-nodes.md).
## Where to go next

14
ee/ucp/authorization/isolate-nodes.md
View File

@ -9,6 +9,8 @@ by organizing nodes into collections and granting `Scheduler` access for
different users. To control access to nodes, move them to dedicated collections
where you can grant access to specific users, teams, and organizations.
![](../images/containers-and-nodes-diagram.svg)
In this example, a team gets access to a node collection and a resource
collection, and UCP access control ensures that the team members can't view
or use swarm resources that aren't in their collection.
@ -176,7 +178,7 @@ that has a `Service Create` grant for the user.
## Deploy a Kubernetes application
Starting in Docker Enterprise Edition 2.0, you can deploy a Kubernetes workload
to worker nodes, based on a Kubernetes namespace.
to worker nodes, based on a Kubernetes namespace.
1. Convert a node to use the Kubernetes orchestrator.
2. Create a Kubernetes namespace.
@ -184,12 +186,12 @@ to worker nodes, based on a Kubernetes namespace.
4. Link the namespace to a node collection.
5. Deploy a Kubernetes workload.
### Convert a node to Kubernetes
### Convert a node to Kubernetes
To deploy Kubernetes workloads, an administrator must convert a worker node to
use the Kubernetes orchestrator.
[Learn how to set the orchestrator type](../admin/configure/set-orchestrator-type.md)
for your nodes in the `/Prod` collection.
for your nodes in the `/Prod` collection.
### Create a Kubernetes namespace
@ -228,8 +230,8 @@ The last step is to link the Kubernetes namespace the `/Prod` collection.
1. Navigate to the **Namespaces** page, and find the **ops-nodes** namespace
in the list.
2. Click the **More options** icon and select **Link nodes in collection**.
2. Click the **More options** icon and select **Link nodes in collection**.
![](../images/isolate-nodes-7.png){: .with-border}
3. In the **Choose collection** section, click **View children** on the
@ -273,7 +275,7 @@ The last step is to link the Kubernetes namespace the `/Prod` collection.
5. Click **Create** to deploy the workload.
6. In the left pane, click **Pods** and confirm that the workload is running
on pods in the `ops-nodes` namespace.
on pods in the `ops-nodes` namespace.
![](../images/isolate-nodes-10.png){: .with-border}