Kustomize Reference

Overview

The k8s/ directory provides a Helm-free alternative for deploying claude-in-a-box using plain kubectl. It follows the Kustomize base/overlays directory convention for organizing manifests, though it uses direct kubectl apply rather than the kustomize build CLI -- there are no kustomization.yaml files.

The base/ directory contains 4 numbered manifests applied in order, and overlays/ contains optional additive patches that extend the base configuration. The Helm chart remains the primary deployment method; the k8s/ directory is suited for quick local testing and CI pipelines where Helm is not available.

Directory Structure

Directory Structure

The k8s/ directory tree with base resources and overlays.

k8s/ base/ Applied with kubectl apply -f k8s/base/ 01-serviceaccount.yaml 02-rbac-reader.yaml 03-networkpolicy.yaml 04-statefulset.yaml overlays/ Optional, applied separately rbac-operator.yaml No kustomization.yaml -- uses plain kubectl apply

Base Resources

The four base manifests are numbered to enforce apply order. Together they create a minimal, secure deployment of claude-in-a-box with read-only cluster access.

File Kind Description
01-serviceaccount.yaml ServiceAccount Dedicated identity for claude-agent pod, automounts API token
02-rbac-reader.yaml ClusterRole + ClusterRoleBinding Read-only access (get/list/watch) to 14 resource types across 4 API groups
03-networkpolicy.yaml NetworkPolicy Egress-only policy: DNS (53), HTTPS (443), K8s API (6443). All ingress blocked
04-statefulset.yaml Service + StatefulSet Headless Service for DNS identity, StatefulSet with PVC, non-root (UID 10000), probes

Overlay: Operator RBAC

The operator overlay is additive -- it grants elevated permissions without removing the base reader role. It lives in overlays/ so it is not applied by default when deploying with kubectl apply -f k8s/base/. Apply or revoke it manually as needed.

Resource Verb Purpose
pods delete Force-restart pods via StatefulSet controller recreation
pods/exec create Interactive debugging inside running containers
deployments, statefulsets update, patch Rollout restarts and spec modifications

Deployment Workflow

Two deployment paths are available. The Helm chart is recommended for production and multi-environment use. The k8s/ directory provides a simpler path for quick testing and CI.

Deployment Workflow

Decision between Helm and kubectl paths, with optional operator overlay.

Deployment method? Helm helm install kubectl kubectl apply -f k8s/base/ optional kubectl apply -f k8s/overlays/rbac-operator.yaml Helm chart is the primary deployment method

Usage

Deploy with base resources

kubectl apply (base)
$ kubectl apply -f k8s/base/

Add operator permissions

kubectl apply (operator overlay)
$ kubectl apply -f k8s/overlays/rbac-operator.yaml

Revoke operator permissions

kubectl delete (operator overlay)
$ kubectl delete -f k8s/overlays/rbac-operator.yaml

Helm vs kubectl

Both deployment methods produce equivalent base infrastructure. The choice depends on your operational needs.

Feature Helm Chart kubectl (k8s/)
Templating Values-driven (values.yaml) Static manifests
Security profiles 3 profiles via values overlays Base + manual operator overlay
Lifecycle helm install/upgrade/rollback kubectl apply/delete
Best for Production, multi-env Quick local testing, CI