Lesson 4.3 · 12 min read
Operating enclaves with nitro-cli
Build, run, inspect and terminate enclaves, and the operational checks an officer should require.
Lifecycle
bash
# 1. Launch the parent instance with enclaves enabled (supported instance types only)
aws ec2 run-instances ... --enclave-options 'Enabled=true'
# 2. Build an enclave image from a container image; record the printed PCRs
nitro-cli build-enclave --docker-uri my-app:1.4.2 --output-file my-app.eif \
--private-key signing-key.pem --signing-certificate signing-cert.pem
# 3. Run it (production: no --debug-mode, no --attach-console)
nitro-cli run-enclave --eif-path my-app.eif --cpu-count 2 --memory 2048
# 4. Inspect and stop
nitro-cli describe-enclaves
nitro-cli terminate-enclave --enclave-id i-0abc...-enc0123...Officer checklist
| Control | Evidence to request |
|---|---|
| Images are built in CI, not on laptops | Pipeline logs showing the build and the PCRs it printed |
| PCRs are recorded as reference values | A versioned file or registry entry per release |
| Production never uses debug mode | Launch scripts or IaC without --debug-mode; alerts on all-zero PCRs |
| Key policies require attestation | KMS key policy conditions on kms:RecipientAttestation:ImageSha384 or kms:RecipientAttestation:PCR<n> |
| Attested KMS calls are monitored | CloudTrail events for KMS requests from enclaves, which include the attestation values |
| Signing keys are protected | Where the EIF signing key lives and who can use it |
Key takeaways
- Build EIFs in CI and store their PCRs as release artifacts.
- Sign EIFs and protect the signing key as carefully as any production credential.
- Monitor attested KMS calls in CloudTrail and alert on denied or debug attestations.
Reference: Nitro Enclaves CLI (AWS).
End of module 4
Take the module 4 quiz to check your understanding.