ADR: Enhancement to the KeyAccessServer table to support key rotations

[jrschumacher]

Enhance Key Access Server table to support key rotations

Context and Problem Statement

The Key Access Server policy store supports a single key and many key access grants. The original design assumed that only a single key would be held at a given time and if a rotation was needed the key access server's public key would be replaced with a new on.

It appears that this may not be a good long term strategy and some enhancement is needed to track the key rotations for remote KAS (whether considered part of the platform or external to the platform).

Decision Drivers

• Support key rotations
• Ensure strict values

Considered Options

• Store multiple keys within the public_key jsonb typed column
• Create an auxiliary table to store the keys with a many:1 relationship with the KeyAccessServer table

Decision Outcome

Chosen option: "{title of option}"

Store multiple keys within the public_key jsonb typed column

• 🟢 Existing table structure and no migration needed
• 🔴 With JSONB the data does not have a schema to conform to and data structure migrations are hard
• 🔴 No indication from a high-level which key is primary without decoding the JSONB
• 🔴 Row needs to be updated "frequently" to capture key rotations and identify the current key
• 🔴 After many key rotations the resulting data is quite large and filtering needs to be added to the service code

Create an auxiliary table to store the keys

erDiagram

    KeyAccessServer ||--|| KeyAccessServerKey: "has current key"
    KeyAccessServerKey }|--|| KeyAccessServer: "belongs to"

    XKeyAccessGrant }|--|| KeyAccessServer: "has many"
    X ||--|| XKeyAccessGrant: "has one"

    X {
        uuid         id                      PK
    }

    XKeyAccessGrant {
        uuid  X_id FK
        uuid  key_access_server_id FK
    }

    %% moving public_key out
    KeyAccessServer {
        uuid       id                PK
        text       name
        text       uri               UK
        uuid       current_key_id    FK
        jsonb      metadata
        created_on date
        updated_on date
    }

    KeyAccessServerKey {
        uuid       id
        uuid       key_access_server_id  FK
        jsonb      public_key
        jsonb      metadata
        created_on date
        updated_on date
    }

• 🟢 Schema enforced solution to multiple keys
• 🟢 Ensure future migrations are simpler (not-NoSQL)
• 🟡 Requires an auto migration to move public keys
• 🔴 If public key json has many keys, a manual migration is required

References

[jakedoublev]

@jrschumacher is this statement accurate given your proposed schema?

"During a key rotation, a new key (row) is added to the KeyAccessServerKey table and the current_key (on one or multiple) KAS is updated to that new key. The old keys will persist within policy (un-utilized as non-current) and are not deleted upon rotation."

[jrschumacher]

That is my assumption. If we don't need to persist the keys then we really don't need a separate table.

It's also worth discussing how this would work for KASes managed by the platform and KASes managed remotely.