How should the Athenz jwk config be distributed? about athenz HOT 5 OPEN

Is it assumed that the jwt format of athenz conf will be distributed by sia?

from athenz.

I understand that sia acquires the information via postInstanceRegisterInformation and postInstanceRefreshInformation.

Would it be feasible to expose the jwkConfig utilized by the two methods mentioned above as an API of ZTS?

Or should this be implemented in sia instead?

from athenz.

I'm slowly moving away from athenz.conf since that was a proprietary format and instead I prefer to use the jwk format as defined in rfc7517.

the initial implementation relies on SIA to automatically fetch the conf file and keep it updated periodically. This eliminates the need for the client to worry about how to refresh and whenever it sees an unknown key, all it needs to do is to reload the latest file from disk which should be updated.

So I would strongly recommend if you're implement your own SIA, then make this part of the agent so it automatically gets updated daily. The server logic only returns the data if there are changes so you don't waste network resources by sending the data every time.

As far as separate APIs, we already have /oauth2/keys API which returns the ZTS keys in this format. If you want to get the zms keys, we can extend this api to specify an optional query element to specify the service name (e.g. /oauth2/keys?rfc=true is default and returns ZTS keys but if you specify /oauth2/keys?rfc=true&service=zms then it can return the ZMS keys - this way we don't need yet another API

from athenz.

Thank you for your proposal. We will consider how we can implement this in our environment.

By the way, regarding the use of JWS policy, I believe that the verification key for ZMS is not inherently necessary. However, is it correct to understand that the current ZTS provides the ZMS verification key in postInstanceRegisterInformation and postInstanceRefreshInformation for backward compatibility?

Specifically, the PublicKeyStore interface used by ZPE has a method named getZmsKey. While the verification of JWS Policy only requires the ZTS verification key, ensuring the principle of Java interface contracts mandates the implementation of this method.

I believe that in the future, the ZMS verification key will become unnecessary for ZPE's PublicKeyStore. Is there any difference in understanding?

from athenz.

ZTS does not just cater ZPE use cases. It's possible that you have an application that fetches full domain jws files from ZMS and needs the public keys for verification of the signature. So we provide both ZMS and ZTS public keys for all clients.

So while ZPE will eventually no longer need ZMS public keys (most likely we'll remove it from the 1.12.x release scheduled sometime in Q3), ZTS will continue to provide the ZMS and ZTS keys.

from athenz.