Secrets, Network, Admission, and Supply-Chain Guardrails
Make unsafe workloads fail closed before they can reach customer data or production compute.
System map · Day 27
Whole-system design
Five stable layers. Today's work is expanded and linked; the rest stays in context.
Product and authority
Covered — People and product entry points · HelixWorks control plane · Generated application plane
Identity and policy
Design target · not proved
Workload identity is declared, but external-secret delivery and signature-verifying admission remain launch-blocking gaps.
Delivery and desired state
Covered — CI and immutable artifacts · Argo CD reconciliation
Git desired state
Source-backed today
Keeps secret references, default-deny network policy, resource bounds, and supply-chain declarations reviewable.
Cloud and orchestration
Covered — Terraform and AWS APIs · Accounts, VPC, DNS, and private paths
Kubernetes or EKS control plane
Source-backed today
Admission and workload controllers reject or reconcile objects before unsafe processes can run.
Compute and traffic
Covered — Worker compute · Platform service workloadsAhead — Ambient mesh data plane
Generated app workloads
Source-backed today
Declares non-root identities, probes, bounded resources, and restricted connectivity in the workload base.
Storage and evidence
Covered — Infrastructure state · Cluster desired and live state · Product data and artifacts · Evidence and observability
The enterprise problem and today’s slice
Enterprise problem: A digest-pinned image can still expose secrets, call arbitrary networks, run with dangerous privileges, or originate from an untrusted build. Whole-course context: Promotion proves exact image identity only after real digests exist; today audits what the repository actually constrains. Today’s slice: The base declares non-root containers, dropped capabilities, read-only filesystems, resource limits, service accounts, and NetworkPolicy; Terraform declares Pod Identity and Secrets Manager scope. No signature-verifying admission controller is installed. End-of-day evidence: Server dry-run and authorization checks can prove declared controls, while unsigned-image denial remains explicitly unproven. Still unsolved: Launch is blocked until signature admission and live network/secret positive and negative tests exist.
Customer outcome and implementation focus
The customer outcome is a reviewable secrets, network, admission, and supply-chain guardrails change, not a collection of requirements. This day starts with the implementation boundary, then uses the command or manifest below to produce positive, denied, and recovery evidence.
Components in focus
External secret/admission controllers, network policy engine, signature verifier, and Argo CD; controller and application pods; secret manager, Git/registry attestations, Kubernetes etcd, and audit storage; cache: not involved.
This map names the implementation boundary for this day. The service or controller changes only the state it owns; runtime and audit evidence let the operator distinguish a declared change from an effective one.
Enforce secrets, network, admission, and supply-chain gates
Verify policy before production sync
Rendering catches missing declarations but cannot prove live admission or packets, so combine local render with server-side dry-run in the explicit production context. The repository declares Pod Identity associations in infra/modules/environment, pod hardening and Services in the base, NetworkPolicy in gitops/apps/forge/base/network-policy.yaml, and required release policy in the production overlay; it does not yet install a signature-verifying admission controller, so signature admission remains a launch gap rather than a passed control. AWS requires the Pod Identity Agent for Pod Identity associations on ordinary EKS clusters (EKS Pod Identity); the module installs that addon.
: "${AWS_PROFILE:?set the approved AWS profile}" "${AWS_REGION:?set the intended AWS region}" "${EXPECTED_ACCOUNT_ID:?set the intended 12-digit AWS account}"
actual_account="$(aws --profile "$AWS_PROFILE" --region "$AWS_REGION" sts get-caller-identity --query Account --output text)"
[ "$actual_account" = "$EXPECTED_ACCOUNT_ID" ] || { echo "AWS account mismatch" >&2; exit 1; }
kubectl kustomize gitops/apps/forge/overlays/prod >/tmp/forge-prod.yaml
aws --profile "$AWS_PROFILE" --region "$AWS_REGION" eks update-kubeconfig --name helixworks-forge-prod --alias helixworks-forge-prod
kubectl --context helixworks-forge-prod apply --server-side --dry-run=server -f /tmp/forge-prod.yaml
kubectl --context helixworks-forge-prod -n helixworks-forge auth can-i get secret --as=system:serviceaccount:helixworks-forge:generator
kubectl --context helixworks-forge-prod -n helixworks-forge get networkpolicy,serviceaccount
Key takeaways
Production guardrails form a chain of independent controls.
- Machine authority precedes optional delegated user authority; neither inherits the other.
- Default-deny needs explicit positive paths and negative proof.
- Admission must verify immutable artifact and pod behavior before scheduling.
Checklist
The runtime is guarded only when failure is closed and observable.
- [ ] Secret values never enter Git or evidence
- [ ] Service identities are environment and responsibility scoped
- [ ] Network policy allows required paths and denies an unapproved path
- [ ] Signature-verifying admission is installed and an unsigned image is denied; until then launch stays blocked