kubeplus VS sealed-secrets

We went through this migration/upgrade in our KubePlus project (https://github.com/cloud-ark/kubeplus). It has an embedded webhook in it, fyi.

You might want to check out - KubePlus (https://github.com/cloud-ark/kubeplus), which has already been referenced in the thread and is exactly designed for building managed application services. I am the originator and core contributor to this project. KubePlus is a Kubernetes Operator that takes an application Helm chart and represents it as a Kubernetes API (CRD) on the cluster. This API allows you to create instances of the application in separate namespaces automatically ensuring a secure perimeter around each instance using NetworkPolicy, Resource Quota, and RBAC. These soft multi-tenancy measures are already mentioned in the thread along with the namespace. KubePlus has automated all of them for you under an API. This API not only allows the creation of the application instances but also supports day-2 operations such as monitoring, troubleshooting, and upgrades to simplify the end-to-end functioning of any managed application service. We are currently seeing interest from teams that want to create managed services for different types of containerized applications, including open-source platforms such as WordPress, Moodle, Ozone/OpenMRS, AI/ML workloads, etc. KubePlus has been tested successfully with all (90+) Bitnami Helm charts. For anyone who wants to deliver a managed application with minimal / no Kubernetes access to their customers, KubePlus can help by accelerating the implementation of namespace-based multi-tenancy on Kubernetes. With the ability to set NetworkPolicy and Resource Quota per application instance, the blast radius is restricted, if something goes wrong in an application instance. KubePlus does not need admin permissions on your cluster. This makes it possible to use KubePlus to manage your application instances on your customer's cluster as well.

We have an FAQ about Operators here: https://github.com/cloud-ark/kubeplus/blob/master/Operator-F...

It should be helpful if you are new to the Operator concept.

Operators are generally useful for handling domain-specific actions - for example, performing database backups, installing plugins on Moodle/Wordpress, etc. If you are looking for application deployment then a Helm chart should be sufficient.

If you are currently delivering your SaaS as a separate instance of your application per customer, you might want to check out our open-source project KubePlus - https://github.com/cloud-ark/kubeplus

A more commerical offering is from Cloudark who have designed a specific solution for operating your Helm application as a SaaS offering. I have never used it (ArgoCD being my poison) but you might find it fits your usecase better

As part of your data platform are you planning to create a separate instance of the database for your end customer? If so, you might find our KubePlus Operator helpful. Check it out here: https://github.com/cloud-ark/kubeplus

We have been helping organizations build such multi-instance multi-tenant cloud-native applications. We start with an application Helm chart and create separate release of it per customer/user of that organization. We have an open source Kubernetes Operator that aids in this: https://github.com/cloud-ark/kubeplus

You might also want to checkout Operator guidelines and Operator FAQ: - Operator Maturity Model guidelines: https://github.com/cloud-ark/kubeplus/blob/master/Guidelines.md

The project that is getting some traction recently is our KubePlus Operator that delivers Helm charts as-a-service: https://github.com/cloud-ark/kubeplus

If you have noticed, you are setting secrets in plain text on the application-configmap.yml file, which is not ideal and is not a best practice for security. The best way to do this securely would be to use AWS Secrets Manager, an external service like HashiCorp Vault, or Sealed Secrets. To learn more about these methods see the blog post Shhhh... Kubernetes Secrets Are Not Really Secret!.

Yeah documentation is hard and I'm guilty (as a former maintainer of SealedSecrets)

SealedSecrets was designed with "write only" secrets in mind.

Turns out a lot of people need to access the current secrets because they need to update a part of a "composite" secret.

There are two kinds of "composite" secrets, one easy and one harder, but if you don't know how to do it, even the easier is hard:

1. Secret with multiple data "items" (also called keys in K8s Secret jargon but that's confusing when there is encryption involved). I.e. good old "data":{"foo": "....", "bar": "..."}

2. Secrets where data within one item is actually a config file with cleartext and secrets mixed up in one single string (usually some JSON or YAML or TOML)

Case 1 is "easy" to deal with once you realize that sealed secrets files are just text files and you can just manually merge and update encryoted data items. We even created a "merge" and some "raw" encryption APIs to make that process a little less "copy pasta" but it's still hard to have a good UX that works for everyone.

Case 2 is harder. We did implement a data templating feature that allows you to generate a config file via a go-template that keeps the cleartext parts in clear and uses templating directives to inject the secret parts where you want (referencing the encrypted the items)

The main problem with case 2 is that it's undocumented.

The feature landed in 2021:

https://github.com/bitnami-labs/sealed-secrets/pull/580

I noticed that people at my current $dayjob used sealed secrets for years and it took me a while to understand that the reason they hated it was that they didn't know about that fundamental feature.

And how to blame them!? It's still undocumented!

In my defense I spent so much effort before and after I left VMware to lobby so that the project got the necessary staffing so it wouldn't die of bitrot that I didn't have much time left to work on documentation. Which is a bit said and probably just an excuse :-)

That said, I'm happy that the project is alive and the current maintainers are taking care of it against the forces of entropy. Perhaps some doc work would be useful too. Unfortunately I don't have time for now.

This might be OT, and forgive me, but I think one of the best practices for Encrypting and Managing secrets in Kubernetes is to use Sealed Secrets, they allow your secrets to be securely stored in git with the rest of the configuration and yet no one with access to the Git repository will be able to read them. I say this might be OT, because Sealed Secrets are trying to mitigate a different threat, the threat of the secrets at rest somewhere, and not "live in the cluster", where in theory all the ingredients to decrypt the secrets would still live.

The addition of Consul and Vault gives me a few things. For one, right now I'm handling secrets with a mixture of SOPS and Sealed Secrets. I use Vault in my professional life, and have used both Vault and Consul at my last job. Vault is a beast, so I may as well get better at it; plus its options for secret injection are better.

Use Sealed Secrets Operator.

sealed-secrets (sealed)

An option that easily works with GitOps is the Operator Sealed Secrets from Bitnami. Secrets encrypted with it can only be decrypted by operators running inside the cluster, not even by the original author. For encryption, there is a CLI (and a third-party web UI) that requires a connection to the cluster. The disadvantage of this is that the key material is stored in the cluster, the secrets are bound to the cluster and one has to take care of backups and operation.