Summary
SGX/TDX platform registration (pck-cert-tool register) and PCS collateral fetch (pcsclient.py cache / pccsadmin.py fetch) require the Intel PCS API key to be entered interactively — there is no environment variable or CLI flag to supply it non-interactively. This is currently the only manual, interactive step in an otherwise fully-scriptable airgap deployment of coco-pattern on bare-metal TDX/SGX.
Impact
- Blocks full end-to-end automation of the airgap deploy runbook (
AIRGAP-DEPLOYMENT-RUNBOOK.md, coco-pattern/airgap/DEPLOY-RUNBOOK.md).
- Every SGX factory reset requires a human to sit at a console and paste the API key when prompted (see
TDX-SGX-FACTORY-RESET-REGISTRATION-RUNBOOK.md, step "Offline-registration bridge").
- Stability Run 5 confirmed the PCK cache can be reused across redeploys when the QE ID doesn't change, which avoids re-running this step most of the time — but any SGX factory reset (platform re-key) still requires it.
Evidence
UPSTREAM-ISSUES-INTEL-DCAP.md — Issue 3, documents this as a known upstream gap, never filed against Intel's tooling.AIRGAP-DEPLOYMENT-RUNBOOK.md explicitly calls this out as an "upstream issue to raise" that was never actually filed.TDX-SGX-FACTORY-RESET-REGISTRATION-RUNBOOK.md documents the manual step in the full re-registration procedure.
Ask
The actual tooling (pck-cert-tool, pcsclient.py/pccsadmin.py) ships inside the Intel DCAP / QGS container image, so the root fix belongs with Intel's SGXDataCenterAttestationPrimitives project or the operator image maintainers, not coco-pattern itself. Filing here as a tracking issue so:
- This isn't lost (no issue currently exists anywhere for it)
- coco-pattern can link to it from the deployment runbook as the reason this one manual step remains
- If/when a non-interactive option exists (env var, flag, or a wrapper script coco-pattern could ship instead, e.g.
expect-based automation), we can retire the manual step from the runbook
Open question for maintainers: is there an existing internal Red Hat/Intel tracker for this that should be linked instead of/alongside a public issue?
Summary
SGX/TDX platform registration (
pck-cert-tool register) and PCS collateral fetch (pcsclient.py cache/pccsadmin.py fetch) require the Intel PCS API key to be entered interactively — there is no environment variable or CLI flag to supply it non-interactively. This is currently the only manual, interactive step in an otherwise fully-scriptable airgap deployment of coco-pattern on bare-metal TDX/SGX.Impact
AIRGAP-DEPLOYMENT-RUNBOOK.md,coco-pattern/airgap/DEPLOY-RUNBOOK.md).TDX-SGX-FACTORY-RESET-REGISTRATION-RUNBOOK.md, step "Offline-registration bridge").Evidence
UPSTREAM-ISSUES-INTEL-DCAP.md— Issue 3, documents this as a known upstream gap, never filed against Intel's tooling.AIRGAP-DEPLOYMENT-RUNBOOK.mdexplicitly calls this out as an "upstream issue to raise" that was never actually filed.TDX-SGX-FACTORY-RESET-REGISTRATION-RUNBOOK.mddocuments the manual step in the full re-registration procedure.Ask
The actual tooling (
pck-cert-tool,pcsclient.py/pccsadmin.py) ships inside the Intel DCAP / QGS container image, so the root fix belongs with Intel'sSGXDataCenterAttestationPrimitivesproject or the operator image maintainers, not coco-pattern itself. Filing here as a tracking issue so:expect-based automation), we can retire the manual step from the runbookOpen question for maintainers: is there an existing internal Red Hat/Intel tracker for this that should be linked instead of/alongside a public issue?