Isolated Mode
Creating a secure multi tenancy environment is hard and vcluster is already able to provide an isolated control plane in a Kubernetes cluster, however actual vcluster workload isolation is currently still up to the users themselves to figure out. With v0.7.0 we want to introduce a new vcluster feature that automatically creates common defaults for workload isolation that can be enabled via the --isolate flag in vcluster create or through the helm value isolation.enabled: true. This feature imposes a couple of restrictions on vcluster workloads to make sure they do not break out of their virtual environment:
- vcluster enforces a Pod Security Standard on syncer level, which means that for example pods that try to run as privileged container or mount a host path will not be synced to the host cluster. Valid options are baseline (default in isolated mode) and restricted.
- vcluster deploys a resource quota as well as limit range alongside the vcluster itself. This allows restricting resource consumption of vcluster workloads. If enabled sane defaults for those 2 resources are chosen.
- (Coming soon) vcluster deploys a network policy alongside itself that will restrict access of vcluster workloads to other pods in the host cluster.
Please take a look at the isolated mode docs for more information.
Changed StorageClasses Syncer
vcluster will now sync storage classes from the virtual cluster to the host cluster if sync of storage classes is enabled. This will replace the current behaviour where storage classes where only synced from host to virtual cluster.
We decided to replace the existing behaviour, because creating storage classes is a valid use case as long as the CSI driver is installed within the host cluster, but certain parameters for the CSI driver should get changed through a storage class. It also makes sense to not sync created storage classes from the host cluster anymore as this is not required to schedule persistent volume claims and currently just has informational purposes.
This is somewhat a breaking change as vclusters that currently have sync of storage classes enabled would now behave differently moving forward as changes to the host cluster storage classes are not propagated anymore. However migration should work as expected, as created storage classes within vcluster that mirrored host cluster storage classes before would just get created in the host cluster under a different name.
Added ServiceAccounts sync support
Added a new service account syncer that makes it possible to sync service accounts from the vcluster to the host cluster with certain annotations and labels. This is useful for features such as IAM Roles for ServiceAccounts where the service account needs a certain annotation to give AWS permissions to a pod
Other Changes
- chart: EKS chart now accepts .sync.* values as documented
- syncer: Adds --sync-label flag to sync untranslated labels onto physical resources (thanks @bschwenn)
- syncer: Fixed an issue where syncing the service
spec.loadBalancerSourceRangeswas not possible