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
Enabling Rancher as an OIDC Provider by rcabello
Description
Kubernetes supports OpenID Connect (OIDC) natively as an authentication mechanism, enabling token-based user authentication. This can be configured through flags in the Kubernetes API server or by using AuthenticationConfiguration.
The purpose of this project is to enable Rancher to function as an OIDC provider, allowing Rancher's local cluster to act as an OIDC identity provider for downstream clusters. This setup will allow users to authenticate directly with downstream clusters without relying on Rancher’s proxy and impersonation mechanisms.
Rancher will continue to support all authentication providers. When a user attempts to log in via the Rancher OIDC provider, they will be redirected to the authentication provider configured in Rancher.
This approach also facilitates integration with third-party tools (e.g StackState)
Goals
- Implement Rancher as an OIDC provider using the ORY Fosite library, focusing only on the essential functionality required for basic integration.
- Enable downstream clusters to authenticate using JWT tokens issued by Rancher.
- Configure StackState to authenticate using Rancher as an OIDC provider.
Resources
https://github.com/ory/fosite
Introducing "Bottles": A Proof of Concept for Multi-Version CRD Management in Kubernetes by aruiz
Description
As we delve deeper into the complexities of managing multiple CRD versions within a single Kubernetes cluster, I want to introduce "Bottles" - a proof of concept that aims to address these challenges.
Bottles propose a novel approach to isolating and deploying different CRD versions in a self-contained environment. This would allow for greater flexibility and efficiency in managing diverse workloads.
Goals
- Evaluate Feasibility: determine if this approach is technically viable, as well as identifying possible obstacles and limitations.
- Reuse existing technology: leverage existing products whenever possible, e.g. build on top of Kubewarden as admission controller.
- Focus on Rancher's use case: the ultimate goal is to be able to use this approach to solve Rancher users' needs.
Resources
Core concepts:
- ConfigMaps: Bottles could be defined and configured using ConfigMaps.
- Admission Controller: An admission controller will detect "bootled" CRDs being installed and replace the resource name used to store them.
- Aggregated API Server: By analyzing the author of a request, the aggregated API server will determine the correct bottle and route the request accordingly, making it transparent for the user.
Rancher/k8s Trouble-Maker by tonyhansen
Project Description
When studying for my RHCSA, I found trouble-maker, which is a program that breaks a Linux OS and requires you to fix it. I want to create something similar for Rancher/k8s that can allow for troubleshooting an unknown environment.
Goal for this Hackweek
Create a basic framework for creating Rancher/k8s cluster lab environments as needed for the Break/Fix Create at least 5 modules that can be applied to the cluster and require troubleshooting
Resources
https://github.com/rancher/terraform-provider-rancher2 https://github.com/rancher/tf-rancher-up
A CLI for Harvester by mohamed.belgaied
[comment]: # Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI [comment]: # Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. [comment]: # Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.
Project Description
Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as:
harvester vm create my-vm --count 5
to create 5 VMs named my-vm-01 to my-vm-05.
Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.
Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli
Done in previous Hackweeks
- Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
- Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE
Goal for this Hackweek
The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.
Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it
Issue list is here: https://github.com/belgaied2/harvester-cli/issues
Resources
The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact).
Welcome contributions are:
- Testing it and creating issues
- Documentation
- Go code improvement
What you might learn
Harvester CLI might be interesting to you if you want to learn more about:
- GitHub Actions
- Harvester as a SUSE Product
- Go programming language
- Kubernetes API
Rancher microfrontend extension by ftorchia
Description
Rancher UI Extensions allow users, developers, partners, and customers to extend and enhance the Rancher UI. Extensions are Helm charts that can only be installed once into a cluster. The charts contain a UI built package that is downloaded and linked to the Host UI at runtime; this means that the extension pkg needs to be implemented using the same technology and have the same APIs as Rancher UI.
Goals
We want to create a new type of Rancher extension, based on microfrontend pattern. The extension is served in a docker container in the k8s clusters and embedded in the host UI; this would guarantee us to be able to create extensions unrelated to the rancher UI architecture, in any technology we want to build it. The communication between host and microfrontend would be implemented using postMessage();
Non Goals
We want to create product-level extensions; we don't want to create cluster-level extensions.
Resources
rancher-extension-microfrontend
OpenQA Golang api client by hilchev
Description
I would like to make a simple cli tool to communicate with the OpenQA API
Goals
- OpenQA has a ton of information that is hard to get via the UI. A tool like this would make my life easier :)
- Would potentially make it easier in the future to make UI changes without Perl.
- Improve my Golang skills
Resources
- https://go.dev/doc/
- https://openqa.opensuse.org/api