Checks

OCI IAM policies are reviewed to ensure storage service-level administrator statements that grant manage permissions exclude the relevant storage delete permissions with request.permission. This supports CIS OCI 3.1 control 1.15 separation of duties for Block Volume, File Storage, and Object Storage administrators.

OCI IAM policies are analyzed for statements granting manage all-resources in tenancy to groups. Only the Tenant Admin Policy for the Administrators group should include this broad verb. Any other active policy containing this tenancy-wide permission is identified.

OCI tenancy administrator accounts (members of the Administrators group) are inspected for configured user API keys tied to those identities.

OCI IAM users with active API signing keys older than 90 days are identified. Key age is derived from each key's creation time; only active keys are considered. Users without API keys are recorded.

OCI IAM user auth tokens are evaluated for rotation age against a 90-day threshold using each token's creation time. Tokens older than this window indicate the token has not been recently rotated.

OCI IAM customer secret keys are assessed by creation timestamp to determine whether their age exceeds 90 days.

OCI IAM user database passwords are evaluated for age. Passwords are compared to a rotation window of 90 days, flagging credentials that have not been refreshed within that period for the associated user accounts and regions.

Covers each user's active database passwords tracked by IAM.

OCI IAM users with console password access are expected to have multifactor authentication enabled. The evaluation inspects each local user allowed to sign in to the Console and identifies those without an active second factor.

OCI IAM user accounts are evaluated for a populated email attribute that resembles an address (contains @). Accounts missing this attribute or with malformed values are identified.

Every Okta Smart Card (X509) Identity Provider must be ACTIVE and its certificate chain must be issued by a DOD-approved CA. The check ships default issuer-DN patterns covering DOD PKI and ECA, and matches them against the chain's issuer. Override or extend via okta_dod_approved_ca_issuer_patterns in the audit config to recognise tenant-specific DOD CAs.

When using a 'FROM' statement you should use a specific tag to avoid uncontrolled behavior when the image is updated.

Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.

Exposing port 22 might allow users to SSH into the container.

You should use COPY instead of ADD unless you want to extract a tar file. Note that an ADD command will extract a tar file, which adds the risk of Zip-based vulnerabilities. Accordingly, it is advised to use a COPY command, which does not extract tar files.

COPY '--from' should not mention the current FROM alias, since it is impossible to copy from itself.

There can only be one ENTRYPOINT instruction in a Dockerfile. Only the last ENTRYPOINT instruction in the Dockerfile will have an effect.

UNIX ports outside the range 0-65535 are exposed.

For clarity and reliability, you should always use absolute paths for your WORKDIR.

Avoid using 'RUN' with 'sudo' commands, as it can lead to unpredictable behavior.

When a COPY command has more than two arguments, the last one should end with a slash.

Different FROMs can't have the same alias defined.

Use WORKDIR instead of proliferating instructions like 'RUN cd … && do-something', which are hard to read, troubleshoot, and maintain.

Avoid using both 'wget' and 'curl' since these tools have the same effect.

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