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

pkg/daemon: support FIPS #889

Merged
merged 1 commit into from
Jun 25, 2019

Conversation

runcom
Copy link
Member

@runcom runcom commented Jun 25, 2019

Signed-off-by: Antonio Murdaca runcom@linux.com

- What I did

resurrected from #826
close #800

Added a new FIPS field to MachineConfig to enable/disable FIPS on rhcos (disabled by default). This is, at this point, only intended as a day-2 operation.

FIPS would also greatly benefit a dedicated CRD (oc edit fips?) - I'm experimenting with that but it will ofc require a new controller.

- How to verify it

added an e2e and manually verified

- Description for the changelog

Added FIPS support

@openshift-ci-robot openshift-ci-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jun 25, 2019
@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jun 25, 2019
@@ -369,6 +400,7 @@ func Reconcilable(oldConfig, newConfig *mcfgv1.MachineConfig) (*MachineConfigDif
return &MachineConfigDiff{
osUpdate: oldConfig.Spec.OSImageURL != newConfig.Spec.OSImageURL,
kargs: !reflect.DeepEqual(oldConfig.Spec.KernelArguments, newConfig.Spec.KernelArguments),
fips: oldConfig.Spec.Fips != newConfig.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.

This will force the reboot so that the change takes effect, correct?

Copy link
Member Author

Choose a reason for hiding this comment

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

nope, the sync itself does the reboot the node (and it can't be avoided today as we know). This is just to log what we're changing during a sync.

Copy link
Member

Choose a reason for hiding this comment

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

WFM. Just wanted to ensure a reboot does happen when FIPS changes 👍

Copy link
Member Author

Choose a reason for hiding this comment

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

👍 the e2e added here also takes care of validating fips has been enabled on nodes so it will fail if we skip a reboot after enabling fips (iiuic)

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.

👍

@@ -37,6 +37,8 @@ const (
coreUserName = "core"
// SSH Keys for user "core" will only be written at /home/core/.ssh
coreUserSSHPath = "/home/core/.ssh/"
// fipsCommand is the command to use when enabling or disabling FIPS
fipsCommand = "/usr/libexec/rhcos-tools/coreos-fips"
Copy link
Member

Choose a reason for hiding this comment

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

Sort of a side comment but I recently was thinking that we probably should have taken the path of replacing /usr/bin/fips-mode-setup; we can totally do that now via override layers.

@@ -51,6 +51,7 @@ type MachineConfigSpec struct {
// Config is a Ignition Config object.
Config ign.Config `json:"config"`
KernelArguments []string `json:"kernelArguments"`
Fips bool `json:"fips"`
Copy link
Member

Choose a reason for hiding this comment

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

What about Erica's comment here?

outIgn := configs[0].Spec.Config
for idx := 1; idx < len(configs); idx++ {
// if any of the config has FIPS enabled, it'll be set
Copy link
Member

Choose a reason for hiding this comment

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

Ah OK I see we went with the last approach. I think that's sane for this indeed.

@cgwalters
Copy link
Member

LGTM, giving to
/assign ericavonb
since she reviewed an earlier version.

@@ -94,6 +95,10 @@ Ignition config keys as well.

This extends the host's kernel arguments. Use this for e.g. [nosmt](https://access.redhat.com/solutions/rhel-smt).

### FIPS

This allows to enable/disable [FIPS mode](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations).
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add a comment here about if any of the config has FIPS enabled, it'll be set as well?

cmd := exec.Command(fipsCommand, arg)
dn.logSystem("Running %s %s", fipsCommand, arg)
if out, err := cmd.CombinedOutput(); err != nil {
return errors.Wrapf(err, "enabling FIPS: %s", string(out))
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you include arg in the error to distinguish between errors from enabling and disabling FIPS?

Copy link
Member Author

Choose a reason for hiding this comment

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

oh good catch this is completely wrong indeed

@@ -546,3 +546,91 @@ func TestDontDeleteRPMFiles(t *testing.T) {
}
}
}

func TestFIPS(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

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

non-blocking suggestion: it might be nice to have this test structured as a table test with a couple variations of machineconfig sets.

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, that would be amazing but test timeout is 75m today and going through various reboots for applying the MC + other tests would exceed that

return dn.updateOSAndReboot(newConfig)
}

func (dn *Daemon) updateFIPS(current, desired *mcfgv1.MachineConfig) error {
if current.Spec.Fips == desired.Spec.Fips {
Copy link
Contributor

Choose a reason for hiding this comment

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

Does the current get written to Status anywhere?

Copy link
Member Author

Choose a reason for hiding this comment

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

nope

Co-authored-by: Colin Walters <walters@verbum.org>
Co-authored-by: Antonio Murdaca <runcom@linux.com>
Signed-off-by: Antonio Murdaca <runcom@linux.com>
@runcom
Copy link
Member Author

runcom commented Jun 25, 2019

Took care of @ericavonb comments

@runcom
Copy link
Member Author

runcom commented Jun 25, 2019

/retest

@ericavonb
Copy link
Contributor

/lgtm

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

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ashcrow, ericavonb, runcom

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 [ashcrow,ericavonb,runcom]

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

@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

1 similar comment
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@kikisdeliveryservice
Copy link
Contributor

Gah. This is hitting AWS/ECS errors now: Error: error attaching EC2 Internet Gateway...

@openshift-merge-robot openshift-merge-robot merged commit c73d4ad into openshift:master Jun 25, 2019
@runcom runcom deleted the fips-all-the-things branch June 25, 2019 19:32
cgwalters added a commit to cgwalters/installer that referenced this pull request Oct 30, 2019
Part of: openshift/enhancements#15

We added FIPS to the MCO a while ago:
openshift/machine-config-operator#889

However, during some discussion it became clear that the main
use case for FIPS is "day 1" - it doesn't make sense to turn it
on "day 2" because the standard requires that e.g. long-term key
material was created with FIPS enabled.

Further, it's unlikely that admins will want to turn it *off*
if they ever had it on.

This is a good candidate for an install config.
cgwalters added a commit to cgwalters/installer that referenced this pull request Oct 30, 2019
Part of: openshift/enhancements#15

We added FIPS to the MCO a while ago:
openshift/machine-config-operator#889

However, during some discussion it became clear that the main
use case for FIPS is "day 1" - it doesn't make sense to turn it
on "day 2" because the standard requires that e.g. long-term key
material was created with FIPS enabled.

Further, it's unlikely that admins will want to turn it *off*
if they ever had it on.

This is a good candidate for an install config.
cgwalters added a commit to cgwalters/installer that referenced this pull request Oct 30, 2019
Part of: openshift/enhancements#15

We added FIPS to the MCO a while ago:
openshift/machine-config-operator#889

However, during some discussion it became clear that the main
use case for FIPS is "day 1" - it doesn't make sense to turn it
on "day 2" because the standard requires that e.g. long-term key
material was created with FIPS enabled.

Further, it's unlikely that admins will want to turn it *off*
if they ever had it on.

This is a good candidate for an install config.
cgwalters added a commit to cgwalters/installer that referenced this pull request Oct 31, 2019
Part of: openshift/enhancements#15

We added FIPS to the MCO a while ago:
openshift/machine-config-operator#889

However, during some discussion it became clear that the main
use case for FIPS is "day 1" - it doesn't make sense to turn it
on "day 2" because the standard requires that e.g. long-term key
material was created with FIPS enabled.

Further, it's unlikely that admins will want to turn it *off*
if they ever had it on.

This is a good candidate for an install config.
alaypatel07 pushed a commit to alaypatel07/installer that referenced this pull request Nov 11, 2019
Part of: openshift/enhancements#15

We added FIPS to the MCO a while ago:
openshift/machine-config-operator#889

However, during some discussion it became clear that the main
use case for FIPS is "day 1" - it doesn't make sense to turn it
on "day 2" because the standard requires that e.g. long-term key
material was created with FIPS enabled.

Further, it's unlikely that admins will want to turn it *off*
if they ever had it on.

This is a good candidate for an install config.
alaypatel07 pushed a commit to alaypatel07/installer that referenced this pull request Nov 13, 2019
Part of: openshift/enhancements#15

We added FIPS to the MCO a while ago:
openshift/machine-config-operator#889

However, during some discussion it became clear that the main
use case for FIPS is "day 1" - it doesn't make sense to turn it
on "day 2" because the standard requires that e.g. long-term key
material was created with FIPS enabled.

Further, it's unlikely that admins will want to turn it *off*
if they ever had it on.

This is a good candidate for an install config.
vrutkovs pushed a commit to vrutkovs/installer that referenced this pull request Dec 2, 2019
Part of: openshift/enhancements#15

We added FIPS to the MCO a while ago:
openshift/machine-config-operator#889

However, during some discussion it became clear that the main
use case for FIPS is "day 1" - it doesn't make sense to turn it
on "day 2" because the standard requires that e.g. long-term key
material was created with FIPS enabled.

Further, it's unlikely that admins will want to turn it *off*
if they ever had it on.

This is a good candidate for an install config.
vrutkovs pushed a commit to vrutkovs/installer that referenced this pull request Dec 2, 2019
Part of: openshift/enhancements#15

We added FIPS to the MCO a while ago:
openshift/machine-config-operator#889

However, during some discussion it became clear that the main
use case for FIPS is "day 1" - it doesn't make sense to turn it
on "day 2" because the standard requires that e.g. long-term key
material was created with FIPS enabled.

Further, it's unlikely that admins will want to turn it *off*
if they ever had it on.

This is a good candidate for an install config.
jhixson74 pushed a commit to jhixson74/installer that referenced this pull request Dec 6, 2019
Part of: openshift/enhancements#15

We added FIPS to the MCO a while ago:
openshift/machine-config-operator#889

However, during some discussion it became clear that the main
use case for FIPS is "day 1" - it doesn't make sense to turn it
on "day 2" because the standard requires that e.g. long-term key
material was created with FIPS enabled.

Further, it's unlikely that admins will want to turn it *off*
if they ever had it on.

This is a good candidate for an install config.
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/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants