openclarity / kubeclarity

KubeClarity is a tool for detection and management of Software Bill Of Materials (SBOM) and vulnerabilities of container images and filesystems
Apache License 2.0
1.3k stars 157 forks source link

Scanning Limitation with private registries #618

Open jseiser opened 5 months ago

jseiser commented 5 months ago

Is your feature request related to a problem? Please describe.

We are trying to run kubeclarity in a very locked down network environment. All of our image pulls except ones coming from AWS Private registries are force to run through a harbor image proxy, that requires authentication. This image rewrite, and the attaching of the imagePullSecret is done automatically by kyverno for all namespaces except kube-system and kyverno. This means whether I run the scan in the kubeclarity namespace, a custom namespace or let the scan happen in the namespace of the pod it wants to scan, there ends up being situations where kubeclarity does not use the required imagepullsecret

Describe the solution you'd like It would be preferable to tell kubeclarity to scan in either kubeclarity namespace, or a custom namespace, and to require all images to use an imagepullsecret that would already exist in that namespace

Describe alternatives you've considered We currently do not scan images in kube-system, or in kyverno's namespaces.

Additional context This is an EKS environment, in a special part of AWS Govcloud, with no outbound internet access except for AWS endpoints, and a few whitelisted proxies like harbor.

uselessidbr commented 5 months ago

Well, here is a workaround. Definetly not the most elegant way but it does the trick.

Just get a docker config, like this:

{
        "auths": {
                "default-route-openshift-image-registry.apps.xyz.com": {
                        "auth": "ZZZzZZZZZZZZzzzzZZzzzzzzzzzzzzZZZZZZZZZZZZZZZZZZzzzzzzzzzzzzzzzzzzzz"
                },
                "docker-registry-default.xyz.com": {
                        "auth": "ZZZzZZZZZZZZzzzzZZzzzzzzzzzzzzZZZZZZZZZZZZZZZZZZzzzzzzzzzzzzzzzzzzzzZZZzZZZZZZZZzzzzZZzzzzzzzzzzzzZZZZZZZZZZZZZZZZZZzzzzzzzzzzzzzzzzzzzz" 

                },
                "https://index.docker.io/v1/": {
                        "auth": "ZZZzZZZZZZZZzzzzZZzzzzzzzzzzzzZZZZZZZZZZZZZZZZZZzzzzzzzzzzzzzzzzzzzz"
                }
        },
        "HttpHeaders": {
                "User-Agent": "Docker-Client/19.03.5 (linux)"
        }
}

And encode it with base64:

cat docker_cfg.txt | base64 -w0 ewoJImF1dGhzIjogewoJCSJkZWZhdWx0LXJvdXRlLW9wZW5zaGlmdC1pbWFnZS1yZWdpc3RyeS5hcHBzLnh5ei5jb20iOiB7CgkJCSJhdXRoIjogIlpaWnpaWlpaWlpaWnp6enpaWnp6enp6enp6enp6elpaWlpaWlpaWlpaWlpaWlpaWnp6enp6enp6enp6enp6enp6enp6IgoJCX0sCgkJImRvY2tlci1yZWdpc3RyeS1kZWZhdWx0Lnh5ei5jb20iOiB7CgkJCSJhdXRoIjogIlpaWnpaWlpaWlpaWnp6enpaWnp6enp6enp6enp6elpaWlpaWlpaWlpaWlpaWlpaWnp6enp6enp6enp6enp6enp6enp6WlpaelpaWlpaWlpaenp6elpaenp6enp6enp6enp6WlpaWlpaWlpaWlpaWlpaWlpaenp6enp6enp6enp6enp6enp6enoiIAoKCQl9LAoJCSJodHRwczovL2luZGV4LmRvY2tlci5pby92MS8iOiB7CgkJCSJhdXRoIjogIlpaWnpaWlpaWlpaWnp6enpaWnp6enp6enp6enp6elpaWlpaWlpaWlpaWlpaWlpaWnp6enp6enp6enp6enp6enp6enp6IgoJCX0KCX0sCgkiSHR0cEhlYWRlcnMiOiB7CgkJIlVzZXItQWdlbnQiOiAiRG9ja2VyLUNsaWVudC8xOS4wMy41IChsaW51eCkiCgl9Cn0K

After this, include this in the ConfigMap “kubeclarity-kubeclarity-scanner-template” within “containers: - name: vulnerability-scanner”:

` lifecycle: postStart: exec: command:

It should look like this:

` containers:

github-actions[bot] commented 3 months ago

Thank you for your contribution! This issue has been automatically marked as stale because it has no recent activity in the last 60 days. It will be closed in 14 days, if no further activity occurs. If this issue is still relevant, please leave a comment to let us know, and the stale label will be automatically removed.