Skip to content

Commit cd75695

Browse files
author
Jim Galasyn
committed
First draft of Kube node rbac section (#356)
1 parent 9eaf0ab commit cd75695

File tree

7 files changed

+120
-12
lines changed

7 files changed

+120
-12
lines changed

datacenter/ucp/3.0/guides/authorization/isolate-nodes.md

Lines changed: 120 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
2-
title: Isolate Swarm nodes in Docker Advanced
2+
title: Isolate cluster nodes in Docker Advanced
33
description: Create grants that limit access to nodes to specific teams.
4-
keywords: ucp, grant, role, permission, authentication
4+
keywords: ucp, grant, role, permission, authentication, node, Kubernetes
55
---
66

77
With Docker EE Advanced, you can enable physical isolation of resources
@@ -118,18 +118,22 @@ The same steps apply for the nodes in the `/Prod` collection.
118118

119119
![](../images/isolate-nodes-2.png){: .with-border}
120120

121-
## Deploy a service as a team member
121+
The cluster is set up for node isolation. Users with access to nodes in the
122+
`/Prod` collection can deploy [Swarm services](#deploy-a-service-as-a-team-member)
123+
and [Kubernetes apps](#kubernetes-apps), and their workloads won't be scheduled
124+
on nodes that aren't in the collection.
122125

123-
Your swarm is ready to show role-based access control in action. When a user
124-
deploys a service, UCP assigns its resources to the user's default collection.
125-
From the target collection of a resource, UCP walks up the ancestor collections
126-
until it finds nodes that the user has `Scheduler` access to. In this example,
127-
UCP assigns the user's service to the `/Prod/Webserver` collection and schedules
128-
tasks on nodes in the `/Prod` collection.
126+
## Deploy a Swarm service as a team member
129127

130-
As a user on the Ops team, set your default collection to `/Prod/Webserver`.
128+
When a user deploys a Swarm service, UCP assigns its resources to the user's
129+
default collection. From the target collection of a resource, UCP walks up the
130+
ancestor collections until it finds nodes that the user has `Scheduler` access
131+
to. In this example, UCP assigns the user's service to the `/Prod/Webserver`
132+
collection and schedules tasks on nodes in the `/Prod` collection.
131133

132-
1. Log in as a user on the Ops team.
134+
As a user on the `Ops` team, set your default collection to `/Prod/Webserver`.
135+
136+
1. Log in as a user on the `Ops` team.
133137
2. Navigate to the **Collections** page, and in the **Prod** collection,
134138
click **View Children**.
135139
3. In the **Webserver** collection, click the **More Options** icon and
@@ -157,7 +161,7 @@ All resources are deployed under the user's default collection,
157161

158162
![](../images/isolate-nodes-4.png){: .with-border}
159163

160-
## Alternative: Use a grant instead of the default collection
164+
### Alternative: Use a grant instead of the default collection
161165

162166
Another approach is to use a grant instead of changing the user's default
163167
collection. An administrator can create a grant for a role that has the
@@ -166,6 +170,110 @@ collection. In this case, the user sets the value of the service's access label,
166170
`com.docker.ucp.access.label`, to the new collection or one of its children
167171
that has a `Service Create` grant for the user.
168172

173+
## Deploy a Kubernetes application
174+
175+
Starting in Docker EE Platform 2.0, you can deploy a Kubernetes workload to
176+
worker nodes, based on a Kubernetes namespace.
177+
178+
1. Convert a node to use the Kubernetes orchestrator.
179+
2. Create a Kubernetes namespace.
180+
3. Create a grant for the namespace.
181+
4. Link the namespace to a node collection.
182+
5. Deploy a Kubernetes workload.
183+
184+
### Convert a node to Kubernetes
185+
186+
To deploy Kubernetes workloads, an administrator must convert a worker node to
187+
use the Kubernetes orchestrator.
188+
[Learn how to set the orchestrator type](../admin/configure/set-orchestrator-type.md)
189+
for your nodes in the `/Prod` collection.
190+
191+
### Create a Kubernetes namespace
192+
193+
An administrator must create a Kubernetes namespace to enable node isolation
194+
for Kubernetes workloads.
195+
196+
1. In the left pane, click **Kubernetes**.
197+
2. Click **Create** to open the **Create Kubernetes Object** page.
198+
3. In the **Object YAML** editor, paste the following YAML.
199+
200+
```yaml
201+
apiVersion: v1
202+
kind: Namespace
203+
metadata:
204+
Name: ops-nodes
205+
```
206+
4. Click **Create** to create the `ops-nodes` namespace.
207+
208+
### Grant access to the Kubernetes namespace
209+
210+
Create a grant to the `ops-nodes` namespace for the `Ops` team by following the
211+
same steps that you used to grant access to the `/Prod` collection, only this
212+
time, on the **Create Grant** page, pick **Namespaces**, instead of
213+
**Collections**.
214+
215+
![](../images/isolate-nodes-5.png){: .with-border}
216+
217+
Select the **ops-nodes** namespace, and create a `Full Control` grant for the
218+
`Ops` team.
219+
220+
![](../images/isolate-nodes-6.png){: .with-border}
221+
222+
### Link the namespace to a node collection
223+
224+
The last step is to link the Kubernetes namespace the `/Prod` collection.
225+
226+
1. Navigate to the **Namespaces** page, and find the **ops-nodes** namespace
227+
in the list.
228+
2. Click the **More options** icon and select **Link nodes in collection**.
229+
230+
![](../images/isolate-nodes-7.png){: .with-border}
231+
232+
3. In the **Choose collection** section, click **View children** on the
233+
**Swarm** collection to navigate to the **Prod** collection.
234+
4. On the **Prod** collection, click **Select collection**.
235+
5. Click **Confirm** to link the namespace to the collection.
236+
237+
![](../images/isolate-nodes-8.png){: .with-border}
238+
239+
### Deploy a Kubernetes workload to the node collection
240+
241+
1. Log in in as a non-admin who's on the `Ops` team.
242+
2. In the left pane, open the **Kubernetes** section.
243+
3. Confirm that **ops-nodes** is displayed under **Namespaces**.
244+
4. Click **Create**, and in the **Object YAML** editor, paste the following
245+
YAML definition for an NGINX server.
246+
247+
```yaml
248+
apiVersion: v1
249+
kind: ReplicationController
250+
metadata:
251+
name: nginx
252+
spec:
253+
replicas: 1
254+
selector:
255+
app: nginx
256+
template:
257+
metadata:
258+
name: nginx
259+
labels:
260+
app: nginx
261+
spec:
262+
containers:
263+
- name: nginx
264+
image: nginx
265+
ports:
266+
- containerPort: 80
267+
```
268+
269+
![](../images/isolate-nodes-9.png){: .with-border}
270+
271+
5. Click **Create** to deploy the workload.
272+
6. In the left pane, click **Pods** and confirm that the workload is running
273+
on pods in the `ops-nodes` namespace.
274+
275+
![](../images/isolate-nodes-10.png){: .with-border}
276+
169277
## Next steps
170278

171279
* [Isolate volumes](isolate-volumes.md)
117 KB
Loading
82.2 KB
Loading
88.2 KB
Loading
67.3 KB
Loading
101 KB
Loading
60.7 KB
Loading

0 commit comments

Comments
 (0)