Title:
Support Envoy to fetch token via SDS and make token consumable by filters and clusters.

Description:
There are two scenarios that require Envoy to fetch and inject a dynamic token into a request.

1. When Envoy fetches config from a config server via ADS, if the config server requires a token to authenticate (e.g. OAuth2 token), Envoy needs to pass a token to authenticate to that config server. If a token is going to expire, Envoy should refresh token and send latest token in next ADS call.

2. When Envoy receives a request and forwards the request to a server where token authentication is required, Envoy needs to inject a token into the request before sending it to server. When a token is going to expire, Envoy should be able to refresh the token. If there are several different servers that have token authentication enabled, Envoy should fetch corresponding token and inject valid token into each request.

The tokens are provisioned by a token server which exposes SDS API. The token server checks resource name carried in every SDS request, and decides which token to be sent out in response. The server is responsible for rotating tokens, and is responsible for pushing refreshed token to Envoy via SDS. This follows the XDS protocol.

Proposal:

• Support Envoy SDS to fetch and refresh token dynamically. We need to add a new secret type into auth.Secret to store token resource. Since SDS is working at main thread, fetching token via SDS does not affect performance at worker threads.

• Support gRPC service to pass dynamic token to upstream. We need to add a new type of call credential into core.GrpcService.GoogleGrpc.CallCredentials and this new type has auth.SdsSecretConfig to fetch token.

• Add a new HTTP filter to inject tokens into requests. We may need to add auth.SdsSecretConfig into listener config to fetch tokens. auth.SdsSecretConfig has a unique SDS resource name which matches a token resource in the token server. We add SDS resource name into the new filter in order to let filter pick the right token for token injection. We can also configure the filter to inject tokens into certain type of requests instead of all proxied requests. I am not sure if this is the right approach, whether a filter could access resources stored in a listener object. Any suggestions are welcomed.