Documentation needed for allowing cache access from different types of bazel clients about bb-storage

[EdSchouten]

If you only do remote caching (no remote execution), then you can make both your CAS and AC read-only for traffic coming from individual dev VMs. If you use remote execution, you must always permit writes to the CAS, as clients will upload input files into it. If you want to limit write access, you can always follow a recipe like this:

Set up a proper authorization policy

The default we provide in the README is:

putAuthorizer: { allow: {} },

You can change that to something like this:

putAuthorizer: { jmespathExpression: 'authenticationMetadata.private.mayWriteAC' },

This says: Only allow clients to put/write objects into the data store if the private part of their authentication metadata has a boolean field named mayWriteAC with value true.

Setting up an authentication policy

Now that we've added authorization logic for conditionally permitting write access to the AC, we must also set up our authentication facilities accordingly, so that we can distinguish both sources of traffic. Notice how the README simply says this:

authenticationPolicy: { allow: {} },

This says: simply allow all traffic, and give it an empty instance of the authentication metadata. If we wanted to give all incoming traffic write access to the AC with the authorization policy above, you can write:

authenticationPolicy: { allow: { private: { mayWriteAC: true } } },

But this is of course undesirable. We only want to grant some users write access. So let's use this instead:

authenticationPolicy: { any: { policies: [
  { jwt: {
    publicKey: ...,
    maximumCacheSize: 10000,                                                     
    cacheReplacementPolicy: 'LEAST_RECENTLY_USED',                               
    claimsValidationJmespathExpression: '`true`',                                
    metadataExtractionJmespathExpression: '{ "private": { "mayWriteAC": `true` } }',
  } },
  { jwt: {
    publicKey: ...,
    maximumCacheSize: 10000,                                                     
    cacheReplacementPolicy: 'LEAST_RECENTLY_USED',                               
    claimsValidationJmespathExpression: '`true`',                                
    metadataExtractionJmespathExpression: '`{}`',
  } },
] } },

And there you have it: traffic using JWTs signed using one key will be able to write into the AC, while the other ones will not. The reason being that the second entry yields empty authentication metadata, which does not satisfy the expression used in the authorization policy.

Hope that helps!