Glue Data Catalog Encryption Disabled: Why It Matters and How to Fix It

The Glue Data Catalog is the metadata backbone for a lot of AWS data platforms. Athena queries it, Redshift Spectrum reads from it, EMR jobs reference it, and Lake Formation builds permissions on top of it. Because it holds metadata rather than the actual data, teams often assume it is low risk and skip encryption. That assumption is where this check earns its keep.

The glue_catalogencryption check looks at the encryption settings on your Glue Data Catalog in a given region and flags the catalog when encryption at rest is not enabled. It is a per-region, account-level setting, so a single misconfiguration can leave every database and table definition in that region unprotected.

---

What this check detects

Glue Data Catalog encryption is controlled by a data catalog encryption settings object that has two independent parts:

• Metadata encryption — encrypts table definitions, partition data, column metadata, and other catalog objects at rest using a KMS key.
• Connection password encryption — encrypts passwords stored inside JDBC connection objects.

This check focuses on metadata encryption. It passes when EncryptionAtRest.CatalogEncryptionMode is set to SSE-KMS (or SSE-KMS-WITH-SERVICE-ROLE) and fails when it is set to DISABLED, which is the default for new accounts.

---

Why it matters

Metadata is not harmless. The catalog describes the exact structure of your data lake: database names, table names, column names, data types, S3 locations of the underlying data, and the connection strings used to reach external databases. To an attacker who lands read access through a leaked role or an over-broad policy, this is a free map of where your sensitive data lives.

Consider a realistic scenario. An IAM role attached to a reporting Lambda has glue:GetTables and glue:GetDatabases permissions. The role gets compromised through a dependency in the function. Without catalog encryption, the attacker can enumerate every table, read column names like ssn, card_number, or patient_dob, and pull the S3 paths those tables point to. They now know exactly which buckets to target next. Encryption at rest does not stop an authorized API call, but it does protect the underlying stored metadata and forces every access path through a KMS key whose usage you can audit and revoke.

There is also the compliance angle. Frameworks like PCI DSS, HIPAA, and SOC 2 expect encryption at rest for systems that store or describe regulated data. An unencrypted catalog that references PII tables is an easy finding for an auditor and a hard one to explain away, since the fix is a few minutes of work.

---

How to fix it

You need a KMS key first. You can use an existing customer managed key or create a dedicated one. A dedicated key gives you cleaner audit trails and the ability to revoke catalog access independently of everything else.

Step 1: Create or pick a KMS key

aws kms create-key \
  --description "Glue Data Catalog encryption key" \
  --tags TagKey=purpose,TagValue=glue-catalog

# Note the KeyId from the output, then optionally alias it
aws kms create-alias \
  --alias-name alias/glue-catalog \
  --target-key-id <key-id>

Step 2: Grant Glue access in the key policy

The principals running crawlers, jobs, and queries need to use the key. At minimum add a statement allowing your Glue service roles and query principals to decrypt and generate data keys. A trimmed example:

{
  "Sid": "AllowGlueCatalogUse",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:role/glue-crawler-role"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Step 3: Enable catalog encryption

aws glue put-data-catalog-encryption-settings \
  --region us-east-1 \
  --data-catalog-encryption-settings '{
    "EncryptionAtRest": {
      "CatalogEncryptionMode": "SSE-KMS",
      "SseAwsKmsKeyId": "alias/glue-catalog"
    },
    "ConnectionPasswordEncryption": {
      "ReturnConnectionPasswordEncrypted": true,
      "AwsKmsKeyId": "alias/glue-catalog"
    }
  }'

To do it in the console: open AWS Glue, go to Data Catalog settings in the left navigation, check Metadata encryption, select your KMS key, and save. While you are there, enable Encrypt connection passwords too.

Step 4: Verify

aws glue get-data-catalog-encryption-settings --region us-east-1

You should see CatalogEncryptionMode reported as SSE-KMS with your key ARN.

---

Fixing it with infrastructure as code

Doing this once by hand fixes one region. Doing it in code fixes it everywhere and keeps it fixed. Here is the Terraform resource:

resource "aws_glue_data_catalog_encryption_settings" "this" {
  data_catalog_encryption_settings {
    encryption_at_rest {
      catalog_encryption_mode = "SSE-KMS"
      sse_aws_kms_key_id      = aws_kms_key.glue.arn
    }

    connection_password_encryption {
      return_connection_password_encrypted = true
      aws_kms_key_id                        = aws_kms_key.glue.arn
    }
  }
}

CloudFormation users can set the same thing through the AWS::Glue::DataCatalogEncryptionSettings resource. Because this is a per-region setting, deploy the stack or workspace to every region where Glue is active, not just your primary one.

---

How to prevent it from happening again

The default is unencrypted, so the only durable fix is to make encryption the standard rather than an afterthought.

• Bake it into your IaC modules. If every team provisions Glue through a shared Terraform module that includes the encryption settings resource, no one can stand up an unencrypted catalog by accident.
• Gate it in CI/CD. Run a policy-as-code scan on pull requests. With Checkov, the relevant rule is CKV_AWS_94 (Glue Data Catalog encryption). With Open Policy Agent, write a Rego rule that fails any plan where catalog_encryption_mode is not SSE-KMS.
• Detect drift continuously. Someone can still disable encryption directly through the API after deployment. A continuous scan catches that. Lensix re-runs glue_catalogencryption across all your regions and alerts when the setting reverts, so you find out in hours instead of at the next audit.

An example OPA check for a Terraform plan:

package glue.encryption

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_glue_data_catalog_encryption_settings"
  mode := resource.change.after.data_catalog_encryption_settings[_].encryption_at_rest[_].catalog_encryption_mode
  mode != "SSE-KMS"
  msg := "Glue Data Catalog must use SSE-KMS encryption at rest"
}

---

Best practices

• Use a customer managed key, not the AWS managed default. A CMK lets you set your own rotation, scope the key policy tightly, and revoke access without affecting unrelated services.
• Encrypt connection passwords too. JDBC connections to RDS, Redshift, or external databases store credentials in the catalog. Turn on ReturnConnectionPasswordEncrypted so those passwords never sit in plaintext.
• Enable key rotation. Run aws kms enable-key-rotation --key-id <key-id> so the underlying key material rotates annually with no work on your side.
• Audit key usage with CloudTrail. Once the catalog runs through KMS, every decrypt is logged. Watch for Decrypt calls from unexpected principals as an early signal of catalog enumeration.
• Apply it in every region. Attackers probe quiet regions where nobody is looking. If you have any Glue presence in a region, encrypt the catalog there even if it only holds a handful of tables.

Encrypting the Glue Data Catalog is one of those changes that costs a few minutes and pennies in KMS charges but closes a quiet information-disclosure gap that sits at the center of your data platform. Set it in code, gate it in CI, and let a continuous scanner watch for drift.