Role-Based Access and Containers as a Service

Containers as a Service (CaaS) is a new term that has arisen over the last several months. It strikes a nice middle ground between Infrastructure as a Service and Platform as a Service when deploying applications infrastructure. Infrastructure as a Service requires managing individual segments of infrastructure and entire low-level configurations in one or a number of Infrastructure as a Service providers. With Platform as a Service, alternatively, the application stack is dictated and the individual configuration and deployment capabilities are relatively fixed. With Containers as a Service, you are able to create more differentiation between application stacks and deployment methods than is possible with Platform as a Service, without the more significant training and resource requirements associated with Infrastructure as a Service.

Containers as a Service resolves the disconnect between developers deploying in production and operations teams needing to run those applications in production. By packaging applications in containers, you are able to maintain version control and configuration management required to deploy those applications stacks. Specific thought should be given to how apps and services are deployed across a highly scalable and resilient containerized architecture. Tightly coupled services should be grouped together, and stacks should be composed to link those individual services into logical groupings that can be deployed.

Role-Based Access Control

Role-Based Access Control (RBAC) is a method of managing specific permissions on accounts. These specific permissions can provide a highly refined access set, mapped specifically to the roles and responsibilities of a specific individual or group. On one side, these individuals are placed into groups in a logical fashion. On the other side, permissions are placed into roles that are commonly needed within the organization. Combining these two methods, groups can be placed into roles that map specifically and explicitly to the needs of the individual. This also allows for more easily configured provisioning and deprovisioning of individuals when they enter and leave an organization. Individual assignment to groups can also be accomplished through attribute assignment.

In the Containers as a Service context, these roles can then be applied to permit individuals to rapidly deploy applications with little risk to existing infrastructure. Different groups of individuals can be provided with permission to deploy into test, development, or production environments. By codifying and explicitly describing permission, integrations can occur more quickly, and delivery and deployment can occur in a more consistent way. Permissions provided with forethought allow for both greater control and greater agility for the operations team managing the production infrastructure.

In a more centralized and highly regulated organization, such controls can be put in place to ensure compliance where necessary. For example, for Sarbanes-Oxley (SOX) compliance, “regulators may need to know who used a system, when they logged in and out, what accesses or modifications were made to what files, and what authorizations were in effect.”1 These schemes typically require significant logging for changes to the environment. In a highly regulated environment, these opportunities also create a manageable way for providing lowest required access. In a decentralized environment, Role-Based Access Control provides greater agility while preventing significant divergence from a shared standard of deployment.

The most glaring and common downside of strict Role-Based Access Control is significantly restricted agility for decentralized organizations. If the application of this control is too strict, not only can progress be significantly slowed, but the ability of these divisions to independently explore their own solutions to unique problems is severely limited.

Balancing Containers as a Service and RBAC

One of the primary issues that virtualization originally attempted to solve was decoupling the hardware from the runtime environment. This primarily benefited the operations teams when running the application, providing greater resiliency. While the dream was not fully realized in many organizations with self-service virtualization, Containers as a Service have the potential to solve this for application deployments, which can also act as one of their primary selling points when introducing them into an environment, with the ability to generate quick wins, and in the long-term impact application deployment patterns. The balance is that if controls are too strictly placed onto the delegate organizations, it will increase time to deployment and decrease overall realized productivity.

This balance can be struck in a number of ways:

• Regular review of permissions and role mappings, especially when groups are nested together, is very important. This is increasingly a pain point in a default-closed environment, as Container as a Service capabilities expand on a rapid and regular cadence.
• Strict controls around highly critical lines of business applications have the ability to be significantly more restrictive than for other applications. This differentiation allows for flexibility and risk tolerance to be built upon and aligned with organizational expectations.
• As is the case with Containers as a Service, and virtualization before it, multi-level, nested role groups increase abstraction of permissions from roles to provide greater flexibility when assigning these roles.
• It is quite possible (and likely necessary) to nest multiple user groups together, then nest the top-level nested group into the lowest level role group. Another complementary approach is to permit multiple roles to be assigned to other user groups and individual users. Care has to be taken to avoid being overly granular to the point of unmanageability, but this allows the closest mapping to permissions and individuals. This can take the form of both functionally driven and organizational/hierarchical user groups.
• Draw a distinction between visibility (which is important to nearly everyone in the organization) and the ability to take action.
• A further differentiation can be defined for exceptions to the workflow or out-of-band needs.

The drive should be to create a workflow that accommodates nearly every case, significantly driving down one-off or special requests. If the environment generates a significant number of out-of-band process requirements, it will likely be less effective at driving original and useful developments that can be rapidly deployed through the standard workflow.

Ultimately, permission should be granted to foster agility within an organization while also providing sufficient controls to prevent unauthorized actors from causing disruptions. With Containers as a Service, we also have the opportunity to create an architecture that is increasingly resilient to accidental disruption. Pairing together Containers as a Service and having a strong framework for leveraging Role-Based Access Control will contribute to greater levels of control and transparency for the organization, as well as more rapid deployment of technologies that ultimately serve the end customer.

Editor’s Note: Role-Based Access and Containers as a Service is published by the Sumo Logic DevOps Community. If you’d like to learn more or contribute, visit devops.sumologic.com. Also, be sure to check out the Sumo Logic Open Source page for free tools, API’s and example code that will enable you to monitor and troubleshoot applications from code to production.

Resources

• Sarbanes Oxley
• NIST RBAC
• Docker Blog on CaaS