-
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?
-
-
- None
-
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
-
Additional requirements related to scope are defined in the Scope documentation
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.