Checks

You should use 'yum clean all' after using a 'yum install' command to clean package cached data and reduce image size.

There can only be one CMD instruction in a Dockerfile. If you list more than one CMD then only the last CMD will take effect.

The instruction 'RUN <package-manager> update' should always be followed by '<package-manager> install' in the same RUN statement.

Cached package data should be cleaned after installation to reduce image size.

The layer and image size should be reduced by deleting unneeded caches after running zypper.

'apt-get' calls should use the flag '-y' to avoid manual user input.

MAINTAINER has been deprecated since Docker 1.13.0.

Providing more than one HEALTHCHECK instruction per stage is confusing and error-prone.

You should use 'apk add' with '--no-cache' to clean package cached data and reduce image size.

You should add HEALTHCHECK instruction in your docker container images to perform the health check on running containers.

Cached package data should be cleaned after installation to reduce image size.

'apt-get' install should use '--no-install-recommends' to minimize image size.

WORKDIR should not be mounted on system directories to avoid container breakouts

Passing secrets via build-args or envs or copying secret files can leak them out

Using 'allUsers' or 'allAuthenticatedUsers' as members in an IAM member/binding causes data to be exposed outside of the organisation.

When you enable uniform bucket-level access on a bucket, Access Control Lists (ACLs) are disabled, and only bucket-level Identity and Access Management (IAM) permissions grant access to that bucket and the objects it contains. You revoke all access granted by object ACLs and the ability to administrate permissions using bucket ACLs.

Permissions should not be directly granted to users, you identify roles that contain the appropriate permissions, and then grant those roles to the user.

Granting permissions to users quickly become unwieldy and complex to make large scale changes to remove access to a particular resource.

Permissions should be granted on roles, groups, services accounts instead.

Default service accounts should not be used - consider creating specialised service accounts for individual purposes.

Users with service account access at folder level can impersonate any service account. Instead, they should be given access to particular service accounts as required.

Default service accounts should not be used - consider creating specialised service accounts for individual purposes.

Service accounts should have a minimal set of permissions assigned in order to do their job. They should never have excessive access as if compromised, an attacker can escalate privileges and take over the entire account.

Default service accounts should not be used - consider creating specialised service accounts for individual purposes.

Users with service account access at organization level can impersonate any service account. Instead, they should be given access to particular service accounts as required.

The default network which is provided for a project contains multiple insecure firewall rules which allow ingress to the project's infrastructure. Creation of this network should therefore be disabled.