In this blog post, we explore the practical implementation of utilizing Terraform on IBM Cloud to create and manage secrets by seamlessly integrating your IBM Cloud Kubernetes Service with IBM Cloud Secrets Manager.
Previously, this functionality to manage TLS and non-TLS certificates and secrets was primarily accessed through the CLI using the namespace ibmcloud ks ingress secret
. This API enables users to create an “Ingress secret” resource by passing Secrets Manager secret CRNs to the API to establish a managed corresponding secret in their Kubernetes cluster. Notably, any updates made to the secrets within the Secrets Manager instance are automatically reflected within the associated Kubernetes cluster, ensuring synchronization between the two environments.
The IBM Cloud Kubernetes Service reconciles the created Ingress secrets in the following way:
By utilizing the integration with IBM Cloud Kubernetes Service and IBM Cloud Secrets Manager, you can leverage the following benefits:
The below example shows an integration of IBM Cloud Kubernetes and IBM Cloud Secrets Manager via a Terraform script. To follow along in the full sample, go to this example. You will provision an IBM Cloud Secrets Manager instance, register it to an IBM Cloud Kubernetes Service, and create managed IBM Cloud Kubernetes Ingress secrets backed by Secrets Manager secrets.
To follow this example, you will require the following:
Create an IBM Cloud Secrets Manager instance and secret group to host your secrets. Learn more about Creating a Secrets Manager service instance:
resource "ibm_resource_instance" "sm_instance" {
name = var.sm_instance_name
service = "secrets-manager"
plan = var.sm_instance_plan
location = var.sm_instance_region
timeouts {
create = "60m"
delete = "2h"
}
}
resource "ibm_sm_secret_group" "sm_secret_group" {
instance_id = ibm_resource_instance.sm_instance.guid
region = ibm_resource_instance.sm_instance.location
name = var.sm_secret_group_name
description = var.sm_secret_group_description
}
See more about what configurations are needed to enable service-to-service communication:
resource "ibm_iam_authorization_policy" "sm_auth" {
source_service_name = "containers-kubernetes"
target_service_name = "secrets-manager"
roles = ["Manager"]
}
When you register a Secrets Manager instance to your cluster as the default, all new Ingress subdomain certificates are stored in that instance:
resource "ibm_container_ingress_instance" "instance" {
cluster = var.cluster_name_or_id
secret_group_id = ibm_sm_secret_group.sm_secret_group.secret_group_id
instance_crn = ibm_resource_instance.sm_instance.id
is_default = true
}
Create an arbitrary and username credential secret in Secrets Manager. Learn more about different secret types:
resource "ibm_sm_arbitrary_secret" "sm_arbitrary_secret" {
instance_id = ibm_resource_instance.sm_instance.guid
region = ibm_resource_instance.sm_instance.location
endpoint_type = var.sm_endpoint_type
name = var.sm_arbitrary_secret_name
description = var.sm_arbitrary_secret_description
expiration_date = var.sm_arbitrary_secret_expiration_date
labels = var.sm_arbitrary_secret_labels
secret_group_id = ibm_sm_secret_group.sm_secret_group.secret_group_id
payload = var.sm_arbitrary_secret_payload
}
resource "ibm_sm_username_password_secret" "sm_username_password_secret" {
instance_id = ibm_resource_instance.sm_instance.guid
region = ibm_resource_instance.sm_instance.location
endpoint_type = var.sm_endpoint_type
name = var.sm_username_password_secret_name
description = var.sm_username_password_secret_description
expiration_date = var.sm_username_password_secret_expiration_date
labels = var.sm_username_password_secret_labels
secret_group_id = ibm_sm_secret_group.sm_secret_group.secret_group_id
rotation {
auto_rotate = true
interval = 1
unit = "day"
}
username = var.sm_username_password_secret_username
password = var.sm_username_password_secret_password
}
Create an Ingress Opaque secret in the cluster. Now, anytime the secrets in Secrets Manager are updated, the corresponding Kubernetes Opaque secret will be updated once a day. The persistence field ensures that if a user inadvertently deletes the secret from the cluster, it will be recreated:
resource "ibm_container_ingress_secret_opaque" "secret_opaque" {
cluster = var.cluster_name_or_id
secret_name = var.opaque_secret_name
secret_namespace = var.opaque_secret_namespace
persistence = true
fields {
crn = ibm_sm_arbitrary_secret.sm_arbitrary_secret.crn
}
fields {
crn = ibm_sm_username_password_secret.sm_username_password_secret.crn
}
}
Now that you’ve gone through what each block of the Terraform script will be doing, let’s create the infrastructure.
terraform init
in your directory.main.tf
and output.tf
files from the example repo..tfvars
file and fill in the corresponding variables needed. You can learn more about what variables are needed in the variables.tf file.terraform plan -var-file=<file_name>
.terraform apply -var-file=<file_name>
.Now that these resources are created, go into the IBM Cloud Dashboard to view the created resources under Resource list:
Navigate to the created IBM Cloud Secrets Manager instance and view the created secrets:
Navigate to the IBM Cloud Kubernetes Service, click on Ingress, then select the Secrets tab to view the Opaque secret:
This sample serves as a starting point to showcase the benefits and functionality of integrating Terraform with IBM Cloud Kubernetes Service and IBM Cloud Secrets Manager. Feel free to expand and tailor this approach to fit your use case.
If you have questions, engage our team via Slack by registering here and join the discussion in the #general channel on our public IBM Cloud Kubernetes Service Slack.
The post Unleashing Terraform for Kubernetes secret management with IBM Cloud Kubernetes Service and Secrets Manager appeared first on IBM Blog.
Jasper Research Lab’s new shadow generation research and model enable brands to create more photorealistic…
We’re announcing new updates to Gemini 2.0 Flash, plus introducing Gemini 2.0 Flash-Lite and Gemini…
Interactive digital agents (IDAs) leverage APIs of stateful digital environments to perform tasks in response…
This post is co-written with Martin Holste from Trellix. Security teams are dealing with an…
As AI continues to unlock new opportunities for business growth and societal benefits, we’re working…
An internal email obtained by WIRED shows that NOAA workers received orders to pause “ALL…