Giter Club home page Giter Club logo

charts's Introduction

Sysdig Helm Charts

This GitHub repository is the official source for Sysdig's Helm charts.

For instructions about how to install charts from this repository, visit the public website at https://charts.sysdig.com


Contribute

contribute

Development

How to make changes to an existing chart without publishing

If you make changes to an existing chart, but do not change its version, nothing new will be published to the charts repository.

Add a new chart

To add a new chart, create a directory inside charts with it contents at main branch.

When you commit it, it will be picked up by the GitHub action, and if it contains a chart and version that doesn't already exist in the charts repository, a new release with the package for the chart will be published on the GitHub repository, and the list of all charts at index.yaml on gh-pages branch will be updated on the charts repository.

Please remind to include the new chart also in .github/workflows/helm-unit-test.yaml and .github/workflows/k8s-apis-deprecation.yml.

Add tests

Currently, two types of tests are available:


Pull Requests

Comply with requirements

Checklist to comply-with when doing the PR

  • Title of the PR starts with type and scope
    • In order to automatically generate a meaningful changelog PR titles must respect the following rules (the same title must be used when merging it)
    • A Type and Scope should always be present. check Conventional Commits ex.:feat(agent,node-analyzer,sysdig-deploy): add automated changelogs
  • Chart Version bumped
  • Variables are documented in the README.md (or README.tpl in some charts)
  • Check GithubAction checks (run pre-commit) to avoid merge-check stoppers
  • Changelogs and Release Notes are automated based on the commit messages using git-chglog

Comply with GithubAction Checks

Several checks are tested before a PR is merged. Make sure to fail-fast on your local, before committing, with pre-commit plugin, configured in /.pre-commit-config.yaml, to automate this step, and validate/detect the issues when committing from your local.

Some current checks:

  • lint checks, running
  • docs autogeneration, based on values.yaml. this does only apply to charts with README.tpl templates (ex.: admission-controller)
  • unit-test, which will call unit-tets

Changelog

Extended Changelog

If necessary it is possible to add extended details to a changelog entry by adding a special section in the commit body.

The custom section must start with Extended Changelog:, in order to instruct the rendering engine to stop and avoid capturing things like Signed-off-by: it is possible to add @@__CHGLOG_DELIMITER__@@ at the end of the section.

Example with Signed-off-by

Extended Changelog: Fixed 21 CVEs in total, the ones with high or critical severity are:
            * CVE-2022-1941
            * CVE-2022-1996
@@__CHGLOG_DELIMITER__@@

Signed-off-by: [email protected]

NOTE: Do not add the delimiter @@__CHGLOG_DELIMITER__@@ at the end of the commit body as it will cause an error.

Example without Signed-off-by

Extended Changelog: Fixed 21 CVEs in total, the ones with high or critical severity are:
            * CVE-2022-1941
            * CVE-2022-1996

NOTE: While merging a PR with Squash & Merge the Extended Changelog section must be manually added to the body or the workflow won't be able to process it.

Manual Changelog

Although not usually recommended it is possible to manually add a changelog entry, the ci does a simple grep in the CHANGELOG.md file and if the version being released is already present it will skip adding a new entry.

GithubPages / Documentation

https://charts.sysdig.com is managed through GithubPages action, .github/workflows/release.yml will merge each charts/*/README.md into the gh-pages branch.


Release

Publishing a new version of a chart

TL;DR: When a commit to main includes a new version of a chart, a GitHub action will make it available on the charts repository.

With each commit to main, a GitHub action will compare all charts versions at the charts folder on main branch with published versions at the index.yaml chart list on gh-pages branch.

When it detects that the version in the folder doesn't exist in index.yaml, it will create a release with the packaged chart content on the GitHub repository, and update index.yaml to include it on the charts repository.

index.yaml is accesible from https://sysdiglabs.github.io/charts/index.yaml and is the list of all charts and their versions available when you interact with the charts repository using Helm.

The packaged referenced in index.yaml, when it's updated using the GitHub action, will link for download to the URL provided by the GitHub repository release files.


More informations

You can find more information at:

charts's People

Contributors

achandras avatar airadier avatar albertobarba avatar aroberts87 avatar chen-shmilovich-sysdig avatar dark-vex avatar deepskyblue86 avatar dependabot[bot] avatar dippie8 avatar draios-jenkins avatar federicoferesini avatar francesco-furlan avatar frasecci avatar galshnapp-sysdig avatar hayk99 avatar ironashram avatar jprieto92 avatar lilx1ao avatar mavimo avatar mech-pig avatar michele-mangili avatar miketnt avatar nestorsalceda avatar nkraemer-sysdig avatar penguinjournals avatar provok avatar radhikapc avatar tembleking avatar vicenteherrera avatar zohar-arad 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

Watchers

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

charts's Issues

[admission-controller] Helm chart generates duplicate ValidatingWebhookConfiguration resources

Hi,

Previously we used terraform to deploy the sysdig-deploy helm chart to our cluster, but are now trying to move the setup to ArgoCD using Kustomize. This works for all our other charts, but it seems like the admission-controller sub-chart is generating multiple resources with the same name/id, which causes kustomization to fail with the following message

Error: may not add resource with an already registered id: admissionregistration.k8s.io_v1_ValidatingWebhookConfiguration|sysdig-agent|sysdig-cluster-agent-admissioncontroller-webhook

Our kustomization.yaml, and the values.yaml has set admissionController.enabled: true:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
helmCharts:
  - name: sysdig-deploy
    namespace: sysdig-agent
    repo: https://charts.sysdig.com/
    releaseName: sysdig-cluster-agent
    valuesFile: values.yaml
    version: "1.19.2"
    includeCRDs: true

Running helm template sysdig sysdig/sysdig-deploy --values values.yaml works, but I can see the two resources created.

# Source: sysdig-deploy/charts/admissionController/templates/webhook/admissionregistration.yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: sysdig-admissioncontroller-webhook
  namespace: default
webhooks: []

and

# Source: sysdig-deploy/charts/admissionController/templates/webhook/admissionregistration.yaml
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: sysdig-admissioncontroller-webhook
  namespace: default
  annotations:
    "helm.sh/hook": "post-install, post-upgrade"
    meta.helm.sh/release-name: sysdig
    meta.helm.sh/release-namespace: default
  labels:
    app.kubernetes.io/managed-by: Helm
webhooks:
- name: audit.secure.sysdig.com
  matchPolicy: Equivalent
  rules:
    <truncated>
  clientConfig:
    <truncated>
  admissionReviewVersions: ["v1", "v1beta1"]
  sideEffects: None
  timeoutSeconds: 5
  failurePolicy: Ignore

I don't know the reason for creating a empty ValidatingWebhookConfiguration and then overwriting it. It seemingly works with Helm, but causes problems for Kustomize. Let me know if you want me to open a PR with a suggested solution or not.

Test resources are being rendered via helm

Hey, seems like test charts are being rendered in latest version even when they should be ignored by .helmignore file.

For example, this resource can be seen when running: helm template sysdig-deploy --namespace sysdig-agent templates/platform/sysdig-agent/helm

Can you fix it please? It's blocking us from updating to latest helm chart.

Thanks :)

Related ticket: 00026796

sysdig-agent daemonset does not respects rolling update strategy

I have observed that sysdig-agent daemonset ignores the rolling update strategy and it takes around 10 minutes to pass readiness checks.

Upon upgrading the helm chart, all the agent pods are replaced with new pods in spite of the readiness check failing on the newly created pods.

  updateStrategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
    type: RollingUpdate

However, node-analyzer with the same updateStrategy works as expected.

I understand this could be unrelated to the helm charts and please feel free to point me in the right direction. Thank you!

Node Analyzer Benchmark Write Permissions Toggle Statements Duplicated

In the Benchmark Runner Cluster Role there's a toggle based on .Values.nodeAnalyzer.benchmarkRunner.includeSensitivePermissions that should be stripping out write permissions required in the role. Above that there is a static statement that gives the Cluster Role for Node Analyzer the permissions regardless. If the value is set to true the same clause shows up twice in the role definition.

This is the only thing that requires cluster wide pod creation and deletion permissions so if it's not needed I would like to strip these permissions out. If they are needed for Node Analyzer's standard operation, take the toggle out to avoid confusion about if the permissions are necessary.

# https://github.com/sysdiglabs/charts/blob/master/charts/node-analyzer/templates/clusterrole-node-analyzer.yaml#L36
- apiGroups:
    - ""
  resources:
    - "pods"
    - "pods/exec"
  verbs:
    - "create"
- apiGroups:
    - ""
  resources:
    - "pods"
  verbs:
    - "delete"

# https://github.com/sysdiglabs/charts/blob/master/charts/node-analyzer/templates/clusterrole-node-analyzer.yaml#L99
{{- if .Values.nodeAnalyzer.benchmarkRunner.includeSensitivePermissions  }}
- apiGroups:
    - ""
  resources:
    - pods/exec
  verbs:
    - create
- apiGroups:
    - ""
  resources:
    - pods
  verbs:
    - create
    - delete
{{- end }}

[sysdig-deploy] Duplicated k8s_coldstart settings

When installing sysdig/sysdig-deploy chart with the cold-start values e.g.

  sysdig:
    settings:
      k8s_coldstart:
        max_parallel_cold_start: 0

The generated agent config map contains a duplicated empty value i.e.

apiVersion: v1
data:
  dragent.yaml: |
    new_k8s: true
    k8s_cluster_name: esc-3113
    collector: collector-staging.sysdigcloud.com
    collector_port: 6443
    security:
      enabled: true
      k8s_audit_server_enabled: true
      k8s_audit_server_port: 7765
      k8s_audit_server_url: 0.0.0.0
    k8s_coldstart: {}


    k8s_coldstart:
      max_parallel_cold_start: 0

cgroups v2 for sysdig agent

  • Please update the Sysdig agent to be compatible with AKS.
  • Beginning with AKS 1.25 and the upgrade to Ubuntu Ubuntu 22.04.2 LTS the sysdig agent breaks our standard environment for deploying java apps because of the cgroup v2 setting
  • This makes Sysdig Secure unusable for us.

@aroberts87

Using old beta annotations for arch and os

The sysdig charts are using old annotations:

Warning: spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[1].matchExpressions[0].key: beta.kubernetes.io/arch is deprecated since v1.14; use "kubernetes.io/arch" instead
Warning: spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[1].matchExpressions[1].key: beta.kubernetes.io/os is deprecated since v1.14; use "kubernetes.io/os" instead

Updating PSP

Hey Team,

We are planning to upgrade our k8s version and we got an alert regarding the PSP policy used by the kspm-collector. Would it be possible to update the PSP(Pod Security Policy) in the template to automatically enable PSA(Pod Security Admission) to the namespace, because since k8s upgrade to 1.25 PSP will be depreciated.
Ref: https://github.com/sysdiglabs/charts/blob/master/charts/kspm-collector/templates/psp.yaml#L2C1-L3C1
https://kubernetes.io/docs/reference/using-api/deprecation-guide/

If its already available. Can you guide me on the update?

Cheers,
Vikranth

Specifying runtimeScanner maxFileSizeAllowed as integer can result in failures

Summary

If users specify the nodeAnalyzer.runtimeScanner.settings.maxFileSizeAllowed setting as an integer, then the quote function sometimes converts it to a string correctly (for small numbers) or otherwise treats it as a floating-point number, which then causes the runtime scanner container to fail to start.

Current behavior

When maxFileSizeAllowed is given as an integer (rather than a string), an incorrect value appears in the resulting ConfigMap, which prevents the scanner from starting correctly.

Desired behavior

In both cases, the chart should be able to accept either a string or int64.

Steps to reproduce

  1. Use the following values file and save it somewhere as values.yaml:

    sysdig:
      accessKey: foo
    
    clusterName: foo
    
    nodeAnalyzer:
      deploy: true
      apiEndpoint: https://api.example.com
      runtimeScanner:
        deploy: true
        settings:
        maxFileSizeAllowed: 262144000
  2. Run helm template sysdig/sysdig --values=values.yaml (it likely also works when running locally against this repo, but I have not checked)

  3. Look at the output; for me, it looks like this:

    # Source: sysdig/templates/runtimeScanner/runtime-scanner-configmap.yaml
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: release-name-sysdig-runtime-scanner
      labels:
        helm.sh/chart: sysdig-1.15.87
        app.kubernetes.io/instance: release-name
        app.kubernetes.io/version: "12.14.0"
        app.kubernetes.io/managed-by: Helm
        app: "sysdig-agent"
    data:
      api_endpoint: https://https://api.example.com
      cluster_name: foo
      debug: "false"
      eve_integration_enabled: "true"
      prom_port: "25001"
      analyzer.maxFileSizeAllowed: "2.62144e+08"

You can also try changing the maxFileSizeAllowed to a smaller number, and then quote behaves as we expect:

# Source: sysdig/templates/runtimeScanner/runtime-scanner-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: release-name-sysdig-runtime-scanner
  labels:
    helm.sh/chart: sysdig-1.15.87
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "12.14.0"
    app.kubernetes.io/managed-by: Helm
    app: "sysdig-agent"
data:
  api_endpoint: https://https://api.example.com
  cluster_name: foo
  debug: "false"
  eve_integration_enabled: "true"
  prom_port: "25001"
  analyzer.maxFileSizeAllowed: "2621"

I also verified that it is possible to reproduce this with the new sysdig-deploy chart using this values file:

global:
  sysdig:
    accessKey: foo

agent:
  enabled: false

nodeAnalyzer:
  enabled: true
  clusterName: foo
  apiEndpoint: https://api.example.com
  secure:
    enabled: true
    vulnerabilityManagement:
      newEngineOnly: true
  nodeAnalyzer:
    enabled: true
    runtimeScanner:
      deploy: true
      settings:
        maxFileSizeAllowed: 2621121212

This is the output:

# Source: sysdig-deploy/charts/nodeAnalyzer/templates/runtimeScanner/runtime-scanner-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: sysdig-runtime-scanner
  labels:
    helm.sh/chart: nodeAnalyzer-1.8.50
    app.kubernetes.io/instance: sysdig
    app.kubernetes.io/version: "12.6.0"
    app.kubernetes.io/managed-by: Helm
data:
  api_endpoint: https://secure.sysdig.com
  cluster_name: foo
  debug: "false"
  eve_integration_enabled: "true"
  prom_port: "25001"
  analyzer.maxFileSizeAllowed: "2.621121212e+09"

Workaround

We can pass in this value as a string, as it is done in the Helm default values.

Other details

This chart passes things in through | quote but the value is being detected as a floating point number (understandable as that would be the default YAML and JSON behavior, since JSON treats everything as a float64):

{{- if .Values.nodeAnalyzer.runtimeScanner.settings.maxFileSizeAllowed }}

A possible solution may be to use one of Helm's type conversion functions to force it to be treated as an int64, but I don't know if that causes issues when values are passed in as a string: https://helm.sh/docs/chart_template_guide/function_list/#type-conversion-functions

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.