https://rancher.com/ logo
Title
t

tall-summer-94523

10/10/2022, 10:56 PM
Hi all! I have two rancher environments that I'm managing – one v2.5 fronting a single RKE cluster, one v2.6 with a single imported cluster, both standalone docker installs – and in both cases we have the agents talking back to the server through cloudflare proxied DNS across the public internet, despite living in the same VPC. The servers' certificate SANs do not currently include the raw IP addresses, if that's relevant, thought I would also be fine wholly disabling TLS verification or disabling TLS altogether if all this traffic becomes internal (if those are even viable options). IP whitelisting has gotten a bit cumbersome on both sides as we move from pets => cattle and the whole setup seems a bit silly. I definitely don't want to break our live environments, though. Thoughts? Suggestions? I'd love to just have the agents talk to the private IP directly and have the node agents advertise their private IPs, dynamically resolved via the metadata service. The path for the latter seems pretty clear, though I don't know what risk exists of making that change in place. For agent => server comms I am not entirely clear what's necessary / possible or what risks exist. Any help is much appreciated! Cheers.
c

creamy-pencil-82913

10/11/2022, 12:07 AM
servers don’t connect directly to agents. Communication is all agent-initiated.
So, configure your network so that the Rancher server addresses resolve to something that doesn’t involve going out to CF
Also, you should be aware that standalone Docker installs of Rancher Manager aren’t supported for anything other than very basic dev/proof-of-concept work.
t

tall-summer-94523

10/11/2022, 12:19 AM
FWIW I did not choose that pattern – it's what I recently inherited – but both are snapshotted regularly, the infrastructure is all declaratively version-controlled, the kubernetes manifests are all being declaratively version-controlled and soon to be continuously deployed as we speak, reducing rancher to a read-only dashboard for everything already checked in, and the production cluster is the imported one. I don't love it, but am not terrified of what currently is and have larger fish to fry at present.
And thank you. So you're proposing I hack at cluster-internal DNS resolution one way or another rather than messing with
CATTLE_SERVER
,
--address
|
--internal-address
and whatever TLS knobs exist on the agent side, then?
c

creamy-pencil-82913

10/11/2022, 12:36 AM
yes. all that matters is the CATTLE_SERVER URL.
The agent connects to the server and maintains a websocket tunnel, when the server needs to connect to the cluster it builds a reverse connection through that websocket to the agent’s in-cluster kubernetes apiserver endpoint.
So, if you can get that URL to resolve to something internal to your VPC, that uses a cert trusted by the agent, you can avoid going out to the internet.
t

tall-summer-94523

10/11/2022, 12:39 AM
coredns to the rescue
Thank you ❤️