Agent Injector
Admission adds Agent containers and shared volumes.
Chapter 14 of 16 · Application/workload user · orders-api
Choose Kubernetes delivery by lifecycle ownership, update semantics, coupling, and failure behavior.
Chapter 13 complete and familiarity with pod volumes and application reload behavior.
The team selects one Kubernetes delivery model with explicit auth, renewal, delivery, and reload owners.
| Owner | Consumer-facing responsibility |
|---|---|
| You own | States the consumer contract and proves reload and degraded behavior. |
| Platform team owns | Owns runtime identity, integration components, rollout, and operational health. |
| Vault owns | Owns server-side trust, policy, engines, audit, and Vault service health. |
Admission adds Agent containers and shared volumes.
Mounts data through the Secrets Store CSI Driver lifecycle.
Reconciles Vault data into Kubernetes resources.
Application owns login, renewal, retries, cache, and telemetry.
cd learn-vault/labs/kubernetes-delivery
python3 decision_matrix.py --requirements requirements.json
python3 validate_examples.py
Optional approved context: client-side kubectl dry-run can supplement the offline checks, but it may still contact the current API server for discovery or schema validation.
| Symptom | Integration is healthy but the pod uses stale material. |
|---|---|
| Likely causes | Volume updated without reload, template stopped, synced Secret not remounted, or cache too old. |
| Inspect safely | Check component status, inode, mtime, resource version, generation, and reload result. |
| Do not print | Volume contents, Secret data, sink token, node log payloads, or API responses. |
Break it: Assume an updated CSI volume automatically reloads the process.
Fix it: Add and verify an application watcher or choose an integration with the required template contract.
Escalate with time, endpoint, auth path, role, mount, namespace when relevant, status code, request ID, and sanitized error class. Never attach a credential or response body.
Platform-supplied external configuration is represented by reserved example inputs; this lab applies nothing.
$0; offline validation with no external resource changes
Use the tracked example and offline validator; real GitLab, AWS, and Kubernetes configuration remains platform-owned.
Run the Lockbox decision matrix and statically validate minimal Injector and CSI examples.
cd learn-vault/labs/kubernetes-delivery
python3 decision_matrix.py --requirements requirements.json | tee ../../.runtime/delivery-decision.txt
grep -q '^selected: agent-injector$' ../../.runtime/delivery-decision.txt
python3 validate_examples.py
rm -f ../../.runtime/delivery-decision.txt
Complete every item in the Verify section using metadata-only evidence; no secret value appears in terminal output or tracked files.
Use the Failure drill and Break it / fix it evidence fields. Stop before broadening policy, weakening identity or TLS checks, or copying secret-bearing diagnostics.
Remove the runtime decision output. Offline checks create no cluster resources.
Lockbox selects Agent Injector for file templates plus app reload; CSI remains valid for volume-native consumers.
Direct API.
No. The application must detect and accept updates.
Kubernetes API, etcd, RBAC, controllers, backups, and watchers.
Agent owns auth and templates while the app owns a small reload contract.
Choose integration by who owns every lifecycle step and how component failure reaches the application.