feature: implement policy store

[ereslibre]

No description provided.

[flavio]

Everything looks good, on top of the comment I left I have two observations:

• This changes from the native-tls to rusttls. This is cool from a certain POV, I'm thinking about a statically linked kwctl binary. However, this crate will be used also inside of the policy-server, which is stuck with the native-tls crate. I don't think this will cause issues, do you?
• We really need some tests for the methods that you introduced, like the ones that build all the paths for the local store. I'm not saying we have to go "crazy" and provide e2e tests that download things from real registries/http/https servers, but there are definitely some low hanging fruits from the testing POV that we must grab

[ereslibre]

This changes from the native-tls to rusttls. This is cool from a certain POV, I'm thinking about a statically linked kwctl binary. However, this crate will be used also inside of the policy-server, which is stuck with the native-tls crate. I don't think this will cause issues, do you?

I don't think so, in principle. The policy-server will do the TLS termination of the requests made by the apiserver, whereas when fetching policies we'll use rustls. They have different CA default stores -- meaning, rustls has its own main CA store, while native-tls uses the system one.

I think we can add a task for checking if this is the best combination and possible hazards later. Meaning: for doing the TLS termination we don't care that much about root CA certificates (and we are using the system certs by using native-tls at this time), but we care a lot about the CA store of the policy-fetcher (using rustls). How secure is to rely on rustls for this? Before bumping dependencies in this case we should check that the store included by rustls only contains well-known CA's, and only those well known, nothing more.

We really need some tests for the methods that you introduced, like the ones that build all the paths for the local store. I'm not saying we have to go "crazy" and provide e2e tests that download things from real registries/http/https servers, but there are definitely some low hanging fruits from the testing POV that we must grab

👍

[flavio]

LGTM, please... start working on the test suite