{"id":29215542,"url":"https://github.com/trendmicro/visionone-container-security-helm","last_synced_at":"2026-06-04T01:00:40.168Z","repository":{"id":299721032,"uuid":"960094569","full_name":"trendmicro/visionone-container-security-helm","owner":"trendmicro","description":null,"archived":false,"fork":false,"pushed_at":"2026-03-24T09:56:42.000Z","size":1944,"stargazers_count":2,"open_issues_count":2,"forks_count":5,"subscribers_count":2,"default_branch":"main","last_synced_at":"2026-04-01T13:42:08.558Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Mustache","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/trendmicro.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.pdf","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2025-04-03T21:10:20.000Z","updated_at":"2026-03-24T09:56:45.000Z","dependencies_parsed_at":"2025-06-18T01:25:26.566Z","dependency_job_id":"abdcefb4-4857-4a61-9657-1b364e112dba","html_url":"https://github.com/trendmicro/visionone-container-security-helm","commit_stats":null,"previous_names":["trendmicro/visionone-container-security-helm"],"tags_count":23,"template":false,"template_full_name":null,"purl":"pkg:github/trendmicro/visionone-container-security-helm","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/trendmicro%2Fvisionone-container-security-helm","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/trendmicro%2Fvisionone-container-security-helm/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/trendmicro%2Fvisionone-container-security-helm/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/trendmicro%2Fvisionone-container-security-helm/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/trendmicro","download_url":"https://codeload.github.com/trendmicro/visionone-container-security-helm/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/trendmicro%2Fvisionone-container-security-helm/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":33886153,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-03T02:00:06.370Z","response_time":59,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-07-03T00:33:07.121Z","updated_at":"2026-06-04T01:00:40.155Z","avatar_url":"https://github.com/trendmicro.png","language":"Mustache","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Trend Micro Vision One Container Security Helm Chart\n\n## Getting started\n\n### Upgrading from cloudone-container-security-helm\n\nIf you are upgrading from the [Trend Micro Cloud One Container Security Helm chart]([cloudone-container-security-helm](https://github.com/trendmicro/cloudone-container-security-helm)), please follow these [instructions](docs/upgrade-from-cloud-one-helm.md).\n\n### Installing Helm\n\nTrend Micro Vision One Container Security components use the `helm` package manager for Kubernetes.\n\nHelm 3 or later is supported when installing Trend Micro Vision One - Container Security components.\nTo get started, see the [Helm installation guide](https://helm.sh/docs/intro/install/).\n\n### Kubernetes Network Policies with Container Security Continuous Compliance\n\nContainer Security Continuous Compliance enforces policies by leveraging [Kubernetes network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) to perform isolation mitigation. Network policies are implemented by the [network plugin](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).\n\nTo install Container Security, a network plugin with NetworkPolicy support is required to allow for network isolation mitigation.\n\n- In Amazon Elastic Kubernetes Service (Amazon EKS), the [Calico network plugin](https://docs.aws.amazon.com/eks/latest/userguide/calico.html) can be used as network policy engine.\n- In OpenShift 4.x, [OpenShift SDN](https://docs.openshift.com/container-platform/4.7/networking/network_policy/about-network-policy.html) supports using network policy in its default network isolation mode.\n- In Azure Kubernetes Service (AKS), network policy are supported by [Azure Network Policies or Calico](https://docs.microsoft.com/en-us/azure/aks/use-network-policies).\n- In Google Kubernetes Engine (GKE), you could enable [network policy enforcement](https://cloud.google.com/kubernetes-engine/docs/how-to/network-policy) for a cluster.\n\n**Note**: If you are running Container Security in a **Red Hat OpenShift** environment, network isolation mitigation is only supported for pods whose security context is acceptable by oversight controller's SecurityContextConstraint.  If you want to let Container Security isolate pods that are not allowed by default, you can use overrides.yaml to override the default setting.\n\nBy default, Container Security Continuous Compliance will create a Kubernetes network policy on your behalf. If you want to create it manually, follow the steps below:\n1. Change the value of `visionOne.policyOperator.enableNetworkPolicyCreation` to `false`, as seen below:\n\n```\n  visionOne:\n    policyOperator:\n      enableNetworkPolicyCreation: false\n```\n\n2. Create a network policy with `matchLabels` set to `trendmicro-vision-one-container-security/isolate: true` in your desired namespaces.\n\n```\n  apiVersion: networking.k8s.io/v1\n  kind: NetworkPolicy\n  metadata:\n    labels:\n      app.kubernetes.io/instance: trendmicro\n    name: trendmicro-vision-one-container-security-isolate\n  spec:\n    podSelector:\n      matchLabels:\n        trendmicro-vision-one-container-security/isolate: \"true\"\n    policyTypes:\n    - Ingress\n    - Egress\n```\n\n**Warning**: The network policy with matchLabels `trendmicro-vision-one-container-security/isolate: true` must exist in each application namespaces in order to perform proper isolation mitigation.\n\n#### Automatic Revert of Isolation\n\nIsolation applied by continuous compliance is automatically reverted when the policy violation no longer applies. This change in evaluation result could be caused by the policy changing or being disabled. Isolation applied through other mechanisms such as XDR response actions is not automatically reverted.\n\n### Registering Cluster with Trend Micro Container Security\n\nTo use the Trend Micro Vision One Container Security components with your Kubernetes cluster, you must first register your cluster. There are two methods to register a cluster with Trend Micro Container Security:\n\n1. [**Manual Registration**](#getting-a-container-security-bootstrap-token): Create a cluster in the Trend Micro Container Security console and obtain a bootstrap token or use the Public API to create a cluster and obtain a bootstrap token.\n2. [**Automated Registration**](#using-automated-cluster-registration): Use the Vision One API key to automatically register all clusters with Trend Micro Container Security.\n\n### Getting a Container Security bootstrap token\n\nManually registered clusters use a bootstrap token to initiate communication with _Trend Micro Vision One Container Security_.\n\nTo obtain a bootstrap token:\n1. Navigate to the _Trend Micro Vision One Container Security_ console using https://portal.xdr.trendmicro.com/index.html#/app/server-cloud/container-inventory.\n\n2. Click on _+ Add Cluster_ under the Kubernetes section.\n\n3. Give your Kubernetes cluster a unique name.\n\n4. Copy your bootstrap token, as it will be used during the installation process.\n\n5. It is recommended to create an authentication secret as outlined in the [Use Existing Secrets for bootstrap token](#use-existing-secrets-for-bootstrap-token) section.\n\n### Use Existing Secrets for bootstrap token and Proxy Credentials\n\n#### Use Existing Secrets for bootstrap token\n\nBy default, the helm chart expects the bootstrap token to be provided through the `visionOne.bootstrapToken` helm value in the `overrides.yaml` file. This method creates an authentication secret in the same namespace where the Container Security components are installed but can expose the bootstrap token in helm values.\n\nIt is recommended to use the `useExistingSecrets.containerSecurityAuth: true` option and create a secret in the same namespace where the Container Security components will be installed. The secret should be named `trendmicro-container-security-bootstrap-token` with the key `bootstrap.token` set to the bootstrap token value. The bootstrap token expires after 24 hours, so you must have Container Security installed within that time frame.\n\n```sh\nkubectl create secret generic trendmicro-container-security-bootstrap-token --from-literal\nbootstrap.token=\u003ccontainer-security-bootstrap-token\u003e --namespace \u003ctrendmicro-namespace\u003e\n```\n\nThen, set the `useExistingSecrets.containerSecurityAuth: true` in the `overrides.yaml` file.\n```yaml\nuseExistingSecrets:\n  containerSecurityAuth: true\n```\n\n#### Use Existing Secrets for Proxy Credentials\n\nFor more details on configuring a proxy, see the [Configure Container Security to use a proxy](#configure-container-security-to-use-a-proxy) section.\n\nIf you are outbound proxy for the Container Security components, you can also set the `useExistingSecrets.outboundProxy: true` in the `overrides.yaml` file and create a secret in the same namespace as chart installation. The secret should be named `trendmicro-container-security-outbound-proxy-credentials`. For secret format, see the [Proxy Credentials Secret Template](./templates/outbound-proxy.yaml).\n\n### Using automated cluster registration\n\nTrend Vision One Container Security users can configure automated cluster registration\nto automate the management of cluster lifecycle. This feature enables clusters to be automatically registered clusters with Trend Vision One Container Security when the Container Security is installed and unregistered when the Container Security is uninstalled. This also allows users to register multiple clusters with a single Vision One API key instead of manually registering each cluster.\n\nTo use automated cluster registration:\n1. Navigate to the _Trend Micro Vision One_ console using https://portal.xdr.trendmicro.com/\n\n2. Create a Vision One API Key with a role that contains only the \"Automatically register cluster\" permission\n\n3. Put the Vision One API Key into a secret called `trendmicro-container-security-registration-key` with the key `registration.key` in the same namespace where the Container Security components are installed.\n\n4. Install the Container Security Helm chart using the values `visionOne.clusterRegistrationKey: true` and `visionOne.groupId=\u003cyour cluster group ID\u003e`. You can optionally define the cluster name by setting either `visionOne.clusterName` or `visionOne.clusterNamePrefix`, if these are not specified the name will be a random string. An existing policy can also be assigned to the cluster by setting `visionOne.policyId=\u003cyour policy ID\u003e`.\n\n### Override configuration defaults\n\nHelm uses a file called `values.yaml` to set configuration defaults. You can find detailed documentation for each of the configuration options in this file.\n\nYou can override the defaults in this file by creating an `overrides.yaml` file and providing the location of this file as input during installation. The `visionOne.bootstrapToken` should be overridden in the `overrides.yaml` file.\n\n**Note**: If you create a file to override the values, make sure to copy the structure from the chart's `values.yaml` file. You only need to provide the values that you are overriding.\n\n### Installing the Container Security Helm chart\n\n1. Create a file called overrides.yaml that will contain your cluster-specific settings. You can find these values in the Container Security console or Container Security API when creating a cluster. The [Values.yaml](values.yaml) file can be used as a reference when creating your overrides file.\n\n2. Use `helm` to install Container Security components with your cluster-specific settings. We recommend that you run Container Security in its own namespace.\n\nTo install Container Security chart into an existing Kubernetes namespace, use the `--namespace` flag with the `helm install` command:\n\n```sh\n  helm install \\\n    --values overrides.yaml \\\n    --namespace ${namespace} \\\n    trendmicro \\\n    https://github.com/trendmicro/visionone-container-security-helm/archive/main.tar.gz\n```\n\nIn the example below, we create a new namespace by using `helm`'s `--create-namespace` option:\n\n```sh\n  helm install \\\n    --values overrides.yaml \\\n    --namespace trendmicro-system \\\n    --create-namespace \\\n    trendmicro \\\n    https://github.com/trendmicro/visionone-container-security-helm/archive/main.tar.gz\n```\n\nFor more information about `helm install`, see the [Helm installation documentation](https://helm.sh/docs/helm/helm_install/).\n\n**Note**: If you are running Container Security in a pure **AWS EKS Fargate** environment, you may need to adjust your Fargate profile to allow pods in a non-default namespace (ex: `trendmicro-system`) to be scheduled. See [AWS documentation](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html) for more information on Fargate profiles.\n\n**Note**: If you are running Container Security in a **Red Hat OpenShift** environment, the Helm Chart creates a [Security Context Constraint](https://docs.openshift.com/container-platform/4.7/authentication/managing-security-context-constraints.html) to allow Container Security components to have the minimum security context requirements to run.\n\n**Note**: If you are running Container Security in a cluster where Pod Security Admission is available and you have runtime security enabled, ensure the namespace where Container Security is installed is using the [privileged Pod Security Standards policy](https://kubernetes.io/docs/concepts/security/pod-security-standards/#privileged).\n\n### Upgrade a Trend Micro Vision One Container Security deployment\n\nTo upgrade an existing installation in the default Kubernetes namespace to the latest version:\n\n```sh\n  helm upgrade \\\n    --values overrides.yaml \\\n    --namespace ${namespace} \\\n    trendmicro \\\n    https://github.com/trendmicro/visionone-container-security-helm/archive/main.tar.gz\n```\n\n**Note**: Helm will override or reset values in `overrides.yaml`. If you want to use the values you had previously, use the [--reuse-values](https://helm.sh/docs/helm/helm_upgrade/) option during a Helm upgrade:\n\n```sh\n  helm upgrade \\\n    --namespace ${namespace} \\\n    --reuse-values \\\n    trendmicro \\\n    https://github.com/trendmicro/visionone-container-security-helm/archive/main.tar.gz\n```\n\n### Uninstall the Container Security Helm chart\n\nYou can delete all of the resources created by a helm chart using Helm's `uninstall` command:\n\n**Warning**: `helm uninstall` and `kubectl delete namespace` are destructive commands, and will delete all of the associated resources.\n\n```sh\n  helm uninstall trendmicro --namespace ${namespace}\n```\n\nUse the `helm list --all-namespaces` command to list installed releases in all namespaces.\n\nIf you created a `trendmicro-system` namespace during install, and don't have any other components in the `trendmicro-system` namespace, you can delete the namespace by running `kubectl delete namespace trendmicro-system`.\n\nBy default, Container Security Continuous Compliance will create a Kubernetes network policy for you. The created network policies will be cleaned up, even if the chart is uninstalled. To clean them up, run:\n\n```sh\n  kubectl delete networkpolicy -l app.kubernetes.io/instance=trendmicro --all-namespaces\n```\n\n**Warning**: If you have running Pods that are isolated by a network policy, removing the network policy will give them network access again.\n\n## Documentation\n\n- [Trend Micro Vision One Container Security Documentation](https://docs.trendmicro.com/en-us/documentation/article/trend-vision-one-container-security)\n\n## Advanced topics\n\n### Install a specific version of the Container Security helm chart\n\nIf you want to install a specific version you can use the archive link for the tagged release. For example, to install Trend Micro Vision One Container Security helm chart version 3.3.9, run the following command:\n\n```sh\n  helm install \\\n    --values overrides.yaml \\\n    --namespace ${namespace} \\\n    --create-namespace \\\n    trendmicro \\\n    https://github.com/trendmicro/visionone-container-security-helm/archive/3.3.9.tar.gz\n```\n\n### Enabling or disabling a specific component\n\nIf desired, specifics components of the Container Security helm chart can be enabled or disabled individually using an overrides file.\nFor example, you can choose to enable the runtime security component by including the below in your `overrides.yaml` file:\n```yaml\n  visionOne:\n    runtimeSecurity:\n      enabled: true\n```\n\n### Managing Container Security policies with Policy as Code\n\nTo learn more about managing Container Security policies with custom resources and policy operator, see the [Policy as Code documentation](./docs/policy-as-code.md).\n\n### Configure Container Security to use a proxy\n\nYou can configure Container Security to use either a socks5 proxy or http proxy by setting the `httpsProxy` value.\nFor example, you can configure a socks5 proxy with authentication in your `overrides.yaml` file this way:\n```\nproxy:\n  httpsProxy: socks5://10.10.10.10:1080\n  username: user\n  password: password\n```\n\nFor http proxy, you can configure it this way:\n```\nproxy:\n  httpsProxy: http://10.10.10.10:3128\n  username: user\n  password: password\n```\n\n### Runtime vulnerability scanning for OpenShift\n\nOn OpenShift, new namespaces created after installing container security need to be configured by upgrading container security to create RBAC resources and provide scanners in the new namespaces the required privileges.\n\nWhen uninstalling the Trend Micro Helm chart, the associated **ServiceAccounts** and **ClusterRoleBindings** used to assign security context constraints to scanner pods will also be removed. To uninstall, run:\n\n```sh\nhelm uninstall trendmicro -n trendmicro-system\n```\n\n***Troubleshooting Installation Issues***: If you encounter an error preventing the uninstallation of the Helm chart, run the following cleanup script to ensure all remaining resources are removed, run the following script with admin privileges:\n\n```sh\n./scripts/openshift-cleanup.sh\n```\nAfter running the script, proceed with the Helm uninstall as usual.\n\n### Enabling scout hostNetwork on OpenShift\n\nOn OpenShift clusters with SELinux enforcing, the scout component requires `hostNetwork: true` to function properly. Without host networking, the pod runs under a strict SELinux label (e.g., `container_t`), which prevents scout from reading `/proc/\u003cpid\u003e/exe` of the falco process within the same pod. This causes scout to fail with the error:\n\n```\n\"error\":\"failed to apply the policy and rule, falco service is not found\"\n```\n\nStarting from chart version 3.3.6, `hostNetwork` is configurable and defaults to `false`. If you are deploying on OpenShift, add the following to your `overrides.yaml` file:\n\n```yaml\nscout:\n  hostNetwork: true\n```\n\n**Note**: This issue only affects OpenShift environments with SELinux in enforcing mode. Other platforms (EKS, GKE, AKS, vanilla Kubernetes) are not affected and can use the default `hostNetwork: false`.\n\n### Enable FIPS mode for container security\n\nIf you are running Container Security in an environment that requires [FIPS 140](https://csrc.nist.gov/projects/cryptographic-module-validation-program) compliance (for example, U.S. federal workloads or Red Hat OpenShift clusters installed in FIPS mode), you can enable FIPS mode to have Container Security pull FIPS-compliant variants of its container images.\n\nTo enable FIPS mode, add the following to your `overrides.yaml` file:\n\n```yaml\nvisionOne:\n  fipsMode:\n    enabled: true\n```\n\n**Note**: Only enable FIPS mode if your cluster nodes and the container runtime are themselves configured for FIPS compliance. Enabling FIPS mode on a non-FIPS cluster will result in runtime errors due to incompatibilties in fips crypto.\n\n### Enable runtime security on AWS bottlerocket\n\nYou can run runtime security on AWS bottlerocket nodes by adding these configurations in your `overrides.yaml` file:\n```yaml\nsecurityContext:\n  scout:\n    scout:\n      allowPrivilegeEscalation: true\n      privileged: true\n```\n\n### Configure Runtime Container Interface\n\nYou can configure Container Security to customize container runtime interface.\nFor example, you can specify a custom path:\n\n```\nscout:\n  falco:\n    cri:\n      socket: \"/run/cri/containerd.sock\"\n```\n\nYou can also configure a custom path for k0s or k3s. For example:\n\n```\nscout:\n  falco:\n    k0s:\n      socket: \"/run/k0s/containerd.sock\"\n```\n\n### Add capabilities to runtime vulnerability scanner\n\nRuntime vulnerability scanner needs the privilege to access all directories and files in an image. `DAC_READ_SEARCH` is needed when the file permissions do not allow scanner to access the files or directories in an image. In this case, you can add `DAC_READ_SEARCH` to the `scanner`'s capabilities\n\n```\nsecurityContext:\n  scanner:\n    target:\n      capabilities:\n        add: [\"DAC_READ_SEARCH\"]\n```\n\n### Configure node selectors and tolerations for the Container Security components\n\nTo configure the scheduling of the Container Security components, you can set the `nodeSelector` and `tolerations` values in your `overrides.yaml` file:\n```yaml\nnodeSelector:\n  defaults: # Node selector applied to all components except those with specific node selectors below\n    kubernetes.io/arch: arm64\n\n  admissionController: # Node selector applied to specific component\n    kubernetes.io/arch: amd64\n\ntolerations:\n  defaults: # Tolerations applied to all components except those with specific tolerations below\n  - key: kubernetes.io/arch\n    operator: Equal\n    value: amd64\n    effect: NoSchedule\n\n  admissionController: # Tolerations applied to specific component\n  - key: kubernetes.io/os\n    operator: Exists\n    effect: NoSchedule\n```\n\nFor scanner pods you have two options for configuring node selectors and tolerations:\n1) Set the `nodeSelector` and `tolerations` values in your `overrides.yaml` file similar to the other components as mentioned above. For example:\n```yaml\nnodeSelector:\n  defaults: # Node selector applied to all components except scanner pods\n    kubernetes.io/arch: arm64\n\n  scanner: # Node selector applied to the scanner pods\n    kubernetes.io/arch: amd64\n\ntolerations:\n  defaults: # Tolerations applied to all components except scanner pods \n  - key: kubernetes.io/arch\n    operator: Equal\n    value: amd64\n    effect: NoSchedule\n\n  scanner: # Tolerations applied to the scanner pods\n  - key: kubernetes.io/os\n    operator: Exists\n    effect: NoSchedule\n```\n2) Inherit node selectors and tolerations - Since they run images from the pods being scanned, you can configure the scanner to inherit the node selectors and tolerations from the owner resource (ie. deployment, daemonset, pod, etc.):\n```yaml\nnodeSelector:\n  inheritNodeSelectorScanner: true # Inherit node selector from the owner resource (default: false)\n\n  filterNodeSelectorScanner: # Only inherit node selector specified in the filter (default: all node selectors are inherited)\n    kubernetes.io/arch: amd64\n\ntolerations:\n  inheritTolerationsScanner: true # Inherit tolerations from the owner resource (default: false)\n\n  filterTolerationsScanner: # Only inherit tolerations specified in the filter (default: all tolerations are inherited)\n  - key: kubernetes.io/arch\n    operator: Equal\n    value: amd64\n    effect: NoSchedule\n```\n\n\n### Configuring logging for the Container Security components\n\nYou can configure the logging for all components by setting the `logConfig` value in your `overrides.yaml` file:\n\n```yaml\nlogConfig:\n  logLevel: info # Sets the log verbosity level. Supported values are debug, info, and error. Overrides the logLevel set for each component\n  logFormat: json # Sets the log encoder. Supported values are json and console\n  stackTraceLevel: error # Sets the level above which stacktraces are captured. Supported values are info, error or panic\n  timeEncoding: rfc3339 # Sets the time encoding format. Supported values are epoch, millis, nano, iso8601, rfc3339 or rfc3339nano\n```\n\nYou can also configure the log level for each component individually by setting the `logLevel` value for the component in your `overrides.yaml` file:\n\n```yaml\nvisionOne:\n  admissionController:\n    logLevel: debug\n```\n\n### Configuring access to private registries for image signature verification deployment rules\n\nTo verify signatures for images stored in private registries, the admission controller requires access to the registry through imagePullSecrets to retrieve and verify the signature bundles.\nWe provide two options for specifying the source of the required imagePullSecrets:\n1) **readPullSecretsFrom:** `trendMicroNamespace` (default) - Create the imagePullSecrets manually in the trendmicro namespace (trendmicro-system). The admission controller directly reads these secrets from its own namespace and does not need any extra privileges into other namespaces for signature verification using this option. Note that signature verification will fail if the necessary imagePullSecrets are not created.\nHere is a kubectl command to create an example imagePullSecret named regcred in the trendmicro-system namespace:\n```bash\nkubectl create secret docker-registry regcred --docker-server=\u003cyour-registry-server\u003e --docker-username=\u003cyour-name\u003e --docker-password=\u003cyour-password\u003e --namespace=trendmicro-system\n```\n2) **readPullSecretsFrom:** `customerNamespace` - Grants access to the admission controller to read the imagePullSecrets directly from the image deployment namespace. During deployment, the admission controller will look for the imagePullSecret reference in the pod specification (reference directly defined in the pod specification or automatically injected by a service account) and get the secret into the trendmicro namespace for signature verification. The admission controller only accesses secrets referenced by the image currently being deployed and discards them after rule evaluation.\n\nTo configure the options, you can set the `readPullSecretsFrom` value in your `overrides.yaml` to either `trendMicroNamespace` or `customerNamespace` as follows:\n```yaml\nadmissionController:\n  readPullSecretsFrom: trendMicroNamespace # or customerNamespace\n```\n\n### Configuring Falco event outputs\n\nYou can enable Falco event outputs to stdout or syslog by setting values under `scout.falco` in your `overrides.yaml` file:\n\n```yaml\nscout:\n  falco:\n    stdout_enabled: true # Enable stdout output for Falco events.\n    syslog_enabled: true # Enable syslog output for Falco events\n```\n\nNote: Enabling stdout output will cause large amounts of logs to be generated. Enable these if the events are being consumed from the respective channel. Container security will only consume the events from the grpc channel.\n\n### Falco event outputs sensitive data redaction\n\nTo hide sensitive fields for runtime security events, add `scout.falco.sanitizer_output` to the `overrides.yaml` file.\nThe `scout.falco.sanitizer_output.patterns` field uses the key-value pairs that have a Falco event field as the key and a regular expression as the value. Note the regular expression shall follow pcre2 syntax.\n(See [the fields supported by Falco](https://falco.org/docs/reference/rules/supported-fields/) for more information.) The regular expression determines if the string matching the pattern should be hidden in the event output. The redaction occurs in both output and output_fields in a Falco event. For example:\n\n```yaml\nscout:\n    falco:\n        sanitizer_output:\n            enabled: true\n            patterns:\n                proc.pcmdline: (?\u003c=--password\\s)\\s?(\\S+)\n                fd.sip: (?\u003c=169\\.254\\.)(\\S+)\n```\n\nIn your Falco event and V1CS UI you will see:\n\n```\nproc.pcmdline=sampleProgram --password ********\n```\n\n### Configuring OCI repository artifacts for Falco Custom Rules\n\nTo learn more about configuring OCI repository artifacts for falco custom rules, see the OCI repo docs [here](./docs/oci-artifact-with-falcoctl.md).\nNote that this feature is subject to breaking changes in the future.\n\n### Least Privileged mode\n\nFalco runs in full privileged mode by default. For the sake of security, you can enable `least_privileged` to make Falco to run in the least privileged mode. In this case, Falco will be non-privileged container with minimum capabilities added.\n\n```yaml\nscout:\n  falco:\n    least_privileged: true\n```\n\n### Argo CD Uninstallation Guide\n\nFor Argo CD deployments, we provide a cleanup script to help with the uninstallation process. We recommend running this script during or after uninstallation to ensure complete removal of all components.\n\nFor detailed instructions on using the Argo CD cleanup script, please refer to the [Argo CD cleanup script documentation](./scripts/argocd-cleanup.md).\n\n## Falco Version Matrix\n\nThe following matrix shows the Falco version that is bundled with each Helm chart version:\n\n| **Helm Chart Version** | **Falco Version** |\n|------------------------|-------------------|\n| 3.1.x                  | 0.39.2            |\n| 3.0.x                  | 0.39.2            |\n\n## Troubleshooting\n\n### Access logs\nMost issues can be investigated using the application logs. The logs can be accessed using `kubectl`.\n\n* Access the logs for the admission controller using the following command:\n```sh\n  kubectl logs deployment/trendmicro-admission-controller --namespace ${namespace}\n```\n\n* Access the logs for the runtime security component using the following command, where container can be one of `scout`, or `falco`:\n```sh\n  kubectl logs daemonset/trendmicro-scout --namespace ${namespace} -c ${container}\n```\n\n* Access the logs for Oversight controller (Continuous Compliance policy enforcement) using the following command:\n```sh\n  kubectl logs deployment/trendmicro-oversight-controller --namespace ${namespace}\n```\n\n### Collect support logs\nTo help debug issues reported in support cases, a log collection script is provided for customer use.\n\nTo enable debug logging, set the `logConfig.logLevel` to `debug` in the `overrides.yaml` file and upgrade the helm chart.\n```yaml\nlogConfig:\n  logLevel: debug\n```\n\nGather logs using the following command:\n\n```sh\n./scripts/collect-logs.sh\n```\n\nThe following environment variables are supported for log collection:\n\n| Environment variable      | Description                             | Default                                                                                        |\n| ------------------------- |:----------------------------------------|:-----------------------------------------------------------------------------------------------|\n| RELEASE                   | Helm release name                       | `trendmicro`                                                                         |\n| NAMESPACE                 | The namespace that the helm chart is deployed in | Current namespace declared in `kubeconfig`. If no namespace setting exists in `kubeconfig`, then `trendmicro-system` will be used. |\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftrendmicro%2Fvisionone-container-security-helm","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftrendmicro%2Fvisionone-container-security-helm","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftrendmicro%2Fvisionone-container-security-helm/lists"}