ISO 27001 Kubernetes Security: Container Orchestration Controls
Organisations across the Middle East are rapidly adopting Kubernetes for container orchestration, seeking the scalability and operational efficiency that cloud-native infrastructure provides. However, extending an ISO 27001-compliant information security management system (ISMS) to cover containerised environments presents unique challenges. Understanding ISO 27001 Kubernetes security requirements is essential for organisations that must maintain certification while embracing modern deployment architectures.
The ISO 27001:2022 standard does not explicitly mention containers or Kubernetes, but its Annex A controls apply comprehensively to container orchestration platforms. Organisations must interpret these controls in the context of dynamic, ephemeral workloads where traditional perimeter-based security models are insufficient. This article provides a practical framework for mapping Annex A controls to Kubernetes environments and implementing the necessary technical and procedural safeguards.
Kubernetes Security Challenges for ISO 27001
Containerised environments introduce specific security challenges that differ materially from traditional virtual machine or bare-metal deployments. The ephemeral nature of pods, the complexity of the container supply chain, and the expanded attack surface created by the Kubernetes control plane all require careful consideration within the ISMS risk assessment framework.
| Security Domain | Traditional Environment | Kubernetes Environment | Risk Level |
|---|---|---|---|
| Network security | Static IPs, firewall rules, VLANs | Dynamic IPs, software-defined networking, CNI plugins | High |
| Identity and access | Active Directory, LDAP, server logins | RBAC, service accounts, OIDC integration | High |
| Secrets management | HSM, encrypted config files | etcd encryption, Kubernetes Secrets, external vaults | Critical |
| Vulnerability management | Periodic OS patching | Image scanning, immutable deployments, patch cycles | High |
| Audit logging | Syslog, Windows Event Log | Audit logs, kube-apiserver logs, container logs | Medium |
| Change management | ITIL-based approvals | GitOps, CI/CD pipelines, Helm charts | Medium |
Annex A Controls for Container Environments
ISO 27001’s Annex A contains 93 controls organised across four themes. The following controls are particularly relevant to Kubernetes security and require specific implementation approaches for containerised environments.
| Annex A Control | Control ID (2022) | Kubernetes Implementation |
|---|---|---|
| Information security policy | 5.1 | Extend policy to cover container lifecycle, image provenance, and cluster administration |
| Asset management | 5.9 | Maintain inventory of container images, clusters, namespaces, and Helm charts |
| Access control | 5.15 – 5.18 | Implement Kubernetes RBAC, service account policies, and OIDC integration |
| Cryptography | 5.19 – 5.20 | Enable etcd encryption, TLS for all components, image signing with Notary |
| Physical security | 5.21 – 5.23 | Secure worker node access, restrict kubelet API, harden host OS |
| Operations security | 5.24 – 5.28 | Pod security standards, network policies, resource quotas, admission controllers |
| Communications security | 5.29 – 5.30 | CNI network policies, mTLS service mesh, ingress TLS termination |
| Supplier relationships | 5.31 – 5.33 | Assess managed Kubernetes providers, review container registry security posture |
Cluster Security Architecture
A compliant cluster security architecture under ISO 27001 must address the entire Kubernetes stack, from the host operating system through to the application workload. The control plane must be protected as a critical asset, given that compromise of the kube-apiserver or etcd would provide attackers with full cluster access.
Organisations should implement a defence-in-depth approach that includes API server authentication and authorisation with OIDC or x509 certificates, TLS encryption for all control plane communications, etcd encryption at rest using KMS providers, and audit logging for all API server requests. Worker nodes must be hardened by removing unnecessary services, applying security patches promptly, and restricting direct SSH access in favour of Kubernetes-native debugging tools.
Pod Security Standards
ISO 27001 requires organisations to implement controls that prevent unauthorised access to information systems (Annex A 5.15) and protect against malicious code (Annex A 5.27). In Kubernetes, pod security standards (PSS) provide a framework for enforcing security contexts at the pod level. The three profiles – privileged, baseline, and restricted – map to different risk acceptance levels within the ISMS.
- Privileged – Unrestricted policy, suitable for system-level pods such as CNI agents and monitoring daemonsets; limited to explicitly authorised namespaces
- Baseline – Minimally restrictive but prevents known privilege escalations; appropriate for most production workloads
- Restricted – Follows pod hardening best practices; required for namespaces handling sensitive data under Annex A 5.22
Organisations should implement admission controllers (PodSecurity Admission or OPA Gatekeeper) to enforce these policies at the namespace level, ensuring that non-compliant pods cannot be deployed. Regular policy-as-code audits should verify that the enforcement mechanisms remain effective.
Network Policies
Annex A 5.29 (Network security) and 5.30 (Network segregation) require organisations to control network traffic between systems and segregate environments based on risk. Kubernetes network policies provide the mechanism for implementing micro-segmentation within the cluster.
By default, Kubernetes allows all pod-to-pod traffic. Organisations must implement a default-deny network policy and then explicitly allow required traffic flows based on application architecture. Policies should be defined at the namespace level and should restrict ingress and egress traffic using pod selectors, namespace selectors, and IP blocks. The network policy implementation must be verified through regular penetration testing, as required by Annex A 5.28.
| Traffic Flow | Policy Rule | ISO 27001 Control Mapping |
|---|---|---|
| Frontend to backend API | Allow ingress from app=frontend to app=backend on TCP 8080 | 5.29 – Network security |
| Backend to database | Allow ingress from app=backend to app=database on TCP 5432 | 5.30 – Network segregation |
| Egress to external API | Allow egress from app=backend to external CIDR on TCP 443 | 5.29 – Network security |
| Deny all other traffic | Default deny ingress and egress on all pods | 5.30 – Network segregation |
| Monitoring access | Allow ingress from namespace=monitoring to all namespaces on TCP 9090 | 5.25 – Monitoring |
Secrets Management
The management of cryptographic keys and secrets is addressed by Annex A 5.19 (Information security in use of cloud services) and 5.20 (Cryptographic controls). Kubernetes Secrets require careful handling because they are stored in etcd by default and may be accessible to anyone with API server access.
For ISO 27001 Kubernetes security compliance, organisations should encrypt Secrets at rest using a KMS provider such as AWS KMS, Azure Key Vault, or HashiCorp Vault. Integration with external secrets management systems should be preferred over native Kubernetes Secrets for production workloads. Secrets should never be stored in container images, Helm charts, or version control systems. Rotation policies must be defined and automated, particularly for service account tokens and TLS certificates.
RBAC and Access Control
Annex A 5.15 (Access control) through 5.18 (Access rights) require organisations to implement role-based access control with the principle of least privilege. Kubernetes RBAC provides the native mechanism for this, but organisations must carefully design their role and binding structure to avoid excessive permissions.
Default Kubernetes service accounts should be configured with no permissions, and explicit RoleBindings or ClusterRoleBindings should be created for each workload. Human access should be managed through OIDC integration with the corporate identity provider, with emergency break-glass accounts secured through privileged access management tools. Regular access reviews must be conducted to ensure that permissions remain appropriate, as required by Annex A 5.18.
Image Scanning and Supply Chain Security
Annex A 5.24 (Information security incident management planning) requires organisations to manage security incidents effectively, including those arising from vulnerable container images. Container images represent a critical supply chain risk, as vulnerabilities in base images or third-party dependencies can undermine the entire security posture.
Organisations must implement automated image scanning in the CI/CD pipeline, blocking deployments that contain vulnerabilities above defined severity thresholds. Images should be signed using tools such as Notary or Sigstore Cosign to ensure integrity throughout the supply chain. A registry of approved base images should be maintained and enforced through admission control policies.
Audit Logging and Monitoring
Annex A 5.25 (Information security event management) and 5.28 (Monitoring) require organisations to log and monitor security-relevant events. Kubernetes audit logging provides a comprehensive record of all API server requests, but organisations must configure the audit policy carefully to capture relevant events without overwhelming storage capacity.
Audit logs should be exported to a central SIEM platform for correlation and analysis. Container stdout and stderr logs should be collected through a logging agent such as Fluentd or Logstash and retained in accordance with the organisation’s data retention policy. Monitoring alerts should be configured for events such as privilege escalation attempts, failed authentication attempts, and modification of RBAC roles.
Frequently Asked Questions
Does ISO 27001 explicitly cover Kubernetes and containers?
ISO 27001 does not mention Kubernetes or containers by name, but its Annex A controls apply to all information processing systems, including container orchestration platforms. Organisations must interpret the controls in the context of their specific technology stack and ensure that their risk assessment addresses container-specific threats.
What is the most critical Annex A control for Kubernetes security?
Annex A 5.15 (Access control) and 5.30 (Network segregation) are typically the most impactful controls for Kubernetes environments. Implementing least-privilege RBAC and default-deny network policies addresses the majority of common Kubernetes attack vectors.
Can I use managed Kubernetes services and remain ISO 27001 certified?
Yes, but you must ensure that the managed service provider holds its own ISO 27001 certification for the platform. You must also review the shared responsibility model carefully and implement controls for the areas that remain your responsibility, such as workload security, access management, and data protection.
How often should container images be scanned for vulnerabilities?
Images should be scanned at every build within the CI/CD pipeline. Additionally, running containers should be rescanned continuously, with most compliance frameworks recommending daily scans. Critical vulnerabilities identified in running containers must be remediated within 24 to 48 hours depending on severity.
What audit evidence is required for Kubernetes during an ISO 27001 certification audit?
Auditors typically request evidence of RBAC configuration, network policy definitions, image scanning reports, audit log retention and review procedures, secrets management policies, pod security standards enforcement, and incident response records related to container security events.
How should secrets be managed to satisfy ISO 27001 requirements in Kubernetes?
External secrets management solutions such as HashiCorp Vault or cloud provider KMS are strongly recommended. Kubernetes native Secrets should be encrypted at rest using KMS encryption. Secrets must never be stored in container images or version control, and automated rotation policies should be implemented.
Conclusion
Implementing ISO 27001 Kubernetes security controls requires a structured approach that maps Annex A requirements to the specific characteristics of container orchestration environments. By addressing cluster security, pod standards, network policies, secrets management, RBAC, image scanning, and audit logging, organisations can maintain ISO 27001 certification while benefiting from cloud-native infrastructure. The key is to treat the Kubernetes platform as a critical information asset within the ISMS scope and apply the same rigour that would be applied to any other significant component of the technology stack.
Contact Bitrixme to discuss how our ISO 27001 consultants can help you extend your ISMS to cover Kubernetes and cloud-native environments.
Book a consultation with our ISO 27001 Kubernetes security team →
