First drafts of rbac tutorials (#227)

datacenter/ucp/2.2/guides/admin/manage-users/access-control/design-access-control-ee-advanced.md

@@ -0,0 +1,75 @@
+---
+title: Design access control in Docker EE Advanced
+description: Learn how to architect multitenancy by using Docker Enterprise Edition Advanced.
+keywords: authorize, authentication, users, teams, groups, sync, UCP, role, access control
+---
+
+[Collections and grants](../manage-users/) are strong tools that can be used to control access and visibility to resources in UCP. The previous [Introductory Multitenancy Tutorial](design-access-control-ee-standard.md) describes a fictional company called SecureBank that has designed a resource access architecture that fits the specific security needs of their organization. Be sure to go through this tutorial if you have not already before continuing. 
+
+In this tutorial SecureBank's deployment model and organizational structure has grown in complexity and will require a new UCP access control design to accommodate it. This tutorial builds on the [Introductory Tutorial](design-access-control-ee-standard) by introducing centralized LDAP/AD, multiple grants per team, and also the ability for resources to be shared between different teams.
+
+
+## Team Access Requirements
+
+After the initial RBAC design, SecureBank has reorganized their application teams to specialize more and provide shared services to other applications. A `db` team was created just to manage the databases that other applications will utilize. Additionally, SecureBank recently read a book about DevOps. They have decided that developers should have the capability to deploy and manage the lifecycle of their own applications, effectively merging developer and operations teams.
+
+- `security` should have visibility-only access across all applications in the cluster.
+- `db` should have the full set of capabilities against all database applications and their respective resources.
+- `payments` should have the full set of capabilities to deploy Payments apps and also access some of the shared services provided by the `db` team.
+- `mobile` has the same rights as the `payments` team, with respect to the Mobile applications.
+
+## Role Composition
+
+SecureBank will use the same roles as in the Introductory Tutorial, but will replace the `dev` role with a new role called `View & Use Networks + Secrets`. This type of role will enable application DevOps teams to use shared resources provided by other teams. It will enable applications to connect to networks and use secrets that will also be used by `db` containers, but not the ability to see or impact the `db` applications themselves.
+
+![image](../../../images/design-access-control-adv-0.png){: .with-border}
+
+
+## Collection Architecture
+
+The previous tutorial introduced a tier of collections specific to the types of applications being deployed by SecureBank.
+
+- `/Shared/payments` hosts all applications and resources for the Payments applications.
+- `/Shared/mobile` hosts all applications and resources for the Mobile applications.
+
+Some new collections will be created to enable the shared `db` applications.
+
+- `/Shared/db` will be a top-level collection for all `db` resources.
+- `/Shared/db/payments` will be specifically for `db` resources providing service to the Payments applications.
+- `/Shared/db/mobile` will do the same for the Mobile applications.
+
+The following grant composition will show that this collection architecture allows an app team to access shared `db` resources without providing access to _all_ `db` resources. At the same time _all_ `db` resources will be managed by a single `db` team.
+
+## LDAP/AD Integration
+
+SecureBank has standardized on LDAP for centralized authentication to help their identity team scale across all the platforms they manage. As a result LDAP groups will be mapped directly to UCP teams using UCP's native LDAP/AD integration. As a result users can be added to or removed from UCP teams via LDAP which can be managed centrally by SecureBank's identity team. The following grant composition shows how LDAP groups are mapped to UCP teams .
+
+## Grant Composition
+
+The Introductory Tutorial used a design with a 1:1 ratio between grants and teams. That is a valid design but eams can also support multiple grants per team which allows for more complex access scenarios. SecureBank will apply two grants for each application team, allowing each team to fully manage their own apps in their collection, but also have limited access against networks and secrets within the `db` collection.
+
+![image](../../../images/design-access-control-adv-1.png){: .with-border}
+
+
+## SecureBank Access Architecture
+
+The resulting access architecture shows applications connecting across collection boundaries. Multiple grants per team allow Mobile applications and Databases to connect to the same networks and use the same secrets so they can securely connect with each other but through a secure and controlled interface. Note that these resources are still deployed across the same group of UCP worker nodes. Node segmentation is discussed in the [next tutorial](#).
+
+![image](../../../images/design-access-control-adv-2.png){: .with-border}
+
+
+### DB Team
+
+The `db` team is responsible for deploying and managing the full lifecycle of the databases used by the application teams. They have the full set of capabilities against all database resources. 
+
+![image](../../../images/design-access-control-adv-3.png){: .with-border}
+
+
+
+### Mobile Team
+
+The `mobile` team is responsible for deploying their own application stack, minus the database tier which is managed by the `db` team. 
+
+![image](../../../images/design-access-control-adv-4.png){: .with-border}
+
+

datacenter/ucp/2.2/guides/admin/manage-users/access-control/design-access-control-ee-standard.md

@@ -0,0 +1,77 @@
+---
+title: Design access control in Docker EE Standard
+description: Learn how to architect multitenancy by using Docker Enterprise Edition Standard.
+keywords: authorize, authentication, users, teams, groups, sync, UCP, role, access control
+---
+
+[Collections and grants](../manage-users/) are strong tools that can be used to control access and visibility to resources in UCP. UCP Access Control is flexible and granular to provide for an access design that fits the architecture and specific needs of diverse organizational structures. Many different structures are possible with the flexibility of UCP and the examples in these tutorials show just a few possible scenarios.
+
+This example shows a very simple access structure to clearly explain the basics of UCP Access Control at a fictional company named SecureBank.
+
+## Team Access Requirements
+
+Company SecureBank deploys their production applications on a UCP cluster. They have four teams that interact with containerized applications along their production lifecycle. 
+
+- `ops` is responsible for deploying and managing all of the operations of all container applications. This is the only team with the capability to deploy applications in the production UCP cluster.
+- `security` conducts security audits for production applications. They must have visibility across all production container resources in the UCP cluster.
+- `payments` is a team of developers responsible for payments applications. At SecureBank developers do not deploy applications in to production, however developers can get access directly to the container only to do operations or troubleshooting. This team should only have visibility to their own applications.
+- `mobile` has the same rights as the `payments` team, but should only be able to have access to only their own applications.
+
+## Role Composition
+
+UCP provides some [default roles](../manage-users/permission-levels/#roles) but custom roles can also be created to cater to very specific combinations of capabilities. SecureBank will create custom roles so they can get provide more customized access to resources. SecureBank will have three types of custom roles that will map to the types of actual roles they have in their organization.
+
+- `Ops` can do any action against any type of resource in the cluster including creating, viewing, and destroying resources.
+- `View Only` can view but not edit any type of resource in the cluster.
+- `Dev` can only see services and containers and `exec` into the containers to interact with the processes inside the containers that they have access to.
+
+![image](../../../images/design-access-control-0.png){: .with-border}
+
+## Collection Architecture
+
+UCP provides [default collections](../manage-users/manage-access-with-collections/#control-access-to-nodes) to enforce broad access rights such as separation between infrastructure (UCP & DTR) nodes and application (worker) nodes. More granular segmentation of users is up to the administrator to design using collections to best fit the organizational structure that they need. 
+
+In addition the the default collections, SecureBank will create two more collections to map to specific application teams in their org.
+
+- `/Shared` is the default Shared collection that all non-Infra, application hosting nodes will belong to.
+- `/Shared/payments` is created to host all resources related to the Payments applications.
+- `/Shared/mobile` is created to host all resources related to the Mobile applications.
+
+## Grant Composition
+
+[Grants](../manage-users/grant-permissions/) are the specific rules that govern who has access to which resources. SecureBank will tie together their teams, custom roles, and collections to create a set of grants. The following images shows the four grants that are created that will enforce the access requirements of SecureBank.
+
+![image](../../../images/design-access-control-1.png){: .with-border}
+
+## SecureBank Access Architecture
+
+The image below shows the access architecture as a result of the UCP Grants. Docker infrastructure nodes that host UCP and DTR are in a `/System` collection that no non-admin UCP users have access to. The remaining UCP worker nodes are by default in the top-level `/Shared` collection and will be shared across all applications. 
+
+![image](../../../images/design-access-control-2.png){: .with-border}
+
+### Ops Team
+
+The `ops` team can execute any capability against resources in the `/Shared` collection. This gives `ops` members the ability to schedule containers on UCP workers, create networks & volumes, and more. The `ops` team has no access against anything in the `/System` collection. When deploying Mobile and Payments applications, `ops` members will select either `/Shared/payments` or `/Shared/mobile` to deploy applications in to.
+
+![image](../../../images/design-access-control-3.png){: .with-border}
+
+### Security Team
+
+The `security` team can view all resources in the `/Shared` collection. This gives visibility to all resources used by the Mobile and Payments applications. 
+
+![image](../../../images/design-access-control-4.png){: .with-border}
+
+
+### Payments Team
+
+All Mobile applications and their respective resources will be scheduled in the `/Shared/payments` collection. The `payments` team will have visibility to the containers and services in this collection as well as the ability to `exec` in to the container.
+
+![image](../../../images/design-access-control-4.png){: .with-border}
+
+
+### Mobile Team
+
+The `mobile` team and Mobile applications will also have their own collection, `/Shared/mobile`.
+
+![image](../../../images/design-access-control-5.png){: .with-border}
+