Skip to content

add compliance policy to gateway API #3671

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ramaraochavali wants to merge 1 commit into
base: master
Choose a base branch
from
+255 −25
Open

add compliance policy to gateway API #3671

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
60 changes: 60 additions & 0 deletions kubernetes/customresourcedefinitions.gen.yaml
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

17 changes: 17 additions & 0 deletions networking/v1/gateway_alias.gen.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

120 changes: 96 additions & 24 deletions networking/v1alpha3/gateway.pb.go
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

44 changes: 43 additions & 1 deletion networking/v1alpha3/gateway.pb.html
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

22 changes: 22 additions & 0 deletions networking/v1alpha3/gateway.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -579,4 +579,26 @@ message ServerTLSSettings {
// * `AES256-SHA`
// * `DES-CBC3-SHA`
repeated string cipher_suites = 9;

enum CompliancePolicy {
// FIPS_202205 configures a TLS connection to use:
//
// * TLS 1.2 or 1.3
// * For TLS 1.2, only ECDHE_[RSA|ECDSA]_WITH_AES_*_GCM_SHA*.
// * For TLS 1.3, only AES-GCM
// * P-256 or P-384 for key agreement.
// * For server signatures, only ``PKCS#1/PSS`` with ``SHA256/384/512``, or ECDSA
// with P-256 or P-384.
//
// .. attention::
//
// Please refer to `BoringSSL policies <https://boringssl.googlesource.com/boringssl/+/refs/tags/0.20240913.0/include/openssl/ssl.h#5608>`_
// for details.
FIPS_202205 = 0;
}

// Optional list of compliance policies. Compliance policies configure various aspects of the TLS
// based on the given policy. The policies are applied last during configuration and may override
// the other TLS parameters, or any previous policy.
repeated CompliancePolicy compliance_policies = 17;
Copy link
Copy Markdown
Member

@howardjohn howardjohn Mar 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is problematic on Gateway... I think the idea was this was a per-proxy setting or even global istiod setting. 1 pod can have multiple Gateways which would make this tricky. @keithmattix wdyt

Copy link
Copy Markdown
Contributor Author

@ramaraochavali ramaraochavali Mar 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you referring to the new Envoy compliance policy added to CommonTLSContext or compliance policy that Istio added?

I was thinking of supporting Envoy one and it can be supported per gateway right - this is similar to Cipher suites for example?

Copy link
Copy Markdown
Member

@howardjohn howardjohn Mar 18, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah. Istio already has this concept though. I think the istio concept should translate to the envoy one probably?

I (now) agree this could work as you implemented, just not sure its the best or just expand our existing compliance policy

Copy link
Copy Markdown
Contributor

@keithmattix keithmattix Mar 18, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Selfishly, my concern is that this compliance policy in envoy is boringSSL only and has dubious/non existent support for other crypto implementations. I do agree it could work as described though.

As to our existent compliance policy, the lines are kinda blurry now that envoy/boring supports this first class. Should we have separate control plane/data plane compliance policy fields?

Copy link
Copy Markdown
Contributor Author

@ramaraochavali ramaraochavali Mar 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the istio concept should translate to the envoy one probably?

That is a possibility. But AFAIK, the Istio compliance policy is not pod/proxy specific. If we set at Istiod it works for all components and all proxies. If we want to enable only at gateways it is not possible and also today's compliance policy does not allow 1.3. If we want to do pod/proxy specific, we have to introduce ISTIO_META and drive it through that. Should we do that or alternatively expose this API and if this is specified, for gateways it takes precedence that way it can be enabled for gateways only

Should we have separate control plane/data plane compliance policy fields?

One challenge with this is, this envoy policy applies to Envoy and if we broadly classify it as data plane, we can not apply to pilot-agent - which probably is fine because pilot-agent though part of dataplane mostly plays control plane component role?

Copy link
Copy Markdown
Contributor Author

@ramaraochavali ramaraochavali Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@keithmattix @howardjohn WDYT ^^?

}
Loading