Add a fips flag to install-config.yaml
#2594
Conversation
openshift-ci-robot
added
the
size/XXL
|
So with this PR so far, I verified that the encapsulated MachineConfig that ends up on the node has |
cgwalters
force-pushed
the
fips
branch
2 times, most recently
from
5d314a4
to
2dce0ae
Compare
|
To emphasize, this PR is just "sugar" for providing MachineConfig objects which set |
|
/test govet |
|
OK, fixed the unit tests, and addressed comments! |
|
/approve |
openshift-ci-robot
added
the
approved
|
/hold Need to make sure a global FIPS option is more appropriate than per pool. |
openshift-ci-robot
added
the
do-not-merge/hold
Prep for FIPS.
Apparently the code in library-go which parses these doesn't honor multiple YAML documents. I thought about fixing that but on the other hand, there's no really good *reason* for us to not just write out individual files either. It's clearer. Prep for FIPS injecting another MachineConfig.
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.
|
/test e2e-aws |
|
@cgwalters: The following tests 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. |
|
Addressed comments! |
Fair question - who makes that call? |
Discussed during group G arch call, feedback from PM and @crawford is that non FIPs hosts taint a cluster so it has to be cluster scoped. |
|
/hold cancel |
openshift-ci-robot
removed
the
do-not-merge/hold
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: abhinavdahiya, cgwalters, sdodson 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 |
Our new thought around this is that really FIPS should be a "day 1" operation, and we don't want to make it really easy to undo. See also openshift/installer#2594 Anyone who wants to force this can change the MC flag, then `oc debug node` and run the disable command by hand, then reboot. Our MachineConfig merge semantics should make it hard for this to happen unless the admin explicitly deletes the installer-generated MC, but still. Since we don't support it and don't want customers to do it by accident, let's disable it and also stop wasting compute hours testing it. Further, a pending RHCOS change will delete the FIPS command entirely and move it into the initramfs. Cleanly handle that case by also refusing to enable FIPS "day 2" - what we expect to be the future. But we still support enabling day 2 for testing until that RHCOS change lands.
The more-convenient property got vendored in with 5366d28 (vendor: Bump machine-config-operator to latest, 2019-10-30, openshift#2594) as part of FIPS support.
The more-convenient property got vendored in with 5366d28 (vendor: Bump machine-config-operator to latest, 2019-10-30, openshift#2594) as part of FIPS support.
The more-convenient property got vendored in with 5366d28 (vendor: Bump machine-config-operator to latest, 2019-10-30, openshift#2594) as part of FIPS support.
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.