Checks

Customer-managed KMS keys used with Nitro Enclaves (identified by prowler:enclave-key=true tag, enclave in description/tags/aliases, or a policy referencing kms:RecipientAttestation:*). Every Allow on sensitive actions (kms:Decrypt, DeriveSharedSecret, GenerateDataKey*, GenerateRandom, kms:*, *) must require a kms:RecipientAttestation:* condition.

Compares the kms:RecipientAttestation:PCR<N> (and equivalent ImageSha384) values referenced by an enclave key policy against a customer-provided list of trusted PCR hashes configured under enclave_golden_pcr_values in audit_config. Detects image provenance drift: policies whose attestation conditions still reference PCRs that no longer correspond to a known-good build.

Scans CloudTrail attestation activity and flags PCR values missing from enclave_golden_pcr_values (only for buckets with a configured golden list). Complements kms_key_enclave_attestation_pcr_mismatch by catching real enclave calls with an unrecognized image. MEDIUM by default, overridable to HIGH via enclave_unknown_image_severity.

Detects Nitro Enclaves launched with --debug-mode via CloudTrail KMS-from-enclave events. Debug enclaves produce attestations with zeroed image/kernel/application PCRs (PCR0/1/2); the check flags every KMS key that received such a call. Configurable via enclave_debug_lookback_window_hours (default 2160h / 90d) and enclave_debug_max_events (5000).

Huawei Cloud Key Management Service (KMS) keys that are in PendingDeletion state should be reviewed. Keys scheduled for deletion may cause decryption failures for dependent resources, leading to data unavailability. Ensure deletion is intentional and all dependent resources have been migrated.

KMS keys are assessed for excessive access in key policies or grants, including * principals and broadly scoped permissions to multiple identities.

Cloud KMS crypto keys are evaluated for public principals in their IAM bindings, specifically allUsers and allAuthenticatedUsers.

The finding reflects whether these memberships are present on a key.

Google Cloud KMS customer-managed keys have automatic rotation enabled, regardless of the rotation interval.

The evaluation reviews each key's rotation settings to confirm that a rotation period is configured so new key versions are created periodically.

Ensure that Huawei Cloud Key Management Service (KMS) keys have automatic key rotation enabled to regularly rotate the cryptographic material.

OCI KMS customer-managed keys configured for automatic rotation, with a rotation interval set to <= 365 days, or manually rotated within the last 365 days. Some vault types do not support auto-rotation, so manual rotation is accepted as an alternative.

Google Cloud KMS customer-managed keys are rotated with an interval of 90 days or less, in line with the CIS Benchmark.

The evaluation reviews each key's rotation settings to confirm that both the rotation period and the next rotation time stay within 90 days.

A program inside the container can elevate its own privileges and run as root, which might give the program control over the container and node.

According to pod security standard 'AppArmor', the AppArmor key must be set to the runtime/default profile or to be undefined.

The container should drop all default capabilities and add only those that are needed for its execution.

Security best practices require containers to run with minimal required capabilities.

SYS_ADMIN gives the processes running inside the container privileges that are equivalent to root.

Mounting docker.sock from the host can give the container full root access to the host.

Managing /etc/hosts aliases can prevent the container engine from modifying the file after a pod’s containers have already been started.

Sharing the host’s IPC namespace allows container processes to communicate with processes on the host.

Sharing the host’s network namespace permits processes in the pod to communicate with processes bound to the host’s loopback adapter.

Sharing the host’s PID namespace allows visibility on host processes, potentially leaking information such as environment variables and configuration.

Enforcing CPU limits prevents DoS via resource exhaustion.

Force the running image to run as a non-root user to ensure least privileges.

It is best to avoid using the ':latest' image tag when deploying containers in production. Doing so makes it hard to track which version of the image is running, and hard to roll back the version.