aquasecurity / appshield Goto Github PK

Hi,

I see https://github.com/aquasecurity/appshield/pull/54/files was merged that updated the metadata for Kubernetes policies.

But the docker policies are still using the old convention: https://github.com/aquasecurity/appshield/blob/master/docker/policies/apt_cache.rego#L1-L6

Aqua's Vulnerability DB uses these policies and generates knowledge base pages out of them. I'm currently updating it to be able to use the new rego convention for metadata that the aforementioned PR incorporates.

Could the docker policies be updated as well so we don't have two styles of metadocs for rego policies?

The directory structure should be:

/
/kubernetes
/docker
readme.md

Kubernetes Sub Directory:
/kubernetes/readme.md
/kubernetes/policies
/kubernetes/policies/pss
/kubernetes/policies/general
/kubernetes/lib
/kubernetes/test

Readme will explain how to run the policy checks and what are the PSS vs. General policies.

Docker Sub Directory:
/docker/readme.md
/docker/policies
/docker/lib
/docker/test

NSA spec : account tokens in pods can be gleaned by cyber actors and used to further compromise the cluster. When an application does not need to access the service account directly, Kubernetes administrators should ensure that Pod specifications disable the secret token being mounted. This can be accomplished using the “automountServiceAccountToken: false” directive in the Pod’s YAML specification.

fixed : #137

All the following scripts are configured to work on deployments and not on pods.

1. Host PID
2. Host IPC
3. Host Aliases
4. Host Network

@ttousai @jerbia FYI

Kubernetes current default is to not set a seccomp profile on containers. At the moment KSV030 appears to only trigger when a seccomp policy or annotation is set which is not RuntimeDefault and does not trigger if there is no mention of seccomp in the manifest.

;to address this case: aquasecurity/trivy#1187

the following regos should be fixed:
https://github.com/aquasecurity/appshield/blob/d7275ab4c26d387c7df7cf90981185abfdf2b148/kubernetes/policies/general/runs_with_UID_le_10000.rego

https://github.com/aquasecurity/appshield/blob/d7275ab4c26d387c7df7cf90981185abfdf2b148/kubernetes/policies/general/runs_with_GID_le_10000.rego

Description

The validation for https://avd.aquasec.com/appshield/ds018/ is invalid, since having a reference to external image is valid and supported, see https://docs.docker.com/develop/develop-images/multistage-build/#use-an-external-image-as-a-stage

Trivy could check if the COPY --from= argument refers to an existing image and skip this check,
OR it could decrease the severity from HIGH to MEDIUM (or even lower),
OR it could just stop checking for this, if it's not possible to differentiate between references to regular images and build stages.

Buildah also supports references to external images "as stages" via this syntax.

What did you expect to happen?

I don't expect this Dockerfile to raise DS018:

FROM ubuntu:20.04
ENV JAVA_HOME=/opt/java/openjdk
COPY --from=eclipse-temurin:17-jdk-focal $JAVA_HOME $JAVA_HOME

but it does.

What happened instead?

Got the error DS018.

Output of run with -debug:

Dockerfile (dockerfile)
=======================
Tests: 17 (SUCCESSES: 15, FAILURES: 2, EXCEPTIONS: 0)
Failures: 2 (HIGH: 2, CRITICAL: 0)
+---------------------------+------------+------------------------------------------+----------+------------------------------------------+
|           TYPE            | MISCONF ID |                  CHECK                   | SEVERITY |                 MESSAGE                  |
+---------------------------+------------+------------------------------------------+----------+------------------------------------------+
| Dockerfile Security Check |   DS002    | root user                                |   HIGH   | Last USER command in                     |
|                           |            |                                          |          | Dockerfile should not be 'root'          |
|                           |            |                                          |          | -->avd.aquasec.com/appshield/ds002       |
+                           +------------+------------------------------------------+          +------------------------------------------+
|                           |   DS018    | 'COPY --from' refers to alias not        |          | The alias                                |
|                           |            | defined previously                       |          | '--from=eclipse-temurin:17-jdk-focal'    |
|                           |            |                                          |          | is not defined in the previous stages    |
|                           |            |                                          |          | -->avd.aquasec.com/appshield/ds018       |
+---------------------------+------------+------------------------------------------+----------+------------------------------------------+

Output of trivy -v:

Version: 0.22.0

Additional details (base image name, container registry info...):

The output is from trivy docker image docker.io/aquasec/trivy:latest (sha256:c6f6e688)

The Docker policy update_instruction_alone complains for a trivial example such as this, which is using industry standard approaches and is not an anti-pattern:

FROM alpine:latest
RUN apk update && apk upgrade

Refer to: kubernetes/kubernetes#97076

This issue affects multitenant clusters. If a potential attacker can already create or edit services and pods, then they may be able to intercept traffic from other pods (or nodes) in the cluster.

An attacker that is able to create a ClusterIP service and set the spec.externalIPs field can intercept traffic to that IP. An attacker that is able to patch the status (which is considered a privileged operation and should not typically be granted to users) of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.
This issue is a design flaw that cannot be mitigated without user-facing changes.

There is a bespoke webhook the SIG created for stopping this: https://github.com/kubernetes-sigs/externalip-webhook

As a bonus, this is likely a very high confidence item to block:

ExternalIP services are not widely used, so we recommend manually auditing any external IP usage. Users should not patch service status, so audit events for patch service status requests authenticated to a user may be suspicious.

The cronjob could be set with concurrencyPolicy: Allow, so when the job fails, the next job doesn't replace the previous job. This could cause resource starvation in the cluster.

It will be nice to have a warning about this, verify concurrencyPolicy is always set to either “Forbid” or “Replace”.

Kubernetes doc: https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/

@itaysk @jerbia

We have 5 PRs pending. The idea with the PRs was to provide a platform for us to investigate and discuss architectural/implementation approaches and a framework for further development. I think they have done that.

The PRs have collected reviews about some of the changes we will want to see. I suggest the current implementation be considered as Phase 1 and all the PRs be merged to prepare for what I suggest we call Phase 2.

This is tentative list of tasks for Phase 2 and owners.

1. Merge Phase 1 PRs to master, so it's easier to add Phase 2 changes (owner @itaysk @jerbia)
2. Add information about controller name and namespace to deny message (owner: @ttousai)
3. Add container name to deny message for container based policies. (owner: @ttousai).
4. Standardize unit testing use of PASS and FAIL.
5. Add remaining policy documents and tests (@ttousai).

Trivy incorrectly detects that I'm using a ":latest" tag. Reproducible with a trivial file such as this:

FROM node:14.18.1-bullseye AS dependencies

FROM dependencies AS build

NSA spec : Kubernetes namespaces are one way to partition cluster resources among multiple individuals, teams, or applications within the same cluster. By default, namespaces are not automatically isolated. However, namespaces do assign a label to a scope, which can be used to specify authorization rules via RBAC and networking policies.
Namespace kube-system should be used by core components only (kube-apiserver, etcd, kube-controller-manager and kube-scheduler)
fixed: #141

At the moment the seccomp policy uses the annotation based format to check whether a seccomp policy has been specified.

As of Kubernetes 1.19, seccomp graduated to GA and the seccomp setting migrated to securityContext (docs here).

Probably a good idea to check in both locations for the seccomp policy being specified, to avoid incorrectly flagging manifests as missing this setting.

I have multiple multi-stage Dockerfiles, where I use root user in the first stages and then I switch to non-privileged user only in the final stage (i.e. where it matters, since all the previous stages are discarded/ omitted from the final image).

FROM eclipse-temurin:17-jdk-focal AS parent

FROM ubuntu:focal AS build
USER root

ENV JAVA_HOME=/opt/java/openjdk
COPY --from=parent $JAVA_HOME $JAVA_HOME
ENV PATH="${JAVA_HOME}/bin:${PATH}"

RUN apt install ...
RUN run build
RUN [start postgres (requires root), run integration tests, stop postgres, cleanup...]

FROM eclipse-temurin:17-jdk-focal
RUN useradd -m -d /opt -s /bin/bash -g root myuser
RUN chown -R myuser /opt
USER myuser
COPY --from=build ....
CMD ["java", ...]

Trivy complains:

trivy --cache-dir .trivycache/ fs --exit-code 1 --no-progress --severity HIGH,CRITICAL --security-checks=vuln,config .
Dockerfile (dockerfile)
=======================
Tests: 17 (SUCCESSES: 16, FAILURES: 1, EXCEPTIONS: 0)
Failures: 1 (HIGH: 1, CRITICAL: 0)
+---------------------------+------------+-----------+----------+------------------------------------------+
|           TYPE            | MISCONF ID |   CHECK   | SEVERITY |                 MESSAGE                  |
+---------------------------+------------+-----------+----------+------------------------------------------+
| Dockerfile Security Check |   DS002    | root user |   HIGH   | Last USER command in                     |
|                           |            |           |          | Dockerfile should not be 'root'          |
|                           |            |           |          | -->avd.aquasec.com/appshield/ds002       |
+---------------------------+------------+-----------+----------+------------------------------------------+

The same situation (although with different message) repeats if I remove the USER root, so it's not a problem with that.
It seems to me that Trivy doesn't like the fact that I don't have USER xyz in the first stage, where I don't really need/want that.

The same situation also happens in one of my other Dockerfiles, where I have 3 stages. Does this mean I should have USER xyz in all stages? I don't really want to...

Is this a bug or is this an expected behavior?

like Dockerfile

• ensure that network policies selectors are applied to pods or namespaces to restricted ingress and egress traffic within the pod network.
  Fixed #149

Add Rego checks for Dockerfile.
See description here: https://github.com/aquasecurity/appshield/tree/master/policies/docker

If I have a kubernetes container that specifies an image with a digest value, the KSV013 rule will incorrectly fail.

For example:
some-image:1.0.0@sha256:askj78jhkf278hdjkf78623gbkljmkvmk8kjn98237487hkjaf897bkjsehf783f

Will result in (trivy output):

|                           |   KSV013   | Image tag ':latest' used               |   LOW    | Container 'some-service' of                |
|                           |            |                                        |          | Deployment 'some-service'                  |
|                           |            |                                        |          | should specify an image tag                |
|                           |            |                                        |          | -->avd.aquasec.com/appshield/ksv013        |

I have a problem with DS005 rule where the source is a URL and not a file.

Trivy suggest changing ADD to COPY but COPY doesn't support URL as source.

Would it be possible to modify the rule to ignore this suggestion if the source is a URL?

Rule suggestion:

Consider using
'COPY https://.../co/elastic/apm/elastic-apm-agent/${ELASTIC_APM_AGENT_VERSION}/elastic-apm-agent-${ELASTIC_APM_AGENT_VERSION}.jar elastic-apm-agent.jar'
command instead of
'ADD https://.../co/elastic/apm/elastic-apm-agent/${ELASTIC_APM_AGENT_VERSION}/elastic-apm-agent-${ELASTIC_APM_AGENT_VERSION}.jar elastic-apm-agent.jar'
-->avd.aquasec.com/appshield/ds005

Docker error:
COPY failed: source can't be a URL for COPY