Skip to content

Conversation

@cgwalters
Copy link
Member

No description provided.

@openshift-ci-robot openshift-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 29, 2019
@openshift-ci-robot openshift-ci-robot added the size/S Denotes a PR that changes 10-29 lines, ignoring generated files. label May 29, 2019
@openshift-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters

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

The pull request process is described here

Details 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 openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 29, 2019
cmd := "/usr/libexec/rhcos-tools/coreos-fips"
args := []string{arg}
dn.logSystem("Running %s %v", cmd, args)
return exec.Command(cmd, args...).Run()
Copy link
Member

Choose a reason for hiding this comment

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

This looks like the right command to me. One thing to keep in mind is that, within OCP, the coreos-fips will not default to updating the kernel args and, instead, defer to MCO to own those args.

Copy link
Member Author

Choose a reason for hiding this comment

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

Let's debate that in openshift/rhcos-tools#2 since...it seems to me doing it that way would make everything unnecessarily more complex.

Copy link
Member

Choose a reason for hiding this comment

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

I closed the PR which would offload kernel args to the MCO. This call should be good as is.

@openshift-ci-robot
Copy link
Contributor

@cgwalters: PR needs rebase.

Details

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.

@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 7, 2019

// updateFIPS handles changes in FIPS
func (dn *Daemon) updateFIPS(oldConfig, newConfig *mcfgv1.MachineConfig) error {
if 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.

wait, shouldn't this be ==?

Copy link
Member

Choose a reason for hiding this comment

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

I know this is wip, just leaving also a comment that we still miss a call to updateFIPS 💪

// It sorts all the configs in increasing order of their name.
// It uses the Ignition config from first object as base and appends all the rest.
// Kernel arguments are concatenated.
// FIPS uses the last specified value.

Choose a reason for hiding this comment

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

I think this will be confusing for users, especially because unset values will decode into false. Like, the following would have FIPS mode OFF:

metadata:
  name: 00_config_controller
spec:
  config: ...
---
metadata:
  name: 99_config_fips
spec:
  FIPS: true
---
metadata:
  name: 99_config_master
spec:
  osImageURL: thelatestversion

Copy link
Member

Choose a reason for hiding this comment

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

We might want to go pointer then to differentiate between set/unset as well?

Choose a reason for hiding this comment

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

Yeah, probably. Another option would be to fail closed, i.e. if ANY configs have FIPS=true, it will be turned on.

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. do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants