rfcs
rfcs copied to clipboard
TLS support for HTTPChaos
Also
/cc @anuragpaliwal80
Thanks, @Hexilee, for creating this draft. To me, it looks we need different ways to handle server-side and client-side.
- server-side: As per current draft, user has to provide privateKey and certificate, which might be difficult as user don't have access to these details as they have limited rights as per their roles, etc. Needs to explore more.
- client-side: Self-Signed Certificates approach looks good. Looks like we don't need any certificate related details from user. I will keep digging more for better understanding.
In general, as we divided this work between two main areas (server-side and client-side), can we pick the client-side first (if possible).
I divide implementation by client-side and server-side to indicate the self-signed cert and ca-injector
are mostly required by the client-side one. User-provided secrets can resolve the most of use cases for server-side HTTPChaos and parts of use cases for client-side HTTPChaos. @STRRL @Andrewmatilde @anuragpaliwal80
Thanks, @Hexilee, for creating this draft. To me, it looks we need different ways to handle server-side and client-side.
- server-side: As per current draft, user has to provide privateKey and certificate, which might be difficult as user don't have access to these details as they have limited rights as per their roles, etc. Needs to explore more.
- client-side: Self-Signed Certificates approach looks good. Looks like we don't need any certificate related details from user. I will keep digging more for better understanding.
In general, as we divided this work between two main areas (server-side and client-side), can we pick the client-side first (if possible).
We divided the use cases instead of work. The user-provided secrets and self-signed cert are the same implementation in chaos-tproxy. (Actually, we are doing it now https://github.com/chaos-mesh/chaos-tproxy/pull/39)
We divided the use cases instead of work
I agree, it's a better way to say it as use case.
The user-provided secrets and self-signed cert are the same implementation in chaos-tproxy.
Thanks, I will have a look.
Other than this, I was exploring on server side and here are few points that I would like to share:
- Earlier I was thinking it might not be possible to get cert and key, but after exploring more I found it's should be possible, and it even makes sense to get these details from client as mentioned by @STRRL as well.
- The only challenge is to version control this file with these certs and private key and client needs to be careful with the same (which we can assume).
We divided the use cases instead of work
I agree, it's a better way to say it as use case.
The user-provided secrets and self-signed cert are the same implementation in chaos-tproxy.
Thanks, I will have a look.
Other than this, I was exploring on server side and here are few points that I would like to share:
- Earlier I was thinking it might not be possible to get cert and key, but after exploring more I found it's should be possible, and it even makes sense to get these details from client as mentioned by @STRRL as well.
- The only challenge is to version control this file with these certs and private key and client needs to be careful with the same (which we can assume).
When using a certain cert/key pair for the chaos experiment, I think signing new certs from PKI with extremely short validity (like 1 day) could be helpful and make sense.