Hard Tenancy

Although namespaces provide the ability to logically partition a cluster, it is not possible to truly enforce partitioning. This means users or resources operating in the same Kubernetes cluster can access any other resource in the cluster regardless of the namespace it is operating in.

Even if compensating controls such as Network Policies are implemented to block/control "namespace-to-namespace" communication, there is still the "noisy neighbor" problem to consider.

For scenarios where this can be problematic, the only practical solution is to use "dedicated" Kubernetes clusters to guarantee true separation across operational boundaries.

A commonly used term for this single tenant model is Cluster as a Service.

One common example for this is the use of a dedicated cluster for "Production" and "Staging". Users can use "Projects" to achieve this isolation. An illustrative example is shown below.

Environment	Project
Production	"Production" Project with a dedicated Kubernetes cluster. Project configured with least privilege RBAC so that only required users can access the project
Staging	"Staging" Project with a dedicated Kubernetes cluster. Project configured with RBAC so that only required users can access the project

One or multiple Kubernetes clusters can exist in a Project. In the example below, an Amazon EKS cluster has been provisioned in the Project.

Users within a project can switch to another project using the search bar. When a user initiates a search with a specific letter(s) (for example, qe), the system auto complete the search and list out all the project names corresponding to the entered text (qe) as shown in the below example

Deployment Options

The below matrix presents a breakdown of actions like creation, updating, and deletion of projects across multiple deployment methods: Interactive UI, Declarative RCTL commands, API-driven automation, and Terraform.

Action	UI	CLI	API	Terraform
Create	Yes	Yes	Yes	Yes
Update	Yes	Yes	Yes	Yes
Delete	Yes	Yes	Yes	Yes

---

Drift Configurations

On this configuration page, users possess the ability to enable the webhook and Namespace Sync at the project level.

Enabling the drift configuration within a project empowers users to deploy the webhook across all clusters under that project using blueprints, contingent upon its activation at the organization level. Should the webhook be deactivated at the project level, users are not allowed to deploy the drift webhook on any cluster under the same project, even if the organization-level webhook remains enabled. By default, this option is enabled.

Namespace Exclusion

At the project level, users are allowed to define a list of namespaces exempt from synchronization processes. This customization helps prevent unintended changes while still allowing flexibility in managing namespaces. Only the Org Admin has the privilege to add or remove namespaces from the exclusion list.

• Click +Namespace to manually add namespaces for exclusion from synchronization, or choose Upload to upload a file containing a list of namespaces. Only .txt format files are supported for upload. Additionally, multiple file uploads are also supported

• Click Download List to retrieve the excluded namespace list configured here

Access Control

Organizations can restrict which users can access a particular project and with what privileges (i.e. read, read/write etc.) using role based access control

---

Resource Quotas

Organizations can leverage "Resource Quotas" to restrict how much of the cluster resources a namespace can use.

---

Quota Overrides

Cluster Quota Overrides provide flexibility in managing resource limits within a project. By default, the Project Resource Quota applies to all clusters, but with quota overrides, users can define custom resource quotas for specific clusters using a YAML-based specification. This feature allows for more granular control over resource allocation across clusters, ensuring optimal utilization and flexibility based on individual cluster requirements. Users can modify various resource types, such as CPU, Memory, ConfigMaps, and more, with clear steps for configuration.

To learn how to create Cluster Quota Overrides, refer to the detailed steps and examples provided in the Cluster Quota Overrides documentation.

---

Tags/Labels

This page provides a comprehensive view of the tags and labels associated with the project defaultproject, displayed in a read-only format. Tags and labels are grouped by their Type (cost, namespacelabel, k8s), which are the allowed categories, and each group contains key-value pairs. These entries are configured based on the specifications defined in the ProjectTagsAssociation resource, ensuring a structured association of metadata with the project.

The purpose of this page is to allow users to view project-level tags and labels that help organize, identify, and manage resources. These tags and labels align project resources with various organizational or technical requirements, depending on specific use cases. Grouping by type provides a clear representation, making it easier to interpret the associations.

The displayed tags and labels are directly derived from Project Tag Association spec like the following:

apiVersion: tags.k8smgmt.io/v3
kind: ProjectTagsAssociation
metadata:
  name: "demo-association"
  project: "defaultproject"
spec:
  associations:
    - tagKey: "demo-key-ns"
      tagType: "namespacelabel"
      tagValue: "demo-value-ns"
      resource: "demo-namespace"

This configuration reflects the defined associations, offering users an accurate and structured representation of their project metadata. For longer lists of tags and labels, users can expand sections using the "View More" links to explore all key-value pairs under a specific type.

View More

Clicking on the View More link from the Tags/Labels page opens this detailed view, providing a complete list of all tags and labels for the selected type (cost, namespacelabel, or k8s), which are the allowed categories. The page displays the tags and labels in a tabular format, including columns for Type, Key, Value, and the associated Resource. This layout allows users to thoroughly review the metadata associated with the project in an organized manner.

At the top of the page, tabs allow users to switch between different tag types, ensuring that the data is filtered to match the selected category. For instance, selecting the namespacelabel tab displays all tags and labels categorized under that type. The table supports pagination, making it easy to navigate through larger datasets when the number of tags exceeds the visible rows on a single page.

Audit Logs

At the bottom, the Audits section provides additional context by pointing users to the Audit Logs page, where they can review audit events related to namespace label assignments.

Clicking on Go to Audit Logs opens this page, showing a history of namespace label changes across clusters. The logs include details like Date, User, Project, Client, Type, and a Message describing each event.

• Client: The source of the action, such as connector-namespace-sync, which manages namespace labels.
• Type: The action performed, such as:
  • namespace.labels.added – A label was added to a namespace
  • namespace.labels.deleted – A label was removed from a namespace
  • namespace.labels.updated – A label was modified within a namespace
• Message: A detailed event description, including the cluster, namespace, and affected labels.

This page improves visibility and tracking of namespace label changes.

• Click Save once the required namespaces are added for exclusion

Important

• File formats other than .txt will be dismissed
• In a project, if two namespaces with the same name are found in the exclusion list, only one will be considered, and the duplicate will be ignored
• If a namespace is already synchronized from the cluster and was not previously added to the exclusion list, this namespace will have no effect. However, if the namespace is recreated, it will be exempted from synchronization

Any changes made to the namespace exclusion list, including additions, removals, or modifications, are tracked in the Audit Log, documenting details such as the time of the change, user responsible for the action, etc.

---