Fix double base64-encoding of ca_bundle field

[adamkpickering]

Issue:

For #1297

Problem

The user reports that configuring a rancher_catalog_v2 resource with the ca_bundle field set fails. This is because the caBundle field in the configured ClusterRepo resource is base64-encoded twice. For more details, the JIRA issue gives a pretty good description.

Also note that there is a discrepancy between the documentation for configuring a repo/catalog via the Rancher UI, and the documentation for the ca_bundle field in the rancher_catalog_v2 resource:

Git-based chart repositories: You must add a base64 encoded copy of the CA certificate in DER format to the spec.caBundle field of the chart repo link

ca_bundle - (Optional) PEM encoded CA bundle which will be used to validate the repo's certificate (string) link

Solution

The cleanest solution, as far as @nicholasSUSE and I can tell, is to slightly change the behavior of the ca_bundle field so that the user sets it to a base64-encoded DER value. When expanding the terraform object into a ClusterRepo, the rancher2 provider base64-decodes the passed ca_bundle value and sets the spec.caBundle field of the ClusterRepo to the result, which is of type []byte. When the encoding/json package marshals the ClusterRepo struct created by the rancher2 provider, it automatically base64-encodes the caBundle field (see the docs for json.Marshal), which appears to be what the Rancher API expects.

Testing

This issue can be reproduced by running the terraform provider against a v2.7.6 Rancher cluster. Note that running it against a version of Rancher run via go run main.go or dlv doesn't work - it seems that the terraform provider chokes on the fact that something (I never figured out what) has the version dev.

Engineering Testing

Manual Testing

On a Rancher v2.7.6 deployment running in k3d, I did the following tests using the terraform provider:

• Creating a ClusterRepo resource with the caBundle field set.
• Creating a ClusterRepo resource without the caBundle field set.
• Deleting a ClusterRepo resource.
• Updating a ClusterRepo resource by changing the name field in the terraform resource. This failed, but I determined that this failure is present on the master branch and thus not related to this PR. This seems wrong to me, but also seems like it may just be due to how the Rancher API works. I'm new to the Rancher project, so can someone who has more experience with Rancher check this?

Automated Testing

I updated the ca_bundle field in the expandCatalogV2 and flattenCatalogV2 unit tests to reflect the HCL value being base64-encoded DER, and the ClusterRepo value being a []byte containing unencoded DER.

QA Testing Considerations

I don't think there is any issue with changing the behavior of the ca_bundle field, since it is broken as is. I could easily be wrong though...

Regressions Considerations

[nicholasSUSE]

I approved, but please wait for @rohitsakala review before merging

[nicholasSUSE]

Let's test the following:

output "some_NAME" {
  value = <the_catalog_resource>.ca_bundle
}

to validate this