CRD Reference

All CRDs use apiVersion: lattice.dev/v1alpha1.

---

LatticeService

Kind: LatticeService Introduced: Chapter 1 (Section 1.4), detailed in Chapter 2 (Section 2.2), designed in Chapter 4 (Section 4.8) Audience: Application developers Purpose: Declares a long-running service. The platform derives Deployment, Service, CiliumNetworkPolicy, AuthorizationPolicy, ExternalSecret, PDB, VMServiceScrape, and KEDA ScaledObject from this single spec.

Complete Spec Example

apiVersion: lattice.dev/v1alpha1
kind: LatticeService
metadata:
  name: checkout
  namespace: commerce
spec:
  replicas: 3
  autoscaling:                          # optional; Chapter 10
    minReplicas: 2
    maxReplicas: 10
    metrics:
      - type: cpu
        target: 70
  workload:
    containers:
      api:
        image: registry.example.com/checkout@sha256:a3f2b7c91e4d0856f3a29b8c74d5e1609fa2c83b47e6d1095a8f23bc4de76801
        command: ["/app/server"]         # optional
        args: ["--port=8080"]            # optional
        variables:
          LOG_LEVEL: info
          DATABASE_URL: "postgres://app:${resources.orders-db.password}@db:5432/orders"
        files:                           # optional; Chapter 9
          /etc/app/config.yaml:
            content: |
              database:
                host: db.internal
                password: "${resources.orders-db.password}"
        resources:
          requests:
            cpu: 500m
            memory: 512Mi
          limits:
            cpu: 500m
            memory: 512Mi
        livenessProbe:                   # optional; platform defaults to HTTP GET /healthz
          httpGet:
            path: /healthz
            port: 8080
        readinessProbe:                  # optional; platform defaults to HTTP GET /readyz
          httpGet:
            path: /readyz
            port: 8080
    service:                             # optional
      ports:
        http:
          port: 8080
          protocol: TCP
    resources:
      payments:
        type: service
        direction: outbound
      orders-db:
        type: secret
        params:
          keys: [password]
      stripe:
        type: secret
        params:
          keys: [api-key]
      s3-endpoint:                       # external-service example; Chapter 13
        type: external-service
        direction: outbound
        params:
          endpoints:
            s3: https://s3.us-east-1.amazonaws.com
      shared-data:                       # volume example; Chapter 4 prose
        type: volume
        params:
          size: 10Gi
          accessMode: ReadWriteOnce
  observability:                         # optional; Chapter 19 prose
    scrapeInterval: 30s
  ingress: {}                            # optional; Chapter 4 prose (Section 4.9)
  deploy: {}                             # optional; deployment strategy; Chapter 4 prose (Section 4.9)

Status Example

status:
  phase: Ready                           # Pending | Compiling | Ready | Failed | Deleting
  observedGeneration: 3
  conditions:
    - type: ImageVerified
      status: "True"
      reason: CosignVerified
      message: "Image signed by key production-signing-key"
    - type: PolicyAuthorized
      status: "True"
    - type: SecretsResolved
      status: "True"
    - type: Compiled
      status: "True"
      message: "8 resources compiled"
  compiledResources:
    count: 8
    types:
      Deployment: 1
      Service: 1
      CiliumNetworkPolicy: 2
      AuthorizationPolicy: 2
      ExternalSecret: 1
      VMServiceScrape: 1

Field Reference

Top-level spec fields

Field	Type	Required	Description	Default
replicas	integer	Yes	Number of pod replicas. Min 1, max 100.	None (required)
autoscaling	object	No	Autoscaling configuration. When present, the pipeline derives a KEDA ScaledObject. Mutual interaction with replicas (used as initial count).	None
autoscaling.minReplicas	integer	Yes (within block)	Minimum replica count for autoscaler.	None
autoscaling.maxReplicas	integer	Yes (within block)	Maximum replica count for autoscaler. Must be >= replicas.	None
autoscaling.metrics	list	Yes (within block)	Scaling triggers. Each entry has type (cpu, memory, or custom metric name) and target (numeric threshold).	None
workload	object	Yes	Container definitions, service ports, and resource dependencies.	None
observability	object	No	Override default observability settings (e.g., scrape interval). Described in Chapter 19 prose.	Platform defaults (30s scrape interval)
ingress	object	No	Ingress configuration. Mentioned in Chapter 4 (Section 4.9) as a LatticeService-specific field.	None
deploy	object	No	Deployment strategy configuration. Mentioned in Chapter 4 (Section 4.9) as a LatticeService-specific field.	None

workload.containers.<name> fields

Field	Type	Required	Description	Default
image	string	Yes	Container image reference. Must be a digest (@sha256:...), not a tag. Validated by admission webhook.	None (required)
command	list of strings	No	Override the image’s default entrypoint. Fewer than 5% of services use this.	Image default
args	list of strings	No	Arguments to the entrypoint.	Image default
variables	map (string -> string)	No	Environment variables. Supports ${resources.<name>.<key>} interpolation for secret references.	None
files	map (path -> object)	No	File mounts. Each key is a mount path; value has content (string with ${resources.*} interpolation). Secrets consumed via files do not cause pod restarts on rotation.	None
resources.requests.cpu	string	Yes	CPU request in Kubernetes quantity format.	None (required)
resources.requests.memory	string	Yes	Memory request in Kubernetes quantity format.	None (required)
resources.limits.cpu	string	Yes	CPU limit. Convention: set equal to requests for Guaranteed QoS.	None (required)
resources.limits.memory	string	Yes	Memory limit. Convention: set equal to requests for Guaranteed QoS.	None (required)
livenessProbe	object	No	Kubernetes-format liveness probe.	HTTP GET /healthz on primary port
readinessProbe	object	No	Kubernetes-format readiness probe.	HTTP GET /readyz on primary port

workload.service fields

Field	Type	Required	Description	Default
ports	map (name -> object)	No	Named service ports. Each entry has port (integer) and protocol (enum: HTTP, GRPC, TCP). Port name carries semantic meaning for mesh routing.	Inferred from container or defaults to 8080

workload.resources.<name> fields

Field	Type	Required	Description	Default
type	enum	Yes	Resource type: service, secret, volume, external-service, gpu.	None (required)
direction	enum	Conditional	Required for service and external-service types: inbound, outbound, or both.	None
params	object	Conditional	Type-specific parameters. See below.	None
params.keys	list of strings	For secret	Which secret keys to sync. Omit for bulk extraction (all keys).	None
params.endpoints	map (name -> URL)	For external-service	Named external endpoints. Cedar AccessExternalEndpoint authorizes each.	None
params.size	string	For volume	Volume size in Kubernetes quantity format.	None
params.accessMode	string	For volume	Volume access mode (e.g., ReadWriteOnce).	None
params.secretType	string	For secret	Override Kubernetes Secret type (e.g., kubernetes.io/dockerconfigjson for image pull secrets).	Opaque
params.count	integer	For gpu	Number of GPUs requested.	None
params.memory	string	For gpu	Minimum GPU memory; used as node selector hint (e.g., A100-80GB vs A100-40GB).	None

---

LatticeCluster

Kind: LatticeCluster Introduced: Chapter 5 (Section 5.2) Audience: Platform operators Purpose: Declares a Kubernetes cluster. The platform derives CAPI resources (Cluster, MachineDeployment, KubeadmControlPlane, etc.) and bootstraps all platform prerequisites (CNI, mesh, cert-manager, ESO, platform operator).

Complete Spec Example

apiVersion: lattice.dev/v1alpha1
kind: LatticeCluster
metadata:
  name: backend
  labels:
    lattice.dev/environment: homelab
    lattice.dev/role: backend
spec:
  latticeImage: "ghcr.io/evan-hines-js/lattice:latest"
  providerRef: proxmox
  provider:
    kubernetes:
      version: "1.32.0"
      bootstrap: kubeadm
    config:
      proxmox:
        sourceNode: "poweredge-lg"
        templateId: 9000
        controlPlaneEndpoint: "10.0.1.110"
        bridge: "vmbr1"
        ipv4Pool:
          range: "10.0.1.111-120/24"
          gateway: "10.0.1.1"
  nodes:
    controlPlane:
      replicas: 1
      instanceType:
        cores: 4
        memoryGib: 16
        diskGib: 50
    workerPools:
      default:
        replicas: 3
        instanceType:
          cores: 12
          memoryGib: 64
          diskGib: 250
  services: true
  monitoring:
    enabled: false
  backups:
    enabled: false
  parentConfig:                          # optional; for clusters that accept child connections
    grpcPort: 50051
    bootstrapPort: 8443
    service:
      type: LoadBalancer

Status Phases

Pending -> Provisioning -> Bootstrapping -> Ready

Also: Scaling, Upgrading, Deleting

Conditions during bootstrapping report each component: CNI, CertManager, Mesh, SecretSync, Metrics, PlatformOperator.

Field Reference

Top-level spec fields

Field	Type	Required	Description	Default
latticeImage	string	Yes	Container image for the Lattice platform operator.	None (required)
providerRef	string	Yes	Name of an InfraProvider CRD holding provider credentials.	None (required)
provider.kubernetes.version	string	Yes	Kubernetes version (e.g., "1.32.0").	None (required)
provider.kubernetes.bootstrap	string	Yes	Bootstrap method (e.g., kubeadm).	None (required)
provider.config	object	Yes	Provider-specific infrastructure configuration. Key is provider name (proxmox, docker, aws). Contents vary by provider.	None (required)
services	boolean	No	Enable the platform operator for workload CRDs on this cluster.	false
monitoring.enabled	boolean	No	Install monitoring stack (VMAgent/Prometheus agent).	false
backups.enabled	boolean	No	Enable backup infrastructure.	false

nodes fields

Field	Type	Required	Description	Default
controlPlane.replicas	integer	Yes	Number of control plane nodes. Typically 1 (dev) or 3 (production).	None (required)
controlPlane.instanceType.cores	integer	Yes	CPU cores per control plane node.	None (required)
controlPlane.instanceType.memoryGib	integer	Yes	Memory in GiB per control plane node.	None (required)
controlPlane.instanceType.diskGib	integer	Yes	Disk in GiB per control plane node.	None (required)
workerPools.<name>.replicas	integer	Yes	Number of worker nodes in this pool.	None (required)
workerPools.<name>.instanceType.cores	integer	Yes	CPU cores per worker node.	None (required)
workerPools.<name>.instanceType.memoryGib	integer	Yes	Memory in GiB per worker node.	None (required)
workerPools.<name>.instanceType.diskGib	integer	Yes	Disk in GiB per worker node.	None (required)

parentConfig fields

Field	Type	Required	Description	Default
grpcPort	integer	Yes (within block)	Port for the gRPC cell endpoint that child clusters connect to.	None
bootstrapPort	integer	Yes (within block)	Port for the bootstrap webhook.	None
service.type	string	Yes (within block)	Kubernetes Service type for exposing the endpoint (e.g., LoadBalancer).	None

Proxmox provider config fields

The example above uses Proxmox, but provider.config accepts any supported provider key (proxmox, docker, aws). Docker and AWS provider configurations follow the same structural pattern — a provider-keyed object under provider.config — but the fields within each are provider-specific and vary. See the respective provider guides for field-level details.

Field	Type	Required	Description	Default
sourceNode	string	Yes	Proxmox node to clone VMs from.	None
templateId	integer	Yes	VM template ID for cloning.	None
controlPlaneEndpoint	string	Yes	Static IP for the Kubernetes API server.	None
bridge	string	Yes	Proxmox network bridge name.	None
ipv4Pool.range	string	Yes	IP range with CIDR for worker nodes.	None
ipv4Pool.gateway	string	Yes	Default gateway IP.	None

---

LatticeJob

Kind: LatticeJob Introduced: Chapter 16 (Section 16.3), GPU examples in Chapter 17 (Section 17.4) Audience: Application developers, ML engineers Purpose: Declares a batch workload with gang scheduling support. The platform derives Volcano VCJob, PodGroup, ExternalSecrets, LatticeMeshMember for network policies, and TracingPolicyNamespaced for Tetragon enforcement.

Complete Spec Example

apiVersion: lattice.dev/v1alpha1
kind: LatticeJob
metadata:
  name: training-run-42
  namespace: ml
spec:
  queue: ml-training
  minAvailable: 8
  schedule: "0 2 * * *"                     # optional; cron schedule (Chapter 16, Section 16.5)
  concurrencyPolicy: Forbid                  # optional; for cron jobs
  successfulJobsHistoryLimit: 3              # optional; for cron jobs
  failedJobsHistoryLimit: 1                  # optional; for cron jobs
  tasks:
    workers:
      replicas: 8
      workload:
        containers:
          trainer:
            image: registry.example.com/trainer@sha256:def456
            variables:
              S3_BUCKET: "${resources.training-data.bucket}"
              WANDB_KEY: "${resources.wandb.api-key}"
            resources:
              requests:
                cpu: "4"
                memory: 32Gi
                nvidia.com/gpu: "1"
              limits:
                cpu: "4"
                memory: 32Gi
                nvidia.com/gpu: "1"
            security:                        # optional; requires OverrideSecurity Cedar gate
              runAsUser: 65534
              apparmorProfile: Unconfined
        resources:
          training-data:
            type: secret
            params:
              keys: [bucket, access-key, secret-key]
          wandb:
            type: secret
            params:
              keys: [api-key]
          s3-endpoint:
            type: external-service
            direction: outbound
            params:
              endpoints:
                s3: https://s3.us-east-1.amazonaws.com
      restartPolicy: OnFailure
  defaults:
    entryRuntime:
      imagePullSecrets:
        - default

Field Reference

Top-level spec fields

Field	Type	Required	Description	Default
queue	string	Yes	Volcano queue name for fair-share scheduling. Pipeline validates namespace is authorized for the queue.	None (required)
minAvailable	integer	Yes	Minimum number of pods that must be placed simultaneously (gang scheduling constraint). Maps to Volcano minMember.	None (required)
schedule	string	No	Cron expression for scheduled execution. When present, the pipeline derives a CronJob wrapping the VCJob.	None (one-shot)
concurrencyPolicy	enum	No	For cron jobs: Allow, Forbid, Replace. Prevents overlapping runs.	Allow
successfulJobsHistoryLimit	integer	No	For cron jobs: how many completed job records to retain.	Kubernetes default
failedJobsHistoryLimit	integer	No	For cron jobs: how many failed job records to retain.	Kubernetes default
tasks	map (name -> object)	Yes	Named task groups. Each group has its own replica count, workload spec, and restart policy.	None (required)
defaults	object	No	Shared defaults applied across all tasks.	None
defaults.entryRuntime.imagePullSecrets	list of strings	No	Image pull secret names injected into all task pods.	None
resources	map	No	Resource dependencies shared across all tasks. Same format as LatticeService workload.resources. Can also be specified per-task inside tasks.<name>.workload.resources.	None

tasks.<name> fields

Field	Type	Required	Description	Default
replicas	integer	Yes	Number of pods in this task group.	None (required)
workload	object	Yes	Container definitions and resource dependencies. Shares the same WorkloadSpec as LatticeService.	None (required)
restartPolicy	enum	No	Pod restart policy: OnFailure or Never.	OnFailure

Container security fields (requires OverrideSecurity Cedar gate)

Field	Type	Required	Description	Default
runAsUser	integer	No	UID to run the container as.	Platform-managed
apparmorProfile	string	No	AppArmor profile name or Unconfined.	Platform-managed

---

LatticeModel

Kind: LatticeModel Introduced: Chapter 18 (Section 18.2) Audience: ML engineers Purpose: Declares an inference endpoint with model lifecycle management. The platform derives multiple Deployments (one per role), model download init containers, role-specific KEDA ScaledObjects with GPU metrics, and inference routing configuration.

Complete Spec Example

apiVersion: lattice.dev/v1alpha1
kind: LatticeModel
metadata:
  name: qwen-8b
  namespace: serving
spec:
  modelSource:
    uri: "hf://Qwen/Qwen3-8B"
    cacheSize: "50Gi"
  defaults:
    entryWorkload:
      containers:
        main:
          image: registry.example.com/vllm@sha256:abc123
          variables:
            MODEL_NAME: "Qwen/Qwen3-8B"
          resources:
            requests:
              cpu: "4"
              memory: 16Gi
              nvidia.com/gpu: "1"
  roles:
    prefill:
      replicas: 2
    decode:
      replicas: 4
      autoscaling:
        max: 16
        metrics:
          - metric: gpu_kv_cache_usage
            target: 0.8
        behavior:
          scaleDown:
            stabilizationWindow: "10m"
  routing:
    inferenceEngine: vLLM
    model: "Qwen/Qwen3-8B"

Field Reference

Top-level spec fields

Field	Type	Required	Description	Default
modelSource.uri	string	Yes	Model artifact location. Supports hf:// (HuggingFace), s3://, gs:// (GCS). Pipeline generates an init container to download.	None (required)
modelSource.cacheSize	string	Yes	Size of the cache volume for model weights.	None (required)
defaults	object	No	Shared container and workload defaults applied to all roles.	None
defaults.entryWorkload	object	No	Default workload spec (containers, resources) inherited by each role unless overridden.	None
roles	map (name -> object)	Yes	Named inference roles (e.g., prefill, decode). Each role gets its own Deployment.	None (required)
routing	object	Yes	Inference-specific request routing configuration.	None (required)
routing.inferenceEngine	string	Yes	Inference engine (vLLM, SGLang). Determines API protocol.	None (required)
routing.model	string	Yes	Model identifier for the routing layer.	None (required)

roles.<name> fields

Field	Type	Required	Description	Default
replicas	integer	Yes	Base replica count for this role.	None (required)
autoscaling	object	No	Role-specific autoscaling.	None
autoscaling.max	integer	Yes (within block)	Maximum replicas.	None
autoscaling.metrics	list	Yes (within block)	Scaling triggers. metric is a custom metric name (e.g., gpu_kv_cache_usage); target is a numeric threshold.	None
autoscaling.behavior.scaleDown.stabilizationWindow	duration string	No	How long demand must stay low before scaling down. Inference endpoints use 10-15 minutes due to expensive cold starts.	"10m"

---

LatticePackage

Kind: LatticePackage Introduced: Chapter 11 (Section 11.3) Audience: Platform operators, team leads Status: Not yet implemented in the reference implementation. See the Implementation Roadmap. Purpose: Orchestrates Helm chart installation with platform secret resolution and Cedar authorization. The primary escape hatch for third-party software (Redis, Prometheus, NGINX) that does not fit the derivation pipeline.

Complete Spec Example

apiVersion: lattice.dev/v1alpha1
kind: LatticePackage
metadata:
  name: redis
  namespace: data
spec:
  chart:
    repo: oci://registry.example.com/charts
    name: redis
    version: 18.4.0
  values:
    replicas: 3
    auth:
      enabled: true
      password: "${resources.redis.auth-token}"
  resources:
    redis:
      type: secret
      params:
        keys: [auth-token]

Field Reference

Field	Type	Required	Description	Default
chart.repo	string	Yes	Chart repository URL. Must use HTTPS or OCI protocol. Validated by admission webhook against repository allowlist.	None (required)
chart.name	string	Yes	Helm chart name.	None (required)
chart.version	string	Yes	Exact chart version. Ranges and latest are rejected.	None (required)
values	object	No	Helm values to pass to the chart. Supports ${resources.<name>.<key>} interpolation for secrets.	None
resources	map	No	Resource dependencies. Same format as LatticeService workload.resources. Secrets are resolved through the platform’s routing paths and authorized by Cedar AccessSecret.	None

Admission Webhook Enforcements

• Chart repository must use HTTPS or OCI protocol.
• Target namespace must not be a system namespace (kube-system, istio-system, lattice-system).
• Chart version must be pinned (exact version, not a range).
• Repository must be on the approved allowlist.

What LatticePackage Does NOT Provide

• Compile-time authorization for the chart’s internal resources.
• Automatic observability wiring (depends on chart including ServiceMonitor).
• Image verification for images the chart pulls.
• Bilateral network agreements (requires a separate LatticeMeshMember).

---

LatticeMeshMember

Kind: LatticeMeshMember Introduced: Chapter 11 (Section 11.4), bilateral model detailed in Chapter 13 (Section 13.2) Audience: Platform operators, team leads Purpose: Brings non-derived workloads (Helm-installed packages, legacy systems) into the bilateral network agreement model. The mesh-member controller generates CiliumNetworkPolicies and AuthorizationPolicies based on declared ports and callers.

Complete Spec Example

apiVersion: lattice.dev/v1alpha1
kind: LatticeMeshMember
metadata:
  name: redis
  namespace: data
spec:
  target:
    selector:
      app: redis
  ports:
    - port: 6379
      name: redis
      peerAuth: Strict
  allowedCallers:
    - name: checkout
      namespace: commerce
    - name: inventory
      namespace: commerce
  dependencies: []

Field Reference

Field	Type	Required	Description	Default
target.selector	map (string -> string)	Yes	Label selector matching the pods this MeshMember describes.	None (required)
ports	list of objects	Yes	Ports exposed by the workload.	None (required)
ports[].port	integer	Yes	Port number.	None (required)
ports[].name	string	Yes	Port name (semantic meaning for mesh routing).	None (required)
ports[].peerAuth	enum	No	mTLS mode: Strict (require mTLS) or Permissive.	Strict
allowedCallers	list of objects	No	Services permitted to call this workload (inbound side of bilateral agreement).	[] (no callers)
allowedCallers[].name	string	Yes	Name of the calling service.	None (required)
allowedCallers[].namespace	string	Yes	Namespace of the calling service.	None (required)
dependencies	list	No	Outbound dependencies of this workload. Participates in bilateral agreements with other services/MeshMembers.	[]

Maintenance Notes

• MeshMembers are manually maintained. When the Helm chart version bumps and adds ports, the MeshMember must be updated.
• The compliance controller (Chapter 14) can detect pods with open ports that no MeshMember declares.
• A package deployed without a MeshMember is safe (default-deny blocks traffic) but fails silently — services that try to reach it get timeouts.

---

LatticeComplianceProfile

Kind: LatticeComplianceProfile Introduced: Chapter 14 (Section 14.4) Audience: Platform team, security team Purpose: Declares which compliance frameworks to evaluate continuously. The compliance controller runs probes for each framework’s controls at the configured interval and reports pass/fail with evidence in the status.

Complete Spec Example

apiVersion: lattice.dev/v1alpha1
kind: LatticeComplianceProfile
metadata:
  name: production
spec:
  frameworks:
    - nist-800-53-moderate
    - cis-kubernetes
    - soc-2
  scanInterval: 1h

Status Example

status:
  lastScanTime: "2026-04-06T02:00:20Z"
  frameworks:
    nist-800-53-moderate:
      passed: 29
      failed: 0
      total: 29
    cis-kubernetes:
      passed: 4
      failed: 0
      total: 4
    soc-2:
      passed: 5
      failed: 0
      total: 5

Field Reference

Field	Type	Required	Description	Default
frameworks	list of strings	Yes	Compliance frameworks to evaluate. Values include nist-800-53-moderate, cis-kubernetes, soc-2.	None (required)
scanInterval	duration string	Yes	How often to run compliance probes (e.g., 1h, 30m).	None (required)

Probe Types (Chapter 14, Section 14.5)

• Cedar authorization probes: Submit known-bad requests and verify denial.
• Resource existence probes: Verify expected resources exist and are healthy (e.g., default-deny CiliumClusterwideNetworkPolicy).
• Configuration probes: Verify cluster-level settings (API server audit logging, etcd encryption).
• Deployment readiness probes: Verify security infrastructure health (Cilium agents, Istio control plane, cert-manager).

---

CedarPolicy

Kind: CedarPolicy Introduced: Chapter 13 (Section 13.1), referenced in Chapter 4 (Section 4.9), Chapter 8 Audience: Platform team, team leads Purpose: Defines Cedar authorization rules evaluated at derivation time. Policies are validated by admission webhook and distributed to workload clusters via gRPC stream. Evaluation uses forbid-overrides-permit semantics with default-deny.

Description

No YAML spec example is shown in the book. CedarPolicy CRDs contain Cedar language policy text. They are:

• Validated by an admission webhook (CedarPolicyValidator) for syntax correctness before admission (Chapter 8 answer key).
• Distributed to workload clusters through the SyncDistributedResourcesCommand gRPC stream (Chapter 7).
• Evaluated locally on each workload cluster — no callback to the parent.
• Deletable for fast rollback: delete the CRD and every cluster re-syncs within 60 seconds (Chapter 13).

The Six Authorization Gates

Gate	Fires When	Description
DeployImage	Always	Can this service deploy this image? Evaluates image signing status.
AllowTagReference	Image uses a tag instead of digest	Can this service use a tag? Defaults to deny.
AccessSecret	Spec references a secret	Can this service access this secret?
OverrideSecurity	Spec requests capabilities, privilege, or AppArmor overrides	Can this service use privileged capabilities?
AccessExternalEndpoint	Spec has type: external-service resources	Can this service call this external host?
AccessVolume	Spec has type: volume resources	Can this service mount this shared volume?

Policy Example (from Chapter 13)

// Team lead permits commerce services to access team secrets
permit(
    principal in Namespace::"commerce",
    action == Action::"AccessSecret",
    resource in SecretStore::"commerce"
);

// Security team forbids all access to the root CA key
forbid(
    principal,
    action == Action::"AccessSecret",
    resource == Secret::"pki/root-ca-key"
);

---

SecretProvider

Kind: SecretProvider Introduced: Chapter 9 (Section 9.3) Audience: Platform team Purpose: Configures a secret backend. One per backend per environment. The derivation pipeline resolves ${resources.<name>.<key>} references against the configured ClusterSecretStore. Backend migrations are transparent to developers.

Complete Spec Example

apiVersion: lattice.dev/v1alpha1
kind: SecretProvider
metadata:
  name: vault-production
spec:
  backend: vault
  config:
    server: https://vault.internal:8200
    path: secret/data
    authMethod: kubernetes

Field Reference

Field	Type	Required	Description	Default
backend	string	Yes	Secret backend type (e.g., vault, aws-secrets-manager).	None (required)
config.server	string	Conditional	Backend server URL. Required for Vault.	None
config.path	string	Conditional	Base path for secret lookups. Required for Vault.	None
config.authMethod	string	Conditional	Authentication method (e.g., kubernetes for Vault’s Kubernetes auth).	None

Notes

• The platform team must ensure key name compatibility during backend migrations. If Vault uses password and AWS uses db-password, developer ${resources.orders-db.password} references break (Chapter 9, Section 9.3).
• A key mapping layer in the SecretProvider can handle name differences during migration.

---

TrustPolicy

Kind: TrustPolicy Introduced: Chapter 14 (Section 14.2) Audience: Platform team, security team Status: Image signing and verification is not yet implemented in the reference implementation. This section describes the intended behavior. See the Implementation Roadmap for current status. Purpose: Maps cosign signing keys to container registries. At derivation time, the pipeline verifies each container image’s signature against the applicable TrustPolicy before producing any Kubernetes resources.

Complete Spec Example

apiVersion: lattice.dev/v1alpha1
kind: TrustPolicy
metadata:
  name: internal-registry
spec:
  registry: registry.example.com
  cosign:
    publicKey:
      secretRef: signing-keys/cosign-public

Field Reference

Field	Type	Required	Description	Default
registry	string	Yes	Container registry hostname to match against image references.	None (required)
cosign.publicKey.secretRef	string	Yes	Reference to a Kubernetes Secret containing the cosign public key (namespace/name format).	None (required)

Verification Behavior

• Caching: Verified results cached for 5 minutes; failed verifications cached for 60 seconds. Concurrent verifications of the same image are coalesced.
• Cache invalidation gap: After key revocation (TrustPolicy update), cached “verified” results persist for up to 5 minutes. Event-driven cache invalidation reduces this to seconds but is not implemented in the reference implementation (Chapter 14, Section 14.9).
• Keyless signing: Cosign supports keyless signing via OIDC/Fulcio/Rekor. The reference implementation uses key-based signing to avoid the Rekor dependency.

---

Shared WorkloadSpec

The following types are shared across LatticeService, LatticeJob, and LatticeModel (Chapter 4, Section 4.9):

Component	Shared Fields	Description
Container spec	image, command, args, variables, files, resources (CPU/memory/GPU), livenessProbe, readinessProbe	Container definition format is identical across all workload CRDs.
Resource declarations	type, direction, params	Dependency declaration format (service, secret, volume, external-service, gpu) is identical.
Secret reference syntax	${resources.<name>.<key>}	Interpolation syntax for variables and files is identical. Resolved through the same five routing paths (Chapter 9).
Security gates	DeployImage, AccessSecret, OverrideSecurity, AccessExternalEndpoint, AccessVolume, AllowTagReference	All workload CRDs pass through the same Cedar authorization gates.

What Differs Per CRD

CRD	Unique Top-Level Fields	Derived Output Differences
LatticeService	replicas, autoscaling, ingress, deploy, workload.service.ports, observability	Deployment, Service, PDB, KEDA ScaledObject, VMServiceScrape
LatticeJob	tasks, queue, minAvailable, schedule, concurrencyPolicy, defaults.entryRuntime	Volcano VCJob, PodGroup, CronJob (if scheduled). No PDB, no ScaledObject.
LatticeModel	modelSource, roles, routing, defaults.entryWorkload	Multiple Deployments (per role), model download init container, role-specific KEDA ScaledObjects with GPU metrics, inference routing resources.