Container Orchestration Guide

1. Introduction and Scope

1.0 Normative Language (Mandatory Keywords)

The following keywords are used to express requirement strength in this standard:

• SHALL / MUST: Mandatory requirement. Non-compliance requires an approved exception.
• SHOULD: Recommended requirement. If not implemented, rationale should be documented.
• MAY: Optional requirement.
• MUST NOT / SHALL NOT: Prohibited requirement.

1.1 Purpose

The purpose of this standard is to define how the Government of Malawi builds, stores, and runs containerized workloads and how orchestration platforms are secured. It covers image provenance and registry use, image scanning, orchestration RBAC and network policies, pod security, and integration with secrets and config.

1.2 Scope of Application

This standard applies to all government ministries and departments; state-owned enterprises and parastatals; local government authorities; and government contractors when they operate containers or orchestration for government systems. It covers on-premises, government cloud, and vendor-managed container platforms where the government retains responsibility.

1.3 Definitions and Key Terms

Container – A lightweight, runnable unit that packages an application and its dependencies; isolated from the host and other containers; built from an image.

Container image – An immutable snapshot of a container’s filesystem and configuration; built from a Dockerfile or similar; stored in a registry and scanned before use.

Orchestration – Automated deployment, scaling, and management of containers (e.g. Kubernetes); includes scheduling, networking, and lifecycle.

Registry – A governed repository for container images; access-controlled; only scanned, approved images are used in production.

RBAC (Role-Based Access Control) – In orchestration, the mechanism that grants users and service accounts minimum required permissions to the cluster and namespaces; cluster-admin restricted.

Network policy – Rules that control traffic between pods or namespaces; used to segment container workloads and limit blast radius.

Pod security – Standards (e.g. restricted: no privileged, read-only root where possible) applied to pods to reduce attack surface; aligns with CIS Kubernetes and NIST SP 800-190.

Secrets – Sensitive configuration (e.g. credentials) for containerised applications; must be injected at runtime from Malawi Government Secrets Management solution, not stored in images or plain text in pod spec.

2. Core Objectives and Success Metrics

2.1 Primary Objectives

Image provenance and scanning – All production images come from a governed registry; images are scanned for vulnerabilities and secrets; critical/high remediated or accepted with exception.

No secrets in images – Secrets are not embedded in images; runtime injection from Secrets Management solution; aligns with Secrets Management and CI/CD Standards.

Orchestration security – RBAC enforced with least privilege; network policies restrict traffic between pods/namespaces; pod security standards applied; control plane secured per CIS Kubernetes.

Governed deployment – Containerised applications are deployed via CI/CD with Change Management; workloads documented (owner, classification).

Consistency – Container and orchestration practices align with Server Hardening, Secrets Management, CI/CD, and Configuration Management so that government container workloads are secure and auditable.

2.2 Key Performance Indicators (KPIs)

2.3 Minimum Baseline and Prohibitions

• Minimum controls (floor for all ministries):
• Registry: All production images SHALL come from a governed registry; only scanned images meeting policy SHALL be used in production.
• Scanning: Images SHALL be scanned for vulnerabilities and secrets before promotion; critical/high remediated or accepted with exception.
• Secrets: Secrets SHALL NOT be in images; runtime injection from Malawi Government Secrets Management solution.
• RBAC: Cluster and namespace RBAC SHALL be enforced with least privilege; cluster-admin use restricted and audited.
• Network policy: Production namespaces SHALL have defined network policies; default-deny where feasible.
• Pod security: Pod Security Standards (e.g. restricted) SHALL be applied; privileged workloads only with exception.
• Prohibitions:

MUST NOT run production images that have not been scanned or that contain critical/high vulnerabilities without an approved exception.

MUST NOT embed secrets in container images or plain text in pod specs.

MUST NOT grant cluster-admin or broad privileges without justification and exception.

MUST NOT grant exception without recording in exception register with compensating controls and expiry.

3. Governance and Compliance Framework

3.1 Governance Structure

Document Owner – The Ministry of Information and Communication Technology (MoICT), Department of eGovernment, owns this standard and is responsible for its maintenance, interpretation, and coordination with other government standards (including Government Server Security Hardening, Secrets Management, and CI/CD Standards).

System Owner – Accountable for containerised applications under their responsibility; approves exception requests within their remit.

Security Officer – Validates that container and orchestration controls meet this standard and governs exceptions.

Platform or container administrator – Operates registry and orchestration platform; enforces RBAC, network policies, and pod security; ensures images are scanned and secrets are from Secrets Management.

Developer or DevOps – Builds images from version-controlled Dockerfile; uses CI/CD and Secrets Management; does not embed secrets in images.

3.2 Image Build and Registry

Images are built from version-controlled Dockerfile; build is part of CI/CD. Images are scanned (vulnerabilities, secrets); only images that meet policy are pushed to the governed registry. Registry is access-controlled. Base images are from trusted sources; minimal base preferred. Image tags are immutable for production.

Procedure: (1) Build images only from version-controlled Dockerfile via CI/CD; use minimal, trusted base images. (2) Run vulnerability and secret scan in pipeline; block push to registry if critical/high or secrets found unless exception is documented. (3) Promote to production only from governed registry; document image digest and owner for each workload. (4) Retain scan results for audit; re-scan when base image or dependencies change.

3.3 Secrets and Configuration

Secrets are not in images. Secrets are injected at runtime from the Malawi Government Secrets Management solution. Configuration is from ConfigMaps or configuration management; no plain-text secrets in pod spec. Aligns with Malawi Government Secrets Management and CI/CD Standards.

3.4 Orchestration Security

RBAC: Cluster and namespace RBAC grant minimum required permissions; cluster-admin restricted. Network policies: Traffic between namespaces or pods restricted; default-deny where feasible. Pod security: Pod Security Standards applied (e.g. restricted: no privileged, read-only root where possible). Control plane: Secured per vendor and CIS Kubernetes. Logging: Cluster and workload logs collected per Malawi Government Monitoring and Observability Standards.

3.4.1 Cluster Baseline (Email-like Minimum Checklist)

Platform owners SHOULD maintain a cluster baseline checklist aligned to CIS Kubernetes Benchmark / NIST SP 800-190. At minimum, the checklist should cover:

• Control plane access restrictions and auditing
• RBAC and service account minimisation
• Namespace standards (prod/non-prod separation where applicable)
• Network policy defaults (deny-by-default where feasible)
• Pod security enforcement (restricted baseline)
• Secrets integration (no secrets in images; secrets from approved solution)
• Logging and monitoring integration (SIEM/central logs where required)
• 3.4.2 Tenancy and Namespace Model (Baseline)
• Where clusters are shared:

Production workloads SHOULD be isolated by namespace and policy.

Resource quotas/limits SHOULD prevent a tenant from exhausting shared resources.

Network policies SHOULD restrict cross-namespace traffic to approved flows.

3.5 Deployment and Change Management

Containerized applications are deployed via CI/CD per Malawi Government CI/CD Standards. Production deployments follow Malawi Government Change Management Standards. Workloads are documented (owner, classification).

3.6 Safe Exception Process

Exceptions to mandatory container/orchestration requirements (e.g. image scanning, RBAC, secrets from solution) SHALL be requested, documented, and reviewed as follows. Exception requests must include: system or service name; requirement(s) from which exception is sought; justification; compensating controls and timeline; proposed end date; and sign-off from System Owner and Security Officer. Request via government form or template. Documentation: justification; compensating controls and timeline; risk acceptance by System Owner and Security Officer; maximum exception duration (not to exceed 12 months unless re-approved). Review: at least quarterly; extensions require re-approval. Register: all exceptions SHALL be recorded in an exception register and made available for audit.

4. Verification and Evidence Baseline (Audit-Ready Container and Orchestration)

To make this standard auditable, ministries and platform administrators SHOULD maintain evidence that, at minimum, demonstrates:

• Images and registry: Governed registry; image scan results; no critical/high in production without exception; image digest and owner per workload.
• Secrets: No secrets in images (scan evidence); secrets integration method; no plain text in manifests.
• Orchestration: RBAC config and review; network policies per namespace; pod security enforcement; cluster baseline checklist (Appendix D.1).
• Exception register: All exceptions with requirement, justification, compensating controls, owner, expiry, review date.
• What internal audit checks: (1) Sample of production images for scan and registry; (2) RBAC and network policy coverage; (3) exception register validity.
• Sampling approach: Quarterly sample of namespaces and workloads; annual review of exception register and cluster baseline.
• Escalation path: Non-compliance → System Owner and Security Officer → remediation plan; repeated → Document Owner and senior management.

4.1 Compliance Reporting

5. Legal Compliance and Training

5.1 Legal and Related Standards

Data Protection Act (2024) and Electronic Transactions and Cybersecurity Act (2016) apply where containers process government or personal data.

• Related standards: Malawi Government Secrets Management Guide; Malawi Government Secure Delivery Guide; Government Server Security Hardening Guide; Malawi Government Monitoring and Observability Guide.
• Training: Platform and development teams on this standard, image security, orchestration security, secrets handling; at role assumption and refreshed at least annually.

6. Framework Alignment

This standard contributes to compliance with international frameworks:

• ISO/IEC 27001:2013 – control families A.14, A.12, A.9, A.13
• NIST SP 800-53 Rev. 5 – families SA, SC, SI, AC
• Benchmarks – CIS Kubernetes Benchmark; NIST SP 800-190 for container security

7. Appendices

Appendix A: Related Standards

Malawi Government Secrets Management Guide; Malawi Government Secure Delivery Guide; Government Server Security Hardening Guide; Malawi Government Monitoring and Observability Guide.

Appendix B: Control and Legal Mapping

• Appendix C: Evidence and Artifact Checklist
• Images and registry: Governed registry; image scanning; no high/critical in production images.
• Orchestration: RBAC; network policies; pod security; secrets from solution; exception register with requirement, justification, and review/expiry dates.
• Appendix D: Templates (Minimum)

D.1 Cluster Baseline Checklist (Outline)

• RBAC: cluster-admin usage restricted; review cadence
• Network: default policies; ingress/egress controls
• Pod security: restricted profile enforced; exceptions documented
• Logging: audit logs enabled; forwarding configured; retention confirmed
• Secrets: integration method; no plaintext secrets in manifests

D.2 Privileged Workload Exception (Template)

• Workload and owner
• Why privileged capability is required
• Compensating controls (namespace isolation, additional monitoring)
• Expiry date and migration plan to remove privilege

References

NIST SP 800-190, Application Container Security Guide.

CIS Kubernetes Benchmark.

Data Protection Act No. 3 of 2024 (Malawi).

Electronic Transactions and Cybersecurity Act (2016) (Malawi).