Feature: Fail on inclusion of "dangerous packages"

[strategicpause]

What I'd like: When troubleshooting an issue, I'll create an AMI which includes the login package in order to poke around the underlying host. One of my concerns is that I might include this package in my Config.toml by mistake and push it to a production environment.

I'd like to see some kind of mechanism in which "dangerous packages" can be added to a list. Should I build an AMI with this package included, then the build should fail. As a developer who needs to use these packages in a development environment, then I can include a flag to override this behavior (e.g. --allow-unsafe-packages).

This would open the door for introducing other packages which may never be included in prod (e.g. with curl or other helpful tools), but would be super helpful for debugging.

Any alternatives you've considered: Careful code reviews.

[ytsssun]

Hi @strategicpause, this is a fair ask. For Bottlerocket, we have dev variants that include tools that we don't ship with our prod variants. (i.e. https://github.com/bottlerocket-os/bottlerocket/blob/develop/variants/aws-dev/Cargo.toml#L35)

Is this something that would fit your use case?

[bcressey]

Twoliter has the "image features" mechanism which could work well for this; these features are exposed as capabilities that packages can require or conflict with. For example, the kernel-5.10 package conflicts with the erofs-root-partition feature.

If there was an image feature like interactive-usage then packages like login and bash could say this in their specs:

Conflicts: %{_cross_os}image-feature(no-interactive-usage)

And then they would be blocked from being installed unless the variant specified the image feature.

[strategicpause]

@ytsssun - Not quite. I have my own set of variants, and I want to make sure that including the login package (in this example) results in a failure unless an override is explicitly added.

@bcressey - This is getting closer to what I'm looking for. However, I can see developers removing such a line when there is a need to build a debug AMI, and then accidentally committing it. Ideally I'd like the check to be made from a CLI argument as we can lean on the build system in a pipeline catching this error (e.g., by not including a override flag in the CLI arguments) and preventing changes from going out.

I like the example provided, but there are cases where I may need bash, but not login, so I would prefer to have this configurable on a per-package basis. This could open the door to teams adding their own debug packages (e.g. with extra debug tools) that they would not otherwise want to have going out in a production variant.