Skip to content

SealedSecrets (self-managed)

This page describes how to install a Customer Application

You are solely responsible for Customer Applications.

If you are an Elastisys Managed Services customer, please review your responsibilities in ToS 5.2.

Specifically, you are responsible for performing due diligence for the project discussed in this page. At the very least, you must:

  • assess project ownership, governance and licensing;
  • assess project roadmap and future suitability;
  • assess project compatibility with your use-case;
  • assess business continuity, i.e., what will you do if the project is abandoned;
  • subscribe to security advisories related to the project;
  • apply security patches and updates, as needed;
  • regularly test disaster recovery.

This page is a preview for self-managed cluster-wide resources

Compliant Kubernetes restricts Application Developers to manage CustomResourceDefinitions (CRDs) and other cluster-wide resources for security purposes. This means that some applications that require such cluster-wide resources are not possible to install for you as an Application Developer. As a trade-off, we are launching this preview feature that allows for self-management of specific cluster-wide resources required for certain popular applications. It is disabled by default, so please ask your Platform Administrator to enable this preview feature.

For Elastisys Managed Services Customers

You can ask for this feature to be enabled by filing a service ticket. This is a preview feature. For more information, please read ToS 9.1 Preview Features.

This page will help you to install Sealed Secrets, so that you are allowed to install the cluster-wide resources that are required by Sealed Secrets.

This guide is a complement to Sealed Secrets own documentation.

Preparation

The self-managed cluster-wide resources feature adds specific Roles, ServiceAccounts, etc. for you. This enables you to install and manage the resources that Sealed Secrets needs. These pre-installed resources are propagated via HNC from your root Namespace (recall the documentation of this feature).

First create a new namespace using HNC, using the snippet below. If you do not know which root namespace you should use, ask your Platform Administrator.

apiVersion: hnc.x-k8s.io/v1alpha2
kind: SubnamespaceAnchor
metadata:
  name: sealed-secrets
  namespace: <root namespace>

Install Sealed Secrets

Supported versions

This installation guide has been tested with Sealed Secrets version 0.24.2 and Helm Chart version 2.13.1.

Sealed Secrets have a section in their documentation about installing Sealed Secrets into a restricted environment, where they give a config.yaml that defines what should be installed.

The following config.yaml is an example of what is required to install Sealed Secrets into Compliant Kubernetes.

serviceAccount:
  create: true
  name: sealed-secrets
rbac:
  create: false
  clusterRole: false
## Add your namespace(s) here
additionalNamespaces: []
resources:
  requests:
    cpu: 150m
    memory: 256Mi
  limits:
    cpu: 150m
    memory: 256Mi

Important

Add the namespaces that should support creation of SealedSecrets to the additionalNamespaces list. If this list is empty the SealedSecrets controller will output an error when attempting to create a SealedSecret as it attempts to get Secrets at cluster level.

You are now ready to install Sealed Secrets:

helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm upgrade --install sealed-secrets -n sealed-secrets --version 2.13.1 sealed-secrets/sealed-secrets -f config.yaml

Note about kubeseal

The Sealed Secrets cli tool kubeseal expects the controller to be installed in the namespace kube-system. However the controller is installed in the namespace sealed-secrets. As such you need to follow this guide to use kubeseal

Further Reading

Please refer to the official documentation how to operate and use Sealed Secrets.