Sealed Secrets Kubernetes: A Complete Guide

A core principle of modern security is enforcing the least privilege, but managing credentials in Kubernetes often complicates this. How do you allow developers to manage their application's secrets without giving them access to production decryption keys? Standard Kubernetes RBAC can be coarse, and injecting secrets through CI/CD pipelines introduces its own risks. The sealed secrets Kubernetes model offers an elegant solution through its "write-only" pattern. Anyone with a public key can encrypt a secret, but only the in-cluster controller holding the private key can decrypt it. This decouples the ability to create secrets from the ability to read them, drastically reducing your attack surface and ensuring plaintext credentials never leave the cluster.

Key takeaways:

• Commit secrets safely to Git: Standard Kubernetes Secrets are only base64 encoded, not truly encrypted, making them unsafe for version control. Sealed Secrets solves this by using public-key cryptography to create encrypted resources you can safely store in any Git repository.
• Follow a one-way encryption workflow: Use the kubeseal CLI to encrypt secrets locally before you commit them. A controller inside your cluster is the only component that can decrypt them, ensuring plaintext credentials are never exposed outside of Kubernetes.
• Establish a key management and recovery plan: The controller's private key is a critical asset, so you must back it up securely to avoid losing access to your secrets. A complete strategy also includes regular key rotation and precise RBAC policies to prevent unauthorized access.

What Are Sealed Secrets?

Sealed Secrets is an open-source project from Bitnami that enables secure secret management in GitOps workflows. It introduces a SealedSecret custom resource (CRD) that contains encrypted data safe to store in Git repositories, including public ones.

The model is based on asymmetric cryptography. The in-cluster controller generates a key pair and retains the private key. Developers use the public key (via kubeseal) to encrypt a standard Kubernetes Secret manifest into a SealedSecret. When the controller detects this resource, it decrypts the payload inside the cluster and materializes a native Secret for workloads to consume.

This design enforces a strict separation of duties:

• Seal (encrypt): Anyone with the public key.
• Unseal (decrypt): Only the controller holding the private key.

Plaintext credentials never appear in Git history, CI/CD logs, or external storage. The cluster becomes the sole decryption boundary.

The Problem with Standard Kubernetes Secrets

Native Kubernetes Secret objects are frequently misunderstood. By default, their data fields are base64-encoded—not encrypted. Base64 is a transport encoding, not a confidentiality mechanism. Anyone with get access to Secret resources can trivially decode values.

Unless you explicitly enable envelope encryption at rest in etcd and tightly restrict RBAC, Secret objects represent a high-value target. Committing them to Git is particularly dangerous: version control creates a permanent, replayable record of exposed credentials.

In short, base64 ≠ security.

How Sealed Secrets Improve Security

Sealed Secrets add a cryptographic control plane layer:

1. Each secret value is encrypted client-side.
2. A symmetric cipher (e.g., AES-256) encrypts the payload.
3. The symmetric key is encrypted with the controller’s public key.
4. Only the private key inside the cluster can reverse the process.

This hybrid encryption model ensures:

• No plaintext secrets in Git.
• No decryption in CI/CD systems.
• No ability for developers to read production secrets.
• Reduced blast radius if repositories or pipelines are compromised.

For GitOps environments using tools like Argo CD or Flux, Sealed Secrets provide a secure bridge between declarative configuration in Git and runtime secret material inside the cluster.

How Sealed Secrets Work

Sealed Secrets implements a hybrid cryptographic workflow that shifts decryption exclusively into the cluster. The system consists of:

• A cluster-side controller
• A client-side CLI (kubeseal)
• A SealedSecret Custom Resource Definition (CRD)

Secrets are encrypted before they reach Git. Decryption is performed only by the controller inside the target cluster.

The Public–Private Key Encryption Model

Sealed Secrets uses asymmetric cryptography:

• Public key → used to encrypt (seal) secrets
• Private key → used to decrypt (unseal) secrets

The controller generates a key pair at startup. Developers retrieve the public key and use it to encrypt standard Kubernetes Secret manifests. Because only the controller holds the private key, ciphertext stored in Git is computationally infeasible to reverse outside the cluster.

Under the hood, Sealed Secrets uses hybrid encryption:

1. Secret data is encrypted with a symmetric cipher (e.g., AES).
2. The symmetric key is encrypted with the controller’s public key.
3. The controller uses its private key to recover the symmetric key and decrypt the payload.

This design ensures confidentiality while remaining performant for arbitrary secret sizes.

The Role of the SealedSecret Controller

The controller runs inside the Kubernetes cluster and:

• Generates and stores the private key (persisted as a Kubernetes Secret)
• Exposes the public key for sealing operations
• Watches for SealedSecret resources
• Decrypts them and creates standard Secret objects

It operates as a reconciliation loop following the Kubernetes controller pattern. When a SealedSecret appears or changes, the controller deterministically materializes the corresponding Secret.

Plaintext secrets only exist inside the cluster after reconciliation. They are never stored in Git, and they never transit CI/CD systems in decrypted form.

The Encryption Workflow: Plaintext → SealedSecret

The sealing workflow is intentionally simple:

1. Create a standard Secret manifest locally.
2. Pipe it to kubeseal.
3. kubeseal fetches the cluster’s public key.
4. The tool outputs a SealedSecret manifest.
5. Commit the encrypted manifest to Git.

In a GitOps setup (e.g., with Argo CD or Flux), the encrypted resource is applied automatically. The controller decrypts it in-cluster and creates the usable Secret.

The net effect: encryption is client-side, decryption is cluster-bound, and the trust boundary is explicit.

Why Use Sealed Secrets?

Native Kubernetes Secret objects are base64-encoded, not encrypted. In Git-centric environments, committing them directly is equivalent to publishing credentials. Sealed Secrets solves this by encrypting secrets before they enter version control, enabling secure, declarative secret management within a GitOps workflow.

Instead of relying on external vault injection or CI/CD-time secret substitution, secrets become first-class Kubernetes resources that are encrypted at rest in Git and decrypted only inside the target cluster.

Safely Commit Secrets to Git

Sealed Secrets converts a standard Secret into a SealedSecret CRD containing ciphertext. The encryption uses the cluster’s public key; the corresponding private key exists only inside that cluster.

Implications:

• Encrypted manifests are safe to store in Git (even public repos).
• Git history remains auditable without leaking credentials.
• No plaintext secrets in CI logs or pipeline artifacts.
• The sealed file is cryptographically useless outside the intended cluster.

This allows teams to treat secrets like any other declarative infrastructure artifact—versioned, peer-reviewed, and reproducible.

Integrate Seamlessly with GitOps Workflows

Because SealedSecret is a Kubernetes resource, GitOps controllers such as Flux and Argo CD reconcile it like any other manifest.

Workflow:

1. Encrypted SealedSecret is committed to Git.
2. GitOps controller applies it to the cluster.
3. The in-cluster controller decrypts it.
4. A native Secret is created.
5. Workloads consume the Secret without modification.

Applications remain unaware of Sealed Secrets; they interact with standard Kubernetes Secret objects.

Strengthen Your Security Posture

Sealed Secrets enforces a cryptographic separation of duties:

• Encrypt (write): anyone with the public key.
• Decrypt (read): only the in-cluster controller.

This write-only model aligns with least privilege:

• Developers can seal production secrets without access to decryption keys.
• CI systems never handle plaintext production credentials.
• Compromise of developer machines does not expose cluster secrets.
• The private key never leaves the cluster boundary.

By constraining decryption to the cluster control plane, Sealed Secrets reduces blast radius and removes entire classes of Git and pipeline leakage risks while preserving a clean GitOps workflow.

How to Install and Set Up Sealed Secrets

Installing Sealed Secrets requires two components:

1. The in-cluster controller (handles decryption and reconciliation).
2. The kubeseal CLI (handles client-side encryption).

Encryption happens locally. Decryption happens only inside the cluster.

Deploy the Controller

The controller is typically installed via its official Helm chart from Bitnami.

Helm-based install (imperative example):

helm repo add sealed-secrets https://bitnami-labs.github.io/sealed-secrets
helm install sealed-secrets sealed-secrets/sealed-secrets \
  --namespace kube-system \
  --create-namespace

In a GitOps setup, you would declaratively install it via a HelmRelease managed by Flux or reconcile it through Argo CD.

On startup, the controller:

• Generates a public/private key pair.
• Stores the private key as a Kubernetes Secret (cluster-internal).
• Registers the SealedSecret CRD.
• Begins watching for SealedSecret resources.

Default namespace is typically kube-system, though production setups may isolate it in a dedicated namespace.

Install the kubeseal CLI

kubeseal performs client-side encryption.

Install options:

macOS (Homebrew):

brew install kubeseal

Linux/Windows:
Download the binary from the project’s GitHub releases and add it to your PATH.

The CLI:

• Fetches the controller’s public key.
• Encrypts standard Secret manifests.
• Outputs a SealedSecret CRD.

Anyone who needs to create or rotate secrets requires this tool. No cluster-admin privileges are needed to seal secrets—only access to the public key.

Verify the Installation

Confirm controller health:

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

You should see initialization logs and confirmation that the controller is ready.

Fetch the public key:

kubeseal --fetch-cert > public-cert.pem

If this succeeds, your CLI can communicate with the controller.

The public certificate is non-sensitive. You can:

• Commit it to Git.
• Distribute it internally.
• Use it in CI for sealing operations.

At this point, your environment is ready: encryption is client-side, decryption is cluster-bound, and sealed manifests are safe for GitOps workflows.

How to Create and Manage Sealed Secrets

With the Sealed Secrets controller running, secret management becomes a deterministic, Git-driven workflow:

1. Create or export a standard Kubernetes Secret.
2. Encrypt it with kubeseal.
3. Commit the resulting SealedSecret to Git.
4. Let your GitOps controller apply it.
5. The in-cluster controller decrypts and materializes a native Secret.

Plaintext exists only locally during creation and inside the cluster after reconciliation—never in version control.

Convert Existing Secrets

To bring unmanaged cluster secrets under GitOps control:

Export the existing secret:

kubectl get secret my-secret -n my-namespace -o yaml

Pipe it to kubeseal:

kubectl get secret my-secret -n my-namespace -o yaml | \
  kubeseal --format yaml > my-sealed-secret.yaml

1. Commit the resulting SealedSecret manifest.

After applying it, the controller decrypts and recreates the original Secret. This migrates runtime-managed secrets into declarative, version-controlled infrastructure.

Best practice: delete the unmanaged original secret once the sealed version is reconciled to avoid configuration drift.

Create New Sealed Secrets

For new secrets:

Create a local Secret manifest containing plaintext values.

Add that file to .gitignore.

Encrypt it:

kubeseal --format yaml < secret.yaml > sealed-secret.yaml

kubeseal fetches the cluster’s public key and outputs a SealedSecret CRD. The generated file is safe to commit.

When your GitOps controller (e.g., Flux or Argo CD) applies it, the Sealed Secrets controller decrypts the payload and creates a standard Kubernetes Secret. Applications consume it normally—no code changes required.

Manage Scopes and Namespaces

Sealed Secrets enforce binding between ciphertext and deployment context.

Default (strict scope):

• Bound to a specific name and namespace.
• Decryption fails if either changes.
• Prevents replay across environments.

You can alter scope via annotations before sealing:

• Namespace-wide scope
  Allows renaming within the same namespace.
• Cluster-wide scope
  Allows unsealing in any namespace with any name.

Strict scope is recommended for production to minimize misuse and lateral movement. Broader scopes should be reserved for platform-level secrets or controlled multi-namespace patterns.

The scoping model adds an additional cryptographic guardrail on top of Kubernetes RBAC, ensuring secrets cannot be trivially repurposed outside their intended boundary.

What Challenges Do Sealed Secrets Solve?

4

Native Kubernetes Secret objects are base64-encoded, not encrypted. In GitOps environments—where Git is the source of truth—this creates systemic risk. Sealed Secrets addresses these gaps with a one-way encryption model that confines decryption to the cluster.

The result is secure version control, tighter access boundaries, safer environment separation, and cleaner CI/CD integration.

Storing Secrets in Version Control

Standard Secret manifests cannot be safely committed to Git. Base64 encoding is reversible, and Git history is immutable. Once exposed, credentials remain exposed.

Sealed Secrets solves this by converting a Secret into a SealedSecret CRD containing ciphertext encrypted with the cluster’s public key. Only the in-cluster private key can decrypt it.

This enables:

• Git as the single source of truth—including secrets.
• Full auditability and pull-request review of secret changes.
• No plaintext credentials in repository history.

Controlling Access and Authorization

Kubernetes RBAC governs API access but does not provide cryptographic separation between “create” and “read decrypted value.”

Sealed Secrets introduces a write-only model:

• Developers and CI systems can encrypt using the public key.
• Only the controller can decrypt using the private key.
• No user or pipeline can retrieve plaintext from a SealedSecret.

This enforces least privilege at a cryptographic layer, reducing blast radius even if developer credentials or CI runners are compromised.

Managing Environment-Specific Secrets

Different environments require distinct credentials (dev, staging, prod). Cross-environment leakage is a common operational failure mode.

Because SealedSecret objects are declarative manifests:

• You can isolate them by directory or branch.
• Each cluster has its own key pair.
• A secret sealed for production cannot be decrypted in staging.

GitOps controllers such as Argo CD or Flux apply only the manifests scoped to their environment. Cryptographic binding prevents accidental replay across clusters.

Integrating with CI/CD Pipelines

Traditional secret injection in CI/CD often involves:

• Pipeline variables
• External vault lookups
• Runtime environment exports

These increase the attack surface and expose plaintext in logs or memory.

With Sealed Secrets:

• CI handles only encrypted manifests.
• Pipelines never require production secret values.
• Decryption happens exclusively inside the cluster.

The CI system becomes a transport mechanism, not a secret custodian. This sharply reduces credential exposure risk while preserving automated deployment workflows.

In aggregate, Sealed Secrets closes the gap between declarative GitOps practices and secure secret management by shifting trust from pipelines and developers to the cluster’s cryptographic boundary.

Avoid These Common Implementation Pitfalls

Sealed Secrets reduces GitOps friction, but misconfiguration can create avoidable outages. The most common issues involve RBAC gaps, controller key loss, and improper key lifecycle management.

Address these early to avoid broken deployments and unrecoverable ciphertext.

Navigating RBAC Permissions

SealedSecret is a Custom Resource. It requires explicit RBAC rules separate from native Secret objects.

Typical failure mode:

• Developers can create Secret resources.
• They lack permissions for SealedSecret.
• GitOps reconciliation fails silently or with authorization errors.

Best practices:

• Define Roles/ClusterRoles that include sealedsecrets.bitnami.com resources.
• Mirror access patterns from Secret where appropriate.
• Ensure GitOps service accounts have get, create, update, and watch permissions for SealedSecret.

In multi-cluster environments, policy drift becomes a risk. Platforms like Plural help standardize and propagate RBAC policies fleet-wide using Global Services, reducing inconsistent authorization across clusters.

Handling Controller Dependencies

The controller generates a public/private key pair at startup and stores the private key as a Kubernetes Secret (commonly in kube-system).

Critical properties:

• The private key is required to decrypt all existing SealedSecret resources.
• Deleting this key makes existing sealed secrets undecryptable.
• Without a backup, recovery requires resealing every secret.

Operational safeguards:

• Back up the controller’s private key secret.
• Restrict deletion rights on that secret.
• Monitor controller logs during startup to confirm key loading.
• Include the key in cluster disaster recovery procedures.

Key loss is the single most disruptive failure mode in Sealed Secrets deployments.

Avoiding Key Management Mistakes

By default, the controller supports periodic key rotation. This improves forward secrecy and reduces long-term exposure risk.

Common mistake:

• Disabling automatic rotation prematurely.
• Manually rotating keys without distributing updated public certs.
• Losing private keys during backup or restore workflows.

Guidance:

• Keep automatic renewal enabled unless you have a defined rotation runbook.
• Document the resealing process for when rotation occurs.
• Version and distribute the public certificate in a controlled manner.
• Test restoration procedures in non-production clusters.

Manual key lifecycle management increases operational complexity and introduces human-error risk. Until your team has production experience with Sealed Secrets, default automation is safer.

When properly configured—with aligned RBAC, protected private keys, and disciplined rotation—Sealed Secrets provides a stable cryptographic boundary for GitOps-driven secret management.

Best Practices for Managing Sealed Secrets

Adopting Sealed Secrets secures GitOps secret storage, but operational rigor determines long-term reliability. The primary risks to plan for are:

• Private key compromise
• Private key loss
• Over-permissive RBAC
• Undetected controller failures

A resilient strategy covers key rotation, access control, disaster recovery, and observability.

Implement a Key Rotation Strategy

The controller periodically renews its sealing key, but you should define an explicit rotation policy.

Key principles:

• Treat the private key as high-value cryptographic material.
• Maintain a documented emergency rotation runbook.
• Reseal secrets when keys rotate (especially after compromise).
• Distribute updated public certificates deterministically.

If a private key is suspected compromised:

1. Trigger key regeneration.
2. Reseal all active secrets with the new public key.
3. Reconcile via GitOps.

Rotation reduces the blast radius and supports compliance requirements for cryptographic hygiene.

Avoid disabling automatic renewal unless you have automation to replace it.

Configure RBAC Correctly

SealedSecret is a CRD and requires explicit RBAC rules.

Best practices:

• Grant namespace-scoped permissions wherever possible.
• Avoid cluster-wide write access unless operationally required.
• Ensure GitOps service accounts can reconcile SealedSecret resources.
• Restrict who can delete or modify the controller’s private key secret.

In multi-cluster environments, RBAC drift becomes a systemic risk. Plural allows centralized RBAC configuration and fleet-wide policy propagation, reducing inconsistency and audit gaps.

Least privilege should apply to:

• Sealing operations
• Applying manifests
• Managing the controller
• Accessing decrypted Secret objects

Plan for Backup and Disaster Recovery

The controller’s private key is a single point of decryption authority.

If lost:

• Existing SealedSecret objects become undecryptable.
• Recovery requires resealing every secret.
• Production deployments may stall.

Mitigation strategy:

• Back up the private key secret securely.
• Store backups in encrypted, access-controlled storage (e.g., managed vault).
• Restrict deletion permissions on the key.
• Test restoration in non-production clusters.

Disaster recovery plans should explicitly include sealed secret key restoration steps.

Set Up Monitoring and Auditing

Operational visibility prevents silent failures.

Monitor:

• Controller startup logs (key load/generation events).
• Decryption failures.
• CRD reconciliation errors.
• Unexpected key regeneration.

Audit:

• Who created or modified SealedSecret resources.
• Namespace-level secret changes.
• RBAC changes affecting sealed secret access.

Centralized observability improves mean time to detection. Plural’s unified dashboard provides consolidated monitoring across clusters, making it easier to correlate Sealed Secrets events with broader control plane activity.

A disciplined lifecycle approach—rotation, least-privilege RBAC, key backup, and active monitoring—turns Sealed Secrets from a GitOps convenience into a hardened cryptographic boundary.

What Are the Limitations of Sealed Secrets?

Sealed Secrets is optimized for securely moving secrets from Git into a Kubernetes cluster. It is intentionally narrow in scope. That simplicity is a strength—but also a constraint.

The primary limitations surface around its write-only model, lack of advanced secret lifecycle features, and operational complexity in multi-cluster environments.

Write-Only Model Trade-Offs

Sealed Secrets enforces one-way encryption:

• Anyone with the public key can seal.
• Only the in-cluster controller can unseal.

This improves confidentiality but introduces workflow constraints:

• You cannot recover plaintext from a SealedSecret manifest.
• Debugging requires access to the live cluster Secret.
• Automated validation outside the cluster is limited.
• Secret value inspection for compliance or rotation requires API access.

This is not a computational performance issue—it is an operational constraint. Teams accustomed to centralized secret introspection may find the model restrictive.

When to Consider Alternatives

Sealed Secrets does not provide:

• Dynamic secrets
• Secret leasing and automatic expiration
• Fine-grained audit trails beyond Kubernetes audit logs
• Cross-platform secret orchestration outside Kubernetes

If your requirements include dynamic database credentials, revocation workflows, or centralized infrastructure-wide secret governance, a dedicated secrets manager such as HashiCorp Vault may be more appropriate.

Vault and similar systems:

• Issue short-lived credentials
• Provide detailed access auditing
• Support policy-driven secret generation
• Operate independently of Kubernetes

Sealed Secrets is best suited for static application secrets in GitOps-driven clusters—not as a universal secrets platform.

Multi-Cluster Management Complexity

Each Sealed Secrets controller generates its own encryption key pair by default.

Implications:

• A secret sealed for Cluster A cannot be decrypted in Cluster B.
• Environment-specific resealing is required.
• Fleet-wide updates require per-cluster ciphertext.

Your options:

1. Maintain per-cluster sealed manifests
   Secure, but increases operational overhead and risk of drift.
2. Share a single key across clusters
   Simplifies management but weakens isolation. A compromised key impacts the entire fleet.

This becomes particularly challenging for platform teams managing dozens of clusters.

Plural mitigates some coordination complexity by providing centralized visibility and deployment orchestration across clusters. However, the cryptographic boundary remains cluster-scoped by design. That isolation is deliberate—but operationally expensive at scale.

Sealed Secrets is highly effective for GitOps-aligned, static secret delivery within a cluster. It is less suitable for:

• Large-scale fleet secret synchronization
• Dynamic credential issuance
• Centralized cross-environment secret governance
• Complex compliance-driven auditing requirements

Choosing it should be a deliberate architectural decision aligned with your operational model.

Using Sealed Secrets at Scale with Plural

Sealed Secrets provide a robust solution for managing secrets within a single Kubernetes cluster, but applying them across a large fleet introduces operational complexity. Plural simplifies this by integrating Sealed Secrets management directly into its GitOps-driven, multi-cluster orchestration platform. This allows you to maintain security and velocity, even as your environment grows from one cluster to hundreds.

Managing Secrets Across a Fleet

The core value of Sealed Secrets is the ability to safely store encrypted secrets as code in your Git repository. When managing a fleet, however, you need a reliable way to ensure the correct secrets are deployed to the correct clusters. Manually tracking which SealedSecret manifest belongs to which environment is not a scalable solution.

Plural’s GitOps-based continuous deployment automates this process. You can define services that sync your Sealed Secrets from a central Git repository to designated clusters based on tags or other criteria. This approach allows you to manage your entire fleet's secrets from a single source of truth, ensuring consistency and reducing the risk of configuration drift.

Automating with Self-Service Workflows

Creating and updating secrets often requires developers to interact with platform engineers, creating a bottleneck. While kubeseal is a powerful tool, requiring every developer to master its workflow can slow down development cycles. A better approach is to provide developers with a streamlined, self-service process for managing their application secrets.

Plural’s PR automation API enables you to build these self-service workflows. You can create simple internal UIs where developers can securely submit new secret values. Plural then automates the encryption process, generates the SealedSecret manifest, and opens a pull request for approval. This empowers developers to manage their own secrets while platform teams maintain control and oversight.

Scaling Securely Across Multiple Environments

As you scale, you need to manage distinct sets of secrets for development, staging, and production environments. Sealed Secrets are designed so that only the controller running within a specific cluster can decrypt them, but you still need to prevent production secrets from accidentally being deployed to a development cluster.

Plural’s agent-based architecture provides the necessary separation and control. You can structure your Git repositories to isolate environment-specific secrets and use Plural to create deployment pipelines that target specific clusters. By combining this with Plural’s embedded Kubernetes dashboard, which uses impersonation for RBAC, you can ensure that only authorized personnel can access and manage secrets in sensitive environments.

Related Articles

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

Frequently Asked Questions

What's the real difference between a standard Kubernetes Secret and a SealedSecret? The main difference is security. A standard Kubernetes Secret stores data using base64 encoding, which is not encryption and can be easily reversed by anyone with access to the cluster. A SealedSecret, on the other hand, contains data that is cryptographically encrypted. This means it's safe to store in a Git repository because it can only be decrypted by the specific controller running inside your target cluster, which holds the private key.

Can I use the same SealedSecret across multiple clusters? By default, no. Each Sealed Secrets controller in each cluster generates its own unique encryption key. A secret sealed for one cluster's public key cannot be decrypted by a different cluster's controller. While this enforces strong security isolation, it creates challenges for multi-cluster management. To handle this at scale, you need a clear strategy for managing different encrypted manifests for each environment, which is where an orchestration platform like Plural becomes essential for ensuring consistency.

What happens if the controller's private key is lost? If the private key is lost, for example if the Kubernetes Secret storing it is accidentally deleted, the controller will lose its ability to decrypt any existing SealedSecrets. This would prevent your applications from accessing their credentials. This is why having a robust backup and disaster recovery plan for this key is critical. Without a backup, you would have to generate a new key and re-encrypt every single one of your secrets.

How does this work in a CI/CD pipeline without exposing the secret? Sealed Secrets allows your CI/CD pipeline to handle secret manifests without ever accessing the plaintext values. The pipeline only needs the controller's public key to encrypt a secret. Its role is simply to commit the resulting encrypted SealedSecret file to your Git repository. The actual decryption happens securely inside the cluster, completely decoupled from your CI/CD system. This keeps your sensitive credentials out of pipeline logs and variables.

Do developers need direct access to the Kubernetes cluster to create secrets? No, and this is one of the primary security benefits. A developer only needs the kubeseal command-line tool and the controller's public key to encrypt a secret. They can perform this action on their local machine and commit the resulting SealedSecret manifest without needing any kubectl access to the cluster. This enforces a strong separation of concerns between creating secrets and managing the cluster where they are used.