feat: add cloud secrets manager docs

content/docs/09.administrator-guide/01.configuration/03.enterprise-edition/secrets/aws-secret-manager/index.md

@@ -0,0 +1,32 @@
+---
+title: AWS Secret Manager configuration
+---
+
+With this integration, Namespace Secrets will be stored in [AWS Secret Manager](https://aws.amazon.com/secrets-manager/). The [AWS IAM user or role](https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_iam-permissions.html) for this integration needs to have the following permissions: `CreateSecret, DeleteSecret, DescribeSecret, GetSecretValue, ListSecrets, PutSecretValue, RestoreSecret, TagResource, UpdateSecret`.
+
+## Authentication
+
+You can configure the authentication to AWS Cloud in multiple ways:
+- Using `accessKeyId` and `secretKeyId` properties
+- Adding `sessionToken`,  `accessKeyId` and `secretKeyId` properties
+- If the above properties are not set, Kestra will use the default AWS authentication, in the same way as AWS CLI handles it (i.e. trying to use the AWS CLI profile or the default environment variables `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_DEFAULT_REGION`)
+
+```yaml
+kestra:
+  secret:
+    aws-secret-manager:
+      accessKeyId: "test"
+      secretKeyId: "test"
+      sessionToken: "token"
+```
+
+## Additional configuration
+
+### `kestra.secret.aws-secret-manager.region`
+The AWS region to be used by the Secrets Manager
+
+### `kestra.secret.aws-secret-manager.prefix`
+Optional property to store secrets separately for a different namespace, tenant, or instance. If configured, Kestra will prefix all Secret keys using that prefix. The main purpose of a prefix is to share the same secret manager between multiple Kestra instances.
+
+### `kestra.secret.aws-secret-manager.endpointOverride`
+Optional property to replace AWS default endpoint by an AWS-compatible service such as [MinIO](https://min.io/).

content/docs/09.administrator-guide/01.configuration/03.enterprise-edition/secrets/azure-key-manager/index.md

@@ -0,0 +1,30 @@
+---
+title: Azure Key Vault configuration
+---
+
+This integration will store secrets in [Azure Key Vault](https://azure.microsoft.com/products/key-vault/). Kestra authentications must have `"Get", "List", "Set", "Delete", "Recover", "Backup", "Restore", "Purge"` permissions.
+
+## Authentication
+You can authenticate the Secrets Manager with Azure Cloud in multiple ways:
+- Using a user or a service principal secret by setting properties `clientId` and `clientSecret`.
+- If none is set, the default authentication will be used e.g. in a similar way as Azure CLI does it.
+
+```yaml
+kestra:
+  secret:
+    azure-key-vault:
+      clientSecret:
+        tenantId: "id"
+        clientId: "id"
+        clientSecret: "secret"
+```
+
+## Others configurations
+### `kestra.secret.azure-key-vault.vaultName`
+Name of the Azure Key Vault to use.
+
+### `kestra.secret.azure-key-vault.keyVaultUri`
+Optionally you can provide the full Azure Key Vault url instead of its name.
+
+### `kestra.secret.azure-key-vault.prefix`
+Optional. All key handled by kestra will be prefixed with this. Can be useful to share the same secret manager between Kestra instances.

content/docs/09.administrator-guide/01.configuration/03.enterprise-edition/secrets/google-secret-manager/index.md

@@ -0,0 +1,27 @@
+---
+title: Google Secret Manager configuration
+---
+
+This integration will store secrets in [Google Secret Manager](https://cloud.google.com/secret-manager). Kestra authentication must have [roles/secretmanager.admin](https://cloud.google.com/secret-manager/docs/access-control) permission.
+
+## Authentication
+You can authenticate the Secrets Manager with Google Cloud in multiple ways:
+- By setting the `serviceAccount` property that must contain the contents of the service account JSON key file.
+- By setting the `GOOGLE_APPLICATION_CREDENTIALS` environment variable on the nodes (or server) running Kestra. It must point to a JSON credentials file. Keep in mind that you'd need to use the same variable on all worker nodes and that this authentication method can cause some security concerns.
+- If none is set, the default service account will be used.
+
+```yaml
+kestra:
+  secret:
+    google-secret-manager:
+      project: kestra-unit-test
+      serviceAccount: 'JSON content of the service account'
+```
+
+## Others configurations
+
+### `kestra.secret.google-secret-manager.project`
+Google Cloud project ID that Kestra will use.
+
+### `kestra.secret.google-secret-manager.prefix`
+Optional. All key handled by kestra will be prefixed with this. Can be useful to share the same secret manager between Kestra instances.