Skip to main content

SPIFFE / SPIRE

Sectigo Edge uses SPIFFE as its workload identity contract and SPIRE as the preferred production implementation. Your existing SPIRE Server and Agents keep issuing and rotating X.509-SVIDs through the standard Workload API. Sectigo Edge adds registration review, policy, PKI lifecycle and evidence on top — and, when you enable it, a Mesh Node beside SPIRE Server turns approved service claims into SPIRE registration entries automatically.

What the integration does​

  1. A new service (using the Sectigo Edge SDK) announces itself to a nearby Mesh Node and proves possession of its key. An announcement alone never creates a SPIRE entry.
  2. An administrator reviews and claims it in ConsoleService claims with fresh MFA, approving only node-derived selectors.
  3. Sectigo Edge issues a short-lived, signed registration grant for that node.
  4. The node verifies the grant against its pinned registration trust (registration_trust_bundle_file, maximum lifetime registration_grant_max_ttl_seconds), re-derives the selectors from its own observation, and creates exactly one entry through the SPIRE Server Entry API over a local Unix socket.
  5. The node compares every returned field before reporting the entry as applied.
Sectigo Edge claim fieldSPIRE entry field
Approved SPIFFE IDspiffe_id
spire_parent_id from the node configurationparent_id
Node-observed runtime factsselectors
Maximum identity lifetimex509_svid_ttl / jwt_svid_ttl
Claim ID and announcement digestdeterministic entry hint

The connector treats both OK and ALREADY_EXISTS from SPIRE only as candidates, and accepts the result only if SPIFFE ID, parent, selectors, both TTLs, hint and every privilege-bearing field match. Unauthenticated TCP, join-token reuse and calling the SPIRE CLI are not supported.

Requirements​

  • A Linux or Kubernetes Mesh Node running on, or co-located with, the SPIRE Server, with access to the Server API socket. Windows nodes cannot enable this connector (configuration rejects it).
  • The SPIRE Server API Unix socket must not be a symbolic link or world-writable.
  • Workloads use the SPIRE Agent's Workload API (SPIFFE_ENDPOINT_SOCKET): a Unix socket on Linux, a named pipe on Windows. Windows workloads should discover a Linux/Kubernetes node adjacent to SPIRE Server so the same node observes the claim and applies the grant.

Prepare the host​

Confirm the socket path and permissions (example path):

spire-server-01 (bash)
ls -l /run/spire/server/private/api.sock
srw-rw---- 1 spire spire 0 Oct  1 09:12 /run/spire/server/private/api.sock

Grant the node's service identity access to that socket in a way your SPIRE operators approve (for example through group membership on Linux). Do not make the socket world-writable — the node refuses it.

Node configuration​

{
  "spire_enabled": true,
  "spire_server_api_socket": "/run/spire/server/private/api.sock",
  "spire_parent_id": "spiffe://acme-corp.example/spire/agent/k8s_psat/prod-cluster/node-01"
}

spire_server_api_socket must be absolute and spire_parent_id a valid SPIFFE ID. The values above are examples.

Configure in the console​

  1. Open ConsoleIntegrations and select Configure on SPIFFE identities.
  2. Select Enable this integration and choose the Linux/Kubernetes node(s) next to SPIRE Server.
  3. Keep or enter the identity profile (default workload-mtls). The Local adapter reference is fixed to builtin/spire.
  4. Select Save desired state.
  5. Review and claim new services in ConsoleService claims.
Verify and claim a service dialog with the human verification code, owner, profile, channels and SVID lifetimes
Claiming a service is the authorization step that leads to a SPIRE entry.

Policy and rotation​

SPIRE generates and rotates workload private keys and SVIDs; applications consume updates through the official SPIFFE libraries. Sectigo Edge does not run dual-slot rotation for SVIDs. The node only accepts grants signed by your registration authority and only within registration_grant_max_ttl_seconds; a policy signing key cannot create a workload identity. Cloud failback from the SDK is allowed only after a transport-level connection failure — an invalid SVID, signature, policy or authorization denial is final.

Verify​

  • The SPIFFE identities card shows Healthy.
  • After claiming a service, the entry exists in SPIRE:
spire-server-01 (bash)
spire-server entry show -spiffeID spiffe://acme-corp.example/ns/prod/sa/payments
Found 1 entry
Entry ID         : 3a7f2c1e-8b4d-4e9a-9c61-0f5d2b7e4a13
SPIFFE ID        : spiffe://acme-corp.example/ns/prod/sa/payments
Parent ID        : spiffe://acme-corp.example/spire/agent/k8s_psat/prod-cluster/node-01
Revision         : 0
X509-SVID TTL    : 3600
JWT-SVID TTL     : 300
Selector         : k8s:ns:prod
Selector         : k8s:sa:payments

(Example output; your selectors and TTLs come from the approved claim.) The node's Prometheus metrics edgepki_node_registration_sync_total and edgepki_node_registration_applied_total count synchronization attempts and applied grants.

Troubleshooting​

SymptomCauseFix
Node will not start: direct SPIRE Server Entry API reconciliation requires a Linux or Kubernetes Mesh Nodespire_enabled on a Windows nodeUse a Linux/Kubernetes node beside SPIRE Server
Node will not start: spire_server_api_socket must be absolute and spire_parent_id must be a valid SPIFFE ID when SPIRE is enabledInvalid configurationFix the two keys
Node will not start: SPIRE reconciliation initialization failedSocket missing, a symbolic link, world-writable or not accessibleFix the socket path and permissions
Card Degraded with spire_not_configuredThe assigned node does not have SPIRE enabledEnable it on that node or assign another node
Card Degraded with adapter_reference_invalidA reference other than builtin/spire was savedRe-save the integration
Claim approved but no entry appearsGrant rejected (wrong tenant/node, expired or untrusted) or SPIRE returned an entry that did not matchCheck the node log for reject untrusted service registration grant or apply service registration grant, and the registration sync metrics