-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
daemon/update.go: fix FIPS check and remove day 2 support #1252
Conversation
a574351
to
3ff1125
Compare
/retest |
3ff1125
to
fa3c675
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
/override ci/prow/e2e-aws-scaleup-rhel7 |
@ashcrow: Overrode contexts on behalf of ashcrow: ci/prow/e2e-aws-scaleup-rhel7 In 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 kubernetes/test-infra repository. |
verify failure:
|
pkg/daemon/update.go
Outdated
return errors.Wrapf(err, "%s FIPS: %s", arg, string(out)) | ||
nodeFIPS, err := strconv.ParseBool(string(content)) | ||
if err != nil { | ||
return errors.Wrapf(err, "Error parsing FIPS file at %s", fipsFile,) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra comma here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops, fixing
pkg/daemon/update.go
Outdated
return nil | ||
} | ||
|
||
if current.Spec.FIPS != desired.Spec.FIPS { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, should we move this check higher up?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm so we ran into this error initially because we detected that the current current.Spec.FIPS
!= desired.Spec.FIPS
right? Because it was nil?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in, maybe I should change this just to return an error if !desired.Spec.FIPS == nodeFIPS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And flat out ignore what current.Spec.FIPS
is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but then the Spec would not be reflective of the state of the system, perhaps I should update that as well just above?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed it to update current.Spec.FIPS so we don't get stuck in a reboot loop. This should definitely be improved of course but I think this can get us past the errors (not tested yet)
// fipsCommand is the command to use when enabling or disabling FIPS | ||
fipsCommand = "/usr/libexec/rhcos-tools/coreos-fips" | ||
// fipsFile is the file to check if FIPS is enabled | ||
fipsFile = "/proc/sys/crypto/fips_enabled" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cgwalters didn't approve of this method (should use the coreos-fips --status
or whatever command): https://github.com/openshift/machine-config-operator/pull/1013/files#r307428010
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah we removed that binary unfortunately, which is what lead to this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fipscheck
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #1250 (comment). That said, checking for /proc/sys/crypto/fips_enabled
is a good start.
We don't want to use coreos-fips
anymore. RHCOS has embedded support for turning on FIPS now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using the proc path above is fine. fipscheck
is an alternate possibility. coreos-fips
has been removed.
fa3c675
to
1b679bb
Compare
/retest
|
/approve This looks sane to me! |
/retest |
1b679bb
to
0be6403
Compare
Minor update: Instead of just returning nil, if FIPS changes were detected, do: |
0be6403
to
542f116
Compare
/approve |
/retest |
/override ci/prow/e2e-aws-scaleup-rhel7 |
@ashcrow: Overrode contexts on behalf of ashcrow: ci/prow/e2e-aws-scaleup-rhel7 In 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 kubernetes/test-infra repository. |
/retest |
/hold Found an error while testing, investigating |
We no longer carry coreos-fips script in RHCOS, so we can no longer update FIPS mode via Machineconfig. For now, let us instead check whether FIPS is expected via /proc/sys/crypto/fips_enabled. Signed-off-by: Yu Qi Zhang <jerzhang@redhat.com>
542f116
to
9075a83
Compare
/hold cancel Can confirm this should work in existing clusters, as well as properly catch and reject day 2 fips applications as we expect. Have not tested with day 1 pending RHCOS updates |
Understood. I don't think an issue will occur but if one does the fix can be done in a different PR. /lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ashcrow, cgwalters, jlebon, yuqi-zhang 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:
Approvers can indicate their approval by writing |
@yuqi-zhang: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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/test-infra repository. I understand the commands that are listed here. |
/override ci/prow/e2e-aws-scaleup-rhel7 |
@ashcrow: Overrode contexts on behalf of ashcrow: ci/prow/e2e-aws-scaleup-rhel7 In 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 kubernetes/test-infra repository. |
@ashcrow FWIW that context is non-blocking, you don't need to override it. |
This effectively reverts fb1c4b4 e2e-fips is currently failing with `/bin/bash: line 15: nodes[i]: unbound variable` Looking at this...we already have code to validate the state of FIPS in the MCO, see: https://github.com/openshift/machine-config-operator/blob/091afde36ac117ef8b782a85b38ae8783ddf4b70/pkg/daemon/update.go#L571 openshift/machine-config-operator#1252 openshift/machine-config-operator#1233 I think these types of checks should be the MCO's role, or if we choose not to do that, let's at least implement them in Go in the existing e2e suite and avoid nontrivial shell-in-YAML.
We no longer carry coreos-fips script in RHCOS, so that check fill
fail regardless. As a temporary fix, check state of node via
cat /proc/sys/crypto/fips_enabled instead.
Fixes: #1250