feat: convert the container image to a rock - #45
Conversation
6f78780 to
63149f4
Compare
dwilding
changed the title
|
@tonyandrewmeyer please could you help to look at the failing checks for dependency-review and pip-audit? One because of a permission issue and one because it can't seem to audit itself (?)
Not urgent. Thanks! |
Those were problems, but there were actual security releases to be picked up as well. Opened #56 and then you can pull that into this branch once merged. |
74cc179 to
725995f
Compare
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
zizmor found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.
| uses: canonical/oci-factory/.github/workflows/Test-Rock.yaml@43f2710f69c29e43fd90f9e600896a7e32de96de | ||
| with: | ||
| oci-archive-name: ${{ matrix.artifact-name }} | ||
| ignored-vulnerabilities: CVE-2026-45447 # CVE affects OpenSSL version in Ubuntu base. |
There was a problem hiding this comment.
@cjdcordeiro, @alesancor1, please could I get your opinion on this?
If I don't ignore CVE-2026-45447, the Test-Rock workflow fails because of a vulnerability in the base (see run). I tried specifying libssl3t64 as a staged package in rockcraft.yaml, but it didn't help. Same when I tried specifying it as an overlay package.
Is ignoring the CVE the recommended approach?
There was a problem hiding this comment.
Does your image need to be baseful?
Considering it's just a FastAPI server you could use bare: base and install the python3.13-venv_ensurepip slice as a stage package. That should exclude many dependencies that would be caught by the CVE scan.
In case you do need that lib, if no fix has been produced upstream there's not much you can do, so you can just ack the CVE by ignoring it.
There was a problem hiding this comment.
Thank you for nudging me in this direction! I've switched to a bare base and everything looks to be working: the rock packs, our postgres integration test passes, and the build & test workflows pass without ignoring any CVEs. Passing run
Another bonus is smaller images - now only 5% the size of our current Docker images 🤯
I had to fiddle around with symlinks to get the image working properly. See comments in rockcraft.yaml. If you spot anything weird in there, please do let me know.
There was a problem hiding this comment.
That is great!
Regarding symlinks, you can totally get rid of that logic by just installing base-files_base, which will provide the fs structure for you!
Check any of our rocks for reference, e.g. memcached-rock, Note the following:
- base-files_base: Provides the filesystem structure
- base-files_chisel: Provides the chisel manifest
- base-files_release-info: Provides release info files like /etc/os-release
Additionally:
- deb-security-manifest part: Uses the chisel manifest to generate a
dpkg.queryused for security monitoring.
Also note the run-user: _daemon_ which makes the image rootless, if your image does not require root privileges (which afaict it doesn't) this is a good practice.
Feel free to navigate through any of our rocks and use them as reference, we use the same template for all of them 👍
There was a problem hiding this comment.
Thanks 🙂 I've incorporated run-user: _daemon_, base-files_base, and base-files_chisel. I found that I still need some symlink juggling to get things to work with the uv plugin (I couldn't find an example of that in the wild). I'm opening this for team review now - but will gladly try any other simplification ideas you might have!
tonyandrewmeyer
left a comment
tonyandrewmeyer
left a comment
There was a problem hiding this comment.
Worked fine for testing the rock manually, and rockcraft test.
| deb-security-manifest: | ||
| plugin: make | ||
| source: https://github.com/canonical/rocks-security-manifest | ||
| source-type: git | ||
| source-branch: main | ||
| override-prime: gen_manifest |
There was a problem hiding this comment.
Your workflow is scanning pip packages, which is okay, no further action needed there.
The manifest is used by our security team to monitor the rocks once released to a repository.
|
Thanks everyone for your help with this! In an earlier comment, Tony asked whether we need to be concerned about a Pydantic warning when packing. That's a known issue - being worked on in canonical/rockcraft#1196. As far as I'm aware, it's not possible to simplify I'm going to merge now, then push a tag and check that the images are correctly published. |
4 participants
This PR converts the image from a Docker image to a rock. I did a fair bit of experimentation, so I don't recommend reviewing the individual commits.
I've summarised the main points below and added comments at other notable places.
Dockerfileis replaced byrockcraft.yaml. It took me a while to figure out how to build with the uv plugin - see discussion - and I'm still not sure I'm using the absolute best approach.To reduce complexity, I decided to drop support for ppc64le. Hence bumping to version 2.0.0. There should be no functional changes on the remaining supported architectures (amd64 and arm64).
The integration test
.scripts/integration-test.shnow packs the rock and loads it into Docker.I brought in Rockcraft's
testprofile so that we have Spread tests and can runrockcraft test. For local development I recommendmake integrationas a lightweight alternative (provided you have Docker).I adapted
.github/workflows/build.yamlbased on this template. I don't think it's worth reviewing the diff. The fundamental idea is unchanged: we publish images to GitHub's container registry when a tag is pushed tomaster. The updated workflow relies on Build-Rock workflow and Test-Rock workflow, which does security scanning. See https://github.com/canonical/oci-factory#-reusable-workflows. Here's a passing dry-run in my fork.Preview of updated README