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

Feat: allow marking paths as finalized in an image and refuse to build derived images that update them. #510

Open
mikemccracken opened this issue Sep 21, 2023 · 0 comments

Comments

@mikemccracken
Copy link
Contributor

Is your feature request related to a problem? Please describe.

It is too easy to accidentally update important files when building derived images, e.g. by installing distro packages.

We don't need a guarantee that an image updating a given file can never be created, that is out of scope, we just want a way to catch when an accidental update has happened early enough to fix it without a lot of debugging.

Describe the solution you'd like

Add the concept of "Finalized" paths/globs to mark a set of filenames as the final version of a file, so that any stacker builds that import the image and try to write to that file will fail, with an error like /etc/ssl/certs/* has been marked as final in image 'minbase' and can not be updated.

This would mostly be a guardrail, not a security guarantee of course, since tools could ignore it and create valid images.

We could store it as an annotation, or just a hidden file in the image at /.stacker-finalized (name tbd).

As for how to specify it, I like the approach of just allowing the run script to append paths / globs to a file in /stacker/, and not have to add lines to the yaml. This makes it a little more flexible, but there is a failure mode where you build such an image with an old stacker that doesn't know about it and it happily succeeds doing nothing.

My use case is to allow a platform team to mark certain files as off limits and feel reasonably confident that product adopters wouldn't unintentionally mess them up.

(I think the simplest way to implement it would be to just build the image and check the paths once the diff is available)

Describe alternatives you've considered

No response

Additional context

No response

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

No branches or pull requests

1 participant