You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two issues related to k8s multi-tenancy, see #195 and #225. This issue tries to make a summary and clarify the scenarios.
Multi-tenancy in Kubernetes allows multiple tenants to share the same cluster resources while maintaining their own isolated environments.
An organization could set up multi-tenancy for different teams, so that each team can share some common resources, while maintaining their own resources. This allows organizations to maximize resources and reduce costs.
An k8s cluster could be shared by different organizations, so that different organizations can share some common resources, while maintaining their own isolated environment. This is valuable for a group of small companies who cannot afford a cluster, but still can have a secure and reliable environment for their own services.
Currently Ratify is a single instance in k8s cluster, and some CRDs are on cluster level. Ratify support multi-tenancy could mean:
Each tenant can manage own Ratify policies independently of other tenants based on their own business
Each tenant can manage own Ratify stores independently of other tenants
Each tenant can manage own Ratify verifiers independently of other tenants
Each tenant can share certain parts of Ratify policies, stores, or verifiers from cluster level.
This issue is to clarify the scenarios of multi-tenancy support and agree on the way forward.
Anything else you would like to add?
Work Item break down:
Support namespace field in external data request key
We already have a design doc on the multi-tenancy model, which can be broken down into a few tasks listed in https://hackmd.io/qrJi6ZtzQeeVo0bWEplohw
Created a few sub-tasks for multi-tenancy:
Support namespace field in external data request key
Cache isolation
Refactor core workflow to apply namespaced/clustered resources.
What would you like to be added?
There are two issues related to k8s multi-tenancy, see #195 and #225. This issue tries to make a summary and clarify the scenarios.
Multi-tenancy in Kubernetes allows multiple tenants to share the same cluster resources while maintaining their own isolated environments.
Currently Ratify is a single instance in k8s cluster, and some CRDs are on cluster level. Ratify support multi-tenancy could mean:
This issue is to clarify the scenarios of multi-tenancy support and agree on the way forward.
Anything else you would like to add?
Work Item break down:
Are you willing to submit PRs to contribute to this feature?
The text was updated successfully, but these errors were encountered: