NE-2218: Add HAProxy standalone images for 2.8 and 3.2#780
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@jcmoraisjr: This pull request references NE-2664 which is a valid jira issue. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
WalkthroughThis PR adds two new Dockerfiles for OpenShift HAProxy router images—one for HAProxy 2.8 and one for HAProxy 3.2. Both install their respective HAProxy versions along with socat, verify packages, lower OpenSSL crypto policy security levels, apply Linux capabilities, configure non-root execution, and expose standard HTTP/HTTPS ports. ChangesOpenShift HAProxy Router Images
🎯 1 (Trivial) | ⏱️ ~5 minutes 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
images/router/haproxy/Dockerfile.ocp.haproxy28 (1)
12-13:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd a container health check.
There is no
HEALTHCHECKinstruction, which breaks the required container contract and weakens runtime failure detection.Suggested adjustment
EXPOSE 80 443 +HEALTHCHECK --interval=30s --timeout=5s --start-period=20s --retries=3 \ + CMD pidof haproxy >/dev/null || exit 1As per coding guidelines "HEALTHCHECK defined".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@images/router/haproxy/Dockerfile.ocp.haproxy28` around lines 12 - 13, Add a HEALTHCHECK instruction to the Dockerfile to satisfy the "HEALTHCHECK defined" guideline: add a HEALTHCHECK that probes the web service (e.g., HTTP GET to port 80/443 on localhost) and returns non-zero on failure, and configure sensible options (interval, timeout, start-period, retries); update the Dockerfile near the EXPOSE 80 443 line so the image reports healthy/unhealthy to the runtime.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@images/router/haproxy/Dockerfile.ocp.haproxy28`:
- Around line 2-7: Split the RUN block into a builder stage that installs
INSTALL_PKGS and performs rpm -V, yum clean, sed on
/etc/crypto-policies/back-ends/opensslcnf.config and runs setcap on
/usr/sbin/haproxy, then create a minimal runtime stage that does not run yum:
copy the haproxy binary (/usr/sbin/haproxy), its required libraries, and the
modified openslcnf.config from the builder into the final image; ensure setcap
is applied to the copied /usr/sbin/haproxy (or applied in the builder before
copy) so the final image contains only the runtime artefacts and no
build/install tooling.
- Line 1: The base image in Dockerfile.ocp.haproxy28 is pointing to a CI
registry (registry.ci.openshift.org) and must be switched to a compliant Red Hat
catalog image; update the FROM line to use a UBI minimal or distroless image
hosted on catalog.redhat.com (for example the appropriate ubi8/ubi-minimal or
Red Hat distroless variant) so the container baseline policy is satisfied,
keeping the rest of the Dockerfile unchanged.
---
Outside diff comments:
In `@images/router/haproxy/Dockerfile.ocp.haproxy28`:
- Around line 12-13: Add a HEALTHCHECK instruction to the Dockerfile to satisfy
the "HEALTHCHECK defined" guideline: add a HEALTHCHECK that probes the web
service (e.g., HTTP GET to port 80/443 on localhost) and returns non-zero on
failure, and configure sensible options (interval, timeout, start-period,
retries); update the Dockerfile near the EXPOSE 80 443 line so the image reports
healthy/unhealthy to the runtime.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 01b47e47-643f-4854-8db9-ddf5048a5c91
📒 Files selected for processing (1)
images/router/haproxy/Dockerfile.ocp.haproxy28
jcmoraisjr
changed the title
|
@jcmoraisjr: This pull request references NE-2218 which is a valid jira issue. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
/assign |
|
/assign |
Adding HAProxy standalone image for the 2.8 and 3.2 branches, without router binary and configurations files. This image is intended to be part of the OCP bundle and should run as a sidecar of the Router pod. These images are intended to be light weight, without scripts or base configuration. Router pod is responsible to configure one of them via a shared volume instead. https://redhat.atlassian.net/browse/NE-2218
jcmoraisjr
force-pushed
the
NE-2664-haproxy28-image
branch
from
14a7867 to
6c0bda3
Compare
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@images/router/haproxy28/Dockerfile.ocp`:
- Line 1: Replace the CI base image used in the Dockerfile FROM line (currently
"registry.ci.openshift.org/ocp/4.23:base-rhel9") with a supported production
base image from catalog.redhat.com—use the UBI minimal or a distroless image
(for example an appropriate "registry.redhat.io/ubi9/ubi-minimal" or equivalent
distroless image and tag) so the bundle image uses a supported provenance;
update the FROM instruction accordingly and ensure any downstream packaging or
build metadata reflect the new base image choice.
- Line 7: The Dockerfile currently lowers system-wide OpenSSL security by
running the sed command "sed -i 's/SECLEVEL=2/SECLEVEL=1/g'
/etc/crypto-policies/back-ends/opensslcnf.config" in
images/router/haproxy28/Dockerfile.ocp (and similar files), which must be
removed; instead, do not modify /etc/crypto-policies globally and implement the
relaxation only for HAProxy by either configuring HAProxy's TLS parameters (set
appropriate ssl-default-bind-ciphers and ssl-default-bind-options in
haproxy.cfg) or by providing a per-service OpenSSL config and pointing HAProxy
to it (e.g., set OPENSSL_CONF or supply a custom openssl.cnf in the image and
ensure only the HAProxy process uses it), then remove the sed line from the
Dockerfiles.
In `@images/router/haproxy32/Dockerfile.ocp`:
- Line 1: Replace the CI base image used in the Dockerfile's FROM instruction
with a supported UBI minimal or distroless image from catalog.redhat.com (e.g.,
use a catalog.redhat.com UBI minimal image or distroless equivalent and pin a
stable tag or digest); update the FROM line in the Dockerfile so it references
the approved production base image and verify the image pull works in your build
environment.
- Around line 2-7: Split package installation and system mutations into a
builder stage: create a builder stage (e.g., "builder") that runs the RUN block
installing INSTALL_PKGS="socat haproxy32", rpm -V, yum clean, setcap
'cap_net_bind_service=ep' /usr/sbin/haproxy and the sed edit; then in the final
runtime stage copy only the needed artifacts (e.g., /usr/sbin/haproxy, socat
binary if required, and any dependent libs) from the builder using COPY
--from=builder, and remove all yum/rpm commands from the final stage so it
contains only the runtime binaries/configuration. Ensure the final stage
preserves the modified openssl config if necessary by copying the specific
config file from builder instead of running sed in the runtime image.
- Line 7: The Dockerfile currently runs a global sed ('sed -i' replacing
SECLEVEL=2 with SECLEVEL=1 in opensslcnf.config) which weakens OpenSSL
system-wide; remove that sed change and instead scope the weaker setting to
HAProxy only by either (A) configuring HAProxy's cipher/options to include the
OpenSSL token '`@SECLEVEL`=1' (e.g., via ssl-default-bind-ciphers / bind ...
ciphers in haproxy.cfg) or (B) create a dedicated OpenSSL config file with
SECLEVEL=1 and set the HAProxy process to use it (e.g., via OPENSSL_CONF
environment for the HAProxy process in the Dockerfile), and reference HAProxy
configuration (haproxy.cfg) or the HAProxy start invocation so only HAProxy uses
the lower SECLEVEL.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 62797aee-6cea-4244-984e-df8f15933b4a
📒 Files selected for processing (2)
images/router/haproxy28/Dockerfile.ocpimages/router/haproxy32/Dockerfile.ocp
| @@ -0,0 +1,12 @@ | |||
| FROM registry.ci.openshift.org/ocp/4.23:base-rhel9 | |||
There was a problem hiding this comment.
Use a supported production base image.
registry.ci.openshift.org/ocp/4.23:base-rhel9 is a CI image, not the UBI minimal/distroless source required for production containers here. That weakens the provenance/support story for a bundle image.
As per coding guidelines "Base image: UBI minimal or distroless from catalog.redhat.com".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@images/router/haproxy28/Dockerfile.ocp` at line 1, Replace the CI base image
used in the Dockerfile FROM line (currently
"registry.ci.openshift.org/ocp/4.23:base-rhel9") with a supported production
base image from catalog.redhat.com—use the UBI minimal or a distroless image
(for example an appropriate "registry.redhat.io/ubi9/ubi-minimal" or equivalent
distroless image and tag) so the bundle image uses a supported provenance;
update the FROM instruction accordingly and ensure any downstream packaging or
build metadata reflect the new base image choice.
| rpm -V $INSTALL_PKGS && \ | ||
| yum clean all && \ | ||
| setcap 'cap_net_bind_service=ep' /usr/sbin/haproxy && \ | ||
| sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/crypto-policies/back-ends/opensslcnf.config |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show Dockerfile context around the referenced line
FILE="images/router/haproxy28/Dockerfile.ocp"
echo "== $FILE =="
nl -ba "$FILE" | sed -n '1,120p'
# Find any other references to this crypto-policy file in the repo
echo
echo "== Search: opensslcnf.config =="
rg -n "opensslcnf\.config|SECLEVEL=2|SECLEVEL=1|crypto-policies/back-ends" -S . || true
# Show what else might run in this image (entrypoint/cmd)
echo
echo "== Search: ENTRYPOINT/CMD/HAProxy start =="
rg -n "ENTRYPOINT|CMD|haproxy|exec |/usr/sbin/haproxy|service haproxy|systemctl" "$FILE" || trueRepository: openshift/router
Length of output: 166
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== command availability =="
for cmd in cat sed awk rg find fd; do
if command -v "$cmd" >/dev/null 2>&1; then
echo "$cmd: YES ($(command -v "$cmd"))"
else
echo "$cmd: NO"
fi
done
FILE="images/router/haproxy28/Dockerfile.ocp"
echo
echo "== File: $FILE =="
if [ -f "$FILE" ]; then
# Prefer line numbers if possible
if command -v cat >/dev/null 2>&1; then
cat -n "$FILE" | sed -n '1,140p'
else
sed -n '1,140p' "$FILE"
fi
else
echo "Missing: $FILE"
fi
echo
echo "== Search for opensslcnf.config usage =="
# Use rg if available, otherwise fallback to grep
if command -v rg >/dev/null 2>&1; then
rg -n "opensslcnf\.config|SECLEVEL=2|SECLEVEL=1|crypto-policies/back-ends/opensslcnf\.config" -S . || true
else
grep -RIn --binary-files=without-match "opensslcnf\.config|SECLEVEL=2|SECLEVEL=1|crypto-policies/back-ends/opensslcnf\.config" . || true
fi
echo
echo "== Search for ENTRYPOINT/CMD in this Dockerfile =="
# Show only this file
grep -nE "^(ENTRYPOINT|CMD)|exec |/usr/sbin/haproxy|haproxy" "$FILE" || trueRepository: openshift/router
Length of output: 1608
Avoid lowering OpenSSL defaults globally; scope the relaxation to HAProxy configuration only.
This Dockerfile changes /etc/crypto-policies/back-ends/opensslcnf.config by rewriting SECLEVEL=2 to SECLEVEL=1, which applies to all OpenSSL consumers in the container (not just HAProxy). Prefer a per-service/per-config approach for the HAProxy compatibility requirement (e.g., adjust HAProxy/OpenSSL settings without altering the system crypto-policy file). The same pattern also appears in images/router/haproxy/Dockerfile.ocp and images/router/haproxy32/Dockerfile.ocp (same sed line).
sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/crypto-policies/back-ends/opensslcnf.config🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@images/router/haproxy28/Dockerfile.ocp` at line 7, The Dockerfile currently
lowers system-wide OpenSSL security by running the sed command "sed -i
's/SECLEVEL=2/SECLEVEL=1/g' /etc/crypto-policies/back-ends/opensslcnf.config" in
images/router/haproxy28/Dockerfile.ocp (and similar files), which must be
removed; instead, do not modify /etc/crypto-policies globally and implement the
relaxation only for HAProxy by either configuring HAProxy's TLS parameters (set
appropriate ssl-default-bind-ciphers and ssl-default-bind-options in
haproxy.cfg) or by providing a per-service OpenSSL config and pointing HAProxy
to it (e.g., set OPENSSL_CONF or supply a custom openssl.cnf in the image and
ensure only the HAProxy process uses it), then remove the sed line from the
Dockerfiles.
| @@ -0,0 +1,12 @@ | |||
| FROM registry.ci.openshift.org/ocp/4.23:base-rhel9 | |||
There was a problem hiding this comment.
Use a supported production base image.
registry.ci.openshift.org/ocp/4.23:base-rhel9 is a CI image, not the UBI minimal/distroless source required for production containers here. That weakens the provenance/support story for a bundle image.
As per coding guidelines "Base image: UBI minimal or distroless from catalog.redhat.com".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@images/router/haproxy32/Dockerfile.ocp` at line 1, Replace the CI base image
used in the Dockerfile's FROM instruction with a supported UBI minimal or
distroless image from catalog.redhat.com (e.g., use a catalog.redhat.com UBI
minimal image or distroless equivalent and pin a stable tag or digest); update
the FROM line in the Dockerfile so it references the approved production base
image and verify the image pull works in your build environment.
| RUN INSTALL_PKGS="socat haproxy32" && \ | ||
| yum install -y --setopt=install_weak_deps=0 $INSTALL_PKGS && \ | ||
| rpm -V $INSTALL_PKGS && \ | ||
| yum clean all && \ | ||
| setcap 'cap_net_bind_service=ep' /usr/sbin/haproxy && \ | ||
| sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/crypto-policies/back-ends/opensslcnf.config |
There was a problem hiding this comment.
Split install/setup from the runtime stage.
Installing packages and mutating system files in the final stage leaves package-management tooling and setup-only layers in the shipped image. Please move install/verification into a builder stage and keep the runtime stage to the binaries/libs/config it actually needs.
As per coding guidelines "Multi-stage builds; no build tools in final image".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@images/router/haproxy32/Dockerfile.ocp` around lines 2 - 7, Split package
installation and system mutations into a builder stage: create a builder stage
(e.g., "builder") that runs the RUN block installing INSTALL_PKGS="socat
haproxy32", rpm -V, yum clean, setcap 'cap_net_bind_service=ep'
/usr/sbin/haproxy and the sed edit; then in the final runtime stage copy only
the needed artifacts (e.g., /usr/sbin/haproxy, socat binary if required, and any
dependent libs) from the builder using COPY --from=builder, and remove all
yum/rpm commands from the final stage so it contains only the runtime
binaries/configuration. Ensure the final stage preserves the modified openssl
config if necessary by copying the specific config file from builder instead of
running sed in the runtime image.
| rpm -V $INSTALL_PKGS && \ | ||
| yum clean all && \ | ||
| setcap 'cap_net_bind_service=ep' /usr/sbin/haproxy && \ | ||
| sed -i 's/SECLEVEL=2/SECLEVEL=1/g' /etc/crypto-policies/back-ends/opensslcnf.config |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="images/router/haproxy32/Dockerfile.ocp"
echo "== File: $FILE =="
if [ -f "$FILE" ]; then
sed -n '1,120p' "$FILE" | cat -n
else
echo "Missing file: $FILE"
fi
echo
echo "== Find SECLEVEL edits in repo =="
rg -n "SECLEVEL=2|SECLEVEL=1|opensslcnf\.config|/etc/crypto-policies/back-ends/opensslcnf\.config" -S .
echo
echo "== Check entrypoint/cmd / haproxy config in this image =="
# Try to locate any haproxy config references around this directory
DIR="$(dirname "$FILE")"
rg -n "haproxy|ENTRYPOINT|CMD|/etc/haproxy" -S "$DIR" || true
echo
echo "== Inspect any HAProxy config that might require lower seclevel =="
rg -n "ssl|seclevel|SECLEVEL|opensslcnf|crypto-policies" -S "$DIR" || trueRepository: openshift/router
Length of output: 1752
🌐 Web query:
RHEL /etc/crypto-policies/back-ends/opensslcnf.config SECLEVEL how affects OpenSSL consumers whole system
💡 Result:
On RHEL, /etc/crypto-policies/back-ends/opensslcnf.config is the OpenSSL “backend” file generated/managed by the system-wide crypto-policies framework, and it sets OpenSSL security constraints (including the OpenSSL @SECLEVEL security level). System-wide policy changes therefore affect any OpenSSL consumer that uses the system defaults from that file (e.g., common system services and libraries) unless the application overrides them or you opt out for that application.[1][2][3] 1) What “SECLEVEL” does in OpenSSL SECLEVEL controls OpenSSL’s security level for negotiating/accepting TLS parameters (key sizes, allowed cipher suites, and related restrictions) via OpenSSL’s security level machinery; it’s intended to provide “sane defaults”. For example, OpenSSL documentation states that at security level 2 it prohibits RSA/DSA/DH keys shorter than 2048 bits and ECC keys shorter than 224 bits, and at level 0 it disables TLS 1.0/1.1/SSLv3 (and other restrictions).[4] 2) How crypto-policies wires SECLEVEL into system OpenSSL behavior The crypto-policies framework applies a selected policy (DEFAULT/LEGACY/FUTURE/FIPS) to core cryptographic subsystems such as TLS, and Red Hat documents that it “ensures that applications reject weak algorithms by default”.[5] The crypto-policies system generates backend configuration files in /etc/crypto-policies/back-ends, including the OpenSSL backend.[2][3] Additionally, crypto-policies is designed so that OpenSSL applications follow the policy via the generated configuration file when they don’t explicitly override OpenSSL’s configuration/cipher strings: applications that don’t override the configuration “automatically adhere to the policy” and inherit the minimum TLS protocol version and default cipher suite preference via this backend file.[2] 3) Whole-system effect on OpenSSL consumers If an OpenSSL consumer: - loads the system OpenSSL configuration (or otherwise uses default behavior), and - does not override cipher/TLS settings, then raising SECLEVEL (e.g., via a stricter crypto-policy) will generally cause more TLS connections to fail because OpenSSL will reject ciphers or key sizes that don’t meet the configured security level constraints.[4][2] Conversely, lowering SECLEVEL would broaden what is accepted (but reduces security). Red Hat notes that for applications which need exceptions you should opt out/override rather than editing generated files, and that “remove a symlink… and replace it with your customized cryptographic settings” can prevent use of the system-wide crypto-policies for that excluded backend, though this modification is not supported by Red Hat.[6] 4) Practical impact you can observe - The effective policy is visible in /etc/crypto-policies/state/CURRENT.pol (lists settings after wildcard expansion).[1] - After a policy change, you can verify negotiated TLS behavior with OpenSSL client tests; and long-running servers may require restart to reload the OpenSSL config.[2] 5) Example of what changes when SECLEVEL is increased (SHA-1 signatures) An OpenSSL/Red Hat related issue describes that at SECLEVEL=2 (used in DEFAULT and LEGACY policies “in crypto-policies”), creation and verification of SHA-1 signatures are rejected as insecure (with the workaround being to lower SECLEVEL, or provide a special compatibility mechanism). This illustrates the kind of backwards-incompatible breakage higher SECLEVEL can trigger for legacy algorithms.[7] Net: SECLEVEL in /etc/crypto-policies/back-ends/opensslcnf.config is a lever that determines what OpenSSL will consider “secure enough” (key sizes/ciphers/protocol constraints). Because crypto-policies generates this backend from the selected system policy and because many OpenSSL-based consumers use the system defaults, changing the system crypto-policy (DEFAULT/LEGACY/FUTURE/FIPS) will generally change SECLEVEL behavior across the whole system for OpenSSL consumers that don’t override it.[1][5][4][2] If you tell me your RHEL version and current crypto-policy (update-crypto-policies --show --is-applied), plus whether the issue is TLS handshake failures or signature/certificate validation failures, I can map the expected effect more precisely to the exact failures you’re seeing.
Citations:
- 1: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/system_design_guide/using-the-system-wide-cryptographic-policies_system-design-guide
- 2: https://manpages.opensuse.org/Leap-16.0/crypto-policies-scripts/update-crypto-policies.8.en.html
- 3: https://manpages.opensuse.org/Leap-15.6/crypto-policies/crypto-policies.7.en.html
- 4: https://docs.openssl.org/master/man3/SSL_CTX_set_security_level/
- 5: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/security_hardening/using-system-wide-cryptographic-policies
- 6: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
- 7: Adding a config option in openssl.cnf to enable SHA-1 signature creation and verification openssl/openssl#17662
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Look for HAProxy config files/templates for haproxy32 and any mention of ciphers/ssl options.
DIR="images/router/haproxy32"
echo "== HAProxy 3.2 configs under $DIR =="
fd -t f -a -e '.cfg' -e '.conf' -e '.template' -e '.cnf' -e '.pem' -e '.key' "$DIR" || true
echo
rg -n "ssl|ciphers|seclevel|SECLEVEL|DEFAULT|`@SECLEVEL`|tune\.ssl|verify|tls-" -S "$DIR" || true
echo
# Also check if the image has an entrypoint script that sets OpenSSL env/config.
rg -n "entrypoint|ENTRYPOINT|CMD|run|openssl|crypto-policies|update-crypto-policies" -S "$DIR" || trueRepository: openshift/router
Length of output: 960
🏁 Script executed:
#!/bin/bash
set -euo pipefail
DIR="images/router/haproxy32"
echo "== Directory listing: $DIR =="
ls -la "$DIR" || true
echo
echo "== File search (common config types) =="
cd "$DIR"
fd -t f -a -e 'cfg' -e 'conf' -e 'template' -e 'cnf' -e 'pem' -e 'key' . || true
echo
echo "== Content search for TLS/ciphers/seclevel =="
rg -n "ssl|ciphers|seclevel|SECLEVEL|`@SECLEVEL`|tune\.ssl|verify|tls-" -S . || true
echo
echo "== Search for entrypoints/scripts =="
rg -n "ENTRYPOINT|CMD|entrypoint|run |exec |haproxy" -S . || trueRepository: openshift/router
Length of output: 716
Scope the OpenSSL SECLEVEL change to HAProxy—don’t edit crypto-policies backend globally.
The sed change to /etc/crypto-policies/back-ends/opensslcnf.config lowers SECLEVEL for any OpenSSL consumer that uses the system defaults in the container (not just HAProxy). Configure the weaker setting only for HAProxy (e.g., via HAProxy TLS/cipher options such as @SECLEVEL=1, or by pointing HAProxy at a dedicated OpenSSL config) instead of mutating the system-wide backend.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@images/router/haproxy32/Dockerfile.ocp` at line 7, The Dockerfile currently
runs a global sed ('sed -i' replacing SECLEVEL=2 with SECLEVEL=1 in
opensslcnf.config) which weakens OpenSSL system-wide; remove that sed change and
instead scope the weaker setting to HAProxy only by either (A) configuring
HAProxy's cipher/options to include the OpenSSL token '`@SECLEVEL`=1' (e.g., via
ssl-default-bind-ciphers / bind ... ciphers in haproxy.cfg) or (B) create a
dedicated OpenSSL config file with SECLEVEL=1 and set the HAProxy process to use
it (e.g., via OPENSSL_CONF environment for the HAProxy process in the
Dockerfile), and reference HAProxy configuration (haproxy.cfg) or the HAProxy
start invocation so only HAProxy uses the lower SECLEVEL.
|
I don't have any major concern. Loosing the The Code Rabbit comments are actually not specific to your new Dockerfiles - but apply to our existing Dockerfile. I don't think it's something we need to block the PR over, but I'm interested in someone following up (should we be using the UBI images)? Feel free to research and create bugs on these if you want to follow up. For testing - you could merge this with no issues, but we don't have a HAProxy 3.2 RPM yet, nor the openshift/release or ocp-build-data PRs are uP (correct me if I'm wrong). So I don't think there is a rush. @Miciah i can leave the final review and approval to you. /lgtm |
I'm specially interested on an agreement about the approach we should use. About merging, it should be noop until ART configures On the |
|
/test e2e-agnostic |
|
This is a pretty straightforward PR, and @Miciah has reviewed it once already. /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: gcs278 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
|
/verified later by @rhamini3 |
|
@rhamini3: Only users can be targets for the DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
/verified later @rhamini3 |
openshift-ci-robot
added
verified-later
verified
|
@rhamini3: This PR has been marked to be verified later by DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
this PR is a a NO-OP so CI failures are unrelated: |
|
@jcmoraisjr: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
5 participants
Adding HAProxy standalone image for the 2.8 and 3.2 branches, without router binary and configurations files. This image is intended to be part of the OCP bundle and should run as a sidecar of the Router pod.
These images are intended to be light weight, without scripts or base configuration. Router pod is responsible to configure one of them via a shared volume instead.
https://redhat.atlassian.net/browse/NE-2218
Summary by CodeRabbit