...
SUBJECT | Secret Management |
|---|---|
| STATUS | Open |
DECISION | The secrets are held in: Vault? The secrets are managed by: The secrets are accessed from Iac …? |
DISCUSSION | 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 - |
SUBJECT | Automation of Hyperleger Fabric Network Setup |
|---|---|
| STATUS | Open |
DECISION | Use Blockchain Automation Framework (BAF) |
DISCUSSION | 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. |
| SUBJECT | User Authentication for Application Access |
|---|---|
| STATUS | Open |
DECISION | User Authentication is Platform Specific or can it use Okta |
DISCUSSION | 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? |
...
| SUBJECT | UI Deployment | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| STATUS | Open | ||||||||||||||||||||||||
DECISION | The UI will be deployed inside kubernetes | ||||||||||||||||||||||||
DISCUSSION | 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. |
| SUBJECT | Channel Policy |
|---|---|
| STATUS | Open |
DECISION | The Channel Policy will be set to ANY with a specific role required to allow new organizations to join the network |
DISCUSSION | The channel policy controls how new organizations are joined to the network. If set to Majority, many of the participants on the network must approve new organizations. If set to Any, then just one is required. We will create a role of Admin which will be required by the policy for any organization to approve new organizations. |