REDACTED_POSSIBLE_SECRET_ACCESS_KEY as part of column value result form aes_encrypt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-11-2023 12:43 PM
Hi, i've encountered an error using base64/aes_encrypt, as result the string saved contains 'REDACTED_POSSIBLE_SECRET_ACCESS_KEY' at the end destroying the original data, rendering it useless undecryptable, is there a way to avoid this replacement in the saved data?
this behaviour occours in special conditions it seems, problem is the redaction is not only in presentation layer but the data beneath... whenever this query is writen, the data renders the REDACTED string
i guess the problem is related to:
https://docs.databricks.com/en/security/keys/redaction.html#aws-secret-access-key-redaction
but it should not destroy the data. (string replaced contains 40 characters, tried appending a letter at the end to retrieve the correct encrypted value)
once the query is saved as table it can not be decrypted any more
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
02-08-2024 03:41 PM
I had the same issue, and my usage was similar to OP:
base64(aes_encrypt(<clear_text>, unbase64(secret(<scope>, <key>))))
Databricks support suggested to not call secret within the insert/update operation that writes to the table. After updating the python code to first fetch the encryption key from secret, then executing aes_encrypt using expr, the redaction and data corruption went away.
This article gives the overall approach I followed, using a mix of pyspark and sql. Just remember to first retrieve the encryption key, then construct the aes_encrypt call with the key, rather than calling secret from within aes_encrypt.
Hope this helps!

