Delegated Identity API SubscribeToX509BundlesResponse caCerts Format Error

[loveyana]

• Version: master
• Platform: Linux 5.10.76-linuxkit CLI authentication #1 SMP Mon Nov 8 10:21:19 UTC 2021 x86_64
• Subsystem: agent

In the SubscribeToX509Bundles request of the Delegated Identity API, all x509 certificates are appended to a [] byte in the marshalBundle method that handles rootCAs. This will cause the client side to be unable to split and format and save the ca certificate file normally. Just like the following way, I think we need to modify the marshalBundle method to
func marshalBundle (certs [] * x509. Certificate) [][]byte{} and modify grpc github.com/spiffe/spire-api-sdk/proto/spire/api/agent/delegatedidentity/v1/delegatedidentity.proto SubscribeToX509BundlesResponse map<string, repeated bytes> ca_certificates = 1;

pkg/agent/api/delegatedidentity/v1/service.go 210 line

	// send initial update....
	caCerts := make(map[string][]byte)
	for td, bundle := range subscriber.Value() {
		caCerts[td.IDString()] = marshalBundle(bundle.RootCAs())
	}

	resp := &delegatedidentityv1.SubscribeToX509BundlesResponse{
		CaCertificates: caCerts,
	}

pkg/agent/api/delegatedidentity/v1/service.go 250 line

func marshalBundle(certs []*x509.Certificate) []byte {
	bundle := []byte{}
	for _, c := range certs {
		bundle = append(bundle, c.Raw...)
	}
	return bundle
}

I am not sure if my understanding of this question is correct, I look forward to your reply~

[azdagron]

Returning concatenated ASN.1 encoded certificates is consistent with the fields used in the Workload API. Parsing concatenated ASN.1 certificate data is possible due to the way ASN.1 encoding works. In Go, you can use x509.ParseCertificates. With OpenSSL, you can use repeated calls to d2i_X509, which advances the buffer pointer on each invocation.

Please let me know if this is still problematic!

[loveyana]

@azdagron Thanks for your help, this problem has been solved perfectly.

Recently, I am developing a spire csi driver component based on the delegated Identity API and kuberentes csi. Do the community have any requirements or specifications for project contributions? It is still in the internal development stage, but if possible, I can provide our design documents.

[evan2645]

Recently, I am developing a spire csi driver component based on the delegated Identity API and kuberentes csi. Do the community have any requirements or specifications for project contributions? It is still in the internal development stage, but if possible, I can provide our design documents.

I'd (personally) love to see the design and would be happy to provide feedback!

This has been raised a few times in the past, and the general consensus from SPIRE maintainers has been to avoid file based SVID delivery whenever possible. You may have seen that we recently attempted to provide some functionality like this but eventually closed as won't fix due to complexities and edge cases involved.

So .. I think officially supporting a CSI driver for this purpose will be controversial. That said, I think we'd be happy to promote and provide links to your implementation if you're willing to open source and maintain it.

Last but not least .. I think there is a good compromise available, which is to use a CSI driver to inject a workload api socket into each container. It would involve a new RPC on delegated identity API that takes in a set of selectors and a path ... SPIRE Agent can then bind a socket at this path with the statically-provided set of selectors. The advantage is we can remove special privileges needed by SPIRE Agent (hostpid, hostnetwork), we can improve performance and reliability of workload api rpc calls... but I don't think this is your main complaint 😅