scripts/gen-secrets.sh generates an RSA key pair (~/.coco-pattern/id_rsa) for optional podvm SSH-debug access, gated behind COCO_ENABLE_SSH_DEBUG=true / global.coco.enableSSHDebug. This key is wired end-to-end:
sandboxed-containers-chart's templates/ssh-key-eso.yaml (Azure-only, opt-in) pulls it from Vault into a k8s ssh-key-secret.sandboxed-policies-chart's templates/peer-pods-cm.yaml toggles CUSTOM_CLOUD_INIT_MODULES when enableSSHDebug is set, which is what lets the injected key reach the podvm's cloud-init.
Is this still a peer-pods requirement? No — cross-repo git history confirms it isn't. sandboxed-containers-chart PR #7 ("feat: optional ssh debug when debug configuration is setup") has a first commit literally titled "feat: remove ssh key", followed by "feat: optional SSH debug key injection for podvm" — i.e. this was originally mandatory and was deliberately made optional/debug-only in that PR. values-global.yaml and values-secret.yaml.template both explicitly document it as "Do not enable in production", off by default.
So it's not dead code (it's real, wired, working functionality if you opt in), but it's also no longer required, and it's currently RSA-only.
Proposal: since generating/supporting an additional key type is low effort, modernize this to also support Ed25519 (matching the approach taken for the RHDP wrapper scripts in #23 / #130) rather than removing it outright.
Scope note: this spans 3 repos — coco-pattern (scripts/gen-secrets.sh, values-secret.yaml.template), sandboxed-containers-chart (templates/ssh-key-eso.yaml), and sandboxed-policies-chart (templates/peer-pods-cm.yaml). Before changing the key type or the field names used in the ssh-key-secret object, verify what the actual consumer (presumably the sandboxed-containers-operator / cloud-api-adaptor's cloud-init logic, upstream of all 3 of these repos) expects — this wasn't verifiable from the 3 repos alone and needs cross-repo/upstream coordination.
scripts/gen-secrets.shgenerates an RSA key pair (~/.coco-pattern/id_rsa) for optional podvm SSH-debug access, gated behindCOCO_ENABLE_SSH_DEBUG=true/global.coco.enableSSHDebug. This key is wired end-to-end:sandboxed-containers-chart'stemplates/ssh-key-eso.yaml(Azure-only, opt-in) pulls it from Vault into a k8sssh-key-secret.sandboxed-policies-chart'stemplates/peer-pods-cm.yamltogglesCUSTOM_CLOUD_INIT_MODULESwhenenableSSHDebugis set, which is what lets the injected key reach the podvm's cloud-init.Is this still a peer-pods requirement? No — cross-repo git history confirms it isn't.
sandboxed-containers-chartPR #7 ("feat: optional ssh debug when debug configuration is setup") has a first commit literally titled "feat: remove ssh key", followed by "feat: optional SSH debug key injection for podvm" — i.e. this was originally mandatory and was deliberately made optional/debug-only in that PR.values-global.yamlandvalues-secret.yaml.templateboth explicitly document it as "Do not enable in production", off by default.So it's not dead code (it's real, wired, working functionality if you opt in), but it's also no longer required, and it's currently RSA-only.
Proposal: since generating/supporting an additional key type is low effort, modernize this to also support Ed25519 (matching the approach taken for the RHDP wrapper scripts in #23 / #130) rather than removing it outright.
Scope note: this spans 3 repos — coco-pattern (
scripts/gen-secrets.sh,values-secret.yaml.template),sandboxed-containers-chart(templates/ssh-key-eso.yaml), andsandboxed-policies-chart(templates/peer-pods-cm.yaml). Before changing the key type or the field names used in thessh-key-secretobject, verify what the actual consumer (presumably the sandboxed-containers-operator / cloud-api-adaptor's cloud-init logic, upstream of all 3 of these repos) expects — this wasn't verifiable from the 3 repos alone and needs cross-repo/upstream coordination.