Kubernetes secrets store your sensitive information such as your CloudTruth API key or any secrets required by your specific app. You can manage K8s secrets multiple ways.
Create a CLOUDTRUTH_API_KEY secret
The **kubectl create secret command will create a base64 encoded K8s secret. You can directly provide CLOUDTRUTH_API_KEY="YOUR_TOKEN" as a literal to use in your pods with the CloudTruth CLI.
You can also store your secrets in CloudTruth and pass them directly to kubectl with the CloudTruth CLI. Here we have a parameter CLOUDTRUTH_API_KEYcreated in CloudTruth and use the following cli command to retrieve and pass the value in one step.
You can also create K8s secrets by applying a yaml secret file. The secret must be base64 encoded in the yaml file itself.
1
apiVersion: v1
2
kind: Secret
3
type: Opaque
4
metadata:
5
name: my-secrets
6
data:
7
CLOUDTRUTH_API_KEY: ZjAwbDNkeTB1
8
MY_PASSWORD: c3VwZXJzZWNyZXRwYXNzd29yZA==
Copied!
K8s Secrets can then be accessed in standard ways. You can access your CloudTruth API key as an environment variable inside your Deployment yaml with envFrom.
1
spec:
2
containers:
3
- name: secrets-example
4
image: my-container-image
5
envFrom:
6
- secretRef:
7
name: my-secrets
Copied!
Review the K8s Secrets docs for details on how secrets are stored as unencrypted base64-encoded strings.
K8s ConfigMaps
Kubernetes ConfigMaps allow you to store non secret type data in key-value pairs that can be consumed by pods in various ways. ConfigMaps can be built from parameters managed directly in CloudTruth providing you flexibility to build out a hierarchy of K8s projects and environments with unique keys and values.
Once your ConfigMap parameters are added to CloudTruth, create a CloudTruth ConfigMap template.
This is an example CloudTruth template for a flask application ConfigMap. CloudTruth will automatically populate values based on your specified environment.
1
kind: ConfigMap
2
apiVersion: v1
3
metadata:
4
name: flask-configmap
5
data:
6
FLASK_APP: {{FLASK_APP}}
7
FLASK_ENV: {{FLASK_ENV}}
8
FLASK_MESSAGE: {{FLASK_MESSAGE}}
9
FLASK_RUN_HOST: "{{FLASK_RUN_HOST}}"
10
FLASK_RUN_PORT: "{{FLASK_RUN_PORT}}"
Copied!
Now you can easily create ConfigMaps across your customized projects and environments. This will directly apply a ConfigMap by using the CloudTruth cli to dynamically generate parameters from a template flask-configmap in project Flask.
1
kubectl apply -f <(cloudtruth --project Flask templates get flask-configmap)
Copied!
Alternatively you can also use CloudTruth templates to generate yaml files for your configmaps.
1
cloudtruth --project Flask templates get flask-configmap > flask-configmap.yaml
Copied!
KubeTruth
With the ever growing number of services, managing a K8s deployment brings continuously expanding configuration complexity.
KubeTruth integrates with CloudTruth providing you an automated K8s configuration management system.
KubeTruth is designed to dynamically build and update K8s ConfigMaps and Secrets while providing you centralized control over your data across a sprawling combination of projects and environments.
You can get started by adding the CloudTruth repo to Helm.
You can now use helm to install KubeTruth in a dedicated namespace demokubetruth. Provide your CloudTruth API Key and the targeted CloudTruth environment.
1
helm install \
2
--create-namespace --namespace demokubetruth \
3
--set appSettings.apiKey=<api_key> \
4
--set appSettings.environment=<environment> \
5
kubetruth-install cloudtruth/kubetruth
Copied!
Once installed KubeTruth will create ConfigMaps and Secrets for each CloudTruth project. It will dynamically poll CloudTruth and update any changes directly within K8s! This provides you a centralized management source for your pods configuration values.
ConfigMaps and Secrets managed by KubeTruth get created with a label: app.kubernetes.io/managed-by: kubetruth
You can find KubeTruth created resources with the -l option.
1
kubectl get configmaps -l app.kubernetes.io/managed-by=kubetruth -A
Copied!
1
kubectl get secrets -l app.kubernetes.io/managed-by=kubetruth -A
Copied!
Customizing KubeTruth
Project requirements differ so KubeTruth allows customization with a Project Mapping Custom Resource Definition. This allows you to manage resources with standard K8s practices.
Here are some common use case examples of configuring the root installation and working with the CRD overrides.
Deploy CloudTruth projects to dedicated namespaces
Patch projectMappings.root.spec.context.resource_namespace to create a namespace per CloudTruth project.
If you have a common set of parameters that you would like to be present in all of your ConfigMaps and Secrets you can specify a project to import it's parameters across other projects.
You can patch projectMappings.root.spec.included_projects which will import all Parameters from a CloudTruth project named base into our other configmaps and secrets.
Inheritance is non-recursive. If project A imports B and B imports C, then A will only get B's parameters. For key conflicts, if project A includes [B, C], then the precedence is A overrides C overrides B.
Override spec
You can create a kind: ProjectMapping with an override scope for customization of naming conventions and key filters. This allows you to create custom configmaps and secrets that do not have to follow the exact project layout in CloudTruth.
1
kubectl apply -n demokubetruth -f - <<EOF
2
apiVersion: kubetruth.cloudtruth.com/v1
3
kind: ProjectMapping
4
metadata:
5
name: custom-pm-override
6
spec:
7
scope: override
8
project_selector: MY_PROJECT
9
key_filter: FOO
10
context:
11
resource_name: custom-name
12
resource_namespace: custom-ns-name
13
EOF
Copied!
Let's break down what the options in this override spec does to the resources it will create.
spec
override
project_selector
Regex to to use CloudTruth project MY_PROJECT.
key_selector
Regex to limit the key fetched in the project to contains FOO.
context.resource_name
Renames the ConfigMap and Secret to custom-name
context.resource_namespace
Creates resources in new namespace custom-ns-name
There are a wide variety of override options. Here is the full usage chart.
Take caution when applying generic overrides as they can affect all resources. Overrides can be can be combined with a project_selector to ensure they do not affect all project configmaps and secrets.
You can view your CRD root and override configurations with kubectl.
KubeTruth can also dynamically apply directly from a project template. This can be useful when you want customized configmaps or even application deployments. KubeTruth will look for templates to apply by specifying them as templates.NAME. The following override will apply CloudTruth template game-demo-template in project configmap. The template is formed as a ConfigMap in CloudTruth.
1
apiVersion: kubetruth.cloudtruth.com/v1
2
kind: ProjectMapping
3
metadata:
4
name: template-config
5
namespace: demokubetruth
6
spec:
7
skip: false
8
scope: "override"
9
project_selector: "configmap"
10
resource_templates:
11
configmap: |
12
{{ templates.game-demo-template }}
13
secret: ""
Copied!
Customizing Installation
You can also customize the desired behavior of KubeTruth at install time using the Project Mapping Custom Resource Definition with Helm. All of the current override specs can be used at install time.
Installation that configures a specific project
So you don't want KubeTruth to create ConfigMaps and Secrets for all of your services at go?
Here is an example that sets the Project Mapping root to skip all projects on installation. It then specifies an override CRD called myoverride that will select project MY_PROJECTto be the only one configured at install time.