Trust Zone Concepts

SPIRE

Each Cofide Connect Trust Zone corresponds to a single SPIRE trust domain with its own SPIRE server deployment and collection of SPIRE agents. This section describes some relevant concepts from Cofide SPIRE and how they relate to Cofide Connect trust zones.

Key Managers & Upstream Authorities

Cofide SPIRE supports the same plugin system as the upstream SPIRE project, including plugins for securely managing cryptographic key material and public key infrastructure. SPIRE’s ‘Key Manager’ plugins are used to generate and store private keys for signing both X.509 and JWT SVIDs. ‘Upstream Authority’ plugins are used to sign an intermediate CA certificate for SPIRE to use when issuing X.509 SVIDs. Without an upstream authority plugin, SPIRE uses a self-signed root CA.

Documentation on each of the available upstream plugins can be found here.

In order to understand how each plugin type is used to securely manage a trust zone’s cryptographic material, it is insightful to trace the path followed when issuing a single SVID to a workload. The process differs depending on the type of SVID requested, so the following sections cover each type separately. Each sequence diagram illustrates SPIRE’s SVID issuance process, plus the roles of the key manager and upstream authority plugins.

JWT-SVIDs

JWT-SVIDs are signed using a dedicated JWT signing key stored in the configured key manager. There is only one private key involved in this flow and no key material ever leaves the key manager. SPIRE server periodically refreshes the JWT signing key using available key manager APIs. The upstream authority plugin is not involved.

sequenceDiagram
    participant W as Workload
    participant A as Cofide SPIRE <br/> agent
    participant S as Cofide SPIRE <br/> server
    participant K as Key manager <br/> (e.g. AWS KMS)

    W->>A: Request JWT-SVID with aud example.com
    A->>S: Request signed JWT
    S->>K: Sign JWT
    K->>K: Sign JWT with current <br/> JWT signing private key
    K-->>S: Signed JWT
    S-->>A: JWT
    Note over A: Cache JWT
    A-->>W: JWT
    Note over W,A: wrap: Subsequent requests for the same subject and audience use the cache until expiry

X.509 SVIDs

For X.509 SVIDs, the SPIRE server periodically obtains an intermediate CA certificate from the configured upstream authority. The intermediate CA is used to sign X.509 SVIDs for workloads.

sequenceDiagram
    participant W as Workload
    participant A as Cofide SPIRE <br/> agent
    participant S as Cofide SPIRE <br/> server
    participant K as wrap: Key manager <br/> (e.g. AWS KMS)
    participant U as wrap: Upstream <br/> authority <br/> (e.g. AWS PCA)

    loop Periodically
        S->>K: Create new private key
        S->>S: Generate CSR for intermediate CA
        S->>K: Sign CSR
        S->>U: Send intermediate CA CSR
        U-->>S: Intermediate CA certificate
    end

    W->>A: Request X509-SVID
    A->>A: Generate private key and CSR
    A->>S: Send CSR
    S->>K: Sign certificate with the <br/> intermediate CA private key
    K-->>S: Signed certificate
    S-->>A: Certificate
    A-->>W: Certificate and private key

In contrast to the JWT-SVID sequence, three distinct private keys are involved in this flow:

• The upstream authority possesses its own private key which is used to sign SPIRE server’s intermediate CA certificate; this private key is never seen by any Cofide or SPIRE component.

• The SPIRE server’s intermediate CA has its own associated private key for signing leaf certificates (i.e. X.509 SVIDs); this private key is stored in the configured key manager and never seen by any Cofide or SPIRE component (unless one of the basic ‘disk’ or ‘memory’ key manager plugins is used, in which case SPIRE server manages the private key).

• The workload’s SVID also has an associated private key which the workload must hold in order to prove to other parties that it is the subject of the certificate (e.g. during an mTLS handshake). This private key is generated by the SPIRE agent when the workload requests an SVID and is included in the SPIRE agent’s response to the workload’s SVID request using the local workload API (along with the signed X.509 leaf certificate). The workload’s private key is never seen by SPIRE server or any other Cofide component.