cloudscale-ch / terraform-provider-cloudscale

Terraform Cloudscale provider
https://registry.terraform.io/providers/cloudscale-ch/cloudscale/latest
MIT License
8 stars 10 forks source link

Mark ObjectsUser's access_key and secret_key as sensitive #60

Closed davidgubler closed 2 years ago

davidgubler commented 2 years ago

The properties "access_key" and "secret_key" of an ObjectsUser are currently not marked as "sensitive", but they probably should be, since they are secrets.

This is probably a simple change in resource_cloudscale_objects_user.go, just add the "Sensitive: true" flag as per Terraform's documentation, just as it was done for a server's password in resource_cloudscale_server.go.

It may be debatable whether both are sensitive or only the "secret_key". I'd say if in doubt it would be better to mark both as sensitive, which would also make sure that both are handled the same way and can be found in the same place.

Context of this request: I'm currently working with Terrajet to create a Crossplane integration for Cloudscale's ObjectsUsers, and the "Sensitive" flag is the deciding factor whether the two keys are returned directly in a Kubernetes object, which is the current insecure behavior, or in a Kubernetes secret, which is the desired and slightly more secure behavior.

Thank you!

alakae commented 2 years ago

Hi @davidgubler

Thanks for your request. I think it should be possible to implement this change. I'll coordinate this with my team. We'll get back to you.

Meanwhile, please feel free to contact us again here on GitHub or directly.

alakae commented 2 years ago

@davidgubler It looks like Terraform does not support "sub objects with only select properties marked as sensitive", see hashicorp/terraform-plugin-sdk/#201

I think the best thing I can offer you is to mark the complete keys object as sensitive:

$ terraform show
# cloudscale_objects_user.basic:
resource "cloudscale_objects_user" "basic" {
    display_name = "donald_knuth"
    href         = "https://api.cloudscale.ch/v1/objects-users/422f0ed922c179b0be6304c24fbe810721e57b3deb2c284f2c2aec21d7113c8f"
    id           = "422f0ed922c179b0be6304c24fbe810721e57b3deb2c284f2c2aec21d7113c8f"
    keys         = (sensitive value)
    user_id      = "422f0ed922c179b0be6304c24fbe810721e57b3deb2c284f2c2aec21d7113c8f"
}

Does that solve your issue? Can you please contact me on DMt, then I could maybe provide you with a pre-release binary to test your use-case?

Kidswiss commented 2 years ago

Hi @alakae

Thanks for the quick response. I could have a look at this, as @davidgubler is currently on a holiday for several weeks. I can contact you via our VSHN rocket chat instance.

Kidswiss commented 2 years ago

As discussed in chat:

The underlying issue that prevented it from working correctly, was in fact a terrajet bug: https://github.com/crossplane/terrajet/issues/27

But it makes still sense to mark the credentials as sensitive here in the module.

alakae commented 2 years ago

@Kidswiss thanks for your feedback. We'll make this ready to be released.

davidhalter commented 2 years ago

@davidgubler @Kidswiss We have just released our terraform 4.0.0 provider. Tags should be included.