Push of secrets to have the option to not delete previous active secrets

[bitboy67]

The existing push of Secrets appears to delete previous active versions of the Secret. This is problematic when a previous version of the secret is still required. For example, for a OAuth Signing Key when Identity Cloud still needs to honour tokens signed with the previous key.

[christian-brindley]

The secrets push is designed to be declarative - i.e. regardless of the current state of the tenant, we will always push the secret(s) defined in the repo. This is because there is no safe way to determine whether the current values of the secrets in the tenant match the values in the pipeline environment. We could just keep adding keys, but this will build up excessively over time.

For example, if we want to have 2 values defined for a secret - as per your example of two generations of a token signing key - the secret JSON in the repo would have two entries such as

{
  "_id": "esv-my-secret",
  "description": "",
  "encoding": "generic",
  "useInPlaceholders": true,
  "versions": [
    {
      "valueBase64": "${ESV_MY_SECRET_1}",
      "version": "1"
    },
    {
      "valueBase64": "${ESV_MY_SECRET_2}",
      "version": "2"
    }
  ]
}

On the push, we remove all secrets then add them back in the order in the repo. The last secret in the array will be the active one. So if you are rolling over your signing key, ESV_MY_SECRET_1 will be your old signing key, and ESV_MY_SECRET_2 will be your new signing key.