Skip to content

Document Vault Structure #87

Description

@srueg

Context

The current Vault structure enforces the <tenant-id>/<cluster-id>/ structure. Nothing more is enforced or recommended.
We should document the best practices around secrets in Vault and how to structure them.
Some inputs:

  • Use as less key-value pairs per secret as possible (it's not possible to update only single key-value pairs)
  • Use descriptive names, so it's clear what a secret is used for
  • Consistent naming (e.g. token vs. password, vs.
  • ...

Alternatives

Implement more secrets generation via Lieutenant-operator which would enforce certain structures.

Activity

  1. added
    enhancementNew feature or request
    RFCRequest for Comments
    on Sep 7, 2020
  2. corvus-ch commented on Oct 15, 2020

    @corvus-ch
    Contributor

    Use as less key-value pairs per secret as possible (it's not possible to update only single key-value pairs)

    There is vault kv patch that can do that.

  3. corvus-ch commented on Oct 15, 2020

    @corvus-ch
    Contributor

    So far, we assumed secretes to be defined on the cluster level. However, some secrets might be better put on the level of a tenant and shared between all clusters of that tenant.

    Would it also makes sens to have globally defined secretes? Maybe but this certainly needs security considerations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    RFCRequest for CommentsenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions