☔ SPIFFE compliance

[lahabana]

Description

Currently we're not fully SPIFFE compliant because we generate certs with many SANs:

kuma/pkg/core/ca/issuer/issuer.go

Lines 57 to 108 in 1175d23

	func newWorkloadTemplate(trustDomain string, tags mesh_proto.MultiValueTagSet, publicKey crypto.PublicKey, certOpts ...CertOptsFn) (*x509.Certificate, error) {
	var uris []*url.URL
	for _, service := range tags.Values(mesh_proto.ServiceTag) {
	domain, err := spiffeid.TrustDomainFromString(trustDomain)
	if err != nil {
	return nil, err
	}
	uri, err := spiffeid.FromSegments(domain, service)
	if err != nil {
	return nil, err
	}
	uris = append(uris, uri.URL())
	}
	for _, tag := range tags.Keys() {
	for _, value := range tags.UniqueValues(tag) {
	uri := fmt.Sprintf("kuma://%s/%s", tag, value)
	u, err := url.Parse(uri)
	if err != nil {
	return nil, errors.Wrap(err, "invalid Kuma URI")
	}
	uris = append(uris, u)
	}
	}
	now := time.Now()
	serialNumber, err := newSerialNumber()
	if err != nil {
	return nil, err
	}
	template := &x509.Certificate{
	SerialNumber: serialNumber,
	// Subject is deliberately left empty
	URIs: uris,
	NotBefore: now.Add(-DefaultAllowedClockSkew),
	NotAfter: now.Add(DefaultWorkloadCertValidityPeriod),
	KeyUsage: x509.KeyUsageKeyEncipherment |
	x509.KeyUsageKeyAgreement |
	x509.KeyUsageDigitalSignature,
	ExtKeyUsage: []x509.ExtKeyUsage{
	x509.ExtKeyUsageServerAuth,
	x509.ExtKeyUsageClientAuth,
	},
	BasicConstraintsValid: true,
	PublicKey: publicKey,
	}
	for _, opt := range certOpts {
	opt(template)
	}
	return template, nil
	}

This prevents us from supporting things like SPIRE, it's also very different from what other meshes do.

Draft design

For verification:

• It should be able to pass in a MeshTLS resource a list of trustDomains with their CA (potentially composable from multiple instances).
• Keep in mind that in the future CA for trustDomains may come from different places (.e.g SPIRE).

For issuing DP certs:

• Specify a trustDomain per generator (and potentially a format).
• Ideally having one trustDomain per zone should be possible (and maybe even default).
• How can we make things straightforward so that people don't have to deal with doing many things whenever they add a new zone?

Also I think the point above makes it fairly obvious that we need to move cert config outside the mesh.

Acceptance criteria:

Once this is implemented users can start generating certs using existing CA provider that are 100% SPIFFE compliant (see spiffe docs).
Meaning that with a MeshProxyPatch and a bit of fiddling you could start using SPIRE instead of our own CA provider.

Using these kind of certs should be a feature flag to allow easy migration.

Out of scope

• Have inbound policies support Spiffe matching (this will be done in a separate work stream).
• Support trustDomains outside of Kuma managed ones (it's likely going to be possible once implemented but this doesn't have to be implemented here).

xref:

• Add a way to identify an application #12095 (this would enable to group multiple spiffe under 1 workload).
• MeshTrafficPermission MADR for spec.rules[].matches #12374 (once we have this we can add matching on SPIFFE ID and prefix)
• https://github.com/Kong/kong-mesh/issues/6664 with SPIFFE certs we can support external trust-domains.