$ account bitnami
Bitnami Sealed Secrets is a Kubernetes controller and CLI tool that enables secure storage of encrypted Kubernetes Secrets in version control. The system consists of a cluster-side operator and a client-side CLI (`kubeseal`). The controller watches for custom `SealedSecret` custom resource definitions (CRDs) and decrypts them into regular Kubernetes `Secret` objects using asymmetric encryption (RSA-OAEP for key encapsulation and AES-256-GCM for data encryption). The CLI allows users to encrypt secrets using the controller's public certificate, validate sealed secrets, and re-encrypt them under different keys. The controller is deployed via a Helm chart or raw manifests, exposes Prometheus metrics, and provides HTTP endpoints for certificate retrieval, verification, and key rotation. The codebase is mature, well-tested with both unit and integration tests, and follows standard Kubernetes operator patterns (informers, work queues, status updates). It has a low technical drift, with recent dependency updates and active maintenance.
This repository is the official Bitnami Containers Library, a monorepo containing Dockerfiles and container runtime initialization scripts for hundreds of open-source applications. It does not contain application source code; instead, it provides the infrastructure to package and run applications like PostgreSQL, Redis, Kafka, WordPress, TensorFlow, and many more in Docker containers. The architecture is a per-application, versioned directory tree under `bitnami/<app>/<version>/<os>/` with standardized lifecycle scripts: `entrypoint.sh`, `setup.sh`, `run.sh`, `postunpack.sh`, and environment configuration files (`*-env.sh`). A set of shared shell libraries (e.g., `liblog.sh`, `libfile.sh`, `libnet.sh`, `libpersistence.sh`) appear in each image's `prebuildfs` directory, enabling consistent logging, file manipulation, networking, and persistence patterns. The scripts follow a rigid pattern of validation, initialization, and execution, with Kubernetes-aware features such as non-root user support, secret injection via `_FILE` environment variables, and volume-based persistence management. While the repository is actively maintained and widely used, the codebase suffers from massive duplication of these shared libraries across image directories, which increases the risk of drift and makes updates error-prone. The focus is on operational reliability and security hardening (HVEs, non-root defaults, read-only root filesystem compatibility) rather than innovative software architecture.