Red Hat Bugzilla – Bug 1463976
[oeP7vrTZ]The router pod will be crashed when the cipher is unvalued
Last modified: 2017-06-22 07:16:21 EDT
Description of problem:
the haproxy pod will be crashed if setting the cipher is a unvalued which is NOT (modern,intermediate,old). So we should verify the value of ROUTER_CIPHERS
Version-Release number of selected component (if applicable):
features: Basic-Auth GSSAPI Kerberos SPNEGO
Steps to Reproduce:
1. Create haproxy to make it running
2. update the cipher to invalud
oc env dc ROUTER_CIPHERS=non
3. check the haproxy router pod
haproxy pod become 'CrashLoopBackOff'
should verify the value of ROUTER_CIPHERS to make it in [modern,intermediate,old]
The ROUTER_CIPHERS can also take any SSL cipher suite (https://en.wikipedia.org/wiki/Cipher_suite).
Our named settings are just conveniences based on the current recommendations at https://wiki.mozilla.org/Security/Server_Side_TLS and we will update them as the recommendations change.
But people may want to specify a specific cipher suite, e.g.:
And honestly, validating the valid settings doesn't seem worthwhile. Admins will get these from their security teams, or from websites where there are recommendations. They aren't likely to tweak these often. So the admin will make a change and then (presumably) test the config and see the router is broken and fix it. This is something only the router admin can set (and there are plenty of other environment variables they can set that will also break the router).
If we could allow this per-route, then we would absolutely need to stringently validate these, because a user could set an annotation that would crash a router. However, it is not yet possible to per-route cipher negotiation yet.