Creating Secrets in K8 using Multiple Provider -Terraform

I recently got a chance to work on terraform in detail. One of the problems we solved was writing secrets to different K8 namespaces using multiple providers for Kubernetes with terraform.

So the official docs have a lot of information to interact with “Kubernetes providerhere. I have used the host and token approach to interact with K8. Let’s write a very basic provider and use it to copy secrets.

You can decide how to design your code by placing different providers in a provider.tf .(trying to bring some structure in TF)

provider “kubernetes”{

}
resource "kubernetes_secret" "example" {
metadata {
namespace = "developers"
}

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

Now what it does is it will try to find default variables as per the provider’s definition, it will search for KUBE_TOKEN and KUBE_HOST so that it knows what is the server address and what is the token value and use them to interact with the K8/namespace unless explicitly provided. If you want to dig deeper into how terraform uses the attributes, can take a look here.
But what if we have to copy secrets to a namespace= “testing” and another one “staging”/”prod”. Enter multiple providers.

provider “kubernetes”{
alias = “developers”
token = var.dev_token
}
provider “kubernetes”{
alias = “testing”
token = var.qa_token
}
provider “kubernetes”{
alias = “staging”
token = var.stag
}

what we have essentially done is given an alias to different providers for each namespace and pass the token parameter as variables that can be injected at run time and then use each provider wherever needed. And the resource declaration would look something like

resource “kubernetes_secret” “dev_secret”{
metadata = {
namespace= “developers”
}
providers = kuberenetes.developers
data={

}
//2nd one
resource “kubernetes_secret” “qa_secret”{
metadata = {
namespace= “testers”
}
providers = kuberenetes.testing
data={

}
// similarly for others…

what we have essentially done is create multiple providers using aliases and introduced variables to be assigned to token, in case you want terraform to talk to different clusters you can pass on the “host” parameter the same way we did for token. The token should have the appropriate permissions to create, update, delete secret as terraform uses the state file to create, compare and delete resources created. Now since we have explicitly mentioned the providers while creating the resource it will use the alias ( and the token) provided instead of searching for default providers and values.

Data Engineer 3 at Mongo DB