Docker Image Scan results for rancher/nginx-ingress-controller

Scan performed at 2022-12-12 15:23:07 using the CoGuard CLI

Summary

21 Total failed checks. 5 High / 4 Medium / 12 Low.

Details

Rule identifier Severity Documentation
nginx_x_frame_options_header 4 There is an HTTP response header that makes it harder to do clickjacking. NGINX can automatically set this header for every response by setting add_header X-Frame-Options to either SAMEORIGIN or DENY in nginx.conf.
Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
nginx_ssl_protocols_tls_1_2_higher 4 By default, NGINX uses for ssl_protocols the value TLSv1 TLSv1.1 TLSv1.2.
Since any protocol before TLSv1.2 is deprecated, it is recommended to change this default and only use TLSv1.2 or higher.Remediation: Set the ssl_protocols on the http block to any protocols greater or equal to TLS1.2.
Source: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols.
nginx_x_xss_protection_header 4 Although being largely replaced nowadays by the Content-Security-Policy header, it is still advisable to add the header X-XSS-Protection to every response to protect older web browsers from potential cross site scripting attacks.
Remediation: Ensure that every http block in your NGINX configuration has add_header X-XSS-Protection [VALUE], where value is not 0.
Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
nginx_content_security_policy_header_set 4 Modern browsers support a header called Content-Security-Policy, where multiple combinations of directives are possible to be set to ensure that the delivered content is not tampered with (e.g. by XSS attacks). This check flags if there is no such header added to an http directive of NGINX.
Remediation: Ensure that every http block in your NGINX configuration has the add_header Content-Security-Policy value with some basic rules enabled.
Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
nginx_hsts_header_added 4 There is an HTTP response header that instructs the browser to only communicate with the website using HTTPS, the so called HSTS header. This one should be enabled.
Remediation: In the http section of the nginx.conf, ensure that there is a directive of the form add_header Strict-Transport-Security "max-age:<YOUR-VALUE>; includeSubdomains"
Source: https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project#hsts
nginx_limit_simultaneous_connections 3 In order to avoid having a single user over-loading the system with parallel connections, NGINX provides a module to limit the parallel connections possible to be opened by a so-called connection zone opened by a user.
Remediation: Set the limit_conn key on the top level of the http-block to a value that would fit your specific use case.
Source: http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html
dockerfile_do_not_upgrade_packages 3 One desirable goal of docker images is that changing their Docker-files and re-building them in the future does not cause issues unrelated to the new changes. One way an image may not build in the future is if the Dockerfile contains instructions to upgrade a certain package to the latest version, i.e. not specifying a version.
Remediation: Ensure that inside a Dockerfile, the following commands are never run:
- apt-get upgrade
- apt-get dist-upgrade
- apt upgrade
- apt full-upgrade
- yum upgrade
- yum update
- pacman -S.*u (u contained after S
- pacman -S --sysupgrade
- rpm -U
- rpm --upgrade
- apk upgrade
- dnf upgrade
Source: https://docs.docker.com/develop/develop-images/dockerfile_best-practices
dockerfile_pin_versions_package_install 3 One desirable goal of docker images is that changing their Docker-files and re-building them in the future does not cause issues unrelated to the new changes. One way an image may not build in the future is if the Dockerfile contains instructions to install a certain program/library without pinning the version.
Remediation: Ensure that inside a Dockerfile, you pin the versions of any installed packages using apt, yum, apk, pacman, dnf, zypper, npm or pip.
Source: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#apt-get
dockerfile_create_volume_for_var_log 3 In linux systems, important operating system logs are stored in the /var/log subfolder. This folder should always be made available to the host through a volume, so that log tracking and log analysis systems can capture them.
Remediation: In every Dockerfile, there should be a VOLUME directive which has /var/log as an argument.
Source: https://docs.docker.com/engine/reference/builder/
nginx_server_tokens_off 2 Knowing what NGINX version you are running may make you vulnerable if there is a known vulnerability for a specific version. There is a parameter to turn the display of the version on the error pages off. Our checking mechanism looks into each http-directive and ensures it is disabled on the top level.
Remediation: Set server_tokens to off on the http-level of the configuration.
Source: https://nginx.org/en/docs/http/ngx_http_core_module.html#server_tokens
nginx_disable_content_sniffing 2 There is an HTTP response header that makes it harder to perform content sniffing, which is considered a security vulnerability. NGINX can automatically set this header for every response by setting add_header X-Content-Type-Options to nosniff in nginx.conf.
Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
dockerfile_shell_commands_invalid_for_image_creation 2 A Dockerfile is a set of commands to create an image. This image creation can appear on any host, and is not reflective of the host the container is run on at the end. Hence, certain shell commands do not make sense in a Dockerfile context.
Remediation: For any RUN command, ensure that the following unix shell commands do not appear in its argument: - ssh
- vim
- emacs
- nano
- shutdown
- service
- systemctl
- ps
- free
- top
- kill
- mount .
dockerfile_shell_check_on_run_commands 2 Run commands in the Dockerfile are, generally speaking, shell scripts. It is best practice to lint them and do a shell-check on them for common, shell-script related errors, which can be quite subtle.
Remediation: Ensure that all RUN command lines would pass a run through the shellcheck database of common shell scripting errors.
Source: https://www.shellcheck.net/wiki/
dockerfile_copy_command_more_than_two_arguments_slash 2 The COPY directive allows the copying of one or more files on the host machine into the image that is being built. If there is more than one file copied, it is apparent that the destination is a folder, and hence has to end with /.
Remediation: Ensure that every COPY instruction with more than two arguments has the last argument ending with /
Source: https://docs.docker.com/engine/reference/builder/#copy
dockerfile_only_one_cmd_instruction 2 The CMD directive specifies the final command that is executed when running the container. This should be unique.
Remediation: Ensure that there is at most one CMD directive in the Dockerfile.
dockerfile_only_one_entrypoint_instruction 2 The ENTRYPOINT directive specifies the final command that is executed when running the container. This should be unique.
Remediation: Ensure that there is at most one ENTRYPOINT directive in the Dockerfile.
dockerfile_container_healthcheck_parameter 2 Dockerfiles have an instruction called HEALTHCHECK. It enables a user to define a command to figure out if the program(s) running inside the container are working properly. It is generally advisable to have healthchecks in place to assist monitoring of running containers.
Remediation: Have at least one HEALTHCHECK instruction in your Dockerfile.
Source: https://docs.docker.com/engine/reference/builder/#healthcheck
nginx_underscores_in_headers_allowed 1 The HTTP standard allows underscores in headers, but NGINX might silently dismiss them. The setting underscores_in_headers on will turn them on for you.
Remark: Since the underscores_in_headers_directive is allowed also in server-blocks, but only in very specific ones, we will only pass it if we find it in http-directives.
Source: https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/
dockerfile_copy_destination_absolute_path_or_var 1 The COPY command should define its destination using an absolute path.
Remediation: Ensure that every COPY instruction has as last argument a string starting with '/' or starting with an environment variable/argument.
Source: https://docs.docker.com/develop/develop-images/dockerfile_best-practices
dockerfile_env_and_arg_defined_and_right_away_used 1 When creating Docker images that use environment variables or build arguments, it is advisable to position the ARG or ENV directives close to their actual uses, since otherwise the caching for building the images is not greatly used.
Remediation: Every variable defined by an ENV or ARG directive should be used within the next five commands inside the Dockerfile.
dockerfile_do_not_use_add 1 Dockerfiles have two directives that allow you to add files from the machine where you build the image into the image, namely COPY and ADD. Both are technically similar, but ADD also has side-effects like automated decompression of archives. It is generally recommended to only use COPY
Remediation: Remove any ADD directive in your dockerfile and replace it with COPY.
Source: https://docs.docker.com/engine/reference/builder/#copy

Scan performed at 2022-12-12 15:23:07 using the CoGuard CLI