RHOAISTRAT-214: Issue #362: feat(nbcs): build containers to be fips-ready

[jiridanek]

• Fixes Build fips-ready #362

We are already having these flags enabled in downstream build as part of the devops initiative to build with fips. It makes lots of sense to me to enable these flags in odh Dockerfile as well, for consistency.

This is not intended to fully resolve https://issues.redhat.com/browse/RHOAISTRAT-214, but it's just a sensible first step done as a code improvement initiative, by following public advice in https://developers.redhat.com/articles/2022/05/31/your-go-application-fips-compliant.

Description

This PR was created by diffing the downstream and upstream dockerfile and then i made changes to upstream dockerfile to reflect the enhancements done downstream.

1. Dockerfiles are brought closer together, especially to the Red Hat build; previously, sourcing things in a stand-alone RUN command had no effect
2. The openssl fips-compatible library is linked into the manager binaries, to proactively address fips concerns

As a next step, cpaas Dockerfiles will need to be updated in turn with the new things here.

How Has This Been Tested?

GHA
running controller on fips-enabled cluster with no problems

• quay.io/opendatahub/kubeflow-notebook-controller:pr-406
• quay.io/opendatahub/odh-notebook-controller:pr-406

Merge criteria:

• The commits are squashed in a cohesive manner and have meaningful messages.
• Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
• The developer has manually tested the changes and verified that the changes work

[jiridanek]

/retest

Looks like a flake, let's retrigger without thinking.

[jiridanek]

First check, see that the expected fips-related symbols are in the binary

sh-4.4$ cat /manager | grep --binary-files=text -oh FIPS_mode
FIPS_mode
FIPS_mode
FIPS_mode
FIPS_mode
FIPS_mode
FIPS_mode

check that the binary is dynamically linked with libc

sh-4.4$ ldd /manager 
 linux-vdso.so.1 (0x00007ffe7ccbd000)
 libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f08a5cb3000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f08a5a93000)
 libdl.so.2 => /lib64/libdl.so.2 (0x00007f08a588f000)
 libc.so.6 => /lib64/libc.so.6 (0x00007f08a54b9000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f08a5ecb000)

https://developers.redhat.com/articles/2022/05/31/your-go-application-fips-compliant?source=sso#how_to_get_started

[jiridanek]

There are no suspicious messages in the logs.

[jiridanek]

For further improvements, we maybe should have /healthz endpoint that has some diagnostics, or just dump these into the log at startup

• metadata about the binary, what it was built from, if it can be found
• what are the dependencies, there is introspection api for go binaries so that they can write out their own deps
• whether it's working in fips regimen or not

[jiridanek]

And the notebook is spawned just fine, so, let's consider this tested.

I used fips-enabled https://console-openshift-console.apps.ods-qe-psi-06

I had to change oauth-proxy image digest to 4f8d66597feeb32bb18699326029f9a71a5aca4a57679d636b876377c2e95695.

[harshad16]

/hold

[openshift-cherrypick-robot]

@jiridanek: once the present PR merges, I will cherry-pick it on top of v1.9-branch in a new PR and assign it to you.

In response to this:

/cherrypick v1.9-branch

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-sigs/prow repository.

[harshad16]

/cherrypick v1.9-branch

@jiridanek , please dont use cherrypick anymore for this repo,
main to v1.9-branch would be synced.
cherry-pick would only be needed , if some other content is not being moved.

[jstourac]

/lgtm in general

Two questions:

1. Why TARGETARCH doesn't have a default value similarly as TARGETOS?
2. Should we have the TARGETARCH defined in our Makefile?

[jiridanek]

/unhold
@harshad16 I think we should have this upstream, since it is working just fine, and we actually have it downstream already, also in the konflux build.

[jstourac]

/lgtm

[jiridanek]

/approve
No point sitting on this; and our Dockerfiles don't affect downstream build, not in cpaas and not in conflux, so there's no impact to red hat.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jiridanek

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jiridanek]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment