As digital transformation programs continue to be a firm priority for many CEOs, organizations are increasingly adopting cloud-native architectures to expand their DevOps practices and build developer platforms that drive innovation. However, these rapid development cycles are putting pressure on enterprise security, as developer-led processes are not always aligned with IT security policies and practices.

The new culture of making developer teams go faster is exposing the platform infrastructure to new types of security vulnerabilities. In fact, according to a recent survey, 52% of companies admitted to cutting back on security measures to meet a business objective, potentially leaving platforms vulnerable to exploitation and cybercrime. In a world where automation thrives, enforcing security policies to run alongside ever faster deployment cycles is a complex challenge.

Adding to the security challenge is the growing popularity of Kubernetes as a container-orchestration system and the need to build-in developer policies or “guardrails” that establish best practices for developers without slowing them down. Offering flexibility and a declarative code-based experience, Kubernetes has fast become the number one platform of choice among developers for cloud-hosted applications. A 2021 survey by the Cloud Native Computing Foundation found that a staggering 96% of respondents said they are using or are evaluating Kubernetes.

However, as an open-source technology, Kubernetes is ever-evolving and improving the speed for developers, so security teams must recommend integrated security tooling solutions that can be readily adopted by developer teams and meet their need for automation.

Increased operational risk

When using Kubernetes, an important remit of container security is to configure and manage machine identities to ensure all workloads are deployed to a cluster with an X.509 digital certificate. Every time a developer spins a microservice, container, or virtual machine up to production, they must assign a digital certificate identity and manage that identity throughout its lifecycle. The rise in cloud-native computing has resulted in an explosion of these machine identities—too many to manage manually.

Machine identity management solutions can give developers the means to automate the issuance and renewal of high volumes of certificates. But without security policies and tooling to know the configuration status of all these certificates, companies risk allowing vulnerabilities to manifest which exposes their platform systems to attack.

To address this problem, companies are looking for ways of bringing the security and development teams closer together using new DevSecOps practices. However, this need to marry the skillsets of DevOps and security is not yet delivering the levels of protection organizations need. While 85% of companies say that employing SecOps best practices is an important goal for them, only 35% say that SecOps is an established practice in their organizations. As a result, we’re seeing large-scale attacks from cybercrime gangs such as TeamTNT, which is becoming known for targeting misconfigured Kubernetes clusters and spreading malware.

To help drive DevSecOps success, we’ve identified four principles that can make processes easier to follow:

1. Monitoring. As digital transformation accelerates, so does the number of machine identities, or X.509 certificates. However, as many organizations are finding out the hard way, it’s impossible to manage large volumes of X.509 certificates manually without creating security holes. To reinforce a zero-trust approach, use automated tools to issue, manage and monitor machine identities inside clusters. Automating X.509 certificates and removing manually signed certificates can significantly reduce security incidents from cloud-native workloads. Automation also ensures organizations can keep up with the speed of modern development and the scale of multi-cloud environments.
2. Consistency. A common mistake among organizations when managing machine identities is being inconsistent. Using different tools and methods across developer teams when creating workloads can lead to security gaps and blind spots, and create toil for the site reliability engineers when outages occur. By clearly defining and communicating straightforward execution processes, developer teams can ensure the way in which they initiate machine identity security is the same for every workload deployed into production. This delivers more consistency and traceability for each new cluster spun up into production.
3. Identification. With teams deploying multiple containers every minute, maintaining visibility at a workload level across a company’s infrastructure becomes challenging. Issues can result from misconfigurations in containers or the underlying Kubernetes infrastructure. By introducing security tooling that works with automation, teams can scan containers at every phase to identify their single most common vulnerability and create a policy “on the fly” to eliminate it. However, make sure processes are in place to enforce the policy to avoid the vulnerability from reappearing when developers introduce new clusters. Automation tools can help by checking configurations against all security policies.
4. Isolation. Create an extra layer of security by isolating applications. Isolation reduces the blast radius of a security breach by ensuring that a compromised application is less likely to affect other areas of an organization’s infrastructure or network. It also helps limit the risk of harm to a system when releasing new applications or functionality. For optimal security, introduce container runtime scanning. Once a container is in production, put suitable mechanisms in place to ensure the container remains secure. Automated scanning tools can continuously check for and detect new common vulnerabilities and exposures and report them to the appropriate team to resolve.

Focus on the Developer Experience

Considering the substantial financial and reputational costs of a cyberattack, security must be a concern for everyone working along the development pipeline. Zero Trust principles are becoming a very acceptable way for security teams to apply policies and best practices. Nevertheless, many development teams still see security as a chore that can prevent them from deploying at speed.

Developer teams instead want to rely on DevSecOps approaches which recommend security tools and practices that work with automation and fit with current developer processes, allowing them to innovate at speed, improve productivity, and be confident their code is secure.

By combining the advantages of developer speed with improved security practices, DevSecOps is increasingly focused on the overall Developer Experience to achieve its goals of high levels of automation and security. Improving the Developer Experience is based on ensuring high levels of security and consistency.

We all need to do everything we can to avoid further damaging attacks. However, as Kubernetes accelerates, new recommendations for security tooling must be made by having a DevEx mindset, and this is the crux that modern DevSecOps can use for improved cloud-native security.

Article written By Steve Judd, Solutions Architect at Jetstack