71 lines
3.0 KiB
Markdown
71 lines
3.0 KiB
Markdown
Title: Kubernetes Security Standard
|
|
Document ID: [STD-K8S-001]
|
|
Version: 0.1 Draft
|
|
Status: Draft
|
|
Owner: CISO (Paul Jenkins)
|
|
Approver: CISO (Paul Jenkins)
|
|
Classification: Internal
|
|
Effective date: [DD Month YYYY]
|
|
Review date: [DD Month YYYY]
|
|
|
|
# Kubernetes Security Standard
|
|
|
|
## Purpose
|
|
|
|
This standard defines the minimum requirements for securing Kubernetes clusters, workloads, and supporting control planes used within the ISMS scope.
|
|
|
|
## Scope
|
|
|
|
This standard applies to Kubernetes clusters, namespaces, workloads, controllers, configuration manifests, ingress paths, secrets usage, administrative access, and supporting operational components.
|
|
|
|
## Mandatory Requirements
|
|
|
|
Access to Kubernetes control planes, cluster administration functions, and production namespaces must be restricted to authorised personnel and systems.
|
|
|
|
Role-based access controls must be defined and maintained to limit privileges according to operational need.
|
|
|
|
Cluster and workload configuration must follow approved security baselines, including restrictions on overly permissive settings and unnecessary privilege.
|
|
|
|
Secrets used by workloads must be managed through approved secrets management processes and must not be embedded insecurely in manifests or images.
|
|
|
|
Network exposure and service-to-service connectivity must be controlled according to business need and risk.
|
|
|
|
Cluster changes and workload deployments must be subject to approved change and deployment controls.
|
|
|
|
Security-relevant cluster events and administrative activity must be logged and monitored where feasible.
|
|
|
|
Workloads, images, and supporting components must be maintained in line with vulnerability and patch management expectations.
|
|
|
|
## Implementation Guidance
|
|
|
|
BlackDice should apply this standard in a way that reflects its use of containerised services, automation pipelines, and potentially different deployment models across SaaS and operator-hosted environments.
|
|
|
|
Kubernetes security assurance should address both platform-level controls and workload-level controls.
|
|
|
|
Baseline expectations should cover namespace separation, administrative identity, workload privilege, network policy, configuration validation, and image provenance where relevant.
|
|
|
|
Where managed Kubernetes services are used, BlackDice should define which responsibilities remain with the provider and which remain internal.
|
|
|
|
## Roles and Responsibilities
|
|
|
|
- [Role] must define Kubernetes security expectations.
|
|
- Platform owners must ensure clusters and supporting services meet this standard.
|
|
- Engineering and operations teams must deploy and manage workloads in line with approved controls.
|
|
|
|
## Exceptions
|
|
|
|
Exceptions must be documented, risk-assessed, approved, and reviewed through the defined process.
|
|
|
|
## Related Documents
|
|
|
|
- Cloud Security Policy
|
|
- Network and Infrastructure Security Policy
|
|
- Secrets Management Standard
|
|
- CI/CD Security Standard
|
|
|
|
## Version Control
|
|
|
|
| Version | Date | Description of Change | Author |
|
|
| --- | --- | --- | --- |
|
|
| 0.1 Draft | [DD Month YYYY] | Initial draft. | [Name or Role] |
|