Add requirements for Trust Policy management. #89
Conversation
Signed-off-by: Milind Gokarn <milind81@gmail.com>
|
|
||
| Deployers who consume signed artifacts from a registry require that only artifacts from trusted parties are deployed and executed. The trusted parties are specified in some form of a trust policy against which the signed artifacts are validated. The trust policy can include a trust store with trusted root and leaf keys/certificates which represent the Publisher identities the Deployer trusts. This section covers where the trust policies should be stored, and how they are distributed/updated. | ||
|
|
||
| Root keys form the basis of hierarchical trust systems, where intermediate and leaf keys chain back to a root key, and leaf keys are used to generate signatures. Consumers of signed artifacts associate a baseline level of trust with signatures that chain to roots they trust. In the scenario that a root key is no longer trusted, all signed artifacts chaining back to the root are no longer trusted. The conditions which render the root keys to be no longer trusted, are disclosed to the customer through some other channel (CVE, internal security audit, etc.). Safe rotation of keys require a overlap period where both new and old root keys are trusted. This is always not possible, such as when a root key is compromised. |
There was a problem hiding this comment.
Roots and intermediates should also be able to delegate a subset of control using namespacing so that the owner of a leaf key is only trusted to sign the artifacts that they are responsible for.
| 2. A Publisher’s repository may contain a mix of artifacts, published by different teams using different keys. The Deployer wants to trust only artifacts signed by specific keys. | ||
| - E.g. A group may include the MySQL image from docker hub, and the MySQL Helm chart from another group in the same registry/repo. These are signed by different entities, and valid to be placed in the same repository. | ||
|
|
||
| #### Scenarios for Trust Store Updates |
There was a problem hiding this comment.
I'd also add a scenario for a root/intermediary revoking/replacing a delegated key.
| - Trust policies need not be stored in another location | ||
| - Allows in band/automated distribution and update of trust policies to consumers. | ||
|
|
||
| Cons |
There was a problem hiding this comment.
There's also a timeliness issue. If new policies are added, the registry would also need to provide a way to ensure you're getting the most recent policy.
| - This model does not allow Deployers to independently define trust policies. Furthermore, it may be required that Deployer Admins define trusted publishers, and Deployer Operators only specify/configure which artifacts (from repositories) are deployed. | ||
|
|
||
| ## Recommendation | ||
| - Trust policies SHOULD NOT be stored in the registry. Multiple Deployers can consume artifacts from the same repository, and may need to define trust policies independently. |
There was a problem hiding this comment.
A potential downside is that the user would need to access a third-party service, which was one of the complaints about notary v1.
|
@gokarnm, Has this been captured in the signature specs? |
|
This PR will complete the last remaining issue around Trust Policy mgmt, and once merged we can close #83 |
|
@iamsamirzon @gokarnm @priteshbandi Any suggestions on how to move this PR forward? It has been open for quite a long time. Thanks. |
PR for #83 , Trust Policy management and Trust store updates, there are no comments on the corresponding hackdoc to track. Also created a new folder for requirements so that we don't crowd the top level dir.
Signed-off-by: Milind Gokarn milind81@gmail.com