Skip to content
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

Mark ObjectsUser's access_key and secret_key as sensitive #60

Closed
davidgubler opened this issue May 10, 2022 · 6 comments · Fixed by #63
Closed

Mark ObjectsUser's access_key and secret_key as sensitive #60

davidgubler opened this issue May 10, 2022 · 6 comments · Fixed by #63

Comments

@davidgubler
Copy link

davidgubler commented May 10, 2022

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
Copy link
Contributor

alakae commented May 11, 2022

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
Copy link
Contributor

alakae commented May 16, 2022

@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
Copy link

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
Copy link

As discussed in chat:

The underlying issue that prevented it from working correctly, was in fact a terrajet bug: crossplane/terrajet#27

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

@alakae
Copy link
Contributor

alakae commented May 18, 2022

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

@davidhalter
Copy link
Contributor

davidhalter commented May 19, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants