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.