Lesson 3.3.6 explained the tools; this lesson takes care of their life in operation. A key is created, used, replaced and eventually retired, and at each of these points something can go wrong: It lies in the wrong place, it expires unnoticed, a change makes all links invalid, or after a leak nobody knows what to do first. At the end of this lesson, the Kladde signs data in the vault without ever seeing the private key, its link key can be changed without breaking a single link that was sent, and an alert speaks up before anything in the vault expires.
New in this lesson:
| Package | Version | What for |
|---|---|---|
Azure.Security.KeyVault.Keys |
4.10.2 | creating keys in the vault, rotating them and signing with them (KeyClient, CryptographyClient) |
Three kinds of objects, three life cycles
Lesson 3.3.2 named the three kinds of objects in Key Vault. For operation, they differ mainly in what the app gets and who does the change:
| Object | What the app gets | Who changes it | In the Kladde |
|---|---|---|---|
| Secret | the value itself | You: write a new version, restart the app | the link key Booking--LinkKey |
| Key | never the private part, only results (a signature) and the public part | Key Vault itself, by a policy | the signing key for exports (Exercise 1) |
| TLS certificate (certificate) | nothing; Container Apps or Front Door fetch it | Key Vault renews it, with an integrated CA or if self-issued | only if no managed certificate fits |
The first rule follows from that: What the app doesn’t need in plain text, it doesn’t get in plain text. An HMAC key has to go into the app as a value, because the app computes the HMAC itself. A signing key doesn’t have to: The vault can sign by itself.