You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Future SPIRE, preferable back-port to supported minor versions.
Platform:
All supported platforms
Subsystem:
Server
Brief
The SPIRE server rejects any attempt to creating a service entry with a DNS contains wildcard. Therefore it doesn't issue wildcard certificate. Understand that this issue has been raided in #1809. And @evan2645 addressed in this comment: #1809 (comment)
I'd like to provide a case of the usage of wildcard certificate.
Case
I'm using SPIFFE/SPIRE as the workload identity provider for Istio. SPIRE infrastructure issue the SVID for both workloads' proxies as well as ingress gateway, which itself is a istio-proxy (envoy).
Once ingress gateway's SDS is configured to the spire-agent, I'm able to issue key materials for TLS termination (as well as mTLS). However, the certificate is limited to support the host names that are defined in the DNS fields (SAN). I haven't tested the max supported amount of SANs, but I believe there is a limitation to it.
A wildcard certificate makes it easier to support this scenario. This allows us to:
Support host based routing;
Issue all key material from spire-agent without using kubernetes secret, which is inherently insecure.
The text was updated successfully, but these errors were encountered:
Future SPIRE, preferable back-port to supported minor versions.
All supported platforms
Server
Brief
The SPIRE server rejects any attempt to creating a service entry with a DNS contains wildcard. Therefore it doesn't issue wildcard certificate. Understand that this issue has been raided in #1809. And @evan2645 addressed in this comment: #1809 (comment)
I'd like to provide a case of the usage of wildcard certificate.
Case
I'm using SPIFFE/SPIRE as the workload identity provider for Istio. SPIRE infrastructure issue the SVID for both workloads' proxies as well as ingress gateway, which itself is a istio-proxy (envoy).
Once ingress gateway's SDS is configured to the spire-agent, I'm able to issue key materials for TLS termination (as well as mTLS). However, the certificate is limited to support the host names that are defined in the DNS fields (SAN). I haven't tested the max supported amount of SANs, but I believe there is a limitation to it.
A wildcard certificate makes it easier to support this scenario. This allows us to:
The text was updated successfully, but these errors were encountered: