Please describe the problem you have
Description
Use Case / Problem Statement
In Project Contour, there are currently two places where crypto/sha1 is used to generate deterministic, unique suffixes for Envoy resource names:
-
SDS Secrets (internal/envoy/secret.go):
Used in Secretname() to hash the raw TLS certificate bytes, ensuring certificate rotations trigger dynamic updates in Envoy.
// This isn't a crypto hash, we just want a unique name.
hash := sha1.Sum(s.Cert()) // nolint:gosec
-
CDS Clusters (internal/envoy/cluster.go):
Used in Clustername() to hash upstream cluster configuration attributes (timeouts, health checks, SNI, protocol, etc.) to deduplicate upstream clusters and prevent conflicts.
// This isn't a crypto hash, we just want a unique name.
hash := sha1.Sum([]byte(buf)) // nolint:gosec
While both locations correctly contain // nolint:gosec and explanatory comments clarifying that these are used purely as non-cryptographic checksums, highly regulated enterprise environments enforce strict automated security scanners. These scanners often flag any import or occurrence of crypto/sha1 in the compiled binary or dependencies and reject the binary outright, without analyzing the non-cryptographic context of the usage.
To help unblock the adoption of Contour in these compliance-sensitive environments, it would be highly beneficial to explore migrating these name-generation hashes away from SHA-1 to a compliant alternative (such as crypto/sha256 which is already imported and used elsewhere in these files, or another suitable hashing method).
Potential Impact (Brownfield Upgrades)
Because these hashes are baked into active resource names, changing the hashing algorithm during a rolling upgrade of a live production cluster introduces risks of traffic disruption:
- Contour Rolling Upgrade Flapping: Older Contour pods (generating SHA-1 names) and upgraded Contour pods (generating the new names) coexisting during an upgrade will cause Envoy to flap and repeatedly delete/recreate secret and cluster definitions.
- CDS Cluster Re-warming: For Envoy, a name change is a delete-and-create operation. New clusters must undergo DNS resolution and active health-check warming, which can lead to temporary
503 Service Unavailable errors for incoming traffic.
- Active Connection Draining: Long-lived connections (e.g. WebSockets, gRPC) routed to old SHA-1 cluster names will be terminated once those old clusters drain and are removed.
- SDS Desynchronization: If downstream listeners (LDS) update to point to new compliant secret names before SDS has pushed the new secrets, TLS handshakes will temporarily fail.
- Metric splits: Prometheus metrics and dashboards are keyed by cluster name; changing these names breaks historical metrics tracking.
Proposed Solution Idea
To address the compliance requirements without causing service disruptions for existing installations, a unified, phased migration approach could be considered:
- Feature Gate / Configuration: Add a single opt-in configuration option under
ContourConfiguration (e.g., enableCompliantNaming), defaulting to false (which retains the current SHA-1 names).
- Opt-in Phase: New (greenfield) deployments or compliance-restricted operators can toggle this to
true to immediately use the new compliant hash names.
- Default Transition: In a future major release of Contour, make this flag default to
true. This gives operators a clear transition path and ample warning in the upgrade/migration notes to prepare for a one-time cluster rotation and connection drain.
Please describe the problem you have
Description
Use Case / Problem Statement
In Project Contour, there are currently two places where
crypto/sha1is used to generate deterministic, unique suffixes for Envoy resource names:SDS Secrets (
internal/envoy/secret.go):Used in
Secretname()to hash the raw TLS certificate bytes, ensuring certificate rotations trigger dynamic updates in Envoy.CDS Clusters (
internal/envoy/cluster.go):Used in
Clustername()to hash upstream cluster configuration attributes (timeouts, health checks, SNI, protocol, etc.) to deduplicate upstream clusters and prevent conflicts.While both locations correctly contain
// nolint:gosecand explanatory comments clarifying that these are used purely as non-cryptographic checksums, highly regulated enterprise environments enforce strict automated security scanners. These scanners often flag any import or occurrence ofcrypto/sha1in the compiled binary or dependencies and reject the binary outright, without analyzing the non-cryptographic context of the usage.To help unblock the adoption of Contour in these compliance-sensitive environments, it would be highly beneficial to explore migrating these name-generation hashes away from SHA-1 to a compliant alternative (such as
crypto/sha256which is already imported and used elsewhere in these files, or another suitable hashing method).Potential Impact (Brownfield Upgrades)
Because these hashes are baked into active resource names, changing the hashing algorithm during a rolling upgrade of a live production cluster introduces risks of traffic disruption:
503 Service Unavailableerrors for incoming traffic.Proposed Solution Idea
To address the compliance requirements without causing service disruptions for existing installations, a unified, phased migration approach could be considered:
ContourConfiguration(e.g.,enableCompliantNaming), defaulting tofalse(which retains the current SHA-1 names).trueto immediately use the new compliant hash names.true. This gives operators a clear transition path and ample warning in the upgrade/migration notes to prepare for a one-time cluster rotation and connection drain.