Teradata Stored Password Protection
eetu-h opened this issue · 5 comments
Describe the feature
Provide a user-friendly approach for Stored Password Protection. Stored Password Protection in Teradata enables an application to provide a connection password in encrypted form to the driver.
As of today, you can provide the password in ENCRYPTED_PASSWORD(file:PasswordEncryptionKeyFileName,file:EncryptedPasswordFileName) format to make this to work. However, I'm looking for an alternative approach in which you could provide i.e. key_file_path and password_file_path connection parameters instead of providing the password parameter.
Describe alternatives you've considered
As described, Stored Password Protection works already when using ENCRYPTED_PASSWORD(file:PasswordEncryptionKeyFileName,file:EncryptedPasswordFileName) format for password.
Additional context
Who will this benefit?
People who'd like to avoid providing their password in plain text or an environment variable.
Are you interested in contributing this feature?
@eetu-h , thank you for the feature request.
Let me play it back to make sure I understood your request correctly. In addition to the following syntax:
...
password: "ENCRYPTED_PASSWORD(file:PasswordEncryptionKeyFileName,file:EncryptedPasswordFileName)"
...
you would like to be able to pass the encrypted password file path and the password encryption key file path as separate profile properties, e.g.:
...
key_file_path: "<key_file_path>"
password_file_path: "<password_file_path>"
...
Is this correct?
@adamtwo, yes your example is exactly something that I'm looking for.
Perhaps it is only me, but I feel the feature is a bit hidden in the current version of the adapter:
...
password: "ENCRYPTED_PASSWORD(file:PasswordEncryptionKeyFileName,file:EncryptedPasswordFileName)"
...
And for this reason, proposing this alternative approach with the optional properties to make it more visible and accessible.
Thanks for confirming my understanding.
Yes, I agree that ENCRYPTED_PASSWORD functionality is not easy to find. It's especially true for dbt users as the option is documented in the Python driver and not in the dbt documentation. Having said that, configuration options for authentication are already a crowded area. We have username, password, logmech, logdata. The field is vast but at least it's consistent between the drivers. I'm reluctant to introduce more ways to configure authentication.
Maybe what we could do instead is extend the dbt-teradata adapter docs and bring in authentication options docs from other drivers to README.md and https://docs.getdbt.com/reference/warehouse-profiles/teradata-profile?
Valid point and I agree that documenting the different authentication options would perhaps be enough. And would be nice to cover both ENCRYPTED_PASSWORD and the options for logmech+logdata. Collecting links to existing documentation available i.e. in docs.teradata.com could even be enough to start with?