Secret Management

The secrets are held in: 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

-        

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?

Mongo DB is a cloud managed service

The default implementation for MongoDB is a cloud managed service. 

In AWS this will be DocumentDB, as long as, it implements the API we need.

In other cloud providers it will be specific to that cloud.

For local deployments it will be inside the kubernetes cluster.

The Terraform to setup the mongo db will be pluggable so it can be replaced with the appropriate platform specific configuration.

Options discussed were:

-       self-managed cloud implementation

-       cloud-managed Infrastructure as a Service

-       mongo db atlas - a mongo provided infrastructure as a service (requires separate account, so it was dismissed)

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 Kind or Minikube for Local Kubernetes Runtime

We will use Minikube

Use GitOps -  use terraform cloud and terraform on-prem(enterprise?)

All provisioning artifacts are managed in git

-       milestones

o   start with github actions, forked repos and manual execution

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

Use Kustomize for managing variables inside and outside of Kubernetes

Kustomize can be used to manage generic scripts to work in different dev envts and for different customers

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 npm 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

Use an NPM registry to hold prebuilt and certified images

The NPM registry allows the images to be created and “certified” before they are deployed.  They are not built as part of the build.

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 outsideside 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.

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