Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues while using disk as upstream plugin #5828

Open
vinod-ps opened this issue Jan 30, 2025 · 1 comment
Open

Issues while using disk as upstream plugin #5828

vinod-ps opened this issue Jan 30, 2025 · 1 comment
Labels
triage/in-progress Issue triage is in progress

Comments

@vinod-ps
Copy link

vinod-ps commented Jan 30, 2025

Hi All,
I would like to understand the usage of Disk as for upstream to PKI.
I have an offline RootCA and generated an intermediate Certificate for spire server.
Then I updated the SPIRE helm to use the disk and provided the intermediate CA signed from my root and intermediate private key.
when I verified the SVID of a workload, it looks like somehow the spire is not taking the certificate correctly because I can see the Intermediate certificate's serial number and thumbprint is different from what I have provided in the input yaml, but the name and subject matches.

Copy of my testing yaml is : https://github.com/vinod-ps/SPIRE_SPIFFE/blob/main/helm-charts-hardened-1/charts/spire/charts/spire-server/values.yaml

Am I missing something?
Thanks in advance

@vinod-ps vinod-ps changed the title Clarification on using Disk for upstream plugin Issues while using disk as upstream plugin Jan 30, 2025
@sorindumitru
Copy link
Collaborator

The UpstreamAuthority plugin serves as the certificate authority for spire-server, but not for workloads. Generally the flow goes like:

  • spire-server creates a new key using the configured KeyManager plugin
  • spire-server signs it's own intermediate CA backed by the key above using the UpstreamAuthority plugin
  • spire-server signs workload SVIDs using the intermediate CA it signed.

So in your case the certificate chain will look like this:
SVID -> SPIRE Intermediate CA -> Your Intermediate CA -> Root CA

The reason SPIRE does this is because it wants to have some control over how often the SPIRE intermediate CA is rotated. Ideally this should be rotated more often and is controlled by the ca_ttl configuration (defaulting to 24h).

@amartinezfayo amartinezfayo added the triage/in-progress Issue triage is in progress label Jan 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triage/in-progress Issue triage is in progress
Projects
None yet
Development

No branches or pull requests

3 participants