Giter Club home page Giter Club logo

kubernetes-monitor's Introduction

Known Vulnerabilities

snyk/kubernetes-monitor

Summary

A containerized application that is deployed with Helm. Monitors the security of a Kubernetes cluster by analyzing container images.

Prerequisites

  • 50 GiB of storage in the form of emptyDir or a PersistentVolumeClaim.
  • External internet access from the Kubernetes cluster to api.snyk.io.
  • 1 CPU, 2 GiB RAM
  • 1 Kubernetes worker node of type linux/amd64 - supported and tested only on the AMD64 CPU architecture

Supported Kubernetes distributions:

  • Any Generally Available Kubernetes Certified distribution, for example: GKE, AKS, EKS, OCP.

Tested with the following Security Context Constraint on OCP.

Installation with Helm

Please refer to the Helm chart installation instructions.

Documentation

For detailed documentation and support, please refer to the Snyk Kubernetes integration documentation.

kubernetes-monitor's People

Contributors

agatakrajewska avatar agouil avatar agranado2k avatar ahmed-agabani-snyk avatar armand-snyk avatar chen-keinan avatar christinadara avatar dkontorovskyy avatar fauxfaux avatar iuliams avatar ivanstanev avatar jmickey avatar jonnyowenpowell avatar karniwl avatar kat1906 avatar michael-c-snyk avatar mihaibuzgau avatar minsiyang avatar pecodez avatar popas90 avatar rotems avatar shaimendel avatar shesekino avatar snaftaly avatar snyk-bot avatar snyk-deployer avatar srlk avatar talik077 avatar tommyknows avatar wayne-grant avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

kubernetes-monitor's Issues

[๐Ÿ›] Gcloud config dir is not writable

  • kubernetes-monitor version 1.92.2
  • Cloud runtime GKE

Expected behaviour

Gcloud docker auth helper works

Actual behaviour

gcloud is unable to create temp tokens because /srv/app/.config/gcloud is not writable

Steps to reproduce

Deploy monitor with helm using gcloud cred helpers

          {
            "credHelpers": {
              "gcr.io": "gcloud",
              "us.gcr.io": "gcloud",
              "eu.gcr.io": "gcloud",
              "asia.gcr.io": "gcloud",
              "staging-k8s.gcr.io": "gcloud",
              "marketplace.gcr.io": "gcloud"
            }
          }

helm upgrade failed with pvc.enabled but without pvc.storageClassName

We faced with error:
Error: UPGRADE FAILED: cannot patch "snyk-monitor-pvc" with kind PersistentVolumeClaim: PersistentVolumeClaim "snyk-monitor-pvc" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

with adding pvc.enabled but without setting pvc.storageClassName.

On first execution it takes default class, but on second upgrade it cannot change, because of null in storage class variable.

It can be fixed as described here: helm/charts#20389 (comment)

I'll submit MR in near future

synk-monitor version in Charts.yaml does not update with version in upstream repo

When new chart versions are published, they do not match the version in the upstream repo.

e.g. right now the Chart.yaml reflects version 0.1.0 but the upstream is `1.22.01

Small nit on my part here, but sometimes I like to go spelunking into the code (looking at values.yaml etc) and look at the chart version to know what to start playing with. As it stands right now, to understand what a specific chart version would have included in it, you would need to helm fetch the repo locally to do this inspection.

Specify the numeric UID for securityContext/runAsUser in the helm chart[๐Ÿ™]

Describe the user need
In order to pass our gateway admission rules that prevent containers from running as root, we need to specify a numeric UID in the container's securityContext. I see that the container is running as the snyk user (uid 10001), but it isn't specified in the securityContext.

Describe expected behaviour
That the uid the container runs as is listed in the securityContext.

[๐Ÿ™] Add optional secret to set dockercfg.json and integrationId

Describe the user need

In order to avoid having to manually create a snyk-monitor secret with dockercfg.json and integrationId item it would be useful to have an optional secret for this in the Helm chart. Right now we have to create a secondary internal Helm chart to create this secret in an automated fashion.

Describe expected behaviour

The values could look something like the following:

secret:
  enable: false
  dockercfg: {}
  integrationID: ""

It would be nice if the values for dockercfg and dockercfg are readable and get base64 encoded by the secret template.

[๐Ÿ™] Allow setting ephemeral-storage requests/limits in the resources block

Describe the user need
After deploying, I ran into an issue when snyk-monitor was scheduled to a node that did not have sufficient ephemeral-storage available. When I edited the deployment with an ephemeral-storage request (as described here: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#setting-requests-and-limits-for-local-ephemeral-storage), the pod scheduled without any issues. I would like to be able to set that request via the helm chart, but cannot as it is currently configured.

Describe expected behaviour

I expected that the template would assign whatever was in the resources block in the values.yaml to the deployment's resources, but it is explicitly mapping memory and cpu. An example of what I mean would look like this:

resources: {{- toYaml .Values.resources | nindent 12 }}
{{- end }}

This would allow an arbitrary set of values to be assigned, including the ephemeral-storage requests and limits.

The automated release is failing ๐Ÿšจ

๐Ÿšจ The automated release from the staging branch failed. ๐Ÿšจ

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. Iโ€™m sure you can fix this ๐Ÿ’ช.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the staging branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

If those donโ€™t help, or if this issue is reporting something you think isnโ€™t right, you can always ask the humans behind semantic-release.


Cannot push to the Git repository.

semantic-release cannot push the version tag to the branch staging on the remote Git repository with URL https://[secure]@github.com/snyk/kubernetes-monitor.git.

This can be caused by:


Good luck with your project โœจ

Your semantic-release bot ๐Ÿ“ฆ๐Ÿš€

[๐Ÿ™] Add support for extra volumes and volumemounts in `snyk-monitor` helm chart

Describe the user need

I would love to see the snyk-monitor helm chart extended with the possibility to add custom volumes and volume mounts. From other helm charts I'm used to see extraVolumes: [] and extraVolumeMounts: [] in the values.yaml.

Describe expected behaviour

I would like the possibility to specify something like this in our values.yaml (like in the official filebeat chart):

extraVolumes:
  - name: extras
    emptyDir: {}
extraVolumeMounts:
  - name: extras
    mountPath: /usr/share/extras
    readOnly: true

Or something more advanced (which would be our use case):

  extraVolumes:
    - csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "my-key-vault-from-azure" # created elsewhere
      name: "my-kv-volume"
  extraVolumeMounts:
    - mountPath: "/mnt/my-kv-volume"
      name: "my-kv-volume"
      readOnly: true

Additional context

Background: We are migrating our Azure Kubernetes clusters to using Azure Key Vault Provider for Secrets Store CSI Driver. This allows us to have secrets from our Azure key vaults mounted into pods as either Kubernetes volumeMount (files) or Kubernetes secret. In order to have the Kubernetes secrets automatically created from a Key Vault secret (by the provider) it is a requirement by the provider that the csi volume is mounted in at least one container. I'm not currently able to achieve this with the current snyk-monitor helm chart.

Our deployment and upgrade processes are fully automated through the use of ArgoCD and running manual steps (ex. manual fiddling with kubectl) as part of the process is not an option.

Implementation

Implementation should be a breeze and I'll be happy to provide a pull request;

Above snyk-monitor/templates/deployment.yaml#L100 add:

          {{- if .Values.extraVolumeMounts }}
          {{- toYaml .Values.extraVolumeMounts  | nindent 10 }}
          {{- end }}

and above snyk-monitor/templates/deployment.yaml#L227 add:

{{- if .Values.extraVolumes }}
{{- toYaml .Values.extraVolumes  | nindent 8 }}
{{- end }}

[๐Ÿ™] Support for ACR authentication via Azure Workload Identity

The recommended authentication mechanism for access to Azure resources for workloads within AKS is now Azure Workload Identity.
The Azure JS SDK doesn't support this authentication flow yet. However, it would already be possible via the az cli binary:

 az login --service-principal -u $AZURE_CLIENT_ID -t $AZURE_TENANT_ID --federated-token $(cat $AZURE_FEDERATED_TOKEN_FILE)

 az acr login --name my-registry.azurecr.io --expose-token 

The token could then be passed to Skopeo.

Would you accept a PR that adds support for Azure Workload Identity via the az cli?

[๐Ÿ™] Add metadata annotations to helm chart

Describe the user need
We use kube2iam which requires annotation on pods to be able to get the assumed role to read ECR for images. Adding a template value to allow this to be set would be immensely helpful.

Describe expected behaviour
I'd like to be able to just set whatever metadata annotations on the deployment spec and it to be passed through in helm

Publish App version for snyk-monitor Helm chart [๐Ÿ™]

Describe the user need
At the moment the helm chart provides information on chart version only which is difficult to map to corresponding app version.

$ helm search repo snyk-charts/snyk-monitor --versions
NAME                            CHART VERSION   APP VERSION     DESCRIPTION                      
snyk-charts/snyk-monitor        2.4.19                          A Helm chart for the Snyk Monitor
snyk-charts/snyk-monitor        2.4.18                          A Helm chart for the Snyk Monitor
snyk-charts/snyk-monitor        2.4.17                          A Helm chart for the Snyk Monitor
snyk-charts/snyk-monitor        2.4.16                          A Helm chart for the Snyk Monitor
...

Describe expected behaviour
Please could the the app version also included into Helm chart ?

Additional context
This is to follow Helm best practices and make it more transparent for end users the version of app to be installed.

[๐Ÿ›] deprecation warnings seen in fresh snyk-monitor chart install in k8s 1.26

  • snyk-charts/snyk-monitor version 2.4.5
  • Cloud runtime: AKS

Expected behaviour

When following published installation steps there are no warnings using modern kubernetes versions
https://docs.snyk.io/scan-containers/kubernetes-integration/snyk-controller-installation/install-the-snyk-controller-with-helm

Actual behaviour

Deprecation messages are seen.

 helm upgrade --install snyk-monitor snyk-charts/snyk-monitor --namespace snyk-monitor --set clusterName="sandbox cluster"
Release "snyk-monitor" does not exist. Installing it now.
W0724 17:22:25.892385   75713 warnings.go:70] spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[2].key: beta.kubernetes.io/arch is deprecated since v1.14; use "kubernetes.io/arch" instead
W0724 17:22:25.892446   75713 warnings.go:70] spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[3].key: beta.kubernetes.io/os is deprecated since v1.14; use "kubernetes.io/os" instead
NAME: snyk-monitor
LAST DEPLOYED: Mon Jul 24 17:22:23 2023
NAMESPACE: snyk-monitor
STATUS: deployed
REVISION: 1
TEST SUITE: None

Steps to reproduce

Follow instructions on this page with k8s of 1.24 or greater:
https://docs.snyk.io/scan-containers/kubernetes-integration/snyk-controller-installation/install-the-snyk-controller-with-helm

Recommended solution

Set this value to have a default of true. The values from this have been deprecated for a long time now.

nodeAffinity:
  disableBetaArchNodeSelector: false

https://github.com/snyk/kubernetes-monitor/blob/staging/snyk-monitor/values.yaml#L112

[๐Ÿ›] snyk-monitor Chart: Specify custom Configmap with rego policy for import/export

  • kubernetes-monitor version: v1.64.1
  • Cloud runtime: custom kops based

Expected behaviour

The helm chart workloadPoliciesMap value will allow to specify a configmap including custom rego policies under the workload-events.rego key. Changing that value in values.yaml must not have any effect in the included default policy.

Actual behaviour

Here's a couple of options I have in mind:

  1. (preferred) Use workloadPoliciesMap in values.yaml to point to a pre-created custom ConfigMap and mount that in the deployment. The ConfigMap in the Chart containing the default policy, should have a fixed name, not configurable (but documented, of course).
  2. Add a new option in values.yaml to point to the external ConfigMap and adjust the Deployment accordingly.

Steps to reproduce

Set workloadPoliciesMap to a name of an existing ConfigMap having the custom policies. The helm release will fail as a ConfigMap with the same name is already part of the helm release.

Ensure that snyk/kubernetes-monitor ships without major vulnerabilities [๐Ÿ™]

Describe the user need
Using kubernetes-monitor in our setup introduces vulnerabilities in the kubernetes clusters which we cannot remediate or know if affects the health of the cluster

Describe expected behaviour

Snyk should "eat their own dog food" ie not ship products with known critical/high vulnerabilities :)

Additional context

Add any other context or screenshots about the feature request here.

Operator projects using the removed APIs in k8s 1.22 requires changes.

Problem Description

Kubernetes has been deprecating API(s), which will be removed and are no longer available in 1.22. Operators projects using these APIs versions will not work on Kubernetes 1.22 or any cluster vendor using this Kubernetes version(1.22), such as OpenShift 4.9+. Following the APIs that are most likely your projects to be affected by:

  • apiextensions.k8s.io/v1beta1: (Used for CRDs and available since v1.16)
  • rbac.authorization.k8s.io/v1beta1: (Used for RBAC/rules and available since v1.8)
  • admissionregistration.k8s.io/v1beta1 (Used for Webhooks and available since v1.16)

Therefore, looks like this project distributes solutions in the repository and does not contain any version compatible with k8s 1.22/OCP 4.9. (More info). Following some findings by checking the distributions published:

NOTE: The above findings are only about the manifests shipped inside of the distribution. It is not checking the codebase.

How to solve

It would be very nice to see new distributions of this project that are no longer using these APIs and so they can work on Kubernetes 1.22 and newer and published in the community-operators collection. OpenShift 4.9, for example, will not ship operators anymore that do still use v1beta1 extension APIs.

Due to the number of options available to build Operators, it is hard to provide direct guidance on updating your operator to support Kubernetes 1.22. Recent versions of the OperatorSDK greater than 1.0.0 and Kubebuilder greater than 3.0.0 scaffold your project with the latest versions of these APIs (all that is generated by tools only). See the guides to upgrade your projects with OperatorSDK Golang, Ansible, Helm or the Kubebuilder one. For APIs other than the ones mentioned above, you will have to check your code for usage of removed API versions and upgrade to newer APIs. The details of this depend on your codebase.

If this projects only need to migrate the API for CRDs and it was built with OperatorSDK versions lower than 1.0.0 then, you maybe able to solve it with an OperatorSDK version >= v0.18.x < 1.0.0:

$ operator-sdk generate crds --crd-version=v1
INFO[0000] Running CRD generator.
INFO[0000] CRD generation complete.

Alternatively, you can try to upgrade your manifests with controller-gen (version >= v0.4.1) :

If this project does not use Webhooks:

$ controller-gen crd:trivialVersions=true,preserveUnknownFields=false rbac:roleName=manager-role paths="./..."

If this project is using Webhooks:

  1. Add the markers sideEffects and admissionReviewVersions to your webhook (Example with sideEffects=None and admissionReviewVersions={v1,v1beta1}: memcached-operator/api/v1alpha1/memcached_webhook.go):

  2. Run the command:

$ controller-gen crd:trivialVersions=true,preserveUnknownFields=false rbac:roleName=manager-role webhook paths="./..."

For further information and tips see the comment.

[๐Ÿ™] Add ability to target specific namespaces

Describe the user need
Currently, the kubernetes-monitor by default scans for pods in all namespaces (with some default exclusions), and have the capability to exclude namespaces via the excludedNamespaces option.

It will be useful if there is the ability to target specific namespaces instead of having to find all other namespaces to exclude.

Describe expected behaviour
Have the ability to specify includedNamespaces option during the helm upgrade to tell the snyk-monitor to only scan the specified namespaces. Similar to excludedNamespaces, this can be a list.

helm upgrade --install snyk-monitor snyk-charts/snyk-monitor \ 
             --namespace snyk-monitor \
             --set includedNamespace="{some_namespace}"

This will take precedence over the excludedNamespaces, so if a namespace is specified on both the includeNamespaces and the excludedNamepsaces then the includedNamespaces will take effect.

Additional context
Our organisation is grouping kubernetes scan results into separate Snyk orgs. To achieve this, a snyk-monitor is deployed into each namespace. However, each snyk-monitor should only scan its own namespace. The existing exclusion approach works but not ideal since if a new namespace is added, all snyk-monitor deployments will need to be re-deployed to have that new namespace excluded.

[๐Ÿ™] Don't use mutable busybox:latest tag by default

Describe the user need
I don't want my containers to break when an upstream vendor publishes a new latest image. I also don't want to be subject to a supply chain attack made easier by blindly pulling in a mutable container image tag.

Describe expected behaviour

Pin init container image to a fixed busybox tag. This is configurable by the end-user, but the chart should come out of the box with a safer value. Additionally, forcing the end-user to manage the container themselves (ensuring it's kept up to date), isn't great.

Additional context

Report cronjobs workload

Is it possible to scan cronjobs workload with Snyk monitor?

Only Daemonset, Deployment or Statefulset was send in our snyk Kubernetes integration.

CHANGELOG.md

Hey folks, just curious if there are any changelogs published for the helm charts somewhere? Looking to do some upgrades and couldn't find any for the version changes.

[๐Ÿ›] Snyk-Monitor crashes - could not read the snyk-monitor deployment unique id

Hi Team

I am trying to get the snyk monitor up and running on AWS and VMware Tanzu but the container crashes immediately

  • v1.85.2
  • EKS

Log

Warning: Ignoring extra certs from /srv/app/certs/ca.pem, load failed: error:02001002:system library:fopen:No such file or directory
10
{"name":"kubernetes-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":30,"msg":"Cleaned temp storage","time":"2022-03-18T10:12:12.904Z","v":0}
9
{"name":"snyk-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":50,"error":{"message":"HTTP request failed","name":"HttpError","stack":"HttpError: HTTP request failed\n    at Request._callback (/srv/app/node_modules/@kubernetes/client-node/dist/gen/api/appsV1Api.js:4141:36)\n    at Request.self.callback (/srv/app/node_modules/request/request.js:185:22)\n    at Request.emit (node:events:520:28)\n    at Request.emit (node:domain:475:12)\n    at Request.<anonymous> (/srv/app/node_modules/request/request.js:1154:10)\n    at Request.emit (node:events:520:28)\n    at Request.emit (node:domain:475:12)\n    at IncomingMessage.<anonymous> (/srv/app/node_modules/request/request.js:1076:12)\n    at Object.onceWrapper (node:events:639:28)\n    at IncomingMessage.emit (node:events:532:35)"},"namespace":"helix-snyk-monitor","msg":"could not read the snyk-monitor deployment unique id","time":"2022-03-18T10:12:13.009Z","v":0}
8
{"name":"kubernetes-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":30,"userLocator":"969f618c-cbc7-4c6c-947b-3de7a7e3bb90","cluster":"Helix AWS Showcase","agentId":"949bd26e-fa6c-45b9-b4f9-dd19a4c47aed","msg":"attempting to send cluster metadata","time":"2022-03-18T10:12:13.009Z","v":0}
7
{"name":"kubernetes-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":30,"userLocator":"969f618c-cbc7-4c6c-947b-3de7a7e3bb90","cluster":"Helix AWS Showcase","agentId":"949bd26e-fa6c-45b9-b4f9-dd19a4c47aed","attempt":1,"msg":"cluster metadata sent upstream successfully","time":"2022-03-18T10:12:13.277Z","v":0}
6
{"name":"kubernetes-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":30,"userLocator":"969f618c-cbc7-4c6c-947b-3de7a7e3bb90","cluster":"Helix AWS Showcase","agentId":"949bd26e-fa6c-45b9-b4f9-dd19a4c47aed","msg":"attempting to send workload auto-import policy","time":"2022-03-18T10:12:13.278Z","v":0}
5
{"name":"kubernetes-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":30,"userLocator":"969f618c-cbc7-4c6c-947b-3de7a7e3bb90","cluster":"Helix AWS Showcase","agentId":"949bd26e-fa6c-45b9-b4f9-dd19a4c47aed","attempt":1,"msg":"workload auto-import policy sent upstream successfully","time":"2022-03-18T10:12:13.579Z","v":0}
4
{"name":"kubernetes-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":30,"cluster":"Helix AWS Showcase","msg":"starting to monitor","time":"2022-03-18T10:12:13.580Z","v":0}
3
{"name":"kubernetes-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":30,"msg":"setting up cluster informers","time":"2022-03-18T10:12:13.580Z","v":0}
2
{"name":"kubernetes-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":50,"err":{"message":"HTTP request failed","name":"HttpError","stack":"HttpError: HTTP request failed\n    at Request._callback (/srv/app/node_modules/@kubernetes/client-node/dist/gen/api/coreV1Api.js:9175:36)\n    at Request.self.callback (/srv/app/node_modules/request/request.js:185:22)\n    at Request.emit (node:events:520:28)\n    at Request.emit (node:domain:475:12)\n    at Request.<anonymous> (/srv/app/node_modules/request/request.js:1154:10)\n    at Request.emit (node:events:520:28)\n    at Request.emit (node:domain:475:12)\n    at IncomingMessage.<anonymous> (/srv/app/node_modules/request/request.js:1076:12)\n    at Object.onceWrapper (node:events:639:28)\n    at IncomingMessage.emit (node:events:532:35)"},"msg":"error while listing namespaces in cluster","time":"2022-03-18T10:12:13.591Z","v":0}
1
{"name":"kubernetes-monitor","hostname":"snyk-monitor-8574686b5f-nj8pq","pid":6,"level":50,"error":{"message":"HTTP request failed","name":"HttpError","stack":"HttpError: HTTP request failed\n    at Request._callback (/srv/app/node_modules/@kubernetes/client-node/dist/gen/api/coreV1Api.js:9175:36)\n    at Request.self.callback (/srv/app/node_modules/request/request.js:185:22)\n    at Request.emit (node:events:520:28)\n    at Request.emit (node:domain:475:12)\n    at Request.<anonymous> (/srv/app/node_modules/request/request.js:1154:10)\n    at Request.emit (node:events:520:28)\n    at Request.emit (node:domain:475:12)\n    at IncomingMessage.<anonymous> (/srv/app/node_modules/request/request.js:1076:12)\n    at Object.onceWrapper (node:events:639:28)\n    at IncomingMessage.emit (node:events:532:35)"},"msg":"an error occurred while monitoring the cluster","time":"2022-03-18T10:12:13.591Z","v":0}

Deploymentconfig

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/instance: helix-snyk-monitor
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: snyk-monitor
    helm.sh/chart: snyk-monitor-1.85.2
  name: snyk-monitor
  namespace: helix-snyk-monitor
spec:
  selector:
    matchLabels:
      app.kubernetes.io/instance: snyk-monitor
      app.kubernetes.io/name: snyk-monitor
  strategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app.kubernetes.io/instance: snyk-monitor
        app.kubernetes.io/managed-by: Helm
        app.kubernetes.io/name: snyk-monitor
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: kubernetes.io/arch
                    operator: In
                    values:
                      - amd64
      containers:
        - env:
            - name: SNYK_CLUSTER_NAME
              value: Helix AWS Showcase
            - name: NODE_EXTRA_CA_CERTS
              value: /srv/app/certs/ca.pem
            - name: SNYK_INTEGRATION_ID
              valueFrom:
                secretKeyRef:
                  key: integrationId
                  name: snyk-monitor
            - name: SNYK_WATCH_NAMESPACE
            - name: SNYK_DEPLOYMENT_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: SNYK_DEPLOYMENT_NAME
              value: snyk-monitor
            - name: SNYK_INTEGRATION_API
            - name: SNYK_MONITOR_VERSION
              value: 1.85.2
            - name: HOME
              value: /srv/app
            - name: HTTP_PROXY
            - name: HTTPS_PROXY
            - name: NO_PROXY
            - name: LOG_LEVEL
            - name: SKIP_K8S_JOBS
            - name: SNYK_SKOPEO_COMPRESSION_LEVEL
              value: '6'
            - name: SNYK_WORKERS_COUNT
              value: '10'
            - name: V8_MAX_OLD_SPACE_SIZE
              value: '2048'
            - name: UV_THREADPOOL_SIZE
              value: '24'
            - name: NODE_OPTIONS
              value: '--max_old_space_size=2048'
          image: 'privateregistry.com/snyk/kubernetes-monitor:1.85.2'
          imagePullPolicy: Always
          livenessProbe:
            exec:
              command:
                - 'true'
          name: snyk-monitor
          readinessProbe:
            exec:
              command:
                - 'true'
          resources:
            limits:
              cpu: '1'
              memory: 2Gi
            requests:
              cpu: 250m
              memory: 400Mi
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL
            privileged: false
            readOnlyRootFilesystem: true
            runAsNonRoot: true
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
          volumeMounts:
            - mountPath: /srv/app/.docker
              name: docker-config
              readOnly: true
            - mountPath: /var/tmp
              name: temporary-storage
            - mountPath: /srv/app/certs
              name: ssl-certs
            - mountPath: /tmp/policies
              name: workload-policies
              readOnly: true
            - mountPath: /srv/app/.config/containers
              name: registries-conf
      initContainers:
        - command:
            - sh
            - '-c'
            - chmod -R go+rwX /var/tmp || true
          image: 'privateregistry.com/snyk/busybox:latest'
          name: volume-permissions
          resources:
            limits:
              cpu: 100m
              memory: 100Mi
            requests:
              cpu: 100m
              memory: 100Mi
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
                - ALL
            privileged: false
            readOnlyRootFilesystem: true
            runAsNonRoot: false
          volumeMounts:
            - mountPath: /var/tmp
              name: temporary-storage
      restartPolicy: Always
      serviceAccountName: snyk-monitor
      volumes:
        - name: docker-config
          secret:
            items:
              - key: dockercfg.json
                path: config.json
            secretName: snyk-monitor
        - emptyDir:
            sizeLimit: 50Gi
          name: temporary-storage
        - configMap:
            name: snyk-monitor-certs
            optional: true
          name: ssl-certs
        - configMap:
            name: snyk-monitor-workload-policies
            optional: true
          name: workload-policies
        - configMap:
            name: snyk-monitor-registries-conf
            optional: true
          name: registries-conf

Can anyone help?

Best Dominik

Snyk complains about this image because of vulnerabilities in Skopeo

Snyk currently flags this image because it includes Skopeo. Skopeo's go.sum has a vulnerable version of ulikunitz/xz, the project but doesn't actually use this version (as verified by looking at the vendor/modules.txt).

The next release of Skopeo should not have this in the go.sum, which will fix Synk's issue with it. When possible, this project should update Skopeo.

Add support for and/or document credHelper dockerconfig option

When running inside GKE cluster with Workload Identity enabled following docker config enabled access to the registry without managing static credentials:

{
  "credHelpers": {
    "gcr.io": "gcloud",
    "marketplace.gcr.io": "gcloud",
    "eu.gcr.io": "gcloud",
    "us.gcr.io": "gcloud",
    "staging-k8s.gcr.io": "gcloud",
    "asia.gcr.io": "gcloud"
  }
}

It would be great if snyk-monitor image and helm chart contained gcloud CLI tool and supported this mode of operation

[๐Ÿ™] Allow setting the upgrade strategy in the helm chart

Describe the user need
I would like to be able to set the upgrade strategy to 'Recreate' on the deployment, without setting up a persistent volume. Currently, the chart only changes this if a pvc is enabled.

Describe expected behaviour
I would like to be able to set the upgrade strategy in the helm values.

Additional context
On some of my clusters, the resources used by the monitor are significant enough that it has trouble running two copies of the pod at once. I would like to be able to change the upgrade strategy in order to avoid the challenge where the replacement pod cannot be scheduled due to lack of resources.

[๐Ÿ›] snyk/kubernetes-monitor GCP Container Registry

  • kubernetes-monitor version [e.g. v2.4.13]
  • Cloud runtime [GKE]

Expected behaviour

Authenticate to private container registries should works.

Actual behaviour

kubernetes-monitor Pod cannot pull image for scan and has errors

{"name":"kubernetes-monitor","hostname":"snyk-kubernetes-monitor-8fdcf4ccc-mh4ls","pid":7,"level":40,"message":"WARNING: Could not setup log file in /srv/app/.config/gcloud/logs, (OSError: [Errno 30] Read-only file system: '/srv/app/.config/gcloud'.\nThe configuration directory may not be writable. To learn more, see https://cloud.google.com/sdk/docs/configurations#creating_a_configuration\nERROR: gcloud crashed (OSError): [Errno 30] Read-only file system: '/srv/app/.config/gcloud'\n\nIf you would like to report this issue, please run the following command:\n  gcloud feedback\n\nTo check gcloud for common problems, please run the following command:\n  gcloud info --run-diagnostics\ntime=\"2023-10-06T09:37:10Z\" level=fatal msg=\"initializing source docker://gcr.io/****/****@sha256:62a442d3d2cf1d72758994e66767f2f6dbc8d2e4b5d9886d393509725d5222f2: getting username and password: 1 error occurred:\\n\\t* error getting credentials - err: exit status 1, out: ``\\n\\n\"\n","bin":"skopeo","loggableArguments":["copy","--dest-compress-level","6","docker://gcr.io/****/****@sha256:62a442d3d2cf1d72758994e66767f2f6dbc8d2e4b5d9886d393509725d5222f2","docker-archive:/var/tmp/gcr_io_****_****_0_0_90_2076038_623683417.tar"],"msg":"child process failure","time":"2023-10-06T09:37:10.828Z","v":0}

{"name":"kubernetes-monitor","hostname":"snyk-kubernetes-monitor-8fdcf4ccc-mh4ls","pid":7,"level":50,"error":{"message":"`skopeo copy --dest-compress-level 6 --src-cert-dir /srv/app/certs docker://gcr.io/****/****@sha256:62a442d3d2cf1d72758994e66767f2f6dbc8d2e4b5d9886d393509725d5222f2 docker-archive:/var/tmp/gcr_io_****_****_0_0_90_2076038_623683417.tar` failed with code 1","name":"ChildProcessError","stack":"ChildProcessError: `skopeo copy --dest-compress-level 6 --src-cert-dir /srv/app/certs docker://gcr.io/****/****@sha256:62a442d3d2cf1d72758994e66767f2f6dbc8d2e4b5d9886d393509725d5222f2 docker-archive:/var/tmp/gcr_io_****_****_0_0_90_2076038_623683417.tar` failed with code 1\n    at ChildProcess.<anonymous> (/srv/app/node_modules/child-process-promise/lib/index.js:132:23)\n    at ChildProcess.emit (node:events:513:28)\n    at ChildProcess.emit (node:domain:489:12)\n    at maybeClose (node:internal/child_process:1100:16)\n    at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5)","code":1},"image":"gcr.io/****/****@sha256:62a442d3d2cf1d72758994e66767f2f6dbc8d2e4b5d9886d393509725d5222f2","msg":"failed to pull image docker/oci archive image","time":"2023-10-06T09:37:10.829Z","v":0}

Steps to reproduce

I have private GCP container registries, i created dockercfg.json which includes

  "credHelpers": {
    "us.gcr.io": "gcloud",
    "asia.gcr.io": "gcloud",
    "marketplace.gcr.io": "gcloud",
    "gcr.io": "gcloud",
    "eu.gcr.io": "gcloud",
    "staging-k8s.gcr.io": "gcloud"
  }

How a was able to fix this issue

Added to Deployment

  extraVolumes:
    - name: config-gcloud
      emptyDir:
         sizeLimit: 500Mi

  extraVolumeMounts:
    - name: config-gcloud
      mountPath: /srv/app/.config/gcloud

[๐Ÿ™] Make NetworkPolicy an optional resource

Describe the user need
The network policy that comes with the monitor opens egress to the world.

We are currently using Cilium for all network policies within the cluster but it appears with both existing the cilium policy is respecting the network policy so this component has unrestricted egress.

Describe expected behaviour

Being able to disable the NetworkPolicy would allow us to control the egress to known destinations

[๐Ÿ›] Having trouble pulling private images during workload scans

  • 1.99.2
  • EKS

Expected behaviour

Should get aws_auth to pull private ecr images

Actual behaviour

{
    "name": "kubernetes-monitor",
    "hostname": "snyk-monitor-66f5c46dd6-wkc7h",
    "pid": 6,
    "level": 50,
    "error": {
        "message": "Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1",
        "name": "CredentialsError",
        "stack": "CredentialsError: Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1\n    at Timeout.connectTimeout [as _onTimeout] (/srv/app/node_modules/aws-sdk/lib/http/node.js:69:15)\n    at listOnTimeout (node:internal/timers:559:17)\n    at processTimers (node:internal/timers:502:7)",
        "code": "CredentialsError"
    },
    "image": "XXXXX.dkr.ecr.ap-southeast-2.amazonaws.com/some-repo@sha256:43d0eeb5047449b7aaa443a5ca7bbe933fad1e04197090ab800e530def5e9f79",
    "msg": "failed to pull image docker/oci archive image",
    "time": "2022-11-18T01:54:20.228Z",
    "v": 0
}

Steps to reproduce

Hey we use AWS so eks and ecr and we run everything on fargate including snyk

Our ecrs are in a separate account to where the eks is hosted, we use the principle org approach to allow access so every account in our org should be able to see it.

ive confirmed that the role we have created is being added to the snyk monitor pod via the service account but no matter which role i provide to the pod i get the same error above.

ive also confirmed if i assume the role being provided on my machine it can describe the images in this cross account ecr

Do you know if there is any debug steps i could try on the pod to further diagnose the issue?

Thanks!

[๐Ÿ›] Snyk-monitor failing in AKS

  • kubernetes-monitor version - v1.100.0
  • Cloud runtime - AKS

Expected behaviour

snyk-monitor pod runs healthy

Actual behaviour

snyk-monitor pod is in crashloop backoff state with errors in logs -

{"name":"kubernetes-monitor","hostname":"snyk-monitor-68d88b84bc-bgffh","pid":7,"level":50,"code":"","error":{"message":"Too Many Requests","name":"Error","stack":"Error: Too Many Requests\n    at Request.<anonymous> (/srv/app/node_modules/@kubernetes/client-node/dist/watch.js:23:31)\n    at Request.emit (node:events:513:28)\n    at Request.emit (node:domain:489:12)\n    at Request.onRequestResponse (/srv/app/node_modules/request/request.js:1059:10)\n    at ClientRequest.emit (node:events:513:28)\n    at ClientRequest.emit (node:domain:489:12)\n    at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:693:27)\n    at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)\n    at HTTPParser.execute (<anonymous>)\n    at TLSSocket.socketOnData (node:_http_client:534:22)"},"msg":"unexpected informer error event occurred","time":"2023-02-02T10:46:41.738Z","v":0}
{"name":"kubernetes-monitor","hostname":"snyk-monitor-68d88b84bc-bgffh","pid":7,"level":50,"code":"","error":{"message":"Too Many Requests","name":"Error","stack":"Error: Too Many Requests\n    at Request.<anonymous> (/srv/app/node_modules/@kubernetes/client-node/dist/watch.js:23:31)\n    at Request.emit (node:events:513:28)\n    at Request.emit (node:domain:489:12)\n    at Request.onRequestResponse (/srv/app/node_modules/request/request.js:1059:10)\n    at ClientRequest.emit (node:events:513:28)\n    at ClientRequest.emit (node:domain:489:12)\n    at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:693:27)\n    at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)\n    at HTTPParser.execute (<anonymous>)\n    at TLSSocket.socketOnData (node:_http_client:534:22)"},"msg":"unexpected informer error event occurred","time":"2023-02-02T10:46:41.739Z","v":0}
{"name":"kubernetes-monitor","hostname":"snyk-monitor-68d88b84bc-bgffh","pid":7,"level":50,"code":"","error":{"message":"Too Many Requests","name":"Error","stack":"Error: Too Many Requests\n    at Request.<anonymous> (/srv/app/node_modules/@kubernetes/client-node/dist/watch.js:23:31)\n    at Request.emit (node:events:513:28)\n    at Request.emit (node:domain:489:12)\n    at Request.onRequestResponse (/srv/app/node_modules/request/request.js:1059:10)\n    at ClientRequest.emit (node:events:513:28)\n    at ClientRequest.emit (node:domain:489:12)\n    at HTTPParser.parserOnIncomingClient [as onIncoming] (node:_http_client:693:27)\n    at HTTPParser.parserOnHeadersComplete (node:_http_common:128:17)\n    at HTTPParser.execute (<anonymous>)\n    at TLSSocket.socketOnData (node:_http_client:534:22)"},"msg":"unexpected informer error event occurred","time":"2023-02-02T10:46:41.741Z","v":0}
{"name":"kubernetes-monitor","hostname":"snyk-monitor-68d88b84bc-bgffh","pid":7,"level":50,"code":"","error":{"message":"HTTP request failed","name":"HttpError","stack":"HttpError: HTTP request failed\n    at Request._callback (/srv/app/node_modules/@kubernetes/client-node/dist/gen/api/coreV1Api.js:14294:36)\n    at Request.self.callback (/srv/app/node_modules/request/request.js:185:22)\n    at Request.emit (node:events:513:28)\n    at Request.emit (node:domain:489:12)\n    at Request.<anonymous> (/srv/app/node_modules/request/request.js:1154:10)\n    at Request.emit (node:events:513:28)\n    at Request.emit (node:domain:489:12)\n    at IncomingMessage.<anonymous> (/srv/app/node_modules/request/request.js:1076:12)\n    at Object.onceWrapper (node:events:627:28)\n    at IncomingMessage.emit (node:events:525:35)"},"msg":"error while listing namespace","time":"2023-02-02T10:46:41.748Z","v":0}
{"name":"kubernetes-monitor","hostname":"snyk-monitor-68d88b84bc-bgffh","pid":7,"level":50,"reason":{"response":{"statusCode":429,"body":"Too many requests, please try again later.\n","headers":{"audit-id":"9f82dcac-58f2-40e3-ba2e-83c891c07d68","cache-control":"no-cache, private","content-type":"text/plain; charset=utf-8","retry-after":"1","x-content-type-options":"nosniff","x-kubernetes-pf-flowschema-uid":"35b327af-8ef2-470d-a133-a232d9b0d219","x-kubernetes-pf-prioritylevel-uid":"86f513a7-ca6d-4052-85bc-3fbe698ccd2c","date":"Thu, 02 Feb 2023 10:46:41 GMT","content-length":"43","connection":"close"},"request":{"uri":{"protocol":"https:","slashes":true,"auth":null,"host":"10.0.0.1:443","port":"443","hostname":"10.0.0.1","hash":null,"search":null,"query":null,"pathname":"/api/v1/namespaces/masked","path":"/api/v1/namespaces/masked","href":"https://10.0.0.1:443/api/v1/namespaces/masked"},"method":"GET","headers":{"Accept":"application/json","Authorization":"Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IlpTaDRPZ2h4eTN0ZEliTVM1VFFqSlE2OG44TnQ5RnZlMVJBaTJwRDh4NVUifQ.eyJhdWQiOlsiaHR0cHM6Ly93ZXUtY2RycGxhdGZvcm0tY2EzZjU1MzEuMmE4YmE2OTEtODNiMy00N2JjLWJkMDYtZmE2Y2M1NjQ5N2IzLnByaXZhdGVsaW5rLndlc3RldXJvcGUuYXptazhzLmlvIiwiXCJ3ZXUtY2RycGxhdGZvcm0tY2EzZjU1MzEuMmE4YmE2OTEtODNiMy00N2JjLWJkMDYtZmE2Y2M1NjQ5N2IzLnByaXZhdGVsaW5rLndlc3RldXJvcGUuYXptazhzLmlvXCIiLCJodHRwczovL3dldS1jZHJwbGF0Zm9ybS1jM2NjOWRkZC5oY3Aud2VzdGV1cm9wZS5hem1rOHMuaW8iLCJcIndldS1jZHJwbGF0Zm9ybS1jM2NjOWRkZC5oY3Aud2VzdGV1cm9wZS5hem1rOHMuaW9cIiJdLCJleHAiOjE3MDY4NzA3MzksImlhdCI6MTY3NTMzNDczOSwiaXNzIjoiaHR0cHM6Ly93ZXUtY2RycGxhdGZvcm0tY2EzZjU1MzEuMmE4YmE2OTEtODNiMy00N2JjLWJkMDYtZmE2Y2M1NjQ5N2IzLnByaXZhdGVsaW5rLndlc3RldXJvcGUuYXptazhzLmlvIiwia3ViZXJuZXRlcy5pbyI6eyJuYW1lc3BhY2UiOiJjZHJwbGF0Zm9ybSIsInBvZCI6eyJuYW1lIjoic255ay1tb25pdG9yLTY4ZDg4Yjg0YmMtYmdmZmgiLCJ1aWQiOiI3Yzc1NjEyYy03ZDYwLTQ3MjItOWE1OC1kN2MxZjBiNDJkMDIifSwic2VydmljZWFjY291bnQiOnsibmFtZSI6InNueWstbW9uaXRvciIsInVpZCI6IjBkZTA5ODM4LWZiMWEtNDkwZS04MzNiLTVjMTdjN2EzNTY5YSJ9LCJ3YXJuYWZ0ZXIiOjE2NzUzMzgzNDZ9LCJuYmYiOjE2NzUzMzQ3MzksInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpjZHJwbGF0Zm9ybTpzbnlrLW1vbml0b3IifQ.NFsE8kRRHuKqDgAzB_yX-fVUjbuPugpaXLWoRkPsCqjeJbHn9vA4if7P9SpFGEF-KlPFHE21n6TwfzWKifsT-u3KMNn4QNMok66HdNbpMBUWbi5Sr6RiziDSRNC1xZ2qJMLyNsAQKG6FbdXG3NJ5LUvW9s_HGIeoLLLlT3ui9icpTDG6nMdJtd_ny93yswiQgjxUshQBjNf1ysD8MEY997sZYKaE4Q0ljoQunW4hfcWDkeD8Ba5i9BTSggz0wyabqsNpTv4HB-eS3eWxwbhuhoz4qRSLdmXy0-IRkaYdPT_iMyfCdHM1S5ZNiJfnWw2eGo8S2WgdrLxbBzNO-OvlJ93rrPGzIk9tbloOgdBz2lsm-NZOc-21JXsEOKGpnv48C6mFPVKs2r9PNzU11T1HiTM1yBWYMsm4JF13xOs30vZC4ksFV4SjaZTfnJna2TqUu11M5HsRiRg0CZhFYQ1OTZficp09bmt4Oqs9rpEWziiZRpCLKWDAmtx9joF94IASenGMRuKZt73pdgnEM8ejYhVh4StPkiG34HzjiIR2cMEqTEu1eantyDuzCFwDyvYhLnV-N0hJSY9iL5xxsW-yNiAR1Bd_vyAGEUjec740RDFT58Bk7rZPAaFfEccKQKIF03gnl9nVqYSLQpGp8lySVUeDQ0OGa-_9bNWAAI9Egug"}}},"body":"Too many requests, please try again later.\n","statusCode":429,"name":"HttpError"},"promise":{},"msg":"UNHANDLED REJECTION!","time":"2023-02-02T10:46:41.749Z","v":0}

Steps to reproduce

Install helm chart -

helm upgrade --install snyk-monitor snyk-charts/snyk-monitor \
  --version 1.100.0 \
  --set clusterName="${snykClusterName}" \
  --set scope=Namespaced \
  --set policyOrgs="${snykOrgId}"

Screenshots

image

[๐Ÿ™] Selectively add namespaces instead of excludedNamespaces

Describe the user need
Instead of excluding namespaces via the excludedNamespaces: array, we would like to selectively add namespaces to a list, or choose namespaces by using label selectors, e.g.:

# Add selected namespaces
includedNamespaces:
  matchLabels: 
    key: value
#or 
includedNamespaces: 
  - namespaceA
  - namespaceB

Describe expected behaviour

snyk-monitor uses the exact list or selection of namespaces provided in the includedNamespaces field.

Additional context

Probably, the changes in the helm chart will not be that much, however, I don't know, if there are code-changes to be done.

Security context of InitContainer conflicts with psp enforced policy

Starting with snyk-monitor version: 1.40.0 an InitContainer was added to deployment which requires : runAsNonRoot to be set to false.
At PSP level, it is enforced that flag: runAsNonRoot to be set to true
runAsUser: rule: MustRunAsNonRoot

Following error is encountered due to this conflict:
Warning FailedCreate 14s (x14 over 55s) replicaset-controller Error creating: pods "snyk-monitor-d99b94898-" is forbidden: unable to validate against any pod security policy: [spec.initContainers[0].securityContext.runAsNonRoot: Invalid value: false: must be true]

Ability to specify nodeSelector in the Helm chart

Can we get the ability to specify the nodeSelector in the Helm chart? This would be handy where we want the monitor to run on a specific set of machines. At present this facility is not available.

[๐Ÿ™] Add (document) support for Google Artifact Registry

Describe the user need
Hi Team, as GCR recently got deprecated it might be high time to start officially supporting Google Artifact Registry.

Describe expected behaviour
The following section of the documentation should include a snippet showcasing a sample configuration of the dockercfg.json including credHelpers set for GAR: https://github.com/snyk/kubernetes-monitor/tree/staging/snyk-monitor#installing

Example:

โฏ cat dockercfg.json | jq
{
  "credHelpers": {
    "us-central1-docker.pkg.dev": "gcloud",
    "europe-west1-docker.pkg.dev": "gcloud"
  }
}

Of course some unit and/or integration test cases would be welcome as well.

Additional context
We've actually tested this in our environment and the proposed addition works as intended.

NOTE: The underlying GCP Service Account mapped via Workload Identity needs to have a proper IAM binding ie. the Artifact Registry Reader role bound to the Registry in scope.

Reference: https://cloud.google.com/artifact-registry/docs/access-control#roles

[๐Ÿ›]Cannot upgrade Helm Chart from "1.103.0" -> "2.0.0"

  • kubernetes-monitor version 1.103.0
  • Cloud runtime RKE2

Expected behaviour

The upgrade to succeed.

Actual behaviour

The upgrade fails with this error:

cannot patch "snyk" with kind Deployment: Deployment.apps "snyk" is invalid: [spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[0].values: Required value: must be specified when operatoris 'In' or 'NotIn', spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[1].values: Required value: must be specified whenoperatoris 'In' or 'NotIn']

Steps to reproduce

Perform a helm update from 1.103.0 to 2.0.0. I am using the terraform helm provider, with the following values.yaml:

clusterName: "${var.project_name}"

excludedNamespaces:
${join("\n", formatlist("  - %s", local.exclude_namespaces))}

requests:
  cpu: "1500m"
  ephemeral-storage: "50Gi"
  memory: "2350Mi"

limits:
  cpu: "3200m"
  ephemeral-storage: "50Gi"
  memory: "5Gi"

strategy:
  type: Recreate

[๐Ÿ™]Support discovery of dockerconfig secrets

Describe the user need
In order to properly configure the snyk-monitor secret with the right dockerconfig secrets, I need to dynamically look up the secrets that are used in an enterprise, which are different for an environment of hundreds of clusters, for each cluster.

Instead, why can't this application just use the same secrets that the workload is already using? Why do I need to configure this information again?

Describe expected behaviour

When prompted to scan a workload, kubernetes-monitor just uses the same secrets that the workload is configured to use.

Additional context

Add any other context or screenshots about the feature request here.

Pod restart every hour

This is not really a bug but seems like what is now deployment should be actually a job. Right now pod restarts every hour and on each run it scans the containers, syncs with Snyk and then does nothing until it gets killed after an hour.
Firstly it should run as a job which once done will be marked as completed so you won't get a running idle container which eventually gets killed. Right now I have this pod running for 2 days and it already shows 40 restarts. We have alerts based on frequent restarts because this many restarts means something is wrong.
Secondly if it is configured as job/cronjob then we can set the frequency ourselves. E.g. we would like to sync it every 15 mins instead of 1 hour.
Let me know if this makes sense.

snyk monitor unable to pull images when using PVC due to permission issues

This might be related to #697 but using PVC (created by snyk monitor helm chart), I came across issue where snyk monitor was not able to write to /var/tmp. Not sure why but even with permissions set by init container it won't allow a a container running as non root to write to it. I think PVC mount perms work differently.

So I solved this is by setting fsgroup on pod level which worked i.e.

securityContext:
        fsGroup: 2000

And I also removed init container as with this context we don't need it anymore. I don't understand what was the need for this container in the first place if we could use fsgroup
I have not tested it with non-pvc volume but I think it should work.

[๐Ÿ›]Error upgrading to chart 1.98.0

  • Upgrading from version 1.92.2 to 1.98.0

Expected behaviour

Upgrade succeeds.

Actual behaviour

I receive this error in the upgrade:
Error: UPGRADE FAILED: template: snyk-monitor/templates/psp.yaml:1:14: executing "snyk-monitor/templates/psp.yaml" at <.Values.psp.enabled>: nil pointer evaluating interface {}.enabled

Steps to reproduce

run a helm upgrade from the old version to the new.

Additional Information

I do not set anything having to do with PSP in the values.yaml.

[๐Ÿ™] Require Linux/ARM64 docker image for snyk/kubernetes-monitor

Describe the user need

Hi Team,

I am working on building snyk/kubernetes-monitor images for both amd64 and arm64 platform. Successfully built the docker image for both the platforms. I have modified build-images.sh script to use buildx for building and pushing and made changes in @jobs.yml file to remove pushing to Docker hub and packed it to config.yml file.

Changes Required: odidev@81ac320

Do you have any plans for releasing ARM64 images?

It will be very helpful if an ARM64 image is available. If interested, I will raise a PR.

[๐Ÿ™] Revisit readiness and liveness probes for k8s deployment

Describe the user need
Would it be possible to set effective liveness and readiness probe on the kubernetes-monitor deployment?

Describe expected behaviour

At the moment, the kubernetes-monitor pod is always starting and working well. But in case of issues from the application itself, Kubernetes will not detect that the pod is having issues if we do not set propre and effective liveness/readiness probe.

Would it be possible to get some accurate ones?

Thanks in advance!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.