Dec 19, 2023 · Dec 17, 2023 · Dec 17, 2023 · Dec 17, 2023 · Dec 19, 2023 · Dec 19, 2023
diff --git a/_docs/security/secrets.md b/_docs/security/secrets.md

 Codefresh provides out-of-the-box management for secrets, generally to store secrets for third-party integrations.

 For secure secret storage, every Codefresh GitOps Runtime uses the [Bitnami Sealed Secrets controller](https://github.com/bitnami-labs/sealed-secrets){:target="_blank"} behind the scenes.
 This controller is installed as part of the Runtime and automatically managed by Codefresh.

 ## How Sealed Secrets work
 For secure secret storage, every Codefresh GitOps Runtime uses the [Bitnami Sealed Secrets Controller](https://github.com/bitnami-labs/sealed-secrets){:target="_blank"} behind the scenes.
 This Controller is installed as part of the Runtime and automatically managed by Codefresh.


 Sealed Secretsare based on [public/private key encryption](https://en.wikipedia.org/wiki/Public-key_cryptography){:target="_blank"}. When the controller is installed, it gets a public and private key. The private key stays within the cluster. The public key can be given anywhere to encrypt secrets.
 ## HowSealed Secretswork

 Any kind of secret can be encrypted with the public key (also via the `kubeseal` executable), and then passed to the cluster for decryption when needed.
 Sealed Secrets operate using [public/private key encryption](https://en.wikipedia.org/wiki/Public-key_cryptography){:target="_blank"}.
 The Controller manages a public and a private key. The private key stays within the cluster. The public key can be distributed anywhere to encrypt secrets.

 Codefresh handles Sealed Secrets at the level oftheaccount, meaning that you need to create a Sealed Secret for an integration once, and it is then availabletoall clusters managed intheaccount. To ensure maximum security, only the ConfigMap with the public key of the SealedSecret is commited to Git.
 Any kind of secret encrypted withthepublic key (or via the `kubeseal` executable), can be passedto thecluster for decryption when needed.

 Codefresh employs a mechanism to consistently apply Sealed Secrets across multiple clusters in the same account, in complete alignment with the GitOps paradigm.
 It also facilitates sharing the public and private keys between the Codefresh platform and the [Shared Configuration Repository]({{site.baseurl}}/docs/installation/gitops/shared-configuration/)
 in the user's GitOps Runtime environment.

 Here's the event flow for Sealed Secrets in GitOps:
 1. The operator or developer creates an encrypted secret with the `kubeseal` executable.
 1. Codefresh creates the `SealedSecret` custom Kubernetes resource.
 1. Codefresh also creates another Kubernetes resource, the `ConfigMap` containing the public key of the `SealedSecret`.
 1. The `ConfigMap` resource is committed to Git.
 1. When required for an application or a resource, the Sealed Secret controller identifies the Sealed Secret object and decrypts it using the private key of the cluster.
 1. The Sealed Secret is converted to a [standard Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/){:target="_blank"} within the cluster.
 1. It is then passed to the application like any other secret, as a mounted file or environment variable.
 1. The application uses the secret in its decrypted form.
 **Sealed Secrets mechanism in Codefresh**
 1. The Sealed Secrets Controller generates both the public and private keys.
 1. Codefresh creates a `ConfigMap` resource representing these keys, and enables their sharing across clusters.
  The `ConfigMap` contains the public key of the `SealedSecret`.
 1. The `ConfigMap` resource is committed to Git. When the `ConfigMap` is synced to the cluster from the Shared Configuration Repo by its Argo CD application,
 the App-proxy reconciles the `ConfigMap`, transforming it into a sealing key secret.
 1. When requested by an application:
  * The Sealed Secret Controller identifies and decrypts the Sealed Secret object using the private key specific to the cluster.
  * Transforms the decrypted Sealed Secret into a [standard Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/){:target="_blank"} within the cluster.
 1. The application receives the decrypted secret just as any other secret, either as a mounted file or environment variable, and uses the secret in its decrypted form.

 For more details, you can read our [blog post for sealed secrets](https://codefresh.io/blog/handle-secrets-like-pro-using-gitops/){:target="_blank"}.

 ## Configuring the Sealed Secretscontroller
 ## Configuring the Sealed SecretsController

 The SealedSecret controller is fully managed by the Codefreshruntime, andsecretencryption and decryption are fully automated.
 The SealedSecrets Controller is fully managed by the CodefreshGitOps Runtime, and encryption and decryption of secrets are fully automated.

 > **Warning!** DO NOT tamper with thecontroller or its private/public keys in any way.
 > **Warning!** DO NOT tamper with theController or its private/public keys in any way.

 The applications you deploy with Codefresh should also have no knowledge of thecontroller. All secrets that you need in your own applications should be accessed using the standard Kubernetes methods.
 The applications you deploy with Codefresh should also have no knowledge of theController. All secrets that you need in your own applications should be accessed using the standard Kubernetes methods.

 ## Related articles
 [Verifying authenticity of Codefresh artifacts]({{site.baseurl}}/docs/security/codefresh-signed-artifacts/)
 [Install Hybrid GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/hybrid-gitops/)


 <!--- Codefresh provides out-of-the-box management for secrets, generally to store secrets for third-party integrations. For secure secret storage, every Codefresh GitOps Runtime uses the [Bitnami Sealed Secrets controller](https://github.com/bitnami-labs/sealed-secrets){:target="_blank"} behind the scenes. This controller is installed as part of the Runtime and automatically managed by Codefresh.

 Codefresh employs a mechanism that applies a Sealed Secret consistently across multiple clusters, in complete alignment with the GitOps paradigm. It also facilitates sharing the public and private keys between the Codefresh platform and the Shared Configuration Repository in the user's GitOps Runtime environment.




 ## How Sealed Secrets work

 Sealed Secrets are based on [public/private key encryption](https://en.wikipedia.org/wiki/Public-key_cryptography){:target="_blank"}. When the controller is installed, it gets a public and private key. The private key stays within the cluster. The public key can be given anywhere to encrypt secrets.  Any kind of secret can be encrypted with the public key (also via the `kubeseal` executable), and then passed to the cluster for decryption when needed.

 For Argo CD applications, it is critical to encrypt secrets, as it means that you can commit any kind of secret in Git as long as it is encrypted.

 **Sealed Secrets mechanism in Codefresh**
 The Sealed Secrets controller in a GitOps Runtime generates a sealing key, which is then divided into two parts:

 1. Half the private key is saved in a `configmap` that represents this sealing key, stored in the Shared Configuration Repo
 2. The other half of the private key is stored in the Codefresh platform

 When the `configmap` is synced to the cluster from the Shared Configuration Repo by its Argo CD application, the App-proxy reconciles this `configmap` into a sealing key secret.

 For more details, you can read our [blog post for sealed secrets](https://codefresh.io/blog/handle-secrets-like-pro-using-gitops/){:target="_blank"}.

 The Sealed Secrets controller is completely managed by the Codefresh GitOps Runtime, and secret encryption and decryption are fully automated.

 > **WARNING!**
 _DO NOT_ tamper with the controller or its private/public keys in any way.

 The Argo CD applications you deploy with Codefresh should also have no knowledge of the controller. Access the secrets that you need in your own applications using the standard Kubernetes methods.

 -->
Original file line number	Diff line number	Diff line change
Expand Up		@@ -9,37 +9,42 @@ toc: true

		Codefresh provides out-of-the-box management for secrets, generally to store secrets for third-party integrations.

		For secure secret storage, every Codefresh GitOps Runtime uses the [Bitnami Sealed Secrets controller](https://github.com/bitnami-labs/sealed-secrets){:target="_blank"} behind the scenes.
		This controller is installed as part of the Runtime and automatically managed by Codefresh.

		## How Sealed Secrets work
		For secure secret storage, every Codefresh GitOps Runtime uses the [Bitnami Sealed Secrets Controller](https://github.com/bitnami-labs/sealed-secrets){:target="_blank"} behind the scenes.
		This Controller is installed as part of the Runtime and automatically managed by Codefresh.


		Sealed Secretsare based on [public/private key encryption](https://en.wikipedia.org/wiki/Public-key_cryptography){:target="_blank"}. When the controller is installed, it gets a public and private key. The private key stays within the cluster. The public key can be given anywhere to encrypt secrets.
		## HowSealed Secretswork

		Any kind of secret can be encrypted with the public key (also via the `kubeseal` executable), and then passed to the cluster for decryption when needed.
		Sealed Secrets operate using [public/private key encryption](https://en.wikipedia.org/wiki/Public-key_cryptography){:target="_blank"}.
		The Controller manages a public and a private key. The private key stays within the cluster. The public key can be distributed anywhere to encrypt secrets.

		Codefresh handles Sealed Secrets at the level oftheaccount, meaning that you need to create a Sealed Secret for an integration once, and it is then availabletoall clusters managed intheaccount. To ensure maximum security, only the ConfigMap with the public key of the SealedSecret is commited to Git.
		Any kind of secret encrypted withthepublic key (or via the `kubeseal` executable), can be passedto thecluster for decryption when needed.

		Codefresh employs a mechanism to consistently apply Sealed Secrets across multiple clusters in the same account, in complete alignment with the GitOps paradigm.
		It also facilitates sharing the public and private keys between the Codefresh platform and the [Shared Configuration Repository]({{site.baseurl}}/docs/installation/gitops/shared-configuration/)
		in the user's GitOps Runtime environment.

		Here's the event flow for Sealed Secrets in GitOps:
		1. The operator or developer creates an encrypted secret with the `kubeseal` executable.
		1. Codefresh creates the `SealedSecret` custom Kubernetes resource.
		1. Codefresh also creates another Kubernetes resource, the `ConfigMap` containing the public key of the `SealedSecret`.
		1. The `ConfigMap` resource is committed to Git.
		1. When required for an application or a resource, the Sealed Secret controller identifies the Sealed Secret object and decrypts it using the private key of the cluster.
		1. The Sealed Secret is converted to a [standard Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/){:target="_blank"} within the cluster.
		1. It is then passed to the application like any other secret, as a mounted file or environment variable.
		1. The application uses the secret in its decrypted form.
		Sealed Secrets mechanism in Codefresh
		1. The Sealed Secrets Controller generates both the public and private keys.
		1. Codefresh creates a `ConfigMap` resource representing these keys, and enables their sharing across clusters.
		The `ConfigMap` contains the public key of the `SealedSecret`.
		1. The `ConfigMap` resource is committed to Git. When the `ConfigMap` is synced to the cluster from the Shared Configuration Repo by its Argo CD application,
		the App-proxy reconciles the `ConfigMap`, transforming it into a sealing key secret.
		1. When requested by an application:
		* The Sealed Secret Controller identifies and decrypts the Sealed Secret object using the private key specific to the cluster.
		* Transforms the decrypted Sealed Secret into a [standard Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/){:target="_blank"} within the cluster.
		1. The application receives the decrypted secret just as any other secret, either as a mounted file or environment variable, and uses the secret in its decrypted form.

		For more details, you can read our [blog post for sealed secrets](https://codefresh.io/blog/handle-secrets-like-pro-using-gitops/){:target="_blank"}.

		## Configuring the Sealed Secretscontroller
		## Configuring the Sealed SecretsController

		The SealedSecret controller is fully managed by the Codefreshruntime, andsecretencryption and decryption are fully automated.
		The SealedSecrets Controller is fully managed by the CodefreshGitOps Runtime, and encryption and decryption of secrets are fully automated.

		> Warning! DO NOT tamper with thecontroller or its private/public keys in any way.
		> Warning! DO NOT tamper with theController or its private/public keys in any way.

		The applications you deploy with Codefresh should also have no knowledge of thecontroller. All secrets that you need in your own applications should be accessed using the standard Kubernetes methods.
		The applications you deploy with Codefresh should also have no knowledge of theController. All secrets that you need in your own applications should be accessed using the standard Kubernetes methods.

		## Related articles
		[Verifying authenticity of Codefresh artifacts]({{site.baseurl}}/docs/security/codefresh-signed-artifacts/)
Expand All		@@ -48,37 +53,7 @@ The applications you deploy with Codefresh should also have no knowledge of the
		[Install Hybrid GitOps Runtimes]({{site.baseurl}}/docs/installation/gitops/hybrid-gitops/)


		<!--- Codefresh provides out-of-the-box management for secrets, generally to store secrets for third-party integrations. For secure secret storage, every Codefresh GitOps Runtime uses the [Bitnami Sealed Secrets controller](https://github.com/bitnami-labs/sealed-secrets){:target="_blank"} behind the scenes. This controller is installed as part of the Runtime and automatically managed by Codefresh.

		Codefresh employs a mechanism that applies a Sealed Secret consistently across multiple clusters, in complete alignment with the GitOps paradigm. It also facilitates sharing the public and private keys between the Codefresh platform and the Shared Configuration Repository in the user's GitOps Runtime environment.




		## How Sealed Secrets work

		Sealed Secrets are based on [public/private key encryption](https://en.wikipedia.org/wiki/Public-key_cryptography){:target="_blank"}. When the controller is installed, it gets a public and private key. The private key stays within the cluster. The public key can be given anywhere to encrypt secrets. Any kind of secret can be encrypted with the public key (also via the `kubeseal` executable), and then passed to the cluster for decryption when needed.

		For Argo CD applications, it is critical to encrypt secrets, as it means that you can commit any kind of secret in Git as long as it is encrypted.

		Sealed Secrets mechanism in Codefresh
		The Sealed Secrets controller in a GitOps Runtime generates a sealing key, which is then divided into two parts:

		1. Half the private key is saved in a `configmap` that represents this sealing key, stored in the Shared Configuration Repo
		2. The other half of the private key is stored in the Codefresh platform

		When the `configmap` is synced to the cluster from the Shared Configuration Repo by its Argo CD application, the App-proxy reconciles this `configmap` into a sealing key secret.

		For more details, you can read our [blog post for sealed secrets](https://codefresh.io/blog/handle-secrets-like-pro-using-gitops/){:target="_blank"}.

		The Sealed Secrets controller is completely managed by the Codefresh GitOps Runtime, and secret encryption and decryption are fully automated.

		> WARNING!
		_DO NOT_ tamper with the controller or its private/public keys in any way.

		The Argo CD applications you deploy with Codefresh should also have no knowledge of the controller. Access the secrets that you need in your own applications using the standard Kubernetes methods.

		-->



Expand Down