Skip to content
This repository has been archived by the owner on Dec 8, 2023. It is now read-only.

Add support for cloud-init ca-certs field #744

Open
philomory opened this issue Sep 8, 2021 · 5 comments
Open

Add support for cloud-init ca-certs field #744

philomory opened this issue Sep 8, 2021 · 5 comments
Labels
kind/feature A new feature

Comments

@philomory
Copy link

Is your feature request related to a problem? Please describe.
I'd like to add a private CA as a trusted root to k3os. Cloud-init provides a way to accomplish this, via the ca-certs parameter, but k3os doesn't seem to support this parameter.

Describe the solution you'd like
I'd like k3os to support using ca-certs.trusted in the cloud-init data to add trusted root CAs (while leaving the existing trusted roots in place unless ca-certs.remove-defaults is set to true).

Describe alternatives you've considered
I considered manually adding the certificate using write_files, but this is difficult to do correctly due to a bug in k3os's implementation of update-ca-certificates (#518).

@philomory philomory added the kind/feature A new feature label Sep 8, 2021
@dweomer
Copy link
Contributor

dweomer commented Sep 10, 2021

The workaround in #518 should be something you can capture in a write_files + run_cmd:

Actually I made a workaround:

Moved the /etc/ssl/certs/ca-certificates.crt to /usr/local/share/ca-certificates
Manually append all wanted certificates with cat *.crt >> /usr/local/share/ca-certificates/ca-certificates.crt
Created directory mkdir -p /etc/ca-certificates/update.d/
Executed command sudo update-ca-certificates

@dweomer dweomer closed this as completed Oct 22, 2021
@philomory
Copy link
Author

Was this closed because a workaround exists, or because there has been an affirmative decision to reject the feature request? Personally I'd still like to see k3os support the standard cloud-init ca-certs parameter.

@philomory
Copy link
Author

philomory commented Nov 8, 2021

@dweomer I was wondering about the reasoning behind closing this issue? Was it closed simply because a workaround exists, or was it closed because there has been an affirmative decision to reject the feature request? Personally I'd still like to see k3os support the standard cloud-init ca-certs parameter rather than requiring this sort of non-obvious, error-prone workaround. Even if the bug in #518 was fixed, the cloud-init ca-certs parameter would still be preferable to using write_files and run_cmd to add the certificate.

@dweomer
Copy link
Contributor

dweomer commented Nov 9, 2021

@dweomer I was wondering about the reasoning behind closing this issue? Was it closed simply because a workaround exists, or was it closed because there has been an affirmative decision to reject the feature request? Personally I'd still like to see k3os support the standard cloud-init ca-certs parameter rather than requiring this sort of non-obvious, error-prone workaround. Even if the bug in #518 was fixed, the cloud-init ca-certs parameter would still be preferable to using write_files and run_cmd to add the certificate.

@philomory apologies for missing your original follow-up: I am happy to re-open this but I must also admit that I do not foresee working on this anytime soon. It would definitely be nice to have!

@dweomer dweomer reopened this Nov 9, 2021
@philomory
Copy link
Author

@dweomer I've tracked down the underlying reason for #518 and have submitted a PR to fix it in #818; my intent is to follow up with a second PR that adds the cloudinit ca-certs functionality once update-ca-certificates itself works as intended.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/feature A new feature
Projects
None yet
Development

No branches or pull requests

2 participants