» kubernetes_secret

The resource provides mechanisms to inject containers with sensitive information, such as passwords, while keeping containers agnostic of Kubernetes. Secrets can be used to store sensitive information either as individual properties or coarse-grained entries like entire files or JSON blobs. The resource will by default create a secret which is available to any pod in the specified (or default) namespace.

» Example Usage

resource "kubernetes_secret" "example" {
  metadata {
    name = "basic-auth"
  }

  data {
    username = "admin"
    password = "P4ssw0rd"
  }

  type = "kubernetes.io/basic-auth"
}

» Example Usage (Docker config)

resource "kubernetes_secret" "example" {
  metadata {
    name = "docker-cfg"
  }

  data {
    ".dockerconfigjson" = "${file("${path.module}/.docker/config.json")}"
  }

  type = "kubernetes.io/dockerconfigjson"
}

» Argument Reference

The following arguments are supported:

» Nested Blocks

» metadata

» Arguments

  • annotations - (Optional) An unstructured key value map stored with the secret that may be used to store arbitrary metadata. By default, the provider ignores any annotations whose key names end with kubernetes.io. This is necessary because such annotations can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such annotations in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see Kubernetes reference
  • generate_name - (Optional) Prefix, used by the server, to generate a unique name ONLY IF the name field has not been provided. This value will also be combined with a unique suffix. For more info see Kubernetes reference
  • labels - (Optional) Map of string keys and values that can be used to organize and categorize (scope and select) the secret. May match selectors of replication controllers and services. By default, the provider ignores any labels whose key names end with kubernetes.io. This is necessary because such labels can be mutated by server-side components and consequently cause a perpetual diff in the Terraform plan output. If you explicitly specify any such labels in the configuration template then Terraform will consider these as normal resource attributes and manage them as expected (while still avoiding the perpetual diff problem). For more info see Kubernetes reference
  • name - (Optional) Name of the secret, must be unique. Cannot be updated. For more info see Kubernetes reference
  • namespace - (Optional) Namespace defines the space within which name of the secret must be unique.

» Attributes

  • generation - A sequence number representing a specific generation of the desired state.
  • resource_version - An opaque value that represents the internal version of this secret that can be used by clients to determine when secret has changed. For more info see Kubernetes reference
  • self_link - A URL representing this secret.
  • uid - The unique in time and space value for this secret. For more info see Kubernetes reference

» Import

Secret can be imported using its namespace and name, e.g.

$ terraform import kubernetes_secret.example default/my-secret