Skip to main content
Version: 1.15

Security Templates

Security Templates can either be Helm charts or plain Kubernetes manifests which are instantiated in spaces automatically as part of the space creation settings of an account.

Security Templates​

Create Security Templates​

Loft provides 2 default templates which will be added to each connected cluster:

  • loft-limit-range for an example of a LimitRange
  • loft-network-policy for an example of a NetworkPolicy

You can edit these templates if you want to or you can create your own templates as shown below.

Loft UI - Create Template

Enforce Security Templates​

One of the most popular use cases for templates is to ensure cluster security and enforce isolation among users and spaces. However, creating a Template per se does nothing at all if you do not enforce the template.

You can enforce that certain templates are always applied to namespaces when they are being created by adding these templates as part of the "Space Creation Settings" of an account. See the examples below for instructions.

Loft UI - Enforce Template
Only During Space Creation

Enforced templates are part of the "Space Creation Settings" which means that they are only looked at during the creation of new spaces. Changing the enforced templates will not be reflected in existing space nor will template instances be removed when a template is removed from the list of enforced templates.

Delete Security Templates​

Loft UI - Delete Template
Template Instances

Deleting a template will not automatically delete the template instances nor will it automatically delete the Kubernetes objects or Helm charts created by the template instance. To delete the Kubernetes objects or Helm charts created by the template, remove the manifests and Helm chart definition from the template and wait until the controller has synchonized the changes to the template instances.

Enforced Templates

Deleting a template will not automatically delete the template from the list of enforced templates in any cluster account.

Security Template Instances​

After enforcing a template for a certain account, Loft will instantiate the template in every new space that is being created with this account. These instances of a template can be tracked with the Loft CRD TemplateInstance.

To list all TemplateInstances in a certain namespace, run the following command:

kubectl get templateinstance -n [NAMESPACE]
Template Sync

Template instances keep track of the Helm charts and manifests they are creating. When the underlying template changes, the instance will automatically update the Helm chart or the modified manifests to keep everything in sync with the template.

Instantiate Security Templates​

Of course, you can also manually instantiate a template by creating a TemplateInstance using kubectl. By default, users will not be permitted to create/update/delete TemplateInstances but you can change this using standard Kubernetes RBAC.

Create file template-instance.yaml:

apiVersion: config.kiosk.sh/v1alpha1
kind: TemplateInstance
metadata:
  name: network-isolation-instance
  namespace: some-namespace
spec:
  sync: true
  template: network-isolation

Create TemplateInstance using kubectl:

kubectl apply -f template-instance.yaml

Delete Instances​

Deleting template instances is only possible via kubectl:

# IMPORTANT: Make sure to switch to the context of the connected cluster!
kubectl delete templateinstance -n [NAMESPACE] [TEMPLATE_INSTANCE_NAME]

Security Template Parameters​

Template parameters are a way to allow template instances to change certain parts of a template. Currently, they can only be configured in the Loft UI via the Show Yaml button or via kubectl directly. Furthermore, there are several predefined parameters that can be used within a template, to change the deployed resources based on which namespace they got deployed in.

Parameters can be defined in the parameters section of a template:

apiVersion: config.kiosk.sh/v1alpha1
kind: Template
metadata:
  name: space-restrictions
# This section defines parameters that can be used for this template
# Can be used in resources.manifests and resources.helm.values
parameters:
  # Name of the parameter
  - name: DEFAULT_CPU_LIMIT
    # The default value of the parameter
    value: "1"
  - name: DEFAULT_CPU_REQUESTS
    value: "0.5"
    # If a parameter is required the template instance will need to set it
    # required: true
    # Make sure only values are entered for this parameter
    validation: "^[0-9]*\\.?[0-9]+$"
resources:
  manifests:
    - apiVersion: v1
      kind: LimitRange
      metadata:
        name: space-limit-range
        annotations: 
          # Parameters can also be used inside a string
          # with ${namespace.metadata.annotations.myAnnotation}
          example-parameter: "Hello from ${namespace} - ${WILL_NOT_BE_REPLACED}"
      spec:
        limits:
          - default:
              # Use the DEFAULT_CPU_LIMIT parameter here and
              # parse it as json, which renders the "1" as 1. 
              cpu: "${{DEFAULT_CPU_LIMIT}}"
            defaultRequest:
              cpu: "${{DEFAULT_CPU_REQUESTS}}"
            type: Container

The available predefined parameters that can be used without specifying them in the parameters section are:

  • ${namespace}: Kubernetes name of the namespace / space the template got deployed in
  • ${account}: Kubernetes name of the account that owns the namespace where the template got deployed in. Fails if the namespace is not owned by an account
  • ${namespace.metadata.annotations.MYANNOTATION}: Value of the annotation on a namespace. If the annotation does not exist, instantiation of the template will fail.
  • ${namespace.metadata.labels.MYLABEL}: Value of the label on a namespace. If the label does not exist, instantiation of the template will fail.
  • ${account.metadata.annotations.MYANNOTATION}: Value of the annotation on the account that owns the namespace. If the annotation does not exist, instantiation of the template will fail.
  • ${account.metadata.labels.MYLABEL}: Value of the label on the account that owns the namespace. If the label does not exist, instantiation of the template will fail.

Sync Security Template <> Instance​

Template instances keep track of the Helm charts and manifests they are creating. When the underlying template changes, the instance will automatically update the Helm chart or the modified manifests to keep everything in sync with the template.