What is Sealed Secrets? Securing K8s Secrets in Git

GitOps relies on a single, declarative source of truth for infrastructure state, but secrets historically undermine that model. Native Kubernetes Secrets are base64-encoded rather than encrypted, which makes committing them to Git a direct security risk. Teams are left with an uncomfortable trade-off: bypass GitOps for secrets or accept the exposure of sensitive credentials.

Sealed Secrets resolves this tension by extending GitOps with first-class secret encryption. It uses asymmetric cryptography to encrypt secrets before they ever reach your repository. The encrypted artifacts can be safely stored and versioned in Git, while decryption occurs only inside the cluster using a private key that never leaves it. The result is a workflow that preserves GitOps guarantees without weakening your security posture.

Key Takeaways

• Encrypt Secrets Before Storing Them in Git: Standard Kubernetes Secrets are merely base64-encoded, not truly encrypted, making them insecure for version control. Sealed Secrets uses public-key cryptography to create a SealedSecret resource that is safe to commit, allowing you to manage secrets declaratively within a GitOps workflow.
• Prioritize Your Controller's Private Key Management: The private key held by the in-cluster controller is the single point of failure for decryption. If this key is lost, all your sealed secrets become permanently inaccessible. Implement a strict backup and recovery plan for this key from day one to avoid catastrophic data loss.
• Integrate Sealing into Your Automated Workflows: To use Sealed Secrets at scale, embed the kubeseal encryption step directly into your CI/CD pipeline. Combine this automation with strong RBAC policies and regular secret rotation. Platforms like Plural can manage the controller deployment and integrate sealed secrets into a cohesive, multi-cluster GitOps process.

What Are Sealed Secrets?

Sealed Secrets is a Kubernetes controller and CLI designed to close a long-standing security gap in GitOps workflows: managing secrets without breaking declarative infrastructure practices. Originally developed by Bitnami, it enables teams to encrypt secrets before they enter version control, allowing sensitive configuration to live safely alongside standard Kubernetes manifests.

At a high level, Sealed Secrets lets you keep Git as the single source of truth without leaking credentials. Secrets are encrypted locally using strong asymmetric cryptography and can only be decrypted by the target cluster. Git stores encrypted intent, not usable credentials.

How Sealed Secrets Works

The workflow builds directly on native Kubernetes primitives and remains fully declarative.

You start with a standard Secret manifest. Instead of applying it directly to the cluster, you pass it through the kubeseal CLI, which encrypts the secret data using the public key exposed by the Sealed Secrets controller running in your cluster. The output is a SealedSecret custom resource.

This SealedSecret is safe to commit to Git—public or private—because it cannot be decrypted without the controller’s private key. That private key never leaves the cluster. When the GitOps reconciler applies the SealedSecret, the controller decrypts it in-cluster and materializes a regular Kubernetes Secret. From the application’s perspective, nothing changes; it consumes a normal Secret object.

The Problem with Secrets in Git

GitOps assumes Git is the authoritative record of desired state. This works cleanly for Deployments, Services, and Ingress resources, but breaks down for secrets.

Kubernetes Secret objects are only base64-encoded. Base64 is a reversible encoding, not encryption. Anyone with read access to the repository can trivially decode API keys, database passwords, or certificates. In practice, this forces teams to choose between two bad options: weaken security by committing secrets, or weaken GitOps by managing secrets out of band.

Both approaches introduce risk—either security exposure or operational drift.

How Sealed Secrets Fix the GitOps Trade-off

Sealed Secrets removes this trade-off by ensuring secrets are encrypted before they reach Git. Only ciphertext is stored in the repository, and only the intended cluster can decrypt it.

The split of responsibilities is deliberate:

• kubeseal handles encryption using the controller’s public key.
• The in-cluster controller holds the private key and performs decryption.
• Git stores encrypted, declarative state.
• Applications continue to read standard Kubernetes Secret objects.

This preserves GitOps invariants—single source of truth, declarative configuration, auditability—while enforcing a strong security boundary around sensitive data. For teams operating Kubernetes at scale, it provides a pragmatic balance between security, simplicity, and operational correctness.

How Do Sealed Secrets Work?

Sealed Secrets uses a deliberately simple cryptographic model that fits cleanly into GitOps workflows. It splits responsibility between a client-side encryption tool and an in-cluster controller, ensuring secrets are encrypted before they ever touch Git and decrypted only inside the cluster. At no point does the private decryption key leave Kubernetes.

This design allows teams to manage secrets declaratively, alongside the rest of their infrastructure, without weakening either their security model or their GitOps guarantees.

End-to-End Workflow

The workflow starts with a standard Kubernetes Secret manifest authored locally. This file should be treated as transient and never committed to version control.

Instead of applying it directly, the developer runs the kubeseal CLI. The tool retrieves a public encryption key from the Sealed Secrets controller running in the target cluster and uses that key to encrypt the secret’s data fields. The output is a SealedSecret custom resource.

This encrypted manifest is safe to commit to Git. When your GitOps reconciler applies it to the cluster, the controller detects the SealedSecret, decrypts it using its private key, and materializes a standard Kubernetes Secret. Applications consume the resulting secret exactly as they would any other native Secret object.

Encryption and Decryption Flow

From a mechanics perspective, the encryption step is entirely client-side. kubeseal reads the raw Secret definition and encrypts only the sensitive data fields, leaving metadata such as name and namespace intact. The encrypted payload is bound to those fields, preventing reuse in unintended contexts.

The decrypted form of the secret never exists outside the cluster. Once applied, only the controller—holding the private key—can convert the SealedSecret back into a conventional Secret. This ensures that Git, CI systems, and developer machines never store decryptable credentials.

The Sealed Secrets Controller

The controller is deployed into the cluster along with the SealedSecret Custom Resource Definition. On startup, it generates a public–private key pair. The private key is stored as a Kubernetes Secret and protected by cluster RBAC; it is never exposed externally.

The controller continuously watches for SealedSecret resources. When it sees a new or updated one, it decrypts the payload and creates or updates the corresponding Kubernetes Secret. The plain-text secret only exists inside the cluster’s control plane and etcd, inheriting Kubernetes’ native access controls and audit mechanisms.

Public-Key Cryptography Model

Sealed Secrets relies on asymmetric cryptography. The controller owns the private key and exposes only the public key. Developers and CI pipelines can fetch this public key—commonly via kubeseal --fetch-cert—and use it to encrypt secrets.

Because the public key cannot decrypt data, it is safe to distribute. The resulting ciphertext can only be decrypted by the controller’s private key. This one-way property is central to the security model: even full read access to the Git repository is insufficient to recover secrets without also compromising the cluster.

In practical terms, this guarantees that encrypted secrets remain secure at rest in Git and in transit through CI/CD systems, while still being fully compatible with declarative GitOps workflows.

Sealed Secrets vs. Standard Kubernetes Secrets

While both standard Kubernetes Secret objects and Sealed Secrets are used to manage sensitive data such as API keys, credentials, and certificates, they differ fundamentally in how they handle security and GitOps compatibility. Standard Secrets were not designed for version control. Sealed Secrets were explicitly built to make secrets safe, auditable, and declarative in a GitOps-driven environment.

Encryption vs. Base64 Encoding

The most important technical distinction is how data is protected.

Standard Kubernetes Secrets are base64-encoded, not encrypted. Base64 is a reversible encoding format intended for data transport, not security. Anyone with access to the manifest—or a Git repository containing it—can trivially decode the values and recover the original secret material.

Sealed Secrets use asymmetric (public-key) cryptography. Secrets are encrypted locally using a public key before they are committed to Git. Only the controller running inside the target cluster holds the corresponding private key, making it the sole component capable of decryption. This ensures that secrets stored in Git are cryptographically protected rather than merely obfuscated.

Version Control and Auditability

Because standard Secrets are unsafe to store in Git, teams frequently manage them outside their GitOps pipelines—via manual kubectl apply steps, external secret injection, or ad hoc scripts. This breaks the single–source-of-truth model and introduces configuration drift.

Sealed Secrets restore consistency by allowing secrets to live in Git alongside Deployments, Services, and other manifests. Encrypted secrets can be reviewed, versioned, and audited using standard Git workflows. Changes to secret configuration become visible, traceable, and reversible, which is critical for compliance, incident response, and operational hygiene.

GitOps Workflow Integration

Sealed Secrets align naturally with GitOps automation. A typical workflow looks like this:

• A developer authors a standard Secret manifest.
• The secret is encrypted using the kubeseal CLI.
• The resulting SealedSecret is committed to Git.
• A GitOps controller—such as the one integrated into Plural—detects the change and applies it to the cluster.
• The in-cluster controller decrypts the SealedSecret and creates a native Kubernetes Secret.

Applications consume the resulting Secret without modification and without awareness of the encryption process. Plain-text secrets exist only inside the cluster, never in Git, CI logs, or developer machines. This preserves GitOps guarantees while enforcing a strong security boundary.

In practice, the difference is not just stronger encryption—it is the ability to treat secrets as code without compromising security.

How to Set Up Sealed Secrets

Setting up Sealed Secrets follows a simple, three-step process: deploy the in-cluster controller, install the kubeseal CLI, and verify connectivity between the two. Once complete, you have the foundation for managing secrets declaratively in Git without exposing credentials.

For organizations operating multiple clusters, consistency matters. Platforms like Plural allow you to define the Sealed Secrets controller as a global service, ensuring it is deployed and maintained uniformly across your fleet. This eliminates per-cluster drift and reduces operational overhead when scaling GitOps practices.

Install the Sealed Secrets Controller

The controller is the core runtime component. It runs inside your Kubernetes cluster, generates a public–private key pair, and handles decryption of sealed secrets at reconciliation time. The private key is stored as a Kubernetes Secret and never leaves the cluster.

Installation is typically done by applying the official manifest with kubectl. This deploys the controller (by default in the kube-system namespace) and registers the SealedSecret Custom Resource Definition. Once running, the controller begins watching for SealedSecret resources across namespaces and is ready to decrypt them as they appear.

Set Up the kubeseal CLI

With the controller running, the next step is installing the kubeseal command-line tool on your local machine or in CI. This tool is responsible for encrypting standard Kubernetes Secret manifests before they are committed to Git.

Installation is platform-specific but trivial. On macOS, kubeseal can be installed via Homebrew. On Linux and Windows, you download a prebuilt binary from the official release artifacts. All encryption happens client-side; kubeseal fetches the controller’s public key and never handles the private key.

This CLI becomes part of your normal workflow whenever secrets are created or rotated.

Verify the Installation

Before sealing secrets, verify that the CLI can communicate with the controller. The simplest check is fetching the public encryption certificate:

kubeseal --fetch-cert

If this command returns a certificate, the CLI can successfully reach the controller and retrieve its public key.

You should also confirm that the controller pod is healthy:

kubectl get pods -n kube-system -l app.kubernetes.io/name=sealed-secrets

A running pod and a retrievable public key indicate the setup is complete. At this point, you can begin sealing secrets and committing SealedSecret manifests to Git, confident that plaintext credentials will only ever exist inside the cluster.

How to Create and Deploy Sealed Secrets

Once the Sealed Secrets controller and the kubeseal CLI are installed, you can begin managing secrets end to end using a GitOps-friendly workflow. The process has two phases: encrypting standard Kubernetes secrets into SealedSecret resources and applying them to your cluster, where decryption happens automatically. This ensures sensitive data is never committed to Git in plaintext and only exists unencrypted inside the cluster.

Create Your First Sealed Secret

The workflow starts with a standard Kubernetes Secret manifest created locally. This file contains the sensitive values you want to protect and should be treated as transient—never committed to version control.

Using the kubeseal CLI, you encrypt this manifest with the public key exposed by the in-cluster controller. For example:

kubeseal -f secret.yaml -w sealedsecret.yaml

This command transforms the original Secret into a SealedSecret custom resource. The resulting sealedsecret.yaml contains only encrypted data and metadata such as name and namespace. Because the payload is encrypted with asymmetric cryptography, this file is safe to commit to Git and share within your GitOps pipeline.

Deploy Sealed Secrets to Your Cluster

After committing the SealedSecret manifest, deployment works like any other Kubernetes resource:

kubectl apply -f sealedsecret.yaml

When the manifest is applied, the Sealed Secrets controller detects the new resource, decrypts it using its private key, and creates a standard Kubernetes Secret in the same namespace. Tools like FluxCD or Argo CD simply reconcile the manifest; no special handling is required.

The key property here is that the unencrypted secret only ever exists inside the cluster’s control plane and etcd, protected by Kubernetes RBAC and audit mechanisms. Plain-text values never appear in Git, CI logs, or developer machines.

Manage Secrets Across Multiple Environments

In multi-environment setups, preventing accidental cross-environment secret usage is critical. Sealed Secrets enforces this through scoping rules.

By default, secrets use a strict scope: a SealedSecret can only be decrypted into a Secret with the same name and namespace it was created for. This makes it impossible to reuse a production secret in staging or development by mistake.

Broader scopes—namespace-wide or cluster-wide—are available for advanced scenarios, but strict scoping is the safest default. For organizations running many clusters, Plural can distribute consistent RBAC and controller configurations as Global Services, ensuring sealed secrets behave predictably and securely across the entire fleet.

Together, these patterns allow teams to treat secrets as code without sacrificing isolation, auditability, or security.

Key Security Considerations for Sealed Secrets

Sealed Secrets materially improves the security of a GitOps workflow, but it does not eliminate the need for careful operational discipline. Its guarantees depend on how well you manage encryption keys, enforce access controls, and isolate environments. Treating Sealed Secrets as a drop-in fix without addressing these concerns can weaken its security model and introduce avoidable failure modes.

Key Management and Backup Strategy

The controller’s private key is the root of trust for your entire Sealed Secrets setup. If that key is lost, every SealedSecret encrypted with it becomes permanently unrecoverable. If it is compromised, every encrypted secret in Git can be decrypted.

Backing up the private key is therefore mandatory. The backup should be taken immediately after controller installation and stored in a hardened system such as HashiCorp Vault or a cloud-native KMS. Access to this backup should be extremely limited and audited. From an operational standpoint, you should treat the sealing key with the same sensitivity as a root certificate authority.

Key rotation should also be planned in advance. While Sealed Secrets supports key rotation, it requires coordination to re-seal existing secrets and ensure uninterrupted cluster operation.

Access Control with Kubernetes RBAC

By default, any principal with permission to create resources in a namespace can create SealedSecret objects. That is often broader access than you want.

Best practice is to restrict creation and modification of SealedSecret resources to a small, well-defined set of users or service accounts—typically CI/CD automation and a limited group of platform engineers. This reduces the risk of unauthorized or incorrect secrets entering your Git repository and being reconciled into production.

In multi-cluster environments, Plural can enforce consistent RBAC policies via Global Services, ensuring that access controls for sealed secrets are identical across all clusters rather than drifting over time.

Auditing and Monitoring

Visibility into secret changes is essential for both security and reliability. At a minimum, you should verify that SealedSecret resources are successfully decrypted by inspecting controller events and resource status. For example, describing a SealedSecret will surface decryption failures or reconciliation errors.

For stronger guarantees, enable Kubernetes audit logging and capture API activity related to SealedSecret and Secret resources. Forwarding these logs into a centralized logging or SIEM system allows you to detect anomalous behavior, such as frequent secret rotation, unexpected deletions, or modifications outside approved workflows.

Git history provides part of the audit trail, but cluster-level auditing completes the picture.

Environment Isolation and Scoping

Secrets for one environment should never be usable in another. Sealed Secrets enforces this by default through strict scoping: a SealedSecret can only be decrypted into a Secret with the same name and namespace it was sealed for.

For stronger isolation, each environment or cluster should use a distinct sealing key. This creates cryptographic separation between development, staging, and production. Even if a lower-trust environment is compromised, the attacker cannot decrypt secrets sealed for higher-trust clusters.

This approach significantly reduces blast radius and aligns well with GitOps patterns where the same repository structure is reused across environments but reconciled into separate clusters.

Taken together, these practices ensure Sealed Secrets remains an asset rather than a liability: encryption backed by disciplined key management, strict access control, comprehensive auditing, and strong environment isolation.

Common Challenges with Sealed Secrets

Sealed Secrets solves a real problem in GitOps, but it introduces its own operational constraints. Its security model is sound, yet day-to-day usability depends heavily on how well it is automated, monitored, and embedded into existing workflows. Most challenges surface around encryption workflows, controller dependency, and organizational process rather than cryptography itself.

Automation and Workflow Friction

Although Sealed Secrets is compatible with automation, sealing secrets is not inherently transparent. Every secret change requires a deliberate encryption step using the kubeseal CLI. Developers must have access to the controller’s public key and the correct tooling setup, which can become a bottleneck in larger teams.

Without standardization, teams often rely on a small group of engineers to seal secrets, slowing development and creating informal gatekeepers. While scripts and Makefile targets can reduce friction, they add yet another layer of tooling to maintain. As the number of secrets and environments grows, this manual sealing step can feel cumbersome unless it is fully integrated into CI pipelines.

Dependency on the In-Cluster Controller

Sealed Secrets introduces a hard dependency on the controller running inside the cluster. This controller is responsible for holding the private key and performing all decryption operations. If it is unavailable, misconfigured, or unable to access its key, secrets cannot be materialized into standard Kubernetes Secret objects.

This makes the controller a critical piece of infrastructure that must be monitored, backed up, and treated as highly available. A controller failure may not immediately break running workloads, but it can block deployments, restarts, or scaling events that require secret reconciliation.

Key loss is an even more severe failure mode. Without a backup of the private key, all sealed secrets become unrecoverable. This elevates key backup and recovery from a “nice to have” to an operational requirement.

CI/CD and Process Integration

Sealed Secrets works best when it is a first-class part of your GitOps process rather than an afterthought. Teams need clear rules around who is allowed to create and seal secrets, how reviews are handled, and how accidental plaintext secrets are prevented from entering repositories.

This is as much a process challenge as a technical one. Developers need training, CI systems need guardrails, and repositories often need policy enforcement to block unsealed secrets. Without this, teams risk inconsistent practices or security regressions that undermine the original intent.

Platforms like Plural help reduce this integration burden by providing a unified GitOps framework. By standardizing controller deployment, RBAC, and reconciliation across clusters, Sealed Secrets becomes an opinionated but reliable part of the delivery pipeline rather than a fragile add-on.

Understanding and planning for these challenges upfront ensures Sealed Secrets delivers on its promise: secure, declarative secret management without sacrificing operational velocity.

How to Integrate Sealed Secrets with GitOps

Sealed Secrets is purpose-built for GitOps. It treats secrets as declarative resources that can live in Git alongside the rest of your Kubernetes manifests, enabling versioning, reviews, and a single source of truth without exposing sensitive data. When integrated correctly, secrets stop being a special-case workflow and become part of the same automated delivery pipeline as everything else.

This approach aligns cleanly with Infrastructure as Code and modern CI/CD practices. Encryption happens before secrets reach Git, reconciliation happens automatically in-cluster, and developers no longer need to manage out-of-band secret distribution.

Add Sealed Secrets to Your CI/CD Pipeline

A GitOps-friendly integration starts in CI. Developers author standard Kubernetes Secret manifests locally, but these files are never committed. During CI execution, the pipeline runs the kubeseal CLI to encrypt the secret into a SealedSecret resource.

Only the encrypted manifest is pushed to Git. The raw secret never leaves the developer’s machine or the CI environment in readable form. This pattern fits naturally into common CI systems such as Jenkins, GitLab CI, and GitHub Actions and aligns well with Plural’s GitOps-driven workflows, where encryption and validation steps are standardized across teams.

The result is a repeatable, automated process that removes manual sealing steps from individual developers while maintaining strong security guarantees.

Apply Version Control Best Practices to Secrets

Once encrypted, SealedSecret manifests are safe to store in Git repositories. This allows teams to apply the same version control discipline to secrets as they do to application code and infrastructure.

Pull requests can be used to review changes, Git history becomes an audit trail, and approvals can be enforced before secrets are deployed. While reviewers cannot see plaintext values, they can still reason about metadata changes, scope, and intent. This brings accountability and traceability to secrets management without compromising confidentiality.

At this point, Git truly becomes the authoritative source of desired state for the entire system, including sensitive configuration.

Automate Deployment with a GitOps Controller

The final step is reconciliation. When a SealedSecret is merged into the main branch, a GitOps controller such as Flux, Argo CD, or the Plural deployment agent detects the change and applies it to the cluster.

From there, the Sealed Secrets controller operates entirely in-cluster. It decrypts the SealedSecret using its private key and creates a standard Kubernetes Secret. Applications consume this secret normally, with no awareness of the encryption or GitOps machinery behind it.

This end-to-end automation ensures secrets flow securely from Git to running workloads without manual steps, CI log exposure, or configuration drift—completing the GitOps model in a way that is both operationally clean and security-conscious.

Best Practices for Managing Sealed Secrets

Sealed Secrets is a strong foundation for securing secrets in a GitOps workflow, but encryption alone is not sufficient. Long-term security and reliability depend on disciplined operational practices that cover secret rotation, backup and recovery, and multi-cluster governance. Treating sealed secrets as a lifecycle-managed asset—rather than a one-time setup—helps avoid common failure modes and keeps your Kubernetes environment resilient as it scales.

Rotate and Validate Secrets Regularly

Sealed Secrets protects secrets in Git, not the secrets themselves. Credentials such as API keys, tokens, and database passwords should still be rotated on a regular schedule to limit blast radius in the event of compromise.

Rotation follows a predictable pattern: generate a new credential, create an updated Kubernetes Secret manifest locally, seal it with kubeseal, and commit the new SealedSecret to Git. Your GitOps controller applies the change, and the Sealed Secrets controller updates the in-cluster Secret.

Equally important is validation. Applications must be verified to successfully consume the new secret before the old value is revoked. Rotation without validation risks outages, particularly for stateful or long-lived services.

Back Up and Test Your Sealing Keys

The controller’s private key is the root of trust for all sealed secrets. Losing it means losing the ability to decrypt every SealedSecret encrypted with that key.

Backups of the private key should be taken immediately after installation and stored in a hardened system such as a dedicated secrets manager, HSM, or offline secure storage. Access should be minimal, audited, and tightly controlled.

Backup alone is not enough. You must periodically test restoration by validating that a new or rebuilt cluster can decrypt existing SealedSecret resources using the backed-up key. Disaster recovery plans that are never exercised tend to fail when they are most needed.

Define a Clear Multi-Cluster Strategy

Multi-cluster environments introduce trade-offs between simplicity and isolation. Sharing a single sealing key across all clusters allows a secret to be sealed once and deployed everywhere, but it also increases risk: a compromised key exposes secrets in every cluster.

Using distinct keys per cluster or per environment (development, staging, production) provides cryptographic isolation and sharply reduces blast radius. The downside is increased operational overhead, since secrets must be sealed separately for each target.

For most production environments, per-cluster or per-environment keys are the safer default. Platforms like Plural help manage this complexity by allowing different secret variants and deployments to coexist in a single Git repository, while targeting them to the correct clusters through controlled deployment pipelines.

Treat Secrets as First-Class Infrastructure

Finally, sealed secrets should be governed like any other critical infrastructure component. Changes should go through pull requests, approvals should be explicit, and access to sealing workflows should be restricted. CI checks can be used to block plaintext secrets from entering repositories, and audit logs should be monitored for unexpected changes.

When combined with rotation, tested backups, and strong environment isolation, these practices ensure Sealed Secrets remains an enabler of GitOps—not a hidden operational risk.

Manage Sealed Secrets at Scale with Plural

While Sealed Secrets provides a robust framework for managing secrets in Git, its operational complexity grows with your cluster fleet. Manually managing controllers and keys across dozens of clusters is inefficient and prone to error. Plural is designed to handle these challenges, providing the tools to deploy and manage Sealed Secrets consistently across your entire Kubernetes environment. By integrating Sealed Secrets into Plural’s management layer, you can automate deployments, enforce consistency, and maintain a strong security posture without the manual overhead.

Deploy Secrets Across Clusters Seamlessly

Managing secrets consistently across a fleet is a common challenge. Plural’s Global Services feature simplifies this process by allowing you to define a configuration once and apply it to multiple clusters. You can package the Sealed Secrets controller and any shared secrets as a single Global Service resource. This ensures that every cluster in your fleet—whether for development, staging, or production—has the necessary secrets and controller configuration without manual intervention. This approach guarantees uniformity and significantly reduces the administrative burden of keeping secrets synchronized across different environments.

Integrate with Plural's Native GitOps Workflows

Sealed Secrets are designed to be stored in Git, which aligns perfectly with a GitOps methodology. Plural’s Continuous Deployment engine leverages this by treating your Sealed Secret manifests just like any other application configuration. When you commit a new or updated secret to your repository, Plural’s GitOps pipelines automatically detect the change and manage the deployment process. This includes generating automated pull requests for promotions between environments and using approval gates for additional control. Integrating Sealed Secrets into this workflow gives you full versioning, auditability, and automated rollouts for your sensitive data.

Secure Your Secrets with an Agent-Based Architecture

Security is paramount when managing secrets. The Sealed Secrets controller decrypts data only within the target cluster, ensuring plain-text secrets are never exposed externally. Plural’s agent-based architecture enhances this security model. A lightweight agent on each managed cluster initiates all communication with the central control plane via egress-only connections, keeping your clusters isolated. The agent applies configurations using local credentials, so the management plane never stores or handles the private keys needed for decryption. This layered approach minimizes the attack surface and ensures your secrets remain secure within their intended environment.

Related Articles

• Kubernetes Secrets: A Practical Guide
• Secrets Kubernetes: Master Security & Management

Frequently Asked Questions

What happens if I lose the private key for the Sealed Secrets controller? Losing the private key means you permanently lose the ability to decrypt any secrets that were encrypted with its corresponding public key. To avoid this, you must back up the private key as soon as the controller is installed. This key is the master key for all your secrets, so store the backup in a highly secure location like a dedicated secrets manager or a cloud KMS. Without a backup, you would have to generate a new key and re-encrypt every secret in your repositories.

Can I use the same encrypted secret across different environments, like staging and production? By default, a Sealed Secret is scoped to a specific name and namespace, which prevents you from accidentally deploying a production secret to a staging environment. For multi-cluster setups, you have two main options. You can use a unique sealing key for each cluster, which provides strong cryptographic isolation. Alternatively, you can share a single key across multiple clusters for a simpler workflow, but this requires careful management to ensure the correct secrets are deployed to the correct environments.

Does a developer have to run kubeseal manually every time a secret changes? While developers can run kubeseal on their local machines, the most effective approach is to integrate this step into your CI/CD pipeline. The pipeline can be configured to take a standard Secret manifest as input, execute the kubeseal command to encrypt it, and then commit the resulting SealedSecret to your Git repository. This automates the process, removes the need for developers to manage public keys locally, and ensures consistency.

Is the Sealed Secrets controller a single point of failure? The controller is a critical component; if it goes down, new or updated SealedSecret resources will not be decrypted and applied. However, any secrets that have already been decrypted and exist as standard Secret objects in the cluster will continue to function, so running applications will not be immediately affected. The primary risk is operational, which is why it's essential to monitor the controller's health and have a tested backup and recovery plan for its private key.

How does Plural help manage Sealed Secrets across many clusters? Plural is designed to solve the operational challenges of using Sealed Secrets at scale. Instead of manually installing the controller on every cluster, you can define it once as a Global Service, and Plural will deploy and manage it consistently across your entire fleet. Plural's GitOps pipelines also streamline the workflow for promoting secrets between environments, using automated pull requests and approval gates to give you better control and a clear audit trail.