fix: use pre-downloaded binaries for cfssl #568
Conversation
|
Thank you! Do you have any other suggestions on how to harden the Dockerfile? |
|
This seems to have introduced a bug: webhook-installer Generating server certificate for "cloud-operator" in namespace "vcp".
webhook-installer Unhandled exception. System.ComponentModel.Win32Exception (2): An error occurred trying to start process 'cfssl' with working directory '/certs'. No such file or directory |
It's not a bug, you need to pre-download the binary on your docker image (instead of expecting the image itself to download it). |
Sorry @buehler I just now saw this. I use an internal company image for runtime, but I would say, use a distroless image. E.g. instead of the operator could propose this for the Dockerfile: Warning: I haven't tested this. it may be that "addgroup" does not actually exist in the cbl-mariner image, and you have to rely on pre-existing user/group (it should be running as non-root already by default). |
It is very much a bug, as its a breaking change. It should be v8.x... also, all users who arent using this docker file (such as ourselves using Cloud Native Buildpacks) or others that are combining this with other code and utilizing their own dockerfile will not be regenerating a Dockerfile which every build. (That's not standard practice at all). Also, a better error message when the tool is not found would be helpful since most users are likely not using it in the same way you are at your company. I think a hook that can be extended with code ( to add the old functionality back for those of us who would need it ) would be a good compromise. I will submit a fix for this if that's ok, @buehler #578 for your consideration |
|
Agree it was a breaking change, sorry for that/ that I hadn't considered existing users. Thanks for the PR! |
With buehler#568 these executables are no longer downloaded on demand, but rather predownloaded to the system. When running `dotnet build` locally, it attempts to run `./cfssl` and `./cfssljson` from `/operator` or `$CFSSL_EXECUTABLES_PATH`. However, it deletes them after it's done. Next time you try build again after cleaning the local dir it'll fail.
With #568 these executables are no longer downloaded on demand, but rather predownloaded to the system. When running dotnet build locally, it attempts to run `./cfssl` and `./cfssljson` from `/operator` or `$CFSSL_EXECUTABLES_PATH`. However, it deletes them after it's done. Next time you try build again after cleaning the local dir it'll fail. Co-authored-by: Christoph Bühler <buehler@users.noreply.github.com>
|
I am still having a problem with this and we are stuck at an older version. Does the generator still create the certs and docker file? Its expecting these executables in the /operator folder but nothing puts them there https://github.com/buehler/dotnet-operator-sdk/blob/v7.6.1/src/KubeOps/Operator/Commands/CommandHelpers/CertificateGenerator.cs#L59 |
This PR makes sure that the init pod will use pre-downloaded binaries, so that the operator can be deployed in offline scenarios. Also it no longer makes the assumption that binaries like
shandchmodexist in the docker image (a lot of hardened/ minimal images don't have shell on them).Other changes:
server.pemandserver-key.pemtoca.pemandca-key.pem- AFAICT, these are the file names generated by cfssljson ; yes I know it's confusing but these are different than the input ones.Fixes #567.