helm-external-secrets/search/search_index.json

{"config":{"lang":["en"],"prebuild_index":false,"separator":"[\\s\\-]+"},"docs":[{"location":"","text":"Introduction External Secrets Operator is a Kubernetes operator that integrates external secret management systems like AWS Secrets Manager , HashiCorp Vault , Google Secrets Manager , Azure Key Vault and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret . What is the goal of External Secrets Operator? The goal of External Secrets Operator is to synchronize secrets from external APIs into Kubernetes. ESO is a collection of custom API resources - ExternalSecret , SecretStore and ClusterSecretStore that provide a user-friendly abstraction for the external API that stores and manages the lifecycle of the secrets for you. Where to get started To get started, please read through API overview this should give you a high-level overview to understand the API and use-cases. After that please follow one of our guides to get a jump start using the operator. For a complete reference of the API types please refer to our API Reference . How to get involved This project is driven by it's users and contributors and we welcome everybody to get involved. Join our meetings, open issues or ask questions in Slack. The success of this project depends on your input: No contribution is too small - even opinions matter! How to get involved: Monthly Meeting: we announce our meetings on slack ( agenda ) Kubernetes Slack #external-secrets Contributing Process Kicked off by","title":"Introduction"},{"location":"#introduction","text":"External Secrets Operator is a Kubernetes operator that integrates external secret management systems like AWS Secrets Manager , HashiCorp Vault , Google Secrets Manager , Azure Key Vault and many more. The operator reads information from external APIs and automatically injects the values into a Kubernetes Secret .","title":"Introduction"},{"location":"#what-is-the-goal-of-external-secrets-operator","text":"The goal of External Secrets Operator is to synchronize secrets from external APIs into Kubernetes. ESO is a collection of custom API resources - ExternalSecret , SecretStore and ClusterSecretStore that provide a user-friendly abstraction for the external API that stores and manages the lifecycle of the secrets for you.","title":"What is the goal of External Secrets Operator?"},{"location":"#where-to-get-started","text":"To get started, please read through API overview this should give you a high-level overview to understand the API and use-cases. After that please follow one of our guides to get a jump start using the operator. For a complete reference of the API types please refer to our API Reference .","title":"Where to get started"},{"location":"#how-to-get-involved","text":"This project is driven by it's users and contributors and we welcome everybody to get involved. Join our meetings, open issues or ask questions in Slack. The success of this project depends on your input: No contribution is too small - even opinions matter! How to get involved: Monthly Meeting: we announce our meetings on slack ( agenda ) Kubernetes Slack #external-secrets Contributing Process","title":"How to get involved"},{"location":"#kicked-off-by","text":"","title":"Kicked off by"},{"location":"api-clustersecretstore/","text":"The ClusterSecretStore is a cluster scoped SecretStore that can be used by all ExternalSecrets from all namespaces unless you pin down its usage by using RBAC or Admission Control.","title":"ClusterSecretStore"},{"location":"api-externalsecret/","text":"The ExternalSecret describes what data should be fetched, how the data should be transformed and saved as a Kind=Secret : tells the operator what secrets should be synced by using spec.data to explicitly sync individual keys or use spec.dataFrom to get all values from the external API. you can specify how the secret should look like by specifying a spec.target.template Example Take a look at an annotated example to understand the design behind the ExternalSecret . apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : \"hello-world\" # labels and annotations are copied over to the # secret that will be created labels : acme.org/owned-by : \"q-team\" annotations : acme.org/sha : 1234 spec : # SecretStoreRef defines which SecretStore to use when fetching the secret data secretStoreRef : name : secret-store-name kind : SecretStore # or ClusterSecretStore # RefreshInterval is the amount of time before the values reading again from the SecretStore provider # Valid time units are \"ns\", \"us\" (or \"\u00b5s\"), \"ms\", \"s\", \"m\", \"h\" (from time.ParseDuration) # May be set to zero to fetch and create it once refreshInterval : \"1h\" # the target describes the secret that shall be created # there can only be one target per ExternalSecret target : # The secret name of the resource # Defaults to .metadata.name of the ExternalSecret # It is immutable name : my-secret # Enum with values: 'Owner', 'Merge', or 'None' # Default value of 'Owner' # Owner creates the secret and sets .metadata.ownerReferences of the resource # Merge does not create the secret, but merges in the data fields to the secret # None does not create a secret (future use with injector) creationPolicy : 'Merge' # Specify a blueprint for the resulting Kind=Secret template : type : kubernetes.io/dockerconfigjson # or TLS... metadata : annotations : {} labels : {} # Use inline templates to construct your desired config file that contains your secret data : config.yml : | endpoints: - https://{{ .data.user }}:{{ .data.password }}@api.exmaple.com # Uses an existing template from configmap # Secret is fetched, merged and templated within the referenced configMap data # It does not update the configmap, it creates a secret with: data[\"alertmanager.yml\"] = ...result... templateFrom : - configMap : name : alertmanager items : - key : alertmanager.yaml # Data defines the connection between the Kubernetes Secret keys and the Provider data data : - secretKey : secret-key-to-be-managed remoteRef : key : provider-key version : provider-key-version property : provider-key-property # Used to fetch all properties from the Provider key # If multiple dataFrom are specified, secrets are merged in the specified order dataFrom : - key : provider-key version : provider-key-version property : provider-key-property status : # refreshTime is the time and date the external secret was fetched and # the target secret updated refreshTime : \"2019-08-12T12:33:02Z\" # Standard condition schema conditions : # ExternalSecret ready condition indicates the secret is ready for use. # This is defined as: # - The target secret exists # - The target secret has been refreshed within the last refreshInterval # - The target secret content is up-to-date based on any target templates - type : Ready status : \"True\" # False if last refresh was not successful reason : \"SecretSynced\" message : \"Secret was synced\" lastTransitionTime : \"2019-08-12T12:33:02Z\"","title":"ExternalSecret"},{"location":"api-externalsecret/#example","text":"Take a look at an annotated example to understand the design behind the ExternalSecret . apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : \"hello-world\" # labels and annotations are copied over to the # secret that will be created labels : acme.org/owned-by : \"q-team\" annotations : acme.org/sha : 1234 spec : # SecretStoreRef defines which SecretStore to use when fetching the secret data secretStoreRef : name : secret-store-name kind : SecretStore # or ClusterSecretStore # RefreshInterval is the amount of time before the values reading again from the SecretStore provider # Valid time units are \"ns\", \"us\" (or \"\u00b5s\"), \"ms\", \"s\", \"m\", \"h\" (from time.ParseDuration) # May be set to zero to fetch and create it once refreshInterval : \"1h\" # the target describes the secret that shall be created # there can only be one target per ExternalSecret target : # The secret name of the resource # Defaults to .metadata.name of the ExternalSecret # It is immutable name : my-secret # Enum with values: 'Owner', 'Merge', or 'None' # Default value of 'Owner' # Owner creates the secret and sets .metadata.ownerReferences of the resource # Merge does not create the secret, but merges in the data fields to the secret # None does not create a secret (future use with injector) creationPolicy : 'Merge' # Specify a blueprint for the resulting Kind=Secret template : type : kubernetes.io/dockerconfigjson # or TLS... metadata : annotations : {} labels : {} # Use inline templates to construct your desired config file that contains your secret data : config.yml : | endpoints: - https://{{ .data.user }}:{{ .data.password }}@api.exmaple.com # Uses an existing template from configmap # Secret is fetched, merged and templated within the referenced configMap data # It does not update the configmap, it creates a secret with: data[\"alertmanager.yml\"] = ...result... templateFrom : - configMap : name : alertmanager items : - key : alertmanager.yaml # Data defines the connection between the Kubernetes Secret keys and the Provider data data : - secretKey : secret-key-to-be-managed remoteRef : key : provider-key version : provider-key-version property : provider-key-property # Used to fetch all properties from the Provider key # If multiple dataFrom are specified, secrets are merged in the specified order dataFrom : - key : provider-key version : provider-key-version property : provider-key-property status : # refreshTime is the time and date the external secret was fetched and # the target secret updated refreshTime : \"2019-08-12T12:33:02Z\" # Standard condition schema conditions : # ExternalSecret ready condition indicates the secret is ready for use. # This is defined as: # - The target secret exists # - The target secret has been refreshed within the last refreshInterval # - The target secret content is up-to-date based on any target templates - type : Ready status : \"True\" # False if last refresh was not successful reason : \"SecretSynced\" message : \"Secret was synced\" lastTransitionTime : \"2019-08-12T12:33:02Z\"","title":"Example"},{"location":"api-overview/","text":"API Overview Architecture The External Secrets Operator extends Kubernetes with Custom Resources , which define where secrets live and how to synchronize them. The controller fetches secrets from an external API and creates Kubernetes secrets . If the secret from the external API changes, the controller will reconcile the state in the cluster and update the secrets accordingly. Resource model To understand the mechanics of the operator let's start with the data model. The SecretStore references an bucket of key/value pairs. But because every external API is slightly different this bucket may be e.g. an instance of an Azure KeyVault or a AWS Secrets Manager in a certain AWS Account and region. Please take a look at the provider documentation to see what the Bucket actually maps to. SecretStore The idea behind the SecretStore resource is to separate concerns of authentication/access and the actual Secret and configuration needed for workloads. The ExternalSecret specifies what to fetch, the SecretStore specifies how to access. This resource is namespaced. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : secretstore-sample spec : controller : dev provider : aws : service : SecretsManager role : arn:aws:iam::123456789012:role/team-a-reader region : us-east-1 auth : secretRef : accessKeyIDSecretRef : name : awssm-secret key : access-key secretAccessKeySecretRef : name : awssm-secret key : secret-access-key The SecretStore contains references to secrets which hold credentials to access the external API. ExternalSecret An ExternalSecret declares what data to fetch. It has a reference to a SecretStore which knows how to access that data. The controller uses that ExternalSecret as a blueprint to create secrets. apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : refreshInterval : 1h secretStoreRef : name : secretstore-sample kind : SecretStore target : name : secret-to-be-created creationPolicy : Owner data : - secretKey : secret-key-to-be-managed remoteRef : key : provider-key version : provider-key-version property : provider-key-property dataFrom : - key : remote-key-in-the-provider ClusterSecretStore The ClusterSecretStore is just a global, cluster-wide SecretStore that can be referenced from all namespaces. Behavior The External Secret Operator (ESO for brevity) reconciles ExternalSecrets in the following manner: ESO uses spec.secretStoreRef to find an appropriate SecretStore . If it doesn't exist or the spec.controller field doesn't match it won't further process this ExternalSecret. ESO instanciates an external API client using the specified credentials from the SecretStore spec. ESO fetches the secrets as requested by the ExternalSecret , it will decode the secrets if required ESO creates an Kind=Secret based on the template provided by ExternalSecret.target.template . The Secret.data can be templated using the secret values from the external API. ESO ensures that the secret values stay in sync with the external API Roles and responsibilities The External Secret Operator is designed to target the following persona: Cluster Operator : The cluster operator is responsible for setting up the External Secret Operator, managing access policies and creating ClusterSecretStores. Application developer : The Application developer is responsible for defining ExternalSecrets and the application configuration Each persona will roughly map to a Kubernetes RBAC role. Depending on your environment these roles can map to a single user. Note: There is no Secret Operator that handles the lifecycle of the secret, this is out of the scope of ESO. Access Control The External Secrets Operator runs as a deployment in your cluster with elevated privileges. It will create/read/update secrets in all namespaces and has access to secrets stored in some external API. Ensure that the credentials you provide give ESO the least privilege necessary. Design your SecretStore / ClusterSecretStore carefully! Be sure to restrict access of application developers to read only certain keys in a shared environment. You should also consider using Kubernetes' admission control system (e.g. OPA or Kyverno ) for fine-grained access control. Running multiple Controller You can run multiple controller within the cluster. One controller can be limited to only process SecretStores with a predefined spec.controller field. Testers welcome This is not widely tested. Please help us test the setup and/or document use-cases.","title":"Overview"},{"location":"api-overview/#api-overview","text":"","title":"API Overview"},{"location":"api-overview/#architecture","text":"The External Secrets Operator extends Kubernetes with Custom Resources , which define where secrets live and how to synchronize them. The controller fetches secrets from an external API and creates Kubernetes secrets . If the secret from the external API changes, the controller will reconcile the state in the cluster and update the secrets accordingly.","title":"Architecture"},{"location":"api-overview/#resource-model","text":"To understand the mechanics of the operator let's start with the data model. The SecretStore references an bucket of key/value pairs. But because every external API is slightly different this bucket may be e.g. an instance of an Azure KeyVault or a AWS Secrets Manager in a certain AWS Account and region. Please take a look at the provider documentation to see what the Bucket actually maps to.","title":"Resource model"},{"location":"api-overview/#secretstore","text":"The idea behind the SecretStore resource is to separate concerns of authentication/access and the actual Secret and configuration needed for workloads. The ExternalSecret specifies what to fetch, the SecretStore specifies how to access. This resource is namespaced. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : secretstore-sample spec : controller : dev provider : aws : service : SecretsManager role : arn:aws:iam::123456789012:role/team-a-reader region : us-east-1 auth : secretRef : accessKeyIDSecretRef : name : awssm-secret key : access-key secretAccessKeySecretRef : name : awssm-secret key : secret-access-key The SecretStore contains references to secrets which hold credentials to access the external API.","title":"SecretStore"},{"location":"api-overview/#externalsecret","text":"An ExternalSecret declares what data to fetch. It has a reference to a SecretStore which knows how to access that data. The controller uses that ExternalSecret as a blueprint to create secrets. apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : refreshInterval : 1h secretStoreRef : name : secretstore-sample kind : SecretStore target : name : secret-to-be-created creationPolicy : Owner data : - secretKey : secret-key-to-be-managed remoteRef : key : provider-key version : provider-key-version property : provider-key-property dataFrom : - key : remote-key-in-the-provider","title":"ExternalSecret"},{"location":"api-overview/#clustersecretstore","text":"The ClusterSecretStore is just a global, cluster-wide SecretStore that can be referenced from all namespaces.","title":"ClusterSecretStore"},{"location":"api-overview/#behavior","text":"The External Secret Operator (ESO for brevity) reconciles ExternalSecrets in the following manner: ESO uses spec.secretStoreRef to find an appropriate SecretStore . If it doesn't exist or the spec.controller field doesn't match it won't further process this ExternalSecret. ESO instanciates an external API client using the specified credentials from the SecretStore spec. ESO fetches the secrets as requested by the ExternalSecret , it will decode the secrets if required ESO creates an Kind=Secret based on the template provided by ExternalSecret.target.template . The Secret.data can be templated using the secret values from the external API. ESO ensures that the secret values stay in sync with the external API","title":"Behavior"},{"location":"api-overview/#roles-and-responsibilities","text":"The External Secret Operator is designed to target the following persona: Cluster Operator : The cluster operator is responsible for setting up the External Secret Operator, managing access policies and creating ClusterSecretStores. Application developer : The Application developer is responsible for defining ExternalSecrets and the application configuration Each persona will roughly map to a Kubernetes RBAC role. Depending on your environment these roles can map to a single user. Note: There is no Secret Operator that handles the lifecycle of the secret, this is out of the scope of ESO.","title":"Roles and responsibilities"},{"location":"api-overview/#access-control","text":"The External Secrets Operator runs as a deployment in your cluster with elevated privileges. It will create/read/update secrets in all namespaces and has access to secrets stored in some external API. Ensure that the credentials you provide give ESO the least privilege necessary. Design your SecretStore / ClusterSecretStore carefully! Be sure to restrict access of application developers to read only certain keys in a shared environment. You should also consider using Kubernetes' admission control system (e.g. OPA or Kyverno ) for fine-grained access control.","title":"Access Control"},{"location":"api-overview/#running-multiple-controller","text":"You can run multiple controller within the cluster. One controller can be limited to only process SecretStores with a predefined spec.controller field. Testers welcome This is not widely tested. Please help us test the setup and/or document use-cases.","title":"Running multiple Controller"},{"location":"api-secretstore/","text":"The SecretStore is namespaced and specifies how to access the external API. The SecretStore maps to exactly one instance of an external API. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : example namespace : example-ns spec : # Used to select the correct ESO controller (think: ingress.ingressClassName) # The ESO controller is instantiated with a specific controller name # and filters ES based on this property # Optional controller : dev # provider field contains the configuration to access the provider # which contains the secret exactly one provider must be configured. provider : # (1): AWS Secrets Manager # aws configures this store to sync secrets using AWS Secret Manager provider aws : service : SecretsManager # Role is a Role ARN which the SecretManager provider will assume role : iam-role # AWS Region to be used for the provider region : eu-central-1 # Auth defines the information necessary to authenticate against AWS by # getting the accessKeyID and secretAccessKey from an already created Kubernetes Secret auth : secretRef : accessKeyID : name : awssm-secret key : access-key secretAccessKey : name : awssm-secret key : secret-access-key vault : server : \"https://vault.acme.org\" # Path is the mount path of the Vault KV backend endpoint path : \"secret\" # Version is the Vault KV secret engine version. # This can be either \"v1\" or \"v2\", defaults to \"v2\" version : \"v2\" # vault enterprise namespace: https://www.vaultproject.io/docs/enterprise/namespaces namespace : \"a-team\" caBundle : \"...\" auth : # static token: https://www.vaultproject.io/docs/auth/token tokenSecretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"vault-token\" # AppRole auth: https://www.vaultproject.io/docs/auth/approle appRole : path : \"approle\" roleId : \"db02de05-fa39-4855-059b-67221c5c2f63\" secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"vault-token\" # Kubernetes auth: https://www.vaultproject.io/docs/auth/kubernetes kubernetes : mountPath : \"kubernetes\" role : \"demo\" # Optional service account reference serviceAccountRef : name : \"my-sa\" namespace : \"secret-admin\" # Optional secret field containing a Kubernetes ServiceAccount JWT # used for authenticating with Vault secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"vault\" # (2): GCP Secret Manager gcpsm : # Auth defines the information necessary to authenticate against GCP by getting # the credentials from an already created Kubernetes Secret. auth : secretRef : secretAccessKeySecretRef : name : gcpsm-secret key : secret-access-credentials projectID : myproject # (TODO): add more provider examples here status : # Standard condition schema conditions : # SecretStore ready condition indicates the given store is in ready # state and able to referenced by ExternalSecrets # If the `status` of this condition is `False`, ExternalSecret controllers # should prevent attempts to fetch secrets - type : Ready status : \"False\" reason : \"ConfigError\" message : \"SecretStore validation failed\" lastTransitionTime : \"2019-08-12T12:33:02Z\"","title":"SecretStore"},{"location":"contributing-coc/","text":"Code of Conduct Our Pledge We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community. Our Standards Examples of behavior that contributes to a positive environment for our community include: Demonstrating empathy and kindness toward other people Being respectful of differing opinions, viewpoints, and experiences Giving and gracefully accepting constructive feedback Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience Focusing on what is best not just for us as individuals, but for the overall community Examples of unacceptable behavior include: The use of sexualized language or imagery, and sexual attention or advances of any kind Trolling, insulting or derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or email address, without their explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting Enforcement Responsibilities Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate. Scope This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at contact@external-secrets.io. All complaints will be reviewed and investigated promptly and fairly. All community leaders are obligated to respect the privacy and security of the reporter of any incident. Enforcement Guidelines Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct: 1. Correction Community Impact : Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. Consequence : A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested. 2. Warning Community Impact : A violation through a single incident or series of actions. Consequence : A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban. 3. Temporary Ban Community Impact : A serious violation of community standards, including sustained inappropriate behavior. Consequence : A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban. 4. Permanent Ban Community Impact : Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. Consequence : A permanent ban from any sort of public interaction within the community. Attribution This Code of Conduct is adapted from the Contributor Covenant , version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html . Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder . For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq . Translations are available at https://www.contributor-covenant.org/translations .","title":"Code of Conduct"},{"location":"contributing-coc/#code-of-conduct","text":"","title":"Code of Conduct"},{"location":"contributing-coc/#our-pledge","text":"We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation. We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.","title":"Our Pledge"},{"location":"contributing-coc/#our-standards","text":"Examples of behavior that contributes to a positive environment for our community include: Demonstrating empathy and kindness toward other people Being respectful of differing opinions, viewpoints, and experiences Giving and gracefully accepting constructive feedback Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience Focusing on what is best not just for us as individuals, but for the overall community Examples of unacceptable behavior include: The use of sexualized language or imagery, and sexual attention or advances of any kind Trolling, insulting or derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or email address, without their explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting","title":"Our Standards"},{"location":"contributing-coc/#enforcement-responsibilities","text":"Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful. Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.","title":"Enforcement Responsibilities"},{"location":"contributing-coc/#scope","text":"This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.","title":"Scope"},{"location":"contributing-coc/#enforcement","text":"Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at contact@external-secrets.io. All complaints will be reviewed and investigated promptly and fairly. All community leaders are obligated to respect the privacy and security of the reporter of any incident.","title":"Enforcement"},{"location":"contributing-coc/#enforcement-guidelines","text":"Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:","title":"Enforcement Guidelines"},{"location":"contributing-coc/#1-correction","text":"Community Impact : Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community. Consequence : A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.","title":"1. Correction"},{"location":"contributing-coc/#2-warning","text":"Community Impact : A violation through a single incident or series of actions. Consequence : A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.","title":"2. Warning"},{"location":"contributing-coc/#3-temporary-ban","text":"Community Impact : A serious violation of community standards, including sustained inappropriate behavior. Consequence : A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.","title":"3. Temporary Ban"},{"location":"contributing-coc/#4-permanent-ban","text":"Community Impact : Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals. Consequence : A permanent ban from any sort of public interaction within the community.","title":"4. Permanent Ban"},{"location":"contributing-coc/#attribution","text":"This Code of Conduct is adapted from the Contributor Covenant , version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html . Community Impact Guidelines were inspired by Mozilla's code of conduct enforcement ladder . For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq . Translations are available at https://www.contributor-covenant.org/translations .","title":"Attribution"},{"location":"contributing-devguide/","text":"Getting Started You must have a working Go environment and then clone the repo: git clone https://github.com/external-secrets/external-secrets.git cd external-secrets Building & Testing The project uses the make build system. It'll run code generators, tests and static code analysis. Building the operator binary and docker image: make build make docker.build IMG = external-secrets:latest Run tests and lint the code: make test make lint Build the documentation: make docs Installing To install the External Secret Operator's CRDs into a Kubernetes Cluster run: make crds.install Apply the sample resources: kubectl apply -f docs/snippets/basic-secret-store.yaml kubectl apply -f docs/snippets/basic-external-secret.yaml You can run the controller on your host system for development purposes: make run To remove the CRDs run: make crds.uninstall Contributing Flow The HOW TO guide for contributing is at the Contributing Process page. Documentation We use mkdocs material to generate this documentation. See /docs for the source code and /hack/api-docs for the build process. When writing documentation it is advised to run the mkdocs server with livereload: make serve-docs Run the following command to run a complete build. The rendered assets are available under /site . make docs make serve-docs Open http://localhost:8000 in your browser.","title":"Developer guide"},{"location":"contributing-devguide/#getting-started","text":"You must have a working Go environment and then clone the repo: git clone https://github.com/external-secrets/external-secrets.git cd external-secrets","title":"Getting Started"},{"location":"contributing-devguide/#building-testing","text":"The project uses the make build system. It'll run code generators, tests and static code analysis. Building the operator binary and docker image: make build make docker.build IMG = external-secrets:latest Run tests and lint the code: make test make lint Build the documentation: make docs","title":"Building &amp; Testing"},{"location":"contributing-devguide/#installing","text":"To install the External Secret Operator's CRDs into a Kubernetes Cluster run: make crds.install Apply the sample resources: kubectl apply -f docs/snippets/basic-secret-store.yaml kubectl apply -f docs/snippets/basic-external-secret.yaml You can run the controller on your host system for development purposes: make run To remove the CRDs run: make crds.uninstall Contributing Flow The HOW TO guide for contributing is at the Contributing Process page.","title":"Installing"},{"location":"contributing-devguide/#documentation","text":"We use mkdocs material to generate this documentation. See /docs for the source code and /hack/api-docs for the build process. When writing documentation it is advised to run the mkdocs server with livereload: make serve-docs Run the following command to run a complete build. The rendered assets are available under /site . make docs make serve-docs Open http://localhost:8000 in your browser.","title":"Documentation"},{"location":"contributing-process/","text":"Project Management The Code, our TODOs and Documentation is maintained on GitHub . All Issues should be opened in that repository. Issues Features, bugs and any issues regarding the documentation should be filed as GitHub Issue in our repository. We use labels like kind/feature , kind/bug , area/aws to organize the issues. Issues labeled good first issue and help wanted are especially good for a first contribution. If you want to pick up an issue just leave a comment. Submitting a Pull Request This project uses the well-known pull request process from GitHub. To submit a pull request, fork the repository and push any changes to a branch on the copy, from there a pull request can be made in the main repo. Merging a pull request requires the following steps to be completed before the pull request will be merged: ideally, there is an issue that documents the problem or feature in depth. code must have a reasonable amount of test coverage tests must pass PR needs be reviewed and approved Once these steps are completed the PR will be merged by a code owner. Cutting Releases As of now this project is in an early alpha phase. There is just the main branch ;)","title":"Contributing Process"},{"location":"contributing-process/#project-management","text":"The Code, our TODOs and Documentation is maintained on GitHub . All Issues should be opened in that repository.","title":"Project Management"},{"location":"contributing-process/#issues","text":"Features, bugs and any issues regarding the documentation should be filed as GitHub Issue in our repository. We use labels like kind/feature , kind/bug , area/aws to organize the issues. Issues labeled good first issue and help wanted are especially good for a first contribution. If you want to pick up an issue just leave a comment.","title":"Issues"},{"location":"contributing-process/#submitting-a-pull-request","text":"This project uses the well-known pull request process from GitHub. To submit a pull request, fork the repository and push any changes to a branch on the copy, from there a pull request can be made in the main repo. Merging a pull request requires the following steps to be completed before the pull request will be merged: ideally, there is an issue that documents the problem or feature in depth. code must have a reasonable amount of test coverage tests must pass PR needs be reviewed and approved Once these steps are completed the PR will be merged by a code owner.","title":"Submitting a Pull Request"},{"location":"contributing-process/#cutting-releases","text":"As of now this project is in an early alpha phase. There is just the main branch ;)","title":"Cutting Releases"},{"location":"guides-getting-started/","text":"Getting started External-secrets runs within your Kubernetes cluster as a deployment resource. It utilizes CustomResourceDefinitions to configure access to secret providers through SecretStore resources and manages Kubernetes secret resources with ExternalSecret resources. Note: The minimum supported version of Kubernetes is 1.16.0 . Users still running Kubernetes v1.15 or below should upgrade to a supported version before installing external-secrets. Installing with Helm To automatically install and manage the CRDs as part of your Helm release, you must add the --set installCRDs=true flag to your Helm installation command. Uncomment the relevant line in the next steps to enable this. Option 1: Install from chart repository helm repo add external-secrets https://charts.external-secrets.io helm install external-secrets \\ external-secrets/external-secrets \\ -n external-secrets \\ --create-namespace \\ # --set installCRDs=true Option 2: Install chart from local build Build and install the Helm chart locally after cloning the repository. make helm.build helm install external-secrets \\ ./bin/chart/external-secrets.tgz \\ -n external-secrets \\ --create-namespace \\ # --set installCRDs=true Create a secret containing your AWS credentials echo -n 'KEYID' > ./access-key echo -n 'SECRETKEY' > ./secret-access-key kubectl create secret generic awssm-secret --from-file = ./access-key --from-file = ./secret-access-key Create your first SecretStore apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : secretstore-sample spec : controller : dev provider : aws : service : SecretsManager role : arn:aws:iam::123456789012:role/team-a-reader region : us-east-1 auth : secretRef : accessKeyIDSecretRef : name : awssm-secret key : access-key secretAccessKeySecretRef : name : awssm-secret key : secret-access-key Create your first ExternalSecret apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : refreshInterval : 1h secretStoreRef : name : secretstore-sample kind : SecretStore target : name : secret-to-be-created creationPolicy : Owner data : - secretKey : secret-key-to-be-managed remoteRef : key : provider-key version : provider-key-version property : provider-key-property dataFrom : - key : remote-key-in-the-provider kubectl describe externalsecret example # [...] Name: example Status: Conditions: Last Transition Time: 2021 -02-24T16:45:23Z Message: Secret was synced Reason: SecretSynced Status: True Type: Ready Refresh Time: 2021 -02-24T16:45:24Z Events: <none> For more advanced examples, please read the other guides . Uninstalling Before continuing, ensure that all external-secret resources that have been created by users have been deleted. You can check for any existing resources with the following command: kubectl get SecretStores,ClusterSecretStores,ExternalSecrets --all-namespaces Once all these resources have been deleted you are ready to uninstall external-secrets. Uninstalling with Helm Uninstall the helm release using the delete command. helm delete external-secrets --namespace external-secrets","title":"Getting started"},{"location":"guides-getting-started/#getting-started","text":"External-secrets runs within your Kubernetes cluster as a deployment resource. It utilizes CustomResourceDefinitions to configure access to secret providers through SecretStore resources and manages Kubernetes secret resources with ExternalSecret resources. Note: The minimum supported version of Kubernetes is 1.16.0 . Users still running Kubernetes v1.15 or below should upgrade to a supported version before installing external-secrets.","title":"Getting started"},{"location":"guides-getting-started/#installing-with-helm","text":"To automatically install and manage the CRDs as part of your Helm release, you must add the --set installCRDs=true flag to your Helm installation command. Uncomment the relevant line in the next steps to enable this.","title":"Installing with Helm"},{"location":"guides-getting-started/#option-1-install-from-chart-repository","text":"helm repo add external-secrets https://charts.external-secrets.io helm install external-secrets \\ external-secrets/external-secrets \\ -n external-secrets \\ --create-namespace \\ # --set installCRDs=true","title":"Option 1: Install from chart repository"},{"location":"guides-getting-started/#option-2-install-chart-from-local-build","text":"Build and install the Helm chart locally after cloning the repository. make helm.build helm install external-secrets \\ ./bin/chart/external-secrets.tgz \\ -n external-secrets \\ --create-namespace \\ # --set installCRDs=true","title":"Option 2: Install chart from local build"},{"location":"guides-getting-started/#create-a-secret-containing-your-aws-credentials","text":"echo -n 'KEYID' > ./access-key echo -n 'SECRETKEY' > ./secret-access-key kubectl create secret generic awssm-secret --from-file = ./access-key --from-file = ./secret-access-key","title":"Create a secret containing your AWS credentials"},{"location":"guides-getting-started/#create-your-first-secretstore","text":"apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : secretstore-sample spec : controller : dev provider : aws : service : SecretsManager role : arn:aws:iam::123456789012:role/team-a-reader region : us-east-1 auth : secretRef : accessKeyIDSecretRef : name : awssm-secret key : access-key secretAccessKeySecretRef : name : awssm-secret key : secret-access-key","title":"Create your first SecretStore"},{"location":"guides-getting-started/#create-your-first-externalsecret","text":"apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : refreshInterval : 1h secretStoreRef : name : secretstore-sample kind : SecretStore target : name : secret-to-be-created creationPolicy : Owner data : - secretKey : secret-key-to-be-managed remoteRef : key : provider-key version : provider-key-version property : provider-key-property dataFrom : - key : remote-key-in-the-provider kubectl describe externalsecret example # [...] Name: example Status: Conditions: Last Transition Time: 2021 -02-24T16:45:23Z Message: Secret was synced Reason: SecretSynced Status: True Type: Ready Refresh Time: 2021 -02-24T16:45:24Z Events: <none> For more advanced examples, please read the other guides .","title":"Create your first ExternalSecret"},{"location":"guides-getting-started/#uninstalling","text":"Before continuing, ensure that all external-secret resources that have been created by users have been deleted. You can check for any existing resources with the following command: kubectl get SecretStores,ClusterSecretStores,ExternalSecrets --all-namespaces Once all these resources have been deleted you are ready to uninstall external-secrets.","title":"Uninstalling"},{"location":"guides-getting-started/#uninstalling-with-helm","text":"Uninstall the helm release using the delete command. helm delete external-secrets --namespace external-secrets","title":"Uninstalling with Helm"},{"location":"guides-introduction/","text":"Guides The following guides demonstrate use-cases and provide examples of how to use the API. Please pick one of the following guides: Getting started Advanced Templating Multi-Tenancy Design Considerations","title":"Introduction"},{"location":"guides-introduction/#guides","text":"The following guides demonstrate use-cases and provide examples of how to use the API. Please pick one of the following guides: Getting started Advanced Templating Multi-Tenancy Design Considerations","title":"Guides"},{"location":"guides-metrics/","text":"Metrics The External Secrets Operator exposes its Prometheus metrics in the /metrics path. To enable it, set the prometheus.enabled Helm flag to true . The Operator has the metrics inherited from Kubebuilder plus some custom metrics with the external_secret prefix.","title":"Metrics"},{"location":"guides-metrics/#metrics","text":"The External Secrets Operator exposes its Prometheus metrics in the /metrics path. To enable it, set the prometheus.enabled Helm flag to true . The Operator has the metrics inherited from Kubebuilder plus some custom metrics with the external_secret prefix.","title":"Metrics"},{"location":"guides-multi-tenancy/","text":"External Secrets Operator provides different modes of operation to fulfill ogranizational needs. This guide outlines the flexibility of ESO and should give you a first impression of how you can employ this operator in your organization. For a multi-tenant deployment you should first examine your organizational structure: what roles (i.e. Application Developers , Cluster Admins , ...) do you have in your organization, what responsibilities do they have and how does that map to Kubernetes RBAC roles. Further, you should examine how your external API provider manages access control for your secrets. Can you limit access by secret names (e.g. db/dev/* )? Or only on a bucket level? Please keep in mind that not all external APIs provide fine-grained access management for secrets. Note: The following examples should not be considered as best practice but rather as a example to show how to combine different mechanics and techniques for tenant isolation. Shared ClusterSecretStore A Cluster Administrator deploys a ClusterSecretStore (CSS) and manages access to the external API. The CSS is shared by all tenants within the cluster. Application Developers do reference it in a ExternalSecret but can not create a ClusterSecretStores or SecretStores on their own. Now all application developers have access to all the secrets. You probably want to limit access to certain keys or prefixes that should be used. ESO does not provide a mechanic to limit access to certain keys per namespace. More advanced validation should be done with an Admission Webhook, e.g. with Kyverno or Open Policy Agent ). This setup suites well if you have one central bucket that contains all of your secrets and your Cluster Administrators should manage access to it. This setup is very simple but does not scale very well. Managed SecretStore per Namespace Cluster Administrators manage one or multipe SecretStores per Namespace. Each SecretStore uses it's own role that limits access to a small set of keys. The peculiarity of this is approach is, that access is actually managed by the external API which provides the roles. The Cluster Administrator does just the wiring. This approach may be desirable if you have an external entity - let's call it Secret Administrator - that manages access and lifecycle of the secrets. ESO as a Service Every namespace is self-contained. Application developers manage SecretStore , ExternalSecret and secret infrastructure on their own. Cluster Administrators just provide the External Secrets Operator as a service. This makes sense if application developers should be completely autonomous while a central team provides common services.","title":"Multi Tenancy"},{"location":"guides-multi-tenancy/#shared-clustersecretstore","text":"A Cluster Administrator deploys a ClusterSecretStore (CSS) and manages access to the external API. The CSS is shared by all tenants within the cluster. Application Developers do reference it in a ExternalSecret but can not create a ClusterSecretStores or SecretStores on their own. Now all application developers have access to all the secrets. You probably want to limit access to certain keys or prefixes that should be used. ESO does not provide a mechanic to limit access to certain keys per namespace. More advanced validation should be done with an Admission Webhook, e.g. with Kyverno or Open Policy Agent ). This setup suites well if you have one central bucket that contains all of your secrets and your Cluster Administrators should manage access to it. This setup is very simple but does not scale very well.","title":"Shared ClusterSecretStore"},{"location":"guides-multi-tenancy/#managed-secretstore-per-namespace","text":"Cluster Administrators manage one or multipe SecretStores per Namespace. Each SecretStore uses it's own role that limits access to a small set of keys. The peculiarity of this is approach is, that access is actually managed by the external API which provides the roles. The Cluster Administrator does just the wiring. This approach may be desirable if you have an external entity - let's call it Secret Administrator - that manages access and lifecycle of the secrets.","title":"Managed SecretStore per Namespace"},{"location":"guides-multi-tenancy/#eso-as-a-service","text":"Every namespace is self-contained. Application developers manage SecretStore , ExternalSecret and secret infrastructure on their own. Cluster Administrators just provide the External Secrets Operator as a service. This makes sense if application developers should be completely autonomous while a central team provides common services.","title":"ESO as a Service"},{"location":"guides-templating/","text":"With External Secrets Operator you can transform the data from the external secret provider before it is stored as Kind=Secret . You can do this with the Spec.Target.Template . Each data value is interpreted as a golang template . Examples You can use templates to inject your secrets into a configuration file that you mount into your pod: apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : template spec : refreshInterval : 1h secretStoreRef : name : secretstore-sample kind : SecretStore target : name : secret-to-be-created # this is how the Kind=Secret will look like template : type : kubernetes.io/tls data : # multiline string config : | datasources: - name: Graphite type: graphite access: proxy url: http://localhost:8080 password: \"{{ .password | toString }}\" # <-- convert []byte to string user: \"{{ .user | toString }}\" # <-- convert []byte to string data : - secretKey : user remoteRef : key : /grafana/user - secretKey : password remoteRef : key : /grafana/password You can also use pre-defined functions to extract data from your secrets. Here: extract key/cert from a pkcs12 archive and store it as PEM. apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : template spec : refreshInterval : 1h secretStoreRef : name : secretstore-sample kind : SecretStore target : name : secret-to-be-created # this is how the Kind=Secret will look like template : type : kubernetes.io/tls data : tls.crt : \"{{ .mysecret | pkcs12cert | pemCertificate }}\" tls.key : \"{{ .mysecret | pkcs12key | pemPrivateKey }}\" data : # this is a pkcs12 archive that contains # a cert and a private key - secretKey : mysecret remoteRef : key : example Helper functions We provide a bunch of convenience functions that help you transform your secrets. A secret value is a []byte . Function Description Input Output pkcs12key extracts the private key from a pkcs12 archive []byte []byte pkcs12keyPass extracts the private key from a pkcs12 archive using the provided password password string , data []byte []byte pkcs12cert extracts the certificate from a pkcs12 archive []byte []byte pkcs12certPass extracts the certificate from a pkcs12 archive using the provided password password string , data []byte []byte pemPrivateKey PEM encodes the provided bytes as private key []byte string pemCertificate PEM encodes the provided bytes as certificate []byte string base64decode decodes the provided bytes as base64 []byte []byte base64encode encodes the provided bytes as base64 []byte []byte fromJSON parses the bytes as JSON so you can access individual properties []byte interface{} toJSON encodes the provided object as json string interface{} string toString converts bytes to string []byte string toBytes converts string to bytes string []byte upper converts all characters to their upper case string string lower converts all character to their lower case string string","title":"Advanced Templating"},{"location":"guides-templating/#examples","text":"You can use templates to inject your secrets into a configuration file that you mount into your pod: apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : template spec : refreshInterval : 1h secretStoreRef : name : secretstore-sample kind : SecretStore target : name : secret-to-be-created # this is how the Kind=Secret will look like template : type : kubernetes.io/tls data : # multiline string config : | datasources: - name: Graphite type: graphite access: proxy url: http://localhost:8080 password: \"{{ .password | toString }}\" # <-- convert []byte to string user: \"{{ .user | toString }}\" # <-- convert []byte to string data : - secretKey : user remoteRef : key : /grafana/user - secretKey : password remoteRef : key : /grafana/password You can also use pre-defined functions to extract data from your secrets. Here: extract key/cert from a pkcs12 archive and store it as PEM. apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : template spec : refreshInterval : 1h secretStoreRef : name : secretstore-sample kind : SecretStore target : name : secret-to-be-created # this is how the Kind=Secret will look like template : type : kubernetes.io/tls data : tls.crt : \"{{ .mysecret | pkcs12cert | pemCertificate }}\" tls.key : \"{{ .mysecret | pkcs12key | pemPrivateKey }}\" data : # this is a pkcs12 archive that contains # a cert and a private key - secretKey : mysecret remoteRef : key : example","title":"Examples"},{"location":"guides-templating/#helper-functions","text":"We provide a bunch of convenience functions that help you transform your secrets. A secret value is a []byte . Function Description Input Output pkcs12key extracts the private key from a pkcs12 archive []byte []byte pkcs12keyPass extracts the private key from a pkcs12 archive using the provided password password string , data []byte []byte pkcs12cert extracts the certificate from a pkcs12 archive []byte []byte pkcs12certPass extracts the certificate from a pkcs12 archive using the provided password password string , data []byte []byte pemPrivateKey PEM encodes the provided bytes as private key []byte string pemCertificate PEM encodes the provided bytes as certificate []byte string base64decode decodes the provided bytes as base64 []byte []byte base64encode encodes the provided bytes as base64 []byte []byte fromJSON parses the bytes as JSON so you can access individual properties []byte interface{} toJSON encodes the provided object as json string interface{} string toString converts bytes to string []byte string toBytes converts string to bytes string []byte upper converts all characters to their upper case string string lower converts all character to their lower case string string","title":"Helper functions"},{"location":"provider-aws-parameter-store/","text":"Parameter Store A ParameterStore points to AWS SSM Parameter Store in a certain account within a defined region. You should define Roles that define fine-grained access to individual secrets and pass them to ESO using spec.provider.aws.role . This way users of the SecretStore can only access the secrets necessary. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : secretstore-sample spec : controller : dev provider : aws : service : ParameterStore # define a specific role to limit access # to certain secrets role : iam-role region : eu-central-1 auth : secretRef : accessKeyIDSecretRef : name : awssm-secret key : access-key secretAccessKeySecretRef : name : awssm-secret key : secret-access-key API Pricing & Throttling The SSM Parameter Store API is charged by throughput and is available in different tiers, see pricing . Please estimate your costs before using ESO. Cost depends on the RefreshInterval of your ExternalSecrets. IAM Policy Create a IAM Policy to pin down access to secrets matching dev-* , for futher information see AWS Documentation : { \"Version\" : \"2012-10-17\" , \"Statement\" : [ { \"Effect\" : \"Deny\" , \"Action\" : [ \"ssm:GetParameter*\" ], \"Resource\" : \"arn:aws:ssm:us-east-2:123456789012:parameter/dev-*\" } ] } JSON Secret Values You can store JSON objects in a parameter. You can access nested values or arrays using gjson syntax : Consider the following JSON object that is stored in the Parameter Store key my-json-secret : { \"name\" : { \"first\" : \"Tom\" , \"last\" : \"Anderson\" }, \"friends\" : [ { \"first\" : \"Dale\" , \"last\" : \"Murphy\" }, { \"first\" : \"Roger\" , \"last\" : \"Craig\" }, { \"first\" : \"Jane\" , \"last\" : \"Murphy\" } ] } This is an example on how you would look up nested keys in the above json object: apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : # [omitted for brevity] data : - secretKey : firstname remoteRef : key : my-json-secret property : name.first # Tom - secretKey : first_friend remoteRef : key : my-json-secret property : friends.1.first # Roger AWS Authentication Access to AWS providers can be granted in various ways: IRSA : IAM roles for service accounts. Per pod IAM authentication: kiam or kube2iam . Directly provide AWS credentials to the External Secrets Operator pod by using environment variables. Additionally, before fetching a secret from a store, ESO is able to assume role (as a proxy so to speak). It is advisable to use multiple roles in a multi-tenant environment.","title":"Parameter Store"},{"location":"provider-aws-parameter-store/#parameter-store","text":"A ParameterStore points to AWS SSM Parameter Store in a certain account within a defined region. You should define Roles that define fine-grained access to individual secrets and pass them to ESO using spec.provider.aws.role . This way users of the SecretStore can only access the secrets necessary. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : secretstore-sample spec : controller : dev provider : aws : service : ParameterStore # define a specific role to limit access # to certain secrets role : iam-role region : eu-central-1 auth : secretRef : accessKeyIDSecretRef : name : awssm-secret key : access-key secretAccessKeySecretRef : name : awssm-secret key : secret-access-key API Pricing & Throttling The SSM Parameter Store API is charged by throughput and is available in different tiers, see pricing . Please estimate your costs before using ESO. Cost depends on the RefreshInterval of your ExternalSecrets.","title":"Parameter Store"},{"location":"provider-aws-parameter-store/#iam-policy","text":"Create a IAM Policy to pin down access to secrets matching dev-* , for futher information see AWS Documentation : { \"Version\" : \"2012-10-17\" , \"Statement\" : [ { \"Effect\" : \"Deny\" , \"Action\" : [ \"ssm:GetParameter*\" ], \"Resource\" : \"arn:aws:ssm:us-east-2:123456789012:parameter/dev-*\" } ] }","title":"IAM Policy"},{"location":"provider-aws-parameter-store/#json-secret-values","text":"You can store JSON objects in a parameter. You can access nested values or arrays using gjson syntax : Consider the following JSON object that is stored in the Parameter Store key my-json-secret : { \"name\" : { \"first\" : \"Tom\" , \"last\" : \"Anderson\" }, \"friends\" : [ { \"first\" : \"Dale\" , \"last\" : \"Murphy\" }, { \"first\" : \"Roger\" , \"last\" : \"Craig\" }, { \"first\" : \"Jane\" , \"last\" : \"Murphy\" } ] } This is an example on how you would look up nested keys in the above json object: apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : # [omitted for brevity] data : - secretKey : firstname remoteRef : key : my-json-secret property : name.first # Tom - secretKey : first_friend remoteRef : key : my-json-secret property : friends.1.first # Roger","title":"JSON Secret Values"},{"location":"provider-aws-parameter-store/#aws-authentication","text":"Access to AWS providers can be granted in various ways: IRSA : IAM roles for service accounts. Per pod IAM authentication: kiam or kube2iam . Directly provide AWS credentials to the External Secrets Operator pod by using environment variables. Additionally, before fetching a secret from a store, ESO is able to assume role (as a proxy so to speak). It is advisable to use multiple roles in a multi-tenant environment.","title":"AWS Authentication"},{"location":"provider-aws-secrets-manager/","text":"Secrets Manager A SecretStore points to AWS Secrets Manager in a certain account within a defined region. You should define Roles that define fine-grained access to individual secrets and pass them to ESO using spec.provider.aws.role . This way users of the SecretStore can only access the secrets necessary. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : secretstore-sample spec : controller : dev provider : aws : service : SecretsManager # define a specific role to limit access # to certain secrets role : iam-role region : eu-central-1 auth : secretRef : accessKeyIDSecretRef : name : awssm-secret key : access-key secretAccessKeySecretRef : name : awssm-secret key : secret-access-key IAM Policy Create a IAM Policy to pin down access to secrets matching dev-* . { \"Version\" : \"2012-10-17\" , \"Statement\" : [ { \"Effect\" : \"Allow\" , \"Action\" : [ \"secretsmanager:GetResourcePolicy\" , \"secretsmanager:GetSecretValue\" , \"secretsmanager:DescribeSecret\" , \"secretsmanager:ListSecretVersionIds\" ], \"Resource\" : [ \"arn:aws:secretsmanager:us-west-2:111122223333:secret:dev-*\" , ] } ] } JSON Secret Values SecretsManager supports simple key/value pairs that are stored as json. If you use the API you can store more complex JSON objects. You can access nested values or arrays using gjson syntax : Consider the following JSON object that is stored in the SecretsManager key my-json-secret : { \"name\" : { \"first\" : \"Tom\" , \"last\" : \"Anderson\" }, \"friends\" : [ { \"first\" : \"Dale\" , \"last\" : \"Murphy\" }, { \"first\" : \"Roger\" , \"last\" : \"Craig\" }, { \"first\" : \"Jane\" , \"last\" : \"Murphy\" } ] } This is an example on how you would look up nested keys in the above json object: apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : # [omitted for brevity] data : - secretKey : firstname remoteRef : key : my-json-secret property : name.first # Tom - secretKey : first_friend remoteRef : key : my-json-secret property : friends.1.first # Roger AWS Authentication Access to AWS providers can be granted in various ways: IRSA : IAM roles for service accounts. Per pod IAM authentication: kiam or kube2iam . Directly provide AWS credentials to the External Secrets Operator pod by using environment variables. Additionally, before fetching a secret from a store, ESO is able to assume role (as a proxy so to speak). It is advisable to use multiple roles in a multi-tenant environment.","title":"Secrets Manager"},{"location":"provider-aws-secrets-manager/#secrets-manager","text":"A SecretStore points to AWS Secrets Manager in a certain account within a defined region. You should define Roles that define fine-grained access to individual secrets and pass them to ESO using spec.provider.aws.role . This way users of the SecretStore can only access the secrets necessary. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : secretstore-sample spec : controller : dev provider : aws : service : SecretsManager # define a specific role to limit access # to certain secrets role : iam-role region : eu-central-1 auth : secretRef : accessKeyIDSecretRef : name : awssm-secret key : access-key secretAccessKeySecretRef : name : awssm-secret key : secret-access-key","title":"Secrets Manager"},{"location":"provider-aws-secrets-manager/#iam-policy","text":"Create a IAM Policy to pin down access to secrets matching dev-* . { \"Version\" : \"2012-10-17\" , \"Statement\" : [ { \"Effect\" : \"Allow\" , \"Action\" : [ \"secretsmanager:GetResourcePolicy\" , \"secretsmanager:GetSecretValue\" , \"secretsmanager:DescribeSecret\" , \"secretsmanager:ListSecretVersionIds\" ], \"Resource\" : [ \"arn:aws:secretsmanager:us-west-2:111122223333:secret:dev-*\" , ] } ] }","title":"IAM Policy"},{"location":"provider-aws-secrets-manager/#json-secret-values","text":"SecretsManager supports simple key/value pairs that are stored as json. If you use the API you can store more complex JSON objects. You can access nested values or arrays using gjson syntax : Consider the following JSON object that is stored in the SecretsManager key my-json-secret : { \"name\" : { \"first\" : \"Tom\" , \"last\" : \"Anderson\" }, \"friends\" : [ { \"first\" : \"Dale\" , \"last\" : \"Murphy\" }, { \"first\" : \"Roger\" , \"last\" : \"Craig\" }, { \"first\" : \"Jane\" , \"last\" : \"Murphy\" } ] } This is an example on how you would look up nested keys in the above json object: apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : # [omitted for brevity] data : - secretKey : firstname remoteRef : key : my-json-secret property : name.first # Tom - secretKey : first_friend remoteRef : key : my-json-secret property : friends.1.first # Roger","title":"JSON Secret Values"},{"location":"provider-aws-secrets-manager/#aws-authentication","text":"Access to AWS providers can be granted in various ways: IRSA : IAM roles for service accounts. Per pod IAM authentication: kiam or kube2iam . Directly provide AWS credentials to the External Secrets Operator pod by using environment variables. Additionally, before fetching a secret from a store, ESO is able to assume role (as a proxy so to speak). It is advisable to use multiple roles in a multi-tenant environment.","title":"AWS Authentication"},{"location":"provider-azure-key-vault/","text":"","title":"Key Vault"},{"location":"provider-google-secrets-manager/","text":"Google Cloud Secret Manager External Secrets Operator integrates with GCP Secret Manager for secret management. Authentication At the moment, we only support service account key authentication. Service account key authentication A service account key is created and the JSON keyfile is stored in a Kind=Secret . The project_id and private_key should be configured for the project. apiVersion : v1 kind : Secret metadata : name : gcpsm-secret labels : type : gcpsm type : Opaque stringData : secret-access-credentials : |- { \"type\": \"service_account\", \"project_id\": \"external-secrets-operator\", \"private_key_id\": \"\", \"private_key\": \"-----BEGIN PRIVATE KEY-----\\nA key\\n-----END PRIVATE KEY-----\\n\", \"client_email\": \"test-service-account@external-secrets-operator.iam.gserviceaccount.com\", \"client_id\": \"client ID\", \"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\", \"token_uri\": \"https://oauth2.googleapis.com/token\", \"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\", \"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/test-service-account%40external-secrets-operator.iam.gserviceaccount.com\" } Update secret store Be sure the gcpsm provider is listed in the Kind=SecretStore apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : example spec : provider : gcpsm : # gcpsm provider auth : secretRef : secretAccessKeySecretRef : name : gcpsm-secret # secret name containing SA key key : secret-access-credentials # key name containing SA key projectID : myproject # name of Google Cloud project Creating external secret To create a kubernetes secret from the GCP Secret Manager secret a Kind=ExternalSecret is needed. apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : refreshInterval : 1h # rate SecretManager pulls GCPSM secretStoreRef : kind : SecretStore name : example # name of the SecretStore (or kind specified) target : name : secret-to-be-created # name of the k8s Secret to be created creationPolicy : Owner data : - secretKey : dev-secret-test # name of the GCPSM secret key remoteRef : key : dev-secret-test The operator will fetch the GCP Secret Manager secret and inject it as a Kind=Secret kubectl get secret secret-to-be-created -n <namespace> | -o jsonpath='{.data.example-externalsecret-key}' | base64 -d","title":"Secrets Manager"},{"location":"provider-google-secrets-manager/#google-cloud-secret-manager","text":"External Secrets Operator integrates with GCP Secret Manager for secret management.","title":"Google Cloud Secret Manager"},{"location":"provider-google-secrets-manager/#authentication","text":"At the moment, we only support service account key authentication.","title":"Authentication"},{"location":"provider-google-secrets-manager/#service-account-key-authentication","text":"A service account key is created and the JSON keyfile is stored in a Kind=Secret . The project_id and private_key should be configured for the project. apiVersion : v1 kind : Secret metadata : name : gcpsm-secret labels : type : gcpsm type : Opaque stringData : secret-access-credentials : |- { \"type\": \"service_account\", \"project_id\": \"external-secrets-operator\", \"private_key_id\": \"\", \"private_key\": \"-----BEGIN PRIVATE KEY-----\\nA key\\n-----END PRIVATE KEY-----\\n\", \"client_email\": \"test-service-account@external-secrets-operator.iam.gserviceaccount.com\", \"client_id\": \"client ID\", \"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\", \"token_uri\": \"https://oauth2.googleapis.com/token\", \"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\", \"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/test-service-account%40external-secrets-operator.iam.gserviceaccount.com\" }","title":"Service account key authentication"},{"location":"provider-google-secrets-manager/#update-secret-store","text":"Be sure the gcpsm provider is listed in the Kind=SecretStore apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : example spec : provider : gcpsm : # gcpsm provider auth : secretRef : secretAccessKeySecretRef : name : gcpsm-secret # secret name containing SA key key : secret-access-credentials # key name containing SA key projectID : myproject # name of Google Cloud project","title":"Update secret store"},{"location":"provider-google-secrets-manager/#creating-external-secret","text":"To create a kubernetes secret from the GCP Secret Manager secret a Kind=ExternalSecret is needed. apiVersion : external-secrets.io/v1alpha1 kind : ExternalSecret metadata : name : example spec : refreshInterval : 1h # rate SecretManager pulls GCPSM secretStoreRef : kind : SecretStore name : example # name of the SecretStore (or kind specified) target : name : secret-to-be-created # name of the k8s Secret to be created creationPolicy : Owner data : - secretKey : dev-secret-test # name of the GCPSM secret key remoteRef : key : dev-secret-test The operator will fetch the GCP Secret Manager secret and inject it as a Kind=Secret kubectl get secret secret-to-be-created -n <namespace> | -o jsonpath='{.data.example-externalsecret-key}' | base64 -d","title":"Creating external secret"},{"location":"provider-hashicorp-vault/","text":"Hashicorp Vault External Secrets Operator integrates with HashiCorp Vault for secret management. Vault itself implements lots of different secret engines, as of now we only support the KV Secrets Engine . Authentication We support three different modes for authentication: token-based , appRole and kubernetes-native , each one comes with it's own trade-offs. Depending on the authentication method you need to adapt your environment. Token-based authentication A static token is stored in a Kind=Secret and is used to authenticate with vault. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # points to a secret that contains a vault token # https://www.vaultproject.io/docs/auth/token tokenSecretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"vault-token\" AppRole authentication example AppRole authentication reads the secret id from a Kind=Secret and uses the specified roleId to aquire a temporary token to fetch secrets. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # VaultAppRole authenticates with Vault using the # App Role auth mechanism # https://www.vaultproject.io/docs/auth/approle appRole : # Path where the App Role authentication backend is mounted path : \"approle\" # RoleID configured in the App Role authentication backend roleId : \"db02de05-fa39-4855-059b-67221c5c2f63\" secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"vault-token\" Kubernetes authentication Kubernetes-native authentication has three options of optaining credentials for vault: by using a service account jwt referenced in serviceAccountRef by using the jwt from a Kind=Secret referenced by the secretRef by using transient credentials from the mounted service account token within the external-secrets operator apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # Authenticate against Vault using a Kubernetes ServiceAccount # token stored in a Secret. # https://www.vaultproject.io/docs/auth/kubernetes kubernetes : # Path where the Kubernetes authentication backend is mounted in Vault mountPath : \"kubernetes\" # A required field containing the Vault Role to assume. role : \"demo\" # Optional service account field containing the name # of a kubernetes ServiceAccount serviceAccountRef : name : \"my-sa\" namespace : \"secret-admin\" # Optional secret field containing a Kubernetes ServiceAccount JWT # used for authenticating with Vault secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"vault\" LDAP authentication LDAP authentication uses username/password pair to get an access token. Username is stored directly in a Kind=SecretStore or Kind=ClusterSecretStore resource, password is stored in a Kind=Secret referenced by the secretRef . apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # VaultLdap authenticates with Vault using the LDAP auth mechanism # https://www.vaultproject.io/docs/auth/ldap ldap : # LDAP username username : \"username\" secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"ldap-password\" JWT/OIDC authentication JWT/OIDC uses a JWT token stored in a Kind=Secret and referenced by the secretRef . Optionally a role field can be defined in a Kind=SecretStore or Kind=ClusterSecretStore resource. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # VaultJwt authenticates with Vault using the JWT/OIDC auth mechanism # https://www.vaultproject.io/docs/auth/jwt jwt : # JWT role configured in a Vault server, optional. role : \"vault-jwt-role\" secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"jwt-token\"","title":"HashiCorp Vault"},{"location":"provider-hashicorp-vault/#hashicorp-vault","text":"External Secrets Operator integrates with HashiCorp Vault for secret management. Vault itself implements lots of different secret engines, as of now we only support the KV Secrets Engine .","title":"Hashicorp Vault"},{"location":"provider-hashicorp-vault/#authentication","text":"We support three different modes for authentication: token-based , appRole and kubernetes-native , each one comes with it's own trade-offs. Depending on the authentication method you need to adapt your environment.","title":"Authentication"},{"location":"provider-hashicorp-vault/#token-based-authentication","text":"A static token is stored in a Kind=Secret and is used to authenticate with vault. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # points to a secret that contains a vault token # https://www.vaultproject.io/docs/auth/token tokenSecretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"vault-token\"","title":"Token-based authentication"},{"location":"provider-hashicorp-vault/#approle-authentication-example","text":"AppRole authentication reads the secret id from a Kind=Secret and uses the specified roleId to aquire a temporary token to fetch secrets. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # VaultAppRole authenticates with Vault using the # App Role auth mechanism # https://www.vaultproject.io/docs/auth/approle appRole : # Path where the App Role authentication backend is mounted path : \"approle\" # RoleID configured in the App Role authentication backend roleId : \"db02de05-fa39-4855-059b-67221c5c2f63\" secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"vault-token\"","title":"AppRole authentication example"},{"location":"provider-hashicorp-vault/#kubernetes-authentication","text":"Kubernetes-native authentication has three options of optaining credentials for vault: by using a service account jwt referenced in serviceAccountRef by using the jwt from a Kind=Secret referenced by the secretRef by using transient credentials from the mounted service account token within the external-secrets operator apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # Authenticate against Vault using a Kubernetes ServiceAccount # token stored in a Secret. # https://www.vaultproject.io/docs/auth/kubernetes kubernetes : # Path where the Kubernetes authentication backend is mounted in Vault mountPath : \"kubernetes\" # A required field containing the Vault Role to assume. role : \"demo\" # Optional service account field containing the name # of a kubernetes ServiceAccount serviceAccountRef : name : \"my-sa\" namespace : \"secret-admin\" # Optional secret field containing a Kubernetes ServiceAccount JWT # used for authenticating with Vault secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"vault\"","title":"Kubernetes authentication"},{"location":"provider-hashicorp-vault/#ldap-authentication","text":"LDAP authentication uses username/password pair to get an access token. Username is stored directly in a Kind=SecretStore or Kind=ClusterSecretStore resource, password is stored in a Kind=Secret referenced by the secretRef . apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # VaultLdap authenticates with Vault using the LDAP auth mechanism # https://www.vaultproject.io/docs/auth/ldap ldap : # LDAP username username : \"username\" secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"ldap-password\"","title":"LDAP authentication"},{"location":"provider-hashicorp-vault/#jwtoidc-authentication","text":"JWT/OIDC uses a JWT token stored in a Kind=Secret and referenced by the secretRef . Optionally a role field can be defined in a Kind=SecretStore or Kind=ClusterSecretStore resource. apiVersion : external-secrets.io/v1alpha1 kind : SecretStore metadata : name : vault-backend namespace : example spec : provider : vault : server : \"https://vault.acme.org\" path : \"secret\" version : \"v2\" auth : # VaultJwt authenticates with Vault using the JWT/OIDC auth mechanism # https://www.vaultproject.io/docs/auth/jwt jwt : # JWT role configured in a Vault server, optional. role : \"vault-jwt-role\" secretRef : name : \"my-secret\" namespace : \"secret-admin\" key : \"jwt-token\"","title":"JWT/OIDC authentication"},{"location":"spec/","text":"Packages: external-secrets.io/v1alpha1 external-secrets.io/v1alpha1 Package v1alpha1 contains resources for external-secrets Resource Types: AWSAuth ( Appears on: AWSProvider ) AWSAuth contains a secretRef for credentials. Field Description secretRef AWSAuthSecretRef AWSAuthSecretRef ( Appears on: AWSAuth ) AWSAuthSecretRef holds secret references for aws credentials both AccessKeyID and SecretAccessKey must be defined in order to properly authenticate. Field Description accessKeyIDSecretRef github.com/external-secrets/external-secrets/apis/meta/v1.SecretKeySelector The AccessKeyID is used for authentication secretAccessKeySecretRef github.com/external-secrets/external-secrets/apis/meta/v1.SecretKeySelector The SecretAccessKey is used for authentication AWSProvider ( Appears on: SecretStoreProvider ) AWSProvider configures a store to sync secrets with AWS. Field Description service AWSServiceType Service defines which service should be used to fetch the secrets auth AWSAuth (Optional) Auth defines the information necessary to authenticate against AWS if not set aws sdk will infer credentials from your environment see: https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials role string (Optional) Role is a Role ARN which the SecretManager provider will assume region string AWS Region to be used for the provider AWSServiceType ( string alias) ( Appears on: AWSProvider ) AWSServiceType is a enum that defines the service/API that is used to fetch the secrets. Value Description \"ParameterStore\" AWSServiceParameterStore is the AWS SystemsManager ParameterStore. see: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html \"SecretsManager\" AWSServiceSecretsManager is the AWS SecretsManager. see: https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html ClusterSecretStore ClusterSecretStore represents a secure external location for storing secrets, which can be referenced as part of storeRef fields. Field Description metadata Kubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec SecretStoreSpec controller string (Optional) Used to select the correct KES controller (think: ingress.ingressClassName) The KES controller is instantiated with a specific controller name and filters ES based on this property provider SecretStoreProvider Used to configure the provider. Only one provider may be set ExternalSecret ExternalSecret is the Schema for the external-secrets API. Field Description metadata Kubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec ExternalSecretSpec secretStoreRef SecretStoreRef target ExternalSecretTarget refreshInterval Kubernetes meta/v1.Duration RefreshInterval is the amount of time before the values are read again from the SecretStore provider Valid time units are \u201cns\u201d, \u201cus\u201d (or \u201c\u00b5s\u201d), \u201cms\u201d, \u201cs\u201d, \u201cm\u201d, \u201ch\u201d May be set to zero to fetch and create it once. Defaults to 1h. data []ExternalSecretData (Optional) Data defines the connection between the Kubernetes Secret keys and the Provider data dataFrom []ExternalSecretDataRemoteRef (Optional) DataFrom is used to fetch all properties from a specific Provider data If multiple entries are specified, the Secret keys are merged in the specified order status ExternalSecretStatus ExternalSecretConditionType ( string alias) ( Appears on: ExternalSecretStatusCondition ) Value Description \"Ready\" ExternalSecretCreationPolicy ( string alias) ( Appears on: ExternalSecretTarget ) ExternalSecretCreationPolicy defines rules on how to create the resulting Secret. Value Description \"Merge\" Merge does not create the Secret, but merges the data fields to the Secret. \"None\" None does not create a Secret (future use with injector). \"Owner\" Owner creates the Secret and sets .metadata.ownerReferences to the ExternalSecret resource. ExternalSecretData ( Appears on: ExternalSecretSpec ) ExternalSecretData defines the connection between the Kubernetes Secret key (spec.data. ) and the Provider data. Field Description secretKey string remoteRef ExternalSecretDataRemoteRef ExternalSecretDataRemoteRef ( Appears on: ExternalSecretData , ExternalSecretSpec ) ExternalSecretDataRemoteRef defines Provider data location. Field Description key string Key is the key used in the Provider, mandatory version string (Optional) Used to select a specific version of the Provider value, if supported property string (Optional) Used to select a specific property of the Provider value (if a map), if supported ExternalSecretSpec ( Appears on: ExternalSecret ) ExternalSecretSpec defines the desired state of ExternalSecret. Field Description secretStoreRef SecretStoreRef target ExternalSecretTarget refreshInterval Kubernetes meta/v1.Duration RefreshInterval is the amount of time before the values are read again from the SecretStore provider Valid time units are \u201cns\u201d, \u201cus\u201d (or \u201c\u00b5s\u201d), \u201cms\u201d, \u201cs\u201d, \u201cm\u201d, \u201ch\u201d May be set to zero to fetch and create it once. Defaults to 1h. data []ExternalSecretData (Optional) Data defines the connection between the Kubernetes Secret keys and the Provider data dataFrom []ExternalSecretDataRemoteRef (Optional) DataFrom is used to fetch all properties from a specific Provider data If multiple entries are specified, the Secret keys are merged in the specified order ExternalSecretStatus ( Appears on: ExternalSecret ) Field Description refreshTime Kubernetes meta/v1.Time refreshTime is the time and date the external secret was fetched and the target secret updated conditions []ExternalSecretStatusCondition (Optional) ExternalSecretStatusCondition ( Appears on: ExternalSecretStatus ) Field Description type ExternalSecretConditionType status Kubernetes core/v1.ConditionStatus reason string (Optional) message string (Optional) lastTransitionTime Kubernetes meta/v1.Time (Optional) ExternalSecretTarget ( Appears on: ExternalSecretSpec ) ExternalSecretTarget defines the Kubernetes Secret to be created There can be only one target per ExternalSecret. Field Description name string (Optional) Name defines the name of the Secret resource to be managed This field is immutable Defaults to the .metadata.name of the ExternalSecret resource creationPolicy ExternalSecretCreationPolicy (Optional) CreationPolicy defines rules on how to create the resulting Secret Defaults to \u2018Owner\u2019 template ExternalSecretTemplate (Optional) Template defines a blueprint for the created Secret resource. ExternalSecretTemplate ( Appears on: ExternalSecretTarget ) ExternalSecretTemplate defines a blueprint for the created Secret resource. we can not use native corev1.Secret, it will have empty ObjectMeta values: https://github.com/kubernetes-sigs/controller-tools/issues/448 Field Description type Kubernetes core/v1.SecretType (Optional) metadata ExternalSecretTemplateMetadata (Optional) data map[string]string (Optional) ExternalSecretTemplateMetadata ( Appears on: ExternalSecretTemplate ) ExternalSecretTemplateMetadata defines metadata fields for the Secret blueprint. Field Description annotations map[string]string (Optional) labels map[string]string (Optional) GCPSMAuth ( Appears on: GCPSMProvider ) Field Description secretRef GCPSMAuthSecretRef GCPSMAuthSecretRef ( Appears on: GCPSMAuth ) Field Description secretAccessKeySecretRef github.com/external-secrets/external-secrets/apis/meta/v1.SecretKeySelector (Optional) The SecretAccessKey is used for authentication GCPSMProvider ( Appears on: SecretStoreProvider ) GCPSMProvider Configures a store to sync secrets using the GCP Secret Manager provider. Field Description auth GCPSMAuth Auth defines the information necessary to authenticate against GCP projectID string ProjectID project where secret is located GenericStore GenericStore is a common interface for interacting with ClusterSecretStore or a namespaced SecretStore. SecretStore SecretStore represents a secure external location for storing secrets, which can be referenced as part of storeRef fields. Field Description metadata Kubernetes meta/v1.ObjectMeta Refer to the Kubernetes API documentation for the fields of the metadata field. spec SecretStoreSpec controller string (Optional) Used to select the correct KES controller (think: ingress.ingressClassName) The KES controller is instantiated with a specific controller name and filters ES based on this property provider SecretStoreProvider Used to configure the provider. Only one provider may be set status SecretStoreStatus SecretStoreConditionType ( string alias) ( Appears on: SecretStoreStatusCondition ) Value Description \"Ready\" SecretStoreProvider ( Appears on: SecretStoreSpec ) SecretStoreProvider contains the provider-specific configration. Field Description aws AWSProvider (Optional) AWS configures this store to sync secrets using AWS Secret Manager provider vault VaultProvider (Optional) Vault configures this store to sync secrets using Hashi provider gcpsm GCPSMProvider (Optional) GCPSM configures this store to sync secrets using Google Cloud Platform Secret Manager provider SecretStoreRef ( Appears on: ExternalSecretSpec ) SecretStoreRef defines which SecretStore to fetch the ExternalSecret data. Field Description name string Name of the SecretStore resource kind string (Optional) Kind of the SecretStore resource (SecretStore or ClusterSecretStore) Defaults to SecretStore SecretStoreSpec ( Appears on: ClusterSecretStore , SecretStore ) SecretStoreSpec defines the desired state of SecretStore. Field Description controller string (Optional) Used to select the correct KES controller (think: ingress.ingressClassName) The KES controller is instantiated with a specific controller name and filters ES based on this property provider SecretStoreProvider Used to configure the provider. Only one provider may be set SecretStoreStatus ( Appears on: SecretStore ) SecretStoreStatus defines the observed state of the SecretStore. Field Description conditions []SecretStoreStatusCondition (Optional) SecretStoreStatusCondition ( Appears on: SecretStoreStatus ) Field Description type SecretStoreConditionType status Kubernetes core/v1.ConditionStatus reason string (Optional) message string (Optional) lastTransitionTime Kubernetes meta/v1.Time (Optional) VaultAppRole ( Appears on: VaultAuth ) VaultAppRole authenticates with Vault using the App Role auth mechanism, with the role and secret stored in a Kubernetes Secret resource. Field Description path string Path where the App Role authentication backend is mounted in Vault, e.g: \u201capprole\u201d roleId string RoleID configured in the App Role authentication backend when setting up the authentication backend in Vault. secretRef github.com/external-secrets/external-secrets/apis/meta/v1.SecretKeySelector Reference to a key in a Secret that contains the App Role secret used to authenticate with Vault. The key field must be specified and denotes which entry within the Secret resource is used as the app role secret. VaultAuth ( Appears on: VaultProvider ) VaultAuth is the configuration used to authenticate with a Vault server. Only one of tokenSecretRef , appRole , kubernetes , ldap or jwt can be specified. Field Description tokenSecretRef github.com/external-secrets/external-secrets/apis/meta/v1.SecretKeySelector (Optional) TokenSecretRef authenticates with Vault by presenting a token. appRole VaultAppRole (Optional) AppRole authenticates with Vault using the App Role auth mechanism, with the role and secret stored in a Kubernetes Secret resource. kubernetes VaultKubernetesAuth (Optional) Kubernetes authenticates with Vault by passing the ServiceAccount token stored in the named Secret resource to the Vault server. ldap VaultLdapAuth (Optional) Ldap authenticates with Vault by passing username/password pair using the LDAP authentication method jwt VaultJwtAuth (Optional) Jwt authenticates with Vault by passing role and JWT token using the JWT/OIDC authentication method VaultJwtAuth ( Appears on: VaultAuth ) VaultJwtAuth authenticates with Vault using the JWT/OIDC authentication method, with the role name and token stored in a Kubernetes Secret resource. Field Description role string (Optional) Role is a JWT role to authenticate using the JWT/OIDC Vault authentication method secretRef github.com/external-secrets/external-secrets/apis/meta/v1.SecretKeySelector SecretRef to a key in a Secret resource containing JWT token to authenticate with Vault using the JWT/OIDC authentication method VaultKVStoreVersion ( string alias) ( Appears on: VaultProvider ) Value Description \"v1\" \"v2\" VaultKubernetesAuth ( Appears on: VaultAuth ) Authenticate against Vault using a Kubernetes ServiceAccount token stored in a Secret. Field Description mountPath string Path where the Kubernetes authentication backend is mounted in Vault, e.g: \u201ckubernetes\u201d serviceAccountRef github.com/external-secrets/external-secrets/apis/meta/v1.ServiceAccountSelector (Optional) Optional service account field containing the name of a kubernetes ServiceAccount. If the service account is specified, the service account secret token JWT will be used for authenticating with Vault. If the service account selector is not supplied, the secretRef will be used instead. secretRef github.com/external-secrets/external-secrets/apis/meta/v1.SecretKeySelector (Optional) Optional secret field containing a Kubernetes ServiceAccount JWT used for authenticating with Vault. If a name is specified without a key, token is the default. If one is not specified, the one bound to the controller will be used. role string A required field containing the Vault Role to assume. A Role binds a Kubernetes ServiceAccount with a set of Vault policies. VaultLdapAuth ( Appears on: VaultAuth ) VaultLdapAuth authenticates with Vault using the LDAP authentication method, with the username and password stored in a Kubernetes Secret resource. Field Description username string Username is a LDAP user name used to authenticate using the LDAP Vault authentication method secretRef github.com/external-secrets/external-secrets/apis/meta/v1.SecretKeySelector SecretRef to a key in a Secret resource containing password for the LDAP user used to authenticate with Vault using the LDAP authentication method VaultProvider ( Appears on: SecretStoreProvider ) Configures an store to sync secrets using a HashiCorp Vault KV backend. Field Description auth VaultAuth Auth configures how secret-manager authenticates with the Vault server. server string Server is the connection address for the Vault server, e.g: \u201c https://vault.example.com:8200\u201d . path string Path is the mount path of the Vault KV backend endpoint, e.g: \u201csecret\u201d. The v2 KV secret engine version specific \u201c/data\u201d path suffix for fetching secrets from Vault is optional and will be appended if not present in specified path. version VaultKVStoreVersion Version is the Vault KV secret engine version. This can be either \u201cv1\u201d or \u201cv2\u201d. Version defaults to \u201cv2\u201d. namespace string (Optional) Name of the vault namespace. Namespaces is a set of features within Vault Enterprise that allows Vault environments to support Secure Multi-tenancy. e.g: \u201cns1\u201d. More about namespaces can be found here https://www.vaultproject.io/docs/enterprise/namespaces caBundle []byte (Optional) PEM encoded CA bundle used to validate Vault server certificate. Only used if the Server URL is using HTTPS protocol. This parameter is ignored for plain HTTP protocol connection. If not set the system root certificates are used to validate the TLS connection. Generated with gen-crd-api-reference-docs .","title":"API specification"},{"location":"snippets/provider-aws-access/","text":"AWS Authentication Access to AWS providers can be granted in various ways: IRSA : IAM roles for service accounts. Per pod IAM authentication: kiam or kube2iam . Directly provide AWS credentials to the External Secrets Operator pod by using environment variables. Additionally, before fetching a secret from a store, ESO is able to assume role (as a proxy so to speak). It is advisable to use multiple roles in a multi-tenant environment.","title":"Provider aws access"},{"location":"snippets/provider-aws-access/#aws-authentication","text":"Access to AWS providers can be granted in various ways: IRSA : IAM roles for service accounts. Per pod IAM authentication: kiam or kube2iam . Directly provide AWS credentials to the External Secrets Operator pod by using environment variables. Additionally, before fetching a secret from a store, ESO is able to assume role (as a proxy so to speak). It is advisable to use multiple roles in a multi-tenant environment.","title":"AWS Authentication"}]}