add compliance policy to gateway API#3671
add compliance policy to gateway API#3671ramaraochavali wants to merge 1 commit intoistio:masterfrom
Conversation
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
istio-testing
added
the
size/S
ramaraochavali
added
release-notes-none
| // 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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
4 participants
There is no easy way to ensure the compliance in some secure envs, that blocks CHACHA cipher for TLS 1.3. Envoy supports this compliance policy now and is a common requirement for gateways. For gateway API, we can support it as one of the options.