Building Image Hotfix for CVE¶

As OpenStack downstream project, we may get notified ahead of time about critical security vulnerabilities in OpenStack. This means, some people get patches before the public get’s announced about a security advisory.

Important

All information received via this must be treated as confidential, only shared with the people working on the issue and NEVER released to the public before the upstream advisory gets published!!!

In the following a process how to handle the patches, so we can provide fixed images as soon the embargo falls.

Yaook-Security Repository¶

We use a separate repository to build the patched images.

Main reason is to not loose opensource state at gitlab if we have to even one private repositories.

The steps need to be done by a member of the yaook-security group.

Fork the repo to yaook-security group (may to subgroup images) if not exist yet. Create the repo as private!! If the repo already exist, make sure it is set to private.
Create a branch, push the provided patches and backported patches there.
Add the patches to the image build script.
Check that the pipeline runs and includes your patches.
The images will get pushed to the (private) gitlab registry. We use the images of the feature branch and don’t merge them at the fork.
At the day the CVE will get published, download the patched images from gitlab registry.
You need to download the -amd64 and -arm64 version, as we want to provide both. Download for each supported OpenStack release.
Make sure the original image Repo can’t get any changes on the main/devel branch.
(e.g. by disabling push and merge for everyone.)
Check at the upstream yaook image what the next image version is (for the most images, this is in .next-version file.)
Tag the downloaded images with the original image name + tag of the next version.
Wait for the CVE to get published.
As soon the CVE got published (e.g. by making the bug public or message to openstack-announce mailinglist):
1. Upload both image versions for all OpenStack releases.
2. Create a manifest and push it, e.g.:
  ` docker manifest create "registry.yaook.cloud/yaook/keystone-${OPENSTACK_VERSION}:${image_tag}" "registry.yaook.cloud/yaook/keystone-${OPENSTACK_VERSION}:${image_tag}-arm64" "registry.yaook.cloud/yaook/keystone-${OPENSTACK_VERSION}:${image_tag}-amd64" docker manifest push "registry.yaook.cloud/yaook/keystone-${OPENSTACK_VERSION}:${image_tag}" `
Set the repository to public to show how the images got build.
Create a MR from the fork and branch with patches to the original repository.
Delete or depublish the repository after at most one week. So no one can later see by checking the repos if there are new CVEs (based on that we took the repo offline again).

CI Variable Settings¶

The group and subgroups needs some settings, so pipelines works without changes to the repos. This is configured one time for the whole group/subgroup and don’t need adjustment afterwards.

At group level:

REGISTRY_PASS: Set to $CI_REGISTRY_PASSWORD with “Expand variable reference” enabled, Visibility: Visible
REGISTRY_PROJECT: Set to yaook-security Visibility: Visible
REGISTRY_URL: Set to $CI_REGISTRY with “Expand variable reference” enabled, Visibility: Visible
REGISTRY_USER: Set to $CI_REGISTRY_USER with “Expand variable reference” enabled, Visibility: Visible

For each subgroup the REGISTRY_PROJECT needs to get overridden:

REGISTRY_PROJECT: Set to yaook-security/images/$CI_PROJECT_NAME with “Expand variable reference” enabled, Visibility: Visible Change the subgroup with the name your group has.

Pipeline Runner¶

We have separate pipeline runners hosted by ALASCA for us. An ARM-Runner is currently hosted at STACKIT.

Members of Yaook-Security Group¶

The list of the members is keept as small as possible. Only the two project maintainers and people known to be on the embargo list are part of the group. Based on each issue additional people can be add to only the affected project, if they work creating/backporting the patches.