Customers have some regulated use cases and cannot include in configuration files (tfvars) or non HSM storage some secret attributes. However those attributes may be required to create or update a resource.
This issue is the opposite of #51 (Store sensitive attributes as HSM secret value [output attributes]) and propose a way to retrieve sensitive data from external HSM and inject them into the payload.
Some API calls are returning sensitive information (passwords, authorisation keys, crypto objects...) that should not be persisted in the tfstate as defined in #51 . The same requirement applies to this feature.
Design goals:
Supporting a pluggable approach where over time additional HSM (secret store) can be added like Hashicorp vault secrets, kubernetes secrets...
Initial HSM support with Azure Key vault, Azure managed HSM, Azure dedicated HSM
Implementation directions:
Add an optional attribute hsm_input_attrs to define the attributes to retrieve from a HSM as secret value to include in the json payload
Some secrets may have an expiration date and a warning should be displayed if it has expired
If the PUT/POSTinclude a response payload with on of the hsm_input_attrs, they must be removed from the diff and not stored into the tfstate
This issue describes the desired state of that feature. In this scenario the Authorization Key is not stored in a variable but retrieved from the HSM and injected by the provider into the payload request of the PUT or POST method
With this approach secure attributes are kept into the HSM and only injected at PUT or POST execution. Their value is never stored into the tfstate.
resource "restful_resource" "resource" {
path = format("...")
create_method = "PUT"
body = jsonencode({
name = "name"
})
hsm_input_attrs = {
authorizationKey = {
provider = azure.keyvault
definition = {
endpoint = "resource id of the keyvault secret"
// HSM security context can inherit from the provider context or provide a specific block in the provider to set the HSM security context.
}
// secret value to retrieve from the HSM
secret_name = "authorization-key"
// JSON path where the value must be included
path = "body.authorization_key"
}
}
After apply execution it is expected that the output attribute will have "body.authorization_key" removed from the json.
output = {
// api response json with hsm_input_attrs removed
}
Customers have some regulated use cases and cannot include in configuration files (tfvars) or non HSM storage some secret attributes. However those attributes may be required to create or update a resource.
This issue is the opposite of #51 (Store sensitive attributes as HSM secret value [output attributes]) and propose a way to retrieve sensitive data from external HSM and inject them into the payload.
Some API calls are returning sensitive information (passwords, authorisation keys, crypto objects...) that should not be persisted in the tfstate as defined in #51 . The same requirement applies to this feature.
Design goals:
Implementation directions:
This issue describes the desired state of that feature. In this scenario the Authorization Key is not stored in a variable but retrieved from the HSM and injected by the provider into the payload request of the PUT or POST method
With this approach secure attributes are kept into the HSM and only injected at PUT or POST execution. Their value is never stored into the tfstate.
After apply execution it is expected that the output attribute will have "body.authorization_key" removed from the json.