12:49 <dustymabe> mass rebuild going on right now in Fedora.. which means some of our pipeline builds might fail because signing is taking a long time

16:26 <fifofonix> Reviewing month's enhancements documentation i see the enhancement to remove userdata for vSphere/fusion.

16:26 <fifofonix> Was there any consideration/thought ever given to somehow doing the same for cloud providers?

16:29 <fifofonix> I was wondering whether there would be a way to somehow reduce what is in cloud userdata by leveraging the layering stuff in some kind of structured way thereby improving security in some scenarios.

16:49 <bgilbert> fifofonix: Ignition now removes userdata for every platform where we know of a way to remove it.

16:50 <bgilbert> fifofonix: there are some additional platforms that provide a control-plane API call to remove userdata, but the VM can't use that API without the user's credentials, so we don't try to do anything on those either

16:50 <bgilbert> fifofonix: if you know of additional platforms where the VM is allowed to modify/delete userdata, please do let us know. I'd like to support that functionality wherever we can.

16:50 <fifofonix> got it. no way i know of to remove from aws say. obvs never include secrets in userdata. but even then you often have to have scripts which have ways/means of deriving secret 0. moving that to the layering might make sense as a use case?

16:53 <bgilbert> fifofonix: Ignition's current recommendations are at https://coreos.github.io/ignition/operator-notes/#secrets

16:53 <bgilbert> but saying "use Hashicorp Vault" is not the same as a worked example. some additional work is needed here

16:54 <bgilbert> I can't speak to the layering side of things unfortunately

16:54 <bgilbert> (haven't followed layering closely)

16:55 <fifofonix> i'm using vault already with the trust model. but you can still spy my scripts which spell out how that interaction happens in userdata. i'm thinking maybe best practice is to push that into a private fcos image.

16:56 <bgilbert> I think ideally vault would bind to a local trust root e.g. a TPM

16:57 <fifofonix> bgilbert: thanks for that link btw.

16:57 <bgilbert> +1

16:58 <bgilbert> I don't think we're actively working on this currently, so if you'd like to contribute any docs, that'd be awesome

16:59 <bgilbert> if you develop a model that works well for you

17:03 <fifofonix> i'm going to stew on it further. i'm already applying one of the mitigations in your link (networkpolicies) to restrict access to metadata but security in layers is the way forward - think i need to implement the other mitigator listed, ie. subsidiary ignition script at secure https location. thnks.

17:06 <bgilbert> +1

18:14 <phynecs> anyone using vultr to run coreos? (if this is the wrong chat to ask just tell me ^^)

18:15 <phynecs> because I don't have it available as en OS when creating a new VM

18:15 <phynecs> even though they are advertising it here: https://www.vultr.com/servers/fedora-coreos/

18:35 <dustymabe> phynecs: just follow https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-vultr/

18:50 <phynecs> @dustymabe thx will have a look

19:59 <dustymabe> walters: want to address https://github.com/coreos/coreos-assembler/pull/3001#issuecomment-1191854687 and then override/merge ?

20:02 <walters> i can get that change into another PR?

20:04 <dustymabe> but shouldn't it go in the same commit that removed the code the comment was referring to?

20:05 <walters> sure, pushed

20:06 <dustymabe> thanks!

20:08 <dustymabe> I'll comment in the COSA issue

20:08 <dustymabe> and close it