How do you build a secure 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 difficult to implement a security-centric culture. Security sometimes appears to be in conflict with other common goals of the delivery chain, such as velocity and agility. IT organizations often place disproportionate emphasis on getting code out the door as quickly and continuously as possible. Ignoring security-related roadblocks may occur in the interest of scaling. This can lead to 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 is, that you take practical steps to encourage a culture of security within your organization. The following are some examples of steps you might take, and can be applied to building and maintaining a secure Kubernetes environment.
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.
Sponsor internal security-themed hackathons. Invite everyone to find ways to improve security at different layers of your solution stack. This can raise awareness and get your team excited about security.
The idea here is not to use hackathons to replace regular security audits. (You should still be doing those!) Rather, use them to give everyone a chance to participate in exercises designed to make your delivery chain and environment more secure; even engineers who don’t normally focus on security.
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.
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
Strategies like those described above can help to build a security culture. But, 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. Kubernetes provides visibility into application deployments and can 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. Take advantage of the security tools and resources available to you. Build a culture of security among your team. Encourage all team members to prioritize security. Give them the tools and processes they need to act on that priority.