Secret Management

The secrets are held in: GitHub Secrets and Vault

The secrets are managed by:

The secrets are accessed from Iac …?

The management of secrets is complicated.  Below are some requirements for the solution.  If we can tick off all these, we’ll have a winner.

Must be able to manage:

-       carrier secrets

-       api keys

-       aais secrets

-       common secrets

-       cloud provider secrets

-       database secrets

-       hlf network secrets like certs

-       application secrets

-       distributed secrets

Must:

-       rotate passwords

-       be encrypted

-       permissioned so only visible to specific individuals or ci/cd

-       manageable - update / delete / create / view

-       auditable - know what changed and that no breaches have occurred

-       be accessible from IaC - terraform

-       be accessible from IaC - helm

-       be accessible during CI/CD

-       be cloud agnostic for use

-       be multi-cloud

-       have a health check of the system - at startup and intervals

-       provide logging and notifications of updates

-       exhibit CIA - confidentiality, integrity, access

-       have a user interface for managing the secrets

Options:

-       tools

o   vault

o   aws secrets manager

-        

Automation of Hyperleger Fabric Network Setup

Use Blockchain Automation Framework (BAF)

BAF will be used to set up the network automatically.

BAF will run on a pod inside the kubernetes cluster so it has access to the required credentials and certificates that are stored in Vault.

The Vault instance is running inside the private cloud, so the automation cannot run from GitHub actions.        

User Authentication is Platform Specific or can it use Okta

The authentication of users must be cloud specific for access to applications because there is no generic authentication provider.

-       start with aws strategy - cognito

-       want to offload identiy to identity provider

-       can we use okta as the main identity management and link it to the underlying provider thus acting as a common api for the applications?

DA - Extraction Processing

TBD

DA - Harmonized Data Scope

Proposal:

data format / schema will be standardized across nodes, for a given use case

The data available for extraction must be normalized for multiple extractions across multiple use cases across multiple members.

Is this one single model?

Is the data at rest in the same model as the data in motion?

DA - Harmonized Data Loading / Normalization

Proposal:

If the HDS is at rest, the loading of that data is the responsibility of the member owner of the node.

If the HDS is an API, the maintenance of that API is the responsibility of the Technical Steering Committee and the mapping to other data sources is the responsibility of the member owner of the node.

1. Loading data will be via an API, IDM or ...? Will a direct SQL load be allowed?  This will use the ingestion model.
2. We should consider using graphQL as the extraction processing language or part of the extraction processing component to replace the current map reduce "extraction pattern"

DA - Harmonized Data Format Governance

Proposal:

data schema, enumerations and the data dictionary will be standardized, and endorsed by the RRSC (and other groups per use case)

The Technical Steering Committee, Regulatory Reporting Steering Committee and the Data Model Steering Committee are all possible owners of this.

DA - Harmonized Data Store

Proposal:

1. HDS can be persistent or transient. It's a member's decision. See next
2. HDS can be persistent and can be used by member's as a "warehouse on the edge" for sharing data via openIDL
3. Either way, the member is responsible for configuring the API that accesses the data.

The data available for extraction must be normalized for multiple extractions across multiple use cases across multiple members.

Is this one single model?

Is this one database?

Is this data at rest and/or available through an API

DA - Harmonized Data Access

Proposal:

1. All access to "Harmonized Data" is through an API
2. Member is responsible for the quality of the data retrieved and for certifying that a "request" for the data is supported.

If we determine that a standing harmonized store is not required, then we must establish an API with a standardized payload format that can be used to access the data.

The member must "certify" that the data is available and quality in order to consent to a data extraction.

The consent and certification can be captured on the ledger.

The call to the API will come from the extraction processor. 

The extraction processor can run on the member node.

Can the extraction processor run on the Analytics Node?

If the extraction runs outside the member node, how does this work?  Can it call the API directly?  Must we use HLF to "transport" the data?

DA - Harmonized Datastore DBMS Implementation

Proposal:

If the HDS is a physical db inside the node, then the HDS DBMS must support our chosen access language (graphQL?)

HDS will be a relational database. It cannot be a noSQL, graph, document DB etc.

technical implementation of a HDS is non-prescriptive i.e. it can be MySQL, MS SQL, Oracle etc.  

If data is at rest in the harmonized datastore, what is the technology?

Does it need to be a single dbms?

Should it be noSQL?

Can it just be an interface?

DA - Harmonized Data Model

??

The data available for extraction must be normalized for multiple extractions across multiple use cases across multiple carriers.

The data must be produced by the carrier from their original sources.

Is this an ETL process?

What is the format of the load data?  Is it the schema of a standing HDS database or is it a messaging format?

Is there just one "in transit" model or are there different ones for different contexts?  Contexts might be the data call, the line of business, etc.

DA - Export Data Model

Proposal:

The export data model is specific to each use case and must be specified in that data call / regulatory report

The extraction process results in an export of data in an agreed format.  The format of this must be defined as part of the specific data call or regulatory report.

Single Application Angular UI Variations will utilize angular libraries

The library will be a different kind of angular app located in the same super library as all apps that use it. This is the approach for the data-call-ui. (openidl-ui and openidl-carrier-ui)

For common / shared libraries we will use an npm registry.

Use Minikube for Local Kubernetes Runtime

There are multiple options for local kubernetes deployment.  We chose Minikube over Kind because of it's simplicity.

Use a combination of solutions depending on application.

• Cloud
  • Terraform for Infrastructure Provisioning in the Cloud
  • GitHub actions for CI/CD and execution of Terraform
  • Ansible for Deploying ??
  • Helm for managing Kubernetes
  • Flux for provisioning and managing distributed nodes
• Local Reference
  • Bash scripts for provisioning local

Provide options for selection upon setup.

• Terraform Cloud
• Terraform Enterprise
• GitHub Actions
• Manual

All provisioning artifacts are managed in git

The customer will have a github / gitlab account that is private to them.

We may or may not have access to that repository.

To accept updates, the customer will accept a merge/pull request into their repository with our changes.

That update in git will automatically trigger the workflow.

The workflow may allow automatic provisioning or require an acceptance from the customer.

-       milestones

1. start with github actions, forked repos and manual execution
2. move to terraform cloud for aais node

target will have two options for node owners

• use terraform cloud
• use terraform on-prem (terraform enterprise)

Use Terraform to provision cloud specific services

Execute Terraform using GitHub actions

If possible use GitHub actions - see above for options
If there is some reason to use cloud specific
-       cost of implementation
-       complexity etc

Use Flux v2 for Deployment of Kubernetes artifacts

This technology enables GitOps in build and deployment

Use Helm Charts for Application and Network provisioning in Kubernetes

Helm is a very popular way to provision Kubernetes clusters

Publish Common Libs as images to NPM Registry in GitHub

Any common components should be packaged as images and published to the GitHub packages.

Images should be published in the GitHub packages container registry

Since we separate building of images from their deployment, we can build the images into the registry and then refer to that registry when deploying

secret management should be cloud agnostic

Notes
-       the secrets for the each cloud might be managed differently
-       hashicorp makes a popular opensource solution called vault
-       if cloud specific, we should have a layer that normalizes the access of secrets so the scripts / config files don’t need to change from cloud to cloud

Secrets are applied during deployment, not in the image

The images used to create the pods in Kubernetes should not contain any private information.  This can all be applied during deployment by mounting the file from a secret held outside.

The Harmonized Data Store will be deployed inside kubernetes

The best practice regarding databases and Kubernetes is to host them outside.  As long as the db is mongo and has a uri accessible to the insurance data manager and other apis, it is viable.

The terraform to set it up may need different flavors for the different clouds.

The UI will be deployed inside kubernetes

There are two main choices for deploying the ui.  Here is the discussion about the relative merits for the options.

We deploy the applications inside kubernetes so they are more manageable. This includes the APIs and the UIs. Deploying at the edge is a best practice, but manageability is more important in this case. We can deliver updates to the code as images in a container registry and have them deployed much easier than if we used AWS (or other cloud) specific services.

Q: Why not have a centralized UI?

A: The UI is configured to access the API. iI has to have private access to the API inside the node, not go out onto the internet and have the apis exposed publicly.  The apis are private to the member cloud, actually private to the kubernetes cluster.

Because manageability is a very high priority item for the ui components, this outweighs the differences in other aspects.

The Channel Policy will be set to ANY with a specific role required to allow new organizations to join the network