Relaxing security requirements

[rlewkowicz]

Describe the bug

Overall I'm getting frustrated with what seems to be a broader software trend of forced https, and general security. The hand holding is insane. From flux to google chrome (https://stackoverflow.com/questions/58802767/no-proceed-anyway-option-on-neterr-cert-invalid-in-chrome-on-macos/63539455#63539455). It's literally a joke.

I asked this question while I was at another company: https://github.com/fluxcd/flux2/issues/689

We pivoted to https so it was never resolved, but at a new company I am once again in need of an ability to inject an ssh config. At the prior company, they had rotating proxies and I just don't have enough time to go back and fourth in an issues thread. There, I wouldn't even always get the same out bound key, and here I honestly have no idea why it's not working. It's a docker desktop environment and theoretically we all have the same one.

I know it's rough, but I'm working with a small company right now and their on prem git doesn't use https. I can't use http. I can understand if there was a development issue and it was easier to scrap http but if that's an intentional decision to "protect" users it's a very frustrating one.

I want to disable strict key host checking. It's such a simple request. Please. I just wish every project on the planet would stop trying to force security on me. These are my risks to consider and a decision I should be able to make.

I have a nice pull against flux v1 that never went anywhere as it was a feature add after deprecation. I'm willing to contribute and be a part of the community. Follow guidelines etc. If I spend the time, and add the functionality, does that even have the possibility of being merged or is it going to get bogged down in committee?

Steps to reproduce

Try to install flux against a system with rotating keys and or http

Expected behavior

Allow me to disable strict key host checking

Screenshots and recordings

No response

OS / Distro

Mac OS

Flux version

flux: v0.30.2

Flux check

► checking prerequisites ✗ flux 0.30.2 <0.31.1 (new version is available, please upgrade) ✔ Kubernetes 1.22.5 >=1.20.6-0 ► checking controllers ✔ helm-controller: deployment ready ► ghcr.io/fluxcd/helm-controller:v0.22.0 ✔ kustomize-controller: deployment ready ► ghcr.io/fluxcd/kustomize-controller:v0.26.0 ✔ notification-controller: deployment ready ► ghcr.io/fluxcd/notification-controller:v0.24.0 ✔ source-controller: deployment ready ► ghcr.io/fluxcd/source-controller:v0.25.3 ✔ all checks passed

Git provider

bitbucket

Container Registry provider

No response

Additional context

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[stefanprodan]

Latest Flux allows you to bootstrap with an HTTP repo. The flux bootstrap git --allow-insecure-http=true was implemented in https://github.com/fluxcd/flux2/pull/2787 Please try it out and see if it works for you.

[rlewkowicz]

First, I apologize for letting my frustrations show through. I'm embarrassed.

flux bootstrap git -s --allow-insecure-http=true \
  --url=REDACT \
  --username REDACT  \
  --password 'REDACT' \
  --branch=master \
  --path=.

It seems flux still attempts an key scan:

✗ SSH key scan for host REDACT failed, error: ssh: handshake failed: ssh: overflow reading version string

setting an ssh hostname seems to resolve it, but then I get timeout:

...
► applying source secret "flux-system/flux-system"
✔ reconciled source secret
► generating sync manifests
✔ generated sync manifests
✔ sync manifests are up to date
► applying sync manifests
✔ reconciled sync configuration
◎ waiting for Kustomization "flux-system/flux-system" to be reconciled
✗ client rate limiter Wait returned an error: context deadline exceeded
► confirming components are healthy
✔ helm-controller: deployment ready
✔ kustomize-controller: deployment ready
✔ notification-controller: deployment ready
✔ source-controller: deployment ready
✔ all components are healthy
✗ bootstrap failed with 1 health check failure(s)

[stefanprodan]

There is no SSH here, you need to give bootstrap the http address and --token-auth.

[stefanprodan]

This is how it works for HTTP and basic auth:

flux bootstrap git -s --allow-insecure-http=true --token-auth \
  --url=http://<URL> \
  --username REDACT  \
  --password 'REDACT' \
  --branch=master \
  --path=.

If you run flux bootstrap git -h:

--token-auth                             when enabled, the personal access token will be used instead of SSH deploy key

[rlewkowicz]

I tried a number of configurations, I believe those were among them. It seemed as if the source controller was still attempting to use SSH even though I set the http url.

My solution in the end was to stand up a local mitm proxy (as this is a local dev env) that simply proxies to our git installation. As a side note, --insecure-skip-tls-verify does not seem to function either. Even with the token auth. You may need additional testing around insecure features.

For those out there with similar issues, this was my approach:

docker run --name git_proxy --restart=always -v $HOME/.mitmproxy:/home/mitmproxy/.mitmproxy -d -p 60000:443 mitmproxy/mitmproxy mitmdump -p 443 --mode reverse:http://REDACT > /dev/null 2>/dev/null

Then for the bootstrap:

flux bootstrap git -s --ca-file $HOME/.mitmproxy/mitmproxy-ca-cert.cer --token-auth \
  --url=https://proxy_url:60000/your/path/flux.git \
  --username YOUR_USER \
  --password 'YOUR_PASSWORD' \
  --branch=master \
  --path=.

I also shim a dns provider so I'm able to set the url there for the git shim and flux can find that still from within the cluster.

I am known to make goofy mistakes, but I'm not confident any of the insecure options function as intended.

[somtochiama]

Hey @rlewkowicz , I tested this out with a http repository and it worked okay for me with this command.

flux bootstrap git --allow-insecure-http=true --url=http://<URL> --password <password> --username root -s

[carlosonunez-vmw]

There is no SSH here, you need to give bootstrap the http address and --token-auth.

@stefanprodan if you specify --token-auth with --allow-insecure-http, the Git bootstrapper will default to HTTPS anyway. See here

However, if you don't specify it, it will try to scan for host keys on the target host, which isn't always possible.