Cultural Considerations of Adopting Application Container Technology

The benefits of application containers have been shared across a variety of forums and to a diverse audience. The ability to have more application instances without a corresponding increase in hardware is probably the primary benefit that is used to persuade enterprises to adopt application containers. But if that is the primary benefit, meeting the objectives of the rapid deployment associated with DevOps is a close second.

Application containers allow developers to easily modify and test because applications are siloed in their own containers. So, the benefits are appealing from a cost savings perspective as well as support of DevOps deployment. Is there a downside, though?

Perhaps it is not a downside as much as a consideration, but as organizations adopt application containerization, some cultural shifts are necessary. These shifts relate to operational processes that organizations may already have in place; however, containerization requires doing those familiar processes differently. Because the change is for an existing process rather than the implementation of something new, the change is more cultural than operational. For example, in a traditional application environment, generally, there is a structured process for code review, which the time to deployment accommodates. As deployment time is shortened (as in a scenario involving DevOps and application containers), organizations may be challenged in how they perform formal, structured code reviews. So, a cultural shift to identify (and accept) solutions that provide assurance around secure coding in the containerized environment despite the rapid speed of deployment may be required.

Another area where a cultural shift may be required relates to access. Unless an organization develops a strategy around administrator access, it is possible for administrators to have access to multiple hosts, containers and images rather than the specific hosts, containers and images to which the administrator needs access to perform job responsibilities. Ensuring that a least privilege strategy is implemented would addresses this. Also, beyond internal expectations, several compliance initiatives, such as the Health Insurance Portability Accountability Act (HIPAA), the Payment Card Industry Data Security Standard (PCI DSS) and the General Data Protection Regulation (GDPR) rely on strong access controls.

Lastly, an organization’s approach to authentication may require a cultural shift. In administering workloads, orchestrators potentially place workloads that have varying levels of sensitivity on the same host. To address this, an orchestrator may have its own authentication directory. This directory, however, may be separate from other non-orchestrator authentication directories in use. As a result, the orchestrator’s authentication directory may have different authentication practices. A concerted effort to ensure alignment of authentication practices for all directories (orchestrator-related or not) may be necessary. These efforts may include, but are not limited to, restricting administrator authentication access to specific repositories rather than multiple repositories.

The benefits of adopting application containers are appealing. More application instances may be possible without incurring the cost of additional hardware and deployment time may be reduced. Effective adoption, however, depends on how organizations can modify existing protocols to accommodate the containerized environment. Code review, access and authentication are examples of areas for which organizations routinely have controls but where a cultural shift is necessary. Once these shifts have been made, the benefits or application containers can be fully realized.

Robin Lyons, Technical Research Manager, ISACA

[ISACA Now Blog]