-
Bug
-
Resolution: Duplicate
-
Undefined
-
None
-
4.12.z, 4.11.z
-
None
-
No
-
1
-
Sprint 240
-
1
-
False
-
Description of problem:
When running ALBO on a FIPS enabled cluster, we are unable to create any Ingress objects due to TLS Protocol issues with the controllers. It would appear the controllers created from an `AWSLoadBalancerController` CR are using an insecure TLS protocol as some sort of fallback. This results in the aws-load-balancer-controller-cluster validating webhook to deny creation of the ingress.
Versions:
aws-load-balancer-operator.v1.0.0 OSD 4.11.44 and 4.12.26
Steps to Reproduce:
1. Create a cluster with FIPS enabled 2. Deploy the operator following instructions in OperatorHub 3. Create any kind of AWSLoadBalancerController (I saw this issue using either alb and tls-terminated class, assuming this error will occur with any class) 4. Create an ingress object
Actual results:
# Validating webhook error is thrown Error from server (InternalError): error when creating "ingress.yml": Internal error occurred: failed calling webhook "vingress.elbv2.k8s.aws": failed to call webhook: Post "https://aws-load-balancer-controller-cluster.aws-load-balancer-operator.svc:9443/validate-networking-v1-ingress?timeout=10s": remote error: tls: protocol version not supported
Expected results:
Ingress created
Additional info:
# checking logs of controllers, there will be multiple errors similar to below. # these errors are from trying to hit metrics endpoint or any attempts to create an ingress 2023/08/02 13:15:06 http: TLS handshake error from 10.130.0.45:50838: tls: client offered only unsupported versions: [304 303] # curling the service directly throws what looks like TLS1.0/SSLv3 settings? $ curl -v https://aws-load-balancer-controller-cluster.aws-load-balancer-operator.svc:9443/validate-networking-v1-ingress * Trying 172.30.209.232:9443... * Connected to aws-load-balancer-controller-cluster.aws-load-balancer-operator.svc (172.30.209.232) port 9443 (#0) * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: none * TLSv1.3 (IN), TLS alert, protocol version (582): * OpenSSL/3.1.0: error:0A00042E:SSL routines::tlsv1 alert protocol version * Closing connection 0 curl: (35) OpenSSL/3.1.0: error:0A00042E:SSL routines::tlsv1 alert protocol version
It should also be noted that to support FIPS fully, the Go binaries that make up the operator would need to be built with proper FIPS configurations so that the binary is FIPS enabled as well. The binary not running in a FIPS enabled mode could be the root cause here too. With FedRAMP being a massive goal for Red Hat, operators supporting FIPS will be critical.
- duplicates
-
-
- Closed
-