...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Overview
Open Horizon has had support for secret deployment for some time now. The current capability enables a service developer to express a requirement for a secret, and enables a service deployer to bind secrets to a service at service deployment time. In this case, it's the same secret that is deployed to all of the nodes where the the service is placed. This works well for large scale application deployment where node specific secrets are not really required. However, if the service(s) being deployed is configured to execute as a privileged container, there are more strict security requirements which result in the need for specific (i.e. different) secrets to be deployed to each node where the service runs. This can be accomplished in Open Horizon by creating a deployment policy that deploys a service to one and only one node, but that approach does not scale beyond a handful of nodes. Open Horizon needs the capability to deploy node specific secrets that scales up easily.
This design uses the configuration by convention approach to provide an optional and scalable capability. In short, the design enables an org admin to name a secret that complies with a pattern (defined in this design) identifying a specific node, so that when the secret is deployed, it is only deployed to the identified node. Nodes for which there is no correspondingly named secret will instead receive the org or user secret as they would have before this capability was added. For example, a deployer binds a secret named myGenericSecret to the service using a deployment policy. The deployer has also created a secret named "node/node1/myGenericSecret" which is specific to node1. When the policy is published, the agbot determines that the service should be placed on node1, node2, and node3. The agreement proposal sent to node1 contains the contents of node/node1/myGenericSecret. The agreement proposal sent to node 2 and 3 contains the contents of myGenericSecret. The removal of the node specific secret from the system would cause the agbot to update the agreement with node1, resulting in the delivery of myGenericSecret to node1.
...
The permissions required to access a node specific secret are not changed by this design. That is, for org wide node specific secrets, the required permissions are the same as for an org wide secret (in terms of Add, Delete, List and Read).
As a service deployer, I want to configure a specific secret for each node on which a service is placed.
...
As a service deployer, I want to roll out node specific secrets to the nodes in small batches.
hzn exchange pattern publish and hzn exchange deployment policy add
...
The syntax and flags supported by these commands is not changed, but the implementation is updated to check for node specific secrets.
The vault auth plugin is updated to support node specific secrets.
Agent, Agbot, Exchange, CLI, vault auth plugin
None. Node specific secrets are secured in the same way that org wide and user specific secrets are secured before this new capbility.
Exchange API is updated to support the new deployment policy and pattern schema for the "secretBinding" section.
...
"/org/{org}/secrets/user/{user}/node/{node}/{secret:[\w\/\-]+}" the "GET", "LIST", "PUT", "POST", "DELETE" is added
None
Documentation is needed to:
- Describe the feature in general, as per the design section and the user experience section.
- Describe the "enableNodeLevelSecrets" flag in deployment policies and patterns
- Illustrate an example using a node specific secret