feat(acme): make account_key configurable

[szesch]

Summary

There is currently no way to configure an existing private key to be used for the acme plugin. If the account does not have a key in storage, then a new one is created. This is a problem when external account binding credentials have already been associated with a key elsewhere (e.g. cert-manager or cert-bot). Some issuers like ZeroSSL allow for EAB credentials to be reused and multiple accounts can be created with different private keys. Others like GCP Public CA only allow for EAB credentials to be associated with one key so when the plugin tries to create a new account with a new key it fails.

The current workaround for this has been to manually insert the key in storage so a new key is not created.

This PR exposes account_key and will use that if the account was not found in storage and the value of account_key is not nil. Otherwise, it will generate a key on the fly as it does currently.

Full changelog

• Add account_key in acme plugin schema
• Add tests for when account_key is present and when it is absent in the configuration

cc @fffonion

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[fffonion]

Thanks for the PR @szesch ! I agree it's a correct way to do. I leave a comment, some tests might need to be adjusted
accordingly.

[fffonion]

@szesch I forgot to mention last time that we need to add this field to https://github.com/Kong/kong/blob/master/kong/clustering/compat/removed_fields.lua for hybrid mode compatibility.
And could you re-commit using company email to pass CLA?

[szesch]

@fffonion Done! Thanks.

[fffonion]

cc @jschmid1 this PR adds the account private key field to acme plugin, with key mgmt feature coming in 3.1, do
you think it should and is feasible for it to store the account key in key mgmt?

[jschmid1]

yeah, I think it would. the acme-plugin would need to add a config field that allows to specify a key (or a set of keys)

[fffonion]

@szesch I assume this wasn't in the urgency of getting in 3.1 (correct me if i'm wrong). As we now introduce
keys entity in kong, the account_key field may need to reference that entity. it won't be huge refactor
of this PR, most likely just conf.account_key becomes kong.db.keys:get_private_key(conf.account_key_id).
But since feature freeze is tomorrow, it's not likely we will have enought time to get this in.

[szesch]

@fffonion it's not urgent to get in to 3.1. Is there another PR I can reference or some docs to better understand what I have to refactor?

[dndx]

This PR needs rebasing.

[gszr]

In the vein of #9367, IMO we should make this accept a base64-encoded key also.

[szesch]

@gszr @fffonion Do I need to add base64 support if the plan is to wait for the key entity work to be done and then update this PR to use that (as mentioned #9746 (comment))? In other words, is the vision to support the key entity AND base64 encoded values or just the key entity?

[jschmid1]

@szesch the key/key-sets feature is in Kong now. There is an ee-plugin that already uses this entity (see https://github.com/Kong/kong-ee/pull/4013 for inspiration)
Note that a base64 encoded version of a key-pair is not supported currently, but may be useful

[kikito]

This comment would need to be actioned before this PR can be merged:

@szesch the key/key-sets feature is in Kong now. There is an ee-plugin that already uses this entity (see https://github.com/Kong/kong-ee/pull/4013 for inspiration)
Note that a base64 encoded version of a key-pair is not supported currently, but may be useful

[kikito]

Since this PR has not been updated in time, I am removing it from the 3.2 milestone.

[szesch]

@fffonion @jschmid1 I've updated the code to use keys and key_sets.

[fffonion]

@jschmid1 could you take another look?

[jschmid1]

lgtm

dismiss as it's addressed

[fffonion]

I'm merging this in as it's been a long while. @szesch Could you also make seperate PR to add changelog in https://github.com/Kong/kong/blob/master/CHANGELOG.md and update docs at kong/docs.konghq.com repo?