Skip to content

Latest commit

 

History

History
82 lines (44 loc) · 3.52 KB

v21-12-X.md

File metadata and controls

82 lines (44 loc) · 3.52 KB

Migrate from Orchestrate v21.1.X to v21.12.X (Orchestrate Kubernetes v5.0.X to v7.0.X)

Orchestrate v21.12.X introduces major architectural and deployement changes including:

  • Keymanager has been removed in favor of a separate new key manager aka quorum-key-manager

1. Orchestrate Helm Chart

It is recommended to rely on the latest chart available here https://github.com/ConsenSys/orchestrate-helm. Check the releases, so you can pick up the current latest version, this deployment should rely on it.

2. Quorum Key Manager Helm Chart

Now that the keyManager feature is separated from orchestrate you will need to install the quorum-key-manager using its own chart which you will find here https://github.com/ConsenSys/quorum-key-manager-helm

Following project also provides a deployment which you can use either directly or as an inspiration https://github.com/ConsenSys/quorum-key-manager-kubernetes

3. Deploy Quorum Key Manager v21.12.X

Manifests

You will have to get your configuration file ready before deployment, this configuration comes in the form of a yaml file called manifests file, you may need to rely on the documentation to have it well understood and formated. Samples are also provided with the project.

You also should follow the given procedure to have the manifests well encoded.

Make sure your quorum-key-manager is reachable either from the k8s service or via tha ingress if you use that option. Orchestrate will need the new KEY_MANAGER_URLenv var to reach it.

Authentication / Authorization

Quorum key manager might be configured using the following mechanisms :

  • OIDC: Choose this in combination with your OIDC IDP server config.
  • TLS: TLS based authentication of client, use this with your certificates management policy and tools.
  • API-KEY: A set of keys that must be defined by yourself, relying on a file based source that you should edit. (see the available sample given in quorum key manager project)

4 Hashicorp Vault (optional)

In case you wish to use Hashicorp Vault as a secure store for your keys it is recommended that you use our adapted image here https://hub.docker.com/r/consensys/quorum-hashicorp-vault-plugin

This image is set as the default one in the current deployment.

5. Deploy Orchestrate v21.12.X

5.1 Configure QKM Authentication

Authentication with OIDC

You will need to provide the following env vars :

AUTH_JWT_ISSUER_URL : your access token issuer url

AUTH_JWT_AUDIENCE : the current audience of your token

AUTH_JWT_ORCHESTRATE_CLAIMS : the path to orchestrate claims within the token

Authentication with TLS

You will need to provide

KEY_MANAGER_CLIENT_TLS_CERT : < path to client cert >

KEY_MANAGER_CLIENT_TLS_KEY : < path to client key >

Authentication with API-KEY

You will need to provide

KEY_MANAGER_API_KEY: the encoded API-KEY value that you have provisioned within your quorum key manager instance

5.2 Proceed with upgrade

Once you have gathered all your helm values and the above mentionned env vars you may proceed with the upgrade, either using the above mentionned kubernetes helmfile chart or your favorite helm tool.

5.3 Cleanup (optional)

If your cluster does not have a TTL controler you could need to delete the migration Job which will remain in your namespace.

You may easily find it with : kubectl get jobs -n $ORCHESTRATE_NAMESPACE

Then deleted with : kubectl delete Job orchestrate-api-migrate-job-XXXX -n $ORCHESTRATE_NAMESPACE