Skip to content

Configuration file specification: R3 Corda

A network.yaml configuration file serves as a centralized and comprehensive blueprint, capturing the essential parameters and configurations needed to set up the entire Corda DLT network. It allows the users to define the network ports, participant nodes, notary service urls, and various parameters crucial for the network's operation. This file needs to be updated for your specific network setup before using it with the Ansible playbooks.

Schema Definition

A json-schema definition is provided in platforms/network-schema.json to assist with semantic validations and lints. You can use your favorite yaml lint plugin compatible with json-schema specification, like redhat.vscode-yaml for VSCode. You need to adjust the directive in template located in the first line based on your actual build directory:

# yaml-language-server: $schema=../platforms/network-schema.json

The configurations are grouped in the following sections for better understanding.

Although, the file itself has comments for each key-value, here is a more detailed description with respective snippets.

Use this sample configuration file as a base.

# yaml-language-server: $schema=../../../../platforms/network-schema.json
# This is a sample configuration file for SupplyChain App on Single K8s Cluster.
# For multiple K8s clusters, there should be multiple configuration files.
network:
  # Network level configuration specifies the attributes required for each organization
  # to join an existing network.
  type: corda
  version: 4.9

Use this sample configuration file as a base.

# yaml-language-server: $schema=../../../../platforms/network-schema.json
# This is a sample configuration file for Corda Enterprise network for SupplyChain App usecase on Single K8s Cluster.
# For multiple K8s clusters, there should be multiple configuration files.
network:
  # Network level configuration specifies the attributes required for each organization
  # to join an existing network.
  type: corda-enterprise
  version: "4.7"        # Hyperledger Bevel deployment supports node and notary enterprise 4.7 version (use older tag for other version supports)

type
type defines the platform choice like corda/fabric/quorum. Use corda for Corda Opensource and corda-enterprise for Corda Enterprise.
version
version defines the version of platform being used, here in example the Corda version is 4.9. Please note only 4.4 above is supported for Corda Enterprise.
env
env section contains the kubernetes settings like flux tag, proxy etc. as describe below.

  #Environment section for Kubernetes setup
  env:
    type: "dev"         # tag for the environment. Important to run multiple flux on single cluster
    proxy: ambassador   # value has to be 'ambassador' as 'haproxy' has not been implemented for Corda
    ambassadorPorts:    # Any additional Ambassador ports can be given here, this is valid only if proxy='ambassador'
      portRange:        # For a range of ports 
        from: 15010 
        to: 15020
    # ports: 15020,15021      # For specific ports
    loadBalancerSourceRanges: '0.0.0.0/0' # comma-separated list without spaces of IP adresses for proxy='ambassador' allowed access
    retry_count: 20                 # Retry count for the checks
    external_dns: enabled           # Should be enabled if using external-dns for automatic route configuration
The fields under env section are

Field Description
type Environment type. Can be like dev/test/prod.
proxy Choice of the Cluster Ingress controller. Currently supports ambassador only as haproxy has not been implemented for Corda
ambassadorPorts Any additional Ambassador ports can be given here. This is only valid if proxy: ambassador
loadBalancerSourceRanges (Optional) Restrict inbound access to a single or list of IP adresses for the public Ambassador ports to enhance network security. This is only valid if proxy: ambassador.
retry_count Retry count for the checks. Use a large number if your kubernetes cluster is slow.
external_dns If the cluster has the external DNS service, this has to be set enabled so that the hosted zone is automatically updated.
docker
docker section contains the credentials of the container registry where all the required images are stored.

The following images are used and needed by Hyperledger Bevel.

For Corda Enterprise, all Docker images must be built and stored in a private Docker registry before running the Ansible playbooks. The required instructions are found here.

  # Docker registry details where images are stored. This will be used to create k8s secrets
  # Please ensure all required images are built and stored in this registry. 
  # Do not check-in docker_password.
  docker:
    url: "ghcr.io/hyperledger"
    username: "docker_username"
    password: "docker_password"
The fields under docker section are

Field Description
url Docker registry url. Must be private registry for Corda Enterprise
username Username credential required for login
password Password or Access token required for login

Note

Please follow these instructions to build and store the docker images before running the Ansible playbooks.

network_services
The network_services section contains a list of doorman/idman/networkmap which is exposed to the network.
  # Remote connection information for doorman and networkmap (will be blank or removed for hosting organization)
  network_services:
    - service:
      type: doorman
      uri: https://doorman.test.corda.blockchaincloudpoc.com
      certificate: home_dir/platforms/r3-corda/configuration/build/corda/doorman/tls/ambassador.crt
    - service:
      type: networkmap
      uri: https://networkmap.test.corda.blockchaincloudpoc.com
      certificate: home_dir/platforms/r3-corda/configuration/build/corda/networkmap/tls/ambassador.crt
  # Remote connection information for idman and networkmap (will be blank or removed for hosting organization)
  network_services:
    - service:
      name: idman
      type: idman
      uri: https://idman.test.corda.blockchaincloudpoc.com
      certificate: home_dir/platforms/r3-corda-ent/configuration/build/ambassador/idman/ambassador.pem
      crlissuer_subject: "CN=Corda TLS CRL Authority,OU=Corda UAT,O=R3 HoldCo LLC,L=New York,C=US"
    - service:
      name: networkmap
      type: networkmap
      uri: https://networkmap.test.corda.blockchaincloudpoc.com
      certificate: home_dir/platforms/r3-corda-ent/configuration/build/ambassador/networkmap/ambassador.pem
      truststore: home_dir/platforms/r3-corda-ent/configuration/build/networkroottruststore.jks #Certificate should be encoded in base64 format
      truststore_pass: rootpassword

Each service has the following fields:

Field Description
type For Corda, networkmap and doorman are the only valid type of network_services.
uri Doorman/Networkmap external URL. This should be reachable from all nodes.
certificate Absolute path to the public certificates for Doorman/IDman and Networkmap.
Field Description
type For Corda Enterprise, networkmap and idman are the only valid type of network_services.
name Name of the idman/networkmap service.
uri Doorman/IDman/Networkmap external URL. This should be reachable from all nodes.
certificate Absolute path to the public certificates for Doorman/IDman and Networkmap.
crlissuer_subject Only for Idman. Subject of the CRL Issuer.
truststore Only for Networkmap. Absolute path to the base64 encoded networkroot truststore.
truststore_pass Only for Networkmap. Truststore password
organizations
The organizations section allows specification of one or many organizations that will be connecting to a network. If an organization is also hosting the root of the network (e.g. doorman, membership service, etc), then these services should be listed in this section as well.

In the sample example the 1st organization is hosting the root of the network, so the services doorman, nms and notary are listed under the 1st organization's service.

A snippet of an organization field with sample values is below

  organizations:
    - organization:
      name: supplychain
      country: UK
      state: London
      location: London
      subject: "CN=DLT Root CA,OU=DLT,O=DLT,L=London,C=GB"
      type: doorman-nms-notary
      external_url_suffix: test.corda.blockchaincloudpoc.com
      cloud_provider: aws   # Options: aws, azure, gcp
  organizations:
    - organization:
      name: supplychain
      country: UK
      state: London
      location: London
      subject: "CN=DLT Root CA,OU=DLT,O=DLT,L=London,C=GB"
      subordinate_ca_subject: "CN=Test Subordinate CA Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
      type: cenm
      version: 1.5
      external_url_suffix: test.corda.blockchaincloudpoc.com
      cloud_provider: aws   # Options: aws, azure, gcp

Each organization under the organizations section has the following fields.

Field Description
name Name of the organization
country Country of the organization
state State of the organization
location Location of the organization
subject Subject format can be referred at OpenSSL Subject
type This field can be doorman-nms-notary/node
external_url_suffix Public url suffix of the cluster. This is the configured path for the Ambassador Service on the DNS provider.
cloud_provider Cloud provider of the Kubernetes cluster for this organization. This field can be aws, azure or gcp
aws When the organization cluster is on AWS
k8s Kubernetes cluster deployment variables.
vault Contains Hashicorp Vault server address and root-token in the example
gitops Git Repo details which will be used by GitOps/Flux.
cordapps (optional) Cordapps Repo details which will be used to store/fetch cordapps jar
services Contains list of services which could be peers/doorman/nms/notary
Field Description
name Name of the organization
country Country of the organization
state State of the organization
location Location of the organization
subject Subject format can be referred at OpenSSL Subject
subordinate_ca_subject Subordinate CA Subject for the CENM.
type This field can be cenm/node.
version Defines the CENM version. Must be 1.5
external_url_suffix Public url suffix of the cluster. This is the configured path for the Ambassador Service on the DNS provider.
cloud_provider Cloud provider of the Kubernetes cluster for this organization. This field can be aws, azure or gcp
aws When the organization cluster is on AWS
k8s Kubernetes cluster deployment variables.
vault Contains Hashicorp Vault server address and root-token in the example
gitops Git Repo details which will be used by GitOps/Flux.
firewall Contains firewall options and credentials
cordapps (optional) Cordapps Repo details which will be used to store/fetch cordapps jar
services Contains list of services which could be peers/doorman/nms/notary/idman/signer

For the aws, k8s and vault fields, a snippet is below

      aws:
        access_key: "aws_access_key"        # AWS Access key, only used when cloud_provider=aws
        secret_key: "aws_secret_key"        # AWS Secret key, only used when cloud_provider=aws
      # Kubernetes cluster deployment variables. The config file path and name has to be provided in case
      # the cluster has already been created.
      k8s:
        context: "cluster_context"
        config_file: "cluster_config"
      # Hashicorp Vault server address and root-token. Vault should be unsealed.
      # Do not check-in root_token
      vault:
        url: "vault_addr"
        root_token: "vault_root_token"

The aws field under each organization contains: (This will be ignored if cloud_provider is not `aws``)

Field Description
access_key AWS Access key
secret_key AWS Secret key

The k8s field under each organization contains

Field Description
context Context/Name of the cluster where the organization entities should be deployed
config_file Path to the kubernetes cluster configuration file

The vault field under each organization contains

Field Description
url The URL for Hashicorp Vault server with port (Do not use 127.0.0.1 or localhost)
root_token The root token for accessing the Vault server

For gitops field, the snippet from the sample configuration file is below

      # Git Repo details which will be used by GitOps/Flux.
      # Do not check-in git_access_token
      gitops:
        git_protocol: "https" # Option for git over https or ssh
        git_url: "https://github.com/<username>/bevel.git"         # Gitops https or ssh url for flux value files 
        branch: "develop"           # Git branch where release is being made
        release_dir: "platforms/r3-corda/releases/dev" # Relative Path in the Git repo for flux sync per environment. 
        chart_source: "platforms/r3-corda/charts"     # Relative Path where the Helm charts are stored in Git repo
        git_repo: "github.com/<username>/bevel.git"   # Gitops git repository URL for git push 
        username: "git_username"          # Git Service user who has rights to check-in in all branches
        password: "git_access_token"          # Git Server user password/token (Optional for ssh; Required for https)
        email: "git@email.com"                # Email to use in git config
        private_key: "path_to_private_key"          # Path to private key file which has write-access to the git repo (Optional for https; Required for ssh)

The gitops field under each organization contains

Field Description
git_protocol Option for git over https or ssh. Can be https or ssh
git_url SSH or HTTPs url of the repository where flux should be synced
branch Branch of the repository where the Helm Charts and value files are stored
release_dir Relative path where flux should sync files
chart_source Relative path where the helm charts are stored
git_repo Gitops git repo URL https URL for git push like "github.com/hyperledger/bevel.git"
username Username which has access rights to read/write on repository
password Access token of the user which has access rights to read/write on repository (Optional for ssh; Required for https)
email Email of the user to be used in git config
private_key Path to the private key file which has write-access to the git repo (Optional for https; Required for ssh)

Corda Opensource does not have credentials section.

The credentials field under each organization contains

Field Description
keystore Contains passwords for keystores
truststore Contains passwords for truststores
ssl Contains passwords for ssl keystores

For organization as type cenm the credential block looks like

      credentials:
        keystore:
          keystore: cordacadevpass
          idman: password
          networkmap: password
          subordinateca: password
          rootca: password
          tlscrlsigner: password
        truststore:
          truststore: trustpass
          rootca: rootpassword
          ssl: password
        ssl:
          networkmap: password
          idman: password
          signer: password
          root: password
          auth: password
For organization as type node the credential section is under peers section and looks like
        subject: "CN=Test Firewall CA Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
        credentials:
            firewallca: firewallcapassword
            float: floatpassword

For cordapps fields, a snippet from the sample configuration file is below:

      # Cordapps Repository details (optional if cordapps jar are store in a repository)
      cordapps:
        jars: 
        - jar:
            # e.g https://maven.pkg.github.com/hyperledger/bevel/com.supplychain.bcc.cordapp-supply-chain/4.7/cordapp-supply-chain-4.7.jar
            url: "https://repo/path/cordapp1.jar"
        - jar:
            # e.g https://maven.pkg.github.com/hyperledger/bevel/com.supplychain.bcc.cordapp-contracts-states/4.7/cordapp-contracts-states-4.7.jar
            url: "https://repo/path/cordapp2.jar"
        username: "git_username"
        password: "git_access_token"

The cordapps optional field under each organization contains

Field Description
jars Contains list of jars with jar URL that needs to fetched and put into organization nodes
username Cordapps Repository username
password Cordapps Repository password

Corda Opensource does not have firewall section.

The firewall section contains Corda Enterprise firewall configuration for each organization.

      external_url_suffix: test.corda.blockchaincloudpoc.com
      firewall:
        enabled: true        # true if firewall components are to be deployed
        subject: "CN=Test Firewall CA Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
        credentials:
            firewallca: firewallcapassword
            float: floatpassword

Field Description
enabled true/false for enabling firewall (external bridge and float)
subject Certificate Subject for firewall, format at OpenSSL Subject
credentials Contains credentials for bridge and float

The services field for each organization under organizations section of Corda contains list of services which could be doorman/idman/nms/notary/peers for opensource, and additionally idman/networkmap/signer/bridge/float for Corda Enterprise.

For doorman/idman

A snippet of doorman service is below:

      services:
        doorman:
          name: doorman
          subject: "CN=Corda Doorman CA,OU=DLT,O=DLT,L=Berlin,C=DE"
          db_subject: "/C=US/ST=California/L=San Francisco/O=My Company Ltd/OU=DBA/CN=mongoDB"
          type: doorman
          ports:
            servicePort: 8080
            targetPort: 8080
          tls: "on"                      # off/on based on TLS mode off/on for doorman
The fields under doorman service are

Field Description
name Name for the Doorman service
subject Certificate Subject for Doorman service. Subject format can be referred at OpenSSL Subject
db_subject Certificate subject for mongodb database of doorman
type Service type must be doorman
ports.servicePort HTTP port number where doorman service is accessible
ports.targetPort HTTP target port number of the doorman docker-container
tls On/off based on whether we want TLS on/off for doorman

A snippet of idman service is below:

        idman:
          name: idman
          subject: "CN=Test Identity Manager Service Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
          crlissuer_subject: "CN=Corda TLS CRL Authority,OU=Corda UAT,O=R3 HoldCo LLC,L=New York,C=US"
          type: cenm-idman
          port: 10000
The fields under idman service are

Field Description
name Name for the IDman service
subject Certificate Subject for Idman service. Subject format can be referred at OpenSSL Subject
crlissuer_subject Certificate subject for CRL Issuer service
type Service type must be cenm-idman
port HTTP port number where idman service is accessible internally

For networkmap

A snippet of nms service is below:

        nms:
          name: networkmap
          subject: "CN=Network Map,OU=FRA,O=FRA,L=Berlin,C=DE"
          db_subject: "/C=US/ST=California/L=San Francisco/O=My Company Ltd/OU=DBA/CN=mongoDB"
          type: networkmap
          ports:
            servicePort: 8080
            targetPort: 8080
          tls: "on"                       # off/on based on TLS mode off/on for nms
The fields under nms service are

Field Description
name Name of the NetworkMap service
subject Certificate Subject for NetworkMap service. Subject format can be referred at OpenSSL Subject
db_subject Certificate subject for mongodb database of nms.
type Service type must be networkmap
ports.servicePort HTTP port number where NetworkMap service is accessible
ports.targetPort HTTP target port number of the NetworkMap docker-container
tls On/off based on whether we want TLS on/off for nms

A snippet of networkmap service is below:

        networkmap:
          name: networkmap
          subject: "CN=Test Network Map Service Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
          type: cenm-networkmap
          ports:
            servicePort: 10000
            targetPort: 10000
The fields under networkmap service are

Field Description
name Name for the Networkmap service
subject Certificate Subject for Networkmap service. Subject format can be referred at OpenSSL Subject
type Service type must be cenm-networkmap
ports.servicePort HTTP port number where networkmap service is accessible internally
ports.targetPort HTTP target port number of the networkmap docker-image

For notary

A snippet of notary service is below

        # Currently only supporting a single notary cluster, but may want to expand in the future
        notary:
          name: notary
          subject: "O=Notary,OU=Notary,L=London,C=GB"
          serviceName: "O=Notary Service,OU=Notary,L=London,C=GB"
          validating: true            #true - if notary is validating, false  - if notary is non-validating
          type: notary            
          p2p:
            port: 10002
            targetPort: 10002
            ambassador: 15010       #Port for ambassador service (must be from env.ambassadorPorts above)
          rpc:
            port: 10003
            targetPort: 10003
          rpcadmin:
            port: 10005
            targetPort: 10005
          dbtcp:
            port: 9101
            targetPort: 1521
          dbweb:             
            port: 8080
            targetPort: 81        
The fields under notary service are

Field Description
name Name of the notary service
subject Certificate Subject for notary node. Subject format can be referred at OpenSSL Subject
serviceName Certificate Subject for notary service applicable from Corda 4.7 onwards. Subject format can be referred at OpenSSL Subject
type Service type must be notary
validating Determines if Notary is validating or non-validating. Use true or false
p2p.port Corda Notary P2P port. Used for communication between the notary and nodes of same network
p2p.targetport P2P Port where notary service is running.
p2p.ambassador Port where notary service is exposed via Ambassador
rpc.port Corda Notary RPC port. Used for communication between the notary and nodes of same network
rpcadmin.port Corda Notary Rpcadmin port. Used for RPC admin binding
dbtcp.port Corda Notary DbTcp port. Used to expose database to other services
dbtcp.targetPort Corda Notary DbTcp target port. Port where the database services are running
dbweb.port Corda Notary dbweb port. Used to expose dbweb to other services
dbweb.targetPort Corda Notary dbweb target port. Port where the dbweb services are running

A snippet of notary service is below:

        notaries:
        - notary:
          name: notary-1
          subject: "O=Notary,OU=Notary1,L=London,C=GB"
          serviceName: "O=Notary Service,OU=Notary1,L=London,C=GB"
          type: notary
          validating: true
          emailAddress: "dev@bevel.com"
          p2p:
            port: 10002
            targetPort: 10002
            ambassador: 15005       #Port for ambassador service (must be from env.ambassadorPorts above)
          rpc:
            port: 30000
            targetPort: 10003
          rpcadmin:
            port: 30009
            targetPort: 10005
          dbtcp:
            port: 9101
            targetPort: 1521
          dbweb:             
            port: 8080
            targetPort: 81
The fields under notary service are

Field Description
name Name of the notary service
subject Certificate Subject for notary node. Subject format can be referred at OpenSSL Subject
serviceName Certificate Subject for notary service applicable from Corda 4.7 onwards. Subject format can be referred at OpenSSL Subject
type Service type must be notary
validating Determines if Notary is validating or non-validating. Use true or false
emailAddress Email address in the notary conf.
p2p.port Corda Notary P2P port. Used for communication between the notary and nodes of same network
p2p.targetport P2P Port where notary service is running.
p2p.ambassador Port where notary service is exposed via Ambassador
rpc.port Corda Notary RPC port. Used for communication between the notary and nodes of same network
rpcadmin.port Corda Notary Rpcadmin port. Used for RPC admin binding
dbtcp.port Corda Notary DbTcp port. Used to expose database to other services
dbtcp.targetPort Corda Notary DbTcp target port. Port where the database services are running
dbweb.port Corda Notary dbweb port. Used to expose dbweb to other services
dbweb.targetPort Corda Notary dbweb target port. Port where the dbweb services are running

For peers/nodes

A snippet of peer service is below:

      services:
        peers:
        - peer:
          name: manufacturer
          subject: "O=Manufacturer,OU=Manufacturer,L=47.38/8.54/Zurich,C=CH"  # This is the node identity. L=lat/long is mandatory for supplychain sample app
          type: node
          p2p:
            port: 10002
            targetPort: 10002
            ambassador: 15010       #Port for ambassador service (must be from env.ambassadorPorts above)
          rpc:
            port: 10003
            targetPort: 10003
          rpcadmin:
            port: 10005
            targetPort: 10005
          dbtcp:
            port: 9101
            targetPort: 1521
          dbweb:             
            port: 8080
            targetPort: 81
          springboot:             # This is for the springboot server
            targetPort: 20001
            port: 20001 
          expressapi:             # This is for the express api server
            targetPort: 3000
            port: 3000
The fields under each peer service are

Field Description
name Name of the Corda Node
subject The node legal name as certificate subject.
type Service type must be node
p2p.port Corda Node P2P port.Used for communication between the nodes of same network
p2p.targetport P2P Port where node service is running.
p2p.ambassador Port where node service is exposed via Ambassador
rpc.port Corda Node RPC port. Used for communication between the nodes of different network
rpcadmin.port Corda Node Rpcadmin port. Used for RPC admin binding
dbtcp.port Corda Node DbTcp port. Used to expose database to other services
dbtcp.targetPort Corda Node DbTcp target port. Port where the database services are running
dbweb.port Corda Node dbweb port. Used to expose dbweb to other services
dbweb.targetPort Corda Node dbweb target port. Port where the dbweb services are running
springboot.port Springboot server port. Used to expose springboot to other services
springboot.targetPort Springboot server target port. Port where the springboot services are running
expressapi.port Expressapi port. Used to expose expressapi to other services
expressapi.targetPort Expressapi target port. Port where the expressapi services are running

A snippet of peer service is below:

          subject: "CN=Test Bridge Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
        peers:
        - peer:
          name: manufacturer
          subject: "O=Manufacturer,OU=Manufacturer,L=47.38/8.54/Zurich,C=CH"  # This is the node identity. L=lat/long is mandatory for supplychain sample app
          type: node
          credentials:
            truststore: trustpass
            keystore: cordacadevpass
          hsm:                              # hsm support for future release
            enabled: false 
          p2p:
            port: 10002
            targetPort: 10002
            ambassador: 15010       #Port for ambassador service (must be from env.ambassadorPorts above)
          rpc:
            port: 30000
            targetPort: 10003
          rpcadmin:
            port: 30009
            targetPort: 10005
          dbtcp:
            port: 9101
            targetPort: 1521
          dbweb:             
            port: 8080
            targetPort: 81
          springboot:             # This is for the springboot server
            targetPort: 20001
            port: 20001 
          expressapi:             # This is for the express api server
            targetPort: 3000

Field Description
name Name of the Corda Node
subject The node legal name subject.
type Service type must be node
credentials The passwords as described in credentials section above.
hsm This is for future use with HSM.
p2p.port Corda Node P2P port.Used for communication between the nodes of same network
p2p.targetport P2P Port where node service is running.
p2p.ambassador Port where node service is exposed via Ambassador
rpc.port Corda Node RPC port. Used for communication between the nodes of different network
rpcadmin.port Corda Node Rpcadmin port. Used for RPC admin binding
dbtcp.port Corda Node DbTcp port. Used to expose database to other services
dbtcp.targetPort Corda Node DbTcp target port. Port where the database services are running
dbweb.port Corda Node dbweb port. Used to expose dbweb to other services
dbweb.targetPort Corda Node dbweb target port. Port where the dbweb services are running
springboot.port Springboot server port. Used to expose springboot to other services
springboot.targetPort Springboot server target port. Port where the springboot services are running
expressapi.port Expressapi port. Used to expose expressapi to other services
expressapi.targetPort Expressapi target port. Port where the expressapi services are running

There are additional services for Corda Enterprise.

Corda Opensource does not support CENM or other advanced features.

A snippet of zone service is below

      services:
        zone:
          name: zone
          type: cenm-zone
          ports:
            enm: 25000
            admin: 12345
The fields under zone service are

Field Description
name Name for the Zone service
type Service type must be cenm-zone
ports.enm HTTP enm port number where zone service is accessible internally
ports.admin HTTP admin port number of zone service

        auth:
          name: auth
          subject: "CN=Test TLS Auth Service Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
          type: cenm-auth
          port: 8081
          username: admin
          userpwd: p4ssWord
The fields under auth service are

Field Description
name Name for the Auth service
subject Certificate Subject for Auth service. Subject format can be referred at OpenSSL Subject
type Service type must be cenm-auth
ports HTTP port number where auth service is accessible internally
username Admin user name for auth service
userpwd Admin password for auth service

        gateway:
          name: gateway
          subject: "CN=Test TLS Gateway Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
          type: cenm-gateway
          ports: 
            servicePort: 8080
            ambassadorPort: 15008
The fields under gateway service are

Field Description
name Name for the Gateway service
subject Certificate Subject for Gateway service. Subject format can be referred at OpenSSL Subject
type Service type must be cenm-gateway
ports.servicePort HTTP port number where gateway service is accessible internally
ports.ambassadorPort Port where gateway service is exposed via Ambassador

        signer:
          name: signer
          subject: "CN=Test TLS Signer Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
          type: cenm-signer
          ports:
            servicePort: 8080
            targetPort: 8080  
The fields under signer service are

Field Description
name Name for the Signer service
subject Certificate Subject for Signer service. Subject format can be referred at OpenSSL Subject
type Service type must be cenm-signer
ports.servicePort HTTP port number where signer service is accessible
ports.targetPort HTTP target port number of the signer docker-container

A snippet of float service is below:

      services:
        float: 
          name: float
          subject: "CN=Test Float Certificate, OU=HQ, O=HoldCo LLC, L=New York, C=US"
          external_url_suffix: test.cordafloat.blockchaincloudpoc.com
          cloud_provider: aws   # Options: aws, azure, gcp
          aws:
            access_key: "aws_access_key"        # AWS Access key, only used when cloud_provider=aws
            secret_key: "aws_secret_key"        # AWS Secret key, only used when cloud_provider=aws
          k8s:
            context: "float_cluster_context"
            config_file: "float_cluster_config"
          vault:
            url: "float_vault_addr"
            root_token: "float_vault_root_token"
          gitops:
            git_protocol: "https" # Option for git over https or ssh
            git_url: "https://github.com/<username>/bevel.git"         # Gitops https url for flux value files
            branch: "develop"           # Git branch where release is being made
            release_dir: "platforms/r3-corda-ent/releases/float" # Relative Path in the Git repo for flux sync per environment. 
            chart_source: "platforms/r3-corda-ent/charts"     # Relative Path where the Helm charts are stored in Git repo
            username: "git_username"          # Git Service user who has rights to check-in in all branches
            password: "git_access_token"          # Git Server user password/token (Optional for ssh; Required for https)
            email: "git@email.com"                # Email to use in git config
            git_repo: "github.com/<username>/bevel.git"   # Gitops git repository URL for git push 
            private_key: "path_to_private_key"          # Path to private key file which has write-access to the git repo (Optional for https; Required for ssh)
          ports:
            p2p_port: 40000
            tunnelport: 39999
            ambassador_tunnel_port: 15021
The Float service is supposed to be in a different Kubernetes cluster and so some fields are repeated, but must be updated with a different cluster details. The fields under float service are:

Field Description
name Name for the float service
subject Certificate Subject for Float service. Subject format can be referred at OpenSSL Subject
external_url_suffix Public url suffix of the cluster. This is the configured path for the Ambassador Service on the DNS provider.
cloud_provider Cloud provider of the Kubernetes cluster for this organization. This field can be aws, azure or gcp
aws When the organization cluster is on AWS
k8s Kubernetes cluster deployment variables.
vault Contains Hashicorp Vault server address and root-token in the example
gitops Git Repo details which will be used by GitOps/Flux.
ports.p2p_port Peer to peer service port
ports.tunnel_port Tunnel port for tunnel between float and bridge service
port.ambassador_tunnel_port Ambassador port for tunnel between float and bridge service
ambassador_p2p_port Ambassador port Peer to peer connection

A snippet of bridge service is below:

            ambassador_p2p_port: 15020
        bridge:
          name: bridge
The fields under bridge service are below:

Field Description
name Name for the bridge service
subject Certificate Subject for bridge service. Subject format can be referred at OpenSSL Subject