TLS: require specific TLS version or other configuration for an application

[jpeach]

What would you like to be added:

The ability for an application to specify its TLS version requirement. This extends to other TLS tunable such as cipher suites, session caching, session tickets and so forth.

Why is this needed:

As an application developer, my client audience is rapidly moving to TLS 1.2, but the cluster operator is also responsible for applications that will require TLS 1.1 for a long time to come. I want to be able to require TLS 1.2 on my application while allowing other applications to continue with TLS 1.1 for compatibility reasons.

The same use case applies to other TLS configuration items in general. Note that some applications will make different security/performance tradeoffs (e.g. around session tickets) so it would be inappropriate for the policy for my application to be allowed to be used for a different application.

/kind user-story

[bowei]

Can we create an overall topic for TLS configuration? (Edit the topic)

References:

• nginx http://nginx.org/en/docs/http/ngx_http_ssl_module.html
• haproxy https://www.haproxy.com/documentation/aloha/9-0/traffic-management/lb-layer7/tls/
• envoy https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/auth/cert.proto
• aws https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/ssl-config-update.html
• gcp https://cloud.google.com/load-balancing/docs/ssl-policies-concepts
• azure https://docs.microsoft.com/en-us/azure/application-gateway/application-gateway-ssl-policy-overview

[bowei]

This story is written from application dev standpoint, but I find that mostly TLS policy is enforced by cluster operator level (see https://kubernetes-sigs.github.io/service-apis/concepts/).

From conversations w/ users, I have found that app dev do not care as long as someone else makes it compliant/secure.

We need to also include mention of enforcement (note such policy can enforced in other ways) if app devs have choice in the matter.

[jpeach]

I can see there could be different stories for dev and cluster operator personas. Cluster operators may define defaults and policy rules. Many dev teams will find the default acceptable, and others will need to specify them.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[jpeach]

Similar to #256, this setting can probably be added to TLSConfig

/remove-lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[jpeach]

/remove-lifecycle rotten

[hbagdi]

It is now possible to configure version specific requirement in the Options map. Is that sufficient for this use case, @jpeach ?

[jpeach]

Yup, let's see how it goes.

/close

[k8s-ci-robot]

@jpeach: Closing this issue.

In response to this:

Yup, let's see how it goes.

/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.