Skip to content

Define a secret-free restricted Kubernetes manifest contract for official plugins #101

Description

@AntoineToussaint

Problem

The shared deployment renderer accepts arbitrary plugin templates and currently passes a populated SecretMap into generated Kustomize overlays. Official plugins then render Kubernetes Secret manifests containing those values. That is usable only for a tightly scoped ephemeral local apply; it is unsafe as GitOps output.

The plugin baseline is also inconsistent. service-go, service-minio, service-envoy, service-neo4j, and service-temporal lack some or all of the restricted pod security context, ServiceAccount-token disablement, probes, resource bounds, and graceful lifecycle settings already present in newer plugins.

Acceptance criteria

  • Define versioned output profiles for ephemeral local apply and promotable GitOps render.
  • The GitOps profile cannot receive secret bytes and cannot emit Secret data/stringData; it emits only approved external-secret/reference contracts.
  • Add a shared conformance validator for official plugin output covering:
    • digest-pinned images for promotable output;
    • automountServiceAccountToken: false;
    • restricted pod/container security contexts and dropped capabilities;
    • requests/limits plus startup/readiness/liveness behavior where applicable;
    • no privileged/host access, unsafe service exposure, unowned namespace/RBAC/cluster resources, or unresolved placeholders;
    • valid Kustomize rendering and server-side schema/admission checks.
  • Extend agents/testing so every official service plugin runs the same positive and hostile contract suite.
  • Migrate all official plugins, explicitly including service-go, service-go-grpc, service-nextjs, service-postgres, service-redis, service-s3, service-minio, service-vault, service-envoy, service-neo4j, and service-temporal.
  • Keep provider-specific managed-service adapters outside generic service plugins.
  • Bind the contract version and validation result into deployment output so the CLI can reject non-promotable trees.

This is a prerequisite for committing Codefly-generated manifests to a production GitOps repository.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions