CSPACE-SAKEY-01: Workload SA has no long-lived user-managed keys¶
| Property | Value |
|---|---|
| Severity | high |
| Platform | GCP Confidential Space (AMD SEV-SNP) |
| Lifecycle stage | deploy |
| Mode | Passive: read-only cloud API calls. |
What it checks¶
It passes when:
- Workload SA has no user-managed keys.
Example failures:
- Workload SA has … user-managed key(s). A stolen long-lived key reaches KMS/GCS permanently, with no attestation.
- Workload SA has … user-managed key(s) — a stolen key reaches KMS/GCS permanently, with no attestation.
How to fix¶
- Delete user-managed keys on the workload SA and disable key creation (org policy iam.disableServiceAccountKeyCreation). The CS VM uses the attached SA via the metadata server — it needs no exported keys.
After the fix, scan again: the check should report PASS.
When it is not assessed¶
SKIP:
- Need --gcp-instance, --gcp-zone, and --gcp-project; skipping check.
ERROR:
- Could not list SA keys: …
Scan inputs¶
The untrust scan options this check reads:
| Option | Description |
|---|---|
--gcp-instance |
Confidential VM instance name. |
--gcp-project |
GCP project ID. |
--gcp-zone |
Zone of the Confidential VM. |
Permissions¶
The cloud API calls this check makes, read from the scanner's source:
| Cloud | API call | Permission | Access |
|---|---|---|---|
| Google Cloud | compute.instances.get |
compute.instances.get |
read |
| Google Cloud | iam.projects.serviceAccounts.keys.list |
iam.serviceAccountKeys.list |
read |
See Required permissions for every check on this platform.
Generated from untrust 1.3.0 (commit 7ef462d9a0c3).