Envoy: Support SPIFFE URI validation in SAN

[ramaraochavali]

Currently Envoy supports exact match while validating SAN field in certificates. However that is not sufficient if URI is a SPIFFE URI with multiple key value pairs.

For example if we have a SPIFFE URI as
spiffe//trust-domain/ns/test-namespace/svc/test-svc/env/some-env/pod/na-x/region/us-east-2

and we want our validation to ensure

• It starts with spiffe//<>
• It has key value pairs specifying the name-space, svc,env,pod and region (the highlighted ones in the above URI) to appear with some values.

The proposal is to extract the information SPIFFE URI in to a generic bag of key-value attributes extracted from the SAN and provide a structure similar to below where user can configure the attributes to match and values to match against.

  repeated string verify_subject_alt_name
  repeated SpiffeAttribute spiffeeAttributes

where SpiffeAttribute is a message that tells what key to validate , what to validate against and optionally match_type specifying whether to match with prefix wildcard (used for trust domains) or exact match.

message SpiffeAttribute
  string key 
  string value
  string match_type // probably just support exact or prefixed wild char

Relevant discussions https://github.com/envoyproxy/envoy/issues/3705

[ramaraochavali]

@PiotrSikora @rshriram @htuch created this issue

[ramaraochavali]

@mattklein123 Please assign this to me. I will work on it.

[heavypackets]

It has key value pairs specifying the name-space, svc,env,pod and region (the highlighted ones in the above URI) to appear with some values.

This second requisite you've noted for SPIFFE URI validation isn't stipulated by the SPIFFE specification: https://github.com/spiffe/spiffe/blob/master/standards/SPIFFE-ID.md

Key-value pairs included in the SPIFFE ID is tied to a specific implementation. Per the spec, the URI path is arbitrary. The SPIFFE project released demos, for example, do not use a key-value pair format and wouldn't parse down correctly into meaningful SpiffeAttributes. SpiffeAttributes, as described here, would be a misnomer. Envoy shouldn't be opinionated about SPIFFE ID path, IMHO.

[mcpherrinm]

I would expect SPIFFE validation to work like configuring a trust domain (& root to verify against), plus regex on the path, (or something simpler than a regex, like how you'd write an http route matcher).

We're still in the early days of scoping how we're using spiffe + envoy, but I don't think the alternating /foo/bar/foo/bar pattern is flexible enough for what we'd been thinking.

[ramaraochavali]

@heavypackets I agree that embedding a key-value in the path is an implementation and is not THE only way path can be defined. However if it is one of the supported types, can we control that via additional config like path-type : hierarchical_key_value ? And we can extends this to multiple implementations slowly? Envoy need not be opinionated about "a specific" SPIFFE ID path implementation but it can support multiple generally used path implementations.

@mcpherrinm The original proposal was to use regex on the SPIFFEID - however because of security challenges, it was not considered. See this https://github.com/envoyproxy/envoy/issues/3705 for more details.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

[lizan]

Reopening this per convo: https://envoyproxy.slack.com/conversation/C78M4KW76/p1539048347000100

[evan2645]

I signed up for envoyproxy slack organization to view the link above... for those who aren't a member of that organization already, please find below the conversation that was linked

lizan [Oct 8th at 6:25 PM]
No, I don’t think we do any wildcard match for URI SANs

Fuyuan Bie [1 day ago]
so sad. this is a common case I think.

Fuyuan Bie [1 day ago]
thank you.

lizan [1 day ago]
Feel free to open an issue, we can look into it

Rama [1 day ago]
There is already an open issue https://github.com/envoyproxy/envoy/issues/3883 which was closed by bot because of inactivity i gues

lizan [1 day ago]
@Rama are you still interested in working on that?

Rama [1 day ago]
Yes. But not in near future though. But the key is to get alignment on how it should work

[joeyb]

Rather than directly encoding spiffe-isms into the SAN verification config, would it make more sense to just add matcher support for SAN verification, using the same matcher plumbing used by the RBAC system?

Strawman proposal:

The SAN validation config would become:

  repeated string verify_subject_alt_name
  repeated envoy.type.matcher.UriMatcher verify_subject_alt_name_uri

And the new envoy.type.matcher.UriMatcher would look like:

message UriMatcher {
  oneof match_pattern {

    // ... other matchers like exact_domain or exact_path

    map<string, string> path_kvps
  }
}

That would provide support for the path-with-key-value-pairs approach, but not lock any part of envoy into that design.

That same matcher would similarly be useful in the RBAC system for enforcing constraints on the client's principal.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

[alexkreidler]

Hey, this seems like a big blocker in Envoy for supporting SPIFFE IDs.

If I want to trust my entire trust domain, I'd love to just set

verify_subject_alt_name: "spiffe://mydomain.com/*"

It seems like there has been a lot of discussion about this but no real progress:

Issues: https://github.com/envoyproxy/envoy/issues/3705, https://github.com/envoyproxy/envoy/issues/3883, https://github.com/envoyproxy/envoy/issues/1272

PRs: https://github.com/envoyproxy/envoy/pull/3858