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

[RFC] schema: add storage.encryption section #515

Closed
wants to merge 3 commits into from

Conversation

lucab
Copy link
Contributor

@lucab lucab commented Feb 12, 2018

This introduces a new storage.encryption section which can be used
to provision LUKS volumes.
Volumes provisioned this way are meant to be unlocked early in the
boot process and made available in the initramfs (e.g. the rootfs).

@lucab
Copy link
Contributor Author

lucab commented Feb 12, 2018

/cc @dgonyeo for review. What do you use to keep JSON format coherent? I used js-beautify -k -n -r -s 2 schema/ignition.json and it introduced some minimal fixes; should we standardize on something?

Copy link
Contributor

@ajeddeloh ajeddeloh left a comment

Choose a reason for hiding this comment

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

File headers should be 2018.

The docs should probably also have a section in the operator notes on how wipeVolume is handled with regards to PXE booting with persistant root (similar to the filesystems section).

Will this be ammended with the implementation or is that coming in a seperate PR?

// Validate ensures a Cryptsetup entry is sane
//
// It fulfills validate.validator interface.
func (e Encryption) Validate() report.Report {
Copy link
Contributor

Choose a reason for hiding this comment

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

These can be broken up into Validate<FIELDNAME>() functions which will let the validator logic be a little more precise with line numbers when reporting errors. The file section has some examples.

@coreosbot
Copy link
Contributor

Can one of the admins verify this patch?

This introduces a new `storage.encryption` section which can be used
to provision LUKS volumes.
Volumes provisioned this way are meant to be unlocked early in the
boot process and made available in the initramfs (e.g. the rootfs).
@lucab
Copy link
Contributor Author

lucab commented Feb 13, 2018

@ajeddeloh thanks, I didn't know about generics Validate reflection. I added a section in the doc for wipeVolume too.

Implementation will follow in a separate PR, with the key fetching/unwrapping logic in coreos/coreos-cryptagent#5 (in case you have review cycles for that too, feel free to).

}

return r
}
Copy link
Contributor

Choose a reason for hiding this comment

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

You should add a func (c Content) ValidateSource() report.Report that calls validateUrl (or maybe something else since this only supports https?) on c.Source.

Copy link
Contributor Author

@lucab lucab Feb 22, 2018

Choose a reason for hiding this comment

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

I've slightly bent validateURL to take an additional optional subset of whitelisted schemes, let me know if you prefer something simpler and dedicated instead.

@lucab
Copy link
Contributor Author

lucab commented Mar 1, 2018

@dgonyeo I guess I'll wait and rebase once #519 lands, as this is easier to rebase.

@lucab lucab removed this from the 0.23.0 milestone Feb 28, 2020
@lucab lucab changed the title schema: add storage.encryption section [RFC] schema: add storage.encryption section Feb 28, 2020
@lucab
Copy link
Contributor Author

lucab commented Mar 3, 2020

@arithx is there anything you want to salvage from here? Otherwise I'd just close it as just another stale PR.

@arithx
Copy link
Contributor

arithx commented Mar 3, 2020

@lucab feel free to nuke.

@lucab lucab closed this Mar 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants