R3 Docs R3 Docs Home

Manual Bootstrapping heading-link-icon

By default, the Corda installation process automatically performs various setup actions in Kafka The means by which Corda workers communicate, acting as a central message bus between the worker processes. , the database, and for Corda RBAC. If you require additional control, you can disable these automatic setup processes and an administrator can manually perform the actions with the assistance of the Corda CLI.

This section describes how to configure the following:

When you have completed the manual configuration of the above, you can Deploy Corda.

By default, a Corda installation automatically creates the Kafka topics it requires. The following sections describe how to create the topics manually:

To disable the automatic creation of topics, do the following:

  1. Set the following override in the deployment configuration:

    bootstrap:
  kafka:
    enabled: false

  2. Create a Kafka client properties file. The following is an example properties file for a Kafka cluster using TLS Transport Layer Security. A protocol that establishes an encrypted session between two computers on the Internet. and SASL authentication:

    security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-256
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="<USERNAME>" password="<PASSWORD>" ;
ssl.truststore.location=ca.crt
ssl.truststore.type=PEM

    The examples that follow assume that this file is named config.properties.

Use the Corda CLI A command line tool that supports various Corda-related tasks, including Corda Package Installer (CPI) creation and Corda cluster management. to assist in the creation of the topics prior to Corda installation in one of two ways:

For information about the Corda CLI topic command’s arguments, see the Corda CLI reference.

Use the connect sub-command of the Corda CLI create sub-command to connect to the Kafka broker and create any required topics:

corda-cli.sh topic -b <BOOTSTRAP-SERVERS> -k <CLIENT-PROPERTIES-FILE> create -r <REPLICAS> -p <PARTITIONS> connect

corda-cli.cmd topic -b <BOOTSTRAP-SERVERS> -k <CLIENT-PROPERTIES-FILE> create -r <REPLICAS> -p <PARTITIONS> connect

For example:

corda-cli.sh topic -b kafka-1.example.com -k config.properties create -r 3 -p 10 connect

corda-cli.cmd topic -b kafka-1.example.com -k config.properties create -r 3 -p 10 connect

Alternatively, the Corda CLI can generate a preview of the required Kafka topic configuration in YAML. You can save, and if required modify, this content before using the Corda CLI to execute it, as follows:

  1. Use the preview sub-command of the Corda CLI create sub-command to generate a preview of the configuration:

    corda-cli.sh topic -b <BOOTSTRAP-SERVERS> -k <CLIENT-PROPERTIES-FILE> create -r <REPLICAS> -p <PARTITIONS> preview

    corda-cli.cmd topic -b <BOOTSTRAP-SERVERS> -k <CLIENT-PROPERTIES-FILE> create -r <REPLICAS> -p <PARTITIONS> preview

    For example:

    corda-cli.sh topic -b kafka-1.example.com -k config.properties create -p 1 -r 1 -u preview

    corda-cli.cmd topic -b kafka-1.example.com -k config.properties create -p 1 -r 1 -u preview

  2. Review the output, make any necessary changes, and save the configuration to a file.

  3. Use the connect sub-command with the -f argument to connect to the Kafka broker and execute the configuration:

    corda-cli.sh topic -b <BOOTSTRAP-SERVERS> -k <CLIENT-PROPERTIES-FILE> create -r <REPLICAS> -p <PARTITIONS> connect -f <YAML-TOPIC-FILE>

    corda-cli.cmd topic -b <BOOTSTRAP-SERVERS> -k <CLIENT-PROPERTIES-FILE> create -r <REPLICAS> -p <PARTITIONS> connect -f <YAML-TOPIC-FILE>

    For example:

    corda-cli.sh topic -b kafka-1.example.com -k config.properties create -r 3 -p 10 connect -f topics.yaml

    corda-cli.cmd topic -b kafka-1.example.com -k config.properties create -r 3 -p 10 connect -f topics.yaml

If you are authenticating Kafka users, the Corda CLI can also create Access Control List (ACL) entries as appropriate for each Corda worker JVM processes that run in a cluster and perform a specific task. The processes required to form a cluster depend on the deployment topology. Workers increase or scale back their capacity depending on the number of available tasks. . Specify a set of name-value pairs giving the Kafka username that will be used for each Corda worker:

corda-cli.sh topic -b <BOOTSTRAP-SERVERS> -k config.properties \
create -r <REPLICAS> -p <PARTITIONS> \
-u crypto=<CRYPTO_USER> -u db=<DB_USER> -u flow=<FLOW_USER>  -u flowMapper=<FLOWMAPPER_USER> -u membership=<MEMBERSHIP_USER> \
-u p2pGateway=<P2P_GATEWAY_USER> -u p2pLinkManager=<P2P_LINK_MANAGER_USER> -u rest=<REST_USER> \
connect

corda-cli.cmd topic -b <BOOTSTRAP-SERVERS> -k config.properties `
create -r <REPLICAS> -p <PARTITIONS> `
-u crypto=<CRYPTO_USER> -u db=<DB_USER> -u flow=<FLOW_USER> -u flowMapper=<FLOWMAPPER_USER> -u membership=<MEMBERSHIP_USER> `
-u p2pGateway=<P2P_GATEWAY_USER> -u p2pLinkManager=<P2P_LINK_MANAGER_USER> -u rest=<REST_USER>
connect

By default, a Corda installation automatically creates and populates the database schema it requires.

To create the schema manually, set the following override in the deployment configuration to disable the automatic creation:

bootstrap:
  db:
    enabled: false

Create and populate the database schema, as follows:

  1. Create the database tables.
  2. Populate the RBAC database connection configuration.
  3. Populate the crypto database connection configuration.
  4. Populate the virtual nodes database connection configuration.
  5. Populate the REST admin user.
  6. Create the RBAC and crypto users.
  7. Populate the crypto configuration.

  1. Use the Corda CLI to generate DML files for creating the database tables to use for each of the crypto, config, and rbac components.

    The following command specifies that the CONFIG, RBAC, and CRYPTO schema should be used for the corresponding components and generates the files in the directory /tmp/db:

    corda-cli.sh database spec -g config:CONFIG,rbac:RBAC,crypto:CRYPTO -c -l /tmp/db

    corda-cli.cmd database spec -g config:CONFIG,rbac:RBAC,crypto:CRYPTO -c -l /tmp/db

    For information about the Corda CLI database command’s arguments, see the Corda CLI reference.

  2. Review the DML files generated and then execute against the database.

  3. For each state type and schema (see State Manager Databases), generate the DML file for creating the state manager database table. The following command specifies that the STATE_MANAGER schema should be used for the state manager and generates the file in the /tmp/statemanager directory:

    corda-cli.sh database spec -s "statemanager" -g "statemanager:state_manager" -c -l /tmp/state-manager

    corda-cli.cmd database spec -s "statemanager" -g "statemanager:state_manager" -c -l /tmp/state-manager

  4. Review the DML file generated and execute it against each of the State Manager databases.

Depending on your installation, follow the steps in one of the following sections to generate DDL for populating the RBAC database connection configuration:

  1. Execute the following Corda CLI command to generate DDL for populating the RBAC Role-based access control. Also known as role-based security. A permission system to restrict system access based on assigned permissions. database connection configuration:

    corda-cli.sh initial-config create-db-config -u <RBAC-USERNAME> -p <RBAC-PASSWORD> \
  --name corda-rbac --jdbc-url 'jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>?currentSchema=RBAC' \
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> \
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> --salt <SALT> --passphrase <PASSPHRASE> -l /tmp/db

    corda-cli.cmd initial-config create-db-config -u <RBAC-USERNAME> -p <RBAC-PASSWORD> `
  --name corda-rbac --jdbc-url jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>?currentSchema=RBAC `
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> `
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> --salt <SALT> --passphrase <PASSPHRASE> -l /tmp/db

    The <SALT> and <PASSPHRASE> are used to encrypt the credentials in the database. These must match the values specified in the Corda deployment configuration.

    For example:

    corda-cli.sh initial-config create-db-config -u rbacuser -p rc9VLHU3 \
  --name corda-rbac --jdbc-url 'jdbc:postgresql://postgres.example.com:5432/cordacluster?currentSchema=RBAC' \
  --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 \
  --validation-timeout 5 --salt X3UaCpUH --passphrase UUWLhD8S -l /tmp/db

    corda-cli.cmd initial-config create-db-config -u rbacuser -p rc9VLHU3 `
   --name corda-rbac --jdbc-url jdbc:postgresql://postgres.example.com:5432/cordacluster?currentSchema=RBAC `
   --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 `
   --validation-timeout 5 --salt X3UaCpUH --passphrase UUWLhD8S -l /tmp/db

    For information about the Corda CLI create-db-config command’s arguments, see the Corda CLI reference.

  2. Review the DDL files generated and then execute against the database, ensuring that you apply them to the CONFIG schema.

  1. Execute the following Corda CLI command to generate DDL for populating the RBAC database connection configuration:

    corda-cli.sh initial-config create-db-config -u <RBAC-USERNAME> \
   --name corda-rbac --jdbc-url 'jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>?currentSchema=RBAC' \
   --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> \
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> -t VAULT --vault-path <path-to-corda-created-secrets> --key rbac -l /tmp/db

    corda-cli.cmd initial-config create-db-config -u <RBAC-USERNAME> `
  --name corda-rbac --jdbc-url jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>?currentSchema=RBAC `
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> `
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> -t VAULT --vault-path <path-to-corda-created-secrets> --key rbac -l /tmp/db

    The Vault parameters are used to retrieve encrypted values from the external secrets service. These must match the values specified in the Corda deployment configuration.

    For example:

    corda-cli.sh initial-config create-db-config -u rbacuser \
   --name corda-rbac --jdbc-url 'jdbc:postgresql://prereqs-postgres:5432/cordacluster?currentSchema=RBAC' \
   --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 \
  --validation-timeout 5 -t VAULT --vault-path dbsecrets --key rbac -l /tmp/db

    corda-cli.cmd initial-config create-db-config -u rbacuser `
  --name corda-rbac --jdbc-url jdbc:postgresql://prereqs-postgres:5432/cordacluster?currentSchema=RBAC `
  --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 `
  --validation-timeout 5 -t VAULT --vault-path dbsecrets --key rbac -l /tmp/db

    For information about the Corda CLI create-db-config command’s arguments, see the Corda CLI reference.

  2. Review the DDL files generated and then execute against the database, ensuring that you apply them to the CONFIG schema.

Depending on your installation, follow the steps in one of the following sections to generate DDL for populating the CRYPTO database connection configuration:

  1. Execute the following Corda CLI command to generate DDL for populating the Crypto database connection configuration:

    corda-cli.sh initial-config create-db-config -u <CRYPTO-USERNAME> -p <CRYPTO-PASSWORD> \
  --name corda-crypto --jdbc-url `jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>?currentSchema=CRYPTO` \
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> \
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> --salt <SALT> --passphrase <PASSPHRASE> -l /tmp/db

    corda-cli.cmd initial-config create-db-config -u <CRYPTO-USERNAME> -p <CRYPTO-PASSWORD> `
  --name corda-crypto --jdbc-url jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>?currentSchema=CRYPTO `
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> `
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> --salt <SALT> --passphrase <PASSPHRASE> -l /tmp/db

    The <SALT> and <PASSPHRASE> must match those used above and specified in the Corda deployment configuration.

    For example:

    corda-cli.sh initial-config create-db-config -u cryptouser -p TqoCp4v2 \
  --name corda-crypto --jdbc-url 'jdbc:postgresql://postgres.example.com:5432/cordacluster?currentSchema=CRYPTO' \
  --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 \
  --validation-timeout 5 --salt X3UaCpUH --passphrase UUWLhD8S -l /tmp/db

    corda-cli.cmd initial-config create-db-config -u cryptouser -p TqoCp4v2 `
  --name corda-crypto --jdbc-url jdbc:postgresql://postgres.example.com:5432/cordacluster?currentSchema=CRYPTO `
  --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 `
  --validation-timeout 5 --salt X3UaCpUH --passphrase UUWLhD8S -l /tmp/db

    For information about the Corda CLI create-db-config command’s arguments, see the Corda CLI reference.

  2. Review the DDL files generated and then execute against the database, ensuring that you apply them to the CONFIG schema.

  1. Execute the following Corda CLI command to generate DDL for populating the Crypto database connection configuration:

    corda-cli.sh initial-config create-db-config -u <CRYPTO-USERNAME> \
  --name corda-crypto --jdbc-url `jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>?currentSchema=CRYPTO` \
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> \
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> -t VAULT --vault-path <path-to-corda-created-secrets> --key crypto -l /tmp/db

    corda-cli.cmd initial-config create-db-config -u <CRYPTO-USERNAME> `
  --name corda-crypto --jdbc-url jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>?currentSchema=CRYPTO `
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> `
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> -t VAULT --vault-path <path-to-corda-created-secrets> --key crypto -l /tmp/db

    The Vault parameters are used to retrieve encrypted values from the external secrets service. These must match the values specified in the Corda deployment configuration.

    For example:

    corda-cli.sh initial-config create-db-config -u cryptouser \
  --name corda-crypto --jdbc-url 'jdbc:postgresql://postgres.example.com:5432/cordacluster?currentSchema=CRYPTO' \
  --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 \
  --validation-timeout 5 -t VAULT --vault-path dbsecrets --key crypto -l /tmp/db

    corda-cli.cmd initial-config create-db-config -u cryptouser `
  --name corda-crypto --jdbc-url jdbc:postgresql://postgres.example.com:5432/cordacluster?currentSchema=CRYPTO `
  --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 `
  --validation-timeout 5 -t VAULT --vault-path dbsecrets --key crypto -l /tmp/db

    For information about the Corda CLI create-db-config command’s arguments, see the Corda CLI reference.

  2. Review the DDL files generated and then execute against the database, ensuring that you apply them to the CONFIG schema.

Depending on your installation, follow the steps in one of the following sections to generate DDL for populating the VIRTUAL_NODE database connection configuration:

  1. Execute the following Corda CLI command to generate DDL for populating the virtual nodes database connection configuration:

    corda-cli.sh initial-config create-db-config -u <VNODE-USERNAME> -p <VNODE-PASSWORD> \
  --name corda-virtual-nodes --jdbc-url 'jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>' \
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> \
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> --salt <SALT> --passphrase <PASSPHRASE> -l /tmp/db \
  --is-admin

    corda-cli.cmd initial-config create-db-config -u <VNODE-USERNAME> -p <VNODE-PASSWORD> `
  --name corda-virtual-nodes --jdbc-url jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME> `
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> `
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> --salt <SALT> --passphrase <PASSPHRASE> -l /tmp/db `
  --is-admin

  2. Review the DDL files generated and then execute against the database, ensuring that you apply them to the CONFIG schema.

  1. Execute the following Corda CLI command to generate DDL for populating the virtual nodes database connection configuration:

    corda-cli.sh initial-config create-db-config -u <VNODE-USERNAME> \
  --name corda-virtual-nodes --jdbc-url 'jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME>' \
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> \
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> -t VAULT --vault-path <path-to-corda-created-secrets> --key vnodes -l /tmp/db \
  --is-admin

    corda-cli.cmd initial-config create-db-config -u <VNODE-USERNAME> `
  --name corda-virtual-nodes --jdbc-url jdbc:postgresql://<DB-HOST>:<DB-PORT>/<DB=NAME> `
  --jdbc-pool-max-size <MAX-POOL-SIZE> --jdbc-pool-min-size <MIN-POOL-SIZE> --idle-timeout <TIMEOUT> `
  --max-lifetime <LIFETIME> --keepalive-time <LIVENESS> --validation-timeout <TIMEOUT> -t VAULT --vault-path <path-to-corda-created-secrets> --key vnodes -l /tmp/db `
  --is-admin

    For example:

    corda-cli.sh initial-config create-db-config -u <VNODE-USERNAME> \
  --name corda-virtual-nodes --jdbc-url 'jdbc:postgresql://prereqs-postgres:5432/cordacluster' \
  --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 \
  --validation-timeout 5 -t VAULT --vault-path dbsecrets --key vnodes -l /tmp/db \
  --is-admin

    corda-cli.cmd initial-config create-db-config -u <VNODE-USERNAME> `
  --name corda-virtual-nodes --jdbc-url jdbc:postgresql://prereqs-postgres:5432/cordacluster `
  --jdbc-pool-max-size 5 --jdbc-pool-min-size 1 --idle-timeout 100 --max-lifetime 1000 --keepalive-time 60 `
  --validation-timeout 5 -t VAULT --vault-path dbsecrets --key vnodes -l /tmp/db `
  --is-admin

  2. Review the DDL files generated and then execute against the database, ensuring that you apply them to the CONFIG schema.

  1. Execute the following Corda CLI command to generate DDL for populating the initial REST admin user for Corda:

    corda-cli.sh initial-config create-user-config -u <INITIAL-ADMIN-USERNAME> -p <INITIAL-ADMIN-PASSWORD> -l /tmp/db

    corda-cli.cmd initial-config create-user-config -u <INITIAL-ADMIN-USERNAME> -p <INITIAL-ADMIN-PASSWORD> -l /tmp/db

    For more information about the Corda CLI create-user-config command’s arguments, see the Corda CLI reference.

  2. Review the DDL files generated and then execute against the database, ensuring that you apply them to the RBAC schema.

The cluster database user is the user set in the config.username field under each Corda worker that interacts with the cluster database (see deployment configuration). For each Corda Worker that interacts with the cluster database, grant access to the user as follows:

GRANT USAGE ON SCHEMA "CONFIG" TO "<CONFIG-DB-USERNAME>";
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA "CONFIG" TO "<CONFIG-DB-USERNAME>";
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA "CONFIG" TO "<CONFIG-DB-USERNAME>";
ALTER ROLE <CONFIG-DB-USERNAME> SET search_path TO "CONFIG";

Using the values defined for RBAC-USERNAME and RBAC-PASSWORD in Populate the RBAC database connection configuration, create the RBAC user and grant access as follows:

CREATE USER "<RBAC-USERNAME>" WITH ENCRYPTED PASSWORD '<RBAC-PASSWORD>';
GRANT USAGE ON SCHEMA "RBAC" to "<RBAC-USERNAME>";
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA "RBAC" to "<RBAC-USERNAME>";
ALTER ROLE "<RBAC-USERNAME>" SET search_path TO "RBAC";

Using the values defined for CRYPTO-USERNAME and CRYPTO-PASSWORD in Populate the crypto database connection configuration, create the Crypto user and grant access as follows:

CREATE USER "<CRYPTO-USERNAME>" WITH ENCRYPTED PASSWORD '<CRYPTO-PASSWORD>';
GRANT USAGE ON SCHEMA "CRYPTO" to "<CRYPTO-USERNAME>";
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA "CRYPTO" to "<CRYPTO-USERNAME>";
ALTER ROLE "<CRYPTO-USERNAME>" SET search_path TO "CRYPTO";

Using the values defined for VNODE-USERNAME and VNODE-PASSWORD in [Populate the virtual nodes database connection configuration, create the virtual node user and grant access as follows:

CREATE USER "<VNODE-USERNAME>" WITH ENCRYPTED PASSWORD '<VNODE-PASSWORD>';
GRANT USAGE ON SCHEMA "VIRTUAL_NODE" to "<VNODE-USERNAME>";
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA "VIRTUAL_NODE" to "<VNODE-USERNAME>";
ALTER ROLE "<VNODE-USERNAME>" SET search_path TO "VIRTUAL_NODE";

As mentioned in State Manager Databases, Corda workers use individual sets of credentials for accessing any particular state type. These credentials are configured at the Corda worker level, under stateManager.<STATE_TYPE>.username and stateManager.<STATE_TYPE>.password. By default, different state types are assigned to different database schemas and so you must grant access carefully.

STATE-MANAGER-USERNAME
STATE-MANAGER-PERMISSIONS
STATE-MANAGER-SCHEMA
flow.stateManager.flowCheckpoint.usernameSELECT, INSERT, UPDATE, DELETEsm_flow_checkpoint
flowMapper.stateManager.flowMapping.usernameSELECT, INSERT, UPDATE, DELETEsm_flow_mapping
rest.stateManager.flowStatus.usernameSELECT, INSERT, UPDATE, DELETEsm_flow_status
rest.stateManager.keyRotation.usernameSELECTsm_key_rotation
crypto.stateManager.keyRotation.usernameSELECT, INSERT, UPDATE, DELETEsm_key_rotation
p2pLinkManager.stateManager.p2pSession.usernameSELECT, INSERT, UPDATE, DELETEsm_p2p_session
tokenSelection.stateManager.tokenPoolCache.usernameSELECT, INSERT, UPDATE, DELETEsm_token_pool_cache

Using the table above as reference, and going from top to bottom, grant access to the user as follows:

GRANT USAGE ON SCHEMA "<STATE-MANAGER-SCHEMA>" TO "<STATE-MANAGER-USERNAME>";
GRANT <STATE-MANAGER-PERMISSIONS> ON ALL TABLES IN SCHEMA "<STATE-MANAGER-SCHEMA>" TO "<STATE-MANAGER-USERNAME>";
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA "<STATE-MANAGER-SCHEMA>" TO "<STATE-MANAGER-USERNAME>";
ALTER ROLE "<STATE-MANAGER-USERNAME>" SET search_path TO "<STATE-MANAGER-SCHEMA>";

Depending on your installation, follow the steps in one of the following sections to generate DDL for populating the initial crypto configuration:

  1. Execute the following Corda CLI command to generate DDL for populating the initial crypto configuration:

    corda-cli.sh initial-config create-crypto-config --salt <SALT> --passphrase <PASSPHRASE> -l /tmp/db

    corda-cli.cmd initial-config create-crypto-config --salt <SALT> --passphrase <PASSPHRASE> -l /tmp/db

    The <SALT> and <PASSPHRASE> must match those used above and specified in the Corda deployment configuration. For more information about the Corda CLI create-crypto-config command’s arguments, see the Corda CLI reference.

  2. Review the DDL files generated and then execute against the database, ensuring that you apply them to the CONFIG schema.

  1. Execute the following Corda CLI command to generate DDL for populating the initial crypto configuration:

    corda-cli.sh initial-config create-crypto-config -t VAULT -v cryptosecrets -ks salt -kp passphrase -l /tmp/db

    corda-cli.cmd initial-config create-crypto-config -t VAULT -v cryptosecrets -ks salt -kp passphrase -l /tmp/db

    salt and passphrase are the names of Vault keys and should be entered as shown: they are not to be substituted for any actual salt or passphrase. For more information about the Corda CLI create-crypto-config command’s arguments, see the Corda CLI reference.

  2. Review the DDL files generated and then execute against the database, ensuring that you apply them to the CONFIG schema.

By default, a post-install job creates three default RBAC roles for the REST API. To create the roles manually, perform the steps described in this section.

  1. Set the following override in the deployment configuration to disable the automatic creation:

    bootstrap:
  rbac:
    enabled: false

  2. Execute the following command:

    corda-cli.sh initial-rbac all-cluster-roles --yield 300 --user <INITIAL-ADMIN-USERNAME> --password <INITIAL-ADMIN-PASSWORD> --target <API-ENDPOINT>

    corda-cli.cmd initial-rbac all-cluster-roles --yield 300 --user <INITIAL-ADMIN-USERNAME> --password <INITIAL-ADMIN-PASSWORD> --target <API-ENDPOINT>

    For information about the Corda CLI initial-rbac command’s arguments, see the Corda CLI reference.

Previous
Deploying
Next
Migrating to Corda Enterprise

Was this page helpful?

Thanks for your feedback!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Chat with us
Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

Learn how

We're sorry this page wasn't helpful. Let us know how we can make it better!

Chat with us

Chat with us on our #docs channel on slack. You can also join a lot of other slack channels there and have access to 1-on-1 communication with members of the R3 team and the online community.

Chat with us
Create an issue

Create a new GitHub issue in this repository - submit technical feedback, draw attention to a potential documentation bug, or share ideas for improvement and general feedback.

Create a new issue
Propose documentation improvements directly

Help us to improve the docs by contributing directly. It's simple - just fork this repository and raise a PR of your own - R3's Technical Writers will review it and apply the relevant suggestions.

Learn how