Failing test(s): TestAccCompute* ("Error 400: Cloud KMS error" permissions denied)

[SarahFrench]

Failure rate: 38% failure since April 18th 2023

Affected Resource(s)

• google_compute_instance_template

Impacted tests:

• TestAccComputeInstanceTemplate_sourceSnapshotEncryptionKey - this is now passing 100%
• TestAccComputeRegionInstanceTemplate_sourceImageEncryptionKey
• TestAccComputeRegionInstanceTemplate_sourceSnapshotEncryptionKey - this is now passing 100%
• TestAccComputeImage_imageEncryptionKey
• TestAccComputeInstanceTemplate_sourceImageEncryptionKey - this is now passing 100%

Nightly builds:

• TestAccComputeInstanceTemplate_sourceSnapshotEncryptionKey - this is now passing 100%
• TestAccComputeRegionInstanceTemplate_sourceImageEncryptionKey
• TestAccComputeRegionInstanceTemplate_sourceSnapshotEncryptionKey - this is now passing 100%
• TestAccComputeImage_imageEncryptionKey
• TestAccComputeInstanceTemplate_sourceImageEncryptionKey - this is now passing 100%

Message:

Error: Error creating Snapshot: googleapi: Error 400: Cloud KMS error when using key projects/PROJECT_ID/locations/us-central1/keyRings/tftest-shared-keyring-1/cryptoKeys/tftest-shared-key-1: Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied on resource 'projects/PROJECT_ID/locations/us-central1/keyRings/tftest-shared-keyring-1/cryptoKeys/tftest-shared-key-1' (or it may not exist)., kmsPermissionDenied

[rileykarson]

Note: This shared key may be a predecessor to a bootstrapped key, and we may want to convert it to one.

[megan07]

The error has changed here: Error 409: The resource 'projects/ci-test-project-188019/zones/us-central1-a/disks/debian-disk' already exists, alreadyExists, we likely need to randomize the name on that disk.

[roaks3]

This was 100% until Mar 10, 2023 with the "already exists" error. Since then, we have seen the original error again at 32%.

This test appears to use its own service account for encryption, and it is configured to have the roles/cloudkms.cryptoKeyEncrypterDecrypter role (which includes cloudkms.cryptoKeyVersions.useToEncrypt), but I don't see a depends_on field to make sure we wait for the permission to be created. It's possible that all we need is that dependency to ensure the permission is available.

[SarahFrench]

TestAccComputeRegionInstanceTemplate_sourceImageEncryptionKey has still been failing due to this issue - 70% failure since migrating to the new TeamCity projects (i.e. as far back as our data goes it's been flaky due to this issue).

I've just been addressing a similar issue (#16687) where I can see lots of failures in the nightly tests for TPGB and I fixed a Beta-specific test that was authoritatively controlling an IAM binding on a cryptokey.

I think this GH issue is due to an acceptance test doing a similar thing, but there must be a test that's present in the GA provider (probably both GA/Beta).

---

After double checking I don't think there are acc tests in the GA provider that authoritatively affect the IAM policy on the crypto key, so I assume adding the missing depends_on argument to the TestAccComputeInstanceTemplate_sourceImageEncryptionKey test will fix the problem.

[SarahFrench]

TestAccComputeInstanceTemplate_sourceImageEncryptionKey now passing 100%

TestAccComputeRegionInstanceTemplate_sourceImageEncryptionKey should also become the same way now that GoogleCloudPlatform/magic-modules#9644 is merged

[SarahFrench]

This PR (GoogleCloudPlatform/magic-modules#9673) will fix TestAccComputeImage_imageEncryptionKey

[melinath]

Marking as forward/exempt since Sarah's actively working on this.

[SarahFrench]

Closing as stale