Skip to content
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

Merged
merged 1 commit into from
Nov 8, 2019

Conversation

yuqi-zhang
Copy link
Contributor

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

@openshift-ci-robot openshift-ci-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Nov 7, 2019
pkg/daemon/update.go Outdated Show resolved Hide resolved
@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Nov 7, 2019
@nee1esh
Copy link

nee1esh commented Nov 7, 2019

/retest

@yuqi-zhang yuqi-zhang changed the title WIP: monkey patch MCD fips daemon/update.go: fix FIPS check and remove day 2 support Nov 7, 2019
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Nov 7, 2019
Copy link
Member

@ashcrow ashcrow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@ashcrow
Copy link
Member

ashcrow commented Nov 7, 2019

/override ci/prow/e2e-aws-scaleup-rhel7

@openshift-ci-robot
Copy link
Contributor

@ashcrow: Overrode contexts on behalf of ashcrow: ci/prow/e2e-aws-scaleup-rhel7

In response to this:

/override ci/prow/e2e-aws-scaleup-rhel7

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
Copy link
Member

ashcrow commented Nov 7, 2019

verify failure:

pkg/daemon/update.go:331: File is not `goimports`-ed (goimports)
		return errors.Wrapf(err, "Error parsing FIPS file at %s", fipsFile,)
pkg/daemon/update.go:339:21: error strings should not be capitalized or end with punctuation or a newline (golint)
		return errors.New("Refusing to update FIPS mode. This is not a supported operation.")
		                  ^

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,)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra comma here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whoops, fixing

return nil
}

if current.Spec.FIPS != desired.Spec.FIPS {
Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

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"
Copy link
Contributor

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

Copy link
Contributor Author

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fipscheck

Copy link
Member

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.

Copy link
Member

@ashcrow ashcrow Nov 7, 2019

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.

@yuqi-zhang
Copy link
Contributor Author

@jlebon
Copy link
Member

jlebon commented Nov 7, 2019

/approve

This looks sane to me!

@yuqi-zhang
Copy link
Contributor Author

/retest

@yuqi-zhang
Copy link
Contributor Author

Minor update: Instead of just returning nil, if FIPS changes were detected, do:
return errors.New("Detected change to FIPS flag. Refusing to modify FIPS on a running cluster.")
instead

@cgwalters
Copy link
Member

/approve

@sinnykumari
Copy link
Contributor

/retest

@ashcrow
Copy link
Member

ashcrow commented Nov 8, 2019

/override ci/prow/e2e-aws-scaleup-rhel7

@openshift-ci-robot
Copy link
Contributor

@ashcrow: Overrode contexts on behalf of ashcrow: ci/prow/e2e-aws-scaleup-rhel7

In response to this:

/override ci/prow/e2e-aws-scaleup-rhel7

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
Copy link
Member

ashcrow commented Nov 8, 2019

/retest

@yuqi-zhang
Copy link
Contributor Author

/hold

Found an error while testing, investigating

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 8, 2019
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>
@yuqi-zhang
Copy link
Contributor Author

/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

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 8, 2019
@ashcrow
Copy link
Member

ashcrow commented Nov 8, 2019

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

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 8, 2019
@openshift-ci-robot
Copy link
Contributor

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot
Copy link
Contributor

openshift-ci-robot commented Nov 8, 2019

@yuqi-zhang: The following test failed, say /retest to rerun them all:

Test name Commit Details Rerun command
ci/prow/e2e-aws-scaleup-rhel7 9075a83 link /test e2e-aws-scaleup-rhel7

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.

@ashcrow
Copy link
Member

ashcrow commented Nov 8, 2019

/override ci/prow/e2e-aws-scaleup-rhel7

@openshift-ci-robot
Copy link
Contributor

@ashcrow: Overrode contexts on behalf of ashcrow: ci/prow/e2e-aws-scaleup-rhel7

In response to this:

/override ci/prow/e2e-aws-scaleup-rhel7

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.

@cgwalters
Copy link
Member

@ashcrow FWIW that context is non-blocking, you don't need to override it.

@openshift-merge-robot openshift-merge-robot merged commit 0cffa48 into openshift:master Nov 8, 2019
cgwalters added a commit to cgwalters/release that referenced this pull request Jul 28, 2020
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Booting in FIPS mode day-1 causes errors on firstboot
9 participants