How to: Configure KubeTruth

In the previous blog post, What Is Kubetruth, you learned all about why CloudTruth created Kubetruth and how it can work for you in any environment to ensure parameters, secrets, and variables have a source of truth. Now that you know what Kubetruth is, it’s time to configure it for use.

In this blog post, you’ll learn how to configure Kubetruth in under five minutes to get your Kubernetes cluster connected to CloudTruth.

Prerequisites

To follow along with this blog post, you’ll learn:

• A Kubernetes cluster. This can either be in the cloud, on-prem, or even using Minikube/Docker Desktop on your local computer

Preparing CloudTruth

First things first, you’ll need a project in CloudTruth and some parameters for Kubernetes.

For the purposes of this blog post, you can create a new CloudTruth project called kubernetes-secrets.

cloudtruth --project kubernetes-secrets

Next, create some new parameters in the kubernetes-secretsproject. Notice how the parameters can be anything from the name of a Docker image to ports. In this case, the parameters are for an Nginx Kubernetes deployment.

cloudtruth --project kubernetes-secrets parameter set --value nginx app_name
cloudtruth --project kubernetes-secrets parameter set --value 3 replicas
cloudtruth --project kubernetes-secrets parameter set --value 80 port
cloudtruth --project kubernetes-secrets parameter set --value nginx image_name
cloudtruth --project kubernetes-secrets parameter set --value latest nginx_version

When you log into CloudTruth, you’ll be able to see the new project and parameters.

Create A Kubernetes Manifest

For Kubetruth to push parameter updates to your environment, it needs to be able to see parameters and a Kubernetes manifest. In the previous section, you set up the CloudTruth project and parameters. In this section, you’ll create a Kubernetes manifest and send it to CloudTruth.

In the Kubernetes manifest below, you’ll see that it’s running a Deployment spec that calls out the parameter names that you created in the previous section. Any parameter with curly brackets around it means that’s a value that CloudTruth will consume. For example .

apiVersion: apps/v1
kind: Deployment
metadata:
  name: 
  namespace: default
  labels:
    app: 
spec:
  replicas: 
  selector:
    matchLabels:
      app: 
  template:
    metadata:
      labels:
        app: 
    spec:
      containers:
      - name: 
        image: :
        ports:
        - containerPort: 

Save the above manifest in a location of your choosing and name it deployment.yaml.

Ensure that you’re in the directory that you saved the deployment.yaml to via your terminal.

Push the Kubernetes manifest to CloudTruth by running the following command which does the following:

• Sets your CloudTruth project
• Tells CloudTruth that you’re setting a new template
• Giving the name of the Kubernetes manifest
• Naming it deployment in CloudTruth

cloudtruth --project 'kubernetes-secrets' template set --body deployment.yaml deployment

You’ll now see the Kubernetes manifest in the templates section of CloudTruth underneath your project.

Configuring KubeTruth

In the previous sections, you set up:

• CloudTruth parameters
• A Kubernetes manifest that will ingest the parameters

Now it’s time to dive into setting up KubeTruth.

In the same directory that the deployment.yamlKubernetes manifest exists in from the previous section, create a new file called ctdeploytest-values.yaml.

Add in the Kubernetes operator configuration which you’ll find below and does the following:

• Gives Kubetruth access to look at Deployments, ReplicaSets, Pods, and Services
• Defines the project selector. For example, on line 27, you’ll see that the kubernetes-secrets project is defined.
• Defines what type of templates to utilize. For example, you’ll see under resource_templates on line 28 that you can use Deployment and Service specs.

# Applying deployment resources requires additional permissions
rbac:
  additionalRoleRules:
    - apiGroups: ["", "extensions", "apps"]
      resources: ["deployments", "replicasets", "pods", "services"]
      verbs: ["*"]

# Kubetruth is configured using a CustomResourceDefinition called
# ProjectMapping, which allows one to specify how the operator
# transforms the data from your CloudTruth projects into kuberenetes
# resources
projectMappings:

  # Define the root project mapping, skipping all projects except for the
  # example we care about
  root:
    scope: "root"
    environment: default
    skip: true

  # Define an override ProjectMapping to enable deployment of CloudTruth projects named k8s*
  k8s-deploy:
    scope: "override"
    skip: false
    # For the project selector, you have to choose the CloudTruth project
    ## Example below
    project_selector: "kubernetes-secrets"
    resource_templates:
      deployment: ''
      service: ''

Once the Kubernetes operator is saved, you can install the Kubetruth Helm Chart. The Kubetruth Helm Chart configures the ctdeploytest-values.yaml to run as an Operator on the Kubernetes cluster. The Operator looks for the Kubernetes manifest template inside of your CloudTruth project along with the parameters.

Ensure to set an API key from your CloudTruth org.

helm repo add cloudtruth https://packages.cloudtruth.com/charts/
helm install --values ctdeploytest-values.yaml --set appSettings.apiKey=$CLOUDTRUTH_API_KEY kubetruth cloudtruth/kubetruth

In a few minutes, you’ll see the Nginx configuration running as a Kubernetes deployment inside of your Kubernetes cluster.

Wrapping Up

One of the best things about Kubernetes is the ability to extend its features using open-source methodologies. CloudTruth utilized this to create Kubetruth, which has the goal of making Kubernetes easier for you in any environment.

Check out more details on the CloudTruth Kubernetes integration and open source Kubernetes operator.

If you’d like to get started with CloudTruth today, there is a free forever version here.

Here’s a short video on this topic: