Vertex AI resources encrypted with Google-managed keys only
What does ZopNight detect here?
Vertex AI endpoints, models, indexes, feature stores, metadata stores and tensorboards, 8 resource types in total, are checked for an encryptionSpec.kmsKeyName. Where the discoverer records cmek=false, the resource uses Google-managed keys, and organizations mandating customer-managed encryption must recreate it with a Cloud KMS key.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1341 · RC-1342 · RC-1343 · RC-1344 · RC-1345 · RC-1346 · RC-1347 · RC-1348 |
| Category | compliance |
| Severity | low |
| Metric | none — pure configuration read |
| Source | vertex_security.go (VertexCMEKRule, one registration per type) |
Where it applies
Eight resource types, one check
Every encryptable Vertex AI resource carries an encryptionSpec: endpoints, models,
Vector Search indexes and index endpoints, both feature-store generations, metadata
stores, and tensorboards. One parameterized rule registers once per type, 8 rule IDs in
all, each asking the same question: is kmsKeyName set? The discoverer reduces the
answer to a cmek stamp, and a recorded false means the resource’s data (model
artifacts, embeddings, feature values, experiment metadata) is encrypted with keys
Google manages and Google rotates, outside your revocation control.
CMEK is set at creation only
Google-managed encryption is not weaker cryptography; the compliance gap is control.
CMEK routes encryption through a Cloud KMS key you own, which means your rotation
schedule, your audit trail on every use, and, decisively for some regulators, your
ability to disable the key and render the data unreadable. Vertex resources accept an
encryptionSpec.kmsKeyName only at creation, so remediation is always recreate-and-
migrate, never an in-place patch. That makes this finding cheapest to fix early, before
an endpoint accumulates deployment history and traffic.
The service agent needs the key
CMEK fails at runtime, not at configuration time, when permissions are missing: the Vertex AI service agent for the project must hold the CryptoKey Encrypter/Decrypter role on the chosen key, in the same region as the resource. Grant it before recreating, or the new resource’s first operation fails with a KMS permission error.
Verify a resource’s encryption spec
gcloud ai endpoints describe ENDPOINT_ID --region us-central1 \ --format="value(encryptionSpec.kmsKeyName)"Empty output is the Google-managed state; the same field exists on gcloud ai models,
indexes, and the other resource groups.
Compliance signal, zero dollars
SavingsUSD is 0 by design: there is a concrete action but no cost lever, and compliance findings are exempt from the savings-floor filters that govern cost rules. The rule fails safe: only a positively recorded cmek=false fires, so resources whose encryption state was never resolved stay off the report rather than being presumed unencrypted.