Understanding Templates in Stakater's Multi Tenancy Operator

March 12, 2024
Vivien Wang Bharath Nallapeta, Muneeb Aijaz & Tanveer Alam
Related topics:
KubernetesOperators
Related products:
Red Hat OpenShift

As a Technology Partner within the Red Hat OpenShift ecosystem, Stakater's Multi Tenant Operator has been officially certified by Red Hat since March 2022, with the latest release certified in November 2023. With Red Hat OpenShift Certified Operators, customers can benefit from validated, verified, mature and supported Operators from Red Hat and partner ISVs in their hybrid cloud environments.

Learn more about Red Hat OpenShift Operator certification here. To learn more about becoming a Red Hat Partner see this link.

This is the third part in a series featuring the exploration of Multi Tenant Operator (MTO) by Stakater, an operator designed to streamline and secure multi-tenancy in OpenShift and Kubernetes environments. In our two previous blogs (1) (2), we described MTO fundamentals. In this blog, we focus on Templates, TemplateInstance (TI), and TemplateGroupInstance (TGI). Templates serve as a standardized playbook, ensuring consistent deployment and management of resources across multiple tenants. We clarify how these features contribute to operational efficiency and security, providing a comprehensive overview of their use and benefits in multi-tenant architectures.

Templates

Templates in the MTO act like a club's standard playbook or strategy guide in soccer. They provide a predefined set of resources or configurations that are consistently deployed across multiple namespaces or Tenants. This feature is crucial for ensuring conformity, efficiency, and simplifying the management of common resources like Network Policies, Helm charts, or secret mappings.

Custom resource (YAML)

A Template in MTO is defined as a Kubernetes Custom Resource (CR). The types of Templates available are as follows.

Helm chart Template: These Templates define Helm charts for deploying applications or services. Example:

apiVersion: tenantoperator.stakater.com/v1alpha1
kind: Template
metadata:
  name: redis
resources:
  helm:
    releaseName: redis
    chart:
      repository:
        name: redis
        repoUrl: https://charts.bitnami.com/bitnami
    values: |
      redisPort: 6379

Manifest Template: These Templates contain Kubernetes manifests for resources like Network Policies, acting like guidelines for specific team strategies. Example:

apiVersion: tenantoperator.stakater.com/v1alpha1
kind: Template
metadata:
  name: networkpolicy
parameters:
 - name: CIDR_IP
   value: 172.17.0.0/16
resources:
 manifests:
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: deny-cross-ns-traffic
     spec:
       egress:
         - ports:
             - port: 5978
               protocol: TCP
           to:
             - ipBlock:
                 cidr: 10.0.0.0/24
       ingress:
         - from:
             - ipBlock:
                 cidr: '${{CIDR_IP}}'
                 except:
                   - 172.17.1.0/24
             - namespaceSelector:
                 matchLabels:
                   project: myproject
             - podSelector:
                 matchLabels:
                   role: frontend
           ports:
             - port: 6379
               protocol: TCP
       podSelector:
         matchLabels:
           role: db
       policyTypes:
         - Ingress
         - Egress

Resource mapping Template: Used for mapping Secrets and ConfigMaps across namespaces, akin to sharing tactics or training methods across different club teams. Example:

apiVersion: tenantoperator.stakater.com/v1alpha1
kind: Template
metadata:
 name: resource-mapping
resources:
 resourceMappings:
   secrets:
   - name: secret-s1
     namespace: namespace-n1
   configMaps:
     - name: configmap-c1
       namespace: namespace-n2

For more information on Templates, refer to the official MTO docs.

Templates and their relation to TemplateInstances

While we've explored how Templates can be directly integrated into Tenants, it is also worth understanding their relationship with TemplateInstances (TI). Templates are the blueprints–the predefined sets of resources or configurations. TemplateInstances are the mechanisms that deploy these blueprints into specific namespaces.

Key points

  • Flexibility in Application: TemplateInstances provide flexibility, allowing for the selective application of Templates. This means that certain Templates can be applied only to specific namespaces as required, rather than across all namespaces of a Tenant.
  • Dynamic Parameter Substitution: TemplateInstances can override or provide values for parameters defined in a Template. This feature is particularly useful when the same Template needs to be applied differently depending on the context.
  • Streamlined Management: By using TemplateInstances, cluster administrators can manage how and where Templates are applied more granularly. This ensures each namespace gets only what it needs, enhancing efficiency and reducing resource clutter.

Templates, along with TemplateInstances, offer a powerful way to standardize and manage resources across multiple namespaces in a Kubernetes environment. They provide a balance between uniformity and customization, ensuring that each part of the cluster operates both independently and cohesively within the larger organizational structure. For more information on TI, refer to the official MTO docs.

TemplateGroupInstances

TemplateGroupInstances (TGIs) in Multi Tenant Operator act as a mechanism to apply a specific set of configurations, defined in a Template, much like TemplateInstances but across multiple namespaces. This is analogous to a sports league uniformly implementing certain rules or training protocols across various teams.

Custom Resource (YAML)

TGIs are defined as cluster-scoped resources. Here is an example of a TGI to deploy a security-policy Template to all namespaces labeled with security-level: high:

apiVersion: tenantoperator.stakater.com/v1alpha1
kind: TemplateGroupInstance
metadata:
 name: security-policy-tgi
spec:
 template: security-policy
 sync: true
 selector:
   matchLabels:
     security-level: high

Field explanation:

  • selector: The selector in a TGI identifies the namespaces where the Template will be applied. In this example, any namespace with the label security-level: high will receive the configurations from the security-policy Template.
  • sync: When true, this feature keeps the resources in the selected namespaces in synchronization with the Template. If changes are unintentionally made locally within a namespace, the TGI will revert them back to match the Template's specifications.

Example use

Let's take a scenario where Susan, a cluster admin, wants to enforce a standardized logging policy across several critical namespaces in the organization. She decides to use a TGI for this purpose.

1. Template creation (logging-policy):

Susan creates a Template named logging-policy that defines the configurations for a logging tool to be used across critical namespaces:

apiVersion: tenantoperator.stakater.com/v1alpha1
kind: Template
metadata:
  name: logging-policy
resources:
  manifests:
    # <Logging tool configuration added>

2. TemplateGroupInstance for logging-policy:

She then creates a TGI named logging-policy-tgi to apply the logging-policy Template to all namespaces meant for critical operations, identified via the operation: critical label:

apiVersion: tenantoperator.stakater.com/v1alpha1
kind: TemplateGroupInstance
metadata:
  name: logging-policy-tgi
spec:
  template: logging-policy
  selector:
    matchLabels:
      operation: critical
  sync: true

3. Here is then a Tenant YAML configuration that uses the logging-policy-tgi TemplateGroupInstance:

apiVersion: tenantoperator.stakater.com/v1beta2
kind: Tenant
metadata:
  name: critical-operations-tenant
spec:
  owners:
    users:
      - susan@techcompany.com
  quota: medium
  namespaces:
    withTenantPrefix:
      - critical-app1
      - critical-app2
      - critical-app3
  commonMetadata:
    labels:
      operation: critical

Field explanation:

  • Tenant Definition: The Tenant named critical-operations-tenant is set up specifically for critical operations within Susan's organization.
  • Namespace Creation: Under this Tenant, the namespaces critical-app1, critical-app2, and critical-app3 are created. These are intended for critical applications or operations.
  • Common Metadata: The commonMetadata field assigns the label operation: critical to all namespaces in this Tenant. This label aligns with the selector criteria defined in the logging-policy-tgi TemplateGroupInstance.
  • Integration with TemplateGroupInstance: The logging-policy-tgi TemplateGroupInstance is designed to target namespaces with the label operation: critical. As a result of using the matching labels, the logging policy defined in the Template is automatically applied to all namespaces created under the critical-operations-tenant, ensuring a consistent logging approach across these critical applications.

In a diverse OpenShift environment, TGIs offer an efficient way to manage and enforce consistent standards, especially in large organizations with numerous namespaces. Whether it's applying security measures, operational policies, or shared configurations, TGIs simplify the process, ensuring that all relevant parts of the organization adhere to the same standards and practices. For more information on TGI, refer to the official MTO docs.

Conclusion

Features like Templates, TemplateInstances (TI), and TemplateGroupInstances (TGI) are key to efficiently manage multi-tenancy in OpenShift. These elements simplify the deployment and management of resources across tenants, and bolster security and operational efficiency. MTO stands as an indispensable tool for orchestrating complex environments, showcasing its vital role in the modern Kubernetes landscape in the field of multi-tenancy.

Further reading

Last updated: March 26, 2024