Add support for multiple trust policies

[vishal-chdhry]

Is your feature request related to a problem?

There is a use case that can allow verification performed by an admission controller in a multi-tenant cluster, where we have two teams with the same image reference deployed in different namespaces using different signatures and trust policies.

What solution do you propose?

Adding support for passing trust policies when verifying.

Solution

What we are doing right now in our use case is

1. Replace notation verifier with notation verifier factory
2. Notation verifier factory is a collection of verifiers, every verifier is created for each trust policy in the notation directory
3. All notation verifiers are refreshed every time there is a change in trust policy or trust stores.
4. To specify what trust policy to use, one can pass trustpolicy in the request or set DEFAULT_TRUST_POLICY env in the deployment.

It would be great if we can do something similar internally instead of externally

1. We can have a trustpolicies.json that will have the locations of all trust policies names and locations and have a default.
2. Instead of keeping track of one Trust Document, we can have a factory that will return either the default trust document or the right trust document based on the request.

What alternatives have you considered?

We are doing something similar at the verifier level, but having this at a lower level would be great

Any additional context?

No response

[yizha1]

Thanks @vishal-chdhry. Other alternatives could be notation verify supports verifying inline policies or specifying a different trust policy file to overwrite the default trust policy file. For example,

notation verify --policy <json_obj>

notation verify --policy <file_path>

[priteshbandi]

For CLI

If this is an advanced scenario, IMO using DEFAULT_TRUST_POLICY env variable instead of --policy would be preferable. For example, if user/team 'A' can set the env variable and now use their own trust policy, while team B can continue to use the default trust policy. The problem I see with a flag is that it needs to be passed every time verify is invoked so unless same user wants to switch between trust policy env variable is better option.

For library

We already expose func Verify(ctx context.Context, verifier Verifier, repo registry.Repository, verifyOpts VerifyOptions) which allows verifier as input and user can create verifier with there own trust policy New(trustPolicy *trustpolicy.Document, trustStore truststore.X509TrustStore, pluginManager plugin.Manager) (notation.Verifier, error).

cc:/ @iamsamirzon

[vishal-chdhry]

Are there any plans to add this to Notary, I would love to help

[yizha1]

Thanks @vishal-chdhry. Would you mind clarifying the scenarios that you wrote in the issue?

There is a use case that can allow verification performed by an admission controller in a multi-tenant cluster, where we have two teams with the same image reference deployed in different namespaces using different signatures and trust policies.

• How do you use Notation in the scenario of a multi-tenant cluster?
• Should the two teams store the image in different paths of the registry or a different registry?