Approved images
There is a a local image registry for UiO. All applications and services used in production must be based on updated and approved base images that are retrieved from here. The use of images directly from public registries like DockerHub and similar is not allowed. If building images yourself, it is permitted to base these builds on maintained images from Red Hat's "container catalog". The local registry provides a security-cleared set of container images from external repositories.
New images
Which container images and repositories are to be offered through the local registry is evaluated by the team that will use the image. New images to be added to the local registry must be registered in a separate web form. Advice from UiOs IT security team can be obtained if needed.
There is a large selection of container images in Red Hat's container catalog. These are generally better maintained than many of the images available on DockerHub. Therefore, anyone seeking to retrieve new images must first check if a corresponding image is available there.
See further under "Container Images"
Dockerfiles and labeling of applications
There must be full traceability of the artifacts included in an image that runs on server networks. Dockerfiles and/or build pipelines must be in a version controlled system with read access for the organization and with access to create pull requests against the repo. Committing new layers is not allowed except in sandbox testing, as this destroys traceability. The use of local files that are added must be documented with a reference to where the file came from, and possibly why the software repo in the base image was not used. External files must also be downloaded over https as a general rule, and if this is not possible, the checksum on the file must be validated.
All applications running in containers must have a contact address in the Dockerfile. The contact address should be set in the label "no.uio.contact" and can, for example, be the email list for the team or application. All images must also be labeled with the team/application name. This is to ensure that no applications run without a responsible owner. In addition to this, there must be a clear relationship between the version of the application's Dockerfile and the image in the registry, which is done by using docker tags.
Secrets
Secrets used in the application should not be included in the Dockerfile or Docker images themselves, but added securely during container startup. IT Security can assist with risk assessment in connection with the use of secrets in the application. Secrets in applications must be treated the same way as passwords and must be changed at least once a year.
Logging
Containers running in production must log container output to ELK via journald. In addition to this, each individual application must log as usual based on requirements for audit logs, access logs, etc.
Updates to container images and vulnerabilities
All container images that are maintained locally and are in use for services in production must be built, uploaded (pushed) to the registry, downloaded (pulled), and restarted at least once a month.
The build process must include elements that ensure that the application's baseline is updated during building. That is, yum/apt/apk upgrade (and similar) for the operating system layer and similarly for the application framework (npm, pip, etc.) so that all dependencies for the application are updated in the build process. Building must be done without caching of image layers. This is to ensure against reuse of old and outdated components. (--no-cache option to Docker build, for example.)
No containers should run images that were built more than a month ago. This is to ensure a basic foundation for exposing vulnerable services.
Vulnerabilities in container images
Images in the local registry must be regularly scanned for vulnerabilities with their own analysis tool that keeps track of what is installed in the various layers of the image and which vulnerabilities exist.
Vulnerabilities in running containers and applications
An overview of all container images running from containers must be collected to a central location, and reports should automatically be generated to application owners about which instances are running with potentially vulnerable image layers. Responsible parties for the application are also responsible for ensuring that the application runs on an updated base image and that vulnerable applications are updated based on vulnerability reports and a separate assessment based on knowledge of the application. IT Security is responsible for ensuring that vulnerability reports are followed up. Updating images for running containers must occur at least once a month. Building and redeployment of containers should be automated as much as possible. Reports will be sent out informing about running services that deviate from policy. It is the responsibility of the service owner to follow up on the deviations in consultation with IT security.
Building application images
Application images can be built on and pushed from any approved server and client platforms at UiO. To reduce the attack surface against applications running in containers, the application image should be built as minimally as possible and avoid unnecessary dependencies. An effective measure here is to use a minimal base image. At the time of writing, Alpine Linux and Busybox are examples of such base images.
Running containers
Delivery of container-based production services is made on an approved runtime environment for containers. This is currently RHEL7-server (and newer) with standard operating procedures and an approved central Kubernetes/OpenShift solution. It is only allowed to use build tools and container runtimes that are available through Red Hat's software sources. Other versions are allowed in closed sandbox environments. The requirement is justified by the fact that RHEL7 follows standard operating procedures for Linux servers with daily package updates. Additionally, frameworks on RHEL7 are automatically protected by SELinux. This provides a higher degree of isolation than container hosts without "mandatory access control".