pck-cert-tool / pcsclient.py require interactive Intel PCS API key entry — blocks full airgap deployment automation

[butler54]

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:

1. This isn't lost (no issue currently exists anywhere for it)
2. coco-pattern can link to it from the deployment runbook as the reason this one manual step remains
3. 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?