-
Notifications
You must be signed in to change notification settings - Fork 487
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.
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
TLS: enforce validation policy for an application #93
Comments
This feels like it would go into the |
The question in my mind is who is writing the policy and maintaining the enforcement. |
Yup, being able to express this as custom config could be a reasonable starting point. The phrase "very specific to a given implementation" feels a bit circular to me, since it is only implementation-specific if its custom :) |
Parking this issue for now; policy enforcement is likely bigger than just TLS cert properties. |
/close |
@bowei: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Update Mesh CRDs directory
What would you like to be added:
The ability to express that my application need guarantees about the TLS validation
Why is this needed:
As an application owner, I have made commitments to third parties (e.g. regulators, security teams) about the TLS policy for my application. If the Gateway allows other sessions secured with different certificates to access my application, then I cannot fulfill those commitments.
For example, perhaps I am distributing content and have represented to the content owners that the application will be "protected" by an EV certificate. The content should not be accessed by clients presenting a different SNI name.
For example, my application has regulatory requirements and runs in a cluster with non-regulatory applications. My requirements cover certificate/key rotation and issuance by a reputable CA. However, other cluster applications use self-signed certificates and may not have any key rotation policies. If SNI-bypass is allowed, are my regulatory requirements still being satisfied?
/kind user-story
The text was updated successfully, but these errors were encountered: