Skip to content
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

Closed
jpeach opened this issue Feb 14, 2020 · 6 comments
Closed

TLS: enforce validation policy for an application #93

jpeach opened this issue Feb 14, 2020 · 6 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. kind/user-story Categorizes an issue as capturing a user story

Comments

@jpeach
Copy link
Contributor

jpeach commented Feb 14, 2020

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

@jpeach jpeach added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 14, 2020
@k8s-ci-robot k8s-ci-robot added the kind/user-story Categorizes an issue as capturing a user story label Feb 14, 2020
@bowei
Copy link
Contributor

bowei commented Feb 14, 2020

This feels like it would go into the custom category given its very specific to a given implementation.
The most important aspect for the API schema is to understand how this would be done using the support: custom extension points.
If we can break this down into more concrete items that we feel are universal (core) or widely (extended) applicable, that would be good as well.

@bowei
Copy link
Contributor

bowei commented Feb 14, 2020

The question in my mind is who is writing the policy and maintaining the enforcement.
Our experience has been that (given the personas), that it is rare that this person is from the app dev team.

@jpeach
Copy link
Contributor Author

jpeach commented Feb 17, 2020

This feels like it would go into the custom category given its very specific to a given implementation.

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 :)

@bowei
Copy link
Contributor

bowei commented Apr 2, 2020

Parking this issue for now; policy enforcement is likely bigger than just TLS cert properties.
Perhaps OPA gatekeeper is more fitting: https://github.com/open-policy-agent/gatekeeper

@bowei
Copy link
Contributor

bowei commented Apr 2, 2020

/close

@k8s-ci-robot
Copy link
Contributor

@bowei: Closing this issue.

In response to this:

/close

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.

jaison-tiu pushed a commit to jaison-tiu/gateway-api that referenced this issue Apr 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. kind/user-story Categorizes an issue as capturing a user story
Projects
None yet
Development

No branches or pull requests

3 participants