Set up access control architecture with additional security requirements

Caution

Complete the Set up access control architecture tutorial before you attempt this advanced tutorial.

In the previous tutorial, you assigned multiple grants to resources across collection boundaries on a single platform. In this tutorial, you will implement the following stricter security requirements for the fictitious company, OrcaBank:

  • OrcaBank is adding a staging zone to their deployment model, deploying applications first from development, then from staging, and finally from production.

  • OrcaBank will no longer permit production applications to share any physical infrastructure with non-production infrastructure. They will use node access control to segment application scheduling and access.

    Note

    Node access control is an MKE feature that provides secure multi-tenancy with node-based isolation. Use it to place nodes in different collections so that you can schedule and isolate resources on disparate physical or virtual hardware. For more information, refer to Isolate nodes.

OrcaBank will still use its three application teams from the previous tutorial (DB, Mobile, and Payments) but with varying levels of segmentation between them. The new access architecture will organize the MKE cluster into staging and production collections with separate security zones on separate physical infrastructure.

The four OrcaBank teams now have the following production and staging needs:

  • Security` needs view-only access to all applications in production and no access to staging.

  • DB needs full access to all database applications and resources in production and no access to staging.

  • In both production and staging, Mobile needs full access to their applications and limited access to shared DB services.

  • In both production and staging, Payments needs full access to their applications and limited access to shared DB services.

The resulting access architecture will provide physical segmentation between production and staging using node access control.

Applications are scheduled only on MKE worker nodes in the dedicated application collection. Applications use shared resources across collection boundaries to access the databases in the /prod/db collection.


To set up a complete access control architecture with additional security requirements:

  1. Verify LDAP, teams, and roles are set up properly:

    1. Verify LDAP is enabled and syncing. If it is not, configure that now.

    2. Verify the following teams are present in your organization: Security, DB, Mobile, and Payment, and if they are not, create them.

    3. Verify that there is a View & Use Networks + Secrets role. If there is not, define a View & Use Networks + Secrets role that enables users to view and connect to networks and view and use secrets used by DB containers. Configure the role so that it prevents those who use it from seeing or impacting the DB applications themselves.

    Note

    You will also use the following built-in roles:

    • View Only allows users to see but not edit all cluster resources.

    • Full Control allows users complete control of all collections granted to them. They can also create containers without restriction but cannot see the containers of other users. This role will replace the custom Ops role from the previous tutorial.

  2. Create the required Swarm collections.

    In the previous tutorial, OrcaBank created separate collections for each application team and nested them all under /Shared.

    To meet their new security requirements for production, OrcaBank will add top-level prod and staging collections with mobile and payments application collections nested underneath. The prod collection (but not the staging collection) will also include a db collection with a second set of mobile and payments collections nested underneath.

    OrcaBank will also segment their nodes such that the production and staging zones will have dedicated nodes, and in production each application will be on a dedicated node.

    Create the following collections:

    • /prod

    • /prod/mobile

    • /prod/payments

    • /prod/db

    • /prod/db/mobile

    • /prod/db/payments

    • /staging

    • /staging/mobile

    • /staging/payments

  3. Create the required grants as described in Create grants:

    1. For the Security team, create grants to access the following collections with the View Only built-in role: /prod, /prod/mobile, /prod/payments, /prod/db, /prod/db/mobile, and /prod/db/payments.

    2. For the DB team, create grants to access the following collections with the Full Control built-in role: /prod/db, /prod/db/mobile, and /prod/db/payments.

    3. For the Mobile team, create grants to access the /prod/mobile and /staging/mobile collections with the Full Control built-in role.

    4. For the Mobile team, create a grant to access the /prod/db/mobile collection with the View & Use Networks + Secrets custom role.

    5. For the Payments team, create grants to access the /prod/payments and /staging/payments collections with the Full Control built-in role.

    6. For the Payments team, create a grant to access the /prod/db/payments collection with the View & Use Networks + Secrets custom role.