-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New resource azurerm_postgresql_server_key
- Add CMK support
#8126
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hey @ArcturusZhang
Thanks for this PR - I've taken a look through and left some comments online which mostly mirror the MySQL PR. If we can fix those up then we should be able to take another look 👍
Thanks!
azurerm/internal/services/postgres/postgresql_server_key_resource.go
Outdated
Show resolved
Hide resolved
"key_vault_key_id": { | ||
Type: schema.TypeString, | ||
Required: true, | ||
ValidateFunc: azure.ValidateKeyVaultChildId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this also support the "versionless" secrets? If so we'll likely need to look up the current version to be able to use that as a name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By saying key_vault_key_id
, it means some key URL WITH version like this:
https://YourVaultName.vault.azure.net/keys/YourKeyName/01234567890123456789012345678901>
Do you suggest we change this schema to align with the CMK for storage? i.e, like this:
key_vault_id =
key_name =
key_version =
to emphasize that we are requiring a versioned key here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right however most Azure API's which support a versioned secret also take a "versionless" version too (since the 'version' gets parsed as empty, which the Key Vault API's return as "latest") - so we should test that
No, this makes sense to leave as key_vault_key_id
- however we need to confirm if this validation needs to accept both a versioned and versionless Key ID, which we'll identify through testing that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure I will have a try with this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just have a try if we pass a key URL without version, and get an internalServerError
.
And per their document page, they should be expecting the key URL with version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then should we be validing that the id has a version then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function ValidateKeyVaultChildId
is expecting this ID to have a version. We have a ValidateKeyVaultChildIdVersionOptional
for the version-optional scenario
Hi @tombuildsstuff I have made some changes, please have a look. About the version of keys, this resource is requiring a key URL with version. Therefore it is possible that we could change the schema a little bit to align with the CMK in storage account (details in review comments). What do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @ArcturusZhang - however it looks like multiple tests are failing with:
Error: creating PostgreSQL Server "acctest-psql-server-200919181404659776" (Resource Group "acctestRG-psql-200919181404659776"): postgresql.ServersClient#Create: Failure sending request: StatusCode=405 -- Original Error: Code="FeatureSwitchNotEnabled" Message="Requested feature is not enabled"
Is there something we need to enable? and how can we add this new feature without breaking existing users?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as the test failure is unrelated 👍
This has been released in version 2.29.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example: provider "azurerm" {
version = "~> 2.29.0"
}
# ... other configuration ... |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks! |
Adding customer managed key support for postgreSQL Server
Fixes #7811