Elastic Fleet Secret Vault

[renzedj]

Feature

A general purpose vault or provider for secrets in Fleet, similar to the env or local_dynamic providers.

From Kibana, users MUST be able to:

• Create a secret with an arbitrary name (e.g., myapp_username, myapp_password).
• Update the secret.
• Users MUST NOT be able to retrieve or view the secret from within Kibana.

Within an integration, users SHOULD be able to reference the secret in an arbitrary field, similar to the env or local_dynamic providers. E.g., username: ${secret.myapp_username}.

Use Case

As our company's Elastic Cloud admin, I am using the elasticstack terraform provider to manage our cluster so that it can be put into version control and managed through a CI/CD pipeline. This includes our integration policies. Per the response to this question in the discussion forums, only variables specifically marked as secrets by an integration will be marked as secrets. My understanding is that they will be automatically extracted from the integration and committed to the secret vault, then a variable will be substituted for the secret (e.g., ${SECRET_0}). When using terraform, this will create configuration drift, which will force an update of the policy each time the terraform configuration is applied, even if no changes have been made. A general-purpose vault will also allow Elastic Stack users to determine which specific items may or may not need to be marked as secrets based on their own policies.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

@nimarezainia To get your eyes on this from product standpoint.