2022 Gartner® Magic Quadrant™ SIEM
Get the reportMore
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 (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.
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:
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.
Reduce downtime and move from reactive to proactive monitoring.
Build, run, and secure modern applications and cloud infrastructures.Start free trial
Observability has become one of the most important areas of your application and infrastructure landscape, and the market has an abundance of tools available that seem to do what you need. In reality, however, most products – especially leading open-source based products – were created to solve a single problem extremely well, and have added additional supporting functionality to become a more robust solution; but the non-core functionality is rarely best of breed. Examples of these are Prometheus and Grafana.