The cos-auditd daemonset deploys 2 images.
The cos-auditd-fluent-bit image comes from gke.gcr.io, which is internal to GCP.
spec:
template:
spec:
containers:
- name: cos-auditd-fluent-bit
image: gke.gcr.io/fluent-bit@sha256:436f3b7a38522314dd3db22ae8187192d928763c29e94d04c0900b34f0ca0779 # v1.8.12-gke.16
However, the cos-auditd-setup init container pulls its ubuntu image from docker.io
spec:
template:
spec:
initContainers:
- name: cos-auditd-setup
image: ubuntu
Inside a VPC Service Perimeter that routes traffic through a PSC, docker.io pulls fail with an x509 error:
Failed to pull image "ubuntu": rpc error: code = Unknown desc = failed to pull and unpack image "docker.io/library/ubuntu/latest": failed to resolve reference "docker.io/library/ubuntu:latest": failed to do request: Head "https://registry-1.docker.io/v2/library/ubuntu/manifests/latest": x509: certificate signed by unknown authority
Additionally, I believe if the cluster could successfully reach docker.io, that the pull would still fail to due binary authorization attestation policies.
If possible, can the init container's image be hosted on a repository that is included in GCP's default binary authorization whitelist (preferably gke.gcr.io)? This would resolve both issues.
admissionWhitelistPatterns:
- namePattern: gcr.io/google_containers/*
- namePattern: gcr.io/google-containers/*
- namePattern: k8s.gcr.io/**
- namePattern: gke.gcr.io/**
- namePattern: gcr.io/stackdriver-agents/*
The cos-auditd daemonset deploys 2 images.
The cos-auditd-fluent-bit image comes from
gke.gcr.io, which is internal to GCP.However, the cos-auditd-setup init container pulls its ubuntu image from
docker.ioInside a VPC Service Perimeter that routes traffic through a PSC,
docker.iopulls fail with an x509 error:Additionally, I believe if the cluster could successfully reach
docker.io, that the pull would still fail to due binary authorization attestation policies.If possible, can the init container's image be hosted on a repository that is included in GCP's default binary authorization whitelist (preferably
gke.gcr.io)? This would resolve both issues.