Author: Lisa

Wonderful Timing

Anya and I went to the grocery store. Scott called while I was driving home and told me not to panic if I saw a bunch of police cars when I turned near the house. Umm, good to know! I certainly would have panicked. We got fiber internet installed at the farmhouse and set up our security cameras a few weeks ago. And, evidently, a couple of people decided tonight that it was a good place to break into. Scott got a motion alert & pulled up the video to see three people at the back door. And in the kitchen, front room, side room, back into the kitchen. He called the police and headed down to the farmhouse. They’d arrested three people by the time he got down there.

SPIFFE: Prove the Configuration Rejects Abuse: Negative Security Testing

A security architecture should be judged by rejection behavior, not only by a successful demonstration. Each test below states a precondition, an enforcement point, and evidence to collect. The exact HTTP status or OAuth error depends on the failing stage and implementation; do not require a universal error code where the standards or product do not prescribe one.

Test environment and positive controls

Use isolated non-production identities and resources. Establish a successful standalone call and a successful Lisa/XYZ delegated call first. Capture the issued token’s approved claims without copying credentials into ordinary logs. Confirm the actual policy version and key material in use. Change one condition per test where possible, and retain request correlation so failures can be attributed to the intended control.

Where a deployment does not implement a proposed control, mark the corresponding test as an identified gap or accepted risk, not a false pass. Sender-constraint tests require a genuinely supported profile. Task-authorization tests require the resource server to implement that policy.

ID Input or precondition Enforcement point Expected outcome/evidence
01 Actor token from untrusted issuer STS actor validation Reject; log issuer-policy failure
02 Actor JWT-SVID with wrong STS audience STS actor validation Reject; intended-recipient failure
03 Human JWT substituted as actor evidence STS profile validation Reject; cross-profile failure
04 Workload JWT substituted as human subject STS subject validation Reject; subject-profile failure
05 Unsigned or disallowed-algorithm JWT STS/API signature policy Reject; algorithm/signature failure
06 Token with attacker-controlled key URL Configured key-resolution boundary No outbound trust in supplied URL; reject invalid signature
07 Expired input token STS time validation Reject; expiration failure
08 Input not yet valid outside allowed skew STS time validation Reject; temporal-policy failure
09 Output token presented to wrong API Resource audience validation Reject; audience mismatch
10 Forged act claim on signed token Resource signature validation Reject; modified token
11 Caller actor override differs from verified identity STS mapping/policy Reject or ignore override under explicit policy; no forged attribution
12 Client/actor pairing forbidden by policy STS relationship policy Reject; pairing decision recorded
13 XYZ paired with ineligible Lisa delegation STS approval/pairing policy Reject; subject/actor eligibility failure
14 Unauthorized output audience requested STS target policy Reject; disallowed exchange edge
15 Scopes exceed approved grant STS scope policy Reject or explicitly downscope; record granted set
16 Missing actor on delegated-only API API delegated-profile policy Reject; required-actor failure
17 Malformed nested actor structure STS/API schema validation Reject; malformed identity context
18 Nested actor has privileged identity API authorization engine No privilege union; deny operation not allowed by top-level context
19 Valid token mutates wrong case API object authorization Reject; resource mismatch
20 Valid token changes forbidden field API mutation authorization Reject; actual-body constraint failure
21 Approval expired before exchange STS approval service Reject; stale grant
22 Approval revoked after token issuance API current-grant control if configured Reject within measured distribution/cache window
23 One-time authorization reused API transactional grant control No second mutation; atomic use evidence
24 Stolen bearer token presented elsewhere Resource authentication May succeed absent sender constraint; document residual risk
25 Wrong certificate for bound token mTLS/token-binding verifier Reject; certificate-thumbprint mismatch
26 Wrong DPoP key or token hash DPoP-capable resource Reject; proof/token binding failure
27 Replayed DPoP proof DPoP replay/freshness verifier Reject per deployed replay policy; proof evidence
28 Unknown kid during discovery outage STS/API key validation Reject unknown key; bounded refresh attempts
29 Planned key rollover with old/new tokens STS/API verification caches Valid intended tokens pass during planned overlap
30 Disabled actor uses cached valid JWT Resource deny/revocation controls Measure rejection latency; no unsupported instant-revocation claim
31 Workload does not match registration selectors SPIRE workload issuance No XYZ credential; attestation/issuance evidence
32 Unrelated pod chooses XYZ service account Admission/RBAC plus SPIRE policy Blocked deployment or deny issuance; otherwise record privilege gap
33 Unauthorized node attempts enrollment SPIRE node attestation No accepted eligible agent identity
34 Queued job runs after delegation revoked Worker authorization boundary Reject execution; log job and approval IDs
35 Tenant/resource identifier substitution STS and resource tenant policy Reject cross-tenant access
36 Policy/STS outage triggers retry fallback Application/worker failure path No anonymous or broader-authority fallback

 

Acceptance criteria

  • Every failure occurs at a documented boundary and emits useful non-secret audit evidence.
  • No test silently changes a delegated request into impersonation or anonymous access.
  • No requested audience or scope becomes trusted merely because it was requested.
  • Resource-level constraints are checked against the actual operation and canonical object.
  • Revocation and outage tests report measured windows, not assumed guarantees.
  • Concurrent one-time execution tests demonstrate atomic behavior.
  • Known valid controls still pass after policy tightening and planned key rotation.

Adversarial execution and evidence

Repeat tests with concurrency, stale caches, alternate replicas, and retrying workers. Exercise non-happy-path serialization and identifier normalization. Confirm that every API instance uses the same intended policy version. Capture both denial and business-state evidence: a rejected response is insufficient if a mutation occurred before the rejection.

Takeaway: a useful test report says where abuse was blocked, why, what residual exposure remains, and how quickly changes reach every enforcement point.

Genealogical Research for Our Property

We’ve tracked our property history through the recorder’s office, but I’ve discovered that the Medina library has USDA aerial photos from the 1930’s, 1950’s, 1960’s, and 1970’s (they skipped the 1940’s due to the war). There is an index image that provides the photo identifier for each rectangle — so we’d take the index photo, find our number, and then pull the detail picture.

Our property in the 1930’s!

SPIFFE: Rotation Without Outages: Credential and Trust-Material Lifecycle

Automatic rotation removes manual renewal work, not lifecycle complexity. Your acceptance tests must cover planned rotation, unknown signing keys, transient outages, and the interaction between credentials issued at different layers.

Separate the trust-material paths

X.509-SVID verification uses certificate trust material. JWT-SVID verification uses the corresponding JWT signing public keys. An OIDC discovery/JWKS integration can expose JWT verification metadata for consumers, but an X.509 bundle is not interchangeable with a JWKS document. Document exactly which discovery component is deployed and how PingFederate trusts it.

Review discovery issuer association, TLS trust, permitted metadata endpoints, cache limits, and key rollover behavior. A kid identifies a candidate key; it does not make a key trustworthy. Do not follow arbitrary jku or x5u values from untrusted token input. Bind verification material to configured issuers.

Plan overlap and bounded refresh

Recommended sequence: publish the new verification key, allow intended verifiers to acquire it, begin signing with it, and retain old verification material for the remaining lifetime of valid old tokens plus permitted skew and bounded propagation delays. Confirm the actual signing-key publisher behavior rather than assuming it follows this sequence. Emergency compromise rollover requires a different plan because retaining the old key preserves trust in forged tokens.

On unknown kid, perform a bounded, issuer-specific refresh if supported. If the key remains unknown, deny the token. Rate-limit and coalesce refreshes to prevent attacker-controlled kid values from turning verification into a discovery-service denial of service. Valid cached material may remain usable within a documented policy; this is not permission to extend token expiration or trust unknown keys.

Failure and recovery matrix

Condition Recommended behavior Evidence to collect
SPIRE unavailable No fabricated credentials; use only still-valid material under policy Issuance failures and remaining lifetime
STS unavailable Do not bypass exchange or broaden authority Exchange failures and job/backoff behavior
Discovery unavailable Bounded cache use; reject unknown keys Cache age and refresh outcomes
Clock skew Enforce reviewed bounded leeway Clock offset and time-validation failures
Old signing key removed Observe rejected old credentials; follow planned policy Affected kid and issuer
Policy distribution unavailable Explicit fail behavior, never implicit permit Policy version and stale-state duration

 

Sender binding complicates credential rotation

RFC 8705 certificate-bound access tokens use the thumbprint of a specific client certificate. Binding to an X.509-SVID certificate therefore binds that token to that particular certificate, not merely to its stable SPIFFE ID. Coordinate token renewal and certificate rotation, and avoid a gap where only a replacement certificate remains but the access token expects the old one.

DPoP is an alternative sender-constraint mechanism only where the issuer and resource server support the agreed profile. Its key lifecycle is separate from SPIRE certificate rotation. Do not imply that configuring SPIRE automatically enables DPoP in PingFederate or a downstream API.

Connections and authorization lifetime

Established TLS connections and application sessions need their own lifecycle review. A certificate rollover is not guaranteed to trigger a new authentication handshake on every existing connection. Decide whether token authorization is evaluated per request, once per connection, or when a session is created; verify the implementation. Connection draining and maximum session duration may be needed for predictable containment.

  • Exercise a planned rotation under normal load.
  • Test new-key visibility before switching signers.
  • Measure clock offsets and verification-cache behavior.
  • Simulate dependency outages without allowing permissive fallbacks.
  • Prove emergency issuer compromise response separately from routine rollover.

Takeaway: rotation must be tested as a distributed protocol, including consumers and their caches.

SPIFFE: Can We Reconstruct What Happened? Audit and Investigation

A useful audit trail must reconstruct whose authority applied, which software acted, what was approved, and what actually changed. A single username field cannot represent that model.

Create a verified request-scoped identity

At authentication, construct an immutable context from validated claims or trusted introspection: subject with issuer, current actor, prior actor history, OAuth client, transport peer, delegation reference, token identifier, granted constraints, and policy version. Propagate it through authorization and business-event logging. Do not use a mutable global user context across concurrent requests or workers.

For delegated tokens, the outermost act identifies the current actor; nested actors represent earlier actors. Prior actors are informational rather than an additional permission source. Preserve history for traceability without authorizing from a union of actor privileges.

A proposed structured business event

{
"event": "case.update",
"identity_mode": "user_delegation",
"effective_subject": {
"issuer": "https://identity.example.org",
"id": "user:lisa"
},
"current_actor": {
"id": "spiffe://agents.example.org/agent/xyz"
},
"transport_peer": "spiffe://services.example.org/tool/case-editor",
"oauth_client_id": "agent-xyz-client",
"delegation_id": "approval-81a6",
"token_id": "token-4b781",
"request_id": "req-a740",
"agent_run_id": "run-93a2",
"resource": "case/4821",
"authorization": {
"decision": "allow",
"policy_version": "case-policy-17"
},
"outcome": "committed"
}

These field names are recommendations, not a standards-defined event schema. A run ID helps correlation but does not prove identity. A token ID helps join events but does not make a token single-use. One-time semantics require protected state and atomic consumption at the appropriate transaction boundary.

One approval, five API calls

Call Observed behavior Expected investigation conclusion
1 Read case/4821 under approved read authority Authorized read, if included in approval
2 Update status on case/4821 Authorized mutation and committed result
3 Update another field on case/4821 Denied field-level violation
4 Update case/9920 Denied resource mismatch
5 Repeat one-time status update Denied replay or recorded idempotent retry under policy

 

Join the approval event, STS decision, API decision, and business commit. A 200 response in an agent trace does not independently prove a database commit. An authorization allow does not prove the operation succeeded. Conversely, a failed response after a commit can cause a retry; the audit model must distinguish this from deliberate duplicate execution.

Background work and provenance

Queue messages should reference a protected grant and carry authenticated provenance. Re-evaluate permission when the worker executes. Record the originating agent and current worker separately, because the worker may become the current actor in a new token exchange. Preserve request and job correlation without trusting identity fields supplied by arbitrary producers.

Mark log fields by provenance: token-verified, authorization-service-issued, infrastructure-derived, or application-supplied. This prevents an agent-provided display name from being mistaken for the verified SPIFFE actor. Use stable identifiers for joins and display names only for presentation.

Logging controls

  • Never log bearer tokens, private keys, or full authorization headers.
  • Redact business payloads and approval details according to sensitivity.
  • Record denied attempts as well as successful operations.
  • Protect log transport, administrative access, and retention configuration.
  • Synchronize clocks and retain event time separately from ingestion time.
  • Version audit schemas and ensure downstream parsers preserve nested identity context.
  • Record configuration/policy changes so investigators can reconstruct the decision in force.

Takeaway: attribution becomes useful only when it survives all the way to the committed business event.

SPIRE Setup Documentation

Overview

This setup deploys SPIRE as follows:

  • SPIRE Server on <SPIRE_SERVER_HOST>
  • SPIRE Agent on <SPIRE_AGENT_HOST>
  • Trust domain: <TRUST_DOMAIN>
  • Server/agent communication port: <SERVER_PORT>/tcp

How it works

SPIRE provides machine and workload identity.

The SPIRE Server on <SPIRE_SERVER_HOST> is the trust authority for the trust domain <TRUST_DOMAIN>.

The SPIRE Agent on <SPIRE_AGENT_HOST> attests to the server using x509pop with an X.509 certificate issued by an enterprise/internal CA.

Applications on <SPIRE_AGENT_HOST> do not talk directly to the SPIRE Server. They talk to the local SPIRE Agent over the local workload API socket <AGENT_SOCKET_PATH>.

The agent returns an X.509-SVID representing the workload identity.

Installation Instructions

  1. Install SPIRE binaries

Run on both hosts:

mkdir -p /opt/spire
cd /tmp
wget https://github.com/spiffe/spire/releases/download/v1.15.2/spire-1.15.2-linux-amd64-musl.tar.gz
tar zxf spire-1.15.2-linux-amd64-musl.tar.gz
cp -r spire-1.15.2/. /opt/spire/

On the SPIRE Server host:

ln -sf /opt/spire/bin/spire-server /usr/bin/spire-server

On the SPIRE Agent host:

ln -sf /opt/spire/bin/spire-agent /usr/bin/spire-agent

  1. Configure SPIRE Server

Create directories:

mkdir -p /opt/spire/conf
mkdir -p /opt/spire/data/server
mkdir -p /opt/spire/conf/x509pop

Place the CA bundle at:

/opt/spire/conf/x509pop/bundle.pem

Contents:

—–BEGIN CERTIFICATE—–
<REDACTED CA CERTIFICATE>
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
<REDACTED CA CERTIFICATE>
—–END CERTIFICATE—–
—–BEGIN CERTIFICATE—–
<REDACTED CA CERTIFICATE>
—–END CERTIFICATE—–

Create /opt/spire/conf/server.conf:

server {
bind_address = “0.0.0.0”
bind_port = “<SERVER_PORT>”
trust_domain = “<TRUST_DOMAIN>”
data_dir = “/opt/spire/data/server”
log_level = “INFO”
}

plugins {
DataStore “sql” {
plugin_data {
database_type = “sqlite3”
connection_string = “/opt/spire/data/server/datastore.sqlite3”
}
}

NodeAttestor “x509pop” {
plugin_data {
ca_bundle_path = “/opt/spire/conf/x509pop/bundle.pem”
}
}

KeyManager “memory” {
plugin_data {}
}
}

health_checks {
listener_enabled = true
bind_address = “127.0.0.1”
bind_port = “<HEALTH_PORT>”
}

Create /etc/systemd/system/spire-server.service:

[Unit]
Description=SPIRE Server
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/spire/bin/spire-server run -config /opt/spire/conf/server.conf
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Start server:

systemctl daemon-reload
systemctl enable –now spire-server
systemctl status spire-server –no-pager

Validate server:

spire-server healthcheck

  1. Configure SPIRE Agent

Create directories:

mkdir -p /opt/spire/conf
mkdir -p /opt/spire/data/agent
mkdir -p /opt/spire/sockets
mkdir -p /opt/spire/conf/x509pop

Issue a certificate through your enterprise PKI platform. Download as OpenSSL format and split CRT/KEY files. Copy the node certificate to:

/opt/spire/conf/x509pop/agent.crt

Copy the node private key to:

/opt/spire/conf/x509pop/agent.key

The private key must be unencrypted PEM.

Set permissions:

chmod 700 /opt/spire/conf/x509pop
chmod 600 /opt/spire/conf/x509pop/agent.key
chmod 644 /opt/spire/conf/x509pop/agent.crt

Create /opt/spire/conf/agent.conf:

agent {
data_dir = “/opt/spire/data/agent”
log_level = “INFO”
trust_domain = “<TRUST_DOMAIN>”
server_address = “<SPIRE_SERVER_HOST>”
server_port = “<SERVER_PORT>”
socket_path = “<AGENT_SOCKET_PATH>”
insecure_bootstrap = true
}

plugins {
KeyManager “disk” {
plugin_data {
directory = “/opt/spire/data/agent”
}
}

WorkloadAttestor “unix” {
plugin_data {}
}

NodeAttestor “x509pop” {
plugin_data {
private_key_path = “/opt/spire/conf/x509pop/agent.key”
certificate_path = “/opt/spire/conf/x509pop/agent.crt”
}
}
}

Create /etc/systemd/system/spire-agent.service:

[Unit]
Description=SPIRE Agent
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/spire/bin/spire-agent run -config /opt/spire/conf/agent.conf
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Start agent:

systemctl daemon-reload
systemctl enable –now spire-agent
systemctl status spire-agent –no-pager

  1. Validate x509pop agent attestation

On the SPIRE Server host:

spire-server agent list

Expected result:

  • Agent attestation type is x509pop
  • Can re-attest is true
  • Parent ID format resembles:

spiffe://<TRUST_DOMAIN>/spire/agent/x509pop/<AGENT_HASH>

  1. Create workload registration entry

Use the current x509pop agent SPIFFE ID from spire-server agent list.

On the SPIRE Server host:

spire-server entry create \
-spiffeID spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME> \
-parentID spiffe://<TRUST_DOMAIN>/spire/agent/x509pop/<AGENT_HASH> \
-selector unix:uid:0

This authorizes a root-owned process on the SPIRE Agent host.

  1. Fetch workload identity on the SPIRE Agent host

/opt/spire/bin/spire-agent api fetch x509 -socketPath <AGENT_SOCKET_PATH>

Expected SPIFFE ID:

spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME>

  1. Write certs to disk for testing

Create destination directory:

mkdir -p /etc/spire/svid/test
chmod 700 /etc/spire/svid/test

Write files:

/opt/spire/bin/spire-agent api fetch x509 \
-socketPath <AGENT_SOCKET_PATH> \
-write /etc/spire/svid/test

Inspect output:

ls -l /etc/spire/svid/test

openssl x509 -in /etc/spire/svid/test/svid.0.pem -text -noout

  1. Reboot persistence validation

Reboot the SPIRE Agent host.

After reboot, validate:

systemctl status spire-agent –no-pager

ls -l <AGENT_SOCKET_PATH>

/opt/spire/bin/spire-agent api fetch x509 -socketPath <AGENT_SOCKET_PATH>

Expected behavior:

  • spire-agent starts automatically
  • Workload API socket exists
  • X.509-SVID fetch succeeds
  1. Operational notes
  • Current architecture: <SPIRE_SERVER_HOST> = SPIRE Server; <SPIRE_AGENT_HOST> = SPIRE Agent
  • Current trust domain: <TRUST_DOMAIN>
  • Current server/agent path: <SPIRE_AGENT_HOST> to <SPIRE_SERVER_HOST> on TCP <SERVER_PORT>
  • Current Workload API socket: <AGENT_SOCKET_PATH>
  • Current example workload selector: unix:uid:0
  • Current example workload identity: spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME>

JWT

Create JWT registration on the SPIRE Server host:

spire-server entry create \
-spiffeID spiffe://<TRUST_DOMAIN>/workload/<JWT_WORKLOAD_NAME> \
-parentID spiffe://<TRUST_DOMAIN>/spire/agent/x509pop/<AGENT_HASH> \
-selector unix:uid:0

Fetch JWT-SVID from the SPIRE Agent host:

/opt/spire/bin/spire-agent api fetch jwt \
-socketPath <AGENT_SOCKET_PATH> \
-audience <JWT_AUDIENCE> \
-spiffeID spiffe://<TRUST_DOMAIN>/workload/<JWT_WORKLOAD_NAME>

Example output:

token(spiffe://<TRUST_DOMAIN>/workload/<JWT_WORKLOAD_NAME>):
<REDACTED JWT-SVID>

bundle(spiffe://<TRUST_DOMAIN>):
<REDACTED JWKS BUNDLE>

SPIRE OIDC Discovery Provider

On the SPIRE Server host:

mkdir -p /opt/spire-extras
cd /tmp
wget https://github.com/spiffe/spire/releases/download/v1.15.2/spire-extras-1.15.2-linux-amd64-musl.tar.gz
tar zxf spire-extras-1.15.2-linux-amd64-musl.tar.gz
cp -r spire-extras-1.15.2/ /opt/spire-extras/

ln -sf /opt/spire-extras/bin/oidc-discovery-provider /usr/bin/oidc-discovery-provider
mkdir -p /opt/spire-extras/conf/oidc-discovery-provider

Create certificate and key files:

/opt/spire-extras/conf/oidc-discovery-provider/tls.crt
/opt/spire-extras/conf/oidc-discovery-provider/tls.key

Set permissions:

chmod 644 /opt/spire-extras/conf/oidc-discovery-provider/tls.crt
chmod 600 /opt/spire-extras/conf/oidc-discovery-provider/tls.key

Create /opt/spire-extras/conf/oidc-discovery-provider/oidc-discovery-provider.conf:

log_level = “INFO”

domains = [“<OIDC_DISCOVERY_DOMAIN>”]

server_api {
address = “unix://<SPIRE_SERVER_API_SOCKET>”
}

serving_cert_file {
cert_file_path = “/opt/spire-extras/conf/oidc-discovery-provider/tls.crt”
key_file_path = “/opt/spire-extras/conf/oidc-discovery-provider/tls.key”
}

Create /etc/systemd/system/spire-oidc-discovery-provider.service:

[Unit]
Description=SPIRE OIDC Discovery Provider
After=network-online.target spire-server.service
Wants=network-online.target

[Service]
Type=simple
ExecStart=/opt/spire-extras/bin/oidc-discovery-provider -config /opt/spire-extras/conf/oidc-discovery-provider/oidc-discovery-provider.conf
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Ping Integration

PingFederate Integration Note for SPIRE JWT Validation

Purpose

Configure PingFederate to trust and validate JWTs issued from the SPIRE environment.

SPIRE issuer details

Use these values:

  • Issuer: https://<OIDC_DISCOVERY_DOMAIN>
  • OIDC discovery URL: https://<OIDC_DISCOVERY_DOMAIN>/.well-known/openid-configuration
  • JWKS URL: https://<OIDC_DISCOVERY_DOMAIN>/keys

Trust model

PingFederate should validate JWT signatures using the JWKS published by the SPIRE OIDC Discovery Provider.

Ping does not need to call the SPIRE server directly for every token validation. It should use the discovery/JWKS metadata from the OIDC Discovery Provider.

Expected JWT characteristics

Issuer

Ping should require:

iss = https://<OIDC_DISCOVERY_DOMAIN>

Audience

Recommended audience value:

<PING_AUDIENCE>

Clients requesting JWT-SVIDs from SPIRE should request them with this audience.

Subject

The workload identity will be in:

sub

Example:

spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME>

This is the primary identity claim Ping should use to identify the calling workload.

Recommended validation rules in Ping

Validate:

  • JWT signature against SPIRE JWKS
  • iss matches https://<OIDC_DISCOVERY_DOMAIN>
  • aud contains <PING_AUDIENCE>
  • token is within validity window (exp, iat)
  • sub is an allowed SPIFFE ID or matches allowed policy rules

Example workload identity currently in use

Current example SPIFFE ID:

spiffe://<TRUST_DOMAIN>/workload/<WORKLOAD_NAME>

Client-side JWT retrieval model

A workload on the SPIRE Agent host should obtain its JWT from the local SPIRE agent, not from the SPIRE server directly.

Local agent socket:

<AGENT_SOCKET_PATH>

Example operational flow

  1. Workload on the SPIRE Agent host requests a JWT-SVID from the local SPIRE agent.
  2. JWT-SVID is issued with:
  • issuer = https://<OIDC_DISCOVERY_DOMAIN>
  • audience = <PING_AUDIENCE>
  • subject = workload SPIFFE ID
  1. Workload presents JWT to PingFederate.
  2. PingFederate validates the JWT using SPIRE OIDC discovery/JWKS.
  3. PingFederate maps the SPIFFE workload identity to access policy, token issuance, or downstream application authorization.

 

 

Voting Philosophy

Sure, it sucks to vote for the “least bad”, but that is better than being governed by the worst.

Vote for the person who is closer to where you think we should be instead of the waiting for your perfect candidate.