Feature: Support Azure Key Vault PurgeProtection and CreateMode

[matthchr]

trafficstars

In order to support the purge protection scenarios supported by KeyVault, each of these properties must be possible to set in the spec.

See CreateMode and enablePurgeProtection for more details.

[matthchr]

Specifically with CreateMode there's some awkward tension between goal-seeking to the customers desired state and the reality that KeyVault will fail creates if a KeyVault of the same name was previously deleted and needs to instead be recovered (needs confirmation).

So we're left with a few options...

1. Automatically detect that we're failing to create the KeyVault because it instead needs to be recovered and automatically change the CreateMode to recover. The downside of this is that CreateMode is a property on KeyVault and we would effectively be saying that whatever the customer set there we're ignoring. That's awkward because we're not actually seeking to the Spec as specified by the customer. There are additional permissions required to escalate to recover as well, which we may not have been granted (it's different than Create).
2. Force the customer to update the CRD to specify CreateMode recover. This more closely matches the KeyVault API but gives a poor goal-seeking experience because customers may need to make modifications to their CRDs in order for them to successfully reconcile.
3. The most complicated but possibly the "best" is for us to fabricate a CreateOrRecover mode for KeyVaults, which would allow customers to clarify that they want the Create behavior if they can get it but the Recover behavior if they have to. From a goal-seeking perspective this is best as it gives the customers a way to express their intent ahead of time so that when a KV is deleted it can be immediately recovered. We could even investigate if this was a feature the KeyVault team itself would be open to supporting as it would seem to have benefits for ARM templates and other declarative creation modes as well as ASO.

[sakthi-vetrivel]

Will revisit once we support KV secrets

[matthchr]

We do support KeyVault, and this is an issue for the KeyVault resource itself as if they also have purge protection enabled on the entire vault. It causes us issues in our CI because we delete and recreate KVs with the same names (for recording tests, etc).

We should do something about this.

[matthchr]

There's 2 parts to this, key vault secrets, which we don't support in ASOv2 yet, and KeyVaults themselves, which we do.

We still need a solution for this for KeyVaults themselves.

[matthchr]

We should write a doc about this, and also 100% confirm that the behavior works as well (it should but might be good to have a test)

[theunrepentantgeek]

Bringing into v2.2.0 as this is about smoothing the experience for users.

[super-harsh]

I did some testing around the properties mentioned above - works fine. Azure docs have good documentation already for the fields explaining how it works. Also, our API docs are clear enough to make users understand them.

[theunrepentantgeek]

I did some testing around the properties mentioned above ...

Given the above comment by @matthchr, I believe the standard properties are not sufficient for the ASO use case.

Extending CreateMode with a third option - autopurge - might get us close to what we need. We should revisit and rediscuss.

[theunrepentantgeek]

Another quirk - you can only specify createMode: recover if there is an existing vault to recover - so it's very much NOT a goal state design.

[radirobi]

@matthchr are you planning to support secret creation through ASOv2?

[matthchr]

@radirobi - it depends on what you mean by secret creation. If you mean, configure ASO to export secrets from Azure into KeyVault automatically, yes we have an item tracking that here: #2242. If you mean, create your secret as a Kubernetes secret and have that be saved as a KeyVault secret: no we deliberately didn't expose this option via ASO because we thought that it didn't meet most organizations security goals.

If you want direct KV secret key creation via user specified secret (not importing Azure secrets such as storage account keys into KV automatically like #2242 is talking about), could you expand some more on your use-case, possibly in a separate issue?