-
Notifications
You must be signed in to change notification settings - Fork 976
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
Datasource: kubernetes_secret
: add binary_data
attribute
#1285
Conversation
In case where we're dealing with secrets that contain, for instance, SSL certificates in PFX format - binary value of the secret becomes corrupted on retrieval. This additional attribute encodes only the values in base64, allowing us to consume binary data as is.
I had to modify the resource, since datasource implicitly uses its |
@dak1n1 Something like this? Didn't run acceptance though, I'm sorry, fiddling around to figure out how to do that first :) |
kubernetes_secret
: add base64_data
attributekubernetes_secret
: add binary_data
attribute
This looks awesome! Thanks for all the work figuring this out. Sorry, I'm really slow to review things, but I'll get it tested and get back to you. |
Thanks so much. If everything looks good - would there be a chance we could get a minor release in the near future? We're really looking forward to this working :) |
Yes, we can do a release on Tuesday, most likely. The tests for this one looks good, but I might need help finding a resource that can consume the data generated by this new data source attribute. I'll show you what I mean. (The code in this PR could be totally fine, and it could just be an issue with the secret resource I'm using for the test). Here's my test so far: Build a local k8s cluster and create the secret outside of Terraform.
Compile the provider using the local branch and use it in a Terraform config. Details here: Result: when I use the data source to read data from an existing secret, only one of the two fields are copied from the original secret into the new one.
The new secret only has one of the two fields from the original secret.
Here's the original secret for comparison.
I'll continue investigating this. |
@dak1n1 Typo in datasource def. |
Thanks! I'll try again. |
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 for the help testing this! It's all working as expected.
|
@dak1n1 Ping :) Could we please release this? Thanks! |
Sorry about that, I made an attempt to release yesterday, but I found an issue with another PR that was merged. @jrhouston is working on a fix. I'll do what I can to support this effort and get the release out. |
The change has been released in version 2.3.0. https://github.com/hashicorp/terraform-provider-kubernetes/releases/tag/v2.3.0 |
Thank you so much! |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Description
In case where we're dealing with secrets that contain, for instance, SSL certificates in PFX format - binary value of the secret becomes corrupted on retrieval.
This additional attribute encodes only the values in base64, allowing us to consume binary data as is.
Use-case: Azure AKS cluster with cert-manager fetching LE certiicates creates a secret with certs in both PEM and PFX format. While retrieving that secret - PEM parts work, PFX becomes garbled, since it's encoded to a string. Some other services (like Application Gateway) do not accept PEM certificates and only want PFX, which forces us to do dark magic with CLI to extract the cert. This change would allow us to do it all nicely inside terraform code.
Tested with a custom-built provider - works like a charm.
Acceptance tests
N/A I think, but can add one if team deems necessary.
N/A I think, but can add one if team deems necessary.
Release Note
Release note for CHANGELOG:
Community Note