Currently, when Rancher tries to provision a Kubernetes cluster on vSphere, it needs to initiate API calls to the vSphere endpoint. In a hybrid cloud environment this often means that the Rancher server is not in the same network as the vSphere endpoint. Therefore inbound access is required to be added to a firewall so Rancher can reach the vSphere system. This naturally poses a security concern and creates administrative burden on our users who have to go through a security review to get this approved.
If instead of requiring direct API access, an agent could exist inside the network where the vSphere API lived, then this agent could broker the communication between the Rancher server and the downstream API. The agent would simply initiate an outbound API connection to the Rancher server (much like any node agent or cluster agent currently) and simultaneously proxy any API calls that Rancher needs to make to vSphere. This would also have the benefit of being able to be run through a HTTP proxy, which many security teams will appreciate as a less risky connectivity model.
No Hackers yet
This project is part of:
Hack Week 20
Activity
Comments
Be the first to comment!
Similar Projects
Rancher microfrontend extension by ftorchia
Description
Rancher UI Extensions allow u...
Introducing "Bottles": A Proof of Concept for Multi-Version CRD Management in Kubernetes by aruiz
Description
As we delve deeper into the c...
Integrate Backstage with Rancher Manager by nwmacd
Description
Backstage (backstage.io) is a...
Rancher/k8s Trouble-Maker by tonyhansen
[comment]: # (Please use the project descriptio...
CVE portal for SUSE Rancher products by gmacedo
Description
Currently it's a bit difficul...