Set up access control architecture¶
This tutorial explains how to set up a complete access architecture for a fictitious company called OrcaBank.
OrcaBank is reorganizing their application teams by product with each team providing shared services as necessary. Developers at OrcaBank perform their own DevOps and deploy and manage the lifecycle of their applications.
OrcaBank has four teams with the following resource needs:
Security needs view-only access to all applications in the cluster.
DB (database) needs full access to all database applications and resources.
Mobile needs full access to their mobile applications and limited access to shared DB services.
Payments needs full access to their payments applications and limited access to shared DB services.
OrcaBank is taking advantage of the flexibility in the MKE grant model by applying two grants to each application team. One grant allows each team to fully manage the apps in their own collection, and the second grant gives them the (limited) access they need to networks and secrets within the db collection.
The resulting access architecture has applications connecting across collection boundaries. By assigning multiple grants per team, the Mobile and Payments applications teams can connect to dedicated database resources through a secure and controlled interface, leveraging database networks and secrets.
MKE deploys all resources across the same group of worker nodes while providing the option to segment nodes.
To set up a complete access control architecture:
Set up LDAP/AD integration and create the required teams.
OrcaBank will standardize on LDAP for centralized authentication to help their identity team scale across all the platforms they manage.
To implement LDAP authentication in MKE, OrcaBank is using the MKE native LDAP/AD integration to map LDAP groups directly to MKE teams. You can add or remove users from MKE teams via LDAP, which the OrcaBank identity team will centrally manage.
Define the required roles:
Opsrole that allows users to perform all operations against configs, containers, images, networks, nodes, secrets, services, and volumes.
View & Use Networks + Secretsrole that enables users to view and connect to networks and view and use secrets used by DB containers, but that prevents them from seeing or impacting the DB applications themselves.
You will also use the built-in
View Onlyrole that allows users to see all resources, but not edit or use them.
Create the required Swarm collections.
All OrcaBank applications share the same physical resources, so all nodes and applications are configured in collections that nest under the built-in Shared collection.
Create the following collections:
/Shared/mobileto host all mobile applications and resources.
/Shared/paymentsto host all payments applications and resources.
/Shared/dbto serve as a top-level collection for all db resources.
/Shared/db/mobileto hold db resources for mobile applications.
/Shared/db/paymentsto hold db resources for payments applications.
The OrcaBank grant composition will ensure that the Swarm collection architecture gives the DB team access to all db resources and restricts app teams to shared db resources.
Create the required grants:
For the Security team, create grants to access the following collections with the View Only built-in role: /Shared/mobile, /Shared/payments, /Shared/db, /Shared/db/mobile, and /Shared/db/payments.
For the DB team, create grants to access the /Shared/db, /Shared/db/mobile, and /Shared/db/payments collections with the Ops custom role.
For the Mobile team, create a grant to access the /Shared/mobile collection with the Ops custom role.
For the Mobile team, create a grant to access the /Shared/db/mobile collection with the View & Use Networks + Secrets custom role.
For the Payments team, create a grant to access the /Shared/payments collection with the Ops custom role.
For the Payments team, create a grant to access the /Shared/db/payments collection with the View & Use Networks + Secrets custom role.