Are access controls necessary for containerized applications? And where does access control fit in with continuous delivery and fully automated continuous delivery pipelines?

In this post, I will answer these questions and describe Nirmata’s approach to managing access controls for application containers.

Are access controls still necessary?

Access Control is used to restrict use of critical resources. In addition to securing critical resources, access control helps prevent accidental changes to always-on environments.

Application containers help enable continuous delivery (learn how). With containers, developers are empowered with packaging their application components, and describing how the application containers get deployed across container hosts. Container-native application management solutions, like Nirmata, can then automate the deployment and operation of these containers across every phase of your continuous delivery pipeline DevOps.

In this brave new world, is access control still necessary? The simple answer is, “Yes, it is!”. However, the access controls needed are quite different than traditional ways of managing access control. Let’s discuss why.

How are they different with containers?

Traditional DevOps tools, built before application containers, will provide role-based access controls (RBAC) and ways to manage permissions and privileges.

But most of these systems treat application environments as physical, static, and long-lived resources. With containers, application environments are now fast to provision and developers will create and manage environments differently. More importantly, with the right tooling it’s now possible to share a cluster of container hosts for multiple isolated environments of the same or different types.

Hence, for proper access controls it’s now necessary to start categorizing environments in a more granular fashion, based on the intended usage, and to manage deployment and access policies based on the specific type of environment.

What does Nirmata provide for access controls?

Nirmata has a built-in RBAC with three roles:

• Admin users have full access to the account and can also manage other users and their access.
• Platform users can manage all resources and policies, but cannot manage users.
• DevOps users can only manage Applications and Environments. They do not have access to Cloud Providers, Host Groups, and Policy settings, and cannot manage users.

In addition to RBAC, Nirmata has a native concept of an Environment Type which you can use to easily manage your environments. You can create and manage your own environment types to represent the different phases of your deployment pipeline, or any other type of environment you create and manage.

Access Controls can now be defined for an Environment Type. In the example below, the production environment type is set to allow read-write access for all Platform users and read-only access for DevOps users, and read-write access for a user, Max.

What this means is that only selected users can make changes in production environments. However, any developer can commit and push code. So how do access controls impact continuous delivery and automated deployment of code changes?

Another important difference when using containers, is that is crucial to qualify the type of change being made. For example, the impact of updating a container image for a single service may be very different than that of updating a Service Gateway, or a scaling and recovery rule, in a production environment.

Developers now share the application operations responsibility, and hence should be allowed to make necessary changes to their services. The platform or operations team, typically being the first line of support for production systems, should have full visibility into the changes and should be able to manage how these changes are rolled out. With container-native continuous delivery systems, like Nirmata, this entire process can be fast and fully-automated!

Nirmata’s access controls are designed to work seamlessly with a built-in continuous delivery pipeline feature, where container images can be promoted across environments.  You can define an Update Policy for each environment type that controls which changes are allowed in an environment, as well as how the changes should be handled for the environment. For example, you can allow all changes with automated rolling upgrades in dev-test environments, but restrict production environments to QA validated changes and supervised updates.

When a new environment is created, it inherits the access controls and update policies from the Environment Type. You can then further customize the settings as needed.

Summary

With traditional systems, access controls has focused on limiting changes. Now, for modern applications it’s about facilitating changes – with the right safeguards in place for critical resources, and the right separation of concerns!

If you are interested in learning more, you can explore Nirmata for free here.  

Containerizing applications? Get our free eBook!