Overview
Every Rafay customer (e.g. enterprise) get access to their own Org. With an Org, multiple options for multi tenancy are supported for users (e.g. data scientists, ML engineers, GenAI app developers).
For every tenant, a number of critical security controls are automatically implemented and enforced to ensure that risks associated with threats such as lateral escalation etc can be blocked.
Threats & Controls¶
Click on each control in the table below for detailed information describing how the controls implemented by Rafay help mitigate the associated threat/risk.
| # | Threat/Risk | Controls | Supported |
|---|---|---|---|
| 1 | Prevent malicious containers from lateral escalation inside the cluster | Isolated Kata Containers | |
| 2 | Prevent malicious containers from using the data center network for lateral escalation to other hosts/services in the data center | Network Policy | |
| 3 | Prevent malicious containers from escaping the container by becoming root etc | Cluster Policy | |
| 4 | Prevent users from touching resources that are not theirs | RBAC | |
| 5 | Ensure only authenticated and authorized users can access resources | Secure Remote Access | |
| 6 | Prevent users from using more resources than allocation | Resource Quotas | |
| 7 | Ensure there is an immutable audit trail for every action | Audit Logging | |
| 8 | Ensure costs can be attached to every resource and allocated to users | Cost Visibility & Allocation | |
| 9 | Network Segmentation via VPCs using Kube-OVN | Network Segmentation |
Options¶
Virtual Clusters¶
This is the default option supported by the solution. Virtual clusters (aka vClusters) are essentially full Kubernetes clusters that operate inside a namespace. Virtual clusters have their own API server that provides better isolation for use cases where namespaces are not practical.
Tenant Autonomy¶
A data scientist that needs to install software packaged as Kubernetes CRDs into a namespace because of lack of privileges. With a virtual cluster, the platform team can provide the user with full autonomy.
Separation of Duties¶
Instead of a complex, shared responsibility and support model, platform teams can focus on supporting and maintaining the underlying "host cluster" and the "namespace" in which the virtual cluster will operate in. They can delegate the administrative responsibilities of the virtual cluster to the end user.
Namespace¶
A Kubernetes namespace allows the organization to partition an existing cluster into logical mini-clusters and assign them to users. Users allocated a Kubernetes namespace will not have privileged access to the cluster. For example, they will not have cluster-wide privileges required to deploy applications that are packaged as CRDs.
Note
Users that require support for cluster-wide privileges are recommended to use the "Virtual Cluster" option described below.