The CryptoMove Developer Hub

Welcome to the CryptoMove Developer Hub. You'll find comprehensive guides and documentation to help you start working with CryptoMove as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started

CryptoMove for Kubernetes

Kubernetes has a native secret manager, but the secrets are not encrypted and are stored in a static location. CryptoMove for Kubernetes improves the native secret management with a more secure solution. When you create secrets in Kubernetes, the values of those secrets are stored in the ultra-secure CryptoMove datastore rather than the default Kubernetes secret manager. The new Kubernetes secret becomes a placeholder, with the actual value protected by CryptoMove's moving target defense until it is needed.

The CryptoMove for Kubernetes plugin consists of a Mutating Admissions Webhook and CryptoMove CRD. When you create a Kubernetes secret, the Webhook automatically diverts the value of the secret into the CryptoMove datastore, inserting a placeholder in the Kubernetes secret. Then, when you need to populate the secret with its value, simply create a cmsecret object with the name of the Kubernetes secret; the CryptoMove CRD finds the name in CryptoMove and populates the secret. When the secret has been consumed, you can delete the cmsecret object to remove the local copy, leaving the original value in the CryptoMove datastore.

Once the plugin is installed, you use a simple configuration file to specify the CryptoMove datastore where you want to store the secrets. This CryptoMove datastore can be CryptoMove's SaaS product, an on-prem deployment, or a deployment on the same Kubernetes cluster that is running the CryptoMove for Kubernetes plugin.

Installing the CryptoMove for Kubernetes Plugin

CryptoMove for Kubernetes currently requires a Kubernetes cluster on an AWS server. You cannot use a Kubernetes cluster on another cloud platform.

Define Namespace and Set Context Entry

Once you have your Kubernetes cluster environment, enter the following commands to create a namespace for the Webhook pod and set the context entry to that namespace:

kubectl create namespace cryptomove
kubectl config set-context --current --namespace=cryptomove

Add the Helm Chart Repository

Before using Helm to install the Plugin, you must add the chart repository that contains cryptomove-plugin:
helm repo add cryptomove​​

You can verify that Helm can successfully find the cryptomove-plugin with the following command:
helm search cryptomove

Install the CryptoMove for Kubernetes Plugin



Before installing the CryptoMove for Kubernetes Plugin, you should read and agree to the CryptoMove EULA.

You are now ready to use Helm to install the CryptoMove for Kubernetes Plugin. Verify that you have read the CryptoMove EULA by adding the following option on the end of your helm install command: --set cryptomove.eula=true

helm install --name cryptomove-plugin cryptomove/cryptomove-plugin --set CLUSTERCABUNDLE=$(kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}') --set cryptomove.eula=true

Wait for the pods to come online before configuring the Plugin to work with a specific CryptoMove datastore.

Identify the CryptoMove Datastore

The CryptoMove for Kubernetes Plugin can store the values of Kubernetes secrets in a variety of CryptoMove deployments, including CryptoMove's SaaS product, an on-prem solution, and a deployment on the same Kubernetes cluster. Use the following procedure to specify the location and credentials of an existing CryptoMove datastore.

For remote CryptoMove datastores, you must specify the URL of the datastore along with valid credentials in a configuration file (cryptomove.cfg) that gets copied to the pods in the Plugin. The credentials can either be an access token and refresh token, or the username and password of a CryptoMove user. For more information about access tokens, see Access Tokens.

Open a text editor to create cryptomove.cfg, using the following as an example. Make sure that CRYPTOMOVE_USEAUTH is "yes".

   "CRYPTOMOVE_USERNAME": "[email protected]", 

Once you have cryptomove.cfg defined, copy it to the Webhook and CRD pods with the following commands:
kubectl cp cryptomove.cfg cryptomovehook:/app/cryptomove.cfg
kubectl cp cryptomove.cfg default/cmcontroller:/app/cryptomove.cfg

Enable the Webhook

Once you have identified your CryptoMove datastore and provided credentials, you must enable the Webhook:
kubectl label --overwrite namespace cryptomove mutateme=enabled
You are now ready to start using CryptoMove for Kubernetes.

Using CryptoMove for Kubernetes

Once you have installed the CryptoMove for Kubernetes Plugin, you simply create Kubernetes secrets as usual. The Webhook automatically puts the value of the secret into CryptoMove.

For example, suppose you create a Kubernetes secret with the following command:
kubectl create secret generic my-secret --from-literal=key1=ey8L2dSecretValue

The new secret, my-secret, is created in both the Kubernetes secret manager and CryptoMove. The value of the Kubernetes secret is a placeholder while the value of the CryptoMove secret is ey8L2dSecretValue. You can verify that the Kubernetes secret does contains the actual secret value by entering:
kubectl get secret my-secret -o yaml

Notice that the data key:value pair in the YAML file does not contain the secret value ey8L2dSecretValue.

Populating a Secret with its True Value

When you want to populate the Kubernetes secret with the value from the CryptoMove datastore, you create a cmsecret object with the same name as the secret. This is a two-step process:

  1. Define the cmsecret object in a YAML file.
  2. Create the cmsecret object by running the kubectl create -f command on the YAML file.

Define the cmsecret object

Before creating a cmsecret object, you must define it in a YAML file. In the following example of a cmsecret object definition, the name of the Kubernetes secret that you want to populate is my-secret. Simply replace this name with the actual name of your Kubernetes secret.

apiVersion: cm.cryptomove.local/v1 
kind: cmsecret 
  name: my-secret 
  type: "A cm secret" 
  populated: false

Create the cmsecret Object

Once you have the cmsecret object defined in a YAML file, you simply pass the name of the file as an argument to the kubectl create command. For example, if you named the YAML file mycmsecret.yaml, create the new cmsecret object by running:

kubectl create -f mycmsecret.yaml

You can verify that the cmsecret object was created by entering:
kubectl get cmsecret my-secret -o yaml
In the following example response, the most important key:value pair is populated: true. This indicates that the Plugin found the secret in the CryptoMove datastore and populated the secret with its value.

apiVersion: cm.cryptomove.local/v1
kind: cmsecret
  annotations: |
      {"apiVersion":"cm.cryptomove.local/v1","kind":"cmsecret","metadata":{"annotations":{},"name":"my-secret","namespace":"cryptomove"},"spec":{"populated":false,"type":"A cm secret"}}
  creationTimestamp: 2019-09-10T19:27:23Z
  generation: 1
  name: my-secret
  namespace: cryptomove
  resourceVersion: "20469"
  selfLink: /apis/cm.cryptomove.local/v1/namespaces/cryptomove/cmsecrets/my-secret
  uid: 03ebe011-d401-11e9-80f6-025d7f5edb20
  populated: true
  status: Populated secret from CryptoMove datastore
  type: A cm secret

You can also verify that the Kubernetes secret is now populated with the actual value from CryptoMove by viewing the secret:
kubectl get secret my-secret -o yaml

Deleting the cmsecret Object

Once your Kubernetes environment is done with the secret, you can return the value of the Kubernetes secret to the placeholder so the only true value is stored in CryptoMove. Simply deleting the cmsecret object is enough to remove the value from the Kubernetes secret and replace it with the placeholder. For example, enter:
kubectl delete cmsecret my-secret

Updated about a year ago

CryptoMove for Kubernetes

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.