How to Secure Container Orchestration in OpenStack

Securing container orchestration in OpenStack is critical to avoid risks like misconfigured access controls, hypervisor flaws, and weak network policies. Misconfigurations are a leading cause of container security breaches. Improperly configured access controls, network policies, and resource limits can create vulnerabilities that attackers can exploit. While precise statistics vary, it’s widely acknowledged that misconfigurations pose a significant risk. 

Here’s a quick overview of how you can protect your OpenStack environment, and what we’ll be going further into in this article:

Key Security Practices:

• Access Controls: Use Keystone for MFA, role-based access, and token expiry limits.
• Container Images: Scan images with Anchore Engine and secure private registries with Barbican encryption.
• Network Security: Apply Neutron policies and Calico integration to enforce zero-trust communication.
• Runtime Protection: Deploy tools like KubeArmor and Falco for real-time threat detection.
• Data Encryption: Secure etcd, Cinder, and Swift with FIPS 140-2 encryption via Barbican.

What to Tackle First:

1. Harden runtime environments with eBPF-based tools.
2. Strengthen access controls.
3. Implement network segmentation.

Organizations with a comprehensive, layered security approach to container orchestration have seen major reductions in security incidents. These improvements come through a combination of best practices, including strong access controls, continuous vulnerability scanning, network segmentation, and runtime protection.

Basic Security Steps for OpenStack Containers

Start with these essential steps:

Setting Up User Access Controls

Keystone authentication is a big part of securing OpenStack containers. Use Multi-Factor Authentication (MFA) along with role-based access controls to strengthen security. Make sure to enforce project-scoped RBAC in Keystone to prevent privilege escalation.

Securing Container Images

Once access controls are configured, move on to container images:

• Use Anchore Engine in your CI/CD pipelines to automatically scan container images for vulnerabilities.
• For private registry security in OpenStack Swift:
  • Enable server-side encryption using Barbican-managed keys.
  • Configure temporary URLs with a 24-hour expiration for secure image pulls.
  • Set up object versioning to allow safe rollbacks if needed.

Network Security Setup

Strengthen network security by combining Neutron security groups with Kubernetes network policies. For example, Calico’s integration with OpenStack Neutron allows detailed control over pod-to-pod communication.

To enforce zero-trust communication between pods, you can use the following Calico policy:

apiVersion: projectcalico.org/v3
kind: NetworkPolicyspec:
  selector: app == 'database' # Applies to pods labeled with "app: database"
  ingress: # Rules for incoming traffic
  - action: Allow
    source:
      selector: app == 'frontend' # Only allow traffic from pods labeled "app: frontend"

The above Calico NetworkPolicy demonstrates a basic zero-trust approach. It specifies that only pods labeled with app: frontend are allowed to send traffic to pods labeled with app: database. All other traffic is implicitly denied. This policy isolates the database and prevents unauthorized access, even from other pods within the same cluster.

Additionally, secure external access with Neutron security group rules, like this example for HTTPS traffic:

openstack security group rule create --protocol tcp --dst-port 443 --remote-ip 0.0.0/0 web-access

This command creates a security group rule in OpenStack Neutron to allow HTTPS traffic (port 443). However, opening a port to 0.0.0.0/0 (all IP addresses) should be done with extreme caution. It’s generally recommended to restrict access to only the necessary IP addresses or networks to minimize the attack surface. Consider using more specific CIDR blocks or security group rules to limit access.

For enhanced monitoring, KubeArmor can be deployed. This tool uses eBPF-based behavioral analysis to detect unusual activity, such as unexpected network socket creation or abnormal process behavior. It has been successfully used in production environments.

High-Level Security for Kubernetes on OpenStack

Security is at the forefront of every engineer’s mind when it comes to Kubernetes. Looking at security and Kubernetes from an OpenStack perspective, one of the most significant pieces is Operations security. In this video, you’ll learn about Kubernetes security on OpenStack and how to manage it from an Ops perspective.

Using Barbican for Kubernetes Security

For clusters deployed with Magnum, Barbican handles secrets management for Kubernetes. Here’s how to configure Barbican integration:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: barbican-secrets
spec:
  provider: barbican
  parameters:
    objects: |
      - secretName: "app-credentials"
        type: "opaque" (non-structured data)
        barbican-name: "prod-credentials"

Data Storage Protection

This approach follows OpenStack’s layered security model. Use Swift‘s server-side encryption for object storage and extend it to persistent volumes with Cinder storage classes. Additionally, enable encryption-at-rest for etcd using AES-256-GCM keys stored securely in Barbican.

FIPS 140-2 is a widely recognized standard for validating the cryptographic modules used in hardware and software. While FIPS 140-2 certification provides assurance about the security of these modules, it’s important to understand that it doesn’t guarantee the security of the entire system. Proper implementation and configuration are still needed.

Security Monitoring Tools

Deploy Falco as a DaemonSet to monitor security events in real-time. For instance, you can use the following rule to detect unauthorized storage mounts:

- rule: unauthorized_cinder_access
  desc: Detect unauthorized volume attachments
  condition: evt.type=mount and container.id != "" and not source.ip in 10.0.0.0/8
  output: Unauthorized volume mount detected (user=%user.name volume=%fd.name)
  priority: CRITICAL

Additionally, keep an eye on authentication failures, etcd latency, and changes to Neutron security groups to ensure thorough security monitoring. 

Security Standards and Automation

Meeting Security Standards

Ensuring OpenStack’s container orchestration layers comply with industry frameworks takes careful configuration. To align with frameworks like NIST SP 800-190 and CIS benchmarks, enabling Pod Security Admission (PSA) in “Restricted” mode is a good starting point. Pod Security Admission is a Kubernetes feature that allows you to enforce pod security standards at the namespace level.

While PSA is a valuable tool for restricting pod capabilities and preventing privilege escalation, it’s not a comprehensive security solution. Other security measures, such as network policies, runtime security, and vulnerability scanning are still necessary to provide a layered defense.

Cloud Security Posture Management (CSPM) tools can automate the process of assessing and improving the security posture of cloud-native environments. These tools can help identify misconfigurations, vulnerabilities, and compliance gaps.

Automated Security Checks

To address OpenStack’s unique challenges, automated workflows can streamline security checks. These workflows help in managing ephemeral workloads and maintaining compliance. A three-stage automation strategy works well:

• Daily image scans: Use Clair-Glance integration for regular vulnerability checks.
• Weekly web app tests: Conduct tests with OWASP ZAP to identify weaknesses.
• Monthly RBAC audits: Validate role-based access controls against SOC 2 requirements.

For runtime security, tools like KubeArmor’s policy validator help catch common misconfigurations, such as:

• API access without proper RBAC controls.
• Unencrypted Cinder volumes storing sensitive data.
• Missing network policies for untrusted pods.

Additionally, operators like the Quay Security Operator can automate the management of container image security. These operators can automatically quarantine vulnerable images, trigger rebuilds, and enforce security policies.

Conclusion: OpenStack Container Security Best Practices Summary

This guide has hopefully clearly outlined how to strengthen OpenStack’s built-in security measures for locking down containers. 

As mentioned above, solid container security relies on three key areas:

• Runtime hardening: Use eBPF monitoring and Linux security modules to protect active containers.
• Centralized access controls: Leverage Keystone’s RBAC system and Barbican for encryption to manage permissions effectively.
• Microsegmented networking: Apply Neutron and Calico policies to isolate workloads and reduce attack surfaces.

When implementing these measures, prioritize runtime protection first, then tackle access controls, and address network security after that.

And of course, keeping all OpenStack components up to date is a must for security. Outdated components may contain known vulnerabilities that attackers can exploit. Regularly apply security patches and updates to minimize the risk of compromise.

For a more complete security plan, integrate continuous vulnerability scans and penetration tests into your workflows. These additional steps help identify and address both current risks and new threats in OpenStack container environments.