mirrors/external-secrets
1
0
Fork 0
mirror of https://github.com/external-secrets/external-secrets.git synced 2024-12-14 11:57:59 +00:00
Code Activity

Fixed docs nav bar and a couple of broken links (#3445)

Browse source 
Signed-off-by: Parth Patel <p.patel81@yahoo.com>
This commit is contained in:
Parth Patel 2024-05-05 22:47:47 +12:00 committed by GitHub
parent f22c53fca0
commit 6d08e679be
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
2 changed files with 5 additions and 25 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/guides/pushsecrets.md
View file

@ -3,7 +3,7 @@ Contrary to what `ExternalSecret` does by pulling secrets from secret providers
The update behavior of `PushSecret` is controlled by `spec.updatePolicy`. The default policy is `Replace`, such that secrets are overwritten in the provider, regardless of whether there already is a secret present in the provider at the given location. If you do not want `PushSecret` to overwrite existing secrets in the provider, you can set `spec.UpdatePolicy` to `IfNotExists`. With this policy, the provider becomes the source of truth. Please note that with using `spec.updatePolicy=IfNotExists` it is possible that the secret value referenced by the `PushSecret` within the cluster differs from the secret value at the given location in the provider.
By default, the secret created in the secret provided will not be deleted even after deleting the `PushSecret`, unless you set `spec.deletionPolicy` to `Delete`.
By default, the secret created in the secret provided will not be deleted even after deleting the `PushSecret`, unless you set `spec.deletionPolicy` to `Delete`.
``` yaml
@ -14,7 +14,7 @@ By default, the secret created in the secret provided will not be deleted even a
An interesting use case for `kind=PushSecret` is backing up your current secret from one provider to another one.
Imagine you have your secrets in GCP and you want to back them up in Azure Key Vault. You would then create a `SecretStore` for each provider, and an `ExternalSecret` to pull the secrets from GCP. This will generate a `kind=Secret` in your cluster that you can use as the source of a `PushSecret` configured with the Azure `SecretStore`.
Imagine you have your secrets in GCP and you want to back them up in Azure Key Vault. You would then create a `SecretStore` for each provider, and an `ExternalSecret` to pull the secrets from GCP. This will generate a `kind=Secret` in your cluster that you can use as the source of a `PushSecret` configured with the Azure `SecretStore`.
![PushSecretBackup](../pictures/diagrams-pushsecret-backup.png)
@ -42,4 +42,4 @@ This will _marshal_ the entire secret data and push it into this single property
This should _ONLY_ be done if the secret data is marshal-able. Values like, binary data cannot be marshaled and will result in error or invalid secret data.
### Key conversion strategy
You can also set `data[*].conversionStrategy: ReverseUnicode` to reverse the invalid character replaced by the `conversionStrategy: Unicode` configuration in the `ExternalSecret` object as [documented here](../guides/getallsecrets/#avoiding-name-conflicts).
You can also set `data[*].conversionStrategy: ReverseUnicode` to reverse the invalid character replaced by the `conversionStrategy: Unicode` configuration in the `ExternalSecret` object as [documented here](../guides/getallsecrets.md#avoiding-name-conflicts).

24
hack/api-docs/mkdocs.yml
View file

@ -116,6 +116,8 @@ nav:
- Passbolt: provider/passbolt.md
- Pulumi ESC: provider/pulumi.md
- Onboardbase: provider/onboardbase.md
- Password Depot: provider-passworddepot.md
- Fortanix: provider/fortanix.md
- Examples:
- FluxCD: examples/gitops-using-fluxcd.md
- Anchore Engine: examples/anchore-engine-credentials.md
@ -132,27 +134,5 @@ nav:
- Talks: eso-talks.md
- Demos: eso-demos.md
- Blogs: eso-blogs.md
- AWS:
- Secrets Manager: provider-aws-secrets-manager.md
- Parameter Store: provider-aws-parameter-store.md
- Azure:
- Key Vault: provider-azure-key-vault.md
- Google:
- Secrets Manager: provider-google-secrets-manager.md
- IBM:
- Secrets Manager: provider-ibm-secrets-manager.md
- HashiCorp Vault: provider-hashicorp-vault.md
- Yandex:
- Lockbox: provider-yandex-lockbox.md
- Password Depot: provider-passworddepot.md
- Gitlab:
- Gitlab Project Variables: provider-gitlab-project-variables.md
- Oracle:
- Oracle Vault: provider-oracle-vault.md
- References:
- API specification: spec.md
- Contributing:
- Developer guide: contributing-devguide.md
- Contributing Process: contributing-process.md
- Code of Conduct: contributing-coc.md
- Deprecation Policy: deprecation-policy.md