--- title: "Five Tips for Successful Kubernetes Network Security and Compliance" source: "https://www.tigera.io/blog/five-tips-for-kubernetes-network-security-and-compliance/" --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # Five Tips for Successful Kubernetes Network Security and Compliance By [Vince Lau](https://www.tigera.io/blog/author/vincetigera-io/) on Oct 08, 2018 • 4 min read Kubernetes is dynamic and hard to secure or monitor using existing tools. This has a significant impact on your security and compliance controls. - Traditional solutions like perimeter security, zone-based security, and static firewalls are not sufficiently scalable or flexible enough to meet security controls for Kubernetes. - Monitoring tools do not provide context into microservices traffic. - Compliance tools designed to provide audit trails were also designed for static applications and environments and won’t work properly for Kubernetes. - Since microservices use the network, several teams – development, platform, networking, security – now need access to security tools that let them work together in an agile manner. Kubernetes changes the way that we implement security controls. Here are some best practices for securing those environments. ## **1. Deploy what you know** Not knowing what is inside containers could be problematic, especially if it has vulnerable code. Downloaded container images could contain vulnerable code, making run-time containers exploitable by attackers. Therefore, it is crucial to practice good security hygiene and understand what exactly is being deployed. Container scanning can help you to an extent, screening out containers with known major CVEs. Assuming that your code does what you want it to do, you want to make sure that no one can change it in a way that you don’t know about. Use source code control systems like Git. ## **2. Ensure deployments are in compliance** Since IP addresses are ephemeral in a Kubernetes environment, we need to use other attributes to identify and audit workloads. This might include metadata and labels that identify infrastructure that must align to your compliance controls. When you use labels or fingerprints as an identity, you can begin attaching the security controls you need for compliance. The next step is to write policies that interact with your labels. If an element in your architecture is labeled for PCI, then it doesn’t matter what specific kind of element it is. Your PCI-related policies should apply automatically, no matter what. Lastly, you need to enforce the concrete nature of your policies. Developers and other personnel should not be able to change your policies – only the security and/or compliance team can. If someone tries to change those policies, the security and/or compliance team should receive an alert. ## **3. Make sure logs are meaningful and durable** You may have thousands or even tens of thousands of servers, each with hundreds of workloads. You need a solution that can correlate all of these workloads, so you can detect what’s really happening in your platform. As one example, your containers need to have a consistent sense of time. Without a sense of time, your logs won’t be in a sequential order, so you can’t determine cause or effect. ## **4. Embrace Zero Trust network security** As we’ve mentioned, you need to assume that you have one or more compromises in your network. Acting accordingly means implementing multiple enforcement points in and outside of your pod and hosts. If a single enforcement point gets compromised, the infection won’t be able to compromise your security posture. By implementing multiple, interlocking, and partially redundant security controls at every level of your stack, you eliminate the possibility that a single compromise can own your entire system. ## **5. Orchestrate security just like you orchestrate code** Your orchestrator is in charge of the rest of your environment, so it should be in charge of security. Doing anything else will create an impedance between your policies and your security. Where the workload goes, the policy should follow. Creating new microservices security models means adding more complexity to what are already very complex environments. Do it right, however, and you’ll be able to create a security model that’s even more secure than the model it’s replacing. ————————————————- [**Free Online Training**](https://www.tigera.io/events/) Access Live and On-Demand Kubernetes Tutorials [**Calico Enterprise – Free Trial**](https://www.calicocloud.io/home) Solve Common Kubernetes Roadblocks and Advance Your Enterprise Adoption [Best Practices](https://www.tigera.io/tags/best-practices/)[Open Source](https://www.tigera.io/tags/open-source/) ## Related posts [![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) #### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 27, 2026 Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a... [Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/) [![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) #### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/) on Aug 24, 2026 The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms... [Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/) [![VM Migration – What Happens to Your NSX Segments in Kubernetes?](https://www.tigera.io/app/uploads/2026/08/VM-Migration-What-Happens-to-Your-NSX-Segments-in-Kubernetes.png)](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/) #### [VM Migration – What Happens to Your NSX Segments in Kubernetes?](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on Aug 5, 2026 Planning a migration off NSX usually starts with a networking conversation. Segments, VLANs, routing topology and BGP peering are not things that map cleanly to Kubernetes-native constructs the way the NSX distributed firewall maps to... [Read more](https://www.tigera.io/blog/vm-migration-what-happens-to-your-nsx-segments-in-kubernetes/)