Terraform-provider-kubernetes: Feature Request: support binary_data in kubernetes_secret like in kubernetes_config_map

[thomas-riccardi]

Terraform Version

Terraform v0.12.20
+ provider.kubernetes v1.11.0

Affected Resource(s)

• kubernetes_secret

Terraform Configuration Files

resource "kubernetes_secret" "example" {
  metadata {
    name = "my-secret"
  }
  binary_data = {
    "my_payload.bin" = filebase64("${path.module}/my_payload.bin")
  }
}

Expected Behavior

I'd like binary_data to be supported in kubernetes_secret like it is in kubernetes_config_map since #400.

Indeed, both ConfigMap and Secrets are very similar in Kubernetes, I was expecting to have feature parity between the two.

Actual Behavior

Error: Unsupported argument

  on resources.tf line 248, in resource "kubernetes_secret" "example":
 248:   binary_data = {

An argument named "binary_data" is not expected here.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

References

• #400

[albertorm95]

I think replicating the solution that @pdecat implemented for #400 but in the secret code would resolve this issue, I can do that! 😄

Update: looking into the Code it looks like the Secret definition does not have BinaryData as ConfigMap does, but the Data property is the same kind of BinaryData so maybe you could resolve your issue just as:

resource "kubernetes_secret" "example" {
  metadata {
    name = "my-secret"
  }
  data = {
    "my_payload.bin" = filebase64("${path.module}/my_payload.bin")
  }
}

This is the definition of the Data property in Secret:

type Secret struct {
    // Data contains the secret data. Each key must consist of alphanumeric
    // characters, '-', '_' or '.'. The serialized form of the secret data is a
    // base64 encoded string, representing the arbitrary (possibly non-string)
    // data value here. Described in https://tools.ietf.org/html/rfc4648#section-4
    // +optional
    Data map[string][]byte `json:"data,omitempty" protobuf:"bytes,2,rep,name=data"`
}

And this is the defition of Data and BinaryData in ConfigMap:

type ConfigMap struct {
    // Data contains the configuration data.
    // Each key must consist of alphanumeric characters, '-', '_' or '.'.
    // Values with non-UTF-8 byte sequences must use the BinaryData field.
    // The keys stored in Data must not overlap with the keys in
    // the BinaryData field, this is enforced during validation process.
    // +optional
    Data map[string]string `json:"data,omitempty" protobuf:"bytes,2,rep,name=data"`

    // BinaryData contains the binary data.
    // Each key must consist of alphanumeric characters, '-', '_' or '.'.
    // BinaryData can contain byte sequences that are not in the UTF-8 range.
    // The keys stored in BinaryData must not overlap with the ones in
    // the Data field, this is enforced during validation process.
    // Using this field will require 1.10+ apiserver and
    // kubelet.
    // +optional
    BinaryData map[string][]byte `json:"binaryData,omitempty" protobuf:"bytes,3,rep,name=binaryData"`
}

If you need that maybe the change should start from Kubernetes API

[thomas-riccardi]

@albertorm95 you are right that at k8s-api-level Secret doesn't have BinaryData as ConfigMap has, but in fact k8s-api Secret data is expected to be base64 encoded of binary data, like k8s-api ConfigMap binaryData.
The issue is that terraform secret changed the semantic of the data field vs k8s-api by automatically doing the base64 encoding.
So manually encoding to base64 before giving it to terraform secret data won't work: i assume there would be a double base64 encoding, breaking everything.

From that, I see 2 possible paths:

• either normalizing to k8s-api semanting: terraform kubernetes_secret data now take already-base64-encoded: it would be up to the user to do the encoding, that's a breaking change though
• or normalize to terraform kubernetes_configmap and introduce the binary_data as I initially suggested: no breaking change.

Another way to see things is that terraform doesn't support binary data (as far as I know) as a standard type:

• file() reads the content as a utf-8 encoded string, so cannot be used to read raw binary data
• filebase64() reads the content as raw binary data, and then serializes it to a string with base64
  => always (unicode) strings.
  If terraform did support binary data, we could have a ~filebinary() returning binary data, and pass that directory to terraform kubernetes_secret data values, and this issue would be resolved too.

[pdecat]

Related:

• https://github.com/hashicorp/terraform-provider-kubernetes/pull/604
• https://github.com/hashicorp/terraform-provider-kubernetes/pull/704

[dak1n1]

Thanks, everyone, for your contributions to this bug report! I've consolidated the information we have regarding this and we're now tracking it here: https://github.com/hashicorp/terraform-provider-kubernetes/issues/901.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!