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.
This design enables deployers to opt-in to the use of this new capability without affecting existing usage behavior. It also supports the current scalability of service placement in OH.
To enable this capability the following changes are introduced. The secret binding in a pattern or deployment policy is extended with the "enableNodeLevelSecrets" flag that enables node specific secrets:
"secretBinding": [
{"serviceOrgid": "$HZN_ORG_ID",
"serviceUrl": "$SERVICE_NAME",
"serviceVersionRange": "0.0.1",
"enableNodeLevelSecrets": <boolean>,
"secrets": [
{"cloudAIservice": "aitoken"}, <— org level secret
{"cloudsqlservice": "user/{userid}/sqltoken"} <— user level secret
]
}
]
The flag "enableNodeLevelSecrets" is a boolean typed field and is false by default. When set to true, it causes the agbot to search for node specific secrets when making agreements. The agbot will limit it's search to the secrets specified in the "secrets" array of the same serviceBinding element where the "enableNodeLevelSecrets" flag is set. Further, this design extends the secretBinding array to support more than 1 element that references the same service. This enables the deployer to enable node specific secrets for some service secrets but disable it for others.
In order for a secret to be considered a node specific secret, it's name must adhere to the following pattern:
- For org wide secrets; node/<node-id>/<secret-name>, where the deployer specifies <secret-name> in the deployment policy.
- For user specific secrets; user/<user-id>/node/<node-id>/<secret-name>, where the deployer specifies user/<user-id/<secret-name> in the deployment policy.
The supported format for <secret-name> is not changed in this design.
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 configure a specific secret to some of the nodes where a given 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 support the changes described above. Notably, validation of the secretBinding section should produce a warning to create node specific secrets if the specified secret is not found AND "enableNodeLevelSecrets" is true.
hzn secretsmanager secrete add/list/read/remove
The syntax and flags supported by these commands is not changed, but the implementation is updated to support node specific secret names.
hzn deploycheck
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.
Agbot secure API is updated to support node specific secrets:
"/org/{org}/secrets/node/{node}" the LIST API is added
"/org/{org}/secrets/node/{node}/{secret:[\w\/\-]+}" the "GET", "LIST", "PUT", "POST", "DELETE" APIs are added
"/org/{org}/secrets/user/{user}/node/{node}" the LIST API is added
"/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