support for service jwt svids #3153
Description
current Athenz only issues x.509 svids. Vespa has a use case where they want to fetch service identity jwt id tokens directly instead of fetching an identity x.509 certificate first and then using that identity to request an id token for the service.
ZTS already has all the components in place so we just need to extend the postInstanceRegister endpoint to request x.509 and jwt svids. We'll make the csr and attestation-data fields in the request object as optional and if the csr is not provided then the client is asking for jwt svid.
We'll also have new fields in the instance register object to specify the instance-id, audience, nonce, spiffe values for the jwt svids. if the spiffe-subject field is configured true, then the sub claim in the jwt svid will be the spiffe uri, otherwise the sub claim will be the service identity and the spiffe uri will be included in the spiffe claim.
The instance provider interface will have a new required method to indicate the type of svid it supports - x509 vs jwt. It will have a default value of x509 so none of the existing providers require any type of change.
As part of the change, we'll also include a new jwt instance provider called InstanceAthenzRBACProvider. This provider requires mTLS connection to ZTS and uses the identity from the certificate to carry out an internal authorization check to see if the principal is authorized to obtain a jwt svid for the given service. For example, in the athenz.demo domain, we can create the following policy with the assertion
allow zts.assume_service to api_service_launchers on service.api
and principal in the api_service_launchers role can request identity jwt svids for service called api
we'll also provide a utility called zts-svctoken that could be utilized to fetch service jwt svids from zts