HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
bitnami
sealed-secrets
Go2019–2024
bitnami / sealed-secrets

sealed-secrets

A Kubernetes controller and tool for one-way encrypted Secrets

Systems & InfrastructureSecurity & PrivacyDevOps & CloudAutomation & Workflows
Explore on GitHubRead Hacker News discussions
9Distinct people
12Mentions
0Explicit recommenders
9.3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A Kubernetes controller and tool for one-way encrypted Secrets

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2019-12-11 13:27:32 UTC to 2024-04-25 17:00:44 UTC.

012342019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC211
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC312
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

12 sources
ithkuil·Jul 21, 2023
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 ma
Read the rest
nually 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.
In Plain Kubernetes Secrets are fine
morelisp·Mar 4, 2022
No, storing encrypted secrets in repositories is an incredibly common and safe practice in DevOps/GitOps environments. Virtually every orchestration tool has some way to support it. E.g. k8s sealed secrets https://github.com/bitnami-labs/sealed-secrets E.g. Salt's GPG filters https://docs.saltproject.io/en/latest/ref/renderers/all/salt... E.g. Ansible Vault https://docs.ansible.com/ansible/latest/user_guide/vault.htm... E.g. Puppet hiera-yaml https://puppet.com/docs/puppet/6/securing-sensitive-data.htm... PD/PII is a completely separate issue. First because even encrypting doesn't remove legal obligations concerning processing, and second because your DS/BI teams probably need access to the unencrypted data to like, do their actual jobs. You need completely orthogonal forms of access control for that (like SSO as you alude to).
In A GitHub repository was public-viewable
freedomben·Oct 14, 2020
Disclaimer: I work for Red Hat as an OpenShift consultant so I'm biased There are competing pieces of advice for secure distribution of secrets, but my current preference comes down to one of these ways, depending on the organization: 1. OpenShift/Kubernetes Secrets mounted into the Pod at runtime. 2. Hashicorp Vault (has a really well designed API. It's very usable just with curl, which makes using it a joy) 3. Sealed Secrets (less experience here but it's looking positive right now) - https://github.com/bitnami-labs/sealed-secrets If you're using a different PaaS besides OpenShift, it may also offer options worth considering (although do think about portability. These days apps move platforms every few years on average, though I think that may be changing now that K8s is becoming the standard).
In Dockerfile Security Best Practices
jrockway·Dec 11, 2019
> Perfectly joined the dots between a complicated but secure thing (you had to store sensitive state in S3 with server-side-encryption, which made it way too complicated to have sensitive data in a small side project) and the throwaway easy but very insecure thing (store the state locally/in a private git repo). I use git-crypt for storing secrets in git repositories. In the future, I'll probably switch to this, though: https://github.com/bitnami-labs/sealed-secrets
In Keybase cancels Stellar token airdrop

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.