Skip to content

Instantly share code, notes, and snippets.

@chcosta
Last active January 29, 2021 22:05
Show Gist options
  • Save chcosta/51af24ab8a1cfd303a50d0aa7332e7f0 to your computer and use it in GitHub Desktop.
Save chcosta/51af24ab8a1cfd303a50d0aa7332e7f0 to your computer and use it in GitHub Desktop.
Secret management requirements

Requirements

Functional requirements

  • Able to rotate any secret we manage

  • Able to detect duplicates within a key vault

  • Able to manage secret relationships

    • dependent secrets

    • secrets duplicated across key vaults

  • Able to validate secrets

  • Able to audit secret access (creation, deletion, rotation, fetch)

  • Able to audit whether secrets in a key vault are managed or unmanaged

  • Able to manage secret expiration events

    • Given that many secrets have expiration dates, how do we want to manage these expirations? ie, if a secret is going to expire in 30 days do we..?

      • send expiration email notifications?

      • warning / failure during a validation build?

      • pend a "rotation operation" and wait for approval?

External interface requirements

  • None

Nonfunctional requirements

  • Documented scenarios and usage

  • Security

    • No self managed identity, use Azure IAM

    • No logging of confidential info (no exposing secrets)

    • No GDPR violations

  • Performance

    • This tool should not impact the performance of normal service operations (helix-services, arcade services, azure builds, etc), ie, we should not bring down services for a significant amount of time when a secret is rotated.

    • Perf requirements for validating?

    • Perf requirements for rotating?

    • Key vaults throttle, we should not design a system which impacts our throttle limits

Scope

Additional requirements related to scope are defined in the Scope documentation

@alexperovich
Copy link

Prevent services from accessing secrets we don't manage (not in our key vault) and / or bad secrets

I don't think this is feasible in a finite amount of work. Any service can just write code to access key vault and we can't stop that without writing crazy code analysis that isn't worth the cost in my opinion. We can prevent services using our standard configuration system from accessing unmanaged secrets which is way more feasible and worth doing.

@markwilkie
Copy link

These are great. I think we'll need to have some sort of audit trail too. Who changed what when....

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