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): oc v3.6.121 kubernetes v1.6.1+5115d708d7 features: Basic-Auth GSSAPI Kerberos SPNEGO How reproducible: always 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 Actual results: haproxy pod become 'CrashLoopBackOff' Expected results: should verify the value of ROUTER_CIPHERS to make it in [modern,intermediate,old] Additional info:
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.: ECDHE+aRSA+AES256+GCM+SHA384:ECDHE+aRSA+AES128+GCM+SHA256:ECDHE+aRSA+AES256+SHA384:ECDHE+aRSA+AES128+SHA256:ECDHE+aRSA+RC4+SHA:ECDHE+aRSA+AES256+SHA:ECDHE+aRSA+AES128+SHA:AES256+GCM+SHA384:AES128+GCM+SHA256:AES128+SHA256:AES256+SHA256:DHE+aRSA+AES128+SHA:RC4+SHA:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS 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.