Traditional security procedures can frequently turn into a barrier when delivering software via DevOps forms at the rate that today’s business world demands. Today, security is not just the responsibility of the security teams—it is a shared responsibility among all the teams in the application lifecycle. This integration is known as DevSecOps. DevSecOps is not about slowing progress or sacrificing agility gained through DevOps. Rather, DevSecOps promotes a collaborative approach to security so that it becomes a central part of the application lifecycle.
At the same time, the modernization of infrastructure and applications is driving the rapid growth of containers and container orchestration platforms as a part of DevOps and consequently, the most popular orchestration platform for running containers in Kubernetes. The Results from the RightScale 2019 State of the Cloud Report show that “All Container use is up, and Kubernetes use is skyrocketing”. The important use of Docker containers continues to grow, with adoption expand to 57 percent from 49 percent in 2018. Thus, Kubernetes is achieving even faster growth, increasing from 27 percent to 48 percent adoption.
Suggested Read: Concepts and terminology of DevSecOps
Companies start to adopt Kubernetes, it’s critical to incorporate DevSecOps best practices, especially because container applications have multiple layers of abstraction. With container technology, you have an orchestration platform, host OS, container runtime, container images, container registry, and the running containers—all of which need to be secured in order to avoid risks like deficient authorization/authentication, bugs, and misconfiguration.
Let’s look at the risk areas of containers and Kubernetes along with the DevSecOps best practices that help mitigate them.
Securing container images
Risks for containing images include clear-text secrets, embedded malware, insecure software or libraries, bugs, outdated/stale images, and the use of untrusted images. There are several ways you can secure images:
- Use an enterprise container security solution like Twistlock, Sysdig Secure, or Aqua, which can scan your images for vulnerabilities and scan can be done in the CI/CD pipeline or on existing containers in a registry.
- Instead of using clear-text secrets in container images better to use Kubernetes Secrets to store secrets or Key Vault.
- Only use images that are verified via your scanning process.
- Container images are characteristically stored in container registries. Use a private trusted container registry that is Azure Container Registry (ACR).
- Digitally sign your container images and set your orchestration platform, e.g., Azure Kubernetes Service (AKS), to only allow validated images.
- Base images are some times updated with new software and security fixes. Every time the base image is updated, use automation to build new container images downstream. The process for image updating can be handled by tools like Jenkins or Azure Pipelines (an Azure DevOps service) in continuous integration and continuous deployment (CI/CD).
Also read: DevSecOps automation
Securing container registries
The second most common security risks in containerization are threats to container registries. These risks include insecure connections to registries, deficient authorization/authentication restrictions, and outdated/stale images. To boost security, you can leverage group isolation through nested namespaces, segmenting image access to specific teams in your organization.
Another isolation technique is to deploy the registry in a dedicated virtual network (VNet). In a dedicated VNet, such as Azure VNet, only users and resources in that VNet can access the registry.
As an example, let’s take a closer look at what Azure Container Registry (ACR) offers. ACR has two authentication methods: individual identity authentication (IIA) and headless/service identity authentication. IIA has an azacr login (via Docker CLI) used by programmers to pull and push registry images. Headless authentication uses a service principle used in CI/CD pipelines. Limit the use of individual identity authentication to a small group of users and follow standard user account best practices.
By granting trusted image push the permission to select users, you can limit who can push images to your container registry. Again, use a DevOps capability such as Azure DevOps to keep container images up to date. And now finally, enable content trust on your container registry so you can enforce using only signed container images.
Authentication and authorization
Authentication and authorization are at the core of securing cloud and DevOps. Authentication is confirming the identity of a user and authorization is the act of verifying and allowing access to resources. Think of these two as AuthN vs AuthZ.
Securing authentication and authorization is important to your container registry and other containerization components like the cluster and CI/CD pipeline. Azure Active Directory (AAD) helps centralize identity and access management to services running in Azure. AAD comes with many features that help with security, including privileged identity management (PIM), multi-factor authentication, service principal accounts, conditional access, and more. AAD extends authentication and access controls with the container registry, the cluster, and even a pipeline in Azure DevOps.
Featured article: DevOps key practices
Policy control for pipelines and cluster
Azure Kubernetes Service also enables you to limit access for not only the resources and people but also the content of the incoming requests. Operators can select from a predefined set of Azure policies and assign them to AKS clusters. This enables the deploy-time enforcement of organizational policies. For example, any resources that are currently deployed to AKS can be checked for compliance with the assigned policies and if found to be non-compliant, the violations are reported so appropriate action can be taken to rectify. Similarly, if a user tries to create resources that are not compliant with policy, his or her requests are denied and the user is presented with a message detailing the policy that caused the denial.
- Microsoft provides AKS cluster monitoring via Azure Monitor for containers. This feature gives you monitoring insights into AKS and containers, cluster and container logs, as well as metric-based cluster and pod performance charts.
- Security Center not only has the ability to show security posture across Azure subscriptions but also can alert you about security that is out of compliance and can assist with remediation of security issues.
- Azure Monitor consists of Log Analytics (infrastructure monitoring) and Application Insights (application performance monitoring). Azure Monitor can assist in the overall visibility and storage of security assessments and issues in Azure subscriptions, as well as advanced alerting and notification when security issues do arise.