Building a Security-Centric Culture for Kube-Native Environments


How do you secure a Kubernetes environment? Ask most engineers that question, and their first thoughts will turn to tools and processes.

But tools and processes are only half of the battle. Ultimately, building and maintaining a secure Kubernetes environment requires instating a security-minded culture across your IT organization.

What constitutes a security-minded culture, and what are some practical steps for achieving one? Keep reading for tips.

The culture of security

Just as DevOps ultimately boils down to culture rather than specific tools, effective IT security also rests upon a culture that prioritizes security across application environments as well as all stages of the delivery chain.

That might seem obvious, and it’s easy to think that you have a security-conscious culture within your organization. But making security a priority in principle is different from placing security front-and-center in practice.

Indeed, it’s especially hard to implement a security-centric culture because security can sometimes appear to be in conflict with other common goals of the delivery chain, such as velocity and agility. If your IT organization places too much emphasis on getting code out the door as quickly and continuously as possible, or being able to scale unfettered by security-related roadblocks, you will end up with a culture that inherently de-prioritizes security in practice, no matter what amount of lip service you give to security.

Building a security culture

Fortunately, you don’t have to choose between goals like velocity and agility on the one hand, and security on the other. You can have your cake and eat it too, provided that you take practical steps to encourage a culture of security within your organization. The following are some examples of steps you might take.

Link quality to security

Many IT professionals today recognize the importance of software quality. But QA and security are often treated as distinct conversations.

Change that by reminding your team that building and deploying quality software requires building and deploying secure software. Security testing should receive just as much priority within your delivery chain as QA tests. Likewise, writing secure code should be just as much a goal for developers as writing performance-optimized code.


One way to help get your team excited about security is to sponsor internal security-themed hackathons, where everyone is invited to find ways to improve security at different layers of your solution stack.

The idea here is not to use hackathons to replace regular security audits (you should still be doing those!), but rather, to give everyone — even engineers who don’t normally focus on security — a chance to participate in exercises designed to make your delivery chain and environment more secure.

Keep in mind, too, that the hackathon need not focus on finding actual vulnerabilities or serious problems; it is equally effective if the goal is to take code or configurations that are already secure, and then find ways to make them even more secure.

Check-ins and feedback

Along similar lines, ensure that everyone in the IT organization has an opportunity to be heard and contribute feedback related to security. Security engineers should not be the only ones whose opinions or guidance matters. Your IT engineers who are out in the trenches of production environments and your developers who know application backends like no one else also have critical security feedback, and they need a routine way to communicate it to the rest of the team.

Security champions

Whether you have security specialists on staff or not, consider designating other members of the DevOps team as security “champions.” This doesn’t mean making security their primary job focus; instead, it entails recognizing them as team members who are especially adept at assessing security challenges and communicating them to the rest of the team. In this way, you can help build a cultural bridge between security roles and the rest of the team.

Where tools fit into security culture

Although strategies like those described above can help to build a security culture, tools are an inescapable part of the equation too. You need to ensure that your tooling enables a security-centric culture by giving all team members the resources they need to support security.

One way to help do that is to adopt a Kube-native strategy, where Kubernetes serves as a single source of truth across the application environment. In this way, you give all team members a single tool — Kubernetes — that provides visibility into application deployments and can also be used to enforce security best practices (via Kubernetes tools like role-based access control and pod security policies).

It’s also critical to implement processes that bring tools and culture together. For example, your security engineers could provide guidelines regarding how frequently vulnerability-scanning tools should be run and where those tools fit into the delivery chain. Similarly, your team should agree on a process for auditing Kubernetes configuration policies to identify settings that are out of compliance with governance rules.


On their own, no amount of security tools will protect your workloads from vulnerabilities or breaches. In order to take advantage of the security tools and resources available to you, you must build a culture of security that is shared across your team by encouraging all team members to prioritize security, and by giving them the tools and processes they need to act on that priority.

Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure and networking. He is Senior Editor of content and a DevOps Analyst at Fixate IO.


Click on a tab to select how you'd like to leave your comment

Leave a Comment

Your email address will not be published. Required fields are marked *