Cloud native security for your clusters

Author:

Over the last few years a small, security focused community has been working diligently to deepen our understanding of security, given the evolving cloud native infrastructure and corresponding iterative deployment practices. To enable sharing of this knowledge with the rest of the community, members of

The paper attempts to not focus on any specific .

Kubernetes native security controls

When using Kubernetes as a workload orchestrator, some of the security controls this version of the whitepaper recommends are:

• Pod Security Policies: Implement a single source of truth for “least privilege” workloads across the entire cluster
• Resource requests and limits: Apply requests (soft constraint) and limits (hard constraint) for shared resources such as memory and CPU
• Audit log analysis: Enable Kubernetes API auditing and filtering for security relevant events
• Control plane authentication and certificate root of trust: Enable mutual TLS authentication with a trusted CA for communication within the cluster
• Secrets management: Integrate with a built-in or external secrets store

Cloud native complementary security controls

Kubernetes has direct involvement in the deploy phase and to a lesser extent in the runtime phase. Ensuring the artifacts are securely developed and distributed is necessary for, enabling workloads in Kubernetes to run “secure by default”. Throughout all phases of the Cloud native application life cycle, several complementary security controls exist for Kubernetes orchestrated workloads, which includes but are not limited to:

• Develop:
  • Image signing and verification
  • Image vulnerability scanners
• Distribute:
  • Pre-deployment checks for detecting excessive privileges
  • Enabling observability and logging
• Deploy:
  • Using a service mesh for workload authentication and authorization
  • Enforcing “default deny” network policies for inter-workload communication via network plugins
• Runtime:
  • Deploying security monitoring agents for workloads
  • Isolating applications that run on the same node using SELinux, AppArmor, etc.
  • Scanning configuration against recognized secure baselines for node, workload and orchestrator

Understand first, secure next

The cloud native way, including containers, provides great security benefits for its users: immutability, modularity, faster upgrades and consistent state across the environment. Realizing this fundamental change in “the way things are done”, motivates us to look at security with a cloud native lens. One of the things that was evident for all the authors of the paper was the fact that it’s tough to make smarter decisions on how and what to secure in a cloud native ecosystem if you do not understand the tools, patterns, and frameworks at hand (in addition to knowing your own critical assets). Hence, for all the security practitioners out there who want to be partners rather than a gatekeeper for your friends in Operations, Product Development, and Compliance, let’s make an attempt to learn more so we can secure better.

We recommend following this 7 step R.U.N.T.I.M.E. path to get started on cloud native security:

1. Read the paper and any linked material in it
2. Understand challenges and constraints for your environment
3. Note the content and controls that apply to your environment
4. Talk about your observations with your peers
5. Involve your leadership and ask for help
6. Make a risk profile based on existing and missing security controls
7. Expend time, money, and resources that improve security posture and reduce risk where appropriate.

Acknowledgements

Huge shout out to Emily Fox, Tim Bannister (The Scale Factory), Chase Pettet (Mirantis), and Wayne Haber (GitLab) for contributing with their wonderful suggestions for this blog post.

• ←Previous
Next→