KubernetesSecretProvider

Status

Implemented as the first concrete production-shaped SecretProvider.

Related Requirements

• SRS references: secure integration credentials and tenant isolation.
• Client response references: platform-managed per-tenant keys are Phase 1; BYOK is Phase 2.
• ADR references: SecretProvider seam and AWS deployment strategy.
• Task board references: OP-D031, OP-022, OP-025.

Problem Statement

Integration delivery needs signing material at worker execution time without returning or logging secrets, and without coupling the app directly to AWS, Azure, GCP, or Vault APIs.

Architectural Intent

Cloud-specific secret sync happens outside the application. OneProtect reads Kubernetes Secrets through KubernetesSecretProvider, while External Secrets Operator, CSI, Vault Agent, or cloud-native sync can populate those secrets.

What Was Implemented

• KubernetesSecretProvider behind the SecretProvider interface.
• Canonical refs:
  • k8s://namespace/secret-name/key
  • k8s://secret-name/key when namespace is configured centrally.
• Tenant-aware and purpose-aware ref validation.
• Worker-time HMAC signing secret resolution.
• Fail-closed behavior for invalid refs, missing config, missing secret/key, tenant/purpose mismatch, and provider errors.
• Helm namespace-scoped read-only Secret RBAC.

Components Involved

• services/common/secret_provider.py
• poc/ingest_api/integration_delivery_service.py
• deploy/helm/oneprotect/templates/worker-secret-rbac.yaml
• Helm values for secret provider mode and secret resource names.

APIs / Events / Schemas

• Integration credential APIs store and return only redacted metadata.
• No API returns secret values.
• Delivery attempts store failure state, not secret material.

Deployment Notes

AWS dev and production-shaped Kubernetes deployments should use ONEPROTECT_SECRET_PROVIDER=kubernetes. The local provider remains local/dev/test only. Exact Secret resourceNames must be configured per environment.

Security / Tenant Isolation

• Secret values are not in API responses, logs, audit payloads, UI props, or docs examples.
• Kubernetes Secret access is namespace-scoped and read-only.
• No silent fallback to local provider occurs in Kubernetes mode.
• Errors are safe and do not include secret values.

Validation Steps

UI Validation

1. Open /console/integrations.
2. Confirm credential status shows configured/redacted metadata only.
3. Confirm no raw secret refs or values are displayed.

API Validation

Fetch integration destination/credential reads and confirm credential values are redacted or absent.

Smoke Validation

make test
make test-delivery-retry
make helm-template

Known Limitations

• External Secrets Operator or CSI manifests are not finalized.
• Exact production Secret resource names are environment-specific.
• Dual-secret rollover is future work.
• Direct AWS/Azure/GCP/Vault app providers are optional future work, not Phase 1 default.

Follow-Up Work

• Add External Secrets sync manifests after target cluster posture is approved.
• Add dual-secret rollover model.
• Implement runtime KMS/S3 use of ADR-0018 key refs when object storage is scoped.

Acceptance Criteria Mapping

Acceptance criterion	Evidence
Concrete SecretProvider exists	KubernetesSecretProvider
Secret refs are validated	Provider parsing/validation tests
Secrets do not leak	Integration credential tests
Helm RBAC is least privilege	Worker Secret RBAC template