search

validatedpatterns / patterns-operator

Apache License 2.0
5 stars 12 forks source link

Support http proxy #185

Open mzhidovinov opened 5 months ago

mzhidovinov commented 5 months ago

Patterns Operator needs to support deployments that require the use of HTTP proxy to access the git repo (e.g. for initial cloning).

Two scenarios should be recognized:

  1. There is a cluster-wide proxy configuration. Patterns operator needs to recognize and use resulting environment variables (e.g. HTTP_PROXY/HTTPS_PROXY/NO_PROXY).
  2. The use of proxy is configured specifically for the Patterns Operator (e.g. for given repo) In that case, Patterns Operator may need to propagate the proxy configuration to the appropriate ArgoCD instances This may require support from validatedpatterns/common
mbaldessari commented 5 months ago

So part 1. is done via https://github.com/validatedpatterns/patterns-operator/pull/190 . It will be part of the upcoming 0.0.45 release (will be a few days, because the community CI is currently down and it is required to release a new version).

mbaldessari commented 5 months ago

So I managed to cram it in to 0.0.44 which is out now. If you also update common/ in your project, cluster-wide proxy support should just work out of the box. Can you let me know if it all works for you as well? (I tested http proxy, https + custom ca and without proxy and they all worked okay for me). Thanks

mzhidovinov commented 5 months ago

Thanks a lot,

I can confirm that it works for my case. I am testing with http proxy and standard RHCOS trusted CA bundle

BR, Michael

On Tue, 16 Apr 2024 at 18:47, Michele Baldessari @.***> wrote:

So I managed to cram it in to 0.0.44 which is out now. If you also update common/ in your project, cluster-wide proxy support should just work out of the box. Can you let me know if it all works for you as well? (I tested http proxy, https + custom ca and without proxy and they all worked okay for me). Thanks

— Reply to this email directly, view it on GitHub https://github.com/validatedpatterns/patterns-operator/issues/185#issuecomment-2059408934, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMXS74D5SEXKRY43F34DFDY5VBY7AVCNFSM6AAAAABF4T6QCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJZGQYDQOJTGQ . You are receiving this because you authored the thread.Message ID: @.***>

mbaldessari commented 5 months ago

Thanks Michael! So I was wondering what the use case for 2. is because it feels like we'd be adding quite a bit of code all over the place to support that (changes in the operator + common). It kinda feels very niche? I mean, if you have a proxy you must use then the whole cluster usually has to use it, I would expect.

mzhidovinov commented 5 months ago

It is common in many disconnected environments, e.g. there is no access to the outside and cluster wide proxy is not allowed by site security policy, but targeted proxy config is ok, e.g. specific subsystems like gitops or patterns-operator can be configured to use proxy. btw in many cases it will not be a proxy to the internet, but to the other side of the corporate network. Support for custom CA will be important.

It is quite common scenario e.g. for telcos

BR, Michael

On Fri, 19 Apr 2024 at 12:25, Michele Baldessari @.***> wrote:

Thanks Michael! So I was wondering what the use case for 2. is because it feels like we'd be adding quite a bit of code all over the place to support that (changes in the operator + common). It kinda feels very niche? I mean, if you have a proxy you must use then the whole cluster usually has to use it, I would expect.

— Reply to this email directly, view it on GitHub https://github.com/validatedpatterns/patterns-operator/issues/185#issuecomment-2066183581, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABMXS73SFKQGVEOYME6CNADY6DPJHAVCNFSM6AAAAABF4T6QCWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRWGE4DGNJYGE . You are receiving this because you authored the thread.Message ID: @.***>

mbaldessari commented 5 months ago

Thanks Michael, this is helpful! Btw. Custom CA is somewhat already there, just make sure that in your pattern CR you add extraCapabilities: initcontainers in the spec field and make sure you have the operator version at >= 0.0.44. Once you do that it will magically pick up the trusted-ca-bundle in all argo instances. The reason for it not being the default is that we're still testing a few scenarios.