-
Notifications
You must be signed in to change notification settings - Fork 556
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
Support userdata privacy beyond cloudinit #1875
Comments
cc @dongsupark |
We can think about the original use case though. What mechanisms are there for mechanisms to provide secrets in userdata. I guess these fall into:
either of those passed into The reason we're using the boothook is that we need to reconstruct the user-data as there's a 10KB limit on AWS Secrets Manager. If we also supported S3 as a mechanism, might become simpler. |
I think we should try out S3. Where should be the ignition code then? |
I think the S3 code should perhaps live in here and work in a similar way to the current method, in that other infrastructure providers can use their own object storage then for the final pass to the userdata. Either that or you make an S3 backend compulsory which may mean deploying minio and making assumptions around network connectivity between the management and workload clusters. Long term, we can also think about chaining a "bootstrap generator" and a "bootstrap injector" as separate things for v1alpha4. |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/lifecycle frozen |
I've made some recent work on CABPK (kubernetes-sigs/cluster-api#4172), which adds support to generate bootstrap data in Ignition format. I also have a WIP branch for CAPA, which adds remaining bits to support provisioning clusters running Flatcar (#1979). My work involves:
I'd really appreciate some feedback on this suggestion. I'm right now finishing this work, cleaning up, I'll try to also add IAM support, some tests etc before I can open the PR. |
I certainly like the sound of this update, the small ignition snippet style and loading from S3 is certainly a common pattern so makes sense to keep to that.
Out of interest, can we account here for generating a v2 vs v3 ignition snippet? Have you thought about this already? Another suggestion I would have is to try and see what other providers can do in this area, perhaps there's some discussion that could be had more centrally about this so we establish a common pattern across the different clouds. |
Yes, similar to CABPK, I use v2 Ignition for Flatcar by default, with easy to add v3 support.
I think other cloud providers will be simpler to implement. E.g. Azure and GCP puts userdata directly in instance metadata, without any sort of middleware service. I'd expect them to work out of the box (or almost) with proposed CABPK changes. Only AWS is special due to userdata size limitation. |
/close |
@randomvariable: Closing this issue. In response to this:
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. |
/kind feature
Describe the solution you'd like
[A clear and concise description of what you want to happen.]
#1490 added support for preventing users reading secrets essential to the cluster via EC2 userdata, by shifting a version of the userdata to AWS Secrets Manager and injecting a boot hook using multi-part MIME to download the real user-data.
This is a cloud-init specific solution which will not work with other bootstrap providers such as Ignition.
The aim is therefore to find a bootstrap provider agnostic form of userdata privacy.
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:
kubectl version
):/etc/os-release
):The text was updated successfully, but these errors were encountered: