Kubernetes Platform — Tender Response Library (World-Bank-grade)
Acest conținut nu este încă disponibil în limba selectată.
Reusable across tenders. The methodology, component catalogue, DevSecOps model, SSO/management design, standards references and measurable non-functional requirements for a production Kubernetes platform, written to the evidentiary bar a World Bank “Information Systems” procurement expects. No commands — this is the approach document. The engineering “how” lives in [[Kubernetes-Platform-Production-Install-Guide]].
How to use. Lift the relevant section into a bid; adapt every target to what the tender demands and what the awarded architecture actually supports. We win on traceable evidence, not adjectives — the Requirement Traceability Matrix (§7) is the spine.
Sibling libraries: [[Database-Tender-NFR-Responses]] · [[PostgreSQL-HA-Production-Install-Guide]]. Last revised: 2026-07-25.
⚠️ Scope caveat (read first). A World Bank Information Systems SPD bid is roughly half non-technical: implementation methodology & timeline, staffing & CVs, past performance, SLA/support model, training & handover, warranty, and the financial envelope. This library covers the technical component only. Assemble the rest of the bid around it.
⚠️ Version & license currency. Component versions and licences change. Re-validate each at bid submission (support window, EOL, licence). Three current flags carried through this document: HashiCorp Vault is BSL (evaluate OpenBao, OSI-licensed), MinIO CE is effectively EOL (SeaweedFS / Garage / Rook-Ceph RGW), Redis 8 is AGPLv3 (Valkey, BSD).
1. Reference architecture (one paragraph for the evaluator)
Section titled “1. Reference architecture (one paragraph for the evaluator)”A self-managed, CNCF-conformant Kubernetes platform: 3 control-plane nodes with stacked etcd behind a highly-available API virtual IP, and 6–9 worker nodes, on the latest supported Kubernetes minor. Networking is Cilium (eBPF, kube-proxy-free, identity-based and L7 network policy, Hubble observability); storage is Longhorn replicated block storage on dedicated disks with off-cluster backups; north-south traffic uses Gateway API with cert-manager (internal CA + public ACME); delivery is GitOps with ArgoCD; secrets are centralised in Vault/OpenBao with dynamic credentials and an internal PKI; security and multi-tenancy are enforced by Kyverno + Pod Security Admission + default-deny network policy; observability is the VictoriaMetrics stack with SLO alerting and a dead-man’s-switch; and all authentication — the Kubernetes API and every management console — federates to Keycloak (OIDC/SAML, groups→RBAC, MFA). Everything is open-source and standards-based, deployed as Infrastructure-as-Code, and independently verifiable (CNCF conformance, CIS benchmark, SBOM, signed images).
2. Component catalogue
Section titled “2. Component catalogue”Each platform component, its technology, purpose, HA approach, governing standard, and licence (the open-standards / anti-lock-in column a World Bank evaluator scores).
| # | Component | Technology (re-validate version) | Purpose | HA approach | Standard | Licence |
|---|---|---|---|---|---|---|
| 1 | Orchestration / control plane | Kubernetes (RKE2 / Talos / kubeadm); containerd + runc | Conformant orchestration substrate | 3 control-plane, odd etcd quorum, API VIP, CP taint | CNCF Certified Kubernetes; CIS K8s Benchmark; NSA/CISA Hardening Guide | Apache-2.0 ✅ |
| 2 | API-server VIP | kube-vip (ARP/BGP) / HAProxy+Keepalived | Stable HA API endpoint, in cert SANs | Leader-elected/advertised VIP, /readyz probe | kubeadm HA topology | Apache-2.0 ✅ |
| 3 | CNI / dataplane | Cilium (eBPF) + Hubble | Pod networking, in-eBPF service LB, identity/L7 policy, flow visibility | DaemonSet + operator, kube-proxy-free | CNCF Graduated; NIST 800-207 ZT; NetworkPolicy/Gateway API | Apache-2.0 ✅ |
| 4 | Service LoadBalancer | Cilium LB-IPAM + BGP (ECMP/BFD); MetalLB fallback | On-prem LoadBalancer VIPs, true multi-node spread | BGP/ECMP + BFD sub-second failover; one announcer/pool | BGP host routes | Apache-2.0 ✅ |
| 5 | Ingress / API gateway | Gateway API via Cilium/Envoy Gateway (ingress-nginx legacy) | North-south HTTP/gRPC routing, role separation | ≥2 replicas, anti-affinity, PDB, externalTrafficPolicy:Local | K8s Gateway API; NIST 800-204 | Apache-2.0 ✅ |
| 6 | TLS / certificates | cert-manager + Vault PKI + ACME DNS-01 | Automated internal/public cert issuance + renewal | Controller + webhook; short-lived leafs; expiry alerting | RFC 5280; ACME RFC 8555 | Apache-2.0 ✅ |
| 7 | Persistent storage | Longhorn (V1 engine), dedicated disks | Replicated block storage without external SAN | 3-way sync replication, node anti-affinity, S3/NFS backups, DR volumes | CNCF Incubating; CSI; PV Retain | Apache-2.0 ✅ |
| 8 | GitOps delivery | ArgoCD (HA) + ApplicationSets + Argo Rollouts | Declarative, auditable delivery; drift heal; progressive delivery | redis-ha 3+3, ≥2 server/repo, sharded controller | OpenGitOps 1.0; NIST SSDF PO.3/PS.1 | Apache-2.0 ✅ |
| 9 | Secrets management | Vault → evaluate OpenBao + VSO | Central secrets, dynamic DB creds, internal PKI, audit | 3/5-node Raft quorum, auto-unseal, snapshots | NIST 800-57; FIPS 140-2/3 (HSM); OWASP ASVS V6 | Vault BSL ⚠️ / OpenBao MPL-2.0 ✅ |
| 10 | Policy / admission | Kyverno + Pod Security Admission + cosign verifyImages | Admission enforcement, tenant guardrails, signature verification | HA 3 admission replicas + separate controllers | K8s Pod Security Standards; CIS; SLSA v1; NIST 800-190 | Apache-2.0 ✅ |
| 11 | Multi-tenant isolation | Namespace-per-tenant (Kyverno generate) → Capsule → vCluster | Graduated project isolation | Per-tenant quota/RBAC/NetworkPolicy; vCluster for strong isolation | K8s multi-tenancy; NIST 800-190 segmentation; ISO 27001 A.9 | Apache-2.0 ✅ |
| 12 | Observability | VictoriaMetrics stack + VictoriaLogs + OTel/Traces + Grafana | Metrics/logs/traces/dashboards/SLO alerting | VMCluster RF≥2, HA Alertmanager, Watchdog + heartbeat | OpenMetrics; OpenTelemetry OTLP; Google SRE SLO | Apache-2.0 ✅ (Grafana AGPLv3) |
| 13 | Identity / SSO | Keycloak (Operator + external PG) + kubelogin + oauth2-proxy | One IdP for the API and every UI, groups→RBAC | 2–3 clustered replicas, external HA PostgreSQL | OIDC Core 1.0; SAML 2.0; NIST 800-63B AAL2 | Apache-2.0 ✅ |
| 14 | Private registry | Harbor (+ mirror for air-gap) | Signed images, SBOMs, cosign attestations, air-gap mirror | HA deployment + replication | OCI Distribution; SLSA provenance | Apache-2.0 ✅ |
| 15 | Runtime threat detection | Tetragon (or Falco) | eBPF runtime security observability/enforcement | DaemonSet | NIST 800-190 runtime countermeasures | Apache-2.0 ✅ |
| 16 | In-cluster PostgreSQL | CloudNativePG (or CrunchyData PGO) | Stage backing DB with failover + PITR | 1 primary + 2 replicas, WAL to object storage | CNCF; PostgreSQL; RPO≤5m/RTO<30s | Apache-2.0 ✅ |
| 17 | In-cluster cache | redis-operator, Sentinel (Valkey) | Cache/session store, HA | 1+2 replicas + 3 sentinels | Redis Sentinel quorum | Redis 8 AGPLv3 ⚠️ / Valkey BSD ✅ |
| 18 | In-cluster broker | RabbitMQ Cluster Operator, RabbitMQ 4.x | Durable messaging, quorum queues | 3-node cluster, Raft quorum queues | Quorum queues | MPL-2.0 ✅ |
| 19 | Object storage | MinIO EOL ⚠️ → SeaweedFS / Garage / Rook-Ceph RGW | S3-compatible store | Erasure coding ≥4 drives, bucket replication | AWS S3 API compat | MinIO AGPLv3+EOL ⚠️ / alternatives Apache/AGPL |
| 20 | Platform backup / DR | Velero (+ etcd snapshots + operator-native backups) | k8s-native namespace/PVC backup + full-cluster DR | CSI snapshots, off-site immutable repos | ISO 27031 continuity | Apache-2.0 ✅ |
(Every ⚠️ has a stated open-licence swap — this is the differentiator for an anti-lock-in bid.)
3. Management-plane access — SSO via Keycloak (a dedicated section)
Section titled “3. Management-plane access — SSO via Keycloak (a dedicated section)”Every administrative console authenticates through a single identity provider (Keycloak), so access
is centrally granted, revoked, MFA-enforced and audited — no per-tool local passwords in daily use.
One reusable groups claim drives authorization everywhere; each tool is deny-by-default.
| Management UI | Integration | Authorization model | Operational note |
|---|---|---|---|
Kubernetes API (kubectl) | OIDC via apiserver Structured Auth Config + kubelogin (PKCE) | RBAC bound to kind: Group (oidc: prefix) | Short-lived tokens; no static kubeconfig certs in daily use |
| ArgoCD (GitOps) | Native OIDC | argocd-rbac-cm: default readonly, group→role | Requires a Keycloak group mapper |
| Grafana (dashboards) | Native OAuth | role_attribute_strict, default Viewer | Strict mapping mandatory |
| Vault / OpenBao (secrets) | Native OIDC | External groups → Vault policies | Recovery-key break-glass kept outside OIDC |
| pgAdmin (DB admin) | Native OAuth2 | OIDC logs into pgAdmin; DB creds separate | No in-app roles; internal auth retained as sealed break-glass |
| Longhorn (storage) | oauth2-proxy (no native auth) | Gated on a Keycloak group; all-or-nothing | A bare Ingress = full storage console — must be gated |
| RabbitMQ (broker) | Native oauth2 plugin | Scopes → vhost/permission tags | aud must equal resource_server_id, not client id |
| MinIO Console (object store) | Native OIDC | policy JWT claim → access | No claim = zero access |
| Hubble UI (network) | oauth2-proxy | Gated on a Keycloak group | No native auth |
| Kubernetes Dashboard | Bearer token / oauth2-proxy | Inherits the user’s RBAC | Reconsider deploying; HA oauth2-proxy mandatory |
Resilience of the identity layer (state it — evaluators probe it). Because the Kubernetes API and the consoles depend on Keycloak, and Keycloak runs inside the platform, we design for its outage:
- a sealed, offline break-glass cluster-admin certificate (expiry monitored) for API access when Keycloak is unavailable;
- a documented, MFA-protected local-admin fallback per console (ArgoCD admin, Grafana admin, Vault recovery keys, pgAdmin internal);
- Keycloak realm-as-code + its database in the platform DR plan (lose the realm = lose every client config);
- oauth2-proxy in HA (≥2 replicas, shared session store) so the fronting layer is not itself a SPOF.
4. DevOps / DevSecOps methodology
Section titled “4. DevOps / DevSecOps methodology”Security is built into every stage, not bolted on — a continuous, everything-as-code pipeline with blocking (not advisory) gates, mapped to recognised frameworks (NIST SSDF, CIS, OWASP, SLSA).
| Phase | Practices | Tooling (representative) | Framework |
|---|---|---|---|
| Plan & threat-model | Security-by-design reviews; security champions; requirements traced to standards; change management is the reviewed PR trail | Threat-model templates, OWASP DSOMM maturity, ADRs, the RTM (§7) | NIST SSDF PO; OWASP ASVS |
| Code & commit | Blocking SAST + secret scanning in pre-commit and CI; peer review as the approval record; no plaintext secrets ever | Semgrep/CodeQL/Sonar; gitleaks/trufflehog | SSDF PW; OWASP Top 10 |
| Build & package | Distroless bases pinned by digest; SBOM (CycloneDX/SPDX); keyless-sign images + SBOMs; SLSA build-L3 provenance; hardened runners | Syft; cosign (Sigstore); Trivy | SLSA v1.0; SSDF PS |
| Test & scan | SCA fail-on fixable CRITICAL/HIGH; IaC + manifest policy scan; CIS checks; fail the build to block promotion | Trivy/Grype; Checkov + kube-linter; kube-bench; Trivy Operator | CIS K8s; NIST 800-190 |
| Release & deploy | Pull-based GitOps as the only path — Git is the sole source of truth, no kubectl/helm from pipelines or laptops; CI holds no cluster admin; drift auto-healed | ArgoCD (App-of-Apps/ApplicationSets, waves) | OpenGitOps 1.0; SOC 2 CC8.1 |
| Admission backstop | Admission-time guarantee that only signed, policy-compliant workloads run even if a gate is bypassed; policies unit-tested; Audit→Enforce; PSA restricted floor | Kyverno verifyImages + PSA | Pod Security Standards; SLSA |
| Progressive delivery | Canary/blue-green with automated SLI analysis that aborts on SLO breach; rollback = git revert | Argo Rollouts (VictoriaMetrics AnalysisTemplate) | Google SRE |
| Operate & respond | Full-stack observability from day 0 with a dead-man’s-switch; probe real SLIs not L4; scheduled CIS + CVE scans; runbooks for low MTTR | VictoriaMetrics + VictoriaLogs + OTel; kube-bench CronJob | SSDF RV; SRE |
| Measure & improve | Track the four DORA keys against elite benchmarks; blameless post-mortems feeding pipeline + policy | Four Keys / DORA dashboards | DORA / Accelerate |
Supply chain & operations additions (from the completeness review): a private registry (Harbor) with an air-gap mirror and self-hosted Sigstore or key-pair signing where public Fulcio/Rekor is unreachable; runtime threat detection (Tetragon/Falco) to realise the NIST 800-190 runtime controls; a vulnerability-remediation SLA with a VEX process for triage (not just “we scan”); a golden-image / OS-patch pipeline (unattended-upgrades, kernel-CVE cadence, LTS EOL tracking); and Git repository HA/backup/mirror, because pull-GitOps makes the repo production-critical.
5. Security & hardening posture
Section titled “5. Security & hardening posture”| Domain | Our approach | Standard / evidence |
|---|---|---|
| Cluster hardening | CIS Kubernetes Benchmark baseline, remediated in risk order, re-scanned for drift | CIS K8s Benchmark (kube-bench PASS report, target score) |
| API audit | kube-apiserver audit logging shipped to VictoriaLogs (who-did-what) | NSA/CISA logging; retained + reviewable |
| Secrets at rest | etcd secret encryption-at-rest (aescbc/secretbox or KMS/HSM) | NIST 800-57; no plaintext secrets in etcd |
| Workload security | Pod Security Admission restricted floor + Kyverno policies (forbid privileged, :latest, untrusted registries; require limits, non-root, labels) — and a policy forbidding downgrade of the PSA labels | Pod Security Standards; CIS |
| Network isolation | Cilium identity-based policy; default-deny per namespace (with explicit CoreDNS egress) + cluster-wide backstop; host-firewall for hostNetwork | NIST 800-207 ZT; NetworkPolicy |
| Zero-trust transit | Cilium transparent encryption (WireGuard/IPsec) + L7 policy — implemented, not “optional” | NIST 800-207; 800-204 mTLS |
| Supply chain | Signed images (cosign) + SBOM + SLSA provenance, enforced at admission | SLSA v1.0; NIST SSDF |
| Runtime | Tetragon/Falco runtime detection; Trivy Operator in-cluster CVE | NIST 800-190 |
| Edge | WAF (Coraza/ModSecurity) + rate-limiting for internet-facing services | OWASP Top 10; NIST 800-204 |
| Identity | Keycloak OIDC/SAML, groups→RBAC, MFA (AAL2) on admin groups | OIDC Core; NIST 800-63B |
Tenancy honesty (state it). A namespace is not a hard security boundary — a shared kernel/node
means a container escape can reach other tenants. For hostile-tenant isolation we use vCluster or
per-tenant node pools, and we document the escape surface (privileged, hostPath, hostPID/IPC/Network,
nodes/proxy, DaemonSet node access) the guardrails close.
6. Standards & compliance references
Section titled “6. Standards & compliance references”| Standard | What it covers in this bid |
|---|---|
| CNCF Certified Kubernetes | Open, portable, vendor-neutral API conformance (Sonobuoy evidence) — anti-lock-in |
| CIS Kubernetes Benchmark | Control-plane/node/policy hardening, machine-verified (kube-bench), version-matched |
| NSA/CISA Kubernetes Hardening Guide v1.2 | Architectural hardening: network separation, authn/authz, logging, upgrades |
| Kubernetes Pod Security Standards | Privileged/baseline/restricted profiles as the in-tree workload floor |
| NIST SP 800-190 | Container security: image, registry, orchestrator, container, host countermeasures |
| NIST SP 800-204 / 204A / 204B | Microservices, service-mesh, API security: mTLS ZT, gateway policy, segmentation |
| NIST SP 800-218 (SSDF v1.1) | DevSecOps practice mapping (PO/PS/PW/RV) |
| NIST SP 800-207 | Zero-trust architecture (identity-based policy, mTLS) |
| SLSA v1.0 + in-toto | Supply-chain integrity: signed artifacts, build provenance |
| Sigstore cosign / CycloneDX / SPDX | Keyless image + SBOM signing + transparency (Rekor) |
| ISO/IEC 27001:2022 (+27017/27018) | Certified ISMS; cloud-security controls; PII protection |
| ISO/IEC 25010:2023 (SQuaRE) | Neutral vocabulary for measurable NFRs (§7) |
| OWASP Top 10 / ASVS / DSOMM | App-sec verification + DevSecOps maturity backing the pipeline gates |
| OpenGitOps v1.0 | Declarative, versioned, pulled, continuously-reconciled delivery |
| DORA / Accelerate | Delivery-performance metrics committed in the bid |
| OIDC Core 1.0 / SAML 2.0 / NIST 800-63B | Federated SSO, groups→RBAC, MFA across the API and every UI |
| World Bank Procurement Framework / SPD (Information Systems) + STEP | The procurement instrument, two-envelope structure, evaluation, STEP workflow |
| Data protection (GDPR / national law) + WCAG 2.2 | Data sovereignty/residency; accessibility for any citizen-facing UI |
7. Requirement Traceability Matrix & measurable NFRs (the spine)
Section titled “7. Requirement Traceability Matrix & measurable NFRs (the spine)”Every non-functional requirement → the component that meets it → the standard → the numeric target → the evidence artefact (automated where possible). This is where a World Bank technical evaluation is scored.
| # | NFR (ISO 25010 characteristic) | Target (calibrate per tender) | Delivered by | Standard | Evidence artefact |
|---|---|---|---|---|---|
| A1 | Availability (reliability) | Platform control-plane 99.9–99.95 %/month at the API VIP; app-tier per SLA. Honest for single-site on-prem — not five-nines | 3 CP + API VIP; HA layers | SRE SLO | SLO dashboard + burn-rate; uptime report |
| A2 | API latency (performance) | apiserver read p99 ≤ 1 s; scheduling latency p99 ≤ target | HA control plane, etcd on NVMe | SRE | VictoriaMetrics SLO dashboard |
| A3 | Fault tolerance | Tolerate loss of 1 control-plane and 1 worker with no service loss | odd etcd quorum, topology spread, PDBs | K8s HA topology | Node-drain/failover drill report |
| R1 | Recoverability — data (RPO) | In-cluster PG RPO ≤ 5 min; external system-of-record per its Patroni design (RPO=0 option) | CloudNativePG WAL archiving / external Patroni | — | PITR drill log |
| R2 | Recoverability — time (RTO) | Automatic DB failover < 30 s; platform DR-restore RTO stated per tier (etcd/Longhorn/Vault/Keycloak) | operators + platform DR runbook | ISO 27031 | Timed DR game-day report |
| R3 | Backup integrity | Backup success ≥ 99 %; restore tested monthly; off-site immutable copies (3-2-1-1-0) | Velero + etcd snapshots + operator backups | ISO 27031 | Restore-test reports; Object-Lock config |
| S1 | Authentication | 100 % SSO via Keycloak; MFA on admin; 0 shared local passwords in daily use | Keycloak OIDC everywhere | NIST 800-63B AAL2 | Auth config review; Keycloak event logs |
| S2 | Hardening | CIS Kubernetes Benchmark ≥ target score; drift re-scan cadence | kube-bench, PSA, Kyverno | CIS | kube-bench PASS/FAIL report |
| S3 | Supply chain | 100 % of prod images signed + SBOM’d; admission blocks unsigned; fixable CRITICAL/HIGH = 0 at release | cosign + Kyverno verifyImages + Trivy | SLSA v1; SSDF | Signed digests, SBOMs, provenance, scan gates |
| S4 | Secrets | 0 plaintext secrets in Git/config; etcd secrets encrypted; rotation interval defined | Vault/OpenBao + VSO; etcd encryption | NIST 800-57 | gitleaks-clean; EncryptionConfiguration; audit log |
| S5 | Network isolation | Default-deny in 100 % of tenant namespaces; only authorised east-west flows | Cilium policy + Kyverno generate | NIST 800-207 | Policy coverage report; Hubble flows |
| M1 | Maintainability | 100 % config as IaC/GitOps; zero undocumented drift; minor patch ≤ 30 days of release | ArgoCD, IaC | OpenGitOps; SSDF | Git history; drift = 0 dashboard |
| M2 | Patch SLA | Critical CVE remediated ≤ 14 days; VEX-triaged | Trivy Operator + patch pipeline | NIST 800-190 | CVE dashboard + VEX records |
| O1 | Observability | MTTD ≤ 2 min; dead-man’s-switch green; alert coverage of all critical signals | VictoriaMetrics stack | SRE | Alert inventory; Watchdog heartbeat |
| C1 | Capacity | Stated pod/node/tenant limits; CPU/IOPS peak < 70 % with headroom; storage alert 75/85 % | sizing model + monitoring | ISO 25010 | Capacity forecast + load-test results |
| P1 | Performance/throughput | Meet stated req/s and p99 latency under representative load | tuned platform + pooling | ISO 25010 | k6/Locust load-test report with thresholds |
| PO1 | Portability / anti-lock-in | CNCF-conformant; 100 % open-source (with the OpenBao/Valkey/SeaweedFS swaps); portable across substrates | open stack | CNCF conformance | Sonobuoy report; licence column (§2) |
| L1 | Licence compliance | Every component OSI-approved or with a stated compliant swap; no EOL on the critical path | §2 licence column | open-source policy | §2 catalogue as evidence |
| G1 | Data sovereignty / privacy | Data residency per national law/GDPR; documented retention vs erasure | on-prem + policy | GDPR; national law | DPIA; residency statement |
| G2 | Accessibility | Citizen-facing UIs meet WCAG 2.2 AA | app layer | WCAG 2.2 | Accessibility audit |
Evidence is automated wherever possible: Sonobuoy (conformance), kube-bench (CIS score), Trivy + Syft + cosign (supply chain), k6/Locust (performance thresholds), SLO dashboards and timed drill reports (availability/DR). A claim without a named artefact is not a claim we make.
8. Non-technical envelope (checklist — assemble separately)
Section titled “8. Non-technical envelope (checklist — assemble separately)”A World Bank IS bid is scored on more than technology. Ensure the full bid also includes: implementation methodology & work plan (with a realistic timeline and milestones), staffing plan & CVs (certified Kubernetes engineers), past performance / references, the SLA & support model (severity matrix, coverage, response/resolution), training & knowledge-transfer / handover, warranty & defect-liability, risk register & mitigation, and the financial proposal — kept in the correct envelope per the two-envelope evaluation.
Companion engineering guide (the “how”, with commands & scripts):
[[Kubernetes-Platform-Production-Install-Guide]]. Grounded in the team’s real clusters (docs/K8S-U2/,
docs/CG-Stage/) and a 2026-07 multi-agent best-practice research pass with an adversarial completeness
review. Keep targets honest and evidence-backed — that is what wins technical evaluations.
Last revised 2026-07-25.