Integration tests should exist to test the usage of this plugin in a running Vault instance.

Initial list of things that should be tested

• Registering & enabling the plugin within Vault
• Logging in with both valid and invalid SVIDs
• Logging in with valid but expired SVIDs
• Logging in with valid SVIDs against expired trust sources

Describe the bug
The assumption in this line is that of all the URIs found in the SVID SAN blocks the first one will be for the workload. This is not necessarily true if the SVID contains multiple PEM blocks.

SVIDs will contain multiple PEM blocks if SPIRE service option upstream_bundle = true is set. Those additional PEM blocks contain the full chain of trust and while important for verification are not the appropriate SpiffeIDs to use when generating Vault policy IDs (discussed in #1). I'm unsure if SPIFFE guarantees the order of PEM blocks within an SVID (see spiffe/spiffe#32 for discussion about the order of SPIFFE IDs in a certificate).

As such, this assumption that the first PEM block contains the workload's SpiffeID is wrong.

uris := []string{}
for _, svidCert := range svidCerts {
  for _, uri := range svidCert.URIs {
    logrus.Info("Found URI: " + uri.String())
    uris = append(uris, uri.String())
  }
}

...

Metadata: map[string]string{
  "spiffeId": uris[0],
}

To Reproduce
Steps to reproduce the behavior:

1. Start SPIRE Server with upstream_bundle = true option.
2. Register a workload
3. Export/view SVID for workload
4. See that the SVID contains multiple PEM blocks.

Expected behavior
The extracted SpiffeID from the SVID should always be for the workload and not for another entry in the trust chain.

The plugin is designed to support multiple sources of trust used to verify SVIDs but currently the only implemented one is TrustFileSource.

Purpose: Track the implementation of a TrustSpireSource.

Goal

The goal of this to support Spire as a live source of trust for the plugin. The final implementation should be able to connect to one or more instances of Spire (via local agents or otherwise) in order to receive from Spire the known trust CAs that SVIDs can be verified against.

Background

Authentication using X509 SVIDs is a three-step process.

1. Prove client logging into Vault is the owner of the X509-SVID being passed in.
2. Prove the X509-SVID was generated by a trusted source.
3. Use the SPIFFE ID to generate a list of policies to apply to the session.

Step (1) occurs during the initial TLS connection between the client and Vault. The mechanisms of that connection result in the verification of the public X509-SVID certificate against the private key used to generate it. If that TLS connection can be made then ownership of the X509-SVID has been proven.

Steps (2) and (3) occur during the execution of this plugin. The plugin receives the X509-SVID certificate (and peers) via logical.Request object passed into the login/renew methods. The X509-SVID can then be verified against known trust sources using spiffe.VerifyPeerCertificate.

Problem

I've discovered there is a problem with this plan stemming from a faulty assumption. It appears that not all of the original TLS connection state is passed to plugins. Here, here, and here show that only the remote_addr is passed from Vault proper into Vault plugins. The faulty assumption stems from my original review of the existing built in TLS authentication method. Seen here this auth built-in plugin uses the peer information in its execution and I incorrectly assumed this information is available in all plugins. In fact, it is not if Vault interacts with the plugin via gRPC (which is the standard communication mechanism for non built-in plugins).

If the X509-SVID is not passed into the plugin via request.Connection.ConnState.PeerCertificates then the ownership of that certificate cannot be guaranteed, thus invalidating step (1).

Path Forward

It appears (though I have not confirmed) that the lack of additional TLS connection information passed to plugins is merely a result of "hasn't been added yet" and not "the information cannot be passed for reasons". If this is true then technically it would be possible to enhance Vault to pass such information to plugins. But, such an action expands the scope of this specific plugin and adds a version dependency. So this approach should not be taken lightly.

It may also be possible to instead enhance the existing TLS authentication built-in to support the usage of SPIFFE IDs. As far as I can tell (though I haven't dug super deep yet) the policies applied to the login/token are passed in as part of something with the certificate. I don't think this approach works well with our use-case (as it may require adding Vault logic to the generation of the certificate, which IMHO should be avoided). Instead, I'd like to find a way to use the SPIFFE ID contained in the certificate to generate the list of policies to apply to the login session.

One of the pieces of data returned from the pathAuthLogin method is a list of Vault policy ids to apply to the login session. A core component of this plugin will be to generate those policy IDs from the SPIFFE ID contained in the SVID.

Purpose: Discuss the logic used to convert a SPIFFE ID into a list of policy IDs.

Problem

Given some SPIFFE ID like spiffe://trust-domain/path what is the best way to generate a list of Vault policy IDs such that different structures of SPIFFE IDs and Vault policy IDs can be supported? Ideally this plugin will not place any unnecessary requirements on the structures of either of those identifiers (if any requirements at all).

Thoughts

I'd suggest that a static translation (ie, not able to take into account alternative structures) to be something to avoid. Ideally the plugin can support some level of translation logic provided by the administrators of the Vault instance, whether via code, plugin, or some type of templating.

The current implementation of SvidVerifier::Verify assumes the SVID will be an x509-SVID and doesn't consider the possibility of a JWT-SVID.

Purpose: This issue will track the discussion and implementation of one of the following

1. Implementation of support for JWT-SVID documents
2. Creation of clear documentation describing support for only x509-SVID documents

Describe the bug

Not all required validations of X509 based SVIDs are taking place. Specifically, the following are not happening:

• The certificate is a leaf certificate (I'm not 100% sure this check is occurring)
• CA field is set to false
• keyCertSign is not set
• cRLSign is not set

Per a conversation in the SPIFFE Slack workspace (#spire channel) the current thinking is that these validations should take place in the go-spiffe::VerifyPeerCertificate method. Issue spiffe/go-spiffe#25 has been created on that project to track the addition of those validations.

This ticket will ensure one of the following occurs:

1. Validations are added to VerifyPeerCertificates (spiffe/go-spiffe#25) and our dependency is changed to require at least the version with those validations.
2. The validations are added to this project (perhaps as a stopgap while waiting for closure of spiffe/go-spiffe#25).

The project currently doesn't include any tests of individual methods / classes and should.

Initial set of tests to add:

• Settings file parsing
• Loading invalid certificates from valid PEM files
• Loading invalid PEM files
• File Trust sources with
  • expired certificates
  • multiple certificates, both in multiple files and single files
• SVID Verification
  • where domain is not in trusted sources