[{"id":0,"title":"Sysdig Agent Release Notes 2024","content":"13.7.1 December 31, 2024 Supported sysdig-deploy version: 1.72.7 Supported Falco Engine version: 1000.36.0 Vulnerability FixesThis hotfix addresses the following security vulnerabilities:\nCVE-2024-51744 CVE-2024-45337 CVE-2024-12254 CVE-2024-9287 Defect fixes Fixed an issue where processes attempting to open or write malicious files were not terminated when prevention was enabled. 13.7.0 December 05, 2024 Supported sysdig-deploy version: 1.70.0 Supported Falco Engine version: 1000.36.0 EnhancementsAgent Capture Resource LimitThe agent monitors memory usage during capture operations and will automatically stop the capture if it nears the configured memory limit to improve resiliency.\nVulnerability Fixes CVE-2024-10963 CVE-2024-34155 CVE-2024-34156 CVE-2024-34158 CVE-2024-3596 CVE-2021-23336 CVE-2024-0450 CVE-2024-11168 CVE-2024-2236 CVE-2024-26462 CVE-2024-50602 CVE-2024-6232 CVE-2024-8088 CVE-2021-3903 CVE-2024-2511 CVE-2024-26458 CVE-2024-26461 CVE-2024-4032 CVE-2024-4603 CVE-2024-4741 CVE-2024-5535 Defect FixesFixed Empty Metrics MessagesResolved an issue where metrics messages were sent before the event source was fully initialized. The agent now waits for the event source to start, preventing empty driver types from being sent to the backend.\nImproved the Connection Reliability of the AgentIf the agent detects a communication problem with the backend, it will now drop the connection and attempt to reconnect instead of restarting the entire agent process. This improves stability and reduces downtime.\n13.6.1 November 18, 2024 Supported sysdig-deploy version: 1.68.0 Supported Falco Engine version: 1000.35.0 Defect Fixes A dependency for the php-fpm app check had been unintentionally omitted and has now been restored, permitting the check to work as intended. The agent container image now uses the same version of Python as the agent-slim and agent-slim-fips container images. 13.6.0 November 13, 2024 Supported Falco Engine version: 1000.35.0 EnhancementsDefault Availability of Falco HashingThe hash enrichment functionality is now enabled by default. The Agent will attempt computing a SHA256 hash for every binary executed in the system, and will attach it to the policy events.\nYou can disable the feature by setting hash_detection.enabled: false in the agent configuration.\nFIPS Compliance SupportA fully FIPS-compliant version of the Sysdig Linux Agent is now available and will be included in all the new agent releases. This option is intended for users who require strict FIPS compliance.\nFor more information, see FIPS Compliance.\nConsiderationsPreviously, a FIPS mode was available that could be enabled within the standard agent. However, for full FIPS compliance, we recommend transitioning to the new FIPS-compliant images and packages.\nThe app_checks support is currently not supported when the agent is running in FIPS mode or in with the new FIPS images and packages.\nImproved Agent ConnectionFixed a defect to enhance the agent\u0026rsquo;s ability to detect communication issues and initiate repair without requiring a restart.\nVulnerability Fixes CVE-2023-48161 CVE-2024-21208 CVE-2024-21210 CVE-2024-21217 CVE-2024-21235 Known IssuesThe php-fpm app check does not work due to a missing dependency. You can disable the feature by adding the following snippet in the agent configuration:\napp_checks: - name: php-fpm enabled: false 13.5.0 October 29, 2024 Supported sysdig-deploy version: 1.67.0 Supported Falco Engine version: 1000.32.0 Vulnerability Fixes CVE-2024-45492 CVE-2024-45491 CVE-2024-45490 CVE-2024-43168 CVE-2024-43167 CVE-2024-33655 CVE-2024-28835 CVE-2024-28834 CVE-2024-8508 CVE-2024-8260 CVE-2024-6119 CVE-2024-1931 CVE-2024-0727 CVE-2024-0567 CVE-2024-0553 CVE-2023-6237 CVE-2023-6129 CVE-2023-5981 CVE-2023-5678 CVE-2023-5363 CVE-2023-3817 CVE-2023-3446 CVE-2023-2975 CVE-2022-33070 Defect FixesFixed Brief Data Loss in Multi-Thread ProcessesFixed an issue where processes which spawn a large number of threads might briefly lose metadata.\nBetter handling of malformed capture requestsThe agent now gracefully handles malformed capture requests, preventing unnecessary restarts and ensuring smoother performance.\nFixed the Ability to Add Cloud Metadata in all AWS RegionsThe agent can successfully add cloud metadata to EC2 Instances in all AWS locations, regardless of the HTTP version used by the IMDS server.\nImproved LogsIf the agent fails to initialize the system inspector, the exception message is logged to both stderr and the system log.\nAbility to Report File WritesThe agent now correctly reports file writes from shell built-in commands and redirects output files as interactive in Activity Audit.\nFixed Dependency Issue in IPv6 SystemsUpdated a dependency to ensure seamless connectivity between the Sysdig Agent and the Sysdig Backend in IPv6-only environments.\n13.4.1 September 18, 2024 Supported sysdig-deploy version: 1.65.4 Supported Falco Engine version: 1000.29.0 Vulnerability FixesThis hotfix addresses the following security vulnerabilities:\nCVE-2024-37371 CVE-2024-37370 CVE-2024-34397 CVE-2024-24791 CVE-2024-6923 In addition to these, we have also addressed other minor vulnerabilities in this release.\nDefect fixesThe native package now lists some required Linux utilities as dependencies.\n13.4.0 September 04, 2024 Supported sysdig-deploy version: 1.64.0 Supported Falco Engine version: 1000.29.0 EnhancementsHost Shield Technical Preview for KubernetesIntroducing Host Shield Technical Preview for Kubernetes! Host Shield simplifies the deployment, management, and configuration of Sysdig security tools by consolidating components such as Host Scanner, KSPM Analyzer, and Rapid Response into Host Shield. For this preview, Sysdig uses the existing sysdig-deploy Helm chart, with plans to release a simplified chart in the coming months.\nSee Host Shield (Technical Preview) for more information.\nVulnerability Fixes CVE-2024-41110 CVE-2024-6345 CVE-2024-2398 Defect FixesEnable Operation in IPv6-Only EnvironmentsAn issue preventing DNS resolution from choosing the correct IPv6 address in IPv6-only environments has been fixed. The agent is now capable of connecting as expected in environments with no IPv4 stack.\nDisplay AWS EC2 Hosts in RisksThe agent can now successfully add cloud metadata to deployments in all the AWS regions, regardless of the HTTP version used in the IMDS server.\nAbility to Report UDP Connections in Secure Light ModeAn agent running in Secure Light mode can now report UDP connections correctly when reporting networking activity under Audit Tap and Secure Audit features.\nFixed Container Metrics CalculationFixed the memory calculations for the containers with multiple cgroup controllers. This correction also resolved issues with the container metrics calculation for the sysdig_container_memory_used_bytes metric.\nFixed Workload Name and Type for Pods Created by CronJobsFixed a defect pertaining to kube_pod_info metric reporting incorrect workload for cronJobs.\nFixed a Defect in RHEL 9 EnvironmentsRHEL 9.4 backported a commit, which might cause misbehaviours with the agent kernel module. Sysdig added a fix that provides an alternative method to extract the necessary information from the kernel module without relying on the affected commit.\nFixed Reporting False Spikes in Container CPU UsageResolved an issue where false CPU spikes were incorrectly reported.\n13.3.3 August 07, 2024 Supported sysdig-deploy version: 1.61.10 Supported Falco Engine version: 1000.28.0 EnhancementsAdded Reference Field for Correlating Policy and Audit Events with UUIDAdded the reference field in Policy and Audit events containing a UUID for correlating the events exported by the Sysdig Agent with the ones exposed by the Sysdig backend.\nAdded Kubernetes Metadata to Audit EventsAgent now adds Kubernetes cluster and host name labels to Audit events, even if the events are not associated with Pods. Previously, the agent added these labels only to events generated from Pods. Now, the agent includes them in all events generated from a host that is also a Kubernetes node. With this automatic node-level event enrichment, you can quickly and easily ascertain where in the cluster a host-level event took place.\n13.3.2 July 25, 2024 Supported sysdig-deploy version: 1.61.1 Supported Falco Engine version: 1000.28.0 Enhancements The kernel module has been updated to support Linux kernel version 6.10 Defect Fixes Fixed a defect that prevented the agent service to automatically start after an upgrade Fixed overlayfs issues on latest Red Hat Enterprise Linux (RHEL) Linux kernel that includes a patch from the newest version of the kernel 13.3.1 July 11, 2024 Supported sysdig-deploy version: 1.59.7 Supported Falco Engine version: 1000.28.0 This hotfix aims to improve the Linux Agent stability in some specific scenarios.\n13.3.0 July 03, 2024 If you are a Sysdig Secure user, skip v13.3.0 and upgrade to Sysdig Agent v13.3.1.\nSupported sysdig-deploy version: 1.58.0 Supported Falco Engine version: 1000.28.0 EnhancementsUniversal eBPF Is Generally AvailableUniversal eBPF is now GA, offering improved agent portability and simplified installation. It provides with single probe for all Linux kernels v5.8 and above shipped with the agent.\nAdded EulerOS SupportYou can now install the Sysdig Agent on EulerOS servers on Huawei Cloud. Currently, only docker installation is supported.\nImproved Resource Consumption for Loaded Threat Detection RulesThis new version of the agent reduces run-time memory usage for the loaded Threat Detection rules.\nLeast Privileged AgentSysdig Agent can now run in Kubernetes with securityContext.privileged set to false. This option is available through the sysdig-deploy Helm chart, specifying agent.privileged=false.\nKnown limitations:\nCompatible with eBPF drivers only. Not compatible with ARM Bottlerocket. For more information, see Manage Agent Privileges.\nSupport for Case-Insensitive Field ComparisonSupport to case-insensitive field comparison in threat detection rules is available through the tolower and toupper field transformers. For example, tolower(proc.name) = cat and toupper(proc.name) != toupper(proc.pname).\nUse IMDSv2 the Default Option for AWS Metadata RetrievalThe agent will now default to using the more secure IMDSv2 API for retrieving AWS metadata. Set imds_version: 1 in the agent configuration file to continue with the legacy behavior.\nCorrelate Dynamic Values in Threat Detection RulesAgent now supports comparing two fields in a rule to correlate the field with a dynamic value. For example:\nnot evt.arg.name startswith val(proc.cwd) This condition expect the value of evt.arg.name to not begin with the value output of proc.cwd, prior to this release, the comparison was a static value.\nAbility to Filter Invalid UTF-8 Characters in the Audit MessageThe agent will now filter out invalid UTF-8 characters from the \u0026ldquo;comm\u0026rdquo; and \u0026ldquo;cmdline\u0026rdquo; fields in the Audit message.\nSupport for base64-Decoding of Falco FieldsAdded support for base64 decoding of Falco fields. For example, b64(fd.name) contains cat.\nDefect FixesVulnerability Fixes CVE-2024-24790 CVE-2024-24789 CVE-2024-6104 CVE-2023-40577 Fixed Native Agent Installation Failure in Ubuntu 24.04 LTSIn the case of a native installation on Ubuntu 24.04 LTS using the legacy eBPF driver, the agent would not start. The issue has now been fixed.\nFixed Agent Installation Failure on Certain Hosts with No Boot Directory or with Kernel ConfigurationIn native install, building kernel module didn\u0026rsquo;t fail if it already exists but kernel configuration isn\u0026rsquo;t available. sysdigcloud-probe-loader script will now search for kernel configuration only when the kernel module has to be built or downloaded.\nAdded Fields Operators CheckThe agent now performs static checks while loading Threat Detection rules to ascertain the compatibility of the fields and operators used in the checks.\nDropped Curl Requirement for Universal eBPF and Native Linux InstallsOn a native installation using Universal eBPF, the agent would refuse to start unless curl is installed. This requirement has been dropped.\nDisplay Kubernetes Network Policies CorrectlyThis version fixes the agent to correctly send the Kubernetes cluster network policies so they can be shown in the network security UI.\nContainer Drift Works as Expected after Container RestartWhen cluster scoping predicate is used, Sysdig Agent might skip applying policies on container restarts. This fix closes that gap and ensures that the policies take effect upon changes in container state.\nDisplay Secure Network Objects with Correct NamespaceThis version attaches the correct Kubernetes namespace labels so UI can display network objects with the right namespaces.\nAbility to Filter Invalid UTF-8 CharactersThe agent will now filter out invalid UTF-8 characters from policy event messages.\nImproved Time ResolutionThe agent can now detect multiple changes to the configuration files in a second, down to the time resolution used by the filesystem.\n13.2.1 June 11, 2024 Supported sysdig-deploy version: 1.56.3 Supported Falco Engine version: 1000.26.0 This hotfix addressed the following:\nLoading policies is now faster and uses less resources up to 10x speedup is expected, with reduced memory usage\nFixed a defect that caused dns event to be raised even if there wasn\u0026rsquo;t a rule to match that event\nFixed a race condition that could lead to closing short-lived file descriptors.\nVulnerability fixes:\nCVE-2024-33602 CVE-2024-33601 CVE-2024-33600 CVE-2024-33599 CVE-2024-32487 CVE-2024-28182 CVE-2024-2961 13.2.0 May 21, 2024 Supported sysdig-deploy version: 1.53.0 Supported Falco Engine version: 1000.25.0 EnhancementsSuse Linux Enterprise Server SupportYou can now install the Sysdig Agent on SLES 12 and SLES 15.\nSLES12 only supports the kernel module driver\nIf you want to enable legacy eBPF on an x86_64-based SLES15 Server, install clang manually using SUSEConnect:\nSUSEConnect --product PackageHub/15.5/x86_64\nSupport for Adding Labels to JMX MetricsAdded support for labels on JMX metrics collected by the agent. For more information, see Collect JMX Labels.\nDefect FixesFixed a Race Condition in Universal eBPFDue to a kernel defect on x86 machines prior to versions 6.8, a page fault occurred when the agent tried to access the VSYSCALL address range using the bpf_probe_read_kernel method. The issue occurred in universal eBPF due to a race condition in the accept/accept4 syscalls. In eBPF, locks cannot be used, and therefore, under some circumstances, race conditions could happen.\nThis agent release provides a fix to avoid race conditions in these syscalls.\nFixed Debian Package UpgradeOn debian-based native installations, upgrading from an older version might result in the agent packages being accidentally marked as unneeded dependencies and subsequently uninstalled by autoremove. This issue has been fixed.\nFixed Metadata Requests in Proxy EnvironmentsWhen the agent had the http_proxy environment, obtaining the instance information for machines running in AWS, Azure, or GCP did not work. This issue has been fixed.\nRPM Install Honors CPU QuotaFixed the issue where RPM installation was not honoring the CPU quota for subprocess_resource_limits.\nFixed Limit Settings for Subprocess ResourcesFixed the issue where the subprocess_resource_limits setting was not working for some distro with cgroup v2.\n13.1.1 May 08, 2024 Supported sysdig-deploy version: 1.52.4 Supported Falco Engine version: 1000.24.0 This hotfix addresses the following:\nVulnerability fixes: CVE-2024-24557 CVE-2023-45288 EnhancementsSupport for Malware Detection and PreventionMalware Detection and Prevention is now available in Technical Preview for Hosts and Containers.\nDetection and Prevention is enabled by default for Containers.\nDetection is enabled by default for Hosts, but Prevention is disabled by default for Hosts. To enable Prevention for Hosts, use this configuration:\nprotections: malware_control: enable_detection_on_host: true enable_prevention_on_host: true For more information, see Malware Detection.\nOn-Demand Security Policy LoadingThe agent now requests security policies only on start, or if the security policies are modified on the Sysdig backend. This should result in a significant reduction in network bandwidth consumption, while also reducing the performance impact of periodically updating security policies.\nDefect FixesAdded Flatcar Support in Legacy eBPF ModeIn earlier versions, the legacy eBPF driver failed to compile on recent 6.8 kernels for Flatcar Container Linux. This issue has now been fixed.\n13.1.0 April 19, 2024 Supported sysdig-deploy version: 1.51.0 Supported Falco Engine version: 1000.24.0 EnhancementsActivity Audit Support for Network and File Activity in Secure Light ModeSysdig Agent configured in secure_light mode will now support tracking network and file activity as part of the Activity Audit feature, in addition to the existing monitoring of command line activity.\nNative Package enhancementsNative package installation has undergone a major revamping resulting in the following changes.\nSwitched supervisor from SysV to systemdThe agent now runs through a systemd service unit as opposed to a SysV init script.\nFine-grained packages depending on the driverDepending on the driver you intend to use (kmod, legacy_ebpf or universal_ebpf) you should now install a specific package with a smaller set of dependencies. The install script and the ansible role have been adapted accordingly. Please refer to Package Reference for more details.\nUptime Metrics for Agent Sub-ProcessesAdded agent health metrics to the prometheus exporter showing the uptime of agent sub-processes.\nFeature-Enabled MetricsSysdig agent can now collect feature-enabled metrics using prometheus exporter when health metrics are enabled. See Agent Health Metrics for more information.\nkube_configmap_info MetricAdded kube_configmap_info metric to provide information on the agent configmap. For more information, see ConfigMap Metrics.\nEnriched sysdig_agent_info with Linux InformationThe sysdig_agent_info metric now is enriched with Linux kernel and distribution information.\nAbility to Configure kube_node_annotationsAdded the ability to configure the kube_node_annotations metric. For more information, see Enable Node Annotations.\nDefect FixesFixed Repeated Warning LogFixed the issue where a warning log was being repeated frequently in both debug and warning modes.\nFixed Automatic Unloading of the Kernel ModuleIn the case of native installations on Debian-based systems, stopping the service or uninstalling the package might leave the kernel module loaded. This has been fixed.\nNo longer inserting the Kernel Module when legacy_ebpf or universal_ebpf are selectedIn the case of native installations, the kernel module would be built and loaded even when not strictly needed (i.e. when legacy_ebpf or universal_ebpf is selected). Provided the appropriate package is selected, this is no longer the case.\n13.0.4 April 12, 2024 Supportedsysdig-deploy helm chart version: 1.49.8 Supported Falco Engine version: 1000.23.0 This hotfix addresses the following:\nFixed a defect that prevented the agent upgrade from v12.20 to v13.0 on EKS Bottlerocket Delivered a preventative change that removes Sysdig Agent\u0026rsquo;s impact on node stability due to GKE PDCSI Driver Defect. All the code paths that can potentially surface the GKE issue have been replaced with alternate logic. 13.0.3 March 27, 2024 Released in sysdig-deploy helm chart version: 1.46.2 Supported Falco Engine version: 1000.23.0 This hotfix addresses the following:\nFixed build failures of the legacy eBPF probe on the most recent 6.x kernels. Fixed an issue where the Runtime Policy pausing Container Action was not working on environments with cgroup v1. 13.0.2 March 21, 2024 Released in sysdig-deploy helm chart version: 1.45.5 Supported Falco Engine version: 1000.23.0 This hotfix addresses the following:\nVulnerability fixes:\nCVE-2024-27304 CVE-2024-24786 Fixed a build issue of the legacy_ebpf driver that impacted RHEL v5.14 kernels with RHEL subversion 410 or higher.\nFixed kernel module build for linux kernel 6.8.\n13.0.1 March 11, 2024 Released in sysdig-deploy helm chart version: 1.42.3 Supported Falco Engine version: 1000.23.0 This hotfix fixed an issue where the Sysdig Agent could retain allocated UDP ports until reaching port saturation, occurring under specific combinations of the driver used and enabled features.\n13.0.0 March 06, 2024 Released in sysdig-deploy helm chart version: 1.41.0 Supported Falco Engine version: 1000.23.0 We strongly recommend you to skip v13.0.0 and upgrade to Sysdig Agent v13.0.1. See Breaking Changes for more information.\nEnhancementsUpdated Docker Image to UBI9Sysdig Agent\u0026rsquo;s Universal Base Image has been upgraded from UBI8 to UBI9.\nAdded Agent Health Metrics in secure_light ModeAdded the following health metrics when the agent is running in secure_light mode:\nsysdig_agent_analyzer_num_evts sysdig_agent_analyzer_dropped_evts Support for TLS and Basic Authentication in Agent Prometheus ExporterAgent Prometheus Exporter now supports TLS and basic authentications.\nAbility to Collect Subattributes from JMX metricsAdded ability to collect individual subattributes from CompositeData JMX metrics.\nAvailability of Promscrape in ARM64 in FIPS ModeSysdig Agent now includes FIPS-mode promscrape binary previously missing for ARM platforms.\nKill Process in WorkloadIn Threat Detection Policies, Workload and List Matching policies can now be configured to kill the event-triggering process. For details, see Workload.\nBreaking ChangesAs part of Sysdig Agent 13.0.0 release, and as anticipated in the release notes for the 12.20.0, Sysdig dropped the support for:\nlogwatcher RHEL6 and CentOS6 All Sysdig users affected by these changes have been notified. If you haven\u0026rsquo;t received any communication from Sysdig, it means there is no impact on your usage.\nDefect FixesUpdated ssl_shim ConfigurationThe ssl_shim configuration has been changed to fix an issue where openssl.cnf bundled with the agent expected ssl_shim to select the FIPS or non-FIPS providers at startup time. This configuration broke other programs that are dynamically linked against OpenSSL v3.\nAdded a openssl_conf configuration flag to allow users to specify a custom openssl.cnf file for use with the agent. To include custom OpenSSL v3 library, you need to set the custom openssl_conf and your library path. This configuration is required when openssl_lib points the agent to a custom OpenSSL v3.x library. See openssl_lib for more information.\nSupport for Universal eBPF on 1-vcore MachinesUniversal eBPF is now supported on 1-vcore machines.\nScoping Events to Containers on Specific Kubernetes ClustersThe host scope resolution now works correctly when additional scope predicates are specified along with the standard contauner_id=\u0026quot;\u0026quot;. For example, contauner_id=\u0026quot;\u0026quot; and kubernetes.cluster.name=my_cluster\nFixed Misleading Collector Reconnection Attempts LogsFixed an issue where agent report a large number of logs with \u0026ldquo;No further retries left for attach to container\u0026rdquo;.\n12.20.0 January 31, 2024 Supported sysdig-deploy version: 1.37.11 Supported Falco Engine version: 1000.22.0 EnhancementsRemoved the sysdig_secure.enabled TagRemoved the hardcoded sysdig_secure.enabled tag generated when runtime detection is enabled using the following configuration:\nsecurity: enabled: true Use the agent_secure_enabled label in the sysdig_agent_info metric instead to check if runtime detection is enabled.\nEnhanced Kernel Sampling Ratio to Handle High Event LoadsThe activation logic of the kernel sampling ratio has been improved. You may notice a change in sampling ratio metrics behavior after upgrading to v12.20.0. This behavior is intentional and indicative of a healthy system response.\nThe sampling ratio is a key tool for the agent to regulate performance during high workloads. Monitoring these metrics gives valuable insights into the overall health of the agent. Version 12.20.0 brings the improvement to optimize the agent\u0026rsquo;s adaptability to high event loads.\nSupport for Container Actions and CapturesSysdig agent supports the following new actions in Container Drift policies and Malware policies:\nThe ability to create capture files The ability to Kill/Pause/Stop a container Malware policies are currently in Controlled Availability. Contact Sysdig Support for access to the Malware feature.\nDefect FixesUpdating Kernel No Longer Results in DKMS FailureFixed an issue where updating the kernel resulted in Dynamic Kernel Module Support(DKMS) failure in host installations with kmod.\nAdditional Log Lines No Longer Appear After Agent UpdateFixed an issue where policy events with associated actions could cause a significant increase in the number of lines logged.\nKnown Issues If you encounter MAC address duplication after upgrading from v12.20.0 to v13.x.x while operating an on-premises backend, upgrade your on-premises backend to the latest version. Alternatively, you can manually set a unique machine ID prefix for each host as a workaround. Deprecation NoticeIn the upcoming agent release, Sysdig will deprecate the support for logwatcher, RHEL6, and CentOS6.\n","url":"https://docs.sysdig.com/en/release-notes/linux-agent-release-notes/2024-archive/"},{"id":1,"title":"Monitor SaaS Release Notes 2025","content":"November 25, 2025Dashboard Enhancements Dashboard Section Grouping: You can now group panels into sections, making large dashboards easier to organize and manage.\nCustomizable Table Column Headers: The Table panel now lets you relabel column headers and reorder columns to match your preferred layout.\nPersistent Query View Selection: The panel editor now remembers your preferred query mode (Form or PromQL) and automatically loads it the next time you open the panel.\nOctober 24, 2025Alert Silencing Rules ImprovementsAdded enhancements to Sysdig Alert Silencing rules:\nRecurring Silences: You can now schedule recurring alert silences to automatically mute notifications during defined maintenance windows (for example, daily or weekly). Full-Scope Silencing: It’s now possible to silence the entire infrastructure, depending on the defined team scope. August 19, 2025Increased Timechart Granularity in DashboardsThe default resolution of the timechart visualization type in Dashboards has been increased, offering finer granularity for 12 hours, 2 days, 5 days and 30 days time windows.\nFor more details, see Timechart - Granularity.\nAugust 13, 2025Dashboard Manager ImprovementsWe have updated the Dashboard Manager to make it easier for you to find, share and organize dashboards:\nDashboard Manager\u0026rsquo;s Search function now detects matches in dashboard names, panel names, metrics and labels. You can now sort dashboards into groups for easier organisation. When locating a dashboard, you can filter by \u0026ldquo;Group\u0026rdquo; and \u0026ldquo;Author\u0026rdquo;. A \u0026ldquo;Shared by Team\u0026rdquo; view helps you easily identify the dashboards your team have shared with you. For more information, see Dashboard Manager.\nJuly 11, 2025Prometheus API Access GASysdig Monitor now supports access to a Prometheus-compatible public API. Use this API to query and ingest metrics programmatically using familiar Prometheus endpoints.\nFor a list of supported endpoints and required permissions, see Prometheus API Endpoint Support.\nJuly 07, 2025Custom Prometheus Jobs via APIYou can now create custom Prometheus jobs via the Sysdig Monitor API as a flexible and efficient way to configure Prometheus scraping without redeploying the sysdig-agent. This is especially useful when small changes to scrape jobs are needed across multiple environments or clusters.\nFor more details, see Create Custom Prometheus Jobs via API.\nApril 29, 2025Workload Rightsizing Reports in BetaSysdig released Workload Rightsizing Reports in beta. This new report type identifies opportunities to downsize or upsize workloads based on real usage patterns, reducing resource waste and improving performance.\nFor more details, see Workload Rightsizing Report.\nApril 14, 2025Improved Alert Evaluation PausesSysdig has improved the capability to temporarily pause alert evaluation. You can pause alert evaluation for a specified duration, while ensuring visibility into who initiated the pause and how long it will last.\nDuration Support: You can now specify how long the pause should last. This helps to prevent alerts from being unintentionally paused indefinitely. Improved Visibility: When the downtime toggle is active, banners appear in the Alert List and Event Feed to indicate that alert evaluations are paused and show who paused them. To learn how to pause all alert evaluations, see Pause Alerts for Downtime.\nImproved Event Detail PanelSysdig has made the following improvements to the Event Detail Panel:\nDecluttered layout: Segment and Scope sections now collapse and expand to better organize events with extensive label-sets. One-click filters: You can now include or exclude events by labels with a single click. Searchable labels: You can now search for specific label keys or values. You can access the Event Detail panel by clicking on any event in the Events Feed. For more details, see Review Events.\nApril 08, 2025Multi-Factor AuthenticationUsers can now enable Multi-Factor Authentication (MFA) to add an additional layer of validation to their login. Once enabled, each login to Sysdig Monitor or Sysdig Secure must be validated with an authenticator app, such as Okta Verify or Google Authenticator. This improves your login security. For more details, see Multi-Factor Authentication.\nMarch 10, 2025Improved Alert Editor for Event Alerts With Automatic Time Window SelectionThe Alert Editor for Event Alerts now automatically selects the optimal time window based on the configured Count Over Last parameter. As a result, the previous options for manually-configured time windows (1h, 6h, 1D, 1W, and 2W) have been removed. This ensure the Alert Editor preview accurately reflects the alert rule evaluation.\nIncreasing the Count Over Last value will continue to reduce the frequency of alert evaluations, just as it did before. For details, see Frequency of Alert Rule Evaluation.\nAdditionally, each data point in the Alert Editor now directly corresponds to an alert rule evaluation, providing clearer visibility into the expected alerting behavior.\nFebruary 11, 2025Automate Orphaned Alert Occurrence Resolution or DeactivationDepending on the alert type, you can now configure an alert occurrence to automatically deactivate or resolve when the triggering entity, such as a host or container, has stopped reporting data.\nEntities may cease to report data during scaling events or on dynamic workloads. Deactivating or resolving orphaned alert occurrences eliminates false positives and ensures only alert occurrences from entities that actually exist are reported in the system.\nAvailability of this feature depends on the alert type. For more details, see Deactivate or Resolve Orphaned Alert Occurrences Automatically\nJanuary 21, 2025Piechart Visualizations for Dashboard PanelsYou can now visualize data with pie charts in Sysdig Monitor Dashboards. To get started, open or create a dashboard panel, and choose the visualization type Piechart. Pie charts present segmented data in a visually appealing and intuitive way. You can customize your pie chart, and select its expression from a wide range of units, such as dollars, terabytes, and microseconds. For more details, see Piechart\nJanuary 16, 2025Wasted Workload Spend ReportsSysdig added a new report type to the Costs Reports module. The Wasted Workload Spend Report provides detailed insights into workload-level resource consumption. It calculates Accrued Cost, Estimated Rightsizing Spend, and Wasted Spend to identify unused CPU and memory resources. This helps your organization optimize costs. For more details, see Wasted Workload Spend Report.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-monitor-release-notes/2025-archive/"},{"id":2,"title":"Secure SaaS Release Notes 2025","content":" You may also want to review the update log for Falco rules used in the Policy Editor: Falco Rules Changelog. The dates shown are for the initial release of a feature. The feature may not be rolled out to all regions concurrently and availability of a feature in a particular region will depend on scheduling.\nSupported Web BrowsersSysdig supports, tests, and verifies the latest versions of Chrome and Firefox. Other browsers may also work but are not tested in the same way.\nDecember 16, 2025Sysdig Runtime Scanner v1.8.5Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-47914 CVE-2025-58181 CVE-2025-61727 CVE-2025-61729 December 15, 2025Sysdig CLI Scanner v1.24.2Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-47914 CVE-2025-58181 CVE-2025-61727 CVE-2025-61729 December 09, 2025Host Scanner v0.14.1Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-61727 CVE-2025-61729 KSPM Analyzer v1.46.2Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-59375 CVE-2025-61727 CVE-2025-61729 CVE-2025-9714 December 04, 2025Accepted Risk Renamed to Exceptions in Risks Renamed Accepted Risk to Exceptions in the Risks workspace. Added a centralized Risk \u0026gt; Exceptions view to list and manage all risk exceptions, including scope, expiration, reason, and ownership details. Updated the risk workflow to allow creating exceptions directly from a Risk Finding using Create Exception. OpenTofu Support for IaC ScanningSysdig now supports OpenTofu for Sysdig’s Infrastructure-as-Code (IaC) scanning. Teams using OpenTofu can now detect misconfigurations earlier in CI/CD and enforce consistent security policies — using the same policy set they already maintain for Terraform.\nWhat’s new\nScan .tofu and .tofu.json files alongside Terraform with consistent results. Keep one set of policies — Terraform policies work with OpenTofu too. In Inventory, resources managed by OpenTofu can be filtered using the Source Type filter OpenTofu. If you’re using OpenTofu today, there’s nothing new to install: point your existing scans at your repository or pipeline and Sysdig will automatically evaluate OpenTofu files.\nRegistry Scanner v0.10.2Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-9714 CVE-2025-61727 CVE-2025-61729 December 03, 2025Runtime detections: FIMA new runtime detection type, File Integrity Monitoring (FIM), is now available. You can configure this detection by creating FIM Policies and using Host Shield \u0026gt;= 14.3. Through this detection, you can meet PCI DSS Requirements 10.5.5 and 11.5.\nDecember 02, 2025Removal of Legacy Cloud Onboarding Parameters (AWS, Azure, and GCP)Sysdig has removed support for legacy parameters previously used in cloud-account onboarding. If your configuration still references these fields, update it to the include/exclude model to continue using cloud onboarding features.\nRemoved legacy parameters AWS: organizational_unit_ids, org_units GCP: management_group_ids Azure: management_group_ids These parameters have been fully replaced by the supported include/exclude options:\nAWS: include_ouids, exclude_ouids, include_accounts, exclude_accounts GCP: include_folders, exclude_folders, include_projects, exclude_projects Azure: include_management_groups, exclude_management_groups, include_subscriptions, exclude_subscriptions See the AWS migration guide, Azure migration guide, and GCP migration guide for details on updating your configuration.\nEvents Feed: Customizable ColumnsYou can now configure the columns available on the Events Feed to preview different attributes without the need to open each event one by one. For more information, see Events Feed.\nDecember 01, 2025Resource Posture Report Template UpdateA new Resource Posture Report template is now available and will be used for all newly generated reports. This update introduces the following improvements:\nRenamed Accepted Risk column to Exception. Expanded Posture Policy Requirements into individual rows per policy or requirement for improved clarity. Removed newline characters from Remediation Playbook entries for better readability. Renamed Provider Type column to Platform. Improved overall Label formatting for consistency and readability. Existing reports remain unchanged. The new template applies only to reports generated after this update.\nNovember 28, 2025Sysdig MCP Server v0.5.0This release delivers a full rewrite of the MCP Server in Go, significantly improving performance, type safety, and deployment simplicity using a single binary distribution. It also introduces a powerful new set of Kubernetes troubleshooting tools for diagnosing pod health, network errors, and resource utilization directly through Sysdig Monitor.\nBreaking Changes The API token environment variable is renamed to SYSDIG_MCP_API_TOKEN. Python-based uvx execution is no longer supported. Use Go or Docker instead. The Sysdig CLI Scanner tool is removed to streamline the server around remote API interactions. This release also enhances the developer experience with Nix support, a standardized task runner, improved CI, and an AI Agent handbook. For more details, see the changelog.\nRegistry Scanner v0.10.1Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-47912 CVE-2025-47913 CVE-2025-47914 CVE-2025-58181 CVE-2025-58183 CVE-2025-58185 CVE-2025-58186 CVE-2025-58187 CVE-2025-58188 CVE-2025-58189 CVE-2025-61723 CVE-2025-61724 CVE-2025-61725 CVE-2025-6965 CVE-2025-9230 KSPM Collector v1.39.16Defect Fixes Fixed an issue where the KSPM Collector could log failed to submit status events when accepting insecure TLS connections. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-47912 CVE-2025-47913 CVE-2025-47914 CVE-2025-58181 CVE-2025-58183 CVE-2025-58185 CVE-2025-58186 CVE-2025-58187 CVE-2025-58188 CVE-2025-58189 CVE-2025-61723 CVE-2025-61724 CVE-2025-61725 November 27, 2025Host Scanner v0.14.0Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-47914 CVE-2025-58181 KSPM Analyzer v1.46.1Enhancements Improved Docker Posture Audits to indicate whether the check is not applicable to the configuration Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-47914 CVE-2025-58181 November 24, 2025Sysdig CLI Scanner v1.24.1Defect Fixes Fixed an issue where the CLI scanner could incorrectly evaluate policies skipping non-OS packages. Sysdig Runtime Scanner v1.8.5Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2022-29458 CVE-2024-25621 CVE-2025-47906 CVE-2025-47907 CVE-2025-47912 CVE-2025-47913 CVE-2025-52881 CVE-2025-54410 CVE-2025-58058 CVE-2025-58183 CVE-2025-58185 CVE-2025-58186 CVE-2025-58187 CVE-2025-58188 CVE-2025-58189 CVE-2025-61723 CVE-2025-61724 CVE-2025-61725 CVE-2025-64329 CVE-2025-8058 November 20, 2025Sysdig CLI Scanner v1.24.0Enhancements Improved Windows container vulnerability detection. The scanner now accurately detects vulnerabilities in Windows containers by correctly recognizing when the base operating system is updated in intermediate layers. Defect Fixes Fixed an issue that could cause the CLI scanner to return a wrong Digest when retrieving images from Containerd. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2024-25621 CVE-2025-31133 CVE-2025-52565 CVE-2025-52881 CVE-2025-58187 CVE-2025-64329 November 17, 2025Host Scanner v0.13.13Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2024-25621 CVE-2025-52881 CVE-2025-64329 KSPM Analyzer v1.46.0Enhancements Improved audit output to include container identifiers (container ID and container name) for evaluated hosts, enhancing traceability. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-6965 CVE-2024-56433 November 12, 2025KSPM Analyzer v1.45.7Defect Fixes Resolved an issue where the kspm-analyzer could be incorrectly flagged by the Sysdig agent as performing malicious actions, such as read ssh information. Resolved an issue where the kspm-analyzer could return an integer expression expected error. Enhancements Improved sysctl posture checks logic adding support for both local and exported configurations. November 05, 2025Role-Based Access Control (RBAC) for IdentitySysdig now supports Role-Based Access Control (RBAC) for Identity (Cloud Infrastructure Entitlements Management) features. Administrators can manage access to Identity data directly in the Roles settings, choosing No Access, Read Only, or Full Access.\nThis makes it easier to enforce least privilege, maintain separation of duties, and prevent unauthorized access to sensitive IAM information. For more details, see the User and Team Administration.\nNovember 03, 2025Jira Platform TicketingJira Platform Ticketing, a major upgrade to Sysdig\u0026rsquo;s Jira integration, is now generally available. This new platform feature is much more robust and will expand across the product, from VM to Posture and beyond.\nWith Jira Platform Ticketing, you’ll get richer ticket types, better context in issues, and deeper coverage across workflows, making it easier to track and manage findings directly from Sysdig. For more information, see Jira Platform Ticketing.\nOctober 31, 2025Image Signature Validation for Admission Control of Kubernetes WorkloadsSysdig Secure now supports Image Signature Validation to ensure that only trusted and verifiable container images are deployed to your Kubernetes and OpenShift clusters. This new capability, powered by Cosign, lets you enforce signature verification at admission using trusted sources like Red Hat Trusted Artifact Signer (RHTAS), GitHub + Sigstore, or a self-hosted Sigstore instance.\nAvailable starting with Cluster Shield 1.17.0, Image Signature Validation integrates with the Sysdig Admission Controller to strengthen supply chain security by preventing unsigned or tampered images before they reach your critical environments.\nFor more information, see the Image Signature Validation Policy.\nOctober 23, 2025Identity Findings: Group By Identity CheckThe Identity Findings page now includes a new grouping option: Group by Identity Check. This aggregates findings by the type of issue (for example, Unused Permissions, No MFA Enabled, etc.). Use this to efficiently assess the scope of common, recurring issues across all identities and prioritize remediation efforts for the most prevalent findings. For more details, see Grouping Findings.\nNew Filtering OperatorsSysdig has added Zones filtering with two new operators: is not and does not contain. These make it easier to exclude resources with precision, enabling more flexible and advanced filtering for your events and findings.\nOCI Integration for ZonesSysdig Zones now support Oracle Cloud Infrastructure (OCI), extending detection and response to cover both container and host events in OCI environments. You can scope Zones using OCI Tenancy ID, Compartment, and Region, giving you consistent visibility and control across multi-cloud deployments.\nEnhanced Zones with Label Support for VM and CDRSysdig has expanded Zones to support filtering with both Kubernetes and cloud labels, giving you more precise control over resource scoping.\nKubernetes labels: Zones now support filtering using standard Kubernetes label selectors for precise resource scoping. You can add custom labels, with autocomplete support, and enrich events with these labels from the time the Zone is created. Cloud labels: Zones now support instance-level labels on AWS, Azure, OCI, and GCP for filtering. You can add custom labels with or without autocomplete, and enrich events from the time the Zone is created. (Note: spaces are not allowed in label fields.) Cloud labels are not applicable to Falco cloud events. For example, on AWS, labels from EC2 instances running the Sysdig agent are automatically attached to any events originating from those instances when the label is used in a Zone. Improved Filtering Capabilities in the Events FeedThe Events Feed now supports filtering Runtime events using output fields in addition to labels.\nYou can apply these filters in two ways:\nFrom within an event: open the event and use the embedded filters. Directly in the filter bar: type and search for filters prefixed with fields. October 17, 2025Host Scanner v0.13.12EnhancementsImproved .NET/NuGet Package DetectionPackages listed only in packages.lock.json are now ignored, as they may not be included in the final compiled binary. This results in a more accurate SBOM and fewer false positives.\nDefect FixesFixed an issue that could cause the Host Scanner to return an error when a risk accept policy is defined for packages with no vulnerabilities.\nSecurity UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-54410 Sysdig CLI Scanner v1.23.0EnhancementsEnhanced CSV OutputAdded RHSA URL, RedHat Severity, and RedHat CVSS Score fields.\nImproved .NET/NuGet Package DetectionPackages listed only in packages.lock.json are now ignored, as they may not be included in the final compiled binary. This results in a more accurate SBOM and fewer false positives.\nDefect Fixes Resolved a nil pointer dereference error that could occur when an image manifest contains an empty platform (missing OS or architecture). Fixed an issue that could cause the CLI scanner to return an error when a risk accept policy is defined for packages with no vulnerabilities. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-55198 CVE-2025-55199 CVE-2025-9566 CVE-2025-58058 KSPM Analyzer v1.45.6Defect Fixes Resolved an issue where control timeouts could be ignored in certain cases, preventing the overall analysis from completing successfully. October 16, 2025Sysdig MCP ServerIntroducing the Sysdig MCP (Model Context Protocol) Server, a new integration component that enables AI clients and LLM-powered assistants to securely query, analyze, and act on data from Sysdig Secure.\nThe Sysdig MCP Server acts as a bridge between AI tools (such as Claude Desktop, Goose Agent, and MCP Inspector) and the Sysdig Secure API, exposing runtime data, SysQL query capabilities, and CLI-based scanning tools in a standardized, extensible way.\nHighlights New AI Integration Layer: Provides an MCP-compliant interface for connecting Sysdig Secure data and workflows to AI clients. Tool Support: Includes runtime event retrieval, process-tree exploration, SysQL query generation and execution, and optional CLI-based image scanning. Secure Access: Uses your existing Sysdig Secure API token with least-privilege RBAC controls. Flexible Deployment: Runs as a Docker container, natively on a host, or in development environments via uv. Multi-Client Compatibility: Supports Claude Desktop, Goose Agent, and MCP Inspector integrations via stdio, streamable-http, or SSE transports. Natural-Language SysQL: Translate human queries into SysQL and retrieve structured runtime results. For more details, see Sysdig MCP Server.\nOctober 15, 2025Subscription page: TimechartsThe subscription page now includes timecharts to help you visualize trends in the usage of different entitlements across all Subscriptions starting from August 2025. The available timecharts include:\nUnits/Resources Sysdig Sage Cloud logs For more details, see Secure Subscription.\nOctober 01, 2025KSPM Analyzer v1.45.5A new version of KSPM analyzer is available with the following improvements:\nResolved an issue where the kspm-analyzer could fail when running on Talos OS. Updated dependencies to address the following vulnerabilities: CVE-2025-32988 CVE-2025-32989 CVE-2025-32990 CVE-2025-6395 September 30, 2025Jira Platform Ticketing (Controlled Availability)Jira Platform Ticketing, a major upgrade to Sysdig\u0026rsquo;s Jira integration, is currently in controlled availability. Unlike the basic Jira integration available today, this new platform feature is much more robust and will expand across the product, from VM to Posture and beyond.\nWith Jira Platform Ticketing, you’ll get richer ticket types, better context in issues, and deeper coverage across workflows, making it easier to track and manage findings directly from Sysdig. For more information, see Jira Platform Ticketing.\nRegistry Scanner v0.10.0The Registry Scanner now supports Kubernetes tolerations in worker pods, enabling deployment on tainted nodes. This provides scheduling flexibility and improves cluster resource utilization and deployment options. You can configure tolerations for worker pods with config.scan.jobs.tolerations. For more details, see the Registry Scanner Charts.\nSysdig Sage for ThreatsSysdig Sage for Threats is now available, enriching the existing Threats feature with AI-powered investigation assistance. This feature helps you quickly understand the impact of runtime threats by connecting related events, rules, and impacted resources.\nWith contextual insights and guided navigation, you can ask questions like What runtime events are associated with this threat? or Who is impacted by this threat? and get actionable answers directly in the Threats UI.\nTo get started, go to Threats \u0026gt; Threats in Sysdig Secure and use the Sage Assistant panel. For more details, see Sysdig Sage for Threats.\nSeptember 24, 2025Registry Scanner v0.9.0A new version of the Registry Scanner is available with the following improvements:\nNew configuration options to tweak the behavior of the image analyzer ( config.scan.imageAnalyzer.maxFileSizeBytes, config.scan.imageAnalyzer.maxFileSizeBytesInMemory and config.scan.imageAnalyzer.parallelFileAnalysisCount). For more details, see the Registry Scanner Charts. Updated dependencies to address the following vulnerabilities: CVE-2025-5914 CVE-2025-32988 CVE-2025-32989 CVE-2025-32990 CVE-2025-6395 September 23, 2025Kubernetes Response ActionsSysdig released new Kubernetes Response Actions, expanding your ability to investigate, respond to security events and contain threats in Kubernetes. The following actions are now available in the Sysdig UI and APIs:\nNetwork Isolate Delete Pod Rollout Restart Get Kubernetes Logs Volume Snapshot For more details, including prerequisites, see Response Actions.\nSeptember 19, 2025KSPM Analyzer v1.45.4A new version of KSPM analyzer is available with the following improvements:\nResolved an issue where the kspm-analyzer could fail with error \u0026quot;root: unable to open /etc/sudoers: Operation not permitted\u0026quot;. Updated dependencies to address the following vulnerabilities: CVE-2025-47906 CVE-2025-47907 September 15, 2025Data Security Findings on AzureSysdig can now scan Azure Blob Storage for sensitive data, including Personally Identifiable Information (PII), Protected Health Information (PHI), and financial data.\nThis feature is available as an optional add-on to your Sysdig Secure Risk Management or CNAPP subscription. To enable Data Security Findings for your Azure accounts, contact your Sysdig account team or Support.\nFor more details, see Data Security Findings.\nSeptember 12, 2025KSPM Collector v1.39.15A new version of KSPM collector is available with the following improvements:\nResolved an issue where the kspm-collector was not sending keepalive messages to the backend, which could cause its data to disappear from the UI. Resolved an issue where proxy-related settings were ignored when accepting insecure TLS connections. Updated dependencies to address the following vulnerabilities: CVE-2022-29458 September 10, 2025Host Scanner v0.13.11A new version of Host Scanner is available with the following changes:\nUpdated dependencies to the latest versions for general improvements and stability September 8, 2025KSPM Analyzer v1.45.3A new version of KSPM analyzer is available with the following improvements:\nResolved an issue where proxy-related settings were ignored when accepting insecure TLS connections. Resolved an issue where the kspm-analyzer could be incorrectly flagged by the Sysdig agent as performing malicious actions, such as read sensitive file untrusted. Improved Bottlerocket and Talos OS detection logic. Updated dependencies to address the following vulnerabilities: CVE-2025-5914 CVE-2025-32414 CVE-2025-32415 CVE-2025-8194 September 3, 2025Data Security Findings on Google Cloud Platform (GCP)Sysdig can now scan Google Cloud Storage (GCS) buckets for sensitive data, including Personally Identifiable Information (PII), Protected Health Information (PHI), and financial data.\nThis feature is available as an optional add-on to your Sysdig Secure Risk Management or CNAPP subscription. To enable Data Security Findings for your GCP accounts, contact your Sysdig account team or Sysdig Support.\nFor more details, see Data Security Findings.\nAugust 29, 2025Software Composition Analysis (SCA) IntegrationsSysdig now integrates with Software Composition Analysis (SCA) tools like Semgrep and Synk. This feature enriches runtime vulnerability findings by linking them to their source code origin, helping teams accelerate triage and remediation.\nTrace vulnerabilities to source: Link runtime findings to the specific repository, dependency file, and commit. Accelerate remediation: Get actionable fix recommendations on the source directly from your SCA tool. Simple configuration: Connect Snyk and Semgrep accounts from the Integrations UI. This feature requires adding the org.opencontainers.image.source label to your container images at build time to enable correlation.\nFor more details, see Software Composition Analysis Integrations.\nAugust 28, 2025A New Risk Management Experience in Sysdig SecureWe are excited to announce a significant update to how you define and manage risks within Sysdig Secure. This release introduces a more intuitive and transparent experience, giving you greater control and deeper insights into your security posture.\nThe new Risks and Risk Definitions pages streamline your workflow, providing a centralized hub for combining, understanding, and prioritizing security findings across your environment.\nWhat\u0026rsquo;s New and Improved:\nTransparent and Explicit Risk Definitions: The new Risk Definitions page is where you manage the criteria that generate your risk findings. We\u0026rsquo;ve migrated all managed risks to SysQL, making the underlying logic fully transparent. You can now view the exact query that generates each risk finding, providing complete clarity and reducing guesswork. This change also moves away from \u0026ldquo;optional findings\u0026rdquo; to more explicit definitions, giving you a clearer, more predictable understanding of your security posture. Powerful New Filtering: The Risks page now includes a suite of new dynamic filters, making it easier to prioritize and focus on what matters most. Quickly filter by Severity, Finding Category, new Risk Definition Tags, and more. You can now easily isolate new risks, live threats, and vulnerabilities with specific contexts like \u0026ldquo;In Use\u0026rdquo; and \u0026ldquo;Has Exploit.\u0026rdquo; Enhanced Customization and Control: We\u0026rsquo;ve made it easier to manage your risk definitions. You can now view the SysQL that defines any managed risk to create a custom version tailored to your specific needs. Additionally, you can disable managed definitions, giving you full control over which out-of-the-box risks are monitored in your environment. Centralized Risk Definition Management: With the introduction of the Risk Definitions page, you can now view both managed and custom risk definitions in a single location. This unified view simplifies management and provides a holistic understanding of all the definitions that govern your risk findings. These updates give you improved visibility and control, helping you to identify and mitigate the most critical risks with greater speed and precision.\nFor more details, see Risks.\nAugust 22, 2025Automations Execution HistoryYou can now review the success and failure of every step of your Automations. Open the Executions tab in a created Automation to explore the history of each of the actions you configured.\nFor more details, see Automations - Executions.\nSysdig CLI Scanner v1.22.6A new version of the CLI Scanner is available with the following improvements:\nAdded support for uv, the python package and project manager backed by Astral. See uv. August 14, 2025KSPM Collector v1.39.14A new version of KSPM collector is available with the following improvements:\nFixed a bug related to posture result visibility. Host Scanner v0.13.10A new version of Host Scanner is available with the following improvements:\nUpdated dependencies to fix the following vulnerabilities: CVE-2025-47907 CVE-2025-8058 CVE-2022-29458 Registry Scanner v0.8.3A new version of Registry Scanner is available with the following improvments:\nUpdated dependencies to fix the following vulnerabilities: CVE-2025-47906 CVE-2025-6965 CVE-2025-7425 CVE-2022-29458 CVE-2025-32414 CVE-2025-32415 CVE-2025-47907 CVE-2025-8058 August 12, 2025Include or Exclude Management Groups and Subscriptions in Azure with Selective Cloud Account OnboardingSysdig now offers enhanced control for Azure onboarding, allowing you to include or exclude specific Management Groups and subscriptions. This capability supports more targeted monitoring configurations, enabling you to onboard only the parts of your Azure environment that matter most. Use the Include/Exclude options during onboarding to align monitoring with your organizational structure. For details, see Selective Cloud Account Onboarding.\nAutomatically Onboard New Azure Subscriptions with Dynamic Cloud Account OnboardingSysdig now supports automatic onboarding of newly created and active Azure subscriptions, helping your cloud environment stay up to date without manual intervention. Once enabled, Sysdig will periodically detect and onboard new subscriptions under the listed Management Groups within your Azure tenant. You can enable or disable this functionality in the onboarding setup screen. For more information, see Automatic Cloud Account Onboarding.\nAugust 11, 2025KSPM Analyzer v1.45.2A new version of KSPM analyzer is available with the following improvements:\nFixed an issue where the kspm-analyzer could generate CPU spikes when running docker-related audits. Updated dependencies to fix the following vulnerabilities: CVE-2025-5994 CVE-2025-6965 CVE-2025-7425 CVE-2025-8058 CVE-2022-29458 August 4, 2025New Identity Experience: Dashboard and Findings PagesSysdig is excited to introduce a redesigned identity experience to support your Cloud Infrastructure Entitlements Management (CIEM) program. The new Identity Dashboard and Findings pages offer a clear, actionable view of your cloud IAM posture. You can quickly uncover risky access, reduce excessive permissions, and focus on the areas that matter most.\nThe previous Identity pages are now deprecated and will be phased out over time. During the transition, both the legacy and new experiences will be available. This update also brings identity management in line with other Program Owner workflows in Sysdig Secure to deliver a more consistent and intuitive experience.\nFor more details, see Identity Overview and Identity Findings.\nAugust 1, 2025Vulnerability Risk Acceptance on Packages and Package PathsSysdig Vulnerability Management now supports granular risk acceptance on packages. You can now accept risk for:\nSpecific package versions All versions of a given package A package (or version) within a specific path A package (or version) on any path This enhanced flexibility allows you to accept risk for known and managed packages in your environment, either universally or for targeted locations. By enabling precise control over which packages and paths are accepted, teams can significantly reduce alert noise and focus remediation on the vulnerabilities that matter most.\nFor more details, see Risk Acceptance for Vulnerability Management.\nSysdig Runtime Scanner v1.8.4A new version of the Runtime Scanner is available with the following vulnerability fixes:\nCVE-2025-4673 CVE-2025-0913 CVE-2025-4802 CVE-2025-5702 July 29, 2025Data Security Findings (New Add-On)Introducing Data Security Findings, a new Sysdig Secure capability designed to uncover and prioritize risks to sensitive data across your cloud environment. With this feature, you can discover, classify, and analyze potential data exposures while ensuring that sensitive data remains in your cloud accounts during scanning.\nHighlights:\nReveal Data Exposure: Automatically discover and classify PII, PHI, and financial data across cloud environments to surface hidden risks. Resource Details Integration: Data security findings are now visible in the Resource Details side panels, giving you a complete view of risk for each resource. SysQL Support: Use SysQL to query and filter data security findings, enabling custom reporting and automation. Risk Attack Path Correlation: Data security findings are integrated with our risk engine, visualizing sensitive data in attack paths to reveal potential blast radius and helping you prioritize remediation based on criticality. This feature is available as an optional add-on to your Sysdig Secure Risk Management or CNAPP subscription. Contact your Sysdig account team or support representative to enable Data Security Findings for your AWS accounts.\nFor more details, see Data Security Findings.\nJuly 18, 2025KSPM Collector v1.39.13A new version of KSPM collector is available with the following improvements:\nFixed a bug in namespace entity generation that caused empty namespace entries to appear in Inventory. Updated dependencies to fix the following vulnerabilities: CVE-2025-4802 CVE-2025-4673 KSPM Analyzer v1.45.1A new version of KSPM analyzer is available with the following improvements:\nChanged log level from ERROR to INFO for certain messages that were incorrectly flagged as errors during normal operations. Updated dependencies to fix the following vulnerabilities: CVE-2024-52533 CVE-2025-4373 CVE-2025-49794 CVE-2025-49796 CVE-2025-4138 CVE-2024-12718 July 16, 2025Sysdig CLI Scanner v1.22.5A new version of the CLI Scanner is available with the following improvements:\nAdded support for risk acceptance at the package level. Updated dependencies to fix the following vulnerabilities: CVE-2025-53547 July 15, 2025Host Scanner v0.13.9A new version of Host Scanner is available with the following improvements:\nFixed an issue where the host-scanner could fail to correctly identify certain Python packages during host scans. Updated dependencies to fix the following vulnerabilities: CVE-2025-5702 July 11, 2025Manage Threats with Exclusion RulesYou can now customize Threats with exclusion rules to reduce the noise from Threats that are not relevant. False positives can include routine admin activities, or test activities. Suppress known noisy rules to focus on the real dangers in your environments.\nFor details, see Threat Exclusion.\nJuly 08, 2025Improved Zones Filtering and UISysdig has improved the Zones experience, making it easier to create a Zone, and reducing the potential for confusion during scope configuration.\nWhen configuring a Zone, the new All Resources toggle lets you choose between complete inclusion or granular selection of resources, tags, or custom labels within your platforms. When it is toggled off, the UI now guides you through selecting a key, choosing an operator (in or contains), and entering values for each filter, ensuring your intent is clear and reducing errors. This makes it easy to include everything or focus only on selected subsets.\nOn the backend, Sysdig has improved how zones work. AWS, Azure, and GCP attributes, such as Account ID, Organization, Subscription, Project, and Region, now apply to Kubernetes events in Detection \u0026amp; Response and to agent-based findings in Vulnerability Management.\nFor more details, see Create and Configure a Zone.\nJuly 07, 2025Gzip Support for ReportingGzip is now supported across the reporting platform features. You can now choose between the compression formats gzip or zip for ad-hoc downloads and schedules of reports.\nECS Vulnerability ReportsSysdig introduced two new vulnerability report templates for ECS, supporting both Fargate and standard EC2 clusters:\nECS Workload Vulnerability Findings shows unique vulnerability finding on each resource. ECS Workload Vulnerability Scans shows each unique workload scanned with the aggregated count of vulnerabilities by severity. July 04, 2025Sysdig CLI Scanner v1.22.4A new version of the CLI Scanner is available with the following improvements:\nFixed a defect where RHEL-EUS OS was occasionally detected as standard RHEL. Fixed a defect in the json scan result output that could cause certain fields (e.g. remediation, rules description, layerRef) to contain incorrect values. Updated dependencies to fix the following vulnerabilities: CVE-2025-4673 CVE-2025-6032 CVE-2025-0913 July 03, 2025Drift Detection Policy EnhancementsSysdig has updated the Drift Detection Policy (formerly known as the Container Drift Policy) with enhancements to optional rules and event descriptions.\nThe Drift Detection Policy supports three optional rules:\nDetect Binary Drift: Detects binaries added or modified after container deployment. Detect Volume Drift: Detect all binaries originating from mounted volumes. To enable this rule independently of Detect Binary Drift, you need shield version 14.0+. For details, see Policy Rules. Block Prohibited Binary Execution: Blocks execution of detected drifted binaries Requires agent version 13.2.0+. Drift Detection Policy events now detail the precise reason they were created. For example, which rule triggered the event.\nThese improvements let you fine-tune your Drift Detection policies, and offer your security and operation teams greater transparency into the drifted binaries, containers and volumes in your environments, ensuring faster investigation and response.\nFor more details, see Configure a Drift Detection Policy.\nJuly 02, 2025Admission Controller GAAdmission Controller is generally available (GA), delivering powerful deploy-time security enforcement across Kubernetes environments. You can use Admission Controller to integrate Kubernetes Security Posture Management (KSPM) and Vulnerability Management (VM) into your deployment workflows.\nTo avail of this release, ensure you are running Cluster Shield version 1.13.0 or higher. For more details, see Install and Configure Admission Controller.\nJune 27, 2025Expanded Checks and Enhancements for Vulnerability Management Policy RulesSysdig has enhanced its Vulnerability Management Policy rules with new checks and improvements to existing capabilities:\nDisclosure Date Range Selection: Filter vulnerabilities based on disclosure date. CISA KEV Checks: Enforce policies based on the CISA Known Exploited Vulnerabilities catalog. EPSS Score \u0026amp; Percentile Checks: Set policies using EPSS probability scores and percentiles. In-Use Validation in Runtime: Detect and filter vulnerabilities present in running workloads. Default Users Rule Enhancement: Specify lists of approved or blocked default users for images. With these updates, you can proactively block images or enforce specific security criteria to better align with organizational best practices.\nFor more information please refer to the Vulnerability Policies documentation.\nExpanded Network Exposure DetectionSysdig has expanded its network exposure detection capabilities with support for detailed, cloud-specific use cases that help identify real-world public exposure scenarios across major cloud providers. This release adds coverage for cloud compute instances, storage services, and Kubernetes workloads, using cloud-native networking constructs to detect exposure paths.\nNewly supported exposure detections include:\nAWS S3 Buckets with public access via ACLs, bucket policies, and access point policies EC2 Instances exposed through: Public subnets (via explicit and default route tables) Classic, Application, and Network Load Balancers, with or without default route tables Google Cloud Cloud Storage Buckets with public access via ACLs, IAM Allow Policies, and Org Policies Compute Instances with public network interfaces and overly permissive firewall rules GKE Deployments exposed via LoadBalancer Services, Ingress resources, and network policy misconfigurations Microsoft Azure Virtual Machines with public IPs and exposed via network interfaces, NSGs, or open virtual networks Blob Containers exposed through public network access settings, network rule sets, or blob-level access These detections are now available in Sysdig Secure SaaS. You can view exposure findings in the Exposure tab of the Resource Details drawer, along with an evidence chain outlining the paths.\nFor more details, see the Exposure Tab documentation.\nJune 25, 2025Threat Intelligence FeedThe new Threat Intelligence page offers bulletins on emerging and high profile threats flagged by Sysdig\u0026rsquo;s threat research team. Each note includes:\nThe impacted platforms or tools. The number of hosts or packages impacted in your environment. Whether you are impacted by the threat. A link to a site where you can find out more. For more details, see Threat Intelligence.\nEnhanced Integrations UISysdig has updated the Integrations section in the Secure UI to bring all integrations into one central location. Here’s what changed:\nMoved Risk Spotlight and Ticketing Integrations (now Notification Channels) from Settings to Integrations. Renamed Ticketing Integrations to Notification Channels. Renamed Event Forwarding to SIEM \u0026amp; Data Platforms. Renamed Git Integrations to Source Code Management. Renamed Events and Logs to Identity \u0026amp; Audit Logs. These updates simplify navigation and make integration settings easier to find.\nNew Risks Tab in Resource Detail DrawersA comprehensive view of all Risk Findings associated with a particular resource is available in the new Risks tab within Resource detail drawers.\nThis tab allows you to:\nSee all known Risks tied to a resource in one place. Filter or sort by severity (Critical, High, Medium, and Low). Drill into full Risk Finding details, such as other affected resources or suggested fixes, within a streamlined workflow. This makes it easier to assess a resource’s security posture at a glance and take quick action.\nFor more information, see Risks Tab.\nJune 18, 2025Host Scanner v0.13.8A new version of Host Scanner is available with the following improvements:\nFixed a defect where RHEL-EUS OS was occasionally detected as standard RHEL Updated dependencies to fix the following vulnerabilities: CVE-2025-0913 CVE-2025-22874 CVE-2025-4673 June 16, 2025KSPM Analyzer v1.44.47A new version of KSPM analyzer is available with the following improvements:\nUpdated dependencies to fix the following vulnerabilities: CVE-2025-0913 CVE-2025-22874 CVE-2025-4673 June 12, 2025KSPM Analyzer v1.44.46A new version of KSPM analyzer is available with the following improvements:\nFixed a defect that could cause high CPU usage on the KSPM analyzer. June 11, 2025AI-Powered Detection and Remediation of Image VulnerabilitiesSysdig Secure now helps you fix image vulnerabilities faster with AI-powered remediation from Sysdig Sage.\nFrom the image\u0026rsquo;s Resource drawer, you can ask Sysdig Sage to analyze vulnerabilities and recommend safe, low-effort changes. These recommendations can be updating base images or application packages, that your team can implement quickly and confidently.\nWith Sysdig Sage, you can:\nGet guided fix recommendations for container image vulnerabilities Automatically create Jira tickets with fix plans for smooth developer handoff Save time by identifying safe, actionable changes without manual effort For more information, see Remediate Vulnerabilities with Sysdig Sage.\nJune 10, 2025Sysdig CLI Scanner v1.22.3A new version of the CLI Scanner is available with the following improvements:\nImproved AWS token match to avoid false positives. Added support for accepting risk on VM packages. Fixed incorrect database corruption detection in standalone mode. Registry Scanner v0.8.2A new version of Registry Scanner is available with the following improvements:\nFixed a defect where RHEL-EUS OS was occasionally detected as standard RHEL. Updated the dependencies to fix the following vulnerabilities: CVE-2025-4673 CVE-2025-49794 CVE-2025-49796 CVE-2024-52533 CVE-2025-0913 CVE-2025-25724 CVE-2025-3576 CVE-2025-4373 CVE-2025-4802 CVE-2025-5702 CVE-2025-6021 June 06, 2025KSPM Analyzer v1.44.45A new version of KSPM analyzer is available with the following improvements:\nChanged the default transport protocol for the Sysdig backend from nats to https. Updated the dependencies to fix the following vulnerabilities: CVE-2024-8176 CVE-2025-0398 CVE-2024-12133 CVE-2024-12243 CVE-2025-22871 CVE-2025-24528 June 05, 2025AWS Log Ingestion - EventBridge with API DestinationsSysdig has upgraded the EventBridge integration for AWS, using API Destinations. While continuing to provide a low latency integration, this improvement significantly reduces costs associated with EventBridge integrations.\nFor more information, see Configure CDR and Advanced CIEM for AWS.\nJune 02, 2025Include or Exclude Folders and Projects in GCP with Selective Cloud Project OnboardingSysdig now offers enhanced control for GCP onboarding, allowing you to include or exclude specific folders and projects. This capability supports more targeted monitoring configurations, making it easier to onboard only the parts of your GCP environment that matter most. Use the Include/Exclude options during onboarding to align monitoring with your organizational structure. For details, see Selective Cloud Project Onboarding.\nAutomatically Onboard New GCP Projects with Dynamic Cloud Project OnboardingSysdig now supports automatic onboarding of newly created and active GCP projects, helping your cloud environment stay current without manual intervention. Once enabled, Sysdig will periodically detect and onboard new projects within the selected folders, across your GCP organization. You can enable or disable this functionality in the onboarding setup screen. For more information, see Automatic Cloud Project Onboarding.\nMay 28, 2025Improved Identity Drawer for Inventory and RiskA newly redesigned Identity resource detail drawer is now available when examining IAM entities from Inventory and Risk. This update brings the Identity experience in line with other resource panels, offering a consistent, unified view of everything Sysdig knows about an IAM entity, without disrupting your workflow.\nThe new panel makes it easier to investigate issues, understand relationships, and take action in context.\nThe new tabs included in the Identity resource detail drawer are:\nIdentity Findings: View identity-related risks and deviations from best practices.\nConnected Resources: See how the selected identity connects to other IAM resources (users, roles, groups).\nRemediate: Take action with guided remediation steps.\nThe Configuration Findings and Configuration tabs are also included in the drawer for a complete view.\nLegacy identity drawers remain available for Advanced CIEM users via the Identity module and will be phased out as we roll out further improvements to the Identity experience.\nFor more details, see View Resource Details.\nReporting UpdateSysdig has performed an update to the Reporting module on behalf of all users. You are not required to take any action at this time.\nPrior to this announcement, you could:\nUse managed reports to generate ad-hoc or schedule exports without needing to create your own reports to manage. Copy managed reports to edit the queries within the panels as a custom report. After this announcement:\nManaged reports have been converted into templates, and you can generate reports from these templates. All managed reports with an associated schedule have been converted to a report. All custom reports will just be considered a report. Users new to reporting will now see No Reports Created Yet and a button to Explore Report Templates on the Reports Manager. You can generate Compliance and Posture reports from two places in the Secure UI: Compliance Overview Compliance Findings For more details, see Reporting.\nAutomations for ThreatsSysdig has introduced Threats Automation — a new feature that lets you automate responses to threat activity. Create an automation to send notifications over Slack, Email, or Microsoft Teams when Sysdig discovers a threat. Learn more in the Threats Management section.\nFor more details, see Threats Automation.\nSysdig Runtime Scanner v1.8.3A new version of the Runtime Scanner is available with the following vulnerability fixes:\nCVE-2025-46569 CVE-2025-27144 CVE-2025-22872 CVE-2025-22871 CVE-2025-22870 CVE-2025-22869 CVE-2025-22868 CVE-2025-22866 CVE-2025-0395 CVE-2024-40635 CVE-2020-11023 Sysdig CLI Scanner v1.22.2A new version of the CLI scanner is available with the following vulnerability fixes:\nCVE-2025-32386 CVE-2025-32387 CVE-2025-46569 CVE-2025-22871 CVE-2025-22872 Defect Fixes Improved .NET analyzer logic to parse the targets section instead of the libraries stanza in \u0026lt;app\u0026gt;.deps.json files, ensuring more accurate detection of dependencies in compiled binaries. May 20, 2025KSPM Collector v1.39.12A new version of KSPM collector is available with the following improvements:\nUpdated the default transport to Sysdig\u0026rsquo;s backend from nats to http. Reduced memory consumption during collection of k8s resources. Dependencies updates to fix the following vulnerabilities: CVE-2025-0395 CVE-2025-22871 CVE-2025-22872 Automatically Onboard New AWS Accounts with Dynamic Cloud Account OnboardingSysdig now supports automatic onboarding of newly created and active AWS accounts, ensuring your cloud environment stays up-to-date without manual intervention. Once enabled, Sysdig will periodically detect and onboard new accounts across your AWS organization. You can enable or disable this functionality in the onboarding setup screen. For more information, see Automatic Cloud Account Onboarding.\nRegistry Scanner v0.8.1 Added fixes for the following vulnerabilities: CVE-2024-12133 CVE-2025-0395 CVE-2025-22871 CVE-2025-24528 Deprecation Notice for Syslog Events Forwarding Using UDPFrom today, 20 May 2025, Sysdig does not support UDP for new Syslog Event Forwarding integrations. We continue to support Syslog integrations using TCP.\nSupport for integrations using UDP is scheduled to end one month from today. Migrate your existing integrations to TCP within this time frame to avoid any disruption.\nHost Scanner v0.13.7Sysdig released a new version of the Host Scanner with the following improvements:\nFixed a defect that could cause the Host Scanner not to properly remove temporary files when scanning containers Fixed a defect that could cause the Host Scanner to send invalid scan-status data to the backend when scanning containers Fixed the following vulnerabilities: CVE-2020-11023 CVE-2025-0395 May 19, 2025Expanded Operator Support for Vulnerability Management Policies Pipeline \u0026amp; Registry: Now supports starts with, is, is not, contains, and not contains.\nRuntime: Expanded to include starts with, is, is not, contains, and not contains.\nThis update gives you more granular control and flexibility in crafting precise policies across your pipeline, registry, runtime, and admission control surfaces.\nMay 14, 2025Reduced Noise from Default Kubernetes System WorkloadsTo improve the signal-to-noise ratio of posture findings, Sysdig Kubernetes Security Posture Management (KSPM) now automatically excludes default Kubernetes system workloads and control plane-managed identities from evaluation.\nThese components, typically deployed by the Kubernetes control plane or cloud provider infrastructure, often trigger posture control violations that are expected and unactionable. By excluding them, this update significantly reduces the volume of false positives, allowing security teams to focus on real misconfigurations in user-managed workloads.\nThe result is a cleaner, more actionable posture signal. Security and platform teams will spend less time triaging noise and more time addressing meaningful risks, particularly in large or complex cluster environments.\nNo configuration changes are required; the update is applied automatically to all monitored Kubernetes clusters.\nThreatsIn Sysdig Secure, Threats combine related security signals into a single, actionable security incident. By grouping events based on shared entities, behavior, and time proximity, Threats help reduce noise, simplify triage workflows, and enhance investigative efficiency.\nKey features include:\nContext-Driven CorrelationSysdig Threat Management intelligently correlates events based on shared context, such as Kubernetes workloads, cloud identities, or attack phases. This consolidation enables teams to quickly understand the scope and criticality of threats.\nSysdig Sage: AI-Powered InsightsThreat Management leverages Sysdig Sage™, a generative AI security analyst. It enriches threats with easy-to-understand summaries and high-fidelity context, providing situational awareness for faster decision-making.\nStreamlined WorkflowsAnalysts can manage alerts more efficiently with inline management features like status changes, rule tuning, enhanced investigation, and response actions, all within a single interface.\nTo get started, see Threats.\nMay 12, 2025VM Filters on Vulnerabilities TabYou can now filter vulnerabilities by name, severity, and context, such as fix availability, known exploits, and runtime usage within the Vulnerabilities tab of Resource Details drawers. It helps you find and prioritize the most critical issues without interrupting your workflow.\nMay 08, 2025Sysdig Sage for Search Sysdig Sage for Search is now generally available, bringing AI-powered natural language search to the Sysdig Secure platform. This feature allows you to search cloud inventory and uncover security insights across AWS, GCP, and Azure using plain language; no need to write SysQL queries manually. With two powerful components - SysQL Translation and Assistant, you can ask questions like What are my EC2 instances with critical vulnerabilities? and receive structured, explainable results. Sysdig Sage automatically translates questions into SysQL and provides context to help you understand results, refine queries, and accelerate investigations. To get started, go to Inventory \u0026gt; Search in Sysdig Secure and select Sysdig Sage icon on the top right corner. For more details, see Sysdig Sage for Search May 08, 2025Response ActionsUntil today, you could respond to threats with Policy Actions, automatically, or with Rapid Response, manually, using a shell.\nIt\u0026rsquo;s now possible to respond to runtime events using the following Response Actions:\nKill/Stop/Pause container Kill process File acquire File quarantine These actions can be executed by enabled users from the Events Feed, enabling you to respond to events directly from Sysdig to contain the threat or gathering additional information for supporting the investigation. Some of the actions can also be reverted if taken by mistake or as a temporary counter-measure. To check this out, update your agents to version 13.9 or above and configure them accordingly.\nFor more information, see Response Actions\nHost Scanner v0.13.6Sysdig released a new version of the Host Scanner with the following improvements:\nFixed a defect that could cause the Host Scanner to display an error message when interacting with older versions of the Sysdig On-Prem backend. Fixed a defect where the Host Scanner failed to correctly detect Flatcar OS installations. Updated the Host Scanner to automatically perform a startup scan by default if no previous scan has been performed on the same node. Fixed the following vulnerabilities: CVE-2025-46569 CVE-2025-22871 CVE-2025-22872 May 06, 2025Automations GA with New Triggers and ActionsAutomations are now generally available (GA) with new triggers and actions available to streamline your security processes:\nOn top of the previously available Risks trigger, you can now create automations for: Vulnerability Risk Accepted: Automatically trigger processes when a vulnerability\u0026rsquo;s risk status is accepted, modified or when it will be expiring. Runtime Events: (Phased Rollout) React instantly to runtime security events. We\u0026rsquo;re enabling this trigger progressively; please reach out to your account representative or support if you\u0026rsquo;d like to activate it. Vulnerability Finding: Kick off notification and ticketing workflows the moment a new vulnerability is identified. A new action is available: You can automate the creation of Jira Tickets for new Vulnerability Findings. This requires an existing Jira integration. Automations empower you to set up custom rules that automatically respond to security events, reducing manual effort and ensuring timely actions. They help maintain audit trails and update relevant teams. For more details, see Automations.\nMay 05, 2025Vulnerability Prioritization and Findings Experience in Technical PreviewThis release includes the technical preview workflow for investigating and prioritizing vulnerabilities across your environment. The following pages have been released and are available for use:\nVulnerability Overview: A high-level dashboard to identify the most critical and exploitable vulnerabilities.\nVulnerability Findings: A filtered, actionable list of findings with deep runtime context.\nFindings Details Drawer: A detailed view of an individual finding, including package metadata, risk indicators, and remediation actions.\nCVE Details Drawer: A centralized view of a specific CVE across your infrastructure, helping assess impact and remediation coverage at scale.\nThis flow is designed to help teams reduce noise, prioritize what matters, and drive faster remediation decisions with full context.\nMay 02, 2025Improved Matching Logic for Non-OS Package Fix DatesImproved the matching logic for non-OS package fix dates when not provided by upstream vendors. This increases the effectiveness of vulnerability remediation efforts for the following ecosystems:\nnpm Go Maven PyPI NuGet RubyGems Gems Cargo Crates With this update, you can more precisely identify when a vulnerability was fixed and which package version contains the fix, improving remediation and upgrade planning for your applications.\nNew and Updated CIS Posture BenchmarksSysdig has updated the CIS Posture Benchmarks for various Kubernetes distributions. Additionally, Sysdig introduced a new Posture Benchmark policy for Microsoft Azure. These enhancements bring more robust security controls and compliance validations, aligning with industry standards for protecting cloud infrastructure and Kubernetes systems.\nKubernetes Distributions CIS Google Kubernetes Engine (GKE) Benchmark v1.5.0 CIS Google Kubernetes Engine (GKE) Benchmark v1.6.0 CIS Google Kubernetes Engine (GKE) Benchmark v1.7.0 CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.6.0 CIS Kubernetes V1.28 Benchmark CIS Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) v1.6.0 Cloud Providers Microsoft Cloud Security Benchmark For more information, see Posture Policies Included.\nApril 24, 2025Posture for Amazon BedrockSysdig Secure now extends CSPM coverage to Amazon Bedrock. You can now monitor the security posture of your Custom Models, Agents, and Knowledge Bases, and define custom controls to enforce best practices across your generative AI workloads.\nNote: Scanning Amazon Bedrock resources requires additional permissions. If you\u0026rsquo;ve already onboarded your AWS accounts, please contact Sysdig Support or reach out to your Sysdig representative. Our team will guide you through the steps to enable the necessary access.\nFor more information, see Cloud Coverage.\nApril 16, 2025Include or Exclude Accounts and OUIDs in AWS with Selective Cloud Account OnboardingSysdig now provides greater flexibility for AWS onboarding, allowing you to select specific accounts or Organizational Units (OUs) to include or exclude. This feature enables more targeted monitoring configurations from the start, simplifying the setup process for organizations that don\u0026rsquo;t require visibility across every account in their AWS infrastructure. Use the Include/Exclude options during onboarding to focus monitoring resources where it is needed most. For more information, see Selective Cloud Account Onboarding.\nApril 11, 2025Sysdig CLI Scanner 1.22.1A new version of the CLI scanner is available with the following improvements:\nFixed a defect in the Amazon vulnerability feed where scans of amazoncorretto:17.0.14 would mistakenly detect irrelevant vulnerabilities. Added fixes for the following vulnerabilities: CVE-2025-30204 April 10, 2025Enhanced Network Exposure DetectionSysdig has enhanced our network exposure detection capabilities with broader resource coverage and the ability to identify multiple exposure paths. With this release, you can now discover multiple network exposure paths for each resource resource, giving you deeper insight into your cloud network security.\nNewly supported resource types include:\nClassic Load Balancers Security Groups Subnets Route Tables Internet Gateways In the following weeks, we will add support for:\nNetwork Load Balancers (NLB) Application Load Balancers (ALB) Target Groups Managed Kubernetes resources This feature is available by default in Secure SaaS. You can see if a resource is exposed through the Exposure tab of the Resource Details drawer.\nFor more details, such as the supported resource types, see the Exposure Tab.\nEnhanced Health Status for Cloud Accounts and Sysdig FeaturesSysdig has improved the onboarding experience with meaningful and actionable status messages for your cloud accounts and Sysdig features. The enhanced Health status provides clear, actionable status updates for cloud accounts and Sysdig features, both during onboarding and ongoing operation. With the tailored remediation guidance based on cloud provider, Sysdig features, and specific status messages, Health Check simplifies troubleshooting and improves the onboarding experience.\nFor more information, see:\nAWS Connection Status for CSPM Connection Status for VM Azure Connection Status for CSPM Connection Status for VM GCP Connection Status for CSPM Connection Status for VM OCIConnection Status for CSPM\nApril 08, 2025Multi-Factor AuthenticationUsers can now enable Multi-Factor Authentication (MFA) to add an additional layer of validation to their login. Once enabled, each login to Sysdig Monitor or Sysdig Secure must be validated with an authenticator app, such as Okta Verify or Google Authenticator. This improves your login security. For more details, see Multi-Factor Authentication.\nApril 04, 2025Host Scanner v0.13.5Sysdig released a new version of the Host Scanner with the following improvements:\nFixed a defect where the host scanner was not getting the cluster name for windows host scans. Added the label gcp.instance.name. Added fixes for the followings vulnerabilities: CVE-2024-40635 April 03, 2025Enhanced Resource Drawers in RiskSysdig has improved the Risk experience with enhancements to the Resource details drawer. Now, when you select an Affected Resource under a Risk, or on the Inventory \u0026gt; Resources page, you can access everything Sysdig knows about the affected resources and relevant findings, such as vulnerabilities, events, misconfigurations, and metadata.\nFor more details, see View Resource Details.\nIdentity Risk without Log IngestionSysdig now provides Basic CIEM (Cloud Infrastructure Entitlement Management) analysis as a standard functionality within CSPM (Cloud Security Posture Management), without requiring log ingestion.\nRisk Policies such as Risky AWS Users and Data Exfiltration Risk in 1 Hop are available. Additional risks will be enriched with optional findings such as Permission Criticality, No MFA, and Administrative Access. You can access these configuration-based findings using Search.\nThe previous CIEM experience is now called Advanced CIEM, which includes analysis of in-use permissions and tailored remediations, such as Least Privilege Policy Optimization.\nFor more information, see Connect Cloud Accounts.\nMarch 31, 2025Posture for Windows Server in Standalone HostsSysdig now provides compliance scanning for Windows Server standalone hosts, enabling security and regulatory compliance checks for Windows environments. This feature helps organizations enforce compliance policies and detect security misconfiguration.\nWith this new feature, Sysdig provides two new out-of-the-box policies:\nCIS Windows Server 2022 Benchmark v3.0.0 CIS Windows Server 2019 Benchmark v3.0.1 These policies help organizations leveraging Windows Server standalone hosts align with industry standards like CIS, NIST, and ISO 27001.\nThis feature only supports standalone Windows Server hosts. It does not apply to Windows Server nodes running inside Kubernetes clusters, or Containers based on Windows images.\nFor installation, see Windows Hosts.\nFor more information, see Posture Policies Included.\nSupport for Host Scanning for Windows ServerSysdig now provides coverage for Windows Server 2019 and 2022 with the GA Release of with Sysdig Host Shield for Windows 0.7.0\nThis release provides coverage for Windows Server Operating System Vulnerabilities sourced sourced from Microsoft Security Response Center.\nIn addition Sysdig Host Shield will detect any non-OS Package Vulnerabilities for supported languages\nMarch 28, 2025CSV Export for Search and Time-based QueriesSearch has been enhanced with the following functionalities:\nIntuitive Time-Based Queries: The Query Builder now includes a calendar picker and logical operators to easily filter and compare time-based attributes. CSV Export and Download History: You can now export Graph Search results as a CSV file for further analysis. The Download History option allows you to retrieve previously generated CSVs. For more information, see Search.\nCSPM Health ManagementCSPM Health Management is now available in the Integrations page under Cloud Accounts in the Secure UI. This feature provides visibility into the health of cloud scans, helping users identify ingestion issues, coverage gaps, and scan failures.\nKey capabilities are:\nMonitor CSPM health across AWS, Azure, Google Cloud, OCI, and IBM Cloud Identify ingestion issues affecting cloud resource visibility Track scan execution status and troubleshoot failures This enhancement ensures continuous policy enforcement and better visibility into CSPM operations.\nNew and Updated CIS Posture BenchmarksSysdig has updated the the CIS Posture Benchmarks for cloud service providers. In addition, we are introducing new CIS Posture Benchmark policies for Linux distributions. These updates include improved security controls and compliance checks, ensuring stronger alignment with industry best practices for securing cloud environments and Linux operating systems.\nCloud Providers CIS Amazon Web Services Foundations Benchmark v4.0.1 CIS Amazon Web Services Foundations Benchmark v4.0.0 CIS Google Cloud Platform Foundation Benchmark v3.0.0 CIS Microsoft Azure Foundations Benchmark v3.0.0 CIS Microsoft Azure Foundations Benchmark v2.1.0 Linux Distributions CIS Amazon Linux 2 Benchmark v3.0.0 CIS Google Container-Optimized OS Benchmark v1.2.0 CIS Talos Linux Benchmark v1.0.0 For more information, see Posture Policies Included.\nMarch 27, 2025Google Kubernetes Engine (GKE) Autopilot Security Posture Management (CSPM) SupportWe are excited to announce full security posture management (CSPM) support for Google Kubernetes Engine (GKE) Autopilot in Sysdig Secure. With this release, security and DevOps teams can now detect misconfigurations, enforce security policies, and ensure compliance across their managed Kubernetes workloads in Google Cloud.\nAdditionally, this release includes the CIS Google Kubernetes Engine (GKE) Autopilot Benchmark policy, enabling you to assess your clusters against industry best practices.\nFor more information, see Posture Policies Included.\nMarch 26, 2025Tenant-Aware Hierarchical Posture ScanningSysdig is excited to announce the release of Tenant-Aware Hierarchical Posture Scanning, a new capability designed to streamline posture management in multi-tenant environments. This feature allows parent tenants to seamlessly integrate posture scanning results from child tenants, ensuring consistent policy application and reporting while eliminating the need for complex cross-region data transfers.\nFor more information, see Tenant-Aware Hierarchical Posture Scanning.\nImproved Resource DrawerSysdig has released a major improvement to the Resource Details drawer. Now, when you select a resource in Inventory \u0026gt; Search, you can see everything Sysdig knows about a resource — all of its findings, vulnerabilities, events, misconfigurations, metadata, environment information, and more. This allows you to get the data you need, when you need it, all in one place.\nFor details, see View Resource Details.\nMarch 25, 2025Registry Scanner v0.8.0 Added support for the following Operating Systems: PhotonOS CBL Mariner Azure Linux Suse Enterprise Linux 12 and 15 Suse Micro Linux Microsoft Windows Added the config.scan.jobs.resources.limits.cpu parameter to allow configuring the CPU limits of the worker jobs. Added fixes for the followings vulnerabilities: CVE-2025-30204 CVE-2025-22870 CVE-2025-22869 CVE-2025-24928 CVE-2024-56171 March 24, 2025Linux Host Support for In-UseStarting with Linux Host Shield v13.8.0, Sysdig can recognize In-Use Packages on hosts.\nThis addition extends Sysdig coverage and helps reduce scope of vulnerabilities you should care about first for remediation; further reducing noise in an ever expanding VM landscape.\nFor more information, see In-Use.\nSysdig CLI Scanner 1.22.0 Adopted a new Fix Date process to align with the Vendor Fix Dates. Added the --platform parameter to scan a specific platform for a given image. See docs here Resolved a defect in Windows image scanning where fix versions are not processed correctly, leading to potential false negatives or incorrect fix versions. Added backend scanning support for the following Operating Systems: PhotonOS CBL Mariner Azure Linux Suse Enterprise Linux 12 and 15 Suse Micro Linux Microsoft Windows For full coverage, see Vulnerability Feeds.\nMarch 19, 2025Reporting Vulnerability Management Fix DateHistorically, Sysdig aligned all vulnerabilities to VulnDB’s fix dates. Moving forward, Sysdig will align fix dates based on the following priority order:\nVendor Fix Dates: Vender fix dates will serve as Sysdig\u0026rsquo;s primary reference where applicable, ensuring alignment with vendor recommendations and fix availability. NVD Fix Dates: If vendor dates are unavailable, Sysdig will rely on the National Vulnerability Database fix dates. VulnDB Fix Dates: VulnDB fix dates will serve as a fallback when neither of the above options are available. If you are using the following components, these changes will be applied automatically, with no action required, when using Sysdig backend Scanning components, such as Cluster Shield, Host Shield, and Registry Scanner (where enabled).\nThe CLI Scanner users will receive this change in the 1.22.0 release.\nVulnerability Management Operating System CoverageAdded support for the following Operating Systems:\nPhotonOS (Host and Container) CBL Mariner (Host and Container) Azure Linux (Host and Container) Suse Enterprise Linux 12 and 15 (Host and Container) Suse Micro Linux (Host and Container) Microsoft Windows (Host and Container Images with CLI only) These Operating Systems are available for Scanning with Sysdig backend enabled components in the following versions:\nLinux Host Shield 13.8.1 Windows Host Shield 0.7.0 Cluster Shield 1.10.0 CLI Scanner 1.22.0 Activity Audit Data Retention UpdateFrom today, the retention period for File Accesses (File) and Connections (Net) entries in Activity Audit has been reduced to 7 days. Kubernetes and Commands (Cmd) continue to be retained for 90 days.\nIf you need to retain events for longer periods, you can use Events forwarding to send logs to a storage solution of your choice. Additionally, Captures let you take snapshots of all the activity happening on the host when an event occurs, supporting you in triage and investigation.\nFor more details, see Data retention.\nMarch 18, 2025Host Scanner v0.13.4Sysdig released a new version of the Host Scanner with the following improvements:\nFixed a defect where the host scanner would generate excessive logs if the Docker or Podman daemon restarted or disconnected. Fixed a defect on Mariner detection. Added fixes for the followings vulnerabilities: CVE-2025-22869 CVE-2025-22870 March 12, 2025SysQL EditorYou can now write and edit SysQL queries directly in the SysQL Editor. To access it, click the SysQL Editor icon on the top left of the Search page. Alternatively, open the three-dot menu in the Query Builder and select Edit in Code Editor.\nThis feature is in addition to the following options:\nQuery Builder Sysdig Sage-based search For more information, see Search.\nFebruary 27, 2025SysQL Public APISysQL query language helps you query Sysdig Secure datastore. To help you programmatically interact with the Sysdig datastore over REST, Sysdig has released the following SysQL Public APIs:\nGET /api/sysql/v2/query POST /api/sysql/v2/query GET /api/sysql/v2/schema You can use these APIs to execute standard SysQL statements and query resource metadata stored in the datastore.\nFor more information, see:\nSySQL API Documentation SySQL Reference Library CLI Scanner v1.21.0Sysdig released a new version of the CLI Scanner with the following improvements:\nAdded support for Windows Container images. Added support to Photon OS and SUSE. Improved model for managing package versions and version ranges, reducing false positives and false negatives. Improved the precision of matching RHEL custom Java package versions. Added support for “known not affected” vulnerabilities for CentOS, reducing false positives. Optimized vulnerability database to reduce disk space usage, memory consumption, and CPU load. February, 25, 2025S3 Log IngestionSysdig now supports another integration option to provide Cloud Detection and Response (CDR) and Identity \u0026amp; Access Management (IAM) features on AWS. Previously, only EventBridge was supported. From today, you can also integrate through S3. This gives you the option to choose between a faster but more expensive EventBridge method, or the more budget-friendly S3 method, while still providing runtime security coverage for your AWS accounts.\nTo set up log ingestion with S3, see Configure CDR and CIEM for AWS.\nRegistry Scanner v0.7.5 Fixed a defect that prevented Registry Scanner from detecting vulnerabilities in Amazon Linux images. Added fixes for the followings vulnerabilities: CVE-2024-12797 CVE-2019-12900 CVE-2020-11023 CVE-2022-49043 February 18, 2025Host Scanner v0.13.2Sysdig released a new version of the Host Scanner with the following improvements:\nFixed a regression bug introduced in v0.13.1 that made the application unresponsive on some redhat distributions. February 13, 2025CLI Scanner v1.20.0Sysdig released a new version of the CLI Scanner with the following improvements:\nYou can now export the vulnerabilities list in CSV format, either to standard output or as a CSV file. Added fixes for the followings vulnerability: CVE-2024-11218 For more details, see Running in VM Mode\nFebruary 12, 2025Policy Unification for Vulnerability ManagementSysdig lets you to create unified Vulnerability Management Policies, streamlining policy management across all stages—Pipeline, Registry, Runtime, and Admission Control. This enhancement brings unified policy definitions, greater flexibility with scope filters, and expanded support for registry policies.\nRegistry Policy Support: Policies can now be applied to images scanned in registries, expanding coverage to all critical stages of your software development lifecycle. Unified Policy Definition: Policies are now defined once with a set of rules and scope filters. These policies can then apply to any or all stages—Pipeline, Registry, Admission Control, and Runtime—reducing complexity and duplication. Image Name scope for All Stages: Policies can now be scoped using filters such as Image Reference (also known as Image Name or Pullstring), enabling granular control and consistency across Pipeline, Registry, Runtime, and Admission Control. The new unified policy system is available to all users of Vulnerability Management. Any existing policies remain functional. Existing policies will be converted automatically to an equivalent policy in the new unified model.\nFor more information, see Vulnerability Management Policies.\nMLPS 2.0 and ITSG-33 Compliance Policies for China and CanadaSysdig has expanded its compliance coverage with two new policies:\nMulti-Level Protection Scheme (MLPS) 2.0: China’s cybersecurity framework, defining four security levels based on system importance, risk impact, and required protections. Organizations must assess their level and implement corresponding controls, with Level 2+ systems requiring certified evaluations. Information Technology Security Guidance (ITSG-33): Canada’s cybersecurity standard, providing a structured catalog of security controls across Technical, Operational, and Management categories to support government security assurance. These frameworks are critical for organizations operating in China and Canada, ensuring compliance with regulatory expectations and strengthening cybersecurity postures.\nFor more information, see Posture Policies.\nFebruary 10, 2025OCI Support Now Generally AvailableOracle Cloud Infrastructure (OCI) support is now generally available across all regions. This milestone builds on Sysdig\u0026rsquo;s Controlled Availability (CA) phase, delivering multi-regional scanning for enhanced security visibility. OCI support is now available by default for all customers. Get started by onboarding your OCI tenants and compartments and leveraging Sysdig multi-region scanning to strengthen your cloud security posture.\nKey Features:\nMulti-Regional Scanning: You can now assess your OCI security posture across multiple OCI regions, ensuring comprehensive coverage. Performance Enhancements: Improved efficiency in ingesting and processing OCI security findings within Sysdig Graph. Expanded Coverage: Security insights now span multiple regions, eliminating blind spots. Graph-Based Security Analytics: Fully integrated OCI resources and findings into Sysdig’s Graph, enabling deeper security correlation and the creation of Custom Risks. Out-of-the-box Compliance: An extensive library of 46 compliance policies with 103 controls specific to OCI. February 07, 2025Host Scanner v0.13.1 Added fixes for the followings vulnerabilities: CVE-2024-45336 CVE-2024-45341 Registry Scanner v0.7.4 Added a new parameter to enforce the use of Federal Information Processing Standards (FIPS) images.\nTo perform this enforcement, set image.fips: true. For more details, see the Registry Scanner Helm Chart.\nFixed a defect where the registry scanner was not using the correct FIPS validated endpoints for Amazon Elastic Container Registry (ECR) installations.\nTo use Registry Scanner v0.7.4, update Helm charts to version 1.6.8. To do this, run helm repo update.\nFebruary 05, 2025Runtime Scanner v1.8.2 Added fixes for the followings vulnerabilities: CVE-2024-34155 CVE-2024-34156 CVE-2024-34158 CVE-2024-45336 CVE-2024-45337 CVE-2024-45338 CVE-2024-45339 CVE-2024-45341 CVE-2024-8260 February 04, 2025Registry Scanner v0.7.3 Fixed a defect where the registry skipTLS was not being honored for AWS ECR installations Added fixes for CVE-2024-45339 February 03, 2025Oracle Cloud Infrastructure (OCI) Support ReleaseSysdig is excited to announce out-of-the-box (OOTB) support for Oracle Cloud Infrastructure (OCI), enabling you to seamlessly onboard your OCI tenants and compartments into Sysdig Secure.\nKey Features:\nCSPM (Posture and Compliance) Support: Full visibility into your OCI resources, with actionable insights into posture and compliance findings. Automated assessments aligned with industry best practices and compliance standards. Compliance Policies: A robust library of 46 compliance policies, covering regulatory frameworks and security benchmarks tailored for OCI environments. CIS Benchmarks: Dedicated policies for OCI and OKE: OCI Benchmarks: 51 controls. OKE Benchmarks: 52 controls. Graph-Based Security \u0026amp; Custom Risk Creation: All OCI resources and findings are fully ingested into Sysdig’s Graph. This means: Resources and findings are accessible via Graph Search and SysQL. You can create Custom Risks by leveraging graph-based queries and correlations. OCI data is seamlessly integrated with other multi-cloud security insights in the platform. This release delivers comprehensive coverage for OCI, ensuring compliance, enhanced security posture, and a faster path to meeting governance standards. With a total of 46 supported policies, your OCI workloads are secured and aligned with best practices.\nFor instructions on setup, onboarding OCI tenants, and accessing compliance reports, see Connect Oracle Cloud.\nJanuary 30, 2025Registry Scanner v0.7.2Fixed a defect where the main job tries to grab logs from the workers.\nAdded fixes for the followings vulnerabilities: CVE-2024-45336 CVE-2024-45341 January 27, 2025New Compliance Policies for CAF, SOX, and FISMAThe following policies expand compliance coverage and enhance security:\nNCSC Cyber Assessment Framework (CAF): Aligns with the UK National Cyber Security Centre (NCSC) guidelines for assessing and improving cyber resilience. Sarbanes-Oxley (SOX) Act: Ensures compliance for financial reporting controls and regulations. Federal Information Security Modernization Act (FISMA): Supports compliance with US federal information security standards. For more information, see Posture Policies Included.\nEvent Feed GroupingIn the Events Feed in the Threats module, you can now group events in a variety of ways, such as by policy, rule, clusters, workloads and cloud accounts. This lets you construct useful lists of events according to your needs. For more details, see Group By.\nJanuary 22, 2025CLI Scanner v1.19.2Sysdig released a new version of the CLI Scanner to fix a defect that caused an error in the policies evaluation in on-prem environments.\nJanuary 21, 2025New Posture Policies for AKS, OpenShift, FERPA, GLBA, and NERC CIPThe following policies have been added to enhance security and compliance across key platforms and regulations:\nCIS Azure Kubernetes Service (AKS) Benchmark v1.5.0: Offers improved security guidance for Azure Kubernetes environments based on the CIS v1.5.0 benchmark. CIS Azure Kubernetes Service (AKS) Benchmark v1.6.0: Incorporates the latest best practices to ensure compliance with the CIS v1.6.0 benchmark for AKS. CIS Red Hat OpenShift Container Platform Benchmark v1.6.0: Enhances compliance for OpenShift environments in accordance with the CIS v1.6.0 benchmark. CIS Red Hat OpenShift Container Platform Benchmark v1.7.0: Strengthens compliance for OpenShift environments in alignment with the CIS v1.7.0 benchmark. Family Educational Rights and Privacy Act (FERPA): Ensures compliance with data privacy and security requirements for educational institutions handling student records. Gramm-Leach-Bliley Act (GLBA): Supports financial institutions in meeting data security and privacy obligations under GLBA. NERC Critical Infrastructure Protection (CIP): Addresses the cybersecurity requirements for bulk electric system entities, ensuring compliance with NERC CIP standards. For more information, see Posture Policies Included.\nJanuary 16, 2025Host Scanner v0.13.0Sysdig released a new version of Host Scanner with the following improvements:\nSupport for OpenSUSE and AlmaLinux Added the HOST_DIRS_TO_SKIP environment variable with the possibility to specify a list of folders to skip while scanning the host Added the IGNORE_CONTAINER_SCAN_INIT_FAILURE environment variable, which can be configured to continue operation when container scanning is enabled and the host-scanner fails to connect to container runtimes socket Fixed a defect that prevented Cloud and K8s metadata to be propagated to the backend when performing container scanning Fixed a defect that could prevent the scan result to be generated if the host had a large number of kernels installed Fixed the CVE-2024-45338 vulnerability January 14, 2025Vulnerability Management API v1Sysdig has upgraded the existing Vulnerability Management API to v1. The API v1 enhances consistency and alignment with platform API standards, and offers improved response schema. See Vulnerability Management API V1 for more information.\nNote that the v1beta1 version of the API will be retained for backward compatibility during the following 6 months, with no further changes or evolution. If you are using the older version, we recommend that you upgrade to v1.\nJanuary 10, 2025CLI Scanner v1.19.0Sysdig released a new version of the CLI Scanner with the following improvements:\nSupport for OpenSUSE and AlmaLinux\nAdded support for Red Hat Extended Update Support (EUS) feed\nAdded fixes for the followings vulnerabilities:\nCVE-2025-21613 CVE-2024-45337 CVE-2024-45338 CVE-2024-9675 CVE-2025-21614 CVE-2024-51744 Vulnerability Detection Supported on AlmaLinux and OpenSUSEYou are now able to detect, generate SBOMs, and receive scan results using the CLI Scanning, Host Scanner, and Agentless Scanning on AlmaLinux and OpenSUSE platforms.\nJanuary 08, 2025Track Risk Acceptance Actions of UsersSysdig has enhanced its Vulnerability Management capabilities by introducing the ability to track user actions related to risk acceptance. You can now easily discover:\nWhich user created the risk Which user last updated the risk When these actions occurred These enhancement provide greater transparency and control over risk acceptance and update workflows, enabling you to manage vulnerabilities more effectively.\nFor more information, see Accepted Risk for Vulnerabilities.\nJanuary 07, 2025Full Custom Controls for KubernetesSysdig now offers the ability to create Custom Controls for Kubernetes via Terraform. You now can create controls from scratch by defining your own REGO code, remediation playbooks, and control severity.\nFor more information, see Create Custom Controls with Terraform.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/2025-archive/"},{"id":3,"title":"Install and Configure Admission Controller","content":"Prerequisites Cluster Shield version 1.13.0 or higher.\nSysdig Secure SaaS\nSysdig Shield installed. See Install Shield on Kubernetes.\nEnsure Admission Controller is enabled for your account. If it isn\u0026rsquo;t, contact Sysdig Support.\nInstallationThe Admission Controller is installed as part of the Sysdig Shield deployment. To enable Admission Controller, deploy or upgrade the shield Helm chart with the following parameters:\nhelm upgrade --install --atomic --create-namespace \\ --namespace sysdig \\ --set cluster_config.name=ac-cluster \\ --set sysdig_endpoint.region=\u0026lt;SaaS Region Code\u0026gt; \\ --set sysdig_endpoint.access_key=\u0026lt;your-access-key\u0026gt; \\ --set features.admission_control.enabled=true \\ --set features.admission_control.container_vulnerability_management.enabled=true \\ --set features.admission_control.posture.enabled=true \\ shield sysdig/shield By default, the Admission Controller is installed with dry_run: true. This means no workloads will be blocked immediately after installation. Policy violations are only logged, not enforced.\nVerificationAfter deployment, confirm the Admission Controller is correctly installed and the webhooks are registered:\nkubectl get validatingwebhookconfigurations | grep shield Look for a webhook configuration named shield-cluster-admission-control. For more detail:\nkubectl describe validatingwebhookconfigurations shield-cluster-admission-control The Sysdig Admission Controller should now be enabled and you can now configure policies and actions to block deployments using Vulnerability Policies or Posture Policies.\nAdvanced ConfigurationsDry Run ModeDry Run is a mode in the Admission Controller that simulates policy evaluations without enforcing rejections. It allows users to preview the results of the Admission Controller without actually blocking workloads. This helps you verify that your Admission Controller and related Vulnerability Policies or Posture Policies work as expected before triggering Warning or Failure actions.\nWhen To Use Dry RunUse dry_run only in these cases:\nYou don\u0026rsquo;t have a non-prod environment, such as dev or stage, to test blocking policies. You\u0026rsquo;re doing early-stage policy experimentation and want to gather data before enforcing. You want to monitor new policies in production before turning on enforcement. This is sometimes referred to as \u0026ldquo;shadow enforcement\u0026rdquo;. You want to validate custom controls or third-party controls in a live system without causing disruption. When Not To Use Dry Run Don\u0026rsquo;t use dry_run as a long-term substitute for environment-based policy promotion. Don’t assume dry_run covers all policy behavior; some logic (e.g. ordering, dependencies) might not behave exactly the same. Don’t rely on it to validate what would have been blocked unless the tooling explicitly shows that. Dry Run Limitations dry_run only simulates a real “rejection” flow. No workload is blocked and no webhook failed. You cannot test the behavior of failure_policy settings with it. You cannot dry-run only a subset of policies; it\u0026rsquo;s all-or-nothing unless scoped in config. Best Practices For policy testing, we recommend non-prod environments, such as dev or stage, with real enforcement. Use dry_run in combination with logging to understand the impact of new policies before enforcing. By default, the Admission Controller is installed with dry_run: true. This means no workloads will be blocked immediately after installation.\nTo disable Dry Run mode, pass the following configuration settings to the shield chart:\nfeatures: admission_control: # Enable the admission control feature enabled: true # The policy to apply when a request is denied failure_policy: Ignore # Set dry_run to false to block non-compliant workloads dry_run: false # The timeout for the admission control feature timeout: 10 # The port that will be used to expose admission control endpoints http_port: 8443 # The list of namespaces that will be excluded from the admission control excluded_namespaces: [] container_vulnerability_management: # Enable the container vulnerability management feature on the admission control enabled: true posture: # Enable the posture feature on the admission control enabled: true Vulnerability-only ConfigurationEnable the Vulnerability-only configuration for the Admission Controller if you only want to check your deployments against the Vulnerability Admission Policies.\nEnsure the individual cluster or resources are within the scope of the defined policies.\nPass the following configuration settings to the shield chart:\nfeatures: admission_control: # Enable the admission control feature enabled: true # The policy to apply when a request is denied failure_policy: Ignore # Set dry_run to false to block non-compliant workloads dry_run: false # The timeout for the admission control feature timeout: 10 # The port that will be used to expose admission control endpoints http_port: 8443 # The list of namespaces that will be excluded from the admission control excluded_namespaces: [] container_vulnerability_management: # Enable the container vulnerability management feature on the admission control enabled: true posture: # Enable the posture feature on the admission control enabled: false Posture-only ConfigurationEnable the Posture-only configuration for the Admission Controller if you only want to check created resources against the Posture Admission Policies.\nEnsure the clusters or resources are within the scope of the defined policy.\nPass the following configuration settings to the shield chart:\nfeatures: admission_control: # Enable the admission control feature enabled: true # The policy to apply when a request is denied failure_policy: Ignore # Set dry_run to false to block non-compliant workloads dry_run: false # The timeout for the admission control feature timeout: 10 # The port that will be used to expose admission control endpoints http_port: 8443 # The list of namespaces that will be excluded from the admission control excluded_namespaces: [] container_vulnerability_management: # Enable the container vulnerability management feature on the admission control enabled: false posture: # Enable the posture feature on the admission control enabled: true Exclude NamespacesTo exclude specific namespaces from evaluation, add them to the Admission Controller exclusion list. The controller will skip these namespaces entirely, even if your Vulnerability Policies or Posture Policies normally include them.\nPass the following configuration settings to the shield chart:\nfeatures: admission_control: # Enable the admission control feature enabled: true # The policy to apply when a request is denied failure_policy: Ignore # Default: dry_run is true (no enforcement, only simulated) dry_run: true # The timeout for the admission control feature timeout: 10 # The port that will be used to expose admission control endpoints http_port: 8443 # The list of namespaces that will be excluded from the admission control excluded_namespaces: [\u0026#34;kube-system\u0026#34;, \u0026#34;sysdig\u0026#34;, \u0026#34;example-app\u0026#34;] container_vulnerability_management: # Enable the container vulnerability management feature on the admission control enabled: true posture: # Enable the posture feature on the admission control enabled: true Change the Failure PolicyThe Sysdig Admission Controller supports the standard Kubernetes failurePolicy configuration, which determines how the API server handles errors from the Admission Controller.\nFailWith this configuration, if the Admission Controller encounters an error or is unreachable, the API server will reject the admission request. This is the default behavior, ensuring that no unverified or potentially unsafe objects are created.\nPass the following configuration settings to the shield chart:\nfeatures: admission_control: # Enable the admission control feature enabled: true # The policy to apply when a request is denied failure_policy: Fail # Set dry_run to false to block non-compliant workloads dry_run: false # The timeout for the admission control feature timeout: 10 # The port that will be used to expose admission control endpoints http_port: 8443 # The list of namespaces that will be excluded from the admission control excluded_namespaces: [] container_vulnerability_management: # Enable the container vulnerability management feature on the admission control enabled: true posture: # Enable the posture feature on the admission control enabled: true IgnoreWith this configuration, if the admission controller encounters an error or is unreachable, the API server will allow the admission request to proceed. This can help avoid disruptions if the webhook is temporarily unavailable but may allow unverified objects.\nPass the following configuration settings to the shield chart:\nfeatures: admission_control: # Enable the admission control feature enabled: true # The policy to apply when a request is denied failure_policy: Ignore # Set dry_run to false to block non-compliant workloads dry_run: false # The timeout for the admission control feature timeout: 10 # The port that will be used to expose admission control endpoints http_port: 8443 # The list of namespaces that will be excluded from the admission control excluded_namespaces: [] container_vulnerability_management: # Enable the container vulnerability management feature on the admission control enabled: true posture: # Enable the posture feature on the admission control enabled: true For more details, see the Kubernetes documentation on failurePolicy.\nSet the Request TimeoutKubernetes API servers enforce a maximum timeout of 30 seconds for all admission webhook calls. If a webhook does not respond within this window, the API server treats the call as a timeout and applies the webhook’s failure_policy (Fail or Ignore) to determine whether to accept or reject the admission request.\nKey Points:\nThe maximum value for timeout is 30 seconds. If timeout is not set, the default is 10 seconds. The API server will never wait longer than 30 seconds, even if a higher value is configured. If the webhook does not respond in time, the API server applies the configured failure_policy in the Sysdig Shield chart. To achieve this and increase your Validating Webhook timeouts the following configuration can be passed to the Sysdig Shield chart:\nBy configuring a longer timeout you may impact your deployment and kubectl command execution times if the Validating Webhook is not returned in a timely fashion.\nfeatures: admission_control: # Enable the admission control feature enabled: true # The policy to apply when a request is denied failure_policy: Ignore # Set dry_run to false to block non-compliant workloads dry_run: false # The timeout for the admission control feature timeout: 30 # The port that will be used to expose admission control endpoints http_port: 8443 # The list of namespaces that will be excluded from the admission control excluded_namespaces: [] container_vulnerability_management: # Enable the container vulnerability management feature on the admission control enabled: true posture: # Enable the posture feature on the admission control enabled: true ","url":"https://docs.sysdig.com/en/sysdig-secure/admission-controller/installation/"},{"id":4,"title":"Architecture \u0026 System Requirements","content":"Visit the onprem-install-docs repository to:\nReview on-prem release versions. Each release is tested on several platforms and Kubernetes orchestrators. Select an on-premises version and navigate to the release note page to view the supported platforms. Find installation instructions. ","url":"https://docs.sysdig.com/en/administration/onprem-arch-system-req/"},{"id":5,"title":"Azure Container Apps","content":"PrerequisitesSysdig A Sysdig Secure account and the Agent Access Key\nThe endpoint of the Sysdig Collector for your region\nNetwork access to the Sysdig Collector from the deployed Workload Agent.\nNetwork access to the Sysdig Collector from the deployed Workload Agent. The Workload Agent requires outbound traffic permissions on port 6443 to communicate with the Collector.\nDeploy the Sysdig Workload AgentThe Serverless Workload Agent consists of two key components packaged together:\nAn instrumentation application that monitors the workload. An agent that gathers security events from the instrumentation application and transmits them to the Sysdig collector. To deploy the Sysdig Workload Agent, embed it into the Docker image of your workload application.\nInstrument the Workload ImageThe instructions given here are generic and apply to any Dockerfile.\nThis example uses sysdiglabs/security-playground as the original workload to secure. It is a sample application that offers endpoints for triggering security events.\nGiven the original Dockerfile:\nFROM python:3.9-slim RUN pip install --upgrade pipenv WORKDIR /app COPY . . RUN pipenv install --system --deploy EXPOSE 8080 ENTRYPOINT [\u0026#34;./entrypoint.sh\u0026#34;] You can instrument it as follows:\nFROM quay.io/sysdig/workload-agent:latest AS workload-agent FROM python:3.9-slim RUN pip install --upgrade pipenv WORKDIR /app COPY . . RUN pipenv install --system --deploy COPY --from=workload-agent /opt/draios /opt/draios EXPOSE 8080 ENTRYPOINT [\u0026#34;/opt/draios/bin/instrument\u0026#34;, \u0026#34;./entrypoint.sh\u0026#34;] In detail:\nThe Sysdig Workload Agent is added as a separate layer and then copied into the image file system under /opt/draios. The Sysdig application, /opt/draios/bin/instrument, is prepended to the original ENTRYPOINT to secure the original workload application at runtime. The secured container image is now ready to be built and deployed as you would with your original image.\nDeploy the Secured ImageYou can deploy the secured container image like you do the original one, using the additional Sysdig environment variables that are required for the Workload Agent to connect to the Sysdig Collector:\nSYSDIG_COLLECTOR and SYSDIG_COLLECTOR_PORT: Used to reach the Sysdig Collector for your region.\nSYSDIG_ACCESS_KEY: The Agent Access Key to authenticate with the Sysdig Collector.\nSYSDIG_WORKLOAD_ID: The identifier for each secured workload. It must be unique for each instrumented container in the revision.\nProvide these variables to the container in the deployment configuration, either as plain environment variables or secrets.\n","url":"https://docs.sysdig.com/en/sysdig-secure/azure-container-apps/"},{"id":6,"title":"Connect Cloud Accounts to Sysdig Monitor","content":"Google Cloud Platform MetricsThe GCP integration allows you to ingest GCP platform metrics into Sysdig. With this integration, you can monitor your GCP infrastructure resources in one location, and get insight into the health and status of your GCP cloud services and workload in realtime.\nMicrosoft Azure Cloud MetricsThe Azure Monitor integration allows you to ingest Azure cloud platform metrics via Azure Monitor into Sysdig so you can monitor all of your Azure and other infrastructure resources in one location. The Azure Monitor integration extends Sysdig’s visibility into the heath \u0026amp; status of your Azure cloud services and workloads so you can monitor all available Azure services in realtime and correlate status of and changes to your cloud infrastructure against application and infrastructure performance.\nAmazon CloudWatch Metric StreamsAmazon CloudWatch is a monitoring service that collects monitoring and operational data in the form of logs, metrics, and events. AWS Metric Streams allows AWS users to export metrics from key AWS services faster by eliminating the need for custom integrations for each AWS resource. The AWS users can send these streams of metric data to different endpoints, such as Sysdig, through an Amazon Data Firehose HTTPS endpoint.\nSysdig Monitor collects CloudWatch metrics from various AWS services and custom namespaces to provide comprehensive visibility of your AWS resources, applications, and services running on AWS. Sysdig provides a CloudFormation template to help you configure an AWS account for metric streaming to Sysdig.\nThis capability is in addition to the existing support to collect AWS CloudWatch metrics by using CloudWatch APIs.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/cloud-accounts/"},{"id":7,"title":"Cloud Accounts","content":"Use the account overviews to:\nConfirm that the incoming data sources you expected are present. Get an overview of the status. Access Cloud AccountsLog in to Sysdig Secure, select Integrations \u0026gt; Cloud Hosts, and choose:\nAWS GCP Azure On each page, you can review details or connect an additional account.\nAdd AWS AccountsTo connect an account, select + Add AWS Account, and follow the instructions in the installation pop-up wizard.\nFor detailed onboarding instructions, see Connect Cloud Account | AWS.\nReview AWS Cloud AccountsThe page lists:\nAccount: AWS Account ID, followed by an Account Alias if one was assigned When an account alias is assigned, the platform filters are configured to recognize only the account alias, not the account ID. To locate specific results within the inventory page, use the account alias.\nStatus: The Status of each AWS Account you have connected.\nPossible values: Connected, Pending, Partial Error, Error, Unknown. For more on status values, see Validate Account Connection. Last Checked: Time at which a feature was last validated. Validation occurs every 24 hours.\nOrg ID: ID of the Organization to which the Account belongs, if applicable.\nAdded On: Date the Account was added to Sysdig Secure.\nValidate Account ConnectionThere are two types integration status displayed, Feature level status, and Account level status. Statuses are validated approximately every 24 hours, with the first check occurring within an hour of enabling a feature.\nIf there are connection errors, if you remediate them, the status will be updated on the page when the validation is run again, up to 24 hours later.\nFeature StatusWhen you connect a cloud account to Sysdig Secure, select the Sysdig features you would like to enable, such as Cloud Security Posture Management (CSPM), Cloud Infrastructure Entitlements Management (CIEM), Threat Detection and Vulnerability Host Scanning. Features you\u0026rsquo;ve enabled will appear in the detail panel that opens when you select a row, where you can also see Feature connection status.\nThe possible Feature statuses are:\nStatus Value Description Connected This feature was successfully onboarded and connected. Not Enabled This feature was not enabled during onboarding. Error There is an error in this feature connection. Pending This feature has been recently connected, and a validation will be run within an hour. Unknown Sysdig cannot determine the current status of the feature. Account StatusThe Account level status appears in the main table, as well as at the top of the details panel. This status is an aggregate of the Feature statuses present in the Account.\nThe possible Account statuses are:\nStatus Value Description Connected All selected features were successfully onboarded and connected. Partial Error There is an error in at least one enabled feature. Error There are errors in all enabled features. Pending The account has been recently connected, and a validation will be run within an hour. Unknown Sysdig cannot determine the current status of the account. Add Azure AccountsTo connect an account, select + Add Azure Account, and then follow the installation pop-up wizard.\nFor detailed onboarding instructions, see Connect Cloud Account | Azure.\nReview Azure Cloud AccountsThe page lists:\nSubscription: Azure Subscription ID, followed by an Subscription Name, if one was assigned.\nStatus: The Status of each Azure Subscription connected.\nPossible values: Connected, Pending, Partial Error, Error, Unknown. For more on status values, see Validate Account Connection. Last Checked: Time at which a feature was last validated. Validation occurs every 24 hours.\nTenant ID: ID of the Organization to which the Subscription belongs, if applicable.\nAdded On: Date the Subscription was added to Sysdig Secure.\nValidate Account ConnectionThere are two types integration status displayed, Feature level status, and Subscription level status. Statuses are validated approximately every 24 hours, with the first check occurring within an hour of enabling a feature.\nIf there are connection errors, if you remediate them, the status will be updated on the page when the validation is run again, up to 24 hours later.\nFeature StatusWhen you connect a cloud account to Sysdig Secure, select the Sysdig features you would like to enable, such as Cloud Security Posture Management (CSPM), Cloud Infrastructure Entitlements Management (CIEM), Threat Detection and Vulnerability Host Scanning. Features you\u0026rsquo;ve enabled will appear in the detail panel that opens when you select a row, where you can also see Feature connection status.\nThe possible Feature statuses are:\nStatus Value Description Connected This feature was successfully onboarded and connected. Not Enabled This feature was not enabled during onboarding. Error There is an error in this feature connection. Pending This feature has been recently connected, and a validation will be run within an hour. Unknown Sysdig cannot determine the current status of the feature. Subscription StatusThe Subscription level status appears in the main table, as well as at the top of the details panel. This status is an aggregate of the Feature statuses present in the subscription.\nThe possible Subscription statuses are:\nStatus Value Description Connected All selected features were successfully onboarded and connected. Partial Error There is an error in at least one enabled feature. Error There are errors in all enabled features. Pending The account has been recently connected, and a validation will be run within an hour. Unknown Sysdig cannot determine the current status of the subscription. Add GCP AccountTo connect a project, select + Add GCP Account, and then follow the installation pop-up wizard.\nFor detailed onboarding instructions, see Connect Cloud Account | GCP.\nReview GCP Cloud AccountsThe page lists:\nProject: GCP Project ID, followed by a Project Name (if assigned).\nStatus: The status of each GCP Project connected.\nPossible values: Connected, Pending, Partial Error, Error, Unknown. For more on status values, see Validate Account Connection. Last Checked: Time at which a feature was last validated (updated every 24 hours)\nOrg Domain: ID of the Organization to which the Project belongs, if applicable\nAdded On: Date the Project was added to Sysdig Secure\nValidate Account ConnectionThe integration statuses displayed are: Feature level status, and Project level status. Status checks are run approximately every 24 hours, with the first check occurring within an hour of enabling a feature.\nIf there are connection errors, if you remediate them, the status will be updated on the page when the validation is run again, up to 24 hours later.\nFeature StatusWhen you connect a cloud account to Sysdig Secure, select the Sysdig features you want to enable, such as Cloud Security Posture Management (CSPM), Cloud Infrastructure Entitlements Management (CIEM), Threat Detection and Vulnerability Host Scanning. Features you\u0026rsquo;ve enabled will appear in the detail panel that opens when you select a row, where you can also see Feature connection status.\nThe possible Feature statuses are:\nStatus Value Description Connected This feature was successfully onboarded and connected. Not Enabled This feature was not enabled during onboarding. Error There is an error in this feature connection. Pending This feature has been recently connected, and a validation will be run within an hour. Unknown Sysdig cannot determine the current status of the feature. Subscription StatusThe Project level status appears in the main table, as well as at the top of the details panel. This status is an aggregate of the Feature statuses present in the Project.\nThe possible Project statuses are:\nStatus Value Description Connected All selected features were successfully onboarded and connected. Partial Error There is an error in at least one enabled feature. Error There are errors in all enabled features. Pending The Project has been recently connected, and a validation will be run within an hour. Unknown Sysdig cannot determine the current status of the Project. Detect all GCP InstancesOptional: Use a script to detect all GCP instances of projects across your entire GCP organization. This information can help you count all the places you want to install an agent in tandem with the Sysdig Agents overview page.\nRun this script to print out the number of instances in the project, and download a CSV file with the information:\necho \u0026#34;id,name,machine_type\u0026#34; \u0026gt; gcloud.csv for PROJECT in $(gcloud projects list --format=\u0026#34;value(projectId)\u0026#34;) do gcloud compute instances list --project $PROJECT --format=\u0026#34;csv( id, name, machineType )\u0026#34; --quiet 2\u0026gt; /dev/null | grep -v \u0026#34;id,name\u0026#34; \u0026gt;\u0026gt; gcloud.csv done echo \u0026#34;Count of instances in all projects: $(cat gcloud.csv | tail -n +2| wc -l)\u0026#34; The terminal entry displays the count similar to the following:\nCount of instances in all projects: 21 ","url":"https://docs.sysdig.com/en/sysdig-secure/integrations-cloud-accounts/"},{"id":8,"title":"Connect Cloud Accounts","content":"Cloud FeaturesAgentless Compliance and Posture Management (CSPM)Sysdig\u0026rsquo;s Compliance and Posture Management for cloud accounts includes:\nInventory: Search and gain visibility into resources across your cloud and Kubernetes environments. Each resource is enriched to provide a 360-overview of misconfigurations, compliance violations, vulnerabilities, and more. Compliance: Review and remediate risk and compliance violations of your business zones against the policies with which you need to comply. Infrastructure as Code (IaC): This feature highlights and resolves misconfigurations and policy violations early in the development lifecycle, moving security close to the source as early as possible. Basic Cloud Infrastructure Entitlement Management (CIEM): Improve your Identity hygiene by identifying Risks based on Connected IAM Resources and Permission Criticality, such as Data Exfiltration Risk in 1 Hop and Risky AWS Users. Use Search to filter for Identities with configuration-based Identity findings such as No MFA and Administrative Permissions. Threat DetectionSysdig\u0026rsquo;s Threat Detection, part of Sysdig\u0026rsquo;s CDR capabilities, offers:\nThreat Detection for Cloud: Sysdig analyzes Cloud platform logs for known threats. Managed Threat Research: Discover new Zero Day Attacks against your cloud. Threat ResponseSysdig\u0026rsquo;s Threat Response complements Threat Detection in providing CDR capabilities in Cloud accounts. The feature is delivered via Response Actions, allowing you to contain threats and stop incidents or to collect additional data to support the investigation and store forensic proofs.\nAdvanced Cloud Infrastructure Entitlement Management (CIEM)Sysdig\u0026rsquo;s Advanced Cloud Infrastructure Entitlement Management (CIEM), also known as Identity and Access Management (IAM), provides:\nLeast Permissive Analysis: Sysdig analyzes cloud platform logs and offers suggestions based on the principle of least privilege (PoLP), which involves eliminating excessive permissions from all identity entities. Usage-Based Context: Clean up IAM Policies and Principals that are going unused, and understand which high-risk permissions are actively used versus unnecessary. Agentless Vulnerability ScanningSysdig\u0026rsquo;s Agentless Vulnerability Host Scanning, also known as Vulnerability Management (VM), provides runtime vulnerability detection in cloud accounts.\nMalware ScanningMalware Scanning (currently in Technical Preview) extends the capabilities of Vulnerabilities Scanning to catch dormant threats. While Sysdig Secure already protects your environment by monitoring file activity at runtime, malware can hide in files that aren\u0026rsquo;t actively being executed or modified.\nMalware Scanning fingerprints all Executable and Linkable Format (ELF) files with a SHA-256 hash. These hash values are compared against Sysdig\u0026rsquo;s up-to-date databases of known malware signatures. If malware is detected, findings are displayed in the UI (see View Malware Scanning Results) and included in your Software Bill of Materials (SBOM).\nYou can use provider-supported tagging to control scan scope at the VM or volume level.\nMalware scanning follows the same snapshot 24-hour schedule as vulnerability management.\nPrerequisites The supported cloud providers are AWS, Azure, and GCP. Vulnerability Management Host Scanning must be enabled. Only Linux-based virtual machines are supported. Enable Malware ScanningFollow these links to enable Malware Scanning for:\nAWS Azure GCP Installation PlanningSysdig\u0026rsquo;s cloud features rely on the following components:\nCSPM: Trust relationship. Threat Detection: Log ingestion. CIEM: Log ingestion and Trust relationship. VM: Volume access. CSPM is set up when you connect a cloud account. The installation wizards in the UI take you through the installation scenarios for your cloud provider, which involve setting up the required component for the feature you desire.\nSupported Features Cloud Provider Cloud Security Posture Management (CSPM) Cloud Infrastructure Entitlement Management (CIEM) Threat Detection Vulnerability Host Scanning Vulnerability Workload Scanning ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ✅ ❌ ❌ ❌ ❌ Onboarding Types Single onboarding is scoped to a single AWS account, GCP project, or Azure subscription. The target can either belong to an organization or operate independently. It is primarily recommended for feature testing before configuring the organizational setup.\nOrganizational onboarding covers an entire AWS Organization, GCP Organization, Azure Tenant or Oracle Cloud Tenancy. This installation is recommended to secure your whole environment.\nQuick StartTo connect a cloud account:\nLog in to Sysdig Secure as admin and select Integrations \u0026gt; Environments and choose AWS, GCP, Azure or Oracle Cloud. From the relevant account page, follow the wizard prompts to connect the account. AWS Azure GCP Oracle Cloud ","url":"https://docs.sysdig.com/en/sysdig-secure/connect-cloud-accounts/"},{"id":9,"title":"Cloud Run Service","content":"PrerequisitesRefer to the following prerequisites for both Sysdig and GCP Cloud Run.\nSysdig A Sysdig Secure account and the Agent Access Key\nThe endpoint of the Sysdig Collector for your region\nNetwork access to the Sysdig Collector from the deployed Workload Agent.\nThe Sysdig Workload Agent requires outbound traffic permissions on port 6443 to communicate with the Sysdig Collector.\nGCP Cloud Run Instance-based billing (previously called CPU Always Allocated) selected in your Service definition.\nSecond-generation execution environment selected in your Service definition.\nDeploy the Sysdig Workload AgentThe Serverless Workload Agent consists of two primary components:\nInstrumentation: Monitors the workload application, operating within the same container alongside it.\nAgent: Analyzes the syscall data collected by the Instrumentation, performs policy matching, and communicates with the Sysdig collector.\nThe Instrumentation always resides within the same container as the workload application it monitors. The Agent, however, can be deployed in one of two configurations:\nEmbedded within the same container as the workload application, sharing the same CPU and memory resources. This approach has minimal deployment impact, only requiring extra environment variables in the workload container.\nAs a sidecar container, enabling independent configuration of its CPU and memory resources separate from the workload container. This setup requires additional configuration in the workload service.\nInstrument the Workload ImageThe first step is instrumenting the workload image with the Serverless Workload Agent, regardless of the chosen deployment strategy. This ensures the Sysdig applications are included in the workload container image.\nThis example uses sysdiglabs/security-playground as the original workload to secure. It is a sample application that offers endpoints for triggering security events.\nGiven the original Dockerfile:\nFROM python:3.9-slim RUN pip install --upgrade pipenv WORKDIR /app COPY . . RUN pipenv install --system --deploy EXPOSE 8080 ENTRYPOINT [\u0026#34;./entrypoint.sh\u0026#34;] It can be instrumented as follows:\n+FROM quay.io/sysdig/workload-agent:latest AS workload-agent FROM python:3.9-slim RUN pip install --upgrade pipenv WORKDIR /app COPY . . RUN pipenv install --system --deploy +COPY --from=workload-agent /opt/draios /opt/draios EXPOSE 8080 +ENTRYPOINT [\u0026#34;/opt/draios/bin/instrument\u0026#34;, \u0026#34;./entrypoint.sh\u0026#34;] In detail:\nThe Sysdig Workload Agent is added as a separate layer and then copied into the image file system under /opt/draios. The Sysdig application /opt/draios/bin/instrument is prepended to the original ENTRYPOINT to secure the original workload application at runtime. The instrumented container image is now ready to be built and deployed.\nEmbedded DeploymentAfter instrumenting your workload image, you can deploy it just like the original.\nMake sure to provide the workload container with the following additional environment variables:\nSYSDIG_COLLECTOR and SYSDIG_COLLECTOR_PORT: Used to reach the Sysdig Collector for your region SYSDIG_ACCESS_KEY: The Agent Access Key to authenticate with the Sysdig backend. SYSDIG_WORKLOAD_ID: The identifier for each instrumented container, must be unique at the service level. Sidecar DeploymentAfter instrumenting your workload image, you will need to:\nAdd an in-memory volume to the service. Provide the instrumented workload container with additional environment variables and mount points. Add a sidecar container running the Sysdig Workload Agent. In detail:\nAdd an in-memory empty-dir volume to the service with the following configuration:\nname: sysdig size limit: 512Mi Provide the instrumented workload container with:\nAn additional environment variable: SYSDIG_SIDECAR: force. A volume mount for the sysdig volume at /opt/draios/run. Add a sidecar container to the service running the Sysdig Workload Agent, and provide it with:\nThe following additional environment variables: SYSDIG_COLLECTOR and SYSDIG_COLLECTOR_PORT: Used to reach the Sysdig Collector for your region SYSDIG_ACCESS_KEY: The Agent Access Key to authenticate with the Sysdig backend SYSDIG_WORKLOAD_ID: The identifier for each instrumented container, must be unique at the service level SYSDIG_SIDECAR: force A volume mount for the sysdig volume at /opt/draios/run. ","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-cloudrun-service/"},{"id":10,"title":"Cloud Shield","content":" This feature is in Technical Preview.\nPrerequisites Terraform version 1.7 Sysdig Secure SaaS account connected to your cloud. OverviewSysdig Cloud Shield is a mechanism for performing in-account or organization operations that Sysdig Agentless functionality provides. Its purpose is to allow highly regulated industries to take advantage of Agentless functionality while still respecting data and regional requirements.\nCloud Shield currently supports an organizational scanning model in which it is deployed into a single account per region. It uses trust relationships to access and scan other accounts within the same AWS organization and regional boundaries.\nTo understand the use cases and platforms that Sysdig Cloud Shield supports, see Supported Environments.\nKey Benefits Complete in-region scanning: All operations take place entirely within your own cloud environment using your own infrastructure. No sensitive data leaves your environment: Only sanitized metadata like resource metadata, SBOMs, and findings is shared. All sensitive data remains within your cloud account(s). Built for compliance: Supports data sovereignty and privacy by ensuring sensitive workload data remains fully under your control. Meets data residency requirements: All supported operations are restricted to your specified cloud account and region. How It Works Streamlined Discovery: Sysdig Cloud Shield uses the Sysdig backend to analyze your cloud resources and monitor your environment. Local execution: Security analysis runs entirely within your environment. There’s no need to export images, snapshots, or other sensitive data externally. Minimal external communication: Sysdig only receives the redacted metadata necessary for visualization not raw data or sensitive artifacts. Ideal For Organizations with data sovereignty mandates or in-region data processing requirements. Enterprises with strict internal data governance policies. Teams needing full control and visibility over their cloud security operations. Supported Environments Cloud Availability Host Scanning Container Scanning Cloud Workload Scanning PREVIEW ✅ ❌ ❌ How to Enable Cloud Shield?To enable this feature in your environment, contact Sysdig Support or your account representative for detailed onboarding steps.\n","url":"https://docs.sysdig.com/en/sysdig-secure/cloud-shield/"},{"id":11,"title":"CloudFormation","content":"Sysdig provides the following YAML template for the Serverless Workload Agent:\ninstrumentation.yaml: Deploys the instrumentation service that instruments your workload template. The instrumentation service leverages serverless-patcher, a Sysdig containerized tool that automates the instrumentation CloudFormation templates.\nRun the template instrumentation service either in the cloud or locally and integrate it into your CI/CD pipeline.\nPrerequisitesReview the Installation Requirements before getting started.\nDeploy the Instrumentation Stack Push the latest image of serverless-patcher to a private ECR repository within the same region where the deployment will take place.\nLog in to the AWS Console, select CloudFormation, and create a stack with new resources.\nSpecify the instrumentation.yaml as the Template source.\nThe name of the Macro must be unique in your account. The serverless-patcher image must be hosted in an ECR private repo within the same region in which the deployment takes place. Provide the stack details to deploy the Instrumentation Service:\nInstrumentation Priority: Supported options are availability (by default) or security. In security mode, the Workload Agent aims to process every syscall event and will prevent the workloads from running unsecured. Consequently, secured applications will not execute until the Workload Agent receives the runtime policies. The availability mode instead facilitates resource sharing between the Workload Agent and the workload containers, enabling the Workload Agent to detect when resource pressure exceeds configurable limits and pause event processing to reduce pressure. Sidecar Essential Flag: If marked as essential, ECS will stop all containers in the task if the sidecar exits. The sidecar container is marked as essential in security mode by default to prevent secured workloads from running unsecured. Sidecar CPU Units and Memory Limit/Reservation: The settings can be adjusted to allocate dedicated CPU units and memory resources/limits to the sidecar container. Complete the stack creation and wait for the deployment to complete.\nWhen complete, note the SysdigInstrumentationMacro from the Stack outputs tab.\nInstrument the Workload StackThe instrumentation process includes inspecting the images of the containers in the TaskDefinition to patch the entrypoint and command of them. If your workload containers are using images from private registries, you must explicitly provide the original entrypoint and command for each container.\nCopy and paste the Transformation Macro string from the Sysdig Instrumentation stack output to the root level of your workload stack template. Deploy your instrumented workload template. The Sysdig instrumentation service will go over the workload template to instrument it. Upgrade the Workload AgentThe Workload Agent version can be upgraded by updating the Instrumentation Stack with the latest image of serverless-patcher specified as Sysdig Serverless Patcher Image and Workload Agent specified as Sysdig Workload Agent Image. These versions do not need to match but it is recommended to use consistent versions.\nOnce the Instrumentation Stack has been updated, the Workload Stack should be deleted and recreated.\nNext StepsAfter the deployment is completed, security-related events will be visible in the Sysdig Secure Events feed.\nOptionally, you can perform advanced Configuration steps.\nUse the Serverless PatcherThe Sysdig serverless-patcher tool lets you instrument your CloudFormation templates when installing the Sysdig Serverless Agent for ECS on Fargate. You can run serverless-patcher both in the cloud and locally, and it can be integrated with your CI/CD pipeline or automation tools to instrument templates automatically before deploying them to your staging environment.\nPatching a CloudFormation template means performing the following changes to its TaskDefinition:\nAdding a sidecar container that exposes a volume to provide the Sysdig Workload Agent to the workload containers Making each workload container mount a data volume from the sidecar container Modifying the original entrypoint of each workload container to run the Sysdig instrumentation into it Adding the Linux capability SYS_PTRACE to each workload container Adding the Sysdig environment variables to each workload container Instrument your CloudFormation Templates Download the latest version of serverless-patcher:\ndocker pull quay.io/sysdig/serverless-patcher:latest Instrument your workload template:\ndocker run -e KILT_MODE=\u0026#34;local\u0026#34; -e KILT_SRC_TEMPLATE=\u0026#34;/path/to/src/template\u0026#34; -e KILT_OUT_TEMPLATE=\u0026#34;/path/to/out/template\u0026#34; [OPTIONS] -v /host/path/template:/path/template quay.io/sysdig/serverless-patcher:latest The above command runs serverless-patcher locally and instruments your CloudFormation template.\nYou need to replace:\n/path/to/src/template with the path to your original CloudFormation template /path/to/out/template with the path to the output instrumented template. /host/path/template with the path to the folder containing the original template on your local machine. Additionally, you can pass the following environment variables to the command to configure serverless-patcher:\nSYSDIG_COLLECTOR: The Collector Host. SYSDIG_COLLECTOR_PORT: The Collector port. The default value is 6443. SYSDIG_ACCESS_KEY: Sysdig Agent access key SYSDIG_WORKLOAD_AGENT_IMAGE: The Workload Agent image to instrument workload containers. Each release defines the proper version. SYSDIG_LOGGING: The Sysdig Instrumentation login level. The supported values are silent, fatal, critical, error, warning, info, debug, trace. Once the command finishes executing, you should have a new CloudFormation template with the same name as the original but with _instrumented appended to it. You can use this instrumented template to deploy your workload to AWS.\nYou can use this to instrument your CloudFormation templates as part of your CI/CD pipeline.\n","url":"https://docs.sysdig.com/en/sysdig-secure/ecs-fargate-cloudformation/"},{"id":12,"title":"Configuration Library","content":"General Agent ConfigurationThe configuration parameters outlined in this section apply to both Sysdig Monitor and Sysdig Secure.\nAgent PrivilegesThe parameter to modify Sysdig Agent privileges to enhance the security of your deployments. For more information, see Manage Agent Privileges\nHelm: securityContext.privileged Default: securityContext.privileged: true\nClusterIdentifier for the Kubernetes cluster where you install the agent. For more information, see Agent Configuration.\ndragent.yaml : k8s_cluster_name\nHelm: global.clusterConfig.name\nFor example, ec2_cluster.\nAccess KeySee Sysdig Agent Access Keys to learn how to retrieve the agent keys.\ndragent.yaml : customerid\nHelm: global.sysdig.accessKey\nSecretThe name of a Kubernetes secret containing an access-key entry.\nThis configuration does not exist in the dragent.yaml.\nHelm: global.sysdig.accessKeySecret\nRegionThe SaaS region where the agent is installed. See Regions and IP Ranges for more information.\nThis configuration does not exist in the dragent.yaml.\nHelm: global.sysdig.region\nPossible values include: us1, us2, us3, us4, eu1, au1, and custom.\nGlobal TagsSets the global tags which can override agent tags. See Quick Install Sysdig Agent for more information.\ndragent.yaml: tags Helm: global.sysdig.tags\nAgent TagsThe list of tags to identify the host where the agent is installed. See Quick Install Sysdig Agent for more information.\ndragent.yaml: tags Helm: global.sysdig.tags\nFor example: role:webserver, location:europe, role:webserver.\nProxyAllows the agent to communicate with Sysdig collector through a http_proxy. See Enable HTTP Proxy for Agents for more information.\ndragent.yaml: http_proxy Helm: global.proxy.httpProxy\nHTTP Proxy HostThe host IP of the proxy server.\ndragent.yaml: http_proxy.proxy_host\nHTTP Proxy PortSee Enable HTTP Proxy for Agents for more information.\ndragent.yaml: http_proxy.proxy_port, http_proxy.proxy_user, http_proxy.proxy_password, http_proxy.ssl, http_proxy.ssl_verify_certificate, http_proxy.ca_certificate.\nCollectorEnter the hostname or IP address of the Sysdig collector service. Note that when used within dragent.yaml, must be lowercase collector.\nSee On-Premises Installation for more information.\nHelm: collectorSettings.collectorHost\nCollector PortOn-prem only. The port used by the Sysdig collector service.\nPort: 6443\neBPFThis configuration does not exist in the dragent.yaml.\nIn Helm:\nSet ebpf.enabled to true to enable the agent Universal eBPF or the current eBPF driver. The default is false.\nSet ebpf.kind to universal_ebpf to enable the Universal eBPF driver. Set to legacy_ebpf to enable the eBPF driver.\nNote ebpf.enabled must also be set to true for this configuration to work.\nFIPS ComplianceStarting v13.6.0, Sysdig Agent is available fully FIPS-compliant. To use the FIPS-compliant Sysdig Agent, use the following images and packages.\nHelm InstallationSet the following configurations to specify the FIPS-compliant images:\n--set agent.slim.image.repository=sysdig/agent-slim-fips --set agent.slim.kmoduleImage.repository=sysdig/agent-kmodule-fips Container InstallationsUse the following images:\nquay.io/sysdig/agent-kmodule-fips quay.io/sysdig/agent-slim-fips Package-Based Installations (deb, rpm) Driver FIPS-Compliant Packages kmod (compatibility mode) draios-agent-fips kmod (recommended) draios-agent-kmodule-fips legacy_ebpf draios-agent-legacy-ebpf-fips universal_ebpf draios-agent-slim-fips ConsiderationsPreviously, a FIPS mode was available that could be enabled within the standard Agent. However, for full FIPS compliance, we recommend transitioning to the new FIPS-compliant images and packages.\nThe app_checks support is currently not supported when the agent is running in FIPS mode or in with the new FIPS images and packages.\nOpenSSL Library Locationdragent.yaml: openssl_lib\nAgent version 12.16.x and older: Required when fips_mode is set to true. Path to the directory containing user-provided OpenSSL v1.1.1 shared library files: libcrypto.so.1, and libssl.so.1. User-provided OpenSSL libraries must contain a FIPS-validated crypto module if setting fips_mode to true.\nAgent version 12.17.0 and newer: Optional: Path to the directory containing user-provided OpenSSL v3.x shared library files: libcrypto.so.3, and libssl.so.3. User-provided OpenSSL libraries must contain a FIPS-validated crypto module if setting fips_mode to true.\nBy default, the agent uses bundled OpenSSL shared libraries.\nOpenSSL Configuration File Locationdragent.yaml: openssl_conf\nAgent version 13.0 and newer: Required when openssl_lib is used to point the agent to a custom OpenSSL v3.x library. If fips_mode is set to true, the configuration file specified by openssl_conf must contain the properties specified in the \u0026ldquo;Making all applications use the FIPS module by default\u0026rdquo; section of fips_module(7) man page. If the OPENSSL_CONF environment variable is also set, it will take precedence over the openssl_conf value.\nBy default, the agent uses OpenSSL configuration files included with its bundled libraries.\nInstance Metadata Service (IMDS)dragent.yaml: imds_version\nOptional: Enables token-based communication with the Amazon Web Service (AWS) metadata service IMDSv2.\nThe default is 1.\nHowever, the agent internally upgrades the IMDS version to IMDSv2 when the IMDSv1 API call returns a \u0026ldquo;Not Authorized\u0026rdquo; error. You can ignore the INFO level message stating to change the configuration to 2.\nLearn More Agent Configuration for Secure Agent Configuration for Monitor ","url":"https://docs.sysdig.com/en/sysdig-secure/classic-agent-library/"},{"id":13,"title":"ECS on Fargate","content":"The Serverless Agent helps you maintain security and compliance for your serverless workloads on ECS Fargate, reducing the risk of security incidents and compliance violations. By default, the Serverless Agent prioritizes workload availability over strict security enforcement, allowing tasks to start even if policies aren’t fully applied. You can adjust this behavior by setting the workload startup policy to prioritize security over availability.\nPrerequisitesBefore starting the installation, ensure that you have the following:\nOn AWS A custom Terraform/CloudFormation template containing the Fargate task definitions that you want to instrument through the Serverless Agent A VPC subnet that can connect with the Internet On Sysdig Sysdig Secure up and running\nThe endpoint of the Sysdig Collector for your region\nFrom the Sysdig Secure UI, retrieve the Access Key to install the agent and push the data to the Sysdig platform\nLimitationsSpecifying the Entry Point and Command in the Container DefinitionThe Sysdig instrumentation service modifies the target workload\u0026rsquo;s task definition so that the original workload runs under Sysdig instrumentation. It pulls and analyzes the workload container image to retrieve its original entry point and command automatically.\nHowever, in the following cases, Sysdig instrumentation cannot pull the workload image to retrieve this information. You must explicitly define EntryPoint and Command in the template\u0026rsquo;s container definitions when:\nYour container image is hosted in a private registry. Your container image name is not a plain string. Next StepsThe Serverless Agent can be deployed in multiple ways to suit your needs and preferences.\nYou can choose automated deployment using Terraform or CloudFormation, or manually adjust your IaC configuration.\nAutomatic deployment via Terraform or CloudFormation (Recommended): You can automate the deployment of the Serverless Agent using Terraform or CloudFormation templates. This method simplifies the deployment process, ensures consistency across deployments, and simplifies ongoing maintenance.\nInstall on ECS Fargate using Terraform\nInstall on ECS Fargate using CloudFormation\nManual deployment: You can manually modify your IaC configuration to deploy the Serverless Agent. This method requires more effort and is prone to human error, but provides more flexibility and control over the deployment process.\nInstall on ECS Fargate manually\nWith the recommended deployment method, you can quickly and easily instrument your Fargate workloads with the Serverless Agent, ensuring runtime detection and policy enforcement for improved security and compliance.\n","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-ecs-fargate/"},{"id":14,"title":"Enable Validated Exposure for Advanced Network Exposure","content":"OverviewAdvanced Network Exposure is automatically enabled when you connect your cloud accounts to Sysdig Secure with Cloud Security Posture Management (CSPM) capabilities. The configuration-based analysis works by analyzing the network configurations and metadata from your cloud providers without requiring additional agent installation.\nHowever, validated exposure through port scanning requires additional manual setup steps and must be explicitly enabled by contacting Sysdig Support.\nEnable Validated Exposure (Port Scanning)Validated exposure adds an additional layer of verification by performing port scanning and IP discovery to confirm resources identified as exposed through configuration analysis are reachable from the internet.\nImportant: Validated exposure requires manual activation by Sysdig Support and involves additional setup steps including IP whitelisting. This feature must be explicitly requested and configured.\nWhen Sysdig performs port scanning and IP discovery to validate exposure, these activities can be detected by your security infrastructure as potentially malicious behavior. Common security systems that may flag or block Sysdig\u0026rsquo;s scanning activities include:\nFirewalls: May interpret repeated connection attempts as port scanning attacks Web Application Firewalls (WAF): Can identify scanning patterns and block the source IPs Intrusion Detection/Prevention Systems (IDS/IPS): May alert on or block scanning activity Cloud-native security services: Such as AWS GuardDuty, Azure Security Center or GCP Security Command Center To ensure validated exposure works correctly and to prevent Sysdig\u0026rsquo;s scanning IPs from being blocked or flagged as malicious actors, you must add Sysdig\u0026rsquo;s IP addresses to your allow lists.\nNote: The IP addresses used for scanning are documented in the SaaS Regions and IP Ranges documentation. Refer to this page for the complete list of IP ranges for your Sysdig region.\nIdentifying Network Scanner ActivityTo help distinguish legitimate Sysdig scanning activity from potential threats, HTTP scans performed by the network scanner include a custom header that can be used to identify and whitelist these requests in your logs and security systems.\nThe following custom header is included in all HTTP scan requests:\nHeader Name: X-Sysdig-CSPM Header Value: NetworkScanner/1.0 You can use this header to:\nConfigure your WAF or firewall rules to allow traffic from Sysdig\u0026rsquo;s network scanner Filter and identify Sysdig scanning activity in your web server and application logs Create exceptions in your IDS/IPS systems to prevent false positive alerts For example, you can configure your web application firewall to recognize requests with the X-Sysdig-CSPM: NetworkScanner/1.0 header as legitimate security scanning from Sysdig and allow them without triggering alerts.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/advanced-network-exposure/enable-advanced-network-exposure/"},{"id":15,"title":"Environments for Sysdig Secure","content":"Environments Cloud Accounts: Connect your Cloud Accounts to Sysdig for Cloud Security Posture Management (CSPM), compliance monitoring, threat detection, and vulnerability assessment in your cloud resources. Managed Kubernetes: Review and add managed Kubernetes clusters detected in the connected cloud accounts. Sysdig Agents: Deploy the Sysdig Host \u0026amp; Cluster Shield for runtime threat detection, security posture management (KSPM), workload vulnerability scanning, and compliance monitoring. Cloud Hosts: View details about the connected hosts, VPCs, and Resource Groups discovered with agentless vulnerability scanning. ","url":"https://docs.sysdig.com/en/sysdig-secure/integration-environments/"},{"id":16,"title":"Events Feed","content":" The Events dashboard provides a navigable interface to:\nFind and surface insights around the most relevant security events in your infrastructure.\nSlice and dice your event data with filters, zones, and groups.\nInspect individual events in the event detail panel.\nFollow up on forensics and activity audits by directly linking to other sections of the product for additional event information.\nWithout filters or scope defined, the event list comprises all events within the timeline, in chronological order. Click any event to open the event detail panel on the right.\nFilter Secure EventsThe Events feed can be filtered, grouped and scoped in a variety of ways.\nSearch and FilterUse the top panel to:\nSelect Zones: Select zones you have access to from the dropdown. Zones are in Technical Preview. To enable Zones, go to Settings \u0026gt; User Profile. Under Sysdig Labs, toggle Zones scoping for all features on. If Zones is not available from your User Profile, contact your Sysdig representative.\nFilter by Event Source, such as AWS, Okta, and GitHub.\nFilter by Severity: Toggle the colored buttons marked H, M, L and I to show or hide events of the severities High, Medium, Low or Info. For info about how severities are mapped to numbers, see Threat Detect Policies.\nSelect the star icon to the right of the search bar to make your current filter your favorite. Access your favorites and recent searches in the dropdown menu located on the left side of the search bar.\nSearch: Add a filter or use free-text search to find events.\nYou can search by the event title and scope label values, such as \u0026ldquo;my-cluster-name,\u0026rdquo; visible in the events lists.\nClick Add Filter for an initial drop-down list of valid scope elements. Keep clicking in the filter bar to view the next logical operand and value that you want to add to your expression.\nFilter by Output FieldsYou can also filter Runtime Events using output fields in addition to labels.\nOpen an event and apply filters directly from its details view, or type filters manually in the search bar using the prefix fields.\nUnderstand Filter Expression ElementsFilters are additive. Click the operand after an element in an event to add it directly to the filter expression.\nClick the is or is-not operand on an event listing to add it to your filter.\nClick the star to save a constructed expression as a Favorite.\nClick the icon on the left of the bar to access recently used Filter and Favorites.\nQuick FiltersAccess the Quick Filters bar on the left for Kubernetes, Cloud and Host filters and tags. The number of hits are listed beside each tag.\nGroup byYou can use the Group by drop-down to sort events in a variety of ways, such as by policy, rules, clusters, workloads and cloud accounts. This helps to create lists of specific kinds of events.\nNo group Grouped by policy Change Time SpanThe time bar allows you to change the time span of for events displayed, as well as pause the intake of events.\nUse buttons to view events in specific periods, such as the last ten minutes, three days, or two weeks.\nTo set a custom time span, select the current date on the left side of the time bar. A calendar will appear and you can manually specify a range.\nUse the pause/play button in the time bar to toggle between Live and Paused.\nWhen Live, events continually update. When Paused, new events are withheld, allowing you to review a point in time. Examine Trends Over TimeThe Trend Over Time graph, above the events list, is a highly dynamic and interactive representation of your event activity over time.\nHover your mouse over any section to see the type of event represented.\nClick and drag across a time period to select it for more detailed analysis.\nThe graph will reload to represent that period in more detail.\nUse the time bar at the bottom of the screen to change the time period displayed.\nCustomize ColumnsYou can choose which columns you want to see in the table, as well as their order. To do so, click on the gear icon at the right of Group by.\nFrom there, you can select the columns you want to add in the \u0026ldquo;Other available columns\u0026rdquo; list by clicking on the eye icon. Similarly, columns in the \u0026ldquo;visible\u0026rdquo; list can be removed by using the hide icon.\nColumn ordering (left to right) can be changed by dragging and dropping, using the left-side handle.\nTime, Severity and Rule columns can\u0026rsquo;t be customized; they are always displayed on the leftmost side.\nYou can revert your changes to the default set of columns by using the Reset to default button.\nEvent Detail PanelWhen you select an Event on the Events page, the Event Detail panel appears on the right.\nReview DetailsAt the top of the Event Details panel, you can:\nFind details such as the event name and ID, associated policy, severity, and time of occurrence. Select the clipboard icon to export the Event ID or payload in simple text, JSON or CSV. Take Action. Below, the Event Detail panel is broken into sections. This lets you quickly review an event, and decide your next step:\nWhat: Contains a brief description of what happened, and the relevant policy, rule and rule type.\nProcess: Contains process details, such as the name and parent name.\nContent: Contains information such as the Event ID.\nWho: Contains information associated with user identity, such as user name, account ID and source IP address.\nCloud: Contains details related to your cloud, such as cloud account ID and region.\nTriggered Rule Tags: Contains an expandable list of associated triggered rule tags. You can filter the rest of the event feed with the symbols on the tag. Select = to include the tag in your search, and != to exclude it.\nOther sections may appear, depending on the Event type.\nHover over an attribute name to learn what it refers to in the Event JSON payload. With the exception of the What and Triggered Rule Tags sections, all the attributes are sourced from the Event fields or labels:\nFields (content.fields in the event JSON payload) are the detection output, based on those specified in the rule output, together with a set of fields extracted by default. You can find more details about what they represent in the dedicated Fields Library.\nLabels (labels in the event JSON payload) are contextual information, indicating the location where the event happened. They are attached to the event when available and the agent is configured to include them. To learn more, see Enrich Secure Events with Labels.\nYou will find all the Event\u0026rsquo;s Fields and Labels across the sections, apart from those that are empty (\u0026quot;\u0026quot;) or null (null or \u0026lt;NA\u0026gt;).\nTake ActionDepending on the event, actions may be available:\nSelect Investigate to open the event on a filtered Resources page.\nSelect More to:\nApply suggestions of Tunable Exceptions you want to create. See Tunable Exceptions. View Rule: Here, you can see which policies use this rule, edit the rule and its exceptions, and check changes made to the rule (+/- diff icon). For details, see View Recent Changes to a Rule. Edit Policy: You can edit the Threat Detection Policy that triggered the event. Depending on the policy type, you may be able to change the severity, the scope, the rules applied and more. For details, see Edit a Managed Policy. Copy Event as JSON: Copy the event payload in JSON format. Export Details: Export the event payload in plain text, JSON, or CSV format. Select Respond to open a shell for Rapid Response, run a Response Action, or ask Sysdig Sage for Response Advice. For details about Respond and Response Actions, see Respond.\nClick the copy icons at the top of the event detail panel to copy the event URL, the event ID, or the event payload in various formats, such as simple text, JSON or CSV.\nWhere available, click the Captures button.\nIf set up in the associated policy, select Respond \u0026gt; View Runbook to view your company\u0026rsquo;s procedure documents.\nFor Runtime events, the Activity shortcut button is available and links to Activity Audit.\nFor Image Scanning, the Scan Results shortcut links to the Scan Results page.\nFor a birds-eye view of the related network activity and the ability to create a Netsec policy, the Network Activity shortcut links to the Netsec page. See also: Quick Link to Netsec Typology.\nScope\nThe new scope selector allows for additional selector logic (such as: in, not in, contains, or starts-with), improving the scoping flexibility over previous versions. This scope selector also provides scope variables. For example, you can quickly switch between Kubernetes namespaces without having to edit the panel scope. See also: Team Scope and the Event Feed.\nNote that the scope details listed can be entered in the free-text search field if desired.\nPortable URLs\nThe Event Feed URL maintains the current filters, scope and selected elements. You can share this URL with other users to let them display the same data.\nProcess TreeThe Process Tree provides visualizations for workload-related events.\nThe Process Tree is enabled by default on:\nLinux Agent versions 12.16.0 and later. Windows Agent versions 1.2.0 and later. Select an event from the Events Feed to open the Event Details pane. Here, you will see the Process Tree summary.\nClick Explore to open the Process Tree page.\nFind Workload EventsNot all events include process trees at this time. Workload events invoke Falco policies that apply to system-call-related data.\nYou can quickly filter workload events with ruleType = Falco - Syscall\nExplore Process Trees with Event CorrelationEvent correlation lets you start from the process tree of a targeted event and view any other events within that process tree from a particular time frame.\nNo additional requirements are needed to enable this feature apart from previous process tree requirements.\nAll Process Trees have a \u0026ldquo;focused\u0026rdquo; event that determines the scope and time box as to which events to show. The process tree always shows the ancestral lineage to the root process. Lineage to the offspring only shows if a Sysdig event has occurred. AnatomyHeader The header in the Process Tree consists of:\nScope: Metadata on the focused event, which may include the cloud account metadata down to the pod and host metadata. All events shown in the tree have the same scope. Time Box Dropdown: The time elapsed before and after the focused event occurred. The default is 15 minutes before and after, with options for 10 and 5 minutes. Severity Filters: Based on the severity of the event, you can filter more or fewer events. Process Tree Overlay\nOn the left side of the process tree is a timeline. The process tree starts at the focused event, shown with the bold outline, and the time of the event. The time of each related process is shown in relation to the event, for example -7 hr and + 2 s Use the chevron on the left to expand or collapse any process with any number of offspring. Process names stacked within a tree also indicate collapsed processes (for example, the second-to-last line in the image). The latest and highest severity policy name for an event shows inline of each process within the tree. Any other events are indicated inline with the count of events by severity. The counts do not include the event with the details shown. For example, the last line in the image shows two unique events. Process \u0026amp; Event Summary Process Summary: Select a process with one or more events to summarize the process details, including the Process ID, Session ID, username and more. Each unique rule triggered will show under the process details, which will open the Event Details panel. Event Details: These are the details provided from the events feed with all event information, including the rules, policies and related metadata. Captures For runtime policy events that have an associated capture, you can find available options through the Respond button. Here, you can:\nView the capture directly in Sysdig Inspect\nDownload the capture\nDelete the capture\nIf the event is scoped to a particular container, Sysdig Inspect automatically filters the displayed information to the scope of that Container ID.\nNetsec TopologyAs part of an event triage, it may be useful to get a bird\u0026rsquo;s-eye view of the network activity, for example, to establish what is connected to what, what else a service communicates with, and whether the connection is expected or an outlier.\nWhen relevant, the event detail Respond button provides a quick link to the Network Activity topology, which displays visible users with Advanced User privileges or above, as well as the ability for administrators to craft a unique netsec policy as needed.\nThe event should include cluster/ namespace/workload details (one of deployment, daemonset, statefulset, job, cronjob), and actual network activity on the workload for the Network Activity link to be offered.\nTunable ExceptionsSysdig\u0026rsquo;s Runtime Policy Tuner helps reduce false positives using rule exceptions. If there are potential exceptions that match one or more events from the same rule a {#} Tunable Exceptions button may appear in the event details, or under the Respond button. When clicked, a modal appears with suggestions of matching exceptions.\nSelect an event and open it to view the event details. If there are available exceptions, you will see an option for Tunable Exceptions.\nNOTE: You can also navigate to the same event details from the Insights module\nSelect Tunable Exceptions.\nThe Tune Rule window appears.\nReview the suggested exceptions and decide whether to use them:\nCompare the Existing Values with the Suggestion.\nAdjust the suggested values, if necessary.\nFor example, if the suggestion said contains: prod-app-1 but you wanted to apply the exception to all the clusters in production, you could edit it to contains: prod.\nReview the previously-applied exceptions that are also displayed, to gain context for the decision.\nClick View affected policies to see all the places the rule and exception would be used.\nClick Apply, or\nIf you want to manage Exceptions outside of Sysdig, click View Exception as YAML/Terraform to copy the snippet in your preferred format.\nSee also: Tuning Best Practices\nTeam Scope and the Event FeedNot every label available in the Sysdig Platform is compatible with the set of labels used to define the scope of a security event in the Event Feed.\nTherefore, to correctly determine if a set of events is visible for a certain Sysdig Secure team, the team scope must not use any label outside the following list.\nPermitted Labels\nagent.tag.* (any label starting with agent.tag is valid) host.hostName host.mac kubernetes.cluster.name kubernetes.namespace.name kubernetes.node.name kubernetes.namespace.label.field.cattle.io/projectId kubernetes.namespace.label.project kubernetes.pod.name container.name container.image.id container.image.repo container.image.tag container.image.digest container.label.io.kubernetes.container.name container.label.io.kubernetes.pod.name container.label.io.kubernetes.pod.namespace container.label.maintainer Also supported is the ability to not use any label to define team scope (Everywhere).\nIf the Secure team scope is defined using a label outside of the list above, the Event Feed will be empty for that particular team.\n","url":"https://docs.sysdig.com/en/sysdig-secure/threats-event-feed/"},{"id":17,"title":"Findings","content":"The failed requirements are sorted by severity and importance. You can view the following:\nControls Failed: The number of controls that failed out of the total number of controls Policy/Control Type: The name of the policy or control type that failed. Hover over the visual logos to see details about the types. Severity: The number of controls or failed with High, Medium, and Low severity Accepted: The number of accepted risks Passing: The number of controls that passed the evaluation. Accept Risk: Global risk acceptance for the control You can edit the filters to focus on the compliance findings that are relevant to you. The Findings page presents the policy requirements for the selected zones and policies, and the controls under each requirement.\nSelect a finding from the list to see the individual controls.\nAccept Risk Globally on a ControlEnsure that you have the required permission to use this feature.\nIn addition to accepting the risk on a single resource, you can accept risk for an entire control, affecting all resources that match the given zone.\nSelect Attack Surface | Findings and a particular tile corresponding to a finding.\nClick an item to display the details drawer and click the Create Exception button to define it as an acceptable risk.\nFill out the required fields to comply with audit best practices and click Save.\nReason: Select a reason, such as Risk Owned, Transferred, Avoided, Mitigated, Not Relevant, or Custom.\nSee Reasons for Accepting Risk.\nDetails: Explain to an auditor more details about the reason for accepting the risk.\nExpires In: Select when you want this acceptance to expire. If the control still fails after the acceptance expires, it will trigger again. Use a default option, such as seven days, or set a custom time span.\nExpiration Date: If you set a Custom expiration period, enter the desired expiration date here.\nYou can filter violations by Has Exception = True to address them or go to the Exceptions management panel. A global accept appears on the Exceptions page under \u0026ldquo;Context\u0026rdquo; showing All Resources.\nReasons for ExceptionsOwned: The risk falls within your risk tolerance levels. No additional risk response action is needed except for monitoring.\nTransferred: For risks that fall outside of tolerance levels, reduce them to an acceptable level by sharing a portion of the consequences with another party, such as cybersecurity insurance. While some of the financial consequences may be transferrable, there are often consequences that cannot be transferred, like the loss of customer trust.\nAvoided: You have taken actions to eliminate the activities or conditions that give rise to risk. Avoiding risk may be the best option if there is no cost-effective method for reducing the risk to an acceptable level. The lost opportunity cost associated with such a decision should also be considered.\nMitigated: You have reduced a given risk\u0026rsquo;s threats, vulnerabilities, and impacts to an acceptable level. This could range from reducing the probability of occurrence, or limiting damage caused by occurrence.\nNot Relevant: The risk does not pose a threat or impact that warrants any specific action or response. Organizations may decide that certain risks are outside the scope of their operations, or that the likelihood or potential impact of the risk is negligible compared to other priorities. However, it\u0026rsquo;s important to thoroughly assess and document the rationale behind deeming a risk Not Relevant to ensure comprehensive risk management.\nCustom: This involves devising unique strategies to address risks that don\u0026rsquo;t align with standard response types. Tailored to fit the organization\u0026rsquo;s specific circumstances and risk tolerance, these responses may combine existing measures with innovative approaches to effectively mitigate identified risks.\nDrill Down to the Control PaneFrom the Attack Surface | Findings page, click a finding type to open the Control pane on the right and review the resources that were evaluated by the control.\nHere you can see:\nA description of the control An overview of all resources that have passed, failed, or have exceptions Filters in the Control PaneThe Control pane shows a mini-inventory with the top 50 resources that were evaluated by the control.\nUse filters to find additional resources. You can construct filter expressions in the Control pane on resource attributes:\nFor each of the following Control Types, you can refine your search in the mini-inventory using the associated attributes:\nKubernetes Identity\nCluster Labels Name NamespaceType (= Resource Type in Inventory) - ex: Group, ServiceAccount, User Kubernetes Resource\nCluster\nLabels\nName\nNamespace\nType ( Resource Type in Inventory)\nFor example, Deployment, DaemonSet, StatefulSet, ReplicaSet, Pod, Job, CronJobHost (K8s, Linux, Docker)\nHost (K8s, Linux, Docker)\nCluster Name OS (Operating System in Inventory) OS Image Managed Cloud Identity \u0026amp; Resource (AWS, GCP, Azure)\nAccount Location (Region in Inventory) Name Organization Select a failing resource to review its remediation guidelines and take action toward its remediation.\nEvaluate and RemediateThe remediation solutions are under continued development in the product.\nSome remediation flows are manual, while others offer different degrees of automation.\nSysdig can present a fix to be manually applied to production, or it can fix the resource via the creation of a Pull Request with the required changes directly in the Git repository that has been previously configured as an IaC integration.\nCurrently, most risk response actions are for a single resource for a single violation. Several types of risk responses are supported:\nManual Remediation: Displays playbook text to remediate the violation. Automatically generate a patch (with or without user input): Displays patch code with an input field if new values are required - you can download the patch, copy and paste the patch application code. Set up an Automatic Pull Request (with or without user input): Displays patch code (with an input field if new values are required) - and you open a PR. Ensure that you have the required permission to use this feature. Accept the Risk on a resource. Note: You can Accept the Risk on an entire control as well. See Accept Risk Globally on a Control. Remediation: How Do Source Detection and Fixing Work?Source Detection\nWhen applying remediation to a resource, Sysdig tries to identify the matching source file from your configured Git integrations. If there are multiple candidates, or if finding the matching source file is impossible, you can use the search field to manually explore and select the relevant file from the connected Git repositories.\nPull Requests (PRs)\nWhen using Pull Request for remediation, Sysdig creates a branch directly in your Git repository, and fixes the offending resource with corrective changes. You can review all the suggested changes in the PR before you merge it.\nFor more information, see IaC integration configuration instructions.\nReview the Remediation PaneTo access the Remediation pane:\nLog in to Sysdig Secure, and select Dashboards \u0026gt; Compliance Overview.\nSelect a zone/policy from the drop-down list to narrow the results.\nClick a requirement from the list to see controls.\nSelect a control to open the Overview \u0026gt; Results pane.\nFrom the Resource Evaluation list, select a resource to View Remediation.\nThis pane will differ depending on the specific control and resource evaluation.\nIf remediation code is available, and Git integration has been set up, then the full remediation pane will be displayed.\nIf there is more than a single possible matching file for the resource, all the candidates are displayed as Suggested Sources.\nIf no candidates are displayed or you want to choose a different file, you can click the Search Source button to manually select from the list of possible files in the connected Git repositories.\nReview IssuesHere you see the impact of the remediation, review the resource attributes, and, if relevant, enter a necessary Value that will be incorporated into the patch code.\nIf a required value is detected, it will be automatically inserted and the Value input field will be read-only.\nRemediateThe code is presented for review when there is a remediation that can be applied manually or used in a Pull Request to remediate the IaC file. In most cases, Sysdig recommends that you download the code in the Continue Remediation section, but you can also copy/paste it.\nContinue Remediation - ManualIf you have not integrated your Git repository with Sysdig’s IaC Scanning, or if creating a pull request is not required in a particular resource failure, then you can perform remediation manually.\nUse the button to download and apply the provided code.\nContinue Remediation - Pull RequestEnsure that you have the required permission to use this feature.\nAfter configuring IaC Scanning in your account, Sysdig scans and analyzes the manifests and modules from your defined Git sources, and scrapes resources declared in your source files. The scan process runs daily or whenever a new Git source is added.\nSysdig tries to match and identify the resources discovered from the IaC Scanning with the deployed and evaluated resources. The best matches under Suggested Sources in the Remediation pane when setting up a Pull Request.\nYou can also search manually for sources by their full URL path.\nUse the button to Open a Pull Request.\nWorkflow Name Selector for Helm/Kustomize:\nWhat is it: You select a source of type Helm/Kustomize. You can type a selector for the workload name. Why: In Helm, in most cases, workload names are derived from the release name, which means that they change with every new release. The selector is a regular expression that matches workloads by prefix/suffix (or a more complex pattern). With the selector in place, you can use the remediation for workloads generated from the same chart, regardless of the release.\nNote that Sysdig will create a new Pull Request in your repository with the suggested fixes, and depending on your Git source configuration, Sysdig can run a Pull Request Policy Evaluation that might report other unfixed control violations.\nSee also: Pull Request Policy Evaluation.\nOption: Exceptions on a ResourceEnsure that you have the required permission to use this feature.\nUse the following steps to temporarily accept a failing control so the resource will pass and the compliance score will improve:\nNavigate to Attack Surface \u0026gt; Compliance Findings. Hover over an item and click the Create Exception button on the right.\nFill out the required fields, to comply with audit best practices, and click Save.\nReason: Risk Owned, Transferred, Avoided, Mitigated, Not Relevant, or Custom. See also: See also: Reasons for Accepting Risk.\nDetails: Explain to an auditor more details about the reason for accepting the risk.\nExpires In: Select when you want this acceptance to expire and the resource to fail. Options: 7, 30, 60 or 90 days; Custom time frame; Never.\nExpiration Date: If Expires In is set to Custom specify the date on which the acceptance expires, otherwise it is autocompleted.\nLater, you can filter violations by Accepted status to address them or go to the Accept Risk management panel.\nCreate and Download a ReportTo meet compliance goals, an organization may need to generate output to be shared with other stakeholders, such as executives or auditors, to show point-in-time compliance/violations.\nYou can use reports to share compliance results with your development teams. Download ad hoc reports as CSV files from the Compliance Results page or from an individual control.\nBased on the filters that have been selected, you can generate or manage reports.\nFor the Policy Compliance Report, you must select one zone and policy, otherwise the report features are disabled. You can still generate the report if additional filters, such as Requirements, Severity, or Status,are selected. Those do not reflect the outcome of the Policy Compliance Report.\nFor the Resource Posture Report, which generates a CSV, select the filters based on your reporting needs. Generating a report with all findings may increase the overall time to generate the report. It is recommended to select a zone, policy, severity, and only failing requirements. Limiting the report scope ensures it generates in a timely fashion.\nTo generate a report of Compliance results:\nSelect Attack Surface \u0026gt; Compliance Findings.\nSelect a tile of a requirement under one of your zones.\nOptional: filter as desired. For example: by dates, by pass/fail status, by controls, and so on. You can select more than one policy for a single zone. The maximum report size of 10 MB.\nClick Report at the top right.\nA file is downloaded in a CSV (Comma-Separated-Values) format and can be used as a spreadsheet.\nTo generate a report from an individual control:\nSelect Attack Surface \u0026gt; Compliance Findings.\nSelect a tile of a policy under one of your zones.\nSelect a control to open the control pane, filter the resources if required, and click the Download Report button.\nThe maximum report size is 10 MB.\nAlso consider using APIs. For details, see CSPM APIs.\n","url":"https://docs.sysdig.com/en/sysdig-secure/compliance-findings/"},{"id":18,"title":"Installation Requirements","content":"Prerequisites A Sysdig account and agent access key. A supported distribution or Kubernetes platform. System Requirements Linux kernel version 3.10 or later.\nPort 6443 open for outbound traffic.\nThe Host Shield communicates with the collector on port 6443. If you\u0026rsquo;re using a firewall, make sure to open port 6443 for outbound traffic so that the agent can communicate with the collector.\nContainer PlatformsSysdig supports the following container platforms:\nKubernetes v1.11 and above Google Kubernetes Engine (GKE) Amazon Elastic Kubernetes Service (EKS) Note: AWS Fargate is not supported on EKS Azure Kubernetes Service (AKS) IBM Cloud Kubernetes Service (IKS) RedHat OpenShift Kubernetes Service (ROKS) 4 and above Amazon ECS on EC2 Linux DistributionsSysdig supports the following Linux distributions:\nDebian v10 and above Ubuntu v18 and above Ubuntu (Amazon) v18 and above CentOS v7 and above Red Hat Enterprise Linux (RHEL) v7 and above SuSE Linux Enterprise Server v15 SP4 and above RHEL CoreOS (RHCOS) Fedora v36 and above Fedora CoreOS Linux Mint Amazon Linux Amazon Linux v2 Amazon Linux v3 Amazon Bottlerocket Google Container Optimized OS (COS) Oracle Linux (UEH) Oracle Linux (RHCK) Flatcar EulerOS * Linux service install is not supported on SuSE Linux Enterprise Server.\nContainer Runtimes Docker LXC CRI-O containerd Podman Mesos CPU Architectures X86 ARM Next Steps Install on ECS Install on Kubernetes Install on Linux Hosts ","url":"https://docs.sysdig.com/en/sysdig-monitor/installation-requirements/"},{"id":19,"title":"Installation Requirements","content":" A supported distribution or Kubernetes platform\nA Sysdig account and agent access key\nPort 6443 open for outbound traffic\nThe Sysdig Agent communicates with the collector on port 6443. If you\u0026rsquo;re using a firewall, make sure to open port 6443 for outbound traffic so that the agent can communicate with the collector.\nDetermine the Agent Mode\nAllow traffic on port 12000 to communicate within the cluster for Kubernetes Security Posture Management (KSPM).\nLinux Kernel 3.10 or later\nSupported across all Sysdig ComponentsKubernetes Platforms Kubernetes (Vanilla)\nAmazon Elastic Kubernetes Service (EKS)\nNote: AWS Fargate is not supported on EKS\nGoogle Kubernetes Engine (GKE)\nAzure Kubernetes Service (AKS)\nRedHat OpenShift\nIBM Kubernetes Service (IKS)\nRKE Government (RKE2)\nLinux Distributions Debian Red Hat Enterprise Linux (RHEL) Amazon Linux Amazon Linux 2 Google Container-Optimized OS (COS) CPU Architectures X86 ARM Sysdig supports additional Linux distributions depending on the feature required.\nFor Specific ComponentsSee individual pages for component installation requirements and supported platforms:\nSysdig Agent Host Scanner KSPM ECS Fargate Next StepsInstall on a Kubernetes cluster\nInstall on a Host\nInstall on an ECS cluster on EC2\nInstall on an ECS Fargate cluster\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-installation-requirements/"},{"id":20,"title":"Integrations Library","content":"Prometheus Integrations Apache Calico Cassandra Ceph Consul Elasticsearch Fluentd Go HAProxy Ingress HAProxy Ingress OpenShift Harbor Istio Istio Envoy Kafka KEDA Knative Memcached Microsoft IIS Microsoft SQL Server MongoDB MySQL NGINX NGINX Ingress NTP OPA OracleDB PHP-FPM Portworx PostgreSQL RabbitMQ Redis Redis Enterprise Sysdig Admission Controller Sysdig Cost Advisor Sysdig Monitor Cloud IntegrationsAWS Metric Streams AWS Lambda Metrics AWS MetricsStream ALB AWS MetricsStream CloudFront AWS MetricsStream EBS AWS MetricsStream ELB AWS MetricsStream Fargate AWS MetricsStream Lambda AWS MetricsStream RDS AWS MetricsStream S3 AWS MetricsStream SQS Azure Integrations Azure API Management Azure Blob Storage Azure Cluster Autoscaler Azure Files Azure Kubernetes Service Azure Queue Storage Azure SQL Azure Storage Accounts Azure Synapse Analytics Azure Table Storage Azure Virtual Machine Scale Sets Azure Virtual Machines GCP Integrations GCP Cloud MySQL GCP Cloud PostgreSQL GCP Cloud SQL Server GCP Compute Engine GCP Memorystore for Redis Infrastructure Integrations IBM Kubernetes API Server Kubernetes API server K8s cAdvisor K8s cAdvisor full Kubernetes controller manager Kubernetes CoreDNS Kubernetes etcd Kubernetes kubelet Kubernetes kube-proxy Kubernetes PVC Kubernetes Scheduler Kubernetes storage Kubernetes Linux OpenShift API-Server OpenShift Controller Manager OpenShift CoreDNS OpenShift Etcd OpenShift Kubelet OpenShift Scheduler OpenShift State Metrics Rancher RKE API Server Rancher RKE Controller Manager Rancher RKE CoreDNS Rancher RKE Kube Proxy Rancher RKE Scheduler Rancher RKE2 API Server Rancher RKE2 Controller Manager Rancher RKE2 CoreDNS Rancher RKE2 Etcd Rancher RKE2 Kube Proxy Rancher RKE2 Scheduler Windows ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/"},{"id":21,"title":"Manage Access Keys","content":"You need the API token from the Sysdig UI to use the API. For more information, see Retrieve the Sysdig API Token.\nReplace the API_TOKEN with your API token in the API calls given below.\nBoth /api/customer and /api/customers endpoints are valid and interchangeable. However, all the examples listed here uses /api/customers to align with the usage.\nView and Search for Access KeysTo view all the access keys for your Sysdig instance, do the following:\nIssue a curl GET request against the Sysdig Monitor endpoint to retrieve all access keys:\n$ curl -X GET -H 'Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;' https://\u0026lt;HOSTNAME\u0026gt;/api/customers/accessKeys\nYou can add a GET parameter at the end of the URL in the form of parameter=value to search using the given parameter. You can combine several parameters. Wildcards are not supported. List of available parameters:\naccessKey=\u0026lt;ACCESS_KEY\u0026gt;: The access key to search for. metadata-key=\u0026lt;METADATA_VALUE\u0026gt;: The metadata key-value pair to search for. For more information, see Search the Available Access Keys Based on Metadata. enabled=\u0026lt;ENABLED\u0026gt;: Specifies that search is performed based on the enabled parameter. Allowed values are true or false id=\u0026lt;ID\u0026gt;: The ID of the access key. The value must be numeric and unique. limit=\u0026lt;LIMIT\u0026gt;: The limit of access keys to return. This parameter is used by the UI. offset=\u0026lt;OFFSET\u0026gt;: The number of access keys to skip before beginning to return data. This parameter is used by the UI. teamId=\u0026lt;TEAM_ID\u0026gt;: Specifies that the search is performed using Team ID. See Retrieve the Available Access Keys Based on Team ID). Replace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;HOSTNAME\u0026gt; with Sysdig domain associated with your region. The output provides a list of the access keys in the response and indicates whether they are enabled.\n{ \u0026#34;customerAccessKeys\u0026#34;: [ { \u0026#34;id\u0026#34;: 1234, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;12345678-1234-4321-1234-123456789000\u0026#34;, \u0026#34;dateCreated\u0026#34;: 5242096409000, \u0026#34;dateDisabled\u0026#34;: null, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: null, \u0026#34;metadata\u0026#34;: {} }, { \u0026#34;id\u0026#34;: 5678, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;87654321-1234-1234-1234-123456789012\u0026#34;, \u0026#34;dateCreated\u0026#34;: 2553849361000, \u0026#34;dateDisabled\u0026#34;: 2553849367000, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: null, \u0026#34;metadata\u0026#34;: {} } ] } Delete an Access Key You can delete only disabled access keys.\nTo delete an access key:\nIssue a curl DELETE request against the Sysdig Monitor endpoint:\n$ curl -XDELETE -H 'Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;' https://\u0026lt;HOSTNAME\u0026gt;/api/customers/accessKeys/\u0026lt;ACCESS_KEY\u0026gt;\nReplace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;ACCESS_KEY\u0026gt; with the Access Key you would like to delete. \u0026lt;HOSTNAME\u0026gt; with Sysdig domain associated with your region. There is no response, only a response status 200 to confirm that the action was performed successfully.\nRetrieve the Access KeysTo view all the access keys assigned to a team of the user whose API token is used:\nIssue a curl GET request against the Sysdig Monitor endpoint to retrieve the list of access keys:\n$ curl -X GET -H 'Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;' https://\u0026lt;HOSTNAME\u0026gt;/api/customers/accessKeys/forCurrentTeam\nReplace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;HOSTNAME\u0026gt; with Sysdig domain associated with your region. The output provides a list of the access keys in the response and indicates whether they are enabled.\n{ \u0026#34;total\u0026#34;: 2, \u0026#34;customerAccessKeys\u0026#34;: [ { \u0026#34;id\u0026#34;: 1234, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;12345678-1234-4321-1234-123456789000\u0026#34;, \u0026#34;dateCreated\u0026#34;: 5242096409000, \u0026#34;dateDisabled\u0026#34;: null, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: 1, \u0026#34;metadata\u0026#34;: {} }, { \u0026#34;id\u0026#34;: 5678, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;87654321-1234-1234-1234-123456789012\u0026#34;, \u0026#34;dateCreated\u0026#34;: 2553849361000, \u0026#34;dateDisabled\u0026#34;: 2553849367000, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: 1, \u0026#34;metadata\u0026#34;: {} } ] } Retrieve the Access Keys Based on Team IDTo view all of the access keys assigned to a specific team.\nIssue a curl GET request against the Sysdig Monitor endpoint to retrieve the list of access keys:\n$ curl -X GET -H 'Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;' https://\u0026lt;HOSTNAME\u0026gt;/api/customers/accessKeys?teamId=\u0026lt;TEAM_ID\u0026gt;\nReplace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;TEAM_ID\u0026gt; with the ID of an existing team. \u0026lt;HOSTNAME\u0026gt; with Sysdig domain associated with your region. The output provides a list of the access keys in the response and indicates whether they are enabled.\n{ \u0026#34;total\u0026#34;: 0, \u0026#34;customerAccessKeys\u0026#34;: [ { \u0026#34;id\u0026#34;: 1234, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;12345678-1234-4321-1234-123456789000\u0026#34;, \u0026#34;dateCreated\u0026#34;: 5242096409000, \u0026#34;dateDisabled\u0026#34;: null, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: 1, \u0026#34;metadata\u0026#34;: {} }, { \u0026#34;id\u0026#34;: 5678, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;87654321-1234-1234-1234-123456789012\u0026#34;, \u0026#34;dateCreated\u0026#34;: 2553849361000, \u0026#34;dateDisabled\u0026#34;: 2553849367000, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: 1, \u0026#34;metadata\u0026#34;: {} } ] } Search for the Access Keys Based on MetadataTo search for access keys based on the metadata, do the following:\nIssue a curl GET request against the Sysdig Monitor endpoint to search based on the metadata:\n$ curl -X GET -H 'Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;' https://\u0026lt;HOSTNAME\u0026gt;/api/customers/accessKeys\u0026lt;METADATA_SEARCH\u0026gt;\nReplace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;METADATA_SEARCH\u0026gt; with URL encoded metadata search criteria, for example ?business-unit=testUnit. The system supports a maximum of 10 entries. Wildcards are not allowed. \u0026lt;HOSTNAME\u0026gt; with Sysdig domain associated with your region. The output provides a list of access keys in the response and indicates whether they are enabled.\n{ \u0026#34;total\u0026#34;: 1, \u0026#34;customerAccessKeys\u0026#34;: [ { \u0026#34;id\u0026#34;: 5678, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;12345678-1234-4321-1234-123456789000\u0026#34;, \u0026#34;dateCreated\u0026#34;: 5242096409000, \u0026#34;dateDisabled\u0026#34;: null, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: null, \u0026#34;metadata\u0026#34;: { \u0026#34;business-unit\u0026#34;: \u0026#34;testUnit\u0026#34; } } ] } Create an Access KeyTo create an access key:\nIssue a curl POST request against the Sysdig endpoint to generate a new access key:\n$ curl -XPOST -H 'Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;' \u0026lt;PAYLOAD\u0026gt; https://\u0026lt;HOSTNAME\u0026gt;/api/customers/accessKeys\nReplace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;HOSTNAME\u0026gt; with Sysdig domain associated with your region. \u0026lt;PAYLOAD\u0026gt; (optional) You can omit this. The structure is as follows: -d \u0026#39;{ \u0026#34;customerAccessKey\u0026#34;: { \u0026#34;limit\u0026#34;: \u0026lt;LIMIT\u0026gt;, \u0026#34;reservation\u0026#34;: \u0026lt;RESERVATION\u0026gt;, \u0026#34;teamId\u0026#34;: \u0026lt;TEAM_ID\u0026gt;, \u0026#34;metadata\u0026#34;: { \u0026lt;METADATA\u0026gt; } } }\u0026#39; \u0026lt;LIMIT\u0026gt; - Maximum number of agents allowed to connect for this access key. Set to null if not required. \u0026lt;RESERVATION\u0026gt; - Number of agent licenses that are ALWAYS available to this access key. This directly counts against the maximum number of available licenses. Set to null if not required. \u0026lt;TEAM_ID\u0026gt; - Team ID to which to assign the access key. Team ID must be valid. Set to null if not required. \u0026lt;METADATA\u0026gt; - Metadata is in the form of comma separated key/value pairs. For example: \u0026#34;environment\u0026#34;: \u0026#34;testEnv\u0026#34;, \u0026#34;business-unit\u0026#34;: \u0026#34;testUnit\u0026#34;, \u0026#34;cluster-name\u0026#34;: \u0026#34;testCluster\u0026#34; The output provides the newly generated access key in the response.\n{ \u0026#34;customerAccessKey\u0026#34;: { \u0026#34;id\u0026#34;: 5678, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;87654321-1234-1234-1234-123456789012\u0026#34;, \u0026#34;dateCreated\u0026#34;: 2263852422114, \u0026#34;dateDisabled\u0026#34;: null, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: null, \u0026#34;metadata\u0026#34;: {} } } You can now use the access key in the Sysdig agent configuration files.\nUpdate an Access KeyTo update an access key:\nIssue a curl PUT request against the Sysdig endpoint to update an existing access key:\n$ curl -XPUT -H 'Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;' \u0026lt;PAYLOAD\u0026gt; https://\u0026lt;HOSTNAME\u0026gt;/api/customers/accessKeys/\u0026lt;ACCESS_KEY\u0026gt;\nReplace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;HOSTNAME\u0026gt; with Sysdig domain associated with your region. \u0026lt;ACCESS_KEY\u0026gt; with an existing Access Key to be updated. \u0026lt;PAYLOAD\u0026gt; (optional) You can omit this. The structure is as follows: -d \u0026#39;{ \u0026#34;customerAccessKey\u0026#34;: { \u0026#34;limit\u0026#34;: \u0026lt;LIMIT\u0026gt;, \u0026#34;reservation\u0026#34;: \u0026lt;RESERVATION\u0026gt;, \u0026#34;teamId\u0026#34;: \u0026lt;TEAM_ID\u0026gt;, \u0026#34;metadata\u0026#34;: { \u0026lt;METADATA\u0026gt; } } }\u0026#39; \u0026lt;LIMIT\u0026gt; - Maximum number of agents allowed to connect for this access key. Set to null if not required. \u0026lt;RESERVATION\u0026gt; - Number of agent licenses that are ALWAYS available to this access key. This directly counts against the maximum number of available licenses. Set to null if not required. \u0026lt;TEAM_ID\u0026gt; - Team ID to which to assign the access key. Team ID must be valid. Set to null if not required. \u0026lt;METADATA\u0026gt; - Metadata is in the form of comma separated key/value pairs. For example: \u0026#34;environment\u0026#34;: \u0026#34;testEnv\u0026#34;, \u0026#34;business-unit\u0026#34;: \u0026#34;testUnit\u0026#34;, \u0026#34;cluster-name\u0026#34;: \u0026#34;testCluster\u0026#34; The output will provide updated information for the provided access key in the response.\n{ \u0026#34;customerAccessKey\u0026#34;: { \u0026#34;id\u0026#34;: 5678, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;87654321-1234-1234-1234-123456789012\u0026#34;, \u0026#34;dateCreated\u0026#34;: 2263852422114, \u0026#34;dateDisabled\u0026#34;: null, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: null, \u0026#34;metadata\u0026#34;: {} } } The access key is now updated.\nDisable an Access KeyTo disable an existing access key:\nIssue a curl POST request against the Sysdig Monitor or Secure endpoint to disable the given access key.\n$ curl -XPOST -H 'Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;' https://\u0026lt;HOSTNAME\u0026gt;/api/customers/accessKeys/\u0026lt;ACCESS_KEY\u0026gt;/disable\nReplace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;HOSTNAME\u0026gt; with Sysdig domain associated with your region. \u0026lt;ACCESS_KEY\u0026gt; with the access key that you wish to disable. { \u0026#34;customerAccessKey\u0026#34;: { \u0026#34;id\u0026#34;: 5678, \u0026#34;enabled\u0026#34;: false, \u0026#34;accessKey\u0026#34;: \u0026#34;87654321-1234-1234-1234-123456789012\u0026#34;, \u0026#34;dateCreated\u0026#34;: 2553849361000, \u0026#34;dateDisabled\u0026#34;: 2553849367000, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: null, \u0026#34;metadata\u0026#34;: {} } } After you disable the Sysdig access key, the agents connected with the access key will be immediately blocked from sending data to the Sysdig backend.\nIf an agent tries to connect with a disabled access key, it will be terminated.\nEnable an Access KeyTo enable an existing access key:\nIssue a curl POST request against the Sysdig Monitor endpoint to enable the given access key.\n$ curl -XPOST -H 'Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;' https://\u0026lt;HOSTNAME\u0026gt;/api/customers/accessKeys/\u0026lt;ACCESS_KEY\u0026gt;/enable\nReplace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved in step 1. \u0026lt;HOSTNAME\u0026gt; with Sysdig domain associated with your region. \u0026lt;ACCESS_KEY\u0026gt; with the access key that you wish to disable. Restart the agents for the new connection to work as expected. { \u0026#34;customerAccessKey\u0026#34;: { \u0026#34;id\u0026#34;: 5678, \u0026#34;enabled\u0026#34;: true, \u0026#34;accessKey\u0026#34;: \u0026#34;87654321-1234-1234-1234-123456789012\u0026#34;, \u0026#34;dateCreated\u0026#34;: 2553849361000, \u0026#34;dateDisabled\u0026#34;: null, \u0026#34;limit\u0026#34;: null, \u0026#34;reservation\u0026#34;: null, \u0026#34;teamId\u0026#34;: null, \u0026#34;metadata\u0026#34;: {} } } The agent that tries to connect with an enabled access key will be allowed to connect.\n","url":"https://docs.sysdig.com/en/developer-tools/managing-access-keys/"},{"id":22,"title":"Manage Threat Detection Policies","content":"Types of Threat Detection PoliciesThere are three Threat Detection policy management types:\nManaged Policy: These policies are created and managed by the Sysdig Threat Research Team. Sysdig updates them regularly. Managed Ruleset: Create a Managed Ruleset by duplicating a managed policy. Managed Ruleset policies still get updates, but are more flexible. Custom Policy: Create a Custom Policy from scratch or by converting existing policies. You have full control, but are responsible for keeping rules up-to-date. Edit a Managed PolicyManaged Policies are created by Sysdig, and are available out of the box. These policies detect various malware, data exfiltration, intrusions, DDoS attacks, and more.\nManaged policies have the following attributes:\nThey exist across all accounts, their names cannot be changed or deleted.\nThey are loaded with a pre-defined enabled or disabled status, based on most common usage, but you can manually Enable or Disable them.\nYou can edit their Scope and Action.\nTo edit a Managed Policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nSelect a policy of the type Managed Policy from Runtime Policies list to expand the policy details and access the icons to edit, copy, or delete the policy.\nClick the edit (pencil) icon.\nConfigure the available parameters.\nIn a Managed Policy, you can toggle the enablement, change the scope, add a Runbook link, enable or disable individual rules, and change the notification settings.\nSave your changes.\nTo make other changes, such as to the name, description, or severity, you must duplicate the policy so that it becomes a Managed Ruleset. See Create a Managed Ruleset Policy.\nManage Daily Updates (On-Prem Only)For on-premises deployments (v6.1.1+), the managed policies and rules are updated daily at midnight UTC. The schedule is handled automatically by the sysdigcloud-falco-rules-deployer cron job service.\nTo change the frequency:\nEdit Values.sysdig.secure.rulesDeployer.schedule to your preferred settings.\nTo disable:\nEdit Values.sysdig.secure.rulesDeployer.enabled to suspend the cron job.\nCreate a Managed Ruleset PolicyDuplicate a Managed Policy to create a Managed Ruleset. This allows you to create multiple policies based one set of rules, but scoped to different environments, and with different actions and additional attributes. This is useful when you need different scopes or actions, such as notification channels, for the same set of rules within a Managed Policy.\nManaged Rulesets have the following attributes:\nYou can edit the Name, Description, Severity, Scope, and Action.\nAs with the default Managed policies, Managed Rulesets are updated by the Sysdig Threat Research team.\nTo create a Managed Ruleset:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFrom the Runtime Policies list, select a Managed Policy, or a Managed Ruleset, and click the duplicate/copy icon in the details panel.\nOptional: Edit any of the parameters except the rules. Rules can be enabled or disabled, but they cannot be removed. To remove a rule, create a custom policy.\nSelect Save.\nThe new policy will appear in the Runtime policy list. Under Managed Type, it will say Managed Ruleset.\nWhen Sysdig updates the ruleset of the Managed Policy on which a Managed Ruleset is based, the Managed Ruleset will also be updated.\nCreate a Custom PolicyCustom policies are not subject to ruleset updates by Sysdig\u0026rsquo;s Threat Research Team. Therefore, you are responsible for ensuring the latest security detections are enabled. You can modify all fields in custom policies.\nThere are three ways to create a Custom policy:\nCreate a policy from scratch Convert a Default managed policy to Custom Convert a Managed Ruleset policy to Custom Create a Custom Policy from ScratchTo create a Custom Policy from scratch:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nOn the Runtime Policies list page, select +Add Policy.\nSelect the Policy type you\u0026rsquo;d like to create.\nConfigure the policy\u0026rsquo;s parameters, such as Name, Description, and Severity.\nSome parameters will vary by policy types. For specific instructions, see the particular policy page. For example, Linux Workload Policy.\nAdd and edit Policy Rules. Some policy types come with pre-configured rules.\nDefine Actions to be taken if the policy rules are breached, such as Notify an email or Slack channel.\nEnable and Save the policy.\nConvert a Managed Ruleset to CustomTo convert a Managed Ruleset into a Custom Policy:\nSelect a Managed Ruleset policy from the Runtime Policies list and click the edit icon in the details panel.\nTo create a custom policy from a Managed Policy, you must first duplicate it so that it becomes a Managed Ruleset.\nIn the Policy Rules section, click convert to a custom policy.\nYou can now edit everything about this policy, including the rules. It will not be managed or updated by the Sysdig team; if new rules are offered, you are responsible for adding them to the custom policies.\nClick Save.\nDuplicating a custom policy creates another unmanaged custom policy.\nConfiguration ExamplesDifferent policy types may have different configuration details, as described in the three examples linked below.\nLinux Workload Policy Example (provided out of the box, but can be created or edited)\nContainer Drift Detection Policy Example (always custom)\nMachine Learning Policy Example (always custom)\nCustomize Policy UpdatesWhenever a rule or policy is updated, the updates are sent out to all the Sysdig agents in your environments. If you have thousands of agents deployed, this might cause excess network activity.\nTo reduce network traffic, use API calls to affix tags to your Sysdig agents. You can manually control when, or whether, an agent receives policy and rule updates. This enables you to reduce the amount of communication between agents and the Sysdig backend.\nUse API CallsAffix TagsThis API request pushes policy and rule updates to agents with specified tags.\nRequest\nPOST /secure/policies/v4/deployments\n{ \u0026#34;tags\u0026#34;: {dict} } Example:\n{ \u0026#34;tags\u0026#34;: { \u0026#34;environment\u0026#34;: \u0026#34;production\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;service\u0026#34;: \u0026#34;web\u0026#34; } } Response\nThe response from policies service will contain the unique identifier deploymentId to check the status:\n{ \u0026#34;deploymentId\u0026#34;: uuid, \u0026#34;deploymentExpression\u0026#34;: string } Example:\n{ \u0026#34;deploymentId\u0026#34;: \u0026#34;abc123\u0026#34;, \u0026#34;deploymentExpression\u0026#34;: \u0026#34;environment=production,service=web,version=1.0.0\u0026#34; } Check Deployment StatusCheck the status of a deployment with deployment ID.\nRate limit: 1 request per minute.\nRequest\nGET \u0026quot;/secure/policies/v4/deployments/{deploymentId}\u0026quot;\nResponse\n{ \u0026#34;deploymentId\u0026#34;: uuid, \u0026#34;status\u0026#34;: string, \u0026#34;agentsTotal\u0026#34;: opt[int], \u0026#34;agentsPushed\u0026#34;: opt[int], \u0026#34;tags\u0026#34;: dict } Example\nIf the response status is in_progress there is an optional field of count of agents that have completed the deployment, (agentsPushed), and total expected (agentsTotal):\n{ \u0026#34;deploymentId\u0026#34;: \u0026#34;abc123\u0026#34;, \u0026#34;status\u0026#34;: \u0026#34;in_progress\u0026#34;, \u0026#34;agentsTotal\u0026#34;: 100, \u0026#34;agentsPushed\u0026#34;: 95, \u0026#34;tags\u0026#34;: { \u0026#34;environment\u0026#34;: \u0026#34;production\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;service\u0026#34;: \u0026#34;web\u0026#34; } } If the response status is complete, there are no additional counts:\n{ \u0026#34;deploymentId\u0026#34;: \u0026#34;abc123\u0026#34;, \u0026#34;status\u0026#34;: \u0026#34;complete\u0026#34;, \u0026#34;tags\u0026#34;: { \u0026#34;environment\u0026#34;: \u0026#34;production\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;service\u0026#34;: \u0026#34;web\u0026#34; } } Disable Automatic Agent Policy UpdatesThe blackout command stops the backend from pushing policies updates automatically to the agent.\nStatus Request\nGET /api/secure/policies/v1/blackout\nResponse\nIf not enabled:\n{\u0026#34;message\u0026#34;:\u0026#34;Not Found\u0026#34;,\u0026#34;referenceId\u0026#34;:\u0026#34;043353e8-fda4-446e-81fc-4b9714495495\u0026#34;} If enabled:\n{\u0026#34;DateTimeStarted\u0026#34;:\u0026#34;2024-06-18 20:07:06.285582+00\u0026#34;,\u0026#34;StartedBy\u0026#34;:\u0026#34;eric.lugo@sysdig.com\u0026#34;} Enable Status Request\nPUT /api/secure/policies/v1/blackout\nResponse\nSuccessful:\nnull\nDisable Status Request\nDELETE /api/secure/policies/v1/blackout\nResponse\nSuccessful:\nnull\nLimitationsSupported Notification ChannelsThreat Detection Runtime Policies are supported for the following notification channels:\nAmazon SNS Email Microsoft Teams OpsGenie PagerDuty Slack Sysdig Team Email VictorOps Webhook Kubernetes workload labelsThe following Kubernetes labels are no longer supported as part of a policy scope, however you can still use these labels to search events.\nkubernetes.daemonset.name kubernetes.deployment.name kubernetes.statefulset.name kubernetes.replicaset.name ","url":"https://docs.sysdig.com/en/sysdig-secure/manage-threat-detection-policies/"},{"id":23,"title":"Metrics Library","content":"The metrics listed in this section follows the StatsD-compatible Sysdig naming convention. To see a mapping between Prometheus notation and legacy Sysdig notation, see Metrics and Label Mapping.\nOverviewEach metric in the dictionary has several pieces of metadata listed to provide greater context for how the metric can be used within Sysdig products. An example layout is displayed below:\nMetric NameMetric definition. For some metrics, the equation for how the value is determined is provided.\nMetadata\nDefinition\nMetric Type\nMetric type determines whether the metric value is a counter metric or a gauge metric. Sysdig Monitor offers two Metric types:\nCounter: The metric whose value keeps on increasing and is reliant on previous values. It helps you record how many times something has happened, for example, a user login.\nGauge: Represents a single numerical value that can arbitrarily fluctuate over time. Each value returns an instantaneous measurement, for example, CPU usage.\nValue Type\nThe type of value the metric can have. The possible values are:\nPercent (%)\nByte\nDate\nDouble\nInteger (int)\nrelativeTime\nString\nSegment By\nThe levels within the infrastructure that the metric can be segmented at:\nHost\nContainer\nProcess\nKubernetes\nMesos\nSwarm\nCloudProvider\nDefault Time Aggregation\nThe default time aggregation format for the metric.\nAvailable Time Aggregation Formats\nThe time aggregation formats the metric can be aggregated by:\nAverage (Avg)\nRate\nSum\nMinimum (Min)\nMaximum (Max)\nDefault Group Aggregation\nThe default group aggregation format for the metric.\nAvailable Group Aggregation Formats\nThe group aggregation formats the metric can be aggregated by:\nAverage (Avg)\nSum\nMinimum (Min)\nMaximum (Max)\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/"},{"id":24,"title":"Group Mappings for OKTA OIDC","content":" Log in to your Okta portal.\nFind the relevant OpenID Sysdig application from the Applications list.\nOn the Sign On tab, scroll down to OpenID Connect ID Token and select Edit.\nSpecify the following:\nGroups claim type: Set to Filter. Groups claim filter: Includes the following elements: The first field is the claim\u0026rsquo;s name, for example, \u0026ldquo;groups\u0026rdquo;. In the second field, you can filter the group information that will be passed to Sysdig by several criteria. Choose the one that works best for you. If you want to send all group information, pick Matches regex and enter .* . Select Next, then Finish.\n","url":"https://docs.sysdig.com/en/administration/group-mappings-okta_oidc_gm/"},{"id":25,"title":"Threats Overview","content":"PrerequisitesSysdig Secure (SaaS) with data sources connected:\nKubernetes: Sysdig Agent installed with Kubernetes orchestrator Cloud Accounts: Integrated Cloud accounts Hosts and Containers: Containers deployed on hosts without Kubernetes orchestration If a particular type of data source is not connected, the corresponding overview will show no data. Only teams scoped to Entire Infrastructure will see the Dashboards. Access OverviewTo access the Threats Overview page, go to Threats | Overview:\nLog into Sysdig Secure (SaaS).\nFrom the left navigation bar, select Threats \u0026gt; Overview.\nThe Overview page appears.\nChoose from the four types of Overviews:\nAll Threats: All sources. Kubernetes: Resources in Kubernetes environments Cloud: AWS, GCP, and Azure environments Host: For environments using hosts and containers without Kubernetes orchestration. Navigate Threats OverviewReview the top policies and rules with events, and drill down into the Threats feed or details to address them.\nReview the top activity associated with data such as location or users, and drill down as needed.\nThe events displayed match the permissions of the team under which you logged in.\nFilter EventsSelect top-level filters to focus on particular subset of event data, as appropriate.\nAll of the context filters apply to the widget on the page and any drill-down pages.\nBy SeverityToggle the coloured buttons on the top right of the dashboards to filter events by severity.\nThe severity levels are:\nHigh: The red H button. Medium: The orange M button. Low: The yellow L button. Info: The blue I button. By DateUse the date selector or double-click on a day to see the Event panel results filtered for just that day.\nUse the Date bar at the bottom of the page to adjust from six hours up to two weeks worth of data at a time.\nEach top trend panel reports on the behavior of events over the past 31 days.\nBy default, the trend graphs are set to 1 week.\nPage-specific filters are detailed in the panel descriptions below.\nAll Threats The Events Overview panel provides:\nMenu options to filter severity and download a PDF of the panel display.\nA summary of the data sources and their connected status.\nEvents by Severity trend graph: Change the date selection at the bottom of the page if desired, or hover over a day to see the event number summarized by severity for that day.\nTop Policies and Top Rules triggered: click on an entry to drill into the event details\nMitre Attack Report by tactic and technique\nKubernetes Filters Available Cluster Namespace Workload Cloud Filters Available Platform\nAccount/Project/Subscription (depending on AWS/GCP/Azure)\nRegion\nCloud Account User\nHostsDesigned for environments using containers without Kubernetes orchestration.\nFilters Available Host Names Containers Use CasesCompany Security UsageThe top trend panels are designed to guide Security workflows.\nThey present an overview of:\nTrends of Events in the environment over the past 31 days (in up to two-week increments) Policies and rules with most events, with up to 20 listings. Event data by date or date range Clusters, Namespaces, Workloads, Cloud account IDs, Users, hosts, and containers with the most events detected This data allow security managers to answer questions about their risk posture, such as:\nAre my event levels trending down? What is my most event-prone environment? Sample FlowsIdentify Progress through Metrics Choose the panel you want to view. Filter on segments of the infrastructure, such as specific clusters, accounts, users, hosts, or containers, as desired. Review the metrics graph to see trends. Click on days to identify the difference between them. Drill down to event feeds for further investigation. ","url":"https://docs.sysdig.com/en/sysdig-secure/threats-overview/"},{"id":26,"title":"Dashboard Panels","content":"Create a New PanelSysdig Monitor supports both form-based and PromQL-based queries.\nTo create a new panel, you can do one of the following:\nCreate a new dashboard: When you create a new dashboard, it opens to a pre-built panel. You can run a new query and build the dashboard. Use a dashboard from the library: Dashboards from the library are immutable dashboards that can\u0026rsquo;t be edited. You can copy and customize them. See Dashboard Library. Add a new panel to an existing dashboard. Create a new panel from an exploration in PromQL Query or Metrics Explorer. The maximum number of panels you can add to a dashboard is 100.\nAccess Panel Contextual Actions Duplicate a Panel: Duplicate the panel within the same dashboard. Export Data: Export panel data in CSV or JSON format. Create an Alert: Create a Prometheus Alert based on one of the panel queries. Open in PromQL Query: Open the panel queries in PromQL Query for further exploration. Copy to Dashboard: Copy the panel to a new or existing dashboard. Delete: Delete the panel from the dashboard. Configure Panel Options Unit and Y-Axes: Specify the unit of scale and display format.\nNo Data Display: Determine how to display null data on the dashboard.\nMin. Interval: Specify the minimum interval to replace $__interval. Ensure that the value is expressed as a time duration, for example: 10s, 1m, 1h, and must be between 10s and 1d.\nCompare To: Optionally, you can compare the data against historical data. This is helpful for comparing current usage to past usage when determining the conditions of your infrastructure. To compare current data with that from a time range in the past, click Enable and select the Range Offset and time unit. The supported time units are, Hour, Day, Week, and Month. When segmentation is applied, comparing time series against historical data is not supported.\nAxes: Determine scale, unit, display format, and gauge for the Y-axes.\nLegend: Determine the position of the legend in the Dashboard.\nPanel: Specify a name and add details about the panel.\nDefine AxesSysdig Monitor provides the flexibility to add two Y-axes to the graph. You can also determine whether you want to use them at all. Having the option to add an extra Y-axis helps when you decide to add an extra query.\nSpecify the following for both Y-Axis and Y-Axis Right:\nShow: Select to show the Y-Axis on the graph. Scale: Specify the scale in which you want the data to be shown on the graph. Unit: Specify the unit of scale for the incoming data. Display Format: Specify the unit of scale for the data to be displayed on the Y-Axis. Y-Max: Specify the highest value to be displayed on the Y-Axis. Consider this as the highest point in the range. You can specify the limits as numeric values. However, the type of values that you specify must match the type of values along the axis. Y-Max should be always greater than Y-Min. Y-Min: Specify the lowest value to be displayed on the Y-Axis. Consider this as the lowest point in the range. You can specify both limits or you can specify one limit and let the axes automatically calculate the other. Configure Panel SizeIndividual PanelsYou can resize individual panels by dragging their bottom right edge. Clicking Save Layout to save your changes.\nAll Panels Configuring this setting overrides all custom panel sizes.\nTo configure the size of every panel in the dashboard Click the Settings (three dots) icon for the dashboard and select Auto Layout to open the drop-down.\nMove PanelsClick and drag panels to move them into a new position.\nClick Save Layout to save your changes.\nDefine Panel Heading and DescriptionTo specify a panel title and description:\nAdd a new panel, or edit an existing panel. Underneath the metric graph, select the Panel tab. Specify a Panel Title, Description, and No Data Message as desired. Configure Panel ScopeTo configure the scope of a dashboard panel:\nClick the edit icon on a panel, or create a new panel.\nSelect the edit icon beside the scope underneath the Panel title.\nDefault Query FormatWhen you open the query editor for the first time, the Form view is used by default. You can switch to PromQL at any time, and this preference becomes your new default for all panels you create moving forward. You can also switch back to Form if needed.\nThis preference is saved per user and does not affect other users.\nCreate a Form-Based PanelEach type of visualization has different settings and the query fields are determined by the type. For example, this topic explains the steps to create a Timechart.\nOn the Dashboards module, select Create new dashboard.\nClick the Timechart icon to select a visualization type.\nFor more information on types of visualization, see Dashboard Visualization types.\nSelect a metric from the drop-down as follows:\nYou can either scroll down or type the first few letters of the metrics.\nSpecify Time Aggregation and Group Rollup.\nSpecify an appropriate segmentation\nSpecify the display text in the Display field.\n(optional) Specify the scope for the panel you are creating: You can either choose to inherit the dashboard scope as it is or apply the scope to one or all the queries.\nSpecify the unit of scale and the display format for Y-Axis: This option is currently available only for Timeseries panels.\nDetermine how to display null data on the dashboard: You can display no data as a gap, a zero value, a dotted line, or a solid line in the graph.\nOptionally, compare the data against historical data: When segmentation is applied, comparing metrics against historical data is not supported.\nCreate a PromQL Panel Do one of the following:\nClick Add Dashboard if you are creating a new dashboard. Click Add Panel if you are adding a new panel to an existing Dashboard. Click the PromQL button. The PromQL panel appears.\nEnter the query in the PromQL field:\nIn this example, the rate of memory heaps released in bytes in an interval of 5 minutes is calculated and then the total rate is calculated in each Kubernetes cluster.\nSpecify a descriptive title for the legend and a name for the time series.\nYou can specify a variable as shown in the image. The variable name is replaced with the Kubernetes cluster names in the legend.\nSpecify the unit for incoming data and how it should be displayed.\nFor example, you can specify the incoming data to be gathered in kilobytes and displayed as megabytes.\nAlso, determine the location of the Y-Axis on the graph. When you have additional queries, the flexibility to place an additional Y-axis on the graph comes in handy.\nDetermine how to display null data on the dashboard: You can display no data as a gap, a zero value, a dotted line, or a solid line in the graph.\nOptionally, compare the data against historical data. When segmentation is applied, comparing metrics against historical data is not supported.\nClick Save to save the changes.\nCreate PromQL Panels from Form QueryUse the Translate to PromQL option to quickly build a PromQL-based panel from form queries as follows:\nBuild a form query, as described in Create a Form-Based Query. This example shows you how to build a Toplist for the metric sysdig_program_cpu_cores_used, segmented by program_name and container_name. Click Translate to PromQL. Click Continue to proceed. Click Save. Apply a Dashboard Scope to a PromQL QueryUse $__scopeThe dashboard scope is automatically applied only to form-based panels. To scope a panel built from a PromQL query, you must use a scope variable within the query. The variable will take the value of the referenced scope parameter, and the PromQL panel will change accordingly.\nThe easiest way to apply the full dashboard scope to a PromQL query is to use $__scope.\navg_over_time(sysdig_container_cpu_used_percent{$__scope}) The following example shows how to use scope variables within PromQL queries when a finer control is required (for example when you want to apply a scope entry on specific metrics).\nFor more information, see Reserved Variables.\nExample: CPU Used PercentThe following query returns the CPU used percent for all the hosts, regardless of the scope configured at the dashboard level, with a mobile average depending on the time span defined.\navg_over_time(sysdig_host_cpu_used_percent[$__interval]) To scope this query, you must set up an appropriate scope variable. A key step is to provide a variable name that is referenced as part of the query.\nIn this example, hostname is used as the variable name. The host can then be referenced using $hostname as follows:\navg_over_time(sysdig_host_cpu_used_percent{host_name=$hostname}[$__interval]) Depending on the operator specified while configuring scope values, you might need to use a different operator within the query.\nScope Operator PromQL Filter Operator Example is foo is not foo = : Select labels that are exactly equal to the provided string. != : Select labels that are not equal to the provided string. sysdig_host_cpu_used_percent{host_name=$hostname} in foo,bar not in foo,bar =~: Select labels that regex-match the provided string. !~ : Select labels that do not regex-match the provided string. sysdig_host_cpu_used_percent{host_name=~$hostname} ","url":"https://docs.sysdig.com/en/sysdig-monitor/dashboard-panels/"},{"id":27,"title":"Resources","content":"Built on Sysdig’s graph database technology, this feature lets you:\nBrowse resource types organized by category, such as Compute, Storage, and Network. Search and Filter resources using dynamic, schema-aware filters. Export filtered data for analysis and reporting. This inventory uses graph-based queries to provide a streamlined way to explore resources across your environment.\nPrerequisitesRead permissions to Inventory.\nEnsure that you are assigned to a Custom Role with read permissions to Inventory.\nExporting data will also require the export permission to Inventory.\nInventory displays all resources from cloud accounts, Kubernetes data sources, and IaC Git resources connected to Sysdig, along with their findings for compliance, vulnerabilities, exposure and more. If expected results do not appear, review these prerequisites:\nNewly created Posture policies are not assigned to any zone by default. To see compliance findings from new policies, Link a Policy to a Zone. Data shown in the UI is refreshed every 24 hours when a compliance evaluation is run. Data from newly added Zones may take up to 24 hours to appear. Data in Inventory Resources is retained for 7 days. For more details, see Data Retention. Enable Inventory Resources Resources Configuration Required Cloud resources (AWS, GCP, Azure) Connect a cloud account.\nSee Connect Cloud Accounts. Yes Kubernetes resources (Users, Roles, Groups, Hosts, Workloads…) Install the Sysdig agent with Kubernetes Security Posture Management (KSPM) enabled, using --set global.kspm.deploy=true \\. See Install Kubernetes. Yes Container Images When installing the Sysdig agent for Kubernetes resources, above, also install the Runtime Image Scanner. This is included automatically when you install the agent using the Quick Start Wizard. See Install Kubernetes. Yes Standalone Hosts (Linux, Docker) Install the Posture Host Analyzer (non-Kubernetes) as a container. See Install Posture Host Analyzer No IaC Code Check the IaC Supportability Matrix.\n- Set up a Git Integration.\n- Add Git Sources.\nSee Git Integrations. No Vulnerable cloud hosts Agent-based or Agentless Vulnerability Host Scanning No Vulnerable packages running on Kubernetes Workloads Requires Risk Spotlight, which is auto-enabled from Sysdig agent v.12.15+.\nSee Risk Spotlight. No Access the Resources Page Log in to Sysdig Secure. From the left navigation, select Inventory. If it isn’t already enabled, switch to new experience using the Try the New Experience toggle in the top-right corner. Interface layoutThe Inventory page is organized into two main areas:\nLeft Navigation Panel: Displays a hierarchical tree of resource types. Main Content Area: Shows the All Resources summary or a data table for the selected resource type. Left Navigation PanelThe left navigation panel groups available resources into a searchable, hierarchical tree:\nSearch bar: Filter resource types by name or category. All Resources: A top-level view that summarizes all available resource types. Categories: Expandable groups such as Compute, Storage, and Network, listed alphabetically. Resource types: Individual entities displayed with icons (for example, EC2 instances, S3 buckets, or Kubernetes pods). Main Content AreaThe main content area updates based on your selection:\nAll Resources view: Displays a table of all available resource types. Select a row to open the corresponding resource type view. Entity detail view: Displays detailed information for a selected resource type, including: Filter bar Paginated data table Export button Side Panel DetailsFrom the entity detail view, select a row in the data table. It provides detailed information about the selected resource:\nComplete set of resource properties and values Related entities Action buttons for supported operations View Resource DetailsClick on any resource to open the Resource Details drawer. This drawer summarizes everything Sysdig knows about a resource — all of its findings, events, misconfigurations, metadata, environment information, and more.\nTo open the Resource Details drawer:\nLog in to Sysdig Secure.\nNavigate to Inventory \u0026gt; Resources.\nPerform a search or filter the resources page.\nFrom the results, select a resource.\nThe Resource Details drawer opens.\nThis drawer lets you determine the status of a resource, and answer questions, such as:\nDoes this resource have a ticket open on it? What\u0026rsquo;s the status of the ticket? Is this resource under investigation by our SOC team? Remediate Vulnerabilities with the Resource Details DrawerA possible work flow for using the Resource Details drawer to remediate a vulnerability might be:\nIn the Sysdig Secure UI, you navigate to Inventory \u0026gt; Resources. You select a resource. The Resource Details drawer opens. On the Highlights tab, you learn the resource is exposed to the internet, and has a critical vulnerability. You select the Vulnerabilities tab to learn more, and discover the critical vulnerability has a remediation. The remediation involves updating a Python package. You copy the details. You select Create Ticket to open a Jira ticket form. You paste the details of the vulnerability and the remediation, and assign it to an engineer to implement. Navigate Resource Detail Drawer TabsThe Resource Details drawer features several tabs, each covering a different category of information about the resource. You can navigate through the tabs to accomplish different goals, like creating a Jira ticket, or discovering what vulnerabilities are associated with a resource.\nHighlights TabThis tab offers a high level security overview for the selected resource, including Top Security Issues, Runtime Insights, Metadata, Resource Labels, and Assigned Zones.\nClick on any of the information displayed, such as the names of the assigned zones or the attached labels, to copy it to your clipboard.\nThe Ownership section displays the results of your configured Owner Keys and Ticket Assignee Keys mapping.\nSysdig Ownership: View the number of owners currently mapped to the resource. In this example, three owners have been identified based on the resource labels. Jira Assignee Indicates who will be automatically tasked with remediation if a security issue is detected. Check Status: If the field shows \u0026ndash;, it means no Ticket Assignee Key (such as sysdig_jira_assignee) was found in the resource metadata. Sysdig Ownership: The number of owners currently mapped to the resource. In this example, three owners have been identified based on the resource labels. Jira Assignee: Who will be automatically tasked with remediation if a security issue is detected. Check Status: If the field shows \u0026ndash;, it means no Ticket Assignee Key (such as sysdig_jira_assignee) was found in the resource metadata. To set your Owner and Ticket Assignee keys, please find the instruction in the Administration setting.\nResponse Actions TabThrough the Response Actions tab you can use Data gathering actions to perform Threat hunting activities or stop incidents detected through other means rather than Runtime Events, where you have the actions directly available.\nSysdig supports executing Response Actions, showing them on the following resource types:\nHosts: Host, Container and File actions, if Response Actions is set up on Host Shield Kubernetes workloads: Kubernetes actions compatible with the selected resource, if Response Actions is enabled on the Cluster Shield. Check out the prerequisites in the Response Actions page to set them up.\nYou will only see the actions applicable to the selected resource. From there, you\u0026rsquo;ll be able to execute them.\nOn the same resource, you can also explore the Response History, to see which actions were performed in the past and download the artifacts. By using the \u0026ldquo;View Detail\u0026rdquo; contextual action, you can see the action parameters:\nMetadata, containing the execution status and the execution timestamp Inputs, showing the action target information Configuration, having details about the setup when that action was run Response Actions TabThrough the Response Actions tab you can use Data gathering actions to perform Threat hunting activities or stop incidents detected through other means rather than Runtime Events, where you have the actions directly available.\nSysdig supports executing Response Actions, showing them on the following resource types:\nHosts: Host, Container and File actions, if Response Actions is set up on Host Shield Kubernetes workloads: Kubernetes actions compatible with the selected resource, if Response Actions is enabled on the Cluster Shield. AWS resources: Cloud Response Actions compatible with the selected resource, if Cloud Response Actions are deployed in the resource\u0026rsquo;s context. Check out the prerequisites in the Response Actions page to set them up.\nYou will only see the actions applicable to the selected resource. From there, you\u0026rsquo;ll be able to execute them.\nOn the same resource, you can also explore the Response History, to see which actions were performed in the past and download the artifacts. By using the \u0026ldquo;View Detail\u0026rdquo; contextual action, you can see the action parameters:\nMetadata, containing the execution status and the execution timestamp Inputs, showing the action target information Configuration, having details about the setup when that action was run Risks TabThe Risks tab provides a centralized view of all Risk Findings associated with a specific resource. This includes details such as:\nRisk Definition – A short description of the potential issue. Severity – Critical, High, Medium, or Low. Finding Categories – What type of issue was detected (e.g., Exposed, Vulnerability, or Configuration). Context – Additional details such as whether the issue is actively in use, or has exploit. You can filter the table by Severity to focus on the most urgent risks.\nClick on a row to open the full Risk Finding drawer, with further details and remediation guidance.\nVulnerabilities TabThe Vulnerabilities tab displays the latest runtime vulnerabilities scan results for that image or workload. This tab lists all of the CVEs identified on this specific resource, with information such as CVE ID, Severity, Context (In Use, Has Exploit, Has Fix, Exception Exists), the Exploit Prediction Scoring System (EPSS) score, the image it is found on, and the package/path.\nYou can filter the list of vulnerabilities by Name, Severity, and Context. The available Context filters are: In Use, Has Exploit, Has Fix, and whether any Exception exists.\nClick the Severity or EPSS columns to sort the list in ascending or descending order of severity or EPSS score.\nClick a CVE listing to open the full CVE details.\nHere, you can:\nLearn more about the vulnerability, such as where else it was reported, and whether a fix is available. Create a Jira ticket, if you have integrated Jira. Accept the Finding in Risk Acceptance. Runtime image scans include the Image ID. If the image was also scanned in Pipeline or Registry, then you can view it in the Pipeline or Registry Vulnerabilities interface using the 3-dot menu.\nCloud Host scans are performed against runtime packages.\nUse the Image ID to view container images as a first-class citizen in Inventory or the Runtime Vulnerabilities interface from Workloads.\nWith Risk Spotlight enabled you can see which of your vulnerable packages are currently loaded in Runtime.\nConfiguration Findings TabThis tab shows you all of your failing Compliance policies for this resource and a breakdown of how many controls failed and passed within each failing policy.\nHover over the results of a failing policy to find out how many controls passed, and how many are failing.\nUnder Failing Controls, you can see the name of the failing control to be remediated, how many policies and requirements it belongs to, and its severity. The controls are grouped by requirement within each policy.\nHover over the number of policies or requirements to find out their name, and copy them to your clipboard with a click.\nExposure TabThe Exposure tab shows you if and how a resource is exposed to the Internet.\nSelect Explore to open a diagram of the different exposure paths. Click on each of the nodes to learn more.\nUnder Exposure Findings, select a finding to learn about the exposure path in detail. You can discover the resource\u0026rsquo;s region, when it was last seen, and which platform it is on.\nYou can also pivot to examining the resource detail drawer for each resource involved in the exposure paths. For instance, if you navigate to an EC2 Instance and view its exposure path, clicking on the Internet Gateway within will overlay a new resource details panel, providing more information about that gateway.\nUnder Contributing Resources, you can find other resources in the same exposure path. Select any of the resources to open a new Resource Details drawer for them.\nSysdig supports network exposure analysis on the following resource types:\nStorage accounts and containers: Azure Storage Account and Blob Service containers Storage buckets: AWS S3 Bucket, GCP Cloud Storage Bucket, and Azure Blob Container Serverless functions: AWS Lambda Function, GCP Cloud Function, and Azure Function Compute instances and virtual machines: AWS EC2 Instance, GCP Compute Instance, and Azure VM Network resources: Classic Load Balancer (CLB), Application Load Balancer (ALB), Network Load Balancer (NLB), Security Group, Subnet, Route Table, and Internet Gateway Kubernetes workloads: GKE Deployments and Services exposed via LoadBalancer, Ingress, and Network Policy misconfigurations These detections use cloud-native constructs such as public IPs, route tables, security groups, access policies, and firewall rules to trace exposure paths. Findings include an evidence chain that explains how each resource became exposed.\nConfiguration TabThis tab shows you different “Configurations” detected for the resource, depending on the type:\nCSPM Resource: Cloud security posture management (CSPM) resource represented in JSON or YAML format. Example: A k8s Deployment Yaml file, or the EC2 Instance description in JSON format. Host resource: List of host-configurations detected at the Linux-Host, or Containers Example: Docker iptables config, or /etc/shadow “password expiration”. IaC Resource: Resources that are read from a Source-Code-Repo show here that actual \u0026ldquo;Manifest\u0026rdquo; Yaml/Json that was detected as an Infra-As-Code file Example: A Json representation of the Terraform HCL configuration block for a EC2 Instance. Images: For Images we will show an empty screen. Packages TabWhere a resource has packages, this tab displays all the packages Sysdig has identified on the resource, and their paths. You can see how many vulnerabilities each package contains, and context about the vulnerabilities (In Use, Has Exploit, Has Fix).\nSelect any Package/Path to see more details about it, such as its source, and package type. You can also check whether any update or patch is necessary.\nIdentity Findings TabThe Identity Findings tab displays identity-related risks and deviations from best practices associated with the selected IAM resource. Findings are listed in a table with columns for Finding Name and Severity, helping you quickly understand the nature and criticality of any detected issues.\nThis tab highlights problems such as risky permissions, misconfigurations, or usage anomalies. Select any Finding to open a panel with a detailed description and suggested remediationss to help you resolve the issue.\nUse this tab to:\nAssess the security posture of IAM entities such as users, roles, or service accounts. Prioritize remediation actions based on severity. Track common identity hygiene issues such as access key usage or inactivity. Connected Resources TabThe Connected Resources tab shows relationships between the selected IAM entity and other IAM resources. This includes users, groups, roles, or service identities that are connected to the current identity, either directly or through shared permissions or policies.\nUse this tab to:\nTrack identity sprawl and assess lateral movement risk. Investigate which other identities might be affected by the same policies or privileges. Pivot to additional identity resources for further inspection. Data Findings TabThe Data Findings tab displays information about any sensitive content that has been discovered on a resource. The findings are at the data category level, with Personal, Health, and Financial supported. Click a row with a finding to open the corresponding Data Finding drawer, which shows a summary of the affected resource, a description of the category, and a list of the specific data classes (such as name, SSN, or credit card number) and an example of where in the resource they were seen.\nWork with IaC ResourcesIf you have configured IaC scanning, you can view the resources supported by the Git-integrated scanner in the Inventory, such as YAML, Terraform, and Helm charts. The view of each code resource includes:\nresource metadata configuration details posture violations that can be remediated with automated workflows. For more information, see IaC Support.\nInventory currently supports AWS (EC2 Instance) and GCP (Compute Instance) Hosts. Azure VMs are out of scope.\nCommon WorkflowsExplore Resource TypesThe goal is to browse available resources and understand your infrastructure composition.\nGo to Inventory \u0026gt; Resources with All Resources selected. Review the table showing all available resource types. In the left navigation, expand a category you want more information on (for example, Compute). Select a specific resource type (for example, AWS EC2 Instance). View the list of resources for the selected type. Filter resourcesThe goal is to find resources that match specific criteria.\nSelect a resource type from the left navigation. Wait for the initial data load to complete. In the filter bar, select + Add filter. Choose a field (for example, Name). Select an operator (for example, In). Enter one or more values (for example, production-server). Add additional filters as needed. Review the filtered results in the table. Export DataThe goal is to download filtered results for external analysis.\nApply the required filters and sorting. Select Export from the toolbar. Wait while the export is generated. Download the report when the export is complete. Use the Inventory APIQuery the Secure API to get a list of multiple inventory resources or retrieve a single one.\nFor details, see the Inventory entries in the API documentation.\nFor API doc links for additional regions or steps to access them from within the Sysdig Secure UI, see the Developer Tools overview.\nAt this time, only resource metadata and posture data are in scope. Vulnerabilities, package, and exposure data are currently not available.\nInventory Data DictionaryYou can construct searches/filters by attribute name in the Inventory unified filter.\nFilter Operators is (=) is not (!=) in (in) not in (!in) yes (Y)\nno (N) startsWith (^) contains (%) (wildcards not supported)\nexists/not exists Attribute Name Attribute Definition Account The container for your AWS resources. You create and manage your AWS resources in an AWS account. If an account has an alias, use the alias to search for the account in Inventory instead of the Account ID. Architecture The CPU architecture for which your container image is built ARN The unique identifier of your AWS cloud resource Attribute* The attributes defined within the configuration of your Kubernetes host or cluster\n* Only filtered from within a Kubernetes host or cluster resource configuration. Base OS Base operating system of your container image Category Classification or grouping of your resources and services based on their functionalities, characteristics, and use cases. Cluster Name of your Kubernetes cluster Containers The container name(s) of your workload(s) Created Date your container image was created CVSS The CVSS score (0.0 - 10.0) of the CVE External DNS The DNS name of your Kubernetes host\u0026rsquo;s node that will resolve into an address with external address characteristics Git Integration Name of the Git integration. See IaC Scanning/Git Integrations Git Repository Name of the repository, example: IaC_Demo Has Exploit If the vulnerability has a known exploit Has Fix If the vulnerability has a known fix Host Image ID The unique identifier associated with a custom or public image used to create and launch your virtual machine instances. Examples:\nAWS: ImageID (ex: ami-0123456789abcdef0)\nGCP: sourceImage or sourceDisk (ex: projects/canonical-cloud/global/images/family/ubuntu-2004-lts) Host OS Operating System of your Kubernetes host Image Digest Hash value computed from the content of your container image to verify its integrity (ex: sha256:0278c0\u0026hellip;) Image ID Unique identifier assigned to your container image (ex: sha256:062ab3\u0026hellip;) Image OS The operating system environment encapsulated within your container image Image Pullstrings The path where your container image was pulled from in the registry Image Registry Storage system where your container is hosted and managed Image Tags Labels or identifiers associated with your container images (ex: latest, v1.4) In Use If the package is running Kubernetes Distribution GKE, EKS, AKS, Rancher, Vanilla, OpenShift v4, IKS, MKE Location Path to the file or module directory in the repository (IaC resources):\n- Kubernetes manifest: path to the YAML file - Helm charts: Helm chart folder - Kustomize: path to the manifests folder (folder containing the base kustomization.yaml file) - Terraform: path to the .tf module folder Namespace Kubernetes cluster namespace Node Type Master or Worker node of your Kubernetes host Organization Root node of your managed cloud resources hierarchy Origin* The origin of your Kubernetes host\u0026rsquo;s or your cluster\u0026rsquo;s configuration (Docker, Linux, Kubernetes, etc.)\n* Only filtered from within a Kubernetes host’s resource configuration.. OS Image Name and version of your host\u0026rsquo;s Operating System Package The name of a package Package Path The file system location or directory path where your software package is stored or installed Package Type The format or structure used to package and distribute your software (ex: Java, OS) Platform AWS, Azure, GCP, Kubernetes, or Linux Posture Accepted Risk Whether or not a risk has been accepted for a resource\u0026rsquo;s control Posture Applied Policy Name(s) of the policies applied to the resource Posture Failed Control Severity High, medium, or low Posture Failed Control Name(s) of the failed control(s) applied to the resource Posture Failed Policy Name(s) of the failed policy(ies) applied to the resource Posture Failed Requirement Name(s) of the failed requirement(s) applied to the resource Posture Passed Policy Name of the passed policy applied to the resource Project The container for your Google Cloud resources. You create and manage your GCP resources in a GCP project Exposed If the resource is publicly or ingress exposed Region Region of the world where your managed cloud resource is deployed (such as us-east, eu-west, asia-northeast) Resource ID The unique identifier of your Google or Azure cloud resource Resource Labels Labels are key/value pairs, such as team:research, that you have applied to your resource from Kubernetes or Managed Cloud platforms (AWS, GCP, Azure). For Kubernetes, the Labels field includes all the labels for the resource, including nested labels. For example, a search on a label that exists on a container will return the workload that contains the container. Resource Name Name of your resource Resource Origin - Code: IaC resources from Git integrations - Deployed: Runtime resources Resource Type For Kubernetes, can be a Workload, Service Account, Role, Cluster Role, Host, User, Cluster, or Group. For managed clouds, it can be a Resource (S3 bucket, Deployment, DaemonSet\u0026hellip;) or an Identity (Access Key, User, Policy\u0026hellip;) Source Type Possible values for IaC source: YAML, Helm, Kustomize, Terraform Subscription The container for your Azure resources. You create and manage your Azure resources in an Azure subscription Version/OpenShift Cluster Version The version of your OpenShift cluster Vulnerability The CVE identified on your vulnerable package Vulnerability Severity The severity of the CVE Zones A business group of resources, defined by a collection of scopes of various resource types (for example: “Dev” - all my development resources) Technical BackgroundSysQL Query EngineGraph Inventory builds queries using SysQL. This graph-based query model enables efficient traversal of resource relationships and supports complex filtering and correlation scenarios across connected entities. The following example illustrates the logical structure of a SysQL query:\nMATCH {entity} WHERE {filters} RETURN DISTINCT {entity} ORDER BY {sort} LIMIT {limit} OFFSET {offset} Entity schemaEach resource type defines a schema that specifies:\nAvailable fields for filtering. Supported data types (text, number, date, boolean, severity). Supported operators per data type. Display properties such as icons and labels. TroubleshootingNo Data Displayed Possible Causes Recommended Action No graph data sources are connected Select + Connect Environment to configure a data source. The selected entity has no resources in your environment Try a different entity type or category. Filters are too restrictive Remove filters by selecting Reset to basic fields. Query Timeout Symptom Recommended Action An error message indicates that the query exceeded the time limit. Add more specific filters to narrow the result set. Remove complex filters that require expensive graph traversalsContact your administrator if timeouts persist. Sort Limitation ErrorSymptomA CantSortState error appears when you select a column header.\nCauseSome entity fields do not support server-side sorting.\nRecommended ActionSort by a different column, or view results without sorting\nLarge Result Set WarningSymptomA TooLargeResultSetState warning appears with a recommendation to filter results.\nRecommended ActionAdd filters to reduce the number of matching resources before viewing results.\n","url":"https://docs.sysdig.com/en/sysdig-secure/inventory-resources/"},{"id":28,"title":"Supply Chain Policies","content":"OverviewSupply Chain Policies in Sysdig Secure provide security controls that help you validate the trust and integrity of software artifacts before they are deployed into your Kubernetes or OpenShift environments.\nThese policies are designed to help you verify that artifacts such as container images, SBOMs, and other workload components:\nOriginate from trusted build systems or registries. Have not been modified after publication. Comply with organizational and regulatory requirements for software provenance and integrity. Sysdig’s Supply Chain Policies form the foundation for enforcing your software supply chain security posture.\nPrerequisitesKubernetes WorkloadsBefore enabling Supply Chain Policies, ensure that the Sysdig Shield chart is installed on your Kubernetes clusters.\nSee Install Shield on Kubernetes for deployment instructions. Verify that the supply_chain feature is enabled in your Cluster Shield configuration. features: supply_chain: enabled: true Goals Objective Description Integrity Validate that images and artifacts have not been altered from their intended state. Authenticity Ensure that artifacts are signed by trusted publishers, CI/CD systems, or registries. Compliance Enforce adherence to enterprise and regulatory requirements for software provenance and chain-of-custody. Supported Policy TypesAt present, the following policy type is supported:\nImage Signature ValidationThe Image Signature Validation policy enforces that only container images with valid digital signatures are admitted into your Kubernetes clusters. Signatures can be verified through:\nPublic Key validation (using PEM-encoded public keys). OIDC Provider validation (e.g., GitHub Actions, Red Hat Trusted Artifact Signer, Google, AWS STS, Microsoft Entra ID, or any compatible Sigstore implementation). This policy operates at the Admission Control stage via the Sysdig Admission Controller. It prevents unsigned or tampered images from being deployed, ensuring supply chain integrity before workloads are scheduled to run.\nExample Use Cases Require that all production workloads use images signed by your organization’s CI/CD pipelines. Prevent deployment of unsigned or third-party images. Enforce that only artifacts signed by approved OIDC providers are admitted into the cluster. Establish a baseline for software provenance and compliance across Kubernetes workloads. ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/policies/supply_chain/"},{"id":29,"title":"Sysdig Secure","content":"Key FeaturesSysdig Secure protects modern, multi-cloud and containerized environments with the following core features:\nSysdig SageSysdig Sage is an AI-powered security assistant built into Sysdig Secure, designed to help teams work smarter and faster. Sysdig Sage accelerates search, vulnerability management, threat investigation and response by providing precise security insights in context, and helping you navigate the user interface to better visualize and respond to threats.\nCloud-Native Application Protection Platform (CNAPP) Sysdig Secure is a Cloud-Native Application Protection (CNAPP) powered by runtime insights. It provides: Risk prioritization to help you remediate on the most critical security issues. Real-time threat detection built on open-source Falco rules. AI-powered security assistance with Sysdig Sage across Search, Vulnerability Management, and Detection and Response workflows. A unified view of all cloud risks and threats with Cloud Attack Graph. Threat Detection Sysdig Secure continuously monitors running workloads (such as containers and Kubernetes clusters) for suspicious activities, delivering Runtime Threat Detection and Response. Sysdig Secure uses Falco, the open-source threat detection engine, to trigger real-time alerts based on predefined or custom security policies. This enables you to prioritize active risks and stop threats in real time.\nActivity Audit and Forensics - provides a detailed audit trail of user and system activity. In case of an incident, it can reconstruct events to provide deep forensic insights, including which files were accessed or modified, what commands were run, and who performed specific actions.\nVulnerability Management (VM) Vulnerability Management - scans images and running containers for vulnerabilities and provides prioritized reports, enabling teams to focus on fixing the most critical security issues. It integrates with CI/CD pipelines to ensure images are scanned before they are deployed, preventing vulnerable components from being pushed to production.\nImage Scanning - scans container images for known vulnerabilities in the package dependencies (e.g., OS packages, libraries). It integrates with registries and CI/CD workflows to automate image scanning throughout the development lifecycle.\nIntegrated DevSecOps Workflow - integrates security into the DevOps pipeline, enabling organizations to shift left on security. By providing real-time feedback to developers, teams can quickly fix issues before they affect production systems.\nKubernetes and Cloud Security Posture Management Compliance Enforcement - helps organizations meet various compliance requirements (such as PCI-DSS, GDPR, NIST) by automating configuration checks and providing audit-ready reports. It monitors for compliance at both the infrastructure and application levels.\nKubernetes and Cloud Security Posture Management (CSPM) - offers deep visibility into Kubernetes clusters, allowing teams to monitor configurations, enforce security policies, and detect misconfigurations or violations of best practices. It also supports multi-cloud environments by ensuring compliance and security across AWS, Azure, and Google Cloud platforms.\nSecurity Policy Management - enables you to define and enforce custom security policies. These policies can be applied to containers, hosts, and orchestrators (Kubernetes). You can also set up runtime policies to detect and respond to unauthorized activities.\nActivity Audit and Forensics - provides a detailed audit trail of user and system activity. In case of an incident, it can reconstruct events to provide deep forensic insights, including which files were accessed or modified, what commands were run, and who performed specific actions.\nQuick StartHere are the steps to get started with Sysdig Secure:\nConnect Cloud Accounts Install Sysdig Shield and components, based on your environment Connect peripherals such as: Sysdig Vulnerability CLI Scanner Sysdig Registry Scanner Rapid Response Warranty DisclaimerCustomer acknowledges and agrees that it is impossible under any current available technology for any security and/or monitoring software to identify one hundred percent (100%) of cloud threats and risks, vulnerabilities, Errors, malicious software, or an attacker’s behavior (collectively, the “Threats”). Sysdig Secure and Monitor (the “Services”) rely upon threat feeds, behavioral analysis, machine learning, and other techniques that are subject to the limitations set forth in this Documentation. However, these techniques may not be enough to discover all Threats. Further, Customer acknowledges and understands that the Sysdig Services may incorrectly identify Threats, resulting in a false positive. Lastly, Customer acknowledges and understands that by procuring Sysdig’s Services, the Services are just one tool in Customer’s overall cloud strategy and do not represent a shift in responsibility for Customer’s business. Customer remains responsible for ensuring that it has appropriate data security measures in place.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/"},{"id":30,"title":"Threat Detection Policies","content":"Threat Detection Runtime Policies provide granular control over runtime behavior by defining rules and configurations. Policies specify where to apply rules and how to respond to security violations. Use policies to monitor clusters, hosts, or user-defined tags and take actions. For example, alert Slack channels, trigger webhooks, or prevent malware from executing.\nReview the Runtime Policies ListTo review the Runtimes Policies list:\nLog in to Sysdig Secure.\nSelect Policies \u0026gt; Runtime Policies.\nHere you can see the default policies loaded into Sysdig Secure, as well as any custom policies you have created.\nSee at a Glance Collapse or expand policy groups: Policies are grouped by policy type. Policies are assigned High, Medium, Low, or Info level severity, which can be edited. Enabled/Disabled: Viewed by toggle position. Managed Type: Filter by policy management type; Managed Policy, Managed Ruleset or Custom Policy. See Manage Threat Detection Policies for details. Select policy type: Filter by policy type, such as Linux Workload. Policy Summary: Includes Update status, the number of Rules, assigned Actions to take on affected containers (Stop | Pause | Notify), and Capture details, if any. Policy Status: The Default policies are managed policies, Ruleset are managed ruleset policies, and Custom policies may be user-designed from scratch or converted from default policies with changes to their rules. Last Updated indicates when a policy was last updated. When you create a policy in the UI, you define the severity as, Info, Low, Medium, or High. From an API perspective these are mapped to a number from 0 to 7. When an event is triggered, the corresponding number to the severity is displayed:\nNumber Severity 0 High (UI Default) 1 High 2 High 3 High 4 Medium (UI Default) 5 Low (UI Default) 6 Info 7 Info (UI Default) Take ActionFrom this page, you can also:\nSelect a policy to open the details panel, where you can review policy details, and potentially Edit them.\nSearch and Filter policies by name, severity level, type, or whether captures are enabled.\nEnable or Disable a policy using the toggle.\nCreate a new policy by selecting +Add Policy.\nView Recent ChangesWhen rules are changed, either by the Sysdig Threat Detection team or by users, an Updated badge is displayed next to relevant policies for seven days.\nThere are several ways to view recent changes to a rule.\nFrom Runtime Policies Go to Polices \u0026gt; Runtime Policies and scroll down to find any Updated badges.\nSelect the policy to open the detail panel and scroll to find the updated rule.\nSelect the +/- rule diff icon to compare the two versions of the rule.\nFrom the Policy Edit Page Go to Policies \u0026gt; Runtime Policies and select a policy.\nClick the Edit (pencil) icon to open the Policy Edit page.\nSelect a rule from the page.\nIf the rule has been updated, you can use the +/- icon next to the rule.\nIf the change has happened in the past seven days, there will also be an icon available next to the Updated badge on the main Policy Edit page.\nSee View Recent Changes to a Rule from the Rules Library.\nReport Policy Actions in Kubernetes EventsSome Threat Detection Runtime policies, such as Linux Workload policies, allow you to take actions on containers. When you perform a container Stop, Pause, or Kill action, Sysdig includes a message in Kubernetes events to explain that Sysdig acted on the container due to the given rule. You will see this information when you kubectl events in your terminal, without requiring login to the Sysdig Secure UI.\nEnablement\nThis feature is included with agent v.12.18+. If you have deployed agent 12.18+ using Helm, the feature and its associated permissions are enabled by default. If you deploy agents manually, you must set Kubernetes role permissions. See Agent Configuration Library for details.\nUnderstand Threat Detection RulesRules are the fundamental building blocks you will use to compose your security policies. Rules discover types of activity an enterprise would want to detect in its environment.\nRules can be expressed in two formats:\nFalco rules syntax, which can be complex and layered. All the default rules delivered by Sysdig are Falco rules, and users can also create their own Falco rules.\nList-matching rules syntax, which is simply a list against which a match/not match condition is applied. All these rules are user-defined. They are grouped into five types: Container Image, File System, Network, Process, and Syscall.\nUsing Falco within Sysdig SecureWhat is FalcoFalco is an open-source intrusion detection and activity monitoring project. Designed by Sysdig, the project has been donated to the Cloud Native Computing Foundation, where it continues to be developed and enhanced by the community. Sysdig Secure incorporates the Falco Rules Engine as part of its Policy and Compliance modules.\nWithin the context of Sysdig Secure, most users will interact with Falco primarily through writing or customizing the rules deployed in the policies for their environment.\nFalco rules consist of a condition under which an alert should be generated and an output string to send with the alert.\nConditions Falco rules use the Sysdig filtering syntax.\n(Note that much of the rest of the Falco documentation describes installing and using it as a free-standing tool, which is not applicable to most Sysdig Secure users.)\nRule conditions are typically made up of macros and lists.\nMacros are simply rule condition snippets that can be re-used inside rules and other macros, providing a way to factor out and name common patterns.\nLists are (surprise!) lists of items that can be included in rules, macros, or other lists. Unlike rules/macros, they can not be parsed as Sysdig filtering expressions.\nBehind the scenes, the falco_rules.yamlfile contains the raw code for all the Falco rules in the environment, including Falco macros and lists.\nAnatomy of a Falco RuleAll Falco rules include the following base parameters:\nrule name: default or user-assigned\ncondition: the command-line collection of fields and arguments used to create the rule\noutput\nsource\ndescription\ntags: for searching and sorting\npriority\nSelect a rule from Rules \u0026gt; Rules Library to see or edit its underlying structure. The same structure applies when creating a new Falco rule and adding it to the library.\nFalco rules with the source k8s_audit need Kubernetes Audit logging enabled for conditions to be met.\nAbout Falco MacrosMany of the Falco rules in the Rules Library contain Falco macros in their condition code.\nYou can browse the Falco Macros list, examine a macro\u0026rsquo;s underlying code, or create your own macro. The default Falco rule set defines a number of macros that make it easier to start writing rules. These macros provide shortcuts for a number of common scenarios and can be used in any user-defined rule sets.\nAbout Falco ListsDefault Falco lists are added to improve the user experience around writing custom rules for the environment.\nFor example, the list allow.inbound.source.domains can be customized and easily referenced within any rule.\nAbout Rule ExceptionsTo reduce false positives, Sysdig uses Falco exceptions in many of the default rules, including adding exceptions to community rules. Rule exceptions are used in the auto-tuning and rules exception features as part of Runtime Policy Tuning.\nTo understand how exceptions are managed: there are the exception definitions, used to define a set of fields and comparisons (comps) that the values (which are optional) can use to create those exceptions\nAvailable FieldsSysdig and the Sysdig Agent enrich events with details that are not available to Falco. The most common classes of fields available are:\nLinux Workload/syscall Rules proc user group container See below for container fields that are not available from Falco fd To understand each field in those classes, you can find them here. The Kubernetes fields are not available in the Falco rules. This is due to performance improvements that could affect the Kubernetes API server when collecting those values from Falco. In the event details you may see this information enriched from other parts of Sysdig, with values such as kubernetes.deployment.name.\nKubernetes Audit/k8s_audit RulesAll ka fields are available. You can find a comprehensive list here.\nHowever as noted above, Sysdig enriches some additional metadata in the event details. An event may have the field kubernetes.cluster.name, however that is not available in the rule or rule exceptions.\nCommon fields that are not available agent.tag.* kubernetes.* host.* container.label.* container.name.repo instead use container.image.repository which outputs sysdig/agent container.image which outputs sysdig/agent:latest (On-Prem Only) Upgrading Falco Rules with the Rules InstallerSysdig Secure SaaS is always using the most up-to-date Falco rules set.\nSysdig Secure On-Prem accounts should upgrade their Falco rules set regularly.\nThis can be achieved through our Rules Installer.\nUnderstanding List-Matching Rules List Matching Policies and rules are being retired on February 28, 2026. Read more in the deprecation notice.\nList-matching rules (formerly known as \u0026ldquo;fast\u0026rdquo; rules) are used for matching against lists of items (when matchItems=true) or matching everything other than lists of items (when matchItems=false). They provide for simple detections of processes, network connections and other operations. For example:\nIf this process is detected, trigger an action when this rule is in a policy (such as send notification).\nOr\nIf a network connection on x port is detected, trigger an action when this rule is in a policy (such as send notification)\nUnlike Falco rules, the list-matching rule types do not permit complex rule combinations, such as \u0026ldquo;If a connection on x port from y IP address is detected\u0026hellip;\u0026rdquo;\nThe five list-matching Rule Types are described below.\nContainer RulesThese rules are used to notify if a specific image name is running in an environment. The rule is evaluated when the container is started. The items in the list are image pattern names, which have the syntax \u0026lt;host.name\u0026gt;:\u0026lt;port\u0026gt;/\u0026lt;name\u0026gt;/\u0026lt;name2\u0026gt;:\u0026lt;tag\u0026gt;@\u0026lt;digest\u0026gt;.\nOnly \u0026lt;name2\u0026gt;is required; everything else is optional and inferred from the name.\nSee also: How Matching Works: Container Example and Create a List-Matching Rule: Container Type Example.\nFile System RulesThese rules are used to notify if there is write activity to a specific directory/file. The rule is evaluated when a file is opened. The items in the list are path prefixes.\nFor example: /one/two/three would match a path /one/two/three, /one/two/three/four, but not /one/two/three-four.\nNetwork RulesThese rules are used to:\nDetect attempts to listen for inbound connections on ports on a specific list\nGenerally identify any inbound or outbound connection attempts\nNote that the current Sysdig UI talks about \u0026ldquo;Allowing\u0026rdquo; or \u0026ldquo;Denying\u0026rdquo; connections with network rules, but this can introduce some confusion.\nFor both Inbound and Outbound connections:\nAllow means do nothing\nDeny means match any attempt to make an inbound or outbound a connection\nYou would still need to add the rule to a policy and attach actions to respond to a connection attempt by stopping/pausing/killing the container where the connection occurred. See also: Understanding How Policy Actions Are Triggered.\nProcess RulesThese rules are used to detect if a specific process, such as SSH, is running in a particular area of the environment.\nThe rule is evaluated when a process is launched. The items in the list are process names, subject to the 16-character limit enforced by the Linux kernel. (See also: Process Name Length information.)\nSyscall Rules The syscall rule type is almost never deployed in user-created policies; the definitions below are for information only.\nThese rules are used (internally) to:\nNotify if a specific syscall happens in a list\nNotify if a syscall outside this trusted list happens in the environment\nThe rule is evaluated on syscalls that create inbound (accept, recvfrom, recvmsg, listen) and/or outbound (connect, sendto, sendmsg) connections. The items in the list are port numbers.\nHow Matching Works: Container ExampleA Container Image consists of the following components:\n\u0026lt;registry host\u0026gt;:\u0026lt;registry port\u0026gt;/\u0026lt;image\u0026gt;:\u0026lt;tag\u0026gt;@\u0026lt;digest\u0026gt;.\nNote that \u0026lt;image\u0026gt; might consist of multiple path components such as \u0026lt;project\u0026gt;/\u0026lt;image\u0026gt; or \u0026lt;project\u0026gt;/\u0026lt;subproject\u0026gt;/\u0026lt;image\u0026gt;.\nComplete example: docker.io:1234/sysdig/agent:1.0@sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709\nWhere:\n\u0026lt;registry host\u0026gt; = docker.io\n\u0026lt;registry port\u0026gt; = 1234\n\u0026lt;image\u0026gt; = sysdig/agent\n\u0026lt;tag\u0026gt; = 1.0\n\u0026lt;digest\u0026gt; = sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709\nEach item in the containers list is first broken into the above components, using the following rules:\nIf the string ends in /, it is interpreted as a registry host and optional registry port, with no image/tag/digestprovided.\nOtherwise, it is interpreted as an image. The registry host and port may precede the image and are optional, and the tag and digest may follow the image, and are optional.\nOnce the item has been broken into components, they are considered a prefix match against candidate image names.\nExamples:\ndocker.io:1234/sysdig/agent:1.0 @sha256:da39a3ee5e6b4b0d3255bfef95601890afd80709: must match all components exactly\ndocker.io:1234/sysdig/agent:1.0:must match the registry host, port, image and tag, with any digest\ndocker.io:1234/sysdig/agent:must match the registry host, port and image, with any tag or digest\nsysdig/agent:must match the image, with any tag or digest. This would not match an image docker.io:1234/sysdig/agent because the image provides additional information not available in the match expression.\ndocker.io:1234/: matches all images for that registry host and port\ndocker.io/: matches all images for that registry host\nGetting Started Manage Policies\nManage Rules\nThere are optional tools to help automate the creation of policies. See Network Security Policy Tool for information on authoring and fine-tuning Kubernetes network policies.\n","url":"https://docs.sysdig.com/en/sysdig-secure/threat-detection-policies/"},{"id":31,"title":"Threat Management","content":"Prerequisites Sysdig SaaS. Access ThreatsTo access the Threats page:\nLog in to Sysdig Secure.\nSelect Detection \u0026amp; Response \u0026gt; Threats.\nThe Threats page appears.\nKey FeaturesContext-Driven CorrelationSysdig Threat Management intelligently correlates events based on shared context, such as Kubernetes workloads, cloud identities, or attack phases. This consolidation enables teams to quickly understand the scope and criticality of threats.\nSysdig Sage: AI-Powered InsightsThreat Management leverages Sysdig Sage™, a generative AI security analyst. It enriches threats with easy-to-understand summaries and high-fidelity context, providing situational awareness for faster decision-making.\nTo benefit from AI enrichment, Enable Sysdig Sage.\nStreamlined WorkflowsAnalysts can manage alerts more efficiently with inline management features like status changes, rule tuning, enhanced investigation, and response actions, all within a single interface.\nConceptsSignal CorrelationSysdig groups related security signals based on:\nEntity Matching: Correlation by shared resources (containers, cloud users, hosts). Time Proximity: Consecutive signals occurring within a time window are grouped. Event Severity: High-severity detections always trigger a Threat, even from a single event. All the other detections are included in the Threat and provide context but do not independently trigger Threats. Grouping BehaviorThe same behavior across multiple workloads is grouped together.\nRecurring behavior within the same workload after an initial Threat will be appended to the existing group.\nThreat StatusAll Threats have a Status. The default status is Open, which remains until you manually mark the Threat as under investigation or archived with a provided reason. Use statuses to track threats. You can also filter by statuses to find particular threats.\nTo change the Status of a Threat:\nLog in to Sysdig Secure.\nSelect Detection \u0026amp; Response \u0026gt; Threats.\nThe Threats page appears.\nIdentify a group or individual threat whose status you want to change.\nSelect the three-dot icon on the right-hand side of a listing.\nSelect Change Status.\nThe Change Status modal appears.\nFrom the New Status drop-down, choose from:\nOpen In Investigation Archived If you select Archived, select a Reason from the drop-down: Resolved / Mitigated Escalated Expected Behavior False Positive Other Select Change Status to save your changes. Alternatively, you can change the status from the Threats Detail panel:\nLog in to Sysdig Secure.\nSelect Detection \u0026amp; Response \u0026gt; Threats.\nSelect a grouping.\nRecorded threats appear.\nSelect a threat.\nThe Threats Detail panel appears.\nFrom the Status drop-down, select:\nOpen In Investigation Archived If you selected Archived, select a reason: Resolved / Mitigated Escalated Expected Behavior False Positive Other Your changes are automatically saved.\nFilter ThreatsYou can filter the Threats page in different ways to find specific threats. For example, you can filter to only see threats from a particular cloud environment and a particular cloud user.\nYou can filter by:\nStatus Cluster in Workload in Cloud User in High Severity Only Select + Add to add additional filters, such as:\nCloud Provider Cloud User Cluster Namespace Source Workload Select Reset to return to the default filter.\nThreats Detail PanelSelect a threat to open the Threats Detail panel.\nThe name given to threats is provided by Sysdig Sage AI. Sysdig Sage looks at all the events and activity Sysdig has recorded and summarizes the behavior in simple English.\nSelect All Events to view the Events Feed, filtered to the scope of the selected threat.\nHighlightsThe panel opens on the Highlights tab. Here, you can get a quick overview of the threat.\nAffected Resource Summary tells you where the threat was recorded. For example, in a certain cluster, namespace, workload or container.\nUnder Threats Summary, you can read a description of what behavior or activity Sysdig has flagged. This clarifies the impact of activity, and saves you time from needing to review individual events.\nThe Highlights tab also presents metadata related to activity related to:\nUser identity Container image and name Cloud environment Files and directory reads/writes Processes RulesIn the Rules tab, you can see the additional rules.\nSelect the three-dot icon on a rule to:\nView Rule View Events Tune Rule: Open the exceptions editor, where you can see suggestions on how to tune the rule. EventsIn the Events tab, you can look at the individual events.\nImpacted ResourcesIn the Impacted Resources tab, you can see the impacted resources.\nActivity AuditIn the Activity Audit tab, you can look at the Activity Audit scoped to the affected resource.\nSelect View All to go to the Activity Audit page and view activity before or after the time frame of the threat.\nProcessesIn the Processes tab, you can view the processes, and explore the Process Tree.\nGraph SearchThreats are ingested into Sysdig’s graph database. You can leverage Search to correlate Threats with other Findings such as vulnerabilities or misconfigurations.\nExample: List Open Threats in Kubernetes Cluster “my-cluster”MATCH Threat GENERATED_BY KubeWorkload WHERE Threat.status IN [\u0026#39;open\u0026#39;] AND KubeWorkload.clusterName IN [\u0026#39;my-cluster\u0026#39;] RETURN DISTINCT Threat, KubeWorkload LIMIT 50; Example: List ingress-NGINX Instances Vulnerable to IngressNightmare and have been ExploitedThis is indicated by the Falco rule “Potential IngressNightmare Vulnerability Exploitation”.\nMATCH KubeWorkload AFFECTED_BY Vulnerability OVER Container, Image, ContainerImageV2 WHERE KubeWorkload.isExposed = true AND Vulnerability.name IN [\u0026#39;CVE-2025-1974\u0026#39;] MATCH KubeWorkload GENERATES Threat WHERE Threat.status IN [\u0026#39;open\u0026#39;] AND Threat.rules IN [\u0026#39;Potential IngressNightmare Vulnerability Exploitation\u0026#39;] RETURN DISTINCT KubeWorkload, Vulnerability, Threat LIMIT 50; Automations for ThreatsYou can use Automations to trigger actions on Threats, such as receiving notifications.\nThe available filters that can be leveraged include:\nThe resource: Workload, user, cloud environment. Specific rules. Severity: Whether the Threat contains a high severity event or not. Threat ExclusionYou can create exclusion rules to prevent the generation of threats you don\u0026rsquo;t find relevant.\nTo create an exclusion from an occurrence of a Threat:\nLog in to Sysdig Secure.\nNavigate to Detection \u0026amp; Response \u0026gt; Threats.\nIdentify a threat you wish to make an exclusion rule for.\nSelect the three-dot menu icon.\nSelect Create Exclusion Rule.\nThe Exclusion Rule modal appears.\nEnter a Name, review the Criteria, and edit as you wish. For details, see Define Criteria.\nSelect Save.\nCreated exclusions appear on the Threat Exclusion page. Here, you can enable or disable them with the toggle, and review their details, such as the creation date.\nFor more details, see Threat Exclusion.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/threats/threat-management/"},{"id":32,"title":"Timechart","content":"For information on configuring a chart, see Create a New Panel.\nTime aggregation: For example, the average value of sysdig_host_cpu_used_percent metric is computed for each entity over 1 hour at 1-minute intervals.\nGroup Rollup: For each host_hostName the values from time aggregation are averaged over the scope and the top 10 segments are shown on the chart.\nTypes of Timecharts Type Preview Line Stacked Area Stacked Bars Timechart look and feel can be configured under Display settings when configuring a panel.\nWhen to Use Type Use case Line When quickly identifying outlier segments is important.\nWhen plotting a single metric over time. Stacked Area When an aggregate view of segments is needed. Stacked Bars When metrics are sometimes reporting zero. Time SelectionThe amount and granularity of data visualized in the timechart is dependent on the time selection within the Dashboard. You can change the time selection with the time scope bar at the bottom of the UI.\nGranularityTimchart panels dynamically choose the appropriate granularity in order to balance maximum resolution with acceptable performance. For a 10-second granular metric such as sysdig_container_cpu_used_percent, the below table can be used as a reference.\nTime Interval Sampling used Up to and including 2 hours. 10 seconds Greater than 2h, up to and including 12 hours. 1 minute Greater than 12 hours, up to and including 5 days. 10 minutes Greater than 5 days, up to and including 30 days. 1 hour Greater than 30 days. 1 day Timecharts are optimised to refresh as soon as new data is available. As a consequence, if a dashboard contains timechart as well as non-timechart panels, the former might have a higher refresh date.\nGranularity does not affect Metric Retention.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/timechart/"},{"id":33,"title":"Vulnerability Management Policies","content":"PrerequisitesThe prerequisites depend on what Vulnerability Management coverage you need:\nContainer Images in CI/CD Pipelines - Install the Sysdig CLI Scanner either via Integration or Standlone execution inside your CI Pipelines. See Install Sysdig CLI Scanner for Pipeline Scanning. Container Registries - Install the Sysdig Registry Scanner. See Registry Scanning. Kubernetes Workloads and Hosts - Install the shield Chart with the following features supported and enabled. See Install Shield on Kubernets or Install Shield on Hosts. Linux Hosts - Install the Sysdig Host Shield. See Install Host Shield on Linux. Windows Hosts - This feature requires the installation of the Sysdig Windows Host Shield. See Install Host Shield on Windows. Agentless Hosts, Containers and Workloads - Install the Sysdig Agentless Scanning components. See Agentless Vulnerability Scanning. ConceptsPoliciesA Vulnerability Policy is a definition of a series of Rule Bundles, Scopes, and Notifications. A policy can accept one or many Rule Bundles to validate the SBOMs generated by the Sysdig scanning components.\nA policy definition (with the exception of Admission Controller) operates on a Pass or Fail basis.\nCertain rules may only apply to certain versions of the CLI Scanner, it is important to keep your version up to date to support the latest Sysdig Vulnerability and Image Configuration, and Content Rules.\nScopes and StagesA Vulnerability Policy scope defines what Resources, such as Hosts, Workloads or static Images, you wish to apply your policies to, and the stage in which they are scanned.\nPipeline StageA Pipeline stage and scope is specifically used with the Sysdig CLI Scanner. This stage supports the following filtering in an AND fashion and can be used to block your images from progressing in your CI/CD pipelines or on your developer machines.\nScopes All Images: Used for when you want to apply the Policy to any execution of the CLI Scanner, whether on individual runs or via Integrations Image Reference: The pullstring of the image(s) you wish to target e.g. quay.io/sysdig Supported Operators: starts with: Single Value. is: Single Value. is not: Single Value. contains: Single Value. not contains: Single Value. Registry StageA Registry stage and scope is specifically used with the Sysdig Registry Scanner. This stage supports the following filtering in an AND fashion and can be used audit images inside your registry, evaluate your common base images or scan third-party images you may have mirrored into your internal registries for use in your Container Runtime environments.\nScopes All Images: Used for when you want to apply the Policy to any execution of the Registry Scanner on any Registry Image Reference: The pullstring of the image you wish to target for the specific Registry or Repository e.g. quay.io/sysdig Supported Operators: starts with: Single Value. is: Single Value. is not: Single Value. contains: Single Value. not contains: Single Value. Admission Control StageAn Admission Control stage and scope is specifically used with the Sysdig Admission Controller. This stage supports the following filtering in an AND fashion and can be used to Warn, Reject, or Reject and Scan images that fail the policy checks. It is the only Sysdig Vulnerability Management Policy with a Warning function.\nScopes: Kubernetes Labels: kubernetes.cluster.distribution, kubernetes.cluster.name, kubernetes.namespace.name, kubernetes.node.name, kubernetes.pod.container.name, kubernetes.workload.name, kubernetes.workload.type Supported Operators: is: Single Value, is not: Single Value, in: Single Value or List, not in: Single Value or List, contains: Single Value, not contains: Single Value, starts with: Single Value Image Reference: The pullstring of the image you wish to target for the specific Registry or Repository Supported Operators: starts with: Single Value, is: Single Value, is not: Single Value, contains: Single Value, not contains: Single Value Policy Failure ActionsUpon Policy Failure you have two individual options to choose from when evaluating an Image for Admission into your Kubernetes Cluster.\nReject Image: Will completely reject the image for admission into your cluster until all applicable issues are resolved or Exceptions are applied to the Findings on the image. Warn: Will indicate that the Image did not pass its Policy checks but will only Warn the users that it failed. For more information on Sysdig Admission Policies and Evaluations please refer to the Sysdig Admission Controller documentation.\nUnknown Image ActionsUpon evaluation of an Unknown or not previously scanned Image, the Sysdig Admission Controller can perform one of three actions against the offending image.\nReject: Outright reject the Image with an indication that the Image is unknown to Sysdig and that it should be scanned prior to admission. Reject and Scan: Outright reject the Image and initiate a scan of the Image via the Sysdig Cluster Shield. Warn: Warn that the image has not been scanned by Sysdig before, and still allow it admittance into a Kubernetes Cluster. For more information on Sysdig Admission Policies and Evaluations please refer to the Sysdig Admission Controller documentation.\nRuntime StageAn Runtime stage and scope is specifically used components that perform any Runtime Scanning such as the Sysdig Cluster Shield. This stage supports the following filtering in an AND fashion and can be used to evaluate your runtime resources status against your compliance, posture, and best practice policies.\nScopes Resource Labels: Resource labels are pieces of metadata collected by Sysdig Runtime Scanning components. Category Fields Kubernetes kubernetes.cluster.name, kubernetes.namespace.name, kubernetes.node.name, kubernetes.workload.type, kubernetes.workload.name, kubernetes.pod.container.name AWS aws.account.id, aws.account.name, aws.organization.id, aws.region, aws.ecs.cluster.name, aws.ecs.cluster.arn, aws.ecs.task.arn, aws.ecs.task.launch_type, aws.ecs.task_definition.arn, aws.ecs.task_definition.family, aws.ecs.task.container.name, aws.ecs.task.container.image, aws.ecs.service.arn, aws.ecs.service.name, aws.lambda.arn, aws.lambda.name, aws.lambda.version, aws.lambda.image, aws.lambda.package_type, aws.lambda.revision, aws.instance.name, aws.host.name Azure azure.subscription.id, azure.subscription.name, azure.tenant.id, azure.resource_group.name, azure.resourceGroup, azure.location, azure.region, azure.instance.id, azure.instance.name, azure.containerapp.id, azure.containerapp.name, azure.containerapp.container.name, azure.containerapp.container.image GCP gcp.organization.id, gcp.project.name, gcp.project.id, gcp.project.numericId, gcp.region, gcp.instance.zone, gcp.instance.id, gcp.instance.name, gcp.cloudrun.service.id, gcp.cloudrun.service.name, gcp.cloudrun.service.namespace, gcp.cloudrun.service.resource_version, gcp.cloudrun.service.container.image, gcp.cloudrun.job.id, gcp.cloudrun.job.name, gcp.cloudrun.job.namespace, gcp.cloudrun.job.resource_version, gcp.cloudrun.job.container.image, gcp.cloudfunction.id, gcp.cloudfunction.name Cloud Provider cloudProvider, cloudProvider.account.id, cloudProvider.region, cloudProvider.instance.name Container container.name, container.id, container.runtime.type Workload workload.orchestrator, workload.name, asset.type, host.hostName Agent Tags: Agent tags are supported and represented as agent.tag.\u0026lt;tag name\u0026gt; for Resources scanned with the Sysdig Host Shield. Supported Operators: is: Single Value, is not: Single Value, in: Single Value or List, not in: Single Value or List, contains: Single Value, not contains: Single Value, starts with: Single Value Image Reference: The pullstring of the image you wish to target for the specific Registry or Repository Supported Operators: starts with: Single Value, is: Single Value, is not: Single Value, contains: Single Value, not contains: Single Value Rule BundlesA Rule Bundle is a grouping of Sysdig Vulnerability, Image Configuration, and Content rules you wish to be applied to the individual scope defined in your Vulnerability Policy. These rules operate in a Pass or Fail fashion evaluate conditions generated in the SBOM generated by the Sysdig scanning components. For more information please refer to the Sysdig Vulnerability Management Rule Bundles documentation.\nPolicy AlertsA Vulnerability Policy alert is a mechanism to inform your Program Owners or Teams that a policy has failed on a specific set of resources. For more details, see Vulnerability Management Policy Alerts documentation.\nCreate a Scanning PolicyTo create a Vulnerability Scanning Policy you must specify the following fields:\nMain Info Name: Name of the specified policy. Description: A short sentence describing your policy. Often this aligns with a set of best practices or environment information you wish to include in the policy. Rules One or many defined sets of Rule Bundles Scopes A defined set of Scopes and Stages you wish to apply your policy to. Notifications Enabled: Determines whether or not you wish to enable notifications for this particular policy. Silence Period: The silence period you wish to select for this policy. Channel: The supported Notification Channel you wish to specify for this policy. Once you have defined your specified criteria you may save your Vulnerability Management Policy.\nSaving a Vulnerability Management Policy triggers a re-evaluation of all Runtime Resources within your environment, generating new Scan Results and Vulnerability Matches where applicable.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/policies/vulnerability_policies/"},{"id":34,"title":"Vulnerability Overview","content":"This dashboard enables rapid identification of:\nThe most critical vulnerabilities. The worst and most pervasive vulnerabilities. The newest vulnerabilities with the biggest impact. It provides quick insights into your worst problems so you can streamline their remediation and improve your security posture quickly and effectively.\nThe Vulnerability Overview Dashboard currently shows Findings only from Runtime Resources. The current Runtime Resources supported are as follows:\nKubernetes Workloads Container Workloads Hosts Interactive Behavior and Filtering Clicking any bar on the All Critical and High Vulnerabilities graph or any vulnerability in the summary tables will navigate to the Vulnerability Findings page with filters automatically applied to match the selection. For example, Has Fix, In Use, or specific CVEs. When navigating to the Findings view from this dashboard, vulnerabilities that have already been risk accepted are automatically excluded by default to help you focus on unresolved threats. The Zone Selector in the upper-left lets you filter the entire dashboard by one or more Sysdig Zones, a logical grouping of resources such as accounts, clusters, or applications. Zones are in Technical Preview. To enable Zones, go to Settings \u0026gt; User Profile. Under Sysdig Labs, toggle Zones scoping for all features on. If Zones is not available from your User Profile, contact your Sysdig representative.\nScope Reduction with All Critical and High Vulnerabilities GraphThe top section visualizes the progressive reduction of vulnerabilities based on runtime and threat context:\nSeverity: Begins with all Critical and High vulnerabilities detected across your environment. In Use: Filters down to packages currently loaded in runtime: a key signal for identifying what’s truly relevant and running. Has Fix: Focuses further on in-use vulnerabilities with a validated or vendor-provided fix. Has Exploit: Highlights the subset of vulnerabilities that are actively being exploited in the wild. This flow is designed to help you reduce your scope, from a broad attack surface to only those vulnerabilities that are real, fixable, and dangerous.\nCritical and Exploitable VulnerabilitiesThis table surfaces the most impactful CVEs based on volume and context:\nCVE ID: Clickable ID linking to Finding360 with full detail. Findings: Number of individual vulnerability findings of the CVE detected in your environment. EPSS: The Exploit Prediction Scoring System score estimating the likelihood of exploitation within the next 30 days. Context Indicators: Shows if the vulnerability: Has a fix available Is active in runtime Is known to be exploitable Has been risk accepted This view enables rapid identification of both widespread and high-risk vulnerabilities.\nMost Recently Discovered CVEsThis table highlights newly detected vulnerabilities that meet the criteria of being both critical and exploitable.\nFirst Seen: Timestamp when the CVE was first observed in your environment. CVE ID: Opens a detailed view with impact and remediation guidance. Findings: Total number of occurrences across your infrastructure. EPSS: Likelihood of exploitation based on global threat intel. Context: Same contextual risk indicators as in the critical/exploitable view. This section helps teams respond quickly to newly critical problems by surfacing new vulnerabilities as they are detected.\nFor deeper insight into individual vulnerabilities and filtering options, see Vulnerability Findings\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/vulnerability-overview/"},{"id":35,"title":"Sysdig Agent Release Notes 2023 Archive","content":"12.19.0 December 20, 2023Feature EnhancementsChanged HTTP Health Endpoint to Bind to LocalhostChanged the HTTP health endpoint to only bind to the localhost interface. If you are using Helm, upgrade to the Sysdig Agent Helm Chart v1.18.2 or higher. For more information, see Agent Health.\nExport Additional Agent Health Metrics Using Prometheus ExporterThe Sysdig Agent now can use a Prometheus exporter to expose additional agent health metrics. For more information, see Agent Health.\nDue to the sensitive nature of some of these metrics, you may want to ensure that the Prometheus exporter endpoints are not exposed outside of your cluster.\nAdded Profiling Fingerprint Generation to Secure Light ModeYou can now enable Profiling in secure_light mode by setting the falcobaseline.enabled parameter to true in the dragent.yaml or by specifying --set agent.sysdig.settings.falcobaseline.enabled=true if you install the agent via Helm chart.\nModified Audit Tap Message Delivery PolicyAudit Tap messages are now delivered even if they contain only file access records.\nDefect FixesImproved Health Monitoring for Agent SubprocessesHealth monitoring for agent subprocesses now covers all subprocesses spawned.\nAdded Socket Timeout for the Proxy Connection to the CollectorSysdig Agent now utilizes a socket timeout when connected to the collector via proxy. This allows the connection to recover faster without an agent restart when an issue occurs.\nReports Correct Values for Container CPU Usage in Kubernetes v1.26Resolved an issue that impacted the calculation of CPU usage for containers in Kubernetes v1.26.\nDetect App Check MetricsSysdig Agent now can successfully detect app check metrics. This fix enables SCM_RIGHTS to transfer file descriptors across all types of processes. Previously, if a file descriptor transferred via SCM_RIGHTS was for a socket serving app check metrics, the agent could not detect and query it for app check metrics. This presented as missing app check metrics after a process reload.\nKnown Issues If you encounter MAC address duplication after upgrading from v12.20.0 to v13.x.x while operating an on-premises backend, upgrade your on-premises backend to the latest version. Alternatively, you can manually set a unique machine ID prefix for each host as a workaround. 12.18.0 November 22, 2023Feature EnhancementsChanged Default Matching Strategy for Falco RulesSysdig Agent now evaluates an event against all the rules, potentially triggering multiple alerts. In previous versions, the agent stopped evaluating rules after the first match.\nTo change the matching strategy, see Configure Falco Rule Matching Strategy.\nAdded a Metric to Detect Kubernetes EnvironmentThe Sysdig Agent now indicates whether it is executing within a Kubernetes environment or not as part of the sysdig_agent_info metric.\nAdded an Option to Show Prometheus Scrape Jobs in Agent ConsoleAdded the option to view all the Prometheus scrape jobs through the agent console with the prometheus scrape_jobs show command.\nReport Policy Actions in Kubernetes EventsSysdig Agent now supports reporting threat detection policy actions in Kubernetes events.\nWhen the agent performs a stop, pause, or kill container action as defined in a rule, the agent will generate a Kubernetes event with the triggering action details and rule name. You can then see why actions were taken directly from the kubectl events, without having to explore the event feed in Sysdig Secure.\nIf you have deployed agent 12.18+ using Helm, the feature and its associated permissions are enabled by default. If you deploy agents manually, you must set Kubernetes role permissions.\nSee Agent Configuration Library for details.\nEvent Forwarding Directly from Sysdig AgentIt is possible to send Runtime Policy Events and Activity Audit events to SIEM platforms and logging tools directly from the agent. This enables event forwarding without exposing the data collection tool on the internet.\nSee Agent Local Forwarding for details.\nDefect FixesAdded Prometheus Support for FIPS-Enabled ARM SystemsAdded Prometheus support for ARM systems running in FIPS mode.\nLogging and Warning Messages in Secure Only ModeFixed an issue in secure-only mode where some warning log messages were being incorrectly generated.\nRetrieve Kubernetes Service Ingresses for LoadBalancer Service TypeAddressed a defect that could hinder the retrieval of Kubernetes service ingresses when the service type is LoadBalancer. This issue had an impact on Cost Advisor.\nFixed overlayfs on Linux HostsFixed overlayfs support on hosts running Linux kernel version 6.5.\nImproved Container Runtime API Failure HandlingAdded a failsafe to ensure that the container manager doesn\u0026rsquo;t loop forever trying to read data from the container API.\n12.17.1 October 24, 2023 This hotfix is applicable only to Sysdig on-prem deployments; Sysdig SaaS users can disregard Sysdig Agent v12.17.1.\nThis hotfix release fixes the issue where the agent generates events in large numbers when Legacy Compliance is enabled due to incorrect throttling. With this fix, compliance events will be throttled as they were before 12.17.0.\n12.17.0 October 17, 2023 If you are a Sysdig on-prem user, skip v12.17.0 and upgrade to Sysdig Agent v12.17.1. See 12.17.1 October 24 2023 for more information.\nFeature EnhancementsTechnical Preview of Universal eBPFUniversal eBPF driver is now available in Sysdig Agent as an opt-in feature. The Universal eBPF driver is pre-built and embedded in the agent binary. It does not require kernel headers or to build tools from the target system to function and thereby removes the need for users to build or download probes on supported systems. To learn more about the capability, see Universal eBPF.\nUse Protocol Buffer to Communicate to Kubernetes API ServerCointerface uses Google Protocol Buffers as a wire format for communicating with the Kubernetes API server.\nUpdate OpenSSL Library to OpenSSL v3.1 and Include a FIPS-Validated Crypto ModuleIn light of OpenSSL v1.1.1 reaching end-of-life, this release updates its bundled OpenSSL libraries to v3.1.3.\nAdditionally, this release bundles a FIPS(Federal Information Processing Standards)-validated OpenSSL crypto module with the agent. Adding the crypto module removes the requirement for user-provided, FIPS-validated OpenSSL shared libraries when the fips_mode configuration parameter is set to true.\nThis update breaks the agent\u0026rsquo;s backward compatibility with OpenSSL v1.1.1. If you have configured the openssl_lib parameter, do one of the following:\nProvide OpenSSL v3.1 shared libraries Remove the parameter and rely on the bundled OpenSSL shared libraries End of Support for OpenShift v3Sysdig Agent versions beyond 12.17.0 will no longer be supported on OpenShift 3. v12.17.0 will be the last version supporting OpenShift 3.\nDefect FixesPrevent Transition During RestartsThe agent will no longer release the Kubernetes delegation lease during tear-down to avoid unwanted transitions during restarts.\nPolicy Scoping in Fargate Now Respects Agent LabelsFargate agents will no longer skip agent labels when performing policy scoping.\nDisplay Resolved IPs in the Network Security Policy EgressThe agent uses improved logic to resolve services and endpoints, and therefore, the network communications in some namespaces will no longer be dropped as unresolved.\nUse get_mm_exe_file()A safer version of the Linux kernel API call is used where get_mm_exe_file() is available.\nShow Correct Kubernetes StatusFixed defects in the Kubernetes status reporting. The kube_workload_status_available and kube_workload_status_unavailable metrics now report correct values even when the cluster node count changes and the Kubernetes status reflects the state correctly after the cointerface switches run modes.\nPrevent Unintended Agent RestartA defect was fixed where an invalid message from the backend caused an unintended agent restart.\nStore Device Metrics as ExpectedA defect was fixed where I/O metrics for devices were not stored.\nDisplay Kubernetes Cluster Association CorrectlyA defect was fixed which caused incorrect agent association with Kubernetes clusters on the Sysdig Agents page in the Integrations UI.\nDisplay Correct Timeseries Count in Prometheus LogsFiltered timeseries counts in Prometheus statistics logs are now reported correctly.\n12.16.3 October 15, 2023This hotfix delivers the following:\nAddressed the following vulnerabilities:\nCVE-2023-38545 CVE-2023-4911 Fixed the kernel null pointer dereference on Linux kernel 6.5. Support for is_exe_upper_layer will be disabled (both kmod and bpf) for those kernels.\n12.16.2 September 28, 2023Improved security for connections between Sysdig Agent and Apache Mesos.\nSysdig Agent primarily connects to Apache Mesos using cURL. When negotiating a TLS (Transport Layer Security) or SSL (Secure Sockets Layer) connection, the Mesos server sends a certificate indicating its identity. cURL verifies the authenticity of the TLS certificate before establishing the connection with the Sysdig Agent. Before this fix, Mesos would not verify the TLS certificate if the connection was over HTTPS.\nTo establish a cURL connection to Apache Mesos as of Sysdig Agent v12.16.2:\nEnsure that the CA cert indicates the Mesos server where the agent will connect. Check that the Mesos server name given in the URL matches the one in the certificate. 12.16.1 September 11, 2023This hotfix release delivers the following:\nAddressed Critical and High vulnerabilities related to Go v1.19:\nCVE-2023-24540 CVE-2023-24538 CVE-2022-41720 CVE-2022-41722 CVE-2022-41723 CVE-2022-41724 CVE-2022-41725 CVE-2023-2253 CVE-2023-24534 CVE-2023-24536 CVE-2023-24537 CVE-2023-24539 CVE-2023-29400 CVE-2023-29403 Fixed an issue of container detection not working properly for Podman containers:\non Alpine Linux when running the Sysdig Agent in a container 12.16.0 August 08, 2023Feature EnhancementsDefault Availability of Process Tree in Sysdig SecureProcess lineage will be available for every event and is enabled by default starting from this version of the agent. The process tree will be visible in the Events detail pane for events related to workloads that are triggered from that point on.\nSupports Control Group v2Control groups v2 (cgroups v2) are now supported in the Sysdig Agent. In particular, the v1 freezer subsystem is no longer mounted when using cgroups v2, as it caused potential compatibility issues in the past.\nView Agent Threads for Improved Performance AnalysisThe Sysdig Agent threads on Linux x86 platforms have been named to facilitate better analysis of agent performance. Previously, they were named after the default process name, dragent. Now, these threads have descriptive names, with suffixes dr- or dr=. For example, dr-monitor and dr=sinsp_evnt_. The thread name is usually a truncation of the nearest unique function name.\nCollects Node LabelsSysdig Agent can by default collect the node-role.kubernetes.io/* labels set on nodes.\nKnown IssuesContainer Limits to Drift Control For kernel versions below v5.13, Drift Control can monitor up to 128 containers per node. For kernel versions v5.13 or above, modify the container limit using one of the following methods: Open the sysctl -n fs.fanotify.max_user_groups file and set the new value by using sysctl -w fs.fanotify.max_user_groups=\u0026lt;new_limit\u0026gt;.\nOpen the cat /proc/sys/fs/fanotify/max_user_groups file and run echo \u0026lt;new_limit\u0026gt; \u0026gt; /proc/sys/fs/fanotify/max_user_groups.\nReplace \u0026lt;new_limit\u0026gt; with your choice of container limit.\nAgent Logs Show Errors for On-Prem Installations in Secure Only ModeWhen connecting to an on-prem backend with Secure Only mode, the agent doesn\u0026rsquo;t connect successfully unless you add the 60s_flush_enable: true configuration under sysdig.settings in the agent configuration file.\nDefect FixesRemoved Compliance Manager SupportCompliance manager functionality has been removed from Sysdig Agent. The feature was no longer supported, but it appeared in a security audit as having a vulnerability. For this reason, the functionality has been dismissed.\nIgnores Non-Running Pods for ScrapingThe Prometheus k8s-pods job configuration has been modified to drop scrapes from non-running pods.\nEnable FIPS-Validated Crypto Module for Agent-to-Backend communicationThe agent can now use a FIPS(Federal Information Processing Standards)-validated crypto module for encrypting communication with the Sysdig backend. This feature requires a user-provided, FIPS-validated OpenSSL v1.1.1 shared library to function properly. See the Configuration Library for more information.\nRetry Sending Secure EventsThe Sysdig Agent now retries sending secure events in cases where the agent disconnects and reconnects.\nAdds Missing Health Metrics in Secure ModesAn additional metric is collected in the secure and secure_light modes. The protobuf output for secure and secure_light mode now includes an aggrSamplingRatio aggregation field, weighted to the negotiated metrics interval.\n12.15.0 June 28, 2023Feature EnhancementsProcess TreeThis version of the Sysdig Agent adds support in Sysdig Secure for the Process Tree visualization which enriches the Events feed for workload-based events. This feature helps you identify all the processes that led up to the offending process.\nTo enable this feature:\nAdd the following configuration to the values.yaml file associated with the sysdig.deploy chart:\nagent: sysdig: settings: enrich_with_process_lineage: true You can use the sysdig.settings parameter of the agent subchart to merge this configuration into your existing values.yaml file.\nLog in to Sysdig Secure as administrator and select Settings \u0026gt; User Profile. Scroll down to Sysdig Labs and toggle the feature on.\nThe process tree will be visible in the Events detail pane for the events related to workloads that are triggered from that point on.\nAdded Support for Java 7In Sysdig Agent versions 12.10.0 to 12.14.1, a Java dependency was upgraded to a version that didn\u0026rsquo;t support Java 7. As a result, those versions cannot run the Java process which collects Java Management Extensions (JMX) metrics on any Java 7 Java Development Kits (JDKs)/Java Runtime Environments (JREs). This release downgrades the dependency back to a version that supports Java 7.\nAdded Support for Node Cost MetricsSysdig Agent now supports node cost metrics when using the thin cointerface.\nBuilding Probes for Airgapped EnvironmentsEffective July 28, 2023, a minor change has been enforced to the process of building probes for airgapped environments. See Airgapped Agent Installation for further details.\nAdded Sysdig Secure Rule for Detecting Fileless AttacksSysdig Secure has added the ability to detect fileless attacks using a new Falco rule on the Sysdig Threat Detection managed policy. See also: SaaS release note.\nVulnerability FixesAddressed CVE-2023-0286 by upgrading the OpenSSL version in the agent to 1.1.1t.\nDefect FixesMetrics Parity Between Secure and Secure Light ModesThe Sysdig Agent will now report the same set of metrics in both secure and secure_light modes, which means that the program metrics in secure mode will also be restricted to the dragent process or container.\nEnhanced Execution Time AccountingFixed system execution time accounting for certain events that would cause incorrect reporting of agent I/O metrics.\nAdded Support for s390x for UbuntuRecent s390x Linux distributions, including Ubuntu v20.04, require the compiler to support the -march=z13/-mtune=z15 flags when building kernel modules. The gcc version used in agent-kmodule image for the s390x platform has been upgraded to gcc-12, which supports the required flags.\n12.14.1 May 16, 2023This hotfix release provides the following enhancements:\nAdded Support for Kernel Version 6.3The kernel module has been updated to support Linux kernel version 6.3.\nFixed VulnerabilitiesResolved CVE-2023-28840 in promscrape.\nFixed Probe Build Errors on RHEL6Fixed probe build errors on RHEL6 hosts.\n12.14.0 May 08, 2023Feature EnhancementsEnhanced Console LoggingThe console log messages sent to stderr have been restricted to Warning or higher priority only. All the lower priority console log messages are sent to stdout. This reduces noise.\nOptimized Filtering The following redundant elements were removed from the Falco rules optimizer: The evt.type/evt.dir fields The evt.arg.res = 0 checks The redundant container.id != host field was removed from conditions while indexing with the rules optimizer. Improved Drift Detection in Sysdig SecureWith agent 12.14.0, drift detection is improved in Sysdig Secure. Drift detection requires a minimum kernel version of 3.18 and drift prevention requires a minimum kernel version of 5.0.\nFor more information, see Enable Drift.\nAdded Logging to Detect Incorrect Collector EndpointsAdded detection for invalid HTTP responses on connection.\nEnabled Default Scraping of Docker ContainersSysdig Agent now supports scraping Prometheus metrics from Docker containers by default. Scraping is based on container labels.\nDependenciesAdded fmt LibraryAdded the fmt library to the Agent dependencies. The agent currently does not use this library.\nUpgraded Library TBBThe TBB (Intel\u0026rsquo;s Threading Building Blocks) library has been upgraded to oneTBB v2021.8.0.\nUpgraded Boost LibraryThe Boost library used by Sysdig Agent has been upgraded to v1.81.0.\nKnown Issues Agent not compatible with GKE Autopilot running Kubernetes v1.26 Agent not compatible with Kernel v6.3 Defect FixesRestarting the Agent No Longer Causes Premature Process TerminationThe SysV init script for RPM-based distributions now takes agent shutdown time into account, avoiding premature SIGKILL.\nPID tracking is now enabled for systemd-sysv-generator.\nExclude JVM from MonitoringAgent can now exclude some Java Virtual Machines (JVMs) from being monitored.\nA set of exclusion rules can be defined in the agent\u0026rsquo;s config. Each rule is a property/pattern pair: when the value of the given Java property matches the pattern, a process of that JVM is excluded from being monitored. For example, the following configuration will exclude OpenJ9-based JVMs from being monitored:\njmx: jvm_exclude: - property: java.vm.name pattern: .+OpenJ9.+ Previously, this functionality was hardcoded to reject OpenJ9, but this is no longer the case. If you observe heap dumps when monitoring OpenJ9, you should add the configuration above to your dragent.yaml file.\nRecover from Handshake Errors Between Agent and CollectorFixed an issue preventing the agent from recovering after a bad protocol handshake.\n12.13.0 March 30, 2023Feature EnhancementsKernel SupportSysdig Agent now supports kernel versions 6.2.x.\nVersion Upgrade for Library BenchmarkLibrary Benchmark has been updated from version 1.5.0 to 1.7.1.\nFixed VulnerabilitiesFixed CVE-2022-40897.\nCollect PodDisruptionBudget MetricsAdded support for collecting Kubernetes PodDisruptionBudget metrics.\nSend Start and Ready Time for PodsAdded support for sending start time and ready time for a pod when configured. For more information, see Customize KSM Collection.\nDefect FixesAgent No Longer Fails When Customer ID Is UnspecifiedFixed a problem where an agent, stuck in a restart loop due to lack of configured customer ID, would fail to recognize when the configuration was subsequently updated to provide a customer ID.\nAgent Retrieves JMX Metrics as ExpectedSysdig agent no longer generates heap dumps while fetching JMX metrics. Agent now performs a check whether the removed JVM is OpenJ9, and in such cases it will not attach to it.\n12.12.1 March 12, 2023This hotfix release provides the following defect fixes:\nPodman containers running as unprivileged systemd services are detected correctly. Container image metadata is reported correctly with Podman 4.x. 12.12.0 March 02, 2023Feature EnhancementsOptimize Collecting Runtime RulesThe Falco rules optimizer has been enabled by default. This performs optimizations on the collection of runtime rules in conjunction with system call events to help reduce agent CPU usage.\nDefect FixesFixed VulnerabilitiesFixed the following:\nCVE-2022-41723 CVE-2022-41723 Fixed Proxy ConnectionFixed an issue where a proxy connection could fail if used in conjunction with the agent console.\nFixed nss_compat Records ParsingThe upgrade to v12.11.0 works as expected. The nss_compat records in /etc/passwd are now parsed correctly if data is missing, which fixes the issue of the agent not being ready after an upgrade.\n12.11.0 February 13, 2023Feature EnhancementsSearch Container Password and GroupsContainer password and groups are now searchable in container terminal shell.\nConfigurable Live Logs SessionsNow live_logs sessions start with the last 100 lines by default, instead of 10.\nTo configure the tail length, edit the dragent.yaml file as follows:\nlive_logs: tail_lines: 200 Replace 200 with the desired number of lines.\nInstance Metadata Service (IMDS)V2 SupportThe agent can now dynamically switch its AWS metadata query version to IMDSv2 if the initial metadata lookup fails with an HTTP 401 error. This retry mechanism will be activated each time the configuration settings are loaded without explicitly setting imds_version to 2 in the dragent.yaml file, as it will result in the same HTTP error on the first subsequent metadata call. For more information on configuration options, see Configuration Library.\nDefect FixesRemoved Proxy Passwords from LogsThe agent logs no longer contain plaintext proxy passwords.\nDisable Containerd EventsYou can configure Containerd events emission by using the events: \u0026gt;containerd: section in the .yaml configuration.\nEnhanced Legacy DelegationA fallback mechanism has been added to get the agent pod’s namespace. All the pods with label app: sysdig-agent and their namespace are now listed.\nDisplay Correct CPU Utilization for Linux HostsMonitor UI now shows correct CPU utilization for the Linux host.\nCommunicate with Kubernetes Clusters with IPV6 AddressesThe cointerface process continue to communicate with Kubernetes clusters with IPs that only have IPV6 addresses.\nFix Cointerface Process FailureFixed a problem in agent 1v2.10.x that could cause the cointerface process to fail when k8s_delegated_nodes was set to 0.\nMake CRI Socket Path Searchable in EKS+Bottlerocket EnvironmentsThe container runtime interface (CRI) socket path used by EKS+Bottlerocket is now added to the set of paths automatically searched by the agent.\nSend Stale Makers for Failed ScrapesFixed an issue that could intermittently cause the agent to send invalid Prometheus values instead of stale markers for failed scrapes.\nAgent Starts as Expected on FedoraFixed a problem of agent startup failure on cloud variants of Fedora v35+ when no kernel headers are available.\n","url":"https://docs.sysdig.com/en/release-notes/linux-agent-release-notes/2023-archive/"},{"id":36,"title":"Secure SaaS Release Notes 2024","content":"December 31, 2024Registry Scanner v0.7.1Added fixes for CVE-2024-45338\nDecember 20, 2024Registry Scanner v0.7.0Registry Scanner now supports OpenSUSE and AlmaLinux.\nAdded fixes for the followings vulnerabilities:\nCVE-2024-3596 CVE-2024-45337 December 19, 2024Validate Public Exposure with Sysdig Exposure Validation ScanningSysdig now offers Public Exposure Validation, a powerful feature that confirms whether resources in your environment are genuinely accessible from the internet. By reducing exposure false positives, this feature empowers you to confidently prioritize remediation efforts, focusing on the fixes that matter to the security of your cloud environment.\nContact your Sysdig representative to enable this feature. For more information, see Network Exposure Tab.\nDecember 18, 2024YARA Rules and Regex Exceptions for Malware Control PolicySysdig released the Malware Control Policy into general availability (GA) with the following improvements:\nYou can now utilize YARA rules maintained by Sysdig\u0026rsquo;s Threat Research Team to enhance the policy\u0026rsquo;s detection capabilities.\nYou can customize exceptions for files, processes, and hashes with Regex or exact string matching.\nTo learn more about YARA rules and exceptions, see Malware Control Policy — Detect.\nDecember 13, 2024Identity Permissions EnhancementThe Identity resource drawer now highlights permissions flagged as risky by the Sysdig Threat Research team. These permissions, identified for their potential misuse by compromised identities, are accompanied by usage insights to help you achieve least privileged access.\nSupported Identity types include:\nIAM Policies (AWS) Users (AWS, Azure, GCP) Roles (AWS, Azure, GCP) Service Identities (Azure, GCP) Find the Risky Permissions section in the Summary tab of the Identity detail drawer. To learn more, see Understand Risky Permissions.\nDecember 10, 2024Enhanced Inventory APIThe Inventory API has been improved by introducing the following cloud resource fields:\nAWS Resources accountName: The AWS Account name. accountId: The AWS account ID. GCP Resources projectName: The GCP project name. projectId: The GCP project ID. Azure Resources subscriptionName: The Azure subscription name. subscriptionId: The Azure subscription ID. Network ExposureSysdig Inventory API enables you to filter by exposed resources such as buckets, workloads, and virtual machines using the isExposed field. This field indicates whether the configuration for the resource exposes it to the internet. Sysdig introduces the validatedExposure field to specify whether the resource, such as buckets and virtual machines, could be reached by the Sysdig\u0026rsquo;s network validator service.\nFor more information, see the Next Gen API Docs.\nDecember 05, 2024Compliance Readiness ReportSysdig is excited to introduce Compliance Readiness Reports, the next step in reporting. Previously, it was hard to see policies structured by compliance, requirements, and controls to track what was passing or failing.\nNow, you can schedule reports and view past reports to easily track progress over time. For more information, see Compliance Readiness Reports.\nGraph SearchQuery a graph database to search for anything in your cloud environments. The intuitive query builder ensures a seamless experience and lets you proactively identify risky patterns before they escalate into full-fledged threats.\nFor more information, see Graph Search.\nCustom RisksEvery organization faces unique security challenges that demand a tailored approach. Sysdig Custom Risks meets this need by enabling security teams to define, write, and execute custom risk patterns. With this flexibility offered by Custom Risks, you can create adaptive queries aligned with your specific environment and risk tolerance. You can build graph queries and save them as Custom Risks for ongoing management. For more information, see Custom Risks.\nDecember 03, 2024Risk Automation (Technical Preview)Introducing the technical preview release of the new Sysdig Secure Automation feature. In this release, you can create automations for new risks and risk update triggers, enabling notification channel alerts and webhook actions based on various attributes within a risk event. This feature is actively evolving, with upcoming enhancements to include additional functionality and triggers, such as vulnerability management and runtime detection.\nFor more information, see Risk Automation.\nNovember 27, 2024Service Account Expiry NotificationsWe have expanded the Sysdig Secure UI to support configuring notifications for expiring Team Based Service Accounts. This builds on existing API capabilities, making token management more accessible for all users.\nBy enabling these notifications, you can ensure your service account tokens are renewed on time.\nFor more details, see Expiry Notifications.\nNovember 19, 2024Hide Accepted RisksSysdig enables you to hide accepted risks, allowing you to focus on unresolved vulnerabilities. To support this, the Sysdig Vulnerability Overview pages and the Vulnerabilities tab on the scanning result pages include a Risk Acceptance filter. This filter help you view All Risks or Accepted Risks, or hide accepted risks by selecting Risk Not Accepted.\nFor more information, see Filters.\nNovember 15, 2024New Posture Policies for AKS, SUSE, and UbuntuThe following policies have been added to support key posture benchmarks:\nCIS Azure Kubernetes Service (AKS) Benchmark v1.4.0: Ensures improved security for Azure Kubernetes environments. CIS SUSE Linux Enterprise 12 Benchmark v3.1.0: Strengthens compliance for SUSE Linux Enterprise 12. CIS Ubuntu Linux 24.04 LTS Benchmark v1.0.0: Provides compliance checks for the newest Ubuntu Long Term Support release. For more information, see Posture Policies Included.\nCSPM Auto-Acceptance EnhancementSysdig-deployed components are now automatically accepted in cloud security posture management (CSPM), regardless of their namespace. This significantly reduces unnecessary alerts in Compliance reports, allowing you to focus on actionable findings.\nNovember 14, 2024EPSS SupportSysdig Vulnerability Management integration and ingestion of First.org Exploit Prediction Scoring System (EPSS). Sysdig EPSS functionality is available via Scan Result API and Vulnerability Management (VM) Reporting.\nIn VM Reporting, this field is available as vulnEPSSPercentile and vulnEPSSScore\nExample API Output:\nExample EPSS Metadata \u0026#34;providersMetadata\u0026#34;: { \u0026#34;first.org\u0026#34;: { \u0026#34;epssScore\u0026#34;: { \u0026#34;score\u0026#34;: 0.00044, \u0026#34;percentile\u0026#34;: 0.13929, \u0026#34;timestamp\u0026#34;: \u0026#34;2024-11-12T00:00:00Z\u0026#34; } }, ... } Expansion of Vendor Metadata in Scan Results: RedHat and NVDAdded scores from National Vulnerability Database (NVD) and RedHat to our Scan Result API in Vulnerability Management (VM). These scores were previously available in Matching, Scoring and Data Sources. This iteration increases their availability, enabling you to take advantage of various CVSS scores and severities.\nExample Provider Metadata \u0026#34;providersMetadata\u0026#34;: { ... \u0026#34;nvd\u0026#34;: { \u0026#34;publishDate\u0026#34;: \u0026#34;2023-11-27T22:15:07.94Z\u0026#34;, \u0026#34;cvssScore\u0026#34;: { \u0026#34;version\u0026#34;: \u0026#34;3.1\u0026#34;, \u0026#34;score\u0026#34;: 5.5, \u0026#34;vector\u0026#34;: \u0026#34;CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H\u0026#34; }, \u0026#34;severity\u0026#34;: \u0026#34;medium\u0026#34; }, \u0026#34;rhel\u0026#34;: { \u0026#34;cvssScore\u0026#34;: { \u0026#34;version\u0026#34;: \u0026#34;3.1\u0026#34;, \u0026#34;score\u0026#34;: 7.8, \u0026#34;vector\u0026#34;: \u0026#34;AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H\u0026#34; }, \u0026#34;severity\u0026#34;: \u0026#34;high\u0026#34; }, \u0026#34;vulndb\u0026#34;: { \u0026#34;publishDate\u0026#34;: \u0026#34;2023-11-23T00:00:00Z\u0026#34; } } These scores are also available in VM Reporting to be consumed from the following fields:\nNVD nvdVulnCvssScore nvdVulnCvssSeverity nvdVulnPublishDate RedHat rhelVulnCvssScore rhelVulnCvssSeverity Registry Scanner v0.6.1The Registry Scanner does not support configuring the cron job to run more frequently than once every 24 hours.\nNovember 06, 2024CLI Scanner v1.18.0Sysdig released a new version of the CLI Scanner with the following improvements:\nIncluded a Federal Information Processing Standards (FIPS) validated cryptographic library within the binaries with suffix tag -fips.\nSee CLI Scanner Installation.\nAdded --output and --output-schema flags.\nThe \u0026ndash;output-json and \u0026ndash;json-scan-result flags have been deprecated.\nSupport for EPSS, NVD CVSS, and RedHat CVSS in CLI.\nThe CLI Scanner now forwards this data to the Sysdig backend.\nSupport for public API v1 output format.\nFor more information, see the Public API docs.\nAdded fixes for the followings vulnerabilities:\nCVE-2024-9341 CVE-2024-9407 Registry Scanner v0.6.0Registry Scanner now supports AWS GovCloud. Starting from this version, Registry Scanner can scan Elastic Container Registries (ECR) within Gov Cloud accounts and organizations.\nFor more information, see Install Registry Scanner\nOctober 29, 2024Download SBOM Using Sysdig Secure UITo address the growing demand for transparency and compliance in software supply chains, Sysdig has improved the scan result experience by introducing an SBOM Download button in the Sysdig Secure UI. With just one click, you can now download a comprehensive Software Bill of Materials (SBOM) that includes a complete record of components detected during a scan, formatted in the widely used CycloneDX JSON format.\nThis enhancement provides you with detailed access to software components, empowering you to conduct more effective audits, manage risks efficiently, and simplify compliance with industry standards.\nFor more information, see Download SBOM.\nRuntime Scanner v1.8.1Sysdig released a new version of Runtime Scanner with fixes for the followings vulnerabilities:\nCVE-2024-34155 CVE-2024-34156 CVE-2024-34158 CVE-2024-8260 October 21, 2024GCP Risk policiesSysdig Risks module extends its capabilities to Google Cloud environments by adding the following risks:\nPublicly exposed GCE with Critical Vulnerability Publicly Exposed GCS Bucket For more information, see Risk Policies.\nOctober 14, 2024Sysdig Sage for Cloud Detection and ResponseSysdig Sage for Cloud Detection and Response (CDR) is now generally available. Designed for security teams responsible for incident response and forensics, Sysdig Sage accelerates investigation and response. It provides features like command line explanations, rule and data interpretation, investigation guidance, and next-step recommendations.\nWith summarization and explainability, Sysdig Sage makes managing security events more efficient. See Sysdig Sage to learn more.\nOctober 02, 2024AWS Behavioral AnalyticsSysdig added a new type of managed policy to the AWS CloudTrail Runtime Policy type. AWS Behavioral Analytics runs on a different engine from the majority of Sysdig\u0026rsquo;s Falco-based policies. This enables the detection of sophisticated threats, such as privilege escalation attempts and reconnaissance activities across a range of AWS services. For more details, see Behavioral Analytics.\nOctober 01, 2024Host Scanner v0.12.3Sysdig released a new version of Host Scanner with a fix for CVE-2024-34155 and CVE-2024-34156.\nSeptember 26, 2024CLI Scanner v1.17.0Sysdig released the new version of CLI Scanner with the following improvements:\nThe Vulnerability Management scan result v1beta json output now includes a ruleId field for each Policy Rule. Fixes CVE-2024-8260. September 25, 2024Host Scanner v0.12.2Sysdig released a new version of Host Scanner with a fix for CVE-2024-8260.\nSeptember 19, 2024Support for Jira Data CenterSysdig Secure\u0026rsquo;s Jira Ticketing integration now supports both Jira Cloud and Jira Data Center. On-Prem users self managing their Jira Data Center can now open Jira tickets from within Sysdig Secure\u0026rsquo;s UI. See Jira Ticketing.\nSeptember 17, 2024Integrate with Visual Studio CodeSysdig released an extension for Visual Studio Code. You can now scan container images, apply policies, and manage vulnerabilities early in the development process, without waiting for lengthy CI/CD checks. This extension sanitizes software packages before the code is pushed to production, saving critical time and preventing security from slowing down developer workflows. To detect and fix security concerns early Integrate with Visual Studio Code.\nSeptember 13, 2024New Compliance Mode for the CLI ToolSysdig has introduced a Compliance Mode for the CLI Scanner, offering enhanced flexibility and customization for policy evaluations. This release brings:\nCustomizable Policy Evaluation: You can now specify the exact policies to evaluate when running the CLI Scanner against a Git repository. Optional Configuration File: You can now customize parameters for your scans with an optional configuration file. JSON Output: The CLI Scanner now supports JSON output, enabling seamless integration with external systems. Flexible Output Grouping: You can group scan results by resource or policy, providing more control over the output format. Additionally, we fixed a defect that previously caused incorrect identification of the Bouncy Castle Crypto Java package.\nThe following vulnerabilities have also been identified and resolved:\nCVE-2024-34155 CVE-2024-34156 CVE-2024-34158 CVE-2024-45310 For more information, see Install Sysdig CLI Scanner.\nHost Scanner v0.12.1Sysdig released a new version of Host Scanner with the following improvements:\nAddressed a defect which could lead to wrong identification of Bouncy Castle Crypto java package Fixed the following vulnerabilities: CVE-2024-34155 CVE-2024-34156 CVE-2024-34158 September 10, 2024GCP Resources in Inventory Network ExposureSysdig has extended the scope of the Network Exposure tab in Inventory, which reveals the exposure paths for exposed resources, to now include Google Cloud Platform (GCP) hosts and GCP Cloud Storage Buckets. See Use the Network Exposure Tab.\nRegistry Scanner v0.5.0Registry Scanner now includes a Federal Information Processing Standards (FIPS) validated cryptographic library within the images with suffix tag -fips.\nSeptember 5, 2024Registry Scanner v0.4.0Sysdig released a new version of Registry Scanner with the following improvements:\nAllow node selector customization for workers. Addressed a defect in the policy and risk acceptance evaluation that caused certain package versions in some Red Hat Enterprise Linux (RHEL) packages to be improperly parsed. Bottlerocket OS detection. Host Scanner v0.12.0Sysdig released a new version of Host Scanner with the following improvements:\nBottlerocket OS detection. Added support for MESOS_TASK_ID docker label for usage in Quick Filters, Policies and Unified Filtering within Runtime Scanning views as mesos.task.id. Runtime Scanner v1.8.0Sysdig released a new version of Runtime Scanner with the following improvements:\nAdded support to replicationcontroller resource kind. Addressed a defect in the policy and risk acceptance evaluation that caused certain package versions in some Red Hat Enterprise Linux (RHEL) packages to be improperly parsed. September 4, 2024New Posture PoliciesSysdig added several new Posture Policies, further enhancing our security and compliance coverage. This release includes the following:\nAustralian Government Information Security Manual (ISM) 2022 DPDP (Digital Personal Data Protection) Act CCPA (California Consumer Privacy Act) Reserve Bank of India (RBI) Framework SEBI (Securities and Exchange Board of India) Act These policies help your organization align with the latest industry standards and regulatory frameworks, ensuring comprehensive security and compliance management.\nFor more information, see Posture Policies Included.\nAugust 28, 2024Sysdig CLI Scanner v1.15.0 ReleasedSysdig released the new version of CLI Scanner with the following enhancements:\nVM Addressed a defect in the policy and risk acceptance evaluation that caused certain package versions in some Red Hat Enterprise Linux (RHEL) packages to be improperly parsed. Resolved a defect that caused the scanner to hang indefinitely when used with container storage during execution. August 27, 2024Vulnerability Management Support for Rocky LinuxSysdig Secure Vulnerability Management now supports operating system and Package detection on Rocky Linux v8 and v9. This support leverages the respective vulnerability feeds for Rocky Linux v8 and v9 sourced from Rocky ERRATA in tandem with Sysdig’s additional vulnerability enrichment.\nThe agent components that support Rocky Linux are:\nCLI Scanner version v1.13.1 and above Cluster Shield v1.2.0 and above Host Scanner v0.10.2 and above Registry Scanner v0.2.73 August 20, 2024Navigation ReorganizationSysdig has streamlined and updated the UI navigation menus to help you access our security platform faster.\nEvents, Insights, and InvestigationThreats happen in real time. You need to be able to quickly identify those threats without having to think about the best tool to use in the moment.\nPreviously these threats were under different menus moving from Events, to Investigate, and Insights. We’ve moved them all under a new unified menu. We’re not stopping there, as we plan to integrate threat investigation experience in a unified workflow.\nInventoryInventory has changed with new submenus.\nResources is now the landing page Kubernetes Live \u0026amp; Network gets a new home Zones help you configure your inventory and assets as needed Cloud Identity EntitlementsIdentity is an integral part of understanding who is acting or compromised when dealing with security threats. Quickly finding and mitigating an identity risk can save precious time, stopping an ongoing threat. We have now given Identity its own section (previously under Posture).\nPosture and VulnerabilitiesCompliance, previously under Posture, is now under its own section.\nVulnerabilities \u0026amp; Risks remain relatively unchanged, with some minor changes such as Accepted Risks now living under its respective menu.\nThe following table lists the mapping between the old and new menus.\nOld and New Menus Old Menu New Menu Home Home Risk Risk Events Threats Inventory Inventory Vulnerabilities Vulnerabilities Posture Compliance Identity and Access Identity n/a Reporting Policies Policies Insights Threats \u0026gt; Activity Network Inventory \u0026gt; Network Investigate Activity Audit Old and New SubmenusThe following table lists the mapping between the old and new submenus.\nMain Menu Old Submenu New Submenu Home Home Home Inventory Inventory - Kubernetes Live Kubernetes Live Inventory Assets Network Network Zones Risk Risk Risk Threats Events Event Dashboards - Events Overview Overview - All Threats Event Dashboards - Kubernetes Events Overview - Kubernetes Events Dashboards - Cloud Events Overview - Cloud Events Feed Activity - Events Feed Threats \u0026gt; Activity Insights - Cloud Activity Activity - Cloud Activity Insights - Cloud User Activity Activity - Cloud User Activity Insights - Kubernetes Activity Activity - Kubernetes Activity Insights - Node \u0026amp; Pod Activity Activity - Node \u0026amp; Pod Activity Insights - Host \u0026amp; Container Activity Activity - Host \u0026amp; Container Activity Threats \u0026gt; Investigate Investigate - Activity Audit Investigate - Activity Audit Investigate - Captures Investigate - Captures Investigate - Rapid Response Respond - Start Rapid Response Investigate - Rapid Response Session Log Respond - Rapid Response Session Log Vulnerabilties Vulnerability Management Overview Overviews - All Vulnerabilities Overview - Vulnerability Management Pipeline Overviews - Pipeline Overview - Vulnerability Management Registry Overviews - Registry Overviews - Runtime Pipeline Findings - Pipeline Registry Findings - Registry Runtime Findings - Runtime Reporting Findings - Reporting Risk Acceptance - Vulnerabilities Findings - Accept Findings Scanning Configure New Overview Compliance Findings Risk Acceptance - Posture Accepted Findings Identity New Reporting New Policies Threat Detection - Runtime Policies Threat Detection - Runtime Policies Threat Detection - Rules - Rules Library Threat Detection - Rules - Rules Library Threat Detection - Rules - Falco List Threat Detection - Rules - Falco List Threat Detection - Rules - Falco Macro Threat Detection - Rules - Falco Macro Threat Detection - Rules - Rules Editor Threat Detection - Rules - Rules Editor Threat Detection - Runtime Policy Tuning Threat Detection - Runtime Policy Tuning Threat Detection - Image Profiles Threat Detection - Image Profiles Vulnerabilities - Pipeline Vulnerabilities - Pipeline Vulnerability - Runtime Vulnerabilities - Runtime Vulnerability - Rule Bundles Vulnerabilities - Rule Bundles Posture - Policies Posture - Policies Posture - Controls Posture - Controls Package Deny ListThe new package deny rule lets you control which packages are allowed in your codebase. You can add a specific package or a specific version of a package in a comma-separated list to the rule bundle. By defining these rules, you can enforce stricter security measures and maintain tighter control over your software artifacts. For more information, see Package Deny List.\nAugust 16, 2024Running CLI Scanner IaC Mode as a Jenkins StepSysdig now supports the integration of the CLI Scanner IaC Mode directly within Jenkins pipelines. This feature allows you to incorporate the CLI scanner into your Jenkins workflows, enabling automated enforcement of Posture Policies during Kubernetes deployments. With this integration, you can block deployments that do not meet user-defined policies or trigger warnings.\nFor more information, see Jenkins Integration.\nNew Reporting ModuleSysdig has released a new module for creating, managing and sharing reports, to be used in place of the Vulnerabilities Reporting interface. The new Reporting module provides more historical data, trends over time, customizable dashboards, panels, and more flexibility for scheduling reports. Scheduling allows you to set the frequency along with the timeframes. You can now create reports of up to 30 days worth of data. You can easily configure, schedule, and share reports. For more details, see Reporting.\nAugust 14, 2024AWS GuardDuty FindingsYou can now see AWS GuardDuty findings in Sysdig Secure, ingested through our Agentless Cloud Detection and Response (CDR) integration. Connect an AWS cloud account with GuardDuty enabled, and Sysdig will analyze GuardDuty findings with Threat Detection Rules, and present them in your Events feed. To create and configure GuardDuty policies, see AWS GuardDuty Policy.\nEnhanced Cloud Identity InsightsSysdig has released Cloud Identity Insights, enabling easy correlattion of identity behavior with events, to detect and respond to potentially compromised users. These insight also helps teams prevent similar attacks in the future. This enhancement includes the following capabilities:\nAutomatic detection of potentially Compromised Users based on abnormal activity Ability for Incident Responders to manually confirm a Compromised User Remediation Suggestions and playbooks to Contain Compromise Risk Policies to target Riskiest Identities for Posture Hardening Least Permissive Policy Optimization that takes into account and excludes actions only taken by a malicious actor August 12, 2024New and Updated Posture PoliciesSysdig added several new Posture Policies as well as updates to existing ones, enhancing our security and compliance coverage. This release includes the following:\nBSI-Standard 200-1: Information Security Management v1.0 CIS Kubernetes V1.25 Benchmark v1.7.1 CIS Kubernetes V1.26 Benchmark v1.8.0 CIS Kubernetes V1.27 Benchmark v1.9.0 Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) Ver 4 Digital Operational Resilience Act (DORA) - Regulation (EU) 2022/2554 NIS2 Directive (Directive on measures for a high common level of cybersecurity across the Union) 2022/2555 NIST Cybersecurity Framework (CSF) v2.0 NIST Privacy Framework v1.0 Sysdig Google Cloud Benchmark v1.0.0 These new policies help organizations align with the latest industry standards and regulatory frameworks, ensuring comprehensive security and compliance management.\nAdditionally, the following Posture Policies have been updated to newest versions:\nCIS Amazon Elastic Kubernetes Service (EKS) Benchmark: Updated from v1.2.0 to v1.4.0 CIS Amazon Web Services Foundations Benchmark: Updated from v1.5.0 to v3.0.0 CIS Red Hat OpenShift Container Platform Benchmark: Updated from v1.2.0 to v1.5.0 Health Information Trust Common Security Framework (HITRUST CSF): Updated from v9.4.2 to v9.6.0 ISO/IEC 27001:2022: Updated from v1 to v3 MITRE ATT\u0026amp;CK for Enterprise: Updated from v10.1 to v13.1 These updates reflect the latest changes in industry standards, helping to maintain ongoing compliance and security.\nFor more information, see Posture Policies Included.\nHost Scanner v0.11.0 ReleasedSysdig released a new version of Host Scanner with the following improvements:\nVulnerability detection of the Go runtime included in a binary, in addition to vulnerability detection of external modules. Fixed CVE-2024-41110 Registry Scanner v0.2.73 ReleasedSysdig released a new version of Registry Scanner with the following improvements:\nAdded support for Rocky Linux. Improved the detection of Java packages through better manifest parsing. Fixed CVE-2024-41110. August 9, 2024Detect Vulnerabilities in Go RuntimeThe following agent components now offer enhanced capabilities to detect runtime vulnerabilities within the Go runtime.\nHost scanner v0.11.0 CLI scanner v1.14.0 Registry scanner v0.3.0 Cluster shield v1.3.0 This improvement allows you to identify vulnerabilities in the Go runtime included within a binary, in addition to those related to external modules. As a result, some existing pipelines that previously passed might now fail due to the detection of new vulnerabilities introduced by the improved scanning process.\nRegistry Scanner v0.3.0 ReleasedSysdig released a new version of Registry Scanner with the following improvements:\nVulnerability detection of the Go runtime included in a binary, in addition to vulnerabilities related to external modules. New Posture Policies for Bottlerocket, Rocky Linux, Ubuntu, and RHELSysdig now supports Posture Policies for Bottlerocket, Rocky Linux 9, Ubuntu 20, Ubuntu 22, RHEL 8, and RHEL 9. These new policies are designed to help you maintain security compliance across a broader range of Linux distributions.\nIn addition, we have updated the Distribution Independent Linux Benchmark to support audits for these distributions.\nFor more information, see Posture Policies Included.\nSysdig CLI Scanner v1.14.0 ReleasedThe new version of CLI Scanner addresses the following:\nVulnerability detection of the Go runtime included in a binary, in addition to vulnerabilities related to external modules. August 7, 2024Infrastructure as Code (IaC) Support for CFT and ARMSysdig now supports ARM (Azure Resource Manager) and Cloud Formation Template (CFT) within our IaC capabilities. You can now onboard Git repositories containing CFT and ARM templates, which will be automatically scanned, integrated into the Inventory, and evaluated for compliance. For more information, see IaC Supportability Matrix.\nAugust 6, 2024Download Vulnerability Scanning Results in CSV FormatVulnerability Reporting has been enhanced to include the ability to download reports in CSV format, addressing the need for easier data manipulation and sharing.\nPreviously, extracting and managing vulnerability data in CSV format required building a report from multiple images, manual copying, or using third-party tools, which could be time-consuming and prone to errors. With the new CSV download capability, you can now quickly and accurately export vulnerability data for analysis, reporting, or integration with other systems, thereby enhancing productivity and reducing the risk of data mishandling.\nFor more information, see Download Vulnerability Scanning Results in CSV Format.\nRuntime Scanner v1.7.2 ReleasedFixed CVE-2024-41110\nAugust 5, 2024New Azure Cloud Account OnboardingSysdig has improved Azure Cloud Account Onboarding experienced for Azure tenants and subscriptions. The new wizard features clearer instructions, and simplifies upgrading accounts with new Sysdig features. If you have existing tenants and subscriptions who would like to benefit from this, contact your Sysdig representative.\nFor more information, see Azure.\nSysdig CLI Scanner v1.13.2 ReleasedFixed CVE-2024-41110\nFull Custom Controls for CloudSysdig now offers the ability to create Custom Controls for CSPM via Terraform. You now can create controls from scratch by defining your own REGO code, remediation playbooks, and control severity.\nFor more information, see Create Custom Controls with Terraform.\nAugust 2, 2024Microsoft Deprecates Office 365 ConnectorsMicrosoft is deprecating Office 365 Connectors for Microsoft Teams notifications. According to the official deprecation notice, new connectors cannot be created after August 15, 2024, and existing ones will require a URL update to function after December 31, 2024. To avoid any interruption in notifications, see migrate from Office 365 Connects to Power Automate.\nJul 30, 2024Sysdig CLI Scanner v1.13.1 ReleasedVM Fixed a defect where the CLI scanner communicated with the Sysdig backend despite being configured to operate in standalone mode Improved the detection of Java packages through better manifest parsing. IACFixed an issue causing a 500 error during Infrastructure as Code (IaC) CLI scans when processing large request payloads.\nJuly 26, 2024Accept Risk for RulesSysdig now offers its Risk Acceptance capabilities for Rules with customizable risk management scopes. This enhancement allows you to extend risk acceptance in both broad and granular ways, giving you greater control over your security policies. Previously, accepted risk was scoped only for a CVE, image, or host.\nFor more information, see Accept Risk\nJuly 22, 2024Leverage Artificial Intelligence for Okta Login Anomaly DetectionSysdig extends its ML capabilities with the Okta Machine Learning (ML) policy. Use an Okta ML policy to detect anomalous Okta login events in connected Okta cloud accounts, and receive notifications when they occur. Our Machine Learning model helps you understand why an event is considered anomalous compared to the expected behavior. To learn more, see Okta ML.\nIdentify Network Exposure in InventoryThe newly added Network Exposure tab in Inventory reveals the exposure path for exposed resources. The feature supports Hosts, Workloads, and Storage resources such as AWS S3 and Azure Blob. See Use the Network Exposure Tab.\nJuly 18, 2024Sysdig CLI Scanner v1.13.0 ReleasedThe new version of CLI Scanner addresses the following:\nFixed a defect that caused the sysdig-cli-scanner to report incorrect results for files deleted inside a JAR/WAR/EAR archive Fixed a defect that caused sysdig-cli-scanner to emit redundant WARN log messages Fixed a defect that caused the sysdig-cli-scanner to generate incorrect CTAs. Recommendations are now correctly sorted by package name. July 11, 2024Layered AnalysisSysdig extends its power of container image scanning toolkit to include Layered Analysis to provide insight into image hierarchy and explore every layer. Layered analysis offers:\nImproved Ownership and Remediation: Differentiate between base image and application layers to streamline routing and remediation. The security team can update base images to newer versions, while development teams handle vulnerabilities in the application layers.\nEnhanced Investigation and Research: Browse and analyze base images and each layer individually and see the packages and vulnerabilities included in each image and layer. This helps gain insights into when and how vulnerabilities were introduced. See the exact Dockerfile command related to each vulnerability layer for a deeper understanding.\nFor information, see Layered Analysis.\nCLI Scanner v1.12.0 ReleasedThe new version of the CLI Scanner released with the following:\nSupport for Layered Analysis\nJSON output now includes layered information for the container images\nIntroduced new options: --separate-by-layer and --separate-by-image.\nSee Install CLI Scanner for more information.\nFixed CVE-2024-6104\nJuly 10, 2024Host Scanner v0.10.2 Released Fixed the defect that caused the host scanner to fail in sending the correct cloud metadata attributes to the backend. Fixed CVE-2024-24791 July 9, 2024Resource Packages in InventoryYou can now use the new Packages in the Inventory module to keep track of vulnerabilities, maintain desired state configurations, and detect unauthorized changes. See Use the Package Tab.\nJuly 01, 2024Azure Risk PolicySysdig Risks module extends its capabilities to Microsoft Azure environments:\nPublicly Exposed VM with Critical Vulnerabilities: Detects if the Azure VM is publicly exposed and was found to be vulnerable to CVEs of Critical severity. Publicly Exposed Azure Storage Account Blob Service Container: Detects if an Azure Blob Container is publicly exposed. For more information, see Risks.\nJune 25, 2024Host Scanner v0.10.1 Released Fixed the following vulnerabilities: CVE-2024-2961 CVE-2024-6104 CVE-2024-33599 CVE-2024-33600 CVE-2024-33601 CVE-2024-33602 June 24, 2024Sysdig CLI Scanner v1.11.1 ReleasedThe new version of CLI Scanner includes the fix for a defect that caused the CLI scanner to use an incorrect HTTP header when downloading the vulnerability database.\nJune 18, 2024CIEM Support for Microsoft AzureSysdig extends its CIEM solution to support Microsoft Azure, providing you with seamless identity and access management across their cloud environments. With this integration, organizations can streamline identity governance, enforce access controls, and enhance security within their Azure infrastructure. For more information, see Optimize Azure User Entitlements.\nIntroducing CSAF-VEX as the Primary Data Source for Redhat VulnerabilitiesSysdig has transitioned from using Redhat OVAL (Open Vulnerability and Assessment Language) as the primary data source for Redhat vulnerabilities to the new CSAF-VEX (Common Security Advisory Framework Vulnerability Exploitability eXchange). This change is aimed at enhancing the vulnerability matching accuracy, improving data quality, and streamlining Sysdig\u0026rsquo;s overall security processes. Here are the key changes introduced by CSAF-VEX:\nEnhanced Data Accuracy and Quality: CSAF-VEX provides more precise and comprehensive vulnerability information. The structured format ensures that data is presented consistently, making it easier to interpret and act upon.\nImproved Vulnerability Assessment: The transition to CSAF-VEX will enable more detailed vulnerability assessments, including specific exploitability information. This will allow for more informed decision-making regarding vulnerability prioritization and remediation.\nBetter Compatibility and Future-Proofing: CSAF-VEX is aligned with modern security standards and practices, ensuring better compatibility with other security frameworks and tools. This transition positions us to adapt more readily to future advancements in vulnerability management.\nJune 13, 2024Sysdig CLI Scanner v1.11.0 ReleasedThe new version of CLI Scanner addresses the following:\nFixed formatting in Infrastructure as Code (IaC) CLI scan report\nTransitioned from OVAL to CSAF-VEX for RedHat Vulnerabilities\nOVAL remains the primary datasource for Sysdig On-Prem installations ahead of version 6.13.\nJune 10, 2024OCP Registry Support for Registry ScannerRegistry Scanner v0.2.69 and above supports scanning OpenShift Container Platform Registry for vulnerabilies. For more information, see OpenShift Container Platform Registry.\nNew UI ThemesSysdig introduces new themes for the Sysdig Secure UI, featuring new colors, shapes, typefaces, and artwork in both Light and Dark modes.\nWith the introduction of the new themes, you can experience a cleaner and more contemporary user interface, enhancing the data narrative. The refined lines of the new font and the minimalist color palette aim to provide additional space for the story Sysdig wants to convey with your data.\nThe older Light and Dark themes are automatically updated to the new ones, so no action is required on your part. The previous themes will remain accessible as Light - Legacy and Dark - Legacy for the next few months.\nJune 06, 2024New Events FeedA new version of the Events Feed is now Generally Available (GA). It includes:\nEvents table: Instead of a list of events, the feed is structured as a columned table. More information is now directly surfaced in the Events feed. Interactive time chart: Spot anomalous volume in the new Events time chart. Click and drag over a timespan to view it in detail. Improved Events Detail panel: Use the Events Detail panel to dive deep into Events. Copy event details in various formats, such as Simple Text, JSON and CSV. Improved Filter: You can now use tags, and filter Events by Kubernetes, Cloud, and Host. Agentless CDR is Now Generally AvailableAgentless Cloud Detection and Response (CDR) is now generally available (GA) for all data sources:\nAWS CloudTrail GCP Audit logs Azure Activity logs Okta GitHub Microsoft Entra June 05, 2024AI Risk PolicySysdig Risks module extends its capabilities to detect workloads that contain malicious AI packages.\nAI Risk Detection: This Risk Policy identifies workloads that are exposed and contain AI packages at a minimum. It also considers optional findings that increase the risk into different risk combinations. AWS AI-Related Services Detection: Detects packages for AWS AI-related services, such as SageMaker and Bedrock. For a full list of detected packages, search for Contains AI Package Control on the UI. For more information, see Risks.\nDownload Scan Results in PDF FormatSysdig Vulnerability Management module extends its capabilities to allow you to download scan results in PDF format:\nComprehensive Reports: Access all the scan details, including summaries and findings, in single document. User-Friendly Format: The PDF is designed for clarity and ease of reading. One-Click Download: Easily download your scan report with a single click. Use the Download PDF button found across the Overview, Vulnerabilities, Content, Policies, and Detail tabs to download the desired scan result.\nMay 29, 2024Sysdig CLI Scanner v1.10.1 ReleasedThe new version of CLI Scanner fixed CVE-2024-3727.\nMay 27, 2024Package Type Condition in Vulnerability RulesSysdig introduced a new condition, Package Type, for the Vulnerabilities Severities and Threats rules. The Package Type condition distinguishes between Operating System (OS) and non-OS packages.\nThe Package Type condition requires:\nSysdig CLI Scanner v1.10.0 or above Sysdig Host Scanner v0.10.0 or above Sysdig Cluster Scanner (any version) or Sysdig Runtime Scanner v1.7.0 or above May 23, 2024Sysdig CLI Scanner v1.10.0 ReleasedThe new version of CLI Scanner addresses the following:\nFixed an issue that could generate error 500 when scanning several paths Extended severities and threats rule to support package type predicates Fixed CVE-2024-32473 May 22, 2024Runtime Scanner v1.7.0 Released Extended severities and threats rule to support package type predicates Host Scanner v0.10.0 Released Extended severities and threats rule to support package type predicates May 13, 2024HostScanner v0.9.1 ReleasedReleased HostScanner v0.9.1. Prometheus and health check servers are disabled by default in this version.\nMay 09, 2024Runtime Scanner v1.6.12 Released Fixed a defect that caused the scanner to ignore the value of CONTAINERD_SOCKET_PATH when trying to connect to ContainerD. Update dependencies to fix the following high severity vulnerabilities: CVE-2023-45288 May 02, 2024HostScanner v0.9.0 Released Improved communication with Sysdig backend by compressing body of http requests. Corrected a bug that can cause scan results to disappear for a short amount of time from the Runtime UI View. Updated dependencies to fix the following high severity vulnerabilities: CVE-2023-45288. May 01, 2024RBAC Permissions Available in Vulnerability ManagementAdministrators can now create RBAC roles and define which roles are permitted to access the Vulnerability Management, Policy, Reporting, and Risk Acceptance functions. For more information, see Custom Roles.\nApril 25, 2024CIEM Support for Google Cloud PlatformSysdig extends its CIEM solution to support Google Cloud Platform (GCP), providing you with seamless identity and access management across their cloud environments. With this integration, organizations can streamline identity governance, enforce access controls, and enhance security within their GCP infrastructure. Our goal is to empower businesses to confidently embrace GCP while maintaining the principle of Least Privilege and having proper Identity Hygiene.\nFor more information, see Optimize GCP User Entitlements.\nAgentless Vulnerability Scanning AWS Agentless Host and Container Scanning is now Generally Available. For details, see AWS Scanning.\nGCP and Azure Agentless Host and Container Scanning is released in Technical Preview For details, see Agentless Scanning.\nNotes:\nResources are scanned once every 24 hours and discovery occurs every 15 minutes for new cloud hosts. Azure resources are rescanned and re-discovered every 24 hours. April 24, 2024Drift Control is Now Generally AvailableDrift control is now generally available (GA) to all workload security customers. To implement Drift Control, create a Container Drift policy. See Container Drift Policy Prerequisites.\nSupport for Volume Mounts in Drift ControlWith agent version 13.1.0., Container Drift policies can detect drift events on volume binaries. You can add or modify new executables outside the monitored resource, making drift difficult to detect. Now, when executables are modified within a monitored resource, it is treated as drift. See Detect | Volume Binaries.\nIn Agent version 13.1.1, it is enabled by default.\nIn v13.1.0, add the following configuration to the dragent.yaml file:\ndrift_deny_execution_from_volumes: true Detect Threats in Microsoft Entra IDSysdig extends its Cloud Detection and Response (CDR) coverage to Microsoft Entra ID, supplementing Okta as an additional solution for Identity and Access Management (IAM).\nOnce you connect your Azure tenant, Sysdig will also connect to Entra, and monitor it with dedicated policies and rules, maintained by Sysdig Threat Research Team (TRT).\nAs with other sources powered by Falco, Sysdig supports customization for Entra ID threat detection.\nApril 22, 2024Sysdig CLI Scanner v1.9.2 ReleasedThe new version of CLI Scanner addresses the following:\nFixed a defect to scan helm chart with kubeVersion set Fixed a defect that could make the sysdig-cli-scanner display a wrong pullstring when retrieving the image with the containers-storage loader April 16, 2024Inventory Vulnerabilities CVE PanelWhen viewing resource vulnerabilities in Inventory, you can now select a CVE to open a detailed panel. Here, you can take action to create a Jira ticket, accept risk, and learn more about the CVE in question. See Use the Resource Vulnerabilities Tab.\nApril 09, 2024Sysdig CLI Scanner v1.9.1 ReleasedThe new version of CLI Scanner addresses the following:\nFixed an issue that could cause the component to print \u0026ldquo;Failed to GetDriver graph overlay\u0026rdquo; error in the output Fixed the following vulnerabilities: CVE-2023-45288 CVE-2024-1753 CVE-2024-24557 CVE-2022-4123 Report Runtime Container InformationSysdig has extended reporting capabilities for runtime container to include raw or bare containers that are not part of Kubernetes clusters, ensuring comprehensive visibility and management of vulnerabilities across your containerized environments.\nThe new Runtime Container entity type includes all the assets that are also available in the Runtime View with the filter asset.type = container.\nFor more information, see Runtime Containers\nApril 04, 2024Enhanced Vulnerability Scanning ToolsSysdig has extended the vulnerability scanning capabilities by introducing the following:\nInstant Scans: Scan your images instantly with the Scan Now button. Registry Credential Management: Easily onboard your private registries by adding your registry credentials. For more information, see Scan Now.\nGCP and Azure Validation for Cloud AccountsSysdig has released automatic validation that covers the permissions, configurations, and resources essential for CSPM and CDR functionalities on both clouds, as well as CIEM for GCP. This check runs every 24 hours to ensure your GCP and Azure cloud accounts are connected and set up correctly.\nFor details, see Cloud Accounts | Validate Account Connection for GCP and Azure.\nEnhanced Risk FindingsSysdig has launched a Findings tab within the Risk feature. Select an affected resource from the Risk page to open the drawer where this new tab lives. It helps you understand all the resources involved in a specific Risk and their findings.\nSysdig also highlights the highest-impact findings and suggests fixes to reduce the most risk with the least effort.\nFor details, see Risks - Review Affected Resource.\nMarch 27, 2024Create and Edit Posture ControlsYou can now create custom controls by duplicating a control and editing its parameters. Custom controls can be used in custom Posture policies and can be edited or deleted as needed. This feature is available for all teams with the permission Posture Controls: Edit See Manage Posture Controls for details.\nMarch 26, 2024Added CIEM to the AWS Onboarding WizardSysdig has launched an improved onboarding experience for CIEM when connecting AWS Cloud Accounts. Users can now enable CIEM as part of the wizard. Sysdig then guides them through the installation process step-by-step, ensuring a seamless and personalized experience.\nFor details, see Connect Cloud Account | AWS.\nMarch 22, 2024Host Scanner v0.8.0Sysdig released Host Scanner v0.8.0 offering support for platform scanning and addressing the following issues:\nFixed a memory leak that could happen when disabling platform scanning Fixed an issue that could potentially cause memory spikes Fixed an issue that could cause the host-scanner to detect the operating system incorrectly when running as a binary March 19, 2024CISA KEVYou can now check if a vulnerability, reported by pipeline, registry, or runtime scanning, is registered in the CISA KEV catalog and filter images by CISA KEV. This allows you to view details such as the date added and due date for CISA KEV vulnerabilities. Drill down into scan results to view the CISA KEV information associated with an image. For more information, see Key Vulnerability Management Terminology.\nPlatform-Based ScanningSysdig has extended the Vulnerability Management scanning capabilities to conduct platform scanning by default. The scanning tools analyze images and host filesystems to extract the Software Bill of Materials (SBOM) and send them to the Sysdig backend for evaluation. Vulnerability matching and policy evaluation now occur within the Sysdig platform rather than on the client side.\nPlatform-based scanning aims to optimize computing resources, conserve data transfer, improve response time by eliminating client-side evaluation of images, and enhance the robust tracking of images across the user environment. For more information, see Platform-Based Scanning.\nImproved GCP Cloud Account OnboardingSysdig has launched an improved onboarding experience for GCP Cloud Accounts. Users can specify their installation preferences regarding desired features. Sysdig then guides them through the installation process step-by-step, ensuring a seamless and personalized experience.\nIn addition, Sysdig’s Agentless CDR now supports threat detection on GCP. By leveraging Falco and its constantly updated rules managed by the Sysdig Threat Research Team, as well as custom rules tailored to specific environments and security requirements, users can connect their GCP accounts effortlessly while benefiting from robust event processing.\nFor details, see Connect Cloud Accounts | GCP.\nMarch 15, 2024Global Service AccountsSysdig has extended the functionality of team-based service accounts with global service accounts. Unlike team-based service accounts, global service accounts can perform actions that require system level permissions. Admins can create a global service account through the API. See Global Service Accounts\nMarch 11, 2024Risks Module Released in Technical PreviewWe are excited to release Risks in Technical Preview. The Risks feature correlates findings from CSPM, KSPM, cloud log ingestion, CIEM, Vulnerability Management, and Agent-Based Threat Detection. By combining the most critical security issues, we prioritize the biggest risks for security teams to focus on.\nFor details, see Risks.\nKill Process in WorkloadIn Threat Detection Policies, Workload and List Matching policies can now be configured to kill the event-triggering process. For details, see Workload.\nSysdig CLI Scanner v1.9.0 ReleasedSysdig released the new version of CLI Scanner with the following enhancements:\nGeneral Fixed CVE-2024-24786 IaC Fixed an error occurred during Terraform directory scanning\nFixed an defect on severity threshold flag\nEnhanced the CLI Scanner to return exit code 1 when violations exceed threshold\nVM Added support for Chainguard Wolfi Improved the CLI Scanner to avoid policy failure if the solution date is absent. March 7, 2024Improved Azure Cloud Account OnboardingSysdig has launched an improved onboarding experience for Azure Cloud Accounts. Users can specify their installation preferences regarding desired features. Sysdig then guides them through the installation process step-by-step, ensuring a seamless and personalized experience.\nIn addition, Sysdig’s Agentless CDR now supports threat detection on Azure. By leveraging Falco and its constantly updated rules managed by the Sysdig Threat Research Team, as well as custom rules tailored to specific environments and security requirements, users can connect their Azure accounts effortlessly while benefiting from robust event processing.\nFor details, see Connect Cloud Account | Azure.\nMarch 5, 2024Deactivate User OptionSysdig has added the ability to configure a period of inactivity for a user, after which the user is deactivated. This helps large enterprises manage users automatically rather than manually deleting users from Sysdig.\nThis feature is deactivated by default. Currently, it can be enabled via API only.\nFor details, access the API documentation under User-Deactivation.\nView Cloud Host Vulnerabilities in InventoryInventory now lets you search for vulnerable resources on your AWS and GCP cloud hosts (EC2 Instance, Compute Instance).\nFurthermore, each cloud host’s resource-360 drawer includes vulnerability findings through a new tab.\nYou can also search on Package Name-Version, Note that Azure VM Hosts are out of scope at this time. See Inventory for details.\nInventory UI UpdatesYou can now search by Host Image ID for AWS EC2 Instance and GCP Compute Instance.\nMarch 1, 2024Monitor Objects in S3 BucketsAgentless AWS Cloud Threat Detection (CDR) coverage is extended to monitor operations performed on objects stored in Simple Storage Service (S3) buckets through S3 notifications.\nAWS CloudTrail integration now supports:\nReadOnly management events (whose verb starts with Get/List/Describe) Coverage for S3 notifications to monitor S3 buckets and extend our AWS Agentless CDR coverage. For details, see the AWS Agentless instructions to connect a cloud account.\nFebruary 29, 2024Improved Overview Page in Identity and Access (CIEM)We are excited to unveil the new and improved Overview Page for Sysdig\u0026rsquo;s Identity and Access (CIEM) feature. This version offers visual dashboards and a quick view into identity risks, enabling organizations to enhance their security posture with ease.\nFor details, see Identity and Access Overview.\nFebruary 28, 2024Global Accept Risk on Posture ControlsUsers can now accept risk on a Posture control for all failing resources, including future resources, and improve compliance results at scale while managing risk.\nFor details, see Accept Risk Globally on a Control.\nFebruary 22, 2024AWS Validation for Cloud AccountsSysdig has released automatic validation that covers the permissions, configurations, and resources essential for CSPM, CDR, and Agentless Host Scanning functionalities. This check runs every 24 hours to ensure your AWS cloud accounts are connected and set up correctly.\nFor details, see Validate Account Connection for AWS.\nAlerting for Vulnerability PoliciesSysdig has introduced notification channels to enable near real-time alerting for vulnerability policies. You can now extend any vulnerability policy with a notification channel, including Slack, Email, Teams, and Webhook.\nWHAT? Ability to send and receive alerts from Sysdig in different scenarios.\nAbility to include triggers any vulnerability policy rule including vulnerability detections and root user configuration\nThe Use of the Notifications Channel aligns with other alerting in the functions in the Secure Platform\nWHY? Provides insight into failing policies in regulated zones Triggers workflows in ticketing systems Alerts the operation teams through notification channels Provides action messages on critical events For more information, see Vulnerability Policy Alerts.\nFebruary 14, 2024Registry Scanner v0.2.67 ReleasedSysdig released the new version of Registry Scanner allowing you to run the registry scanner in ARM architecture.\nLegacy Inline Scanner v 2.4.28 ReleasedAdded support for Docker version 25.\nFebruary 12, 2024Host Scanner v0.7.5Sysdig released Host Scanner v0.7.5, addressing an issue where special characters prevented the display of non-Kubernetes results in the UI. It also bumped dependencies to address the following security vulnerabilities:\nCVE-2024-21626 CVE-2023-29491 CVE-2023-29491 CVE-2023-48795 February 9, 2024Runtime Resource TypesSysdig has introduced the following new types of resources for AWS, bringing the total to 122 different supported runtime resource types:\nIAM Role Policy Attachment Lambda Function Alias Lambda Function URL Configuration Lambda Policy Lambda Provisioned Concurrency Config Infrastructure as Code (IaC) and Runtime Resource ParityAWS Parity Between IaC and Runtime Resource TypesThe parity level of IaC resources for AWS Terraform provider is now of 85%, supporting 99 different resource types.\nMicrosoft Azure Parity Between IaC and Runtime Resource TypesThe parity level of IaC resources for Microsoft Azure Terraform provider is now of 99%, supporting 57 different resource types.\nGoogle Cloud Parity Between IaC and Runtime Resource TypesThe parity level of IaC resources for GCP Terraform provider is now of 15%, supporting 32 different resource types across the following categories:\nAudit \u0026amp; Monitoring Compute Database Encryption \u0026amp; Secrets IAM Management Networking Storage High Profile ControlsHigh Profile Controls for AWSSysdig has introduced a complete set of 24 high profile controls for the following categories:\nAudit \u0026amp; Monitoring: 6 controls Database: 18 controls These controls affect the following AWS services:\nDynamoDB ElastiCache Simple Notification Service (SNS) Personalized ControlsAs part of the continuous endeavor to incorporate parameters into controls that are amenable to accepting them, 18 new controls have been personalized for the cloud. See the complete list of customizable controls.\nFebruary 7, 2024Legacy Inline Scanner v 2.4.27 ReleasedChanges Updated anchore to 0.8.1-68 (February 2024) FixesVulnerability fixes for the following high-severity CVEs:\nCVE-2018-20225 CVE-2023-49083 CVE-2023-50782 CVE-2024-21626 February 05, 2024Registry Scanner v0.2.65 ReleasedSysdig released the new version of Registry Scanner with the following fixes:\nFixed a pagination issue on Quay Registry.\nFixed the following vulnerabilities:\nCVE-2024-0567 CVE-2024-0553 CVE-2023-5363 CVE-2023-5981 CVE-2023-7104 CVE-2023-48795 CVE-2021-35937 CVE-2021-35938 CVE-2021-35939 Use Registry Scanner v0.2.65 by updating helm charts to version 1.1.30.\nCLI Scanner v1.8.3 ReleasedSysdig released the new version of CLI scanner with the following:\nAdded CISA KEV data to JSON output to indicate if the given vulnerability is included in the CISA KEV. If it is reported in the CISA KEV catalog, the JSON output provides the following:\npublishDateByVendor: When the vulnerability was added to the catalog. cisakev.dueDate: The deadline by which organizations, particularly federal agencies, are mandated to apply necessary patches or mitigations to safeguard their systems from potential exploitation. cisakev.knownRansomwareCampaignUse: Indicates whether the CISA KEV is known to have been leveraged as part of a ransomware campaign. Fixed the following vulnerabilities:\nCVE-2023-46129 CVE-2023-47090 CVE-2023-48795 January 31, 2024Container Actions and Captures added to More PoliciesSysdig agent supports the following new actions in Container Drift policies and Malware policies:\nThe ability to create capture files The ability to Kill/Pause/Stop a container Malware policies are currently in Controlled Availability. Contact Sysdig Support for access to the Malware feature.\nThese features require Sysdig Agent v12.20+.\nJanuary 24, 2024Infrastructure as Code (IaC) and Runtime Resource ParityAWS Parity Between IaC and Runtime Resource TypesThe parity level of IaC resources for AWS Terraform provider is now of 84%, supporting 94 different resource types across the following categories:\nAudit \u0026amp; Monitoring Compute Database Encryption \u0026amp; Secrets IAM Managed Services Management Networking Security \u0026amp; Compliance Storage Microsoft Azure Parity Between IaC and Runtime Resource TypesThe parity level of IaC resources for Microsoft Azure Terraform provider is now of 97%, supporting 56 different resource types across the following categories:\nAudit \u0026amp; Monitoring Compute Database Encryption \u0026amp; Secrets IAM Management Networking Storage High Profile ControlsHigh Profile Controls for AWSSysdig has introduced a complete set of 53 high profile controls for the following categories:\nAudit \u0026amp; Monitoring: 1 control Compute: 25 controls Managed Services: 5 controls Management: 2 controls Networking: 18 controls Security \u0026amp; Compliance: 2 controls These controls affect the following AWS services:\nAWS Certificate Manager (ACM) API Gateway Autoscaling CloudFront Elastic Compute Cloud (EC2) Elastic Container Service (ECS) Elastic Beanstalk Lambda Simple Notification Service (SNS) Systems Manager (SSM) Web Application Firewall (WAF) High profile controls for Microsoft AzureSysdig has introduced a complete set of 28 high profile controls for the following categories:\nAudit \u0026amp; Monitoring: 8 controls Compute: 9 controls Management: 11 controls These controls affect the following Microsoft Azure services:\nAppService Defender Monitoring Personalized ControlsAs part of the ongoing effort of adding parameters to the controls that are susceptible of accepting them, 23 controls have been personalized for cloud and Kubernetes. Please refer to the complete list of customizable controls.\nCompliance Results Show Passing CountThe Compliance Results page now includes a column to display the number of controls that are passing for each resource.\nSee Compliance for details.\nJanuary 18, 2024Data Types for Events ForwardingSysdig is happy to announce the General Availability for Activity Audit data type in Events Forwarding. Additionally, we have initiated the deprecation process for the following legacy data types:\nLegacy Runtime policy event format, replaced by the new format Legacy Compliance v1 events (Secure events compliance and Benchmark events), part of the Legacy compliance Legacy Vulnerability Scanner v1, part of the Legacy scanning engine Effective immediately, the creation of new integrations using this format is no longer possible. The removal of these integrations will be finalized when the replacement features are available across all environments, with dedicated announcements to follow.\nHost Scanner v0.7.4Sysdig released Host Scanner v0.7.4, addressing a date handling issue that prevented non-kubernetes results from appearing in the UI. The release also updated the DEBUG environmental variable to be compatible with older versions. Log level values, such as INFO, TRACE, or boolean values where true enables DEBUG level are now accepted.\nJanuary 9, 2024Filter for Updated Threat Detection RulesWe have added a new drop-down filter on the Rules Library page to easily review recent changes made to rules and exceptions.\nSee View Recent Changes to a Rule for details.\nJanuary 04, 2024Introducing Infrastructure as Code (IaC) Scanning Integration to Sysdig CLI ScannerSysdig is thrilled to announce a major advancement to the sysdig-cli-scanner tool with the integration of Infrastructure as Code (IaC) scanning functionality. This release empowers users to seamlessly scan IaC resources for potential risks and compliance issues, enhancing the security posture of your development workflows. By using the familiar sysdig-cli-scanner interface, you can initiate IaC scans to identify potential risks and compliance issues early in the development lifecycle. The tool continues to support the basic functionality.\nKey Features\nA comprehensive exit code system for easy interpretation of scan results Role-Based Access Control (RBAC) for precise control over permissions Cross-platform compatibility Ability to integrate into existing workflows, such as CI/CD pipelines Use of API Token for authentication, ensuring consistency with the VM CLI Simple command execution See Run Sysdig CLI Scanner in IaC Mode for details.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/2024-archive/"},{"id":37,"title":"Serverless Agent Release Notes 2025","content":"Serverless Patcher 5.4.2 December 19, 2025Defect FixesVulnerability FixesAddressed the following vulnerabilities in Serverless Patcher:\nCVE-2025-61727 CVE-2025-61729 Serverless Agent 6.1.2 December 18, 2025Defect FixesVulnerability FixesAddressed the following vulnerabilities in the Workload Agent:\nCVE-2025-61727 CVE-2025-61729 Serverless Patcher 5.4.1 November 12, 2025Vulnerability FixesAddressed the following vulnerabilities in Serverless Patcher:\nCVE-2025-58183 CVE-2025-58185 CVE-2025-58186 CVE-2025-58187 CVE-2025-58188 CVE-2025-61723 CVE-2025-61724 CVE-2025-61725 CVE-2025-47912 CVE-2025-58189 Serverless Agent 6.1.1 November 10, 2025Defect Fixes Fixed an issue where the instrumentation did not deliver signals correctly to managed processes. Vulnerability FixesAddressed the following vulnerabilities in the Workload Agent:\nCVE-2025-58183 CVE-2025-58185 CVE-2025-58186 CVE-2025-58187 CVE-2025-58188 CVE-2025-61723 CVE-2025-61724 CVE-2025-61725 CVE-2025-47912 CVE-2025-58189 Serverless Agent 6.1.0 September 24, 2025EnhancementsStandard and FIPS-Compliant VariantsServerless Agent is now available in two variants:\nStandard: For general workloads without compliance constraints. FIPS-compliant: For improved compliance and security across regulated environments. FIPS-compliant is based on the scratch image and includes binaries and libraries grouped into two main components: Agent: Runs as a sidecar container and uses OpenSSL FIPS-validated libraries for TLS communications. Instrumentation: Performs userspace instrumentation within the operational context of the secured container. Defect Fixes Fixed an issue where the workload agent failed to create directories for storing custom CA certificates. Resolved a segmentation fault triggered while collecting CPU metrics. Improved reliability and stability by hardening the workload agent to handle cases where required system calls for reading instrumented process memory are unavailable. Vulnerability FixesAddressed the following vulnerabilities in the Workload Agent:\nCVE-2025-47906 CVE-2025-47907 Serverless Patcher 5.4.0 September 16, 2025EnhancementsStandard and FIPS-Compliant VariantsServerless Patcher is now available in two variants:\nStandard: Built on a non-STIG–hardened base image. FIPS-compliant: Built on a STIG-hardened base image, providing improved compliance and security for regulated environments. Vulnerability FixesAddressed the following vulnerabilities in Serverless Patcher:\nCVE-2025-47907 CVE-2025-5702 CVE-2025-8058 CVE-2022-29458 Serverless Agent 5.3.4 July 23, 2025 This release does not include Workload Agent updates.\nVulnerability FixesAddressed the following vulnerabilities in the Orchestrator Agent:\nCVE-2024-12718 CVE-2025-4138 CVE-2025-4517 CVE-2025-49794 CVE-2025-49796 CVE-2025-6020 CVE-2024-12133 CVE-2024-12243 CVE-2024-52533 CVE-2024-8176 CVE-2024-8508 CVE-2025-0395 CVE-2025-0938 CVE-2025-24528 CVE-2025-25724 CVE-2025-3576 CVE-2025-4330 CVE-2025-4373 CVE-2025-4435 Serverless Patcher 5.3.5 July 2, 2025Vulnerability FixesAddressed the following vulnerabilities in Serverless Patcher:\nCVE-2025-4673 CVE-2025-0913 CVE-2025-4802 Serverless Agent 6.0.0 26 June, 2025 This release introduces major changes, including new defaults, and component deprecations. Review carefully, as some updates may require action.\nEnhancementsSupported Independent Container Restarts in Availability ModeThe workload agent now supports individual container restarts in availability mode without requiring a full task or instance restart. Both the Sysdig sidecar and workload containers can now restart independently without disrupting Sysdig security and observability operations.\nDeprecationsOrchestrator Agent Connectivity SunsetThe workload agent now supports only direct connections to the collector, and no longer allows connections via the orchestrator agent.\nDefect FixesVulnerability FixesAddressed the following vulnerabilities in the Workload Agent:\nCVE-2025-4673 CVE-2025-0913 CVE-2025-22874 Serverless Patcher 5.3.4 May 8, 2025Vulnerability FixesAddressed the following vulnerabilities in Serverless Patcher:\nCVE-2025-0395 CVE-2025-22871 Serverless Agent 5.5.0 May 7, 2025Defect FixesLogging improvementsImproved error messages for cases where the Workload Agent fails to instrument syscalls, making them easier to understand and troubleshoot.\nVulnerability FixesAddressed the following vulnerability in the Workload Agent:\nCVE-2025-22871. Serverless Agent 5.4.0 April 10, 2025EnhancementsGeneral Availability for Google Cloud Run SupportThe Serverless Workload Agent supports securing containers running in Google Cloud Run Service. For more information, see Cloud Run Service.\nGeneral Availability for Microsoft Azure Container AppsThe Serverless Workload Agent supports securing containers running in Microsoft Azure Container Apps. For more information, see Azure Container Apps.\nCustom CA certificates for Workload AgentThe Serverless Workload Agent supports adding custom CA certificates for secure communication with the Sysdig backend. For more information, see Add Custom CA Certificates.\nMulti-cloud serverless labels in policy eventsThe Serverless Workload Agent provides the following multi-cloud labels in policy events:\nserverless.platform serverless.revision serverless.cluster serverless.service serverless.task Defect FixesLogging improvementsLogging has been optimized to exclude messages irrelevant to serverless environments, enhancing clarity and reducing noise.\nVulnerability FixesAddressed CVE-2025-22866 in the Workload Agent.\nServerless Agent 5.3.3 April 10, 2025Vulnerability FixesAddressed the following CVEs:\nOrchestrator Agent CVE-2025-24928 CVE-2024-8176 CVE-2024-56171 CVE-2024-28835 CVE-2024-28834 CVE-2024-2236 CVE-2024-0567 CVE-2024-0553 CVE-2023-5981 Serverless Patcher 5.3.3 March 17, 2025Defect FixesInstrumentation failure with dynamically resolved image namesThe serverless-patcher can perform task instrumentation when images are dynamically defined at deployment. You must still specify the image\u0026rsquo;s original entry point and command in the template\u0026rsquo;s container definitions as mentioned in ECS on Fargate\nServerless Agent 5.3.2 February 26, 2025Defect FixesOrchestrator Agent Metadata Parsing on StartupFixed an issue where the Orchestrator Agent failed to properly parse the Network Configuration in the Task Definition, preventing it from starting correctly.\nVulnerability FixesAddressed the following CVEs:\nOrchestrator Agent CVE-2024-12797 CVE-2019-12900 CVE-2020-11023 CVE-2022-49043 Serverless Patcher CVE-2020-11023 CVE-2025-22866 Serverless Agent 5.3.1 February 03, 2025EnhancementsNew CloudFormation Templates are available for direct connection with the Sysdig backend and Orchestrator connection for the Workload Agent.\nDefect FixesFixed an issue to improve the agent stability and connection with the collector to prevent unexpected restarts.\nVulnerability FixesAddressed the following CVEs:\nOrchestrator Agent CVE-2024-11168 CVE-2024-8508 CVE-2024-9287 Workload Agent CVE-2024-45336 CVE-2024-45341 Serverless Patcher CVE-2024-45336 CVE-2024-45341 ","url":"https://docs.sysdig.com/en/release-notes/serverless-agent-release-notes/2025-archive/"},{"id":38,"title":"On-Prem Release Notes 2025","content":" Supported Web Browsers: Sysdig supports, tests, and verifies the latest versions of Chrome and Firefox. Other browsers may also work but are not tested with the same rigour. Falco Rules: You may also want to review the update log for Falco Rules. used in the Sysdig Secure Policy Editor. 7.5.0 Release, November 2025Upgrade ProcessSupported Upgrades From: 6.x, 7.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nBreaking Changes Related to Kafka \u0026amp; NATS Storage RequirementsIn v7.5.0, the default storage allocation for Kafka and NATS has been increased to 200 GB to support the newly onboarded features and enhancements, which generate additional metadata and events. As a result, it is necessary to resize the PVCs for both Kafka and NATS before initiating the Installer upgrade.\nContact Sysdig Support to open a support case for guidance and assistance with the upgrade process.\nSysdig SecureImage Signature Validation for Admission Control of Kubernetes WorkloadsSysdig Secure now supports Image Signature Validation to ensure that only trusted and verifiable container images are deployed to your Kubernetes and OpenShift clusters. This new capability, powered by Cosign, lets you enforce signature verification at admission using trusted sources like Red Hat Trusted Artifact Signer (RHTAS), GitHub + Sigstore, or a self-hosted Sigstore instance.\nAvailable starting with Cluster Shield 1.17.0, Image Signature Validation integrates with the Sysdig Admission Controller to strengthen supply chain security by preventing unsigned or tampered images before they reach your critical environments.\nFor more information, see the Image Signature Validation Policy.\nVulnerability Risk Acceptance on Packages and Package PathsSysdig Vulnerability Management now supports granular risk acceptance on packages. You can now accept risk for:\nSpecific package versions All versions of a given package A package (or version) within a specific path A package (or version) on any path This enhanced flexibility allows you to accept risk for known and managed packages in your environment, either universally or for targeted locations. By enabling precise control over which packages and paths are accepted, teams can significantly reduce alert noise and focus remediation on the vulnerabilities that matter most.\nFor more information, see Risk Acceptance for Vulnerability Management.\nKubernetes Response ActionsSysdig released new Kubernetes Response Actions, expanding your ability to investigate, respond to security events and contain threats in Kubernetes. The following actions are now available in the Sysdig UI and APIs:\nNetwork Isolate Delete Pod Rollout Restart Get Kubernetes Logs Volume Snapshot For more information, see Response Actions.\nImproved Zones Filtering and UISysdig has improved the Zones experience, making it easier to create a Zone, and reducing the potential for confusion during scope configuration.\nWhen configuring a Zone, the new All Resources toggle lets you choose between complete inclusion or granular selection of resources, tags, or custom labels within your platforms. When it is toggled off, the UI now guides you through selecting a key, choosing an operator (in or contains), and entering values for each filter, ensuring your intent is clear and reducing errors. This makes it easy to include everything or focus only on selected subsets.\nOn the backend, Sysdig has improved how zones work. Kubernetes attributes such as Resource Distribution, Cluster, Namespace, Custom Labels, now apply to Kubernetes events in Detection \u0026amp; Response and to agent-based findings in Vulnerability Management.\nFor more details, see Create and Configure a Zone.\nSysdig PlatformAutomations Execution HistoryYou can now review the success and failure of every step of your Automations. Open the Executions tab in a created Automation to explore the history of each of the actions that you have configured.\nFor more details, see Automations - Executions.\nSysdig MonitorPrometheus API AccessSysdig Monitor now supports access to a Prometheus-compatible public API. Use this API to query and ingest metrics programmatically using familiar Prometheus endpoints.\nFor a list of supported endpoints and required permissions, see Prometheus API Endpoint Support.\n7.3.1 Hotfix Release, August 2025Upgrade ProcessSupported Upgrades From: 6.x, 7.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nDefect FixesThis hotfix fixes an issue with Neo4j installations when deployed in non-default custom namespaces.\n7.4.0 Release, August 2025Upgrade ProcessSupported Upgrades From: 6.x, 7.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation. If you are currently using on-prem version below v6.15.x and plan to upgrade to v7.4.0, ensure that you have first upgraded to any on-prem version up to v7.2.x before upgrading to v7.4.0.\nSysdig PlatformHelm Values RestructuringAs of this release v7.4.0, we’ve restructured the values.yaml file used in our Helm charts to improve clarity, modularity, and maintainability. This includes:\nClear separation of global and service-level configurations Removal of duplicate or redundant values Enhanced consistency across all configuration sections These changes affect both internal Helm charts and customer-provided user.values.yaml files. To make the transition easier, a new Installer migrate-values command will help migrate existing user.values.yaml to the new structure. Please Contact Sysdig Support to open a support case for guidance and assistance with the upgrade process.\nIP AllowlistYou can now control which IP ranges/IP addresses are allowed to access your Sysdig UI/API. For more details, see IP Allowlist.\nSysdig SecureKubernetes Security Posture Management (KSPM)You can now use Kubernetes Security Posture Management (KSPM), enabling posture assessment and compliance monitoring directly within your On-premises Kubernetes clusters. This feature allows users to evaluate configuration risks and monitor compliance across their infrastructure.\nThe KSPM module checks selected controls from various compliance standards, and compiles and reports the findings enabling the following:\nAutomated checks based on CIS Benchmarks for Kubernetes, Docker, and supported Linux distributions. Predefined assessments for regulatory frameworks (e.g., PCI-DSS, NIST, ISO 27001). Policy management, posture dashboards, and findings drill-down by cluster, node, and workload. Compliance reporting tools for audit and governance use cases. See the list of supported benchmarks and standards\nAdmission ControllerAdmission Controller is a Kubernetes-native component that evaluates resource creation requests after they are authenticated and authorized, but before they are deployed to the cluster. It applies real-time security policies from posture controls to image scanning rules to block non-compliant workloads at deploy time and enables a shift-left approach by preventing risky configurations and vulnerable images from reaching production. This reduces runtime exposure and strengthens security posture across Kubernetes environments.\nAdmission Controller enables multiple layers of security checks across runtime security, audit logging, and posture management with the following features:\nDeploy-Time Image Scanning: Admission Controller integrates with scan policies to evaluate images at deployment time, blocking workloads that use images with CVEs, misconfigurations, or policy violations. Workloads are rejected before scheduling to a node, eliminating unnecessary risk. Kubernetes Audit Logging: This feature enables Audit Detections to record API-level admission decisions, including who attempted deployments, when, and why actions were allowed or blocked. This provides a complete audit trail for security investigations and policy tuning. See also: Kubernetes Audit Logging. Kubernetes Posture Enforcement: This feature applies posture policies to define best practices, such as preventing privileged containers, enforcing non-root users, or applying resource limits. The Admission Controller evaluates these policies during admission and blocks non-compliant deployments. You can assign different policies per Zone to account for environment-specific constraints (for example, staging versus production). Once enabled, you can use Admission Controller to integrate Kubernetes Security Posture Management (KSPM) and Vulnerability Management (VM) into your deployment workflows. For more details, see Install and Configure Admission Controller.\nExpanded Operator Support for Vulnerability Management PoliciesYou can now filter Vulnerability Management policies with operators for granular control and flexibility in crafting precise policies across your pipeline, registry, runtime, and admission control surfaces.\nPipeline \u0026amp; Registry now support starts with, is, is not, contains, and not contains. Runtime now supports starts with, is, is not, contains, and not contains. Drift Detection Policy EnhancementsSysdig has updated the Drift Detection Policy (formerly known as the Container Drift Policy) with enhancements to optional rules and event descriptions.\nThe Drift Detection Policy supports three optional rules:\nDetect Binary Drift: Detects binaries added or modified after container deployment. Detect Volume Drift: Detect all binaries originating from mounted volumes. To enable this rule independently of Detect Binary Drift, you need shield version 14.0+. For details, see Policy Rules. Block Prohibited Binary Execution: Blocks execution of detected drifted binaries Requires agent version 13.2.0+. Drift Detection Policy events now detail the precise reason they were created. For example, which rule triggered the event.\nThese improvements let you fine-tune your Drift Detection policies, and offer your security and operation teams greater transparency into the drifted binaries, containers and volumes in your environments, ensuring faster investigation and response.\nFor more details, see Configure a Drift Detection Policy.\n7.3.0 Release, June 2025Upgrade ProcessSupported Upgrades From: 6.x, 7.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig PlatformMulti-Factor AuthenticationYou can now enable Multi-Factor Authentication (MFA) to add an additional layer of validation to your Sysdig login. Once enabled, each login to Sysdig Monitor or Sysdig Secure must be validated with an authenticator app, such as Okta Verify or Google Authenticator. This improves your login security.\nFor more details, see Multi-Factor Authentication.\nSysdig SecureResponse ActionsYou can now respond to Runtime events using the following Response Actions:\nKill/Stop/Pause container Kill process File acquire File quarantine With the required permissions, you can execute response actions actions from the Events Feed. This enables you to contain threats and gather information to support investigations. Some response actions can even be reverted if taken by mistake, or as a temporary counter-measure. To use response actions, update your agents to version 13.9 or above and configure them accordingly. See Response Actions for more details.\nVulnerability Management ImprovementsSysdig Secure introduces significant improvements to Vulnerability Management with an updated vulnerability database and the following enhancements:\nWindows Container Image Support: CLI Scanner now supports scanning Windows container images. Host Shield v0.7 adds Windows host support. Broader OS Coverage: Vulnerability Management now supports PhotonOS and SUSE across all major scanners. Improved Matching Accuracy: Enhanced handling of complex version formats and RHEL-specific packaging reducing false positives and negatives. Reduced False Positives on CentOS: Improved alignment with RHEL advisories significantly reducing noise in scan results. Improved Performance: The updated database is approximately 40% smaller than the previous database, lowering memory and compute usage for faster, more efficient scans. The updated database is fully integrated with Cluster Shield, Host Scanner, and Registry Scanner components. To take advantage of these improvements using the CLI Scanner, ensure you\u0026rsquo;re running version 1.22.0 or later.\n7.2.0 Release, April 2025Upgrade ProcessSupported Upgrades From: 6.x, 7.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig PlatformSysdig Documentation Hub in Airgap EnvironmentsSysdig documentation is now available through the UI for airgapped environments. Find it under the Help section of the user menu in the bottom left corner of the Secure or Monitor UI.\nSysdig SecureAutomations for Vulnerability Management Risk AcceptanceThe Sysdig Secure Automations module now supports Vulnerabilities Accepted Risks automations. This lets you create automated actions, such as sending notifications via email, Slack or MS Teams, in response to events related to Risk Acceptance in Vulnerability Management, such as:\nRisk Acceptance Created Risk Acceptance Updated Risk Acceptance Deleted Risk Acceptance Expired Risk Acceptance Expiring For more information, see Automations.\nVulnerability Management Policies Public APIThe Unified Vulnerability Management Policies are now exposed via Public API allowing you to streamline policy management across all stages: Pipeline, Registry and Runtime.\n7.1.0 Release, April 2025Upgrade ProcessSupported Upgrades From: 6.x, 7.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig SecureYARA Rules and Regex Exceptions for Malware Control PolicyYou can now utilize YARA rules, maintained by Sysdig’s Threat Research Team, to enhance the Malware Control policy’s detection capabilities. You can customize exceptions for files, processes, and hashes with Regex or exact string matching. For more information, see Malware Control Policy — Detect.\nPolicy Unification for Vulnerability ManagementYou can now create unified Vulnerability Management Policies, streamlining policy management across all stages: Pipeline, Registry and Runtime. This updates brings unified policy definitions, greater flexibility with scope filters, and expanded support for registry policies.\nThe new unified policy system is available to all users of Vulnerability Management. Existing policies remain functional, and will be automatically converted to an equivalent policy in the new unified model.\nFor more information, see Vulnerability Management Policies.\nUnified Policy Definition: Policies are now defined once with a set of rules and scope filters. These policies can apply to any or all stages: Pipeline, Registry, and Runtime. This removes the need for policy duplication and reduces complexity.\nRegistry Policy Support: Policies can now be applied to images scanned in registries, expanding coverage to all critical stages of your software development lifecycle.\nImage Name Scope for All Stages: You can now scope policies using filters, such as Image Reference (also known as Image Name or Pullstring). This gives you granular control and ensures consistency across Pipeline, Registry and Runtime.\n7.0.0 Release, February 2025Upgrade ProcessSupported Upgrades From: 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig PlatformNext Gen Sysdig API DocumentationThe Next Gen API Docs are the new and standardized documentation for both Sysdig Secure and Monitor APIs. To access them, see Next Gen API Docs.\nSysdig SecureZonesYou can now use Zones to filter the results across Vulnerability Findings and the Events feed. A zone is a collection of scopes that represent logical groupings of your infrastructure or workloads. For example, you can create a zone for your production environment, a staging environment, or a region. They allow you to scope the infrastructure based on specific attributes for Hosts, Kubernetes, Image and Git. For more information, see Zones.\nConfigurable Data Retention for Scan ResultsYou can now configure the data retention period for Pipeline and Registry scan results, up to a maximum of 90 days. For more information, See Scan Results Retention.\nAutomations for Vulnerability Findings (Technical Preview)You can use the new Sysdig Secure Automations feature to create automated actions, such as sending notifications via email and Slack, in response to conditions you specify. You can use this feature to create automations to alert on any new Vulnerability Findings. For more information, see Automations.\nThe feature is not enabled by default and requires a new Graph datastore added to the Sysdig On-Premise backend. As a result, this release may require additional hardware resources. Contact Sysdig Support to open a support case for guidance and assistance with the upgrade process.\nSysdig MonitorEnhanced IOPS \u0026amp; NFS VisibilitySysdig introduced the following metrics to enhance IOPS and NFS visibility at the filesystem mount level:\nNFS Host sysdig_host_fs_nfs_op_count sysdig_host_fs_nfs_op_request_count sysdig_host_fs_nfs_op_sent_bytes sysdig_host_fs_nfs_op_recv_bytes sysdig_host_fs_nfs_op_queue_time_us sysdig_host_fs_nfs_op_round_trip_time_us sysdig_host_fs_nfs_op_total_client_time_us NFS Container sysdig_container_fs_nfs_op_count sysdig_container_fs_nfs_op_request_count sysdig_container_fs_nfs_op_sent_bytes sysdig_container_fs_nfs_op_recv_bytes sysdig_container_fs_nfs_op_queue_time_us sysdig_container_fs_nfs_op_round_trip_time_us sysdig_container_fs_nfs_op_total_client_time_us IOPS sysdig_fs_file_total_time sysdig_fs_file_open_count sysdig_fs_file_error_total_count sysdig_fs_file_total_bytes sysdig_fs_file_in_bytes sysdig_fs_file_out_bytes For additional details, see Metrics Dictionary.\nDefect Fixes Fixed the login issue when using OpenID Connect integration. Fixed the issue with setting up a Custom Role when using LDAP integration. 6.14.3 Hotfix Release, February 2025Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nDefect FixesThis hotfix fixes an issue with setting up a Custom Role when using the lightweight directory access protocol (LDAP) integration.\n6.16.2 Hotfix Release, January 2025Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nDefect FixesThis hotfix fixes the issue with authentication when using OpenID Connect.\n6.16.1 Release, January 2025Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig SecurePlatform Audit Logs for CLI ScannerSysdig Platform Audit Logs now record the following CLI Scanner actions:\nvm-collector-write vm-policies-read vm-policies-write vm-riskacceptance-read-scanner vm-riskacceptance-read-ui vm-riskacceptance-write-ui Track Risk Acceptance Actions of UsersSysdig has enhanced its Vulnerability Management (VM) capabilities by introducing the ability to track user actions related to risk acceptance. You can now easily discover:\nWhich user created the risk Which user last updated the risk When these actions occurred These enhancement provide greater transparency and control over risk acceptance and update workflows, enabling you to manage vulnerabilities more effectively. For more information, See Accepted Risks for Vulnerabilities.\nHide Accepted RisksYou can now hide accepted risks. This lets you focus on unresolved vulnerabilities. To support this, the Sysdig Vulnerability Overview pages and the Vulnerabilities tab on the scanning result pages now include a Risk Acceptance filter. This filter help you view All Risks or Accepted Risks, or hide accepted risks by selecting Risk Not Accepted. For more information, see, Filters.\nSBOM Download ButtonYou can now download a complete Software Bill of Materials (SBOM) from your scan results in CycloneDX JSON format. For more information, see SBOM Download.\n","url":"https://docs.sysdig.com/en/release-notes/sysdig-on-premises-release-notes/2025-archive/"},{"id":39,"title":"Activity","content":"Choose your ScopeActivity offers five different Activity Views. Use one of the following options to select an activity view:\nSelect Threats to bring up the Activity Views list, where you can select your desired view.\nFrom the Activity module, click the name of the current view on the top left. A dropdown appears with the full list, where you can select your desired view.\nFindings are grouped in a hierarchical order.\nCloud User ActivityDetects events related to user activity in connected cloud accounts. The findings are grouped in the following order: User / Account / Region / Resource Category / Resource Type / Resource.\nCloud ActivityDetects events in connected cloud accounts. The findings are grouped in the following order: Account / Region / Resource Category / Resource Type / Resource.\nKubernetes ActivityDetects events in connected Kubernetes clusters, namespaces, and workloads. The findings are grouped in the following order: Cluster / Namespace / Workload / Pod.\nNode and Pod ActivityDetects events in connected Kubernetes nodes and pods, but presents them in a different order to assist visibility. The findings are grouped in the following order: Cluster / Node / Pod.\nHost and Container ActivityDetects events in connected hosts and containers. The findings are grouped in the following order: Hostname / Container.\nFor more information on the order of subheadings, see Use the Visualization Panel.\nUse the Graph PanelOn the left side of the Activity UI, you will find the graph panel. Here, a coloured visual is displayed which represents a part of your infrastructure. To switch between parts, refer back to Choose your Scope.\nThe Activity graph is designed to convey hierarchy in an intuitive way. If you have selected Node \u0026amp; Pod Activity, for example, there are three levels at play: clusters, nodes, and pods. These levels are found in the headers under the name of the current scope. The hierarchy is conveyed visually by nested circles. Small circles representing pods sit inside bigger circles representing nodes, which in turn sit inside large circles representing clusters.\nThe graph is dynamic and responsive. Click any circle to highlight it and read details from the floating panel that appears. The Activity Panel on the right will also update in accordance with your selection.\nChange TimespanTo scope by timespan, use the timeline at the bottom of the page.\nChoose your timespan by selecting presets such as three hours, (3H), one day (1D), and one week (1W). The default span is 14 days (2W).\nTo specify a custom span, click on the date range the date to open a calendar.\nActivity can display up to a maximum of 14 days or 999 events, whichever comes first.\nFilter by SeverityTo the right of the search bar, you find four severity buttons; (H)igh, (M)edium, (L)ow, and (I)nfo. Toggle the buttons to remove or include events of that severity from the results.\nTo learn more about severity, see Severity and Status.\nUse the Activity PanelThe All Activity panel is found on the right side of the Activity module for Cloud, Cloud User, Kubernetes, Node\u0026amp;Pod, and Host\u0026amp;Container. If a particular type of resource is not connected in your environment, the panel will show No Activities.\nSummary TabWhen findings are present, click Summary to see a recapitulation the data in the visualization as an ordered list. You can group findings by Rule or User \u0026gt; Rule.\nHover over a line item to see at a glance the affected containers, images, rules, and user names.\nEvents TabClick the right arrow on any rule to see it in the Events tab.\nThe Events tab replicates the Sysdig Secure Events feed. Click an entry in the time-based list to open its details. Hover over any event to see its exact location in your environment highlighted in the visualization.\nSearch | Show | Hide | ExcludeThe Search bar works in conjunction with options in the Summary tab.\nEach item in the Summary list includes the options:\nClick 🚫, exclude, to reload the visualization and exclude this entry. This can cut down on repetitious results (which, in some cases, can cause the 999-item limit to be exceeded).\nClick =, show, to add the finding to the Search bar, and to the page URL. The visualization will be targeted accordingly.\nClick !=, hide, to hide that finding from the visualization, adding the filter to the Search and the URL.\nNote that =, show, and !=, hide, do not trigger a re-fetch of data.\nAfter you exclude an entry, an Exclusions button appears at the top of the page.\nClick Exclusions to:\nView the events you have marked for exclusion. Clear All Exclusions, if desired. Tunable ExceptionsSysdig\u0026rsquo;s Runtime Policy Tuner helps reduce false positives by using rule exceptions. If there are potential exceptions that match one or more events from the same rule a {#} Tunable Exceptions button may appear in the rules summary. When clicked, a modal appears with suggestions of matching exceptions.\nExpand a rule to open the event summary, if there are available exceptions, you will see an option for Tunable Exceptions.\nClick Tunable Exceptions.\nThe exceptions modal appears.\nReview the suggested exceptions and decide whether to use them:\nCompare the Existing Values with the Suggested Values.\nAdjust the suggested values, if required.\nFor example, if the suggestion shows contains: prod-app-1 but you wanted to apply the exception to all the clusters in production, you could edit it to say contains: prod.\nReview the previously-applied exceptions, which are also displayed, to gain context for the decision.\nClick View affected policies to see all the places the rule and exception would be used.\nClick Apply, or:\nIf you do not want to manage Exceptions with Sysdig, you can view the Exception as Terraform, copy the snippet, and paste it in your Terraform file.\nYAML snippets are also available.\nBest practices for using Tunable Exceptions\nYou can also use tunable exceptions in the events tab. For more information see, Events Feed Tunable Exceptions.\nGroup by User | RuleGroup the Summary by User \u0026gt; Rule to detect outlier behavior.\nExpand the user entry to view details and click the arrow to switch to the event feed for that user, with events listed in reverse chronological order.\nCloud Activity Summary PanelFor AWS Cloud Activity, click View in Console for a link to view the data in the AWS Console\nTeam-Based Views and SharingWhen sharing activities across teams, note:\nYour team and user role influence what activities you have access to.\nThe page URL persists search and filter items, and can be shared with team members with the same level of permissions.\nSee User and TeamAdministration for more detail.\n","url":"https://docs.sysdig.com/en/sysdig-secure/threat-activity/"},{"id":40,"title":"Advanced Network Exposure Use Cases","content":"Supported Cloud ProvidersNetwork Exposure Paths by Cloud ProviderBelow are the available use cases for each cloud provider and resource type. Each use case analyzes specific network paths to determine if a resource is exposed to the internet.\nAWS Exposure Paths S3 Bucket • S3 via ACL\n• S3 via Policy\n• S3 via ACL without Account\n• S3 via Policy without Account\n• S3 via ACL without Block Configuration\n• S3 via Policy without Block Configuration\n• S3 via ACL without Account and Block Configuration\n• S3 via Policy without Account and Block Configuration\n• S3 via Policy and ACL without Account and Block Configuration EC2 Instance • EC2 via Classical Load Balancer\n• EC2 via Subnet\n• EC2 via ELBV2 Load Balancer Lambda Function • Lambda Edge via CloudFront\n• Lambda via Function URL\n• Lambda via ALB RDS Instance • RDS via Subnet\n• RDS via EC2 Instance API Gateway • API Gateway V1 via Stage\n• API Gateway V2 via Stage EFS File System • EFS via VPC ElastiCache Cluster • ElastiCache via EC2 Instance App Runner • AppRunner Public Endpoint\n• AppRunner with VPC Ingress via NLB Azure Exposure Paths Virtual Machine • Virtual Machine with NIC Security Group\n• Virtual Machine without Security Group\n• Virtual Machine with Virtual Network Security Group\n• Virtual Machine with All Security Groups Storage Blob • Storage Blob via Storage Account Functions/Websites • Website via Config SQL Server • SQL Server Redis Cache • Redis Cache Deployment • Deployment via Service\n• Deployment via Service and Network Policy\n• Deployment via Service and Ingress\n• Deployment via All GCP Exposure Paths Cloud Storage Bucket • Storage Bucket via IAM Config\n• Storage Bucket via IAM Config Alone\n• Storage Bucket via IAM Policy\n• Storage Bucket via IAM Policy Alone Compute Instance • Compute Instance via Network Interface Cloud SQL • Cloud SQL Instance App Engine • App Engine Public BigQuery Dataset • BigQuery Dataset via IAM Policy External Load Balancer • Global External Load Balancer Deployment • Deployment via Service\n• Deployment via Service and Network Policy\n• Deployment via Service and Ingress\n• Deployment via All IBM Cloud Exposure Paths Cloud Object Storage Bucket • Cloud Object Storage Bucket via Access Policy Virtual Server Instance for VPC • Virtual Server Instance via Network Security Group ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/advanced-network-exposure/advanced-network-exposure-use-cases/"},{"id":41,"title":"Identity and Audit Logs","content":"From the Events and Logs page you can:\nAdd a new integration Review the name and status of an integration Search, filter, and sort by: Keyword Type (currently just Okta) Status (connected/disconnected) Delete an integration Validate Account ConnectionUse the Status column to validate the connection status of your log source:\nSelect Integrations \u0026gt; Third Party \u0026gt; Identity \u0026amp; Audit Logs and select a row from the list to open a detail panel.\nReview the connection status and follow the prompts to resolve any errors or unknowns as needed.\nThe validation runs every 24 hours.\nStatus Value Description Connected Your account is successfully connected. Error There is an issue with your integration. See Troubleshooting an Okta Integration Pending The account has been recently connected, and a validation will be run within an hour. Unknown Sysdig cannot determine the current status of the account. In the case of connection errors, if you remediate them the status will be updated on the page when the validation is run again, up to 24 hours later.\nNext Steps Add Okta Integration ","url":"https://docs.sysdig.com/en/sysdig-secure/identity-audit-logs/"},{"id":42,"title":"Image Signature Validation Policy","content":"The Image Signature Validation policy enforces that only container images signed by trusted sources are admitted into Kubernetes Clusters. This prevents the use of unsigned or tampered images in your workloads.\nThe Sysdig Image Signature validation is powered by Cosign.\nLimitations Container Workloads scanned Agentlessly are not supported. Runtime Container Workloads post-admission are not yet supported. Registry-level enforcement and attestations are not yet supported. CLI Level enforcement and attestations are not yet supported. Current CapabilitiesAvailable Stages:Admission Control StageAn Admission Control stage and scope is specifically used with the Sysdig Admission Controller. This stage supports the following filtering in an AND fashion and can be used to Warn or Reject images that fail the policy checks. It is the only Sysdig Vulnerability Management Policy with a Warning function.\nScopes: Kubernetes Labels: kubernetes.cluster.distribution, kubernetes.cluster.name, kubernetes.namespace.name, kubernetes.node.name, kubernetes.pod.container.name, kubernetes.workload.name, kubernetes.workload.type Supported Operators: is: Single Value, is not: Single Value, in: Single Value or List, not in: Single Value or List, contains: Single Value, not contains: Single Value, starts with: Single Value Image Reference: The pullstring of the image you wish to target for the specific Registry or Repository Supported Operators: starts with: Single Value, is: Single Value, is not: Single Value, contains: Single Value, not contains: Single Value Example Use Cases Enforce that all production workloads use images signed by your CI/CD pipeline. Prevent unsigned third-party images from being deployed. Align with compliance frameworks requiring artifact signature validation. Image Signature ValidationsPublic KeyLeveraging Cosign, you can validate signatures against configured public keys.\nTo achieve this you will need to input the Public Key in standard PEM format into the Policy configuration.\nExample Key in PEM Format:\n-----BEGIN PUBLIC KEY----- MFswDQYJKoZIhvcNAQEBBQADSgAwRwJAXWRPQyGlEY+SXz8Uslhe+MLjTgWd8lf/ nA0hgCm9JFKC1tq1S73cQ9naClNXsMqY7pwPt1bSY8jYRqHHbdoUvwIDAQAB -----END PUBLIC KEY----- OIDC ProviderLevaraging Cosign, you can validate signatures issued by trusted OIDC providers (e.g., GitHub Actions, Google, or other CI/CD systems such as RHTAS).\nTo achieve this you will need to input multiple pieces of data for the policy:\nCertificate Chain in PEM format (Optional) - Used to override the Certificate Chain provided by the TUF root configured in the Sysdig Cluster Shield configuration. Example Certificate Chain in PEM Format:\n-----BEGIN CERTIFICATE----- MIIGczCCBJegAwIBAgIQDk... (Your Server Certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIF7jCCA9mgAwIBAgIQ... (Intermediate Certificate 1) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIF7jCCA9mgAwIBAgIQ... (Intermediate Certificate 2 - if applicable) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIF7jCCA9mgAwIBAgIQ... (Root Certificate) -----END CERTIFICATE----- OIDC Issuer - The OIDC issuer of the Image Signature e.g. https://github.com/login/oauth Accepts Regexp format supported by Cosign e.g. ^https://token.actions.githubusercontent.com$ or https://github.com.* or https://keycloak-route-name.apps.cluster-domain.example.com.* Supports OIDC Issuers (GitHub, Keycloak, Google OAuth, AWS STS, Microsoft Entra ID, etc.) so long as cosign verify is compatible with that issuer. Certificate Identity - The identity of the issuer e.g. john.smith@sysdig.com Accepts Regexp format supported by Cosign e.g. ^https://github.com/my-org/my-repo/.github/workflows/build.yml@refs/heads/main$ or ^https://github.com/my-org/.* or '^system:serviceaccount:my-namespace:my-service-account$' or ^user@example.com$ Integration GuidesThe Image Signature Validation Policy can integrate with multiple signing and verification sources depending on your organization’s environment and trust model.\nRefer to the following guides for setup instructions specific to each integration type:\nIntegration Type Description Link Red Hat Trusted Artifact Signer (RHTAS) Use a Red Hat–supported Sigstore deployment to verify images signed within Red Hat or OpenShift environments. How to Integrate with RHTAS GitHub + Sigstore Verify images signed by GitHub Actions workflows using Sigstore’s public Fulcio and Rekor services. How to Integrate with GitHub + Sigstore Self-Hosted Sigstore Integrate with your organization’s private Sigstore stack (Fulcio, Rekor, and TUF) for internal OIDC or key-based signing. How to Integrate with a Self-Hosted Sigstore This list is not exhaustive. Sysdig supports verification through any standard Cosign mechanism as long as cosign verify is compatible with your signing configuration and cosign verify is compatible with that issuer.\nSignature CachingThe Sysdig Admission Controller uses a 15-minute cache to reduce registry overhead when validating image signatures.\nDuring this period, any change to an image’s signature in the registry is not immediately reflected. Deployments will continue to be allowed or rejected based on the cached signature state until the cache refreshes.\nUsing digest-pinned image references and understanding the 15-minute cache behavior ensures predictable validation, consistent security posture, and reliable deployments across environments.\nWhen This Matters Scenario Description Impact 1. Signature added or changed in registry An image without a valid signature is updated with a valid one while still cached. The Admission Controller continues to treat the image as unsigned until the 15-minute cache expires. 2. Mutable tags used in deployments Deployments use mutable tags like latest, 1, or dev that can change over time. Cached validations may not match the actual image content, potentially leading to inconsistent admission decisions. Mutable tags are not recommended in Kubernetes. Sysdig RecommendationUse immutable image references that include a digest instead of mutable tags. Digest references uniquely identify an image, ensuring reproducible deployments and consistent signature validation.\nExample:\nnginx@sha256:65fa4b21b132808d912dce4978bc4b42c0ce66d7e73c90a75f79dfe3e6058c4b Related Compensating ControlsSysdig’s KSPM controls in tandem with its Admission Controller functionality can help detect workloads using mutable or non-digest image references.\nTo help; you can create a Sysdig Posture Policy and apply it to your Kubernetes infrastructure with the following controls:\nControl Description Why It Matters What We Check Recommended Remediation Severity Container using latest image Flags workloads using the latest tag or no tag. Mutable tags can change without notice, causing version drift and inconsistent deployments. Checks:\n• spec.template.spec.containers.image\n• spec.template.spec.initContainers.image\nFails if tag ends with :latest or is missing. Use explicit versions or digests (e.g., nginx:1.25.3 or nginx@sha256:\u0026lt;digest\u0026gt;). Enforce immutability in CI/CD or admission policies. High Container using image without digest Flags workloads using images referenced only by tag (name:tag). Tag-only references can be rebuilt or replaced, breaking reproducibility and traceability. Checks:\n• spec.template.spec.containers.image\n• spec.template.spec.initContainers.image\nFails if image reference lacks a digest (@sha256:\u0026lt;hash\u0026gt;). Replace tag-only references with digest-pinned versions. Update build pipelines to include digests in manifests. High ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/policies/supply_chain_policies/image-signature-validation/"},{"id":43,"title":"Investigate","content":"Use Sysdig Investigate to perform:\nActivity Audit: Track commands, connections, and requests made to your Kubernetes API. You can view activity in the form of an interactive graph, and more details in the event feed. Captures: Create a snapshot of a moment in time of your environment. Use it to inspect activity and uncover more data. Kubernetes Audit Logging: Use Kubernetes audit log data in the Events feed and the Activity Audit. ","url":"https://docs.sysdig.com/en/sysdig-secure/threats-investigate/"},{"id":44,"title":"Install Shield on Kubernetes","content":"This section helps you install cluster shield using the shield chart\nPrerequisites Helm v3.10 and above Your agent access key Sysdig Monitor Endpoint for your Sysdig SaaS region Coverage Map Platform App Checks Java Management Extensions Prometheus StatsD EKS ✅ ✅ ✅ ✅ EKS Fargate ✅ ✅ ✅ ✅ GKE ✅ ✅ ✅ ✅ GKE Autopilot ✅ ✅ ✅ ✅ IKS ✅ ✅ ✅ ✅ Kubernetes Vanilla ✅ ✅ ✅ ✅ Mirantis (MKE) ✅ ✅ ✅ ✅ OpenShift (OCP4) ✅ ✅ ✅ ✅ Rancher (RKE2) ✅ ✅ ✅ ✅ Migrate to the Shield ChartTo migrate from previous deployments to Sysdig Shield, you must back up your deployment, uninstall the old components, and install the Sysdig Shield components with the shield Helm chart.\nBefore uninstalling, make sure to take a backup of your Sysdig deployment to preserve configurations and data. helm get values {RELEASE_NAME} -n {NAMESPACE} \u0026gt; sysdig-agent-backup.yaml Since Host and Cluster Shield replace all the components previously deployed using the sysdig-deploy chart, uninstall any existing installations before proceeding. This will prevent duplicate entity errors. To remove an existing installation, run the following command:\nhelm uninstall sysdig-agent --namespace sysdig-agent If you are doing a fresh installation, you can ignore this requirement.\nInstall Using HelmConfiguration FileTo install Host Shield and Cluster Shield, you can use the following values.yaml file:\ncluster_config: # The name of the cluster name: \u0026lt;your-cluster-name\u0026gt; sysdig_endpoint: # Sysdig Monitor instance location region region: \u0026lt;your-sysdig-region\u0026gt; # Access key for Sysdig Monitor instance access_key: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx features: monitor: app_checks: enabled: true java_management_extensions: enabled: true prometheus: enabled: true # The content of the prometheus.yaml file prometheus_yaml: {} statsd: enabled: true kubernetes_events: enabled: true kube_state_metrics: enabled: true host: # Driver for the host agent (Accepted Values: kmod, legacy_ebpf, universal_ebpf (Linux Kernel ≥ 5.8)) driver: universal_ebpf Google Kubernetes Engine (GKE) AutopilotTo deploy Host Shield and Cluster Shield on GKE Autopilot, add the following configuration to your values.yaml file:\ncluster_config: cluster_type: gke-autopilot shield chart 1.1.0 supports GKE Autopilot version 1.32.2-gke.1652000 and later.\nCustom Registries and SHA256 in GKE AutopilotThis section explains how to work with custom registries, SHA256 digests, and the Google allow list when deploying Sysdig on GKE Autopilot. It also provides a list of approved versions and SHA256 digests.\nWhy This MattersGKE Autopilot allows workloads only from approved images, verified by their SHA256 digest.\nWhen using a custom registry, you must mirror the public image (sysdig/agent-slim) without altering the digest so it matches Google’s allow list.\nMirror public image to custom registryTo mirror the public sysdig/agent-slim to your custom registry without altering the digest, you can use skopeo with the following command:\nskopeo copy --multi-arch all --preserve-digests docker://quay.io/sysdig/agent-slim:14.1.1 docker://company-registry/sysdig/agent-slim:14.1.1 Set custom registry on Shield ChartYou can use the following table or run the command below to retrieve the proper SHA256 Digest\ndocker pull quay.io/sysdig/agent-slim:latest docker inspect quay.io/sysdig/agent-slim:latest --format=\u0026amp;#34;{{index .RepoDigests 0}}\u0026amp;#34; Then update the host.image section in your values.yaml:\nhost: image: registry: your_company_registry repository: sysdig kmodule_name: agent-kmodule shield_name: agent-slim tag: sha256:1111112222233333 List of Approved Versions and SHA256 DigestsThis table is updated when Google adds new SHA256 digests to the allow list. There may be a delay of ~10 business days after a new Sysdig release before its SHA is approved.\nSysdig Shield Version SHA256 Digest Approval Date by Google 13.9.1 sha256:14860d181a8b712c4150bb59e3ba0ff4be08959e2c45376b32c8eb7ff70461f9 2025-07-11 13.9.2 sha256:0dcdb6d70bab60dae4bf5f70c338f2feb9daeba514f1b8ad513ed24724c2a04d 2025-07-11 14.0.0 sha256:9d668dc0d3fc3db783bdf4ce5c4755c355ff7b3b401b7d0ad4c087d05ba270f9 2025-07-11 14.0.1 sha256:b1f5bf4677632c715e9a5cde9af8d36dd66f5e79c80aadfd4b74dc5cc310a570 2025-07-11 14.1.0 sha256:2c6401018cfe3f5fcbd0713b64b096c38d47de1b5cd6c11de4691912752263fc 2025-07-24 14.1.1 sha256:36366b082d8d45dfe44d995830a1c0b0293cb9df9e55c6ab8c389e800596c743 2025-08-07 14.2.0 sha256:cd9f6c5588280cdb60d07264b812f6635c57557020cdd131757e1c986431cd23 2025-09-09 14.2.1 sha256:f945768cbdd0672bb635de49622d24f7eba6b170214f9af8a9c3b0f02538548c 2025-09-11 14.2.2 sha256:8b9768427392315619c9f14a365e7461bb06c0b8b606a9dfee2e87dd32380c4b 2025-10-09 14.2.3 sha256:cb2c437afde546554e04dbc018c125c6ffb60a9878ce6b45a29d769d91782c4b 2025-11-05 14.2.4 sha256:c8e6924999390de58471c2ac82b211a0207a50047a1bd15654a678f2b3d1e26e 2025-12-09 14.2.5 sha256:64b9d77bbd1bb22f97a74198144dcfea62bb5cee7629091252694e9040058035 2025-12-09 14.3.0 sha256:281da13df130813a4f00171756046ac969150d36a9b0dd32a817d41502f19fe4 2025-12-09 14.3.1 sha256:1055002e0e8f88d62d62ea77a7383d44ef33e79ed6d07d3d6431a810421d30b7 2026-01-16 14.3.2 sha256:b6028d17b917e58302a601556546739f0ecec134fbc9ceeab0042f95a9fb9b3e 2026-01-16 14.4.0 sha256:7546019a9fc55650a5d73825b2ebfcd6f49f435102c35b87249ae163cb9cf22f 2026-02-18 14.4.1 sha256:579a0fbc9c32e4263b54444b60689f2c16caa1c4f5518430f9b71566a0870bd5 2026-03-23 14.5.0 sha256:5083e00914894b6425711250bdd38ff359c449c662fa03866c15376e03c558d5 2026-04-28 14.5.1 sha256:5bf984e15b7b4c6f183e2da891dfdfa2364086d40afc9f1dad8db9cb14dce266 2026-04-28 14.5.2 sha256:bd8395584ac718449ac6e68ba62eaff7efa55b1fe68c3e2ce47a358144e5c812 2026-04-28 14.6.0 sha256:83d8a9c31de8737413ede5c262eb4e90bed8122aa3806868bb96d4544e925450 2026-05-21 Installationhelm repo add sysdig https://charts.sysdig.com helm repo update helm upgrade --install --atomic --create-namespace \\ -n sysdig \\ -f values.yaml \\ shield \\ sysdig/shield Parameters: http_proxy: Specifies the URL for the HTTP proxy server. https_proxy: Specifies the URL for the HTTPS proxy server. no_proxy: A comma-separated list of hosts or domains to bypass the proxy. For example: localhost,127.0.0.1,.my-cluster.local Additional FeaturesTo enable the additional features, edit the values.yaml file to use the following configuration:\nProxy SettingsIf your environment requires internet access through a proxy server, you can configure proxy settings in the values.yaml file. These settings ensure that Sysdig Host and Cluster Shield can communicate with Sysdig.\nAdd the following configuration under the proxy section:\nproxy: http_proxy: http://your-proxy https_proxy: http://your-proxy no_proxy: \u0026lt;comma-separated-list-of-hosts-or-domains\u0026gt; Replace http://your-proxy and the list of hosts or domains with the values appropriate to your proxy configuration.\nAdvanced SettingsYou can use the additional_settings section to configure advanced options, such as log levels, syscall filtering, and DNS detection. Sysdig recommends you use these settings with caution and contact Sysdig Support for guidance.\nFor the detailed information on configuring the shield chart, see shield.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/kubernetes/"},{"id":45,"title":"Install Shield on Kubernetes","content":"Sysdig Shield provides runtime detection and policy enforcement for Kubernetes workloads by leveraging Falco to enhance security and compliance. The Cluster Shield collects data from the Kubernetes nodes where it is installed, sending it to the Sysdig backend while synchronizing runtime policies and rules.\nFor detailed installation instructions based on your node type, see:\nSysdig Secure Shield for Linux nodes Sysdig Secure Windows Agent for Windows nodes Before installing Sysdig Shield, ensure that your system meets the following requirements.\u0026quot;\nSystem Requirements A supported distribution or Kubernetes platform.\nA Sysdig account and agent access key.\nPorts 443 and 6443 open for outbound traffic\nThe Host Shield communicates to Sysdig APIs on port 443 and with the collector on port 6443. If you\u0026rsquo;re using a firewall, make sure to open port 443 and 6443 for outbound traffic so that the Host Shield can communicate with the Sysdig APIs and collector.\nAllow traffic on port 12000 to communicate within the cluster (same namespace) for Kubernetes Security Posture Management (KSPM).\nAllow traffic on port 4222 to communicate within the cluster (same namespace) for Container Vulnerability Management.\nKubernetes Platforms Kubernetes (Vanilla)\nAmazon Elastic Kubernetes Service (EKS)\nNote: AWS Fargate is not supported on EKS\nGoogle Kubernetes Engine (GKE)\nAzure Kubernetes Service (AKS)\nRedHat Openshift\nIBM Kubernetes Service (IKS)\nRKE Government (RKE2)\nLinux Distributions Debian Ubuntu 18.04 and above Ubuntu (Amazon) CentOS 7 and above Alma Linux Rocky Linux Red Hat Enterprise Linux (RHEL) 7 and above SuSE Linux Enterprise Server* RHEL CoreOS (RHCOS) Fedora Fedora CoreOS Linux Mint Amazon Linux (Original) Amazon Linux 2 (AL2) Amazon Linux 2023 (AL2023) Amazon Bottlerocket Google Container Optimized OS (COS) Oracle Linux (UEH) Oracle Linux (RHCK) Azure Linux (CBL-Mariner) EulerOS ArchLinux Alpine Linux 3.20 and above CPU Architectures X86 ARM We support additional Linux distributions depending on the feature required.\n","url":"https://docs.sysdig.com/en/sysdig-secure/install-shield-kubernetes/"},{"id":46,"title":"Kubernetes Live","content":"Kubernetes Live is a powerful tool that assists in the response and investigation into security events, vulnerabilities, and misconfigurations in your infrastructure.\nKubernetes Live presents a live view of your infrastructure by scopes based on the hierarchy, such as cluster, namespace, and workloads. Selecting one of these scopes presents existing data from different parts of Sysdig Secure in a curated set of panels and tabs that are specific to that scope.\nKubernetes Live is in Technical Preview status for Sysdig Secure SaaS as part of the Sysdig Platform offering.\nKnown Limitations:\nNo customization: The scopes, panels, and tabs in Secure Live cannot be customized at this time Access Kubernetes LiveTo access Kubernetes Live:\nLog in to Sysdig Secure as an Administrator User. Select Inventory \u0026gt; Kubernetes Live. Navigate Kubernetes LiveKubernetes Live helps you protect your Kubernetes environment from a wide range of threats. It can be used for reactive investigation to security events or proactive highlighting images that have known vulnerabilities.\nThere are two main parts of Kubernetes Live:\nThe left pane used as the scope tree for navigating your infrastructure The right pane with security-related finding, events, and more. Left Pane Scope TreeThe scope tree has three main functionalities\nInfrastructure Layout: Provides a hierarchical structure of the infrastructure that Sysdig has secured for some period of time in the last hour period. In Kubernetes, this is all Clusters, Namespaces \u0026amp; Workloads. Panel View: Depending on the hierarchy you select, the curated tabs and panels will change to be relevant for the level you\u0026rsquo;ve selected, such as Namespace. Scope: Filters the data that will be presented in the curated tabs, such as selecting your production cluster, or default namespace. Only that data will show in the right panel. The scope tree is the live view of your infrastructure grouped by Cluster, Namespace, and Workload.\nAs pods and containers are ephemeral, you may end up having 10s or 100s of pods or containers shown in the tree that no longer exist. For that reason, the scope tree does not display pods and containers directly. The tabs and panels provide the information needed to investigate pods and containers, even if they are no longer running.\nScopingAs you move down the tree, the scopes are always additive.\nFor example, you can\u0026rsquo;t scope to a namespace without a cluster. This also includes any filters that are available in any of the tabs, it will be the scope below along with any new filter you add.\nInfrastructure Runtime Scope Cluster kubernetes.cluster.name Namespace kubernetes.cluster.name AND kubernetes.namespace.name Workload kubernetes.cluster.name AND kubernetes.namespace.name AND kubernetes.workload.name Right Pane Tabs and PanelsThe data in the tabs and panels on the right pane are sourced from many different parts of Sysdig Secure, and scoped based on the scope tree selected.\nFor example, selecting the default Namespace in your production Cluster would be similar to setting the scope in the Events feed or Vulnerability runtime to kubernetes.cluster.name = production AND kubernetes.namespace.name=default.\nThe tabs and panels are each curated with live details of your environment based on the scope selected. Some of the tabs take existing functionality and add the scoping, while some of the tabs and panels add new functionality or combine existing data into a single aggregate panel.\nOverviewOverview is the most dynamic tab based on the scope you have selected in the tree. This tab shows the high-level details about your infrastructure, such as the visibility in the number of resources that have been or are being protected.\nNew dashboards for aggregated events and vulnerabilities have been added that were not previously in Sysdig. New Mitre ATT\u0026amp;CK map that is only available in the Entire Infrastructure scope. Support for other scopes may be added in the future. EventsProvides the same functionality as the Secure Events page. Secure Live provides two main enhancements:\nThe filter has an implicit filter that is hidden based on the scope you have selected in the scope tree The quick filters at the top change based on the scope that you have selected in the scope tree. You will not see clusters if you select a cluster scope or lower, but there are New filters available the lower you go, such as container or image available in the workload scope. ImagesProvides the same functionality as the Vulnerabilities Runtime page, with an implicit filter that is hidden based on the scope you have selected in the scope tree.\nClusters, Namespaces, Workloads \u0026amp; PodsBased on the scope selected, you will see one or more of these tabs.\nNew functionality has been added to aggregate the events and metrics about the objects in the scope you have selected. If available, it will drill down into the scope of the selected resource, for example when there are multiple findings, without the user needing to select the resource from the scope tree. LogsOnly available in the Workload scope.\nLive Logs can display the tail logs for a container, which is the equivalent of running kubectl logs -f. This is useful for investigating container logs that may hint at what a workload is doing (provided there are logs with that level of detail).\nWhen selecting a workload with multiple pods or containers, choose the pod and container for which you wish to view logs. Once requested, logs are streamed for 3 minutes before the session is automatically closed. You can simply re-start streaming if necessary.\nLive logs are tailed on-demand and thus not persisted. After a session is closed they are no longer accessible.\nNetworkOnly available in the Workload scope.\nThe Network tab provides similar functionality to the existing Network Security but is meant to be used as an observability feature only. The functionality to generate a network policy is removed.\n","url":"https://docs.sysdig.com/en/sysdig-secure/kubernetes-live/"},{"id":47,"title":"Install Host Shield on Linux","content":"Host Shield consolidates the following features into one application:\nRuntime Threat Detection Host Vulnerability Scanning KSPM for the Host Rapid Response InstallationFollow specific instructions, depending on whether you are installing on Kubernetes, or as a standalone container or package on a host.\nCoverage Map OS Version Threat Detection and Response Vulnerability Management Posture Management Alibaba Linux ✅ ✅ ✅ (Partial) Alma Linux ✅ ✅ ✅ (Partial) Alpine ✅ ✅ ✅ (Partial) Amazon Bottlerocket ✅ ✅ ✅ Amazon Linux ✅ ✅ ✅ (Partial) Amazon Linux 2 ✅ ✅ ✅ Amazon Linux 2023 ✅ ✅ ✅ (Partial) Azure Linux (CBL-Mariner) ✅ ✅ ✅ (Partial) CentOS ✅ ✅ ✅ (Partial) Debian ✅ ✅ ✅ Fedora ✅ ✅ ✅ (Partial) Fedora CoreOS ✅ ❌ ✅ FlatCar ✅ ✅ ✅ Google COS ✅ ❌ ✅ (Partial) Linux Mint ✅ ❌ ✅ (Partial) Oracle Linux (RHCK) ✅ ✅ ✅ (Partial) Oracle Linux (UEH) ✅ ✅ ✅ (Partial) PhotonOS ✅ ✅ ✅ (Partial) Red Hat Enterprise Linux (RHEL, EUS) 7 and above ✅ ✅ ✅ RHEL CoreOS (RHCOS) ✅ ✅ ✅ Rocky Linux (8 \u0026amp; 9) ✅ ✅ ✅ OpenSuse ✅ ✅ ✅ SuSE Linux Enterprise Server* ✅ ✅ ✅ SuSE Linux Micro ✅ ✅ ✅ Ubuntu (Amazon) ✅ ✅ ✅ Ubuntu 18.04 and above ✅ ✅ ✅ Talos ✅ ✅ (Partial) ✅ For a complete list of Vulnerability Management Coverage please refer to our Vulnerability Feeds documentation.\n","url":"https://docs.sysdig.com/en/sysdig-secure/host-shield-linux/"},{"id":48,"title":"Install Shield on Linux Nodes","content":"You use the shield chart to install the Host and Cluster Shield components in your Kubernetes environment. In addition to providing instructions for freshly installing the shield chart, this topic also guides you through migrating from previously installed Sysdig components deployed with the sysdig-deploy chart to the Host and Cluster Shield components.\nThe shield chart deploys the Cluster Shield as a deployment and the Host Shield as a daemonset in your Kubernetes environment.\nPrerequisites kubectl installed Helm v3.10 and above Your agent access key Sysdig Secure Endpoint for your Sysdig SaaS region Review Understand Agent Drivers System Requirements A supported distribution or Kubernetes platform. Ports 443 and 6443 open for outbound traffic. Allow traffic on port 12000 to communicate within the cluster (same namespace) for Kubernetes Security Posture Management (KSPM). Allow traffic on port 4222 to communicate within the cluster (same namespace) for Container Vulnerability Management. Linux Kernel 3.10 or later. Kubernetes PlatformsThe supported Kubernetes platforms for Host Shield and Cluster Shield on Linux worker nodes are:\nKubernetes (Vanilla)\nAmazon Elastic Kubernetes Service (EKS)\nNote: AWS Fargate is not supported on EKS\nGoogle Kubernetes Engine (GKE)\nAzure Kubernetes Service (AKS)\nRedHat Openshift 4 (OCP4)\nIBM Kubernetes Service (IKS)\nRKE Government (RKE2)\nOracle Kubernetes Engine (OKE)\nLinux DistributionsThe supported Linux distributions are:\nDebian Ubuntu 18.04 and above Ubuntu (Amazon) CentOS 7 and above Alma Linux Rocky Linux Red Hat Enterprise Linux (RHEL) 7 and above SuSE Linux Enterprise Server* RHEL CoreOS (RHCOS) Fedora Fedora CoreOS Linux Mint Amazon Linux (Original) Amazon Linux 2 (AL2) Amazon Linux 2023 (AL2023) Amazon Bottlerocket Google Container Optimized OS (COS) Oracle Linux (UEH) Oracle Linux (RHCK) Azure Linux 3 EulerOS ArchLinux Flatcar Alpine Linux 3.20 and above Talos We may support additional Linux distributions depending on the feature required. For more details, Contact Sysdig Support.\nCPU ArchitecturesThe supported CPU architectures are:\nX86 ARM Coverage Map The following table shows high‑level feature coverage for Shield (Threat Detection and Response, Vulnerability Management, and Posture Management).\nPlatform Threat Detection and Response Vulnerability Management Posture Management EKS ✅ ✅ ✅ EKS Fargate ❌ ❌ ❌ GKE ✅ ✅ ✅ GKE Autopilot ✅ ✅ ✅ AKS ✅ ✅ ✅ IKS ✅ ✅ ✅ Kubernetes Vanilla ✅ ✅ ✅ Mirantis (MKE) ✅ ✅ ✅ OpenShift (OCP4) ✅ ✅ ✅ Rancher (RKE2) ✅ ✅ ✅ OKE ✅ ✅ ✅ Admission Control Support Across Kubernetes PlatformsAdmission Control is supported on a subset of the Kubernetes platforms supported by Shield. The following table summarizes the Admission Control support on Linux worker nodes:\nPlatform Admission Control support Notes EKS ✅ EKS managed node groups only. EKS Fargate is not supported. EKS Fargate ❌ Admission Control is not supported on EKS Fargate. GKE ✅ Requires API server connectivity to the Admission Controller webhook service. GKE Autopilot ✅ Supported when Shield is configured with cluster_config.cluster_type: gke-autopilot. AKS ✅ IKS / ROKS ✅ Kubernetes (Vanilla) ✅ Self‑managed Kubernetes clusters that meet the system requirements. Mirantis (MKE) ✅ OpenShift (OCP4) ✅ Linux worker nodes only. Rancher (RKE2) ✅ OKE ❌ Admission Control is currently not supported on Oracle Kubernetes Engine (OKE). Important:\nAdmission Control is supported only on Linux worker nodes for the platforms listed above. Windows worker nodes and AWS Fargate are not supported for Admission Control. Migrate to the Shield ChartSysdig introduces a new chart, shield, to install Cluster Shield and Host Shield components. If you have previously installed Sysdig components in your cluster or are considering a fresh installation, use the shield chart instead of sysdig-deploy.\nSince the Host and Cluster Shield replace all the components previously deployed using the sysdig-deploy chart, uninstall any existing installations before proceeding. This will prevent encountering duplicate entity errors.\nBefore uninstalling, make sure to take a backup of your Sysdig deployment to preserve configurations and data.\nhelm get values {RELEASE_NAME} -n {NAMESPACE} \u0026gt; sysdig-agent-backup.yaml To remove an existing installation, run the following command:\nhelm uninstall sysdig-agent --namespace sysdig-agent If you are doing a fresh installation, you can ignore this requirement.\nInstall Using HelmConfiguration FileTo install Host Shield and Cluster Shield, use the following values.yaml file:\ncluster_config: name: \u0026lt;your-cluster-name\u0026gt; # The name of the cluster sysdig_endpoint: region: \u0026lt;your-sysdig-region\u0026gt; # Sysdig Secure instance location region. Defaults to `custom` if not specified. access_key: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx # Access key for Sysdig Secure instance features: kubernetes_metadata: enabled: true # Enable Kubernetes metadata collection for the cluster posture: host_posture: enabled: true # Enable host posture assessment cluster_posture: enabled: true # Enable cluster posture assessment vulnerability_management: host_vulnerability_management: enabled: true # Enable host vulnerability management container_vulnerability_management: enabled: true # Enable container vulnerability management in_use: enabled: true # Enable retrieval of in-use packages detections: drift_control: enabled: true # Enable Drift Detection malware_control: enabled: true # Enable malware control detection file_integrity_monitoring: enabled: true # Enable FIM ml_policies: enabled: true # Enable machine learning policies kubernetes_audit: enabled: true # Enable Kubernetes audit logging investigations: activity_audit: enabled: true # Enable activity audit live_logs: enabled: true # Enable Kubernetes live logs captures: enabled: true # Enable System captures respond: response_actions: enabled: true # Enable Response Actions host: driver: universal_ebpf # Driver for the host agent (Accepted Values: kmod, legacy_ebpf, universal_ebpf (Linux Kernel ≥ 5. 8)) Google Kubernetes Engine (GKE) AutopilotTo deploy Host Shield and Cluster Shield on GKE Autopilot, add the following configuration to your values.yaml file:\ncluster_config: cluster_type: gke-autopilot shield chart 1.1.0 supports GKE Autopilot version 1.32.2-gke.1652000 and later.\nCustom Registries and SHA256 in GKE AutopilotThis section explains how to work with custom registries, SHA256 digests, and the Google allow list when deploying Sysdig on GKE Autopilot. It also provides a list of approved versions and SHA256 digests.\nWhy This MattersGKE Autopilot allows workloads only from approved images, verified by their SHA256 digest.\nWhen using a custom registry, you must mirror the public image (sysdig/agent-slim) without altering the digest so it matches Google’s allow list.\nMirror public image to custom registryTo mirror the public sysdig/agent-slim to your custom registry without altering the digest, you can use skopeo with the following command:\nskopeo copy --multi-arch all --preserve-digests docker://quay.io/sysdig/agent-slim:14.1.1 docker://company-registry/sysdig/agent-slim:14.1.1 Set custom registry on Shield ChartYou can use the following table or run the command below to retrieve the proper SHA256 Digest\ndocker pull quay.io/sysdig/agent-slim:latest docker inspect quay.io/sysdig/agent-slim:latest --format=\u0026amp;#34;{{index .RepoDigests 0}}\u0026amp;#34; Then update the host.image section in your values.yaml:\nhost: image: registry: your_company_registry repository: sysdig kmodule_name: agent-kmodule shield_name: agent-slim tag: sha256:1111112222233333 List of Approved Versions and SHA256 DigestsThis table is updated when Google adds new SHA256 digests to the allow list. There may be a delay of ~10 business days after a new Sysdig release before its SHA is approved.\nSysdig Shield Version SHA256 Digest Approval Date by Google 13.9.1 sha256:14860d181a8b712c4150bb59e3ba0ff4be08959e2c45376b32c8eb7ff70461f9 2025-07-11 13.9.2 sha256:0dcdb6d70bab60dae4bf5f70c338f2feb9daeba514f1b8ad513ed24724c2a04d 2025-07-11 14.0.0 sha256:9d668dc0d3fc3db783bdf4ce5c4755c355ff7b3b401b7d0ad4c087d05ba270f9 2025-07-11 14.0.1 sha256:b1f5bf4677632c715e9a5cde9af8d36dd66f5e79c80aadfd4b74dc5cc310a570 2025-07-11 14.1.0 sha256:2c6401018cfe3f5fcbd0713b64b096c38d47de1b5cd6c11de4691912752263fc 2025-07-24 14.1.1 sha256:36366b082d8d45dfe44d995830a1c0b0293cb9df9e55c6ab8c389e800596c743 2025-08-07 14.2.0 sha256:cd9f6c5588280cdb60d07264b812f6635c57557020cdd131757e1c986431cd23 2025-09-09 14.2.1 sha256:f945768cbdd0672bb635de49622d24f7eba6b170214f9af8a9c3b0f02538548c 2025-09-11 14.2.2 sha256:8b9768427392315619c9f14a365e7461bb06c0b8b606a9dfee2e87dd32380c4b 2025-10-09 14.2.3 sha256:cb2c437afde546554e04dbc018c125c6ffb60a9878ce6b45a29d769d91782c4b 2025-11-05 14.2.4 sha256:c8e6924999390de58471c2ac82b211a0207a50047a1bd15654a678f2b3d1e26e 2025-12-09 14.2.5 sha256:64b9d77bbd1bb22f97a74198144dcfea62bb5cee7629091252694e9040058035 2025-12-09 14.3.0 sha256:281da13df130813a4f00171756046ac969150d36a9b0dd32a817d41502f19fe4 2025-12-09 14.3.1 sha256:1055002e0e8f88d62d62ea77a7383d44ef33e79ed6d07d3d6431a810421d30b7 2026-01-16 14.3.2 sha256:b6028d17b917e58302a601556546739f0ecec134fbc9ceeab0042f95a9fb9b3e 2026-01-16 14.4.0 sha256:7546019a9fc55650a5d73825b2ebfcd6f49f435102c35b87249ae163cb9cf22f 2026-02-18 14.4.1 sha256:579a0fbc9c32e4263b54444b60689f2c16caa1c4f5518430f9b71566a0870bd5 2026-03-23 14.5.0 sha256:5083e00914894b6425711250bdd38ff359c449c662fa03866c15376e03c558d5 2026-04-28 14.5.1 sha256:5bf984e15b7b4c6f183e2da891dfdfa2364086d40afc9f1dad8db9cb14dce266 2026-04-28 14.5.2 sha256:bd8395584ac718449ac6e68ba62eaff7efa55b1fe68c3e2ce47a358144e5c812 2026-04-28 14.6.0 sha256:83d8a9c31de8737413ede5c262eb4e90bed8122aa3806868bb96d4544e925450 2026-05-21 custom Region ConfigurationIf you are using a Sysdig Secure instance in a custom region, use the following configuration:\ncluster_config: name: \u0026lt;your-cluster-name\u0026gt; # The name of the cluster sysdig_endpoint: region: \u0026lt;your-sysdig-region\u0026gt; # Sysdig Secure instance location region. Defaults to `custom` if not specified. access_key: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx # Access key for Sysdig Secure instance # When the region is `custom`, the following configuration is required. api_url: \u0026lt;your-api-url\u0026gt; # Custom Sysdig Secure API URL. collector: host: \u0026lt;your-collector-hostname\u0026gt; # Custom Sysdig Secure collector hostname. port: \u0026lt;your-collector-port\u0026gt; # Custom Sysdig Secure collector port. Installationhelm repo add sysdig https://charts.sysdig.com helm repo update helm upgrade --install --atomic --create-namespace \\ -n sysdig \\ -f values.yaml \\ shield \\ sysdig/shield The \u0026ndash;atomic flag should be replaced with \u0026ndash;rollback-on-failure when Helm 4 is used.\nParameters: http_proxy: Specifies the URL for the HTTP proxy server. https_proxy: Specifies the URL for the HTTPS proxy server. no_proxy: A comma-separated list of hosts or domains to bypass the proxy. For example: localhost,127.0.0.1,my-cluster.local Feature ManagementFeature management in Sysdig Host and Cluster Shield is handled through a values.yaml configuration file, where you can enable or disable specific features like posture, vulnerability management, admission control, and detection capabilities. Each feature has associated options, allowing customization to fit your environment\u0026rsquo;s security and compliance needs.\nFor example, you can enable host scanning with the following snippet:\nfeatures: vulnerability_management: host_vulnerability_management: enabled: true This setup activates host vulnerability scanning, allowing you to identify and address potential security risks on your cluster\u0026rsquo;s nodes.\nAdditional FeaturesTo enable the following additional features, edit the values.yaml file:\nAdmission ControllerAdmission Controller is supported on a subset of Kubernetes platforms. Before enabling it, review the Admission Control support by Kubernetes platform table in the Coverage Map section.\nAdd the following configuration to your admission_control section under features.\nfeatures: admission_control: # Enable Admission Controller enabled: true container_vulnerability_management: # Enable Container Vulnerability Management on Admission Controller enabled: true posture: # Enable Posture on Admission Controller enabled: true See Admission Controller for more details.\nNetwork SecurityAdd the following configuration to your existing investigations section under the features section.\nSee Network for details on this feature.\nfeatures: investigations: network_security: enabled: true Rapid ResponseAdd the following configuration to your existing respond section under the features section.\nfeatures: respond: rapid_response: enabled: true password: \u0026lt;password\u0026gt; Later, you can use the password you define here to Start Rapid Response.\nSee Rapid Response for details on this feature.\nFurther customizations are available in the Configuration Library.\nProxy SettingsIf your environment requires internet access through a proxy server, you can configure proxy settings in the values.yaml file. These settings ensure that Sysdig Host and Cluster Shield can communicate with Sysdig.\nAdd the following configuration under the proxy section:\nproxy: http_proxy: http://customer-proxy https_proxy: http://customer-proxy no_proxy: \u0026lt;comma-separated-list-of-hosts-or-domains\u0026gt; Cert-manager IntegrationOverviewThe Shield Helm chart supports automatic TLS certificate generation through cert-manager. When enabled, cert-manager issues and rotates the certificates required by:\nAudit Server Admission Controller (webhooks) This integration removes the need to manually create and manage TLS secrets and aligns Shield with Kubernetes-native certificate lifecycle management.\nYou can configure this behavior using the cert_manager section in values.yaml\nPrerequisitesBefore enabling cert-manager:\nBefore Enabling cert_manager configuration, an instance of cert-manager must already be installed and healthy in the cluster. Depending on your configuration, the prerequisites may vary:\nIf ca.create is false: Shield must have permission to read the TLS secret generated by cert-manager (cert-manager.io/allow-direct-injection: \u0026ldquo;true\u0026rdquo; annotation)\nIf issuer.create is false: A valid Issuer or ClusterIssuer (CA, ACME, Vault, or self-signed) must exist\nEnabling cert-manager in the Shield ChartThe cluster.tls_certificates.cert_manager block in values.yaml controls whether Shield uses cert-manager for certificate provisioning. Example configuration\ncluster: tls_certificates: cert_manager: # Enable cert-manager for certificate management enabled: true ca: # Create the CA certificate using cert-manager create: false # The template for the CA certificate secret (if create=true) # will automatically add the annotation `cert-manager.io/allow-direct-injection: \u0026#34;true\u0026#34;` if not present secret_template: {} # The name of the existing CA certificate secret (if create=false) # has to be annotated with `cert-manager.io/allow-direct-injection: \u0026#34;true\u0026#34;` secret_name: \u0026#34;\u0026#34; # The namespace of the existing CA certificate secret (if create=false) secret_namespace: \u0026#34;\u0026#34; issuer: # Create the Issuer instead of using an existing one create: false # The name of the existing issuer name: \u0026#34;\u0026#34; # The kind of the existing issuer (Issuer, ClusterIssuer) kind: Issuer # The group of the existing issuer group: cert-manager.io # Certificate duration (default: 30 days) duration: \u0026#34;720h\u0026#34; # How long before expiry to renew (default: 15 days) renew_before: \u0026#34;360h\u0026#34; Issuer Configuration ExamplesBelow is an example of a cert-manager ClusterIssuer configuration:\nSelf-signed CAGenerate a self-signed CA using the cert-manager:\napiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: selfsigned-cluster-issuer spec: selfSigned: {} --- apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: sysdig-shield-ca spec: isCA: true commonName: sysdig-shield-ca secretName: sysdig-shield-ca-secret secretTemplate: annotations: cert-manager.io/allow-direct-injection: \u0026#34;true\u0026#34; privateKey: algorithm: ECDSA size: 256 issuerRef: name: selfsigned-cluster-issuer kind: ClusterIssuer group: cert-manager.io Now use the self-signed cert you just created in the shield values.yaml:\ncluster: tls_certificates: create: true cert_manager: enabled: true ca: secret_name: \u0026#34;sysdig-shield-ca-secret\u0026#34; # secret_namespace: \u0026#34;your_namespace\u0026#34; issuer: name: \u0026#34;selfsigned-cluster-issuer\u0026#34; kind: \u0026#34;ClusterIssuer\u0026#34; Advanced SettingsYou can use the additional_settings section to configure advanced debugging options, such as log levels, syscall filtering and DNS detection. It is recommended to use these settings with caution and contact Sysdig Support for guidance.\nFor the detailed information on configuring the shield chart, see shield.\nSetting LogsThe console_priority sets the minimum log level for messages displayed in the console.\nhost: additional_settings: log: console_priority: warning # or none, debug, info, warning, error Access Key Using a Kubernetes SecretYou can use a Kubernetes Secret to pass the Sysdig access key. Store the key in a Secret and reference it in the values.yaml file using the access_key_existing_secret field.\nCreate a Kubernetes SecretRun the following command to create a secret named my-secret in the Sysdig namespace.\nkubectl create secret generic my-secret \\ --type=Opaque \\ --from-literal=access-key=\u0026lt;access-key\u0026gt; \\ -n sysdig Replace \u0026lt;access-key\u0026gt; with your Sysdig access key.\nThis command creates a Secret named my-secret in the sysdig namespace.\nConfigure Sysdig Access Key Using a Kubernetes SecretIn your values.yaml, configure the access key using the access_key_existing_secret parameter:\nsysdig_endpoint: # Sysdig accees key secret access_key_existing_secret: my-secret Cluster Shield looks for the Kubernetes Secret my-secret and extracts the access key stored under access-key.\nDynamic Syscall FilteringDynamic Syscall Filtering setting improves performance by monitoring only the system calls (syscalls) required by active components such as plugins, features, and security policies.\nConfigurationDynamic Syscall Filtering is enabled by default.\nhost: additional_settings: feature_syscalls_filtering: enabled: true # set to \u0026#39;false\u0026#39; to disable When enabled, shield automatically ignores system calls that are not needed. This reduces CPU and memory usage, especially in lightweight or high-load environments.\nFurther customizations are available in the Configuration Library.\nAdd Specific System CallsUse add_events_by_type to ensure shield always monitors specific system calls, even if they are not currently required by any feature.\nhost: additional_settings: feature_syscalls_filtering: enabled: true # Set to false to disable the feature. add_events_by_type: # List the specific syscalls of interest (optional) - recvmsg - process_vm_readv skip_events_by_typeIf the skip_events_by_type setting is used, it takes precedence over Dynamic Syscall Filtering. If a syscall is excluded due to skip_events_by_type but is required by an active feature, shield logs a warning. The warning includes the syscall name and the affected feature (such as policies or plugins). This helps troubleshoot unexpected behavior or misconfiguration.\nenrich_with_host_ipsUse enrich_with_host_ips to add the host’s IPv4 and IPv6 addresses to Threat Events. When disabled, no IP enrichment is performed.\nhost: additional_settings: enrich_with_host_ips: enabled: true # Set to false to disable. CapturesWhen using the Captures feature:\nOnly system calls required by active features are recorded by default.\nCapture files may not include all system call events unless configured otherwise.\nTo capture all system call events:\nDisable Dynamic Syscall Filtering, or\nExplicitly list required system calls using add_events_by_type\nRecommendations Sysdig recommends that you keep Dynamic Syscall Filtering enabled for performance improvements.\nUse add_events_by_type to include system calls required for custom workflows or debugging.\nDisable filtering only when full system call visibility is needed (for example, when creating complete capture files).\nBackoff on ProxyThe backoff_on_proxy_error setting controls how the agent retries connections when a proxy error occurs. Based on the type of connection failure, the agent will either retry every second or use exponential backoff with a capped delay.\nConfigurationhost: additional_settings: backoff_on_proxy_error: true When enabled, the agent uses exponential backoff to manage retry intervals. The maximum backoff interval is capped to prevent unbounded delays. This approach helps avoid overwhelming network resources while ensuring connection recovery is attempted in a controlled manner.\nSupport for Custom Container RuntimesCustom Container Runtime support (referred to as Custom Container) enables you to monitor workloads that run outside of standard container runtimes such as containerd, CRI-O, and Docker Engine, as well as other runtimes commonly used by industry-standard container orchestrators.\nUsing the Custom Container feature, you can match processes from containers running on your custom container runtimes through either of the two mechanisms, or both:\ncgroup matching Environment matching Metadata can be assigned to containers matching the cgroup or environment rules, enabling the agent to enrich the data it sends back to the collector for those containers. ConfigurationCustom Container support is disabled by default. To enable it, add the following to your shield.yaml:\nhost: additional_settings: custom_container: enabled: true limit: 50 # Maximum number of custom containers per host (default: 50, max: 150) max_id_length: 12 # Maximum container ID length (max: 100) Match by cgroupYou can use cgroups to map a process to a container. Run the following to inspect a process cgroup:\ncat /custom/\u0026lt;pid\u0026gt;/cgroup An example of a cgroup path is freezer:/docker/custom/xxxxxxx9992392abcdefxxxx.scope\nExamplehost: additional_settings: custom_container: match: cgroup: ^/custom/.* # Match any cgroup path starting with /custom/ (uses regex). container: id: \u0026lt;cgroup:1\u0026gt; # \u0026#34;:1\u0026#34; is the capture group for the container ID. For example, `/custom/xxxxxxx9992392abcdefxxxx.scope` would capture `xxxxxxx9992392abcdefxxxx` name: \u0026lt;myapp\u0026gt; image: \u0026lt;custom-app\u0026gt; The cgroup value supports regex patterns with capture groups.\nMatch by Environment VariablesYou can also match based on process environment variables:\nsudo cat /custom/\u0026lt;pid\u0026gt;/environ Examplehost: additional_settings: custom_container: match: environ: CUSTOM_CONTAINER_NAME: (.*) MY_VAR: container_([a-z]*) id: \u0026lt;cgroup:1\u0026gt; name: \u0026lt;CUSTOM_CONTAINER_NAME\u0026gt; Container MetadataAfter a process matches, the agent fills container metadata that is sent to the backend.\nKey Field Description id container.id Required. Unique identifier for the container. Must not be empty. name container.name Human-readable name. Defaults to id if not set. image container.image Application image name. Optional. Used for grouping across hosts. labels container.label.* Key–value pairs for tagging (for example, env=prod). Empty values are not sent. Metadata can be assigned to plain strings or any of the following template parameters:\nTemplated Parameter Translates to \u0026lt;cgroup\u0026gt; Full matched cgroup path. \u0026lt;cgroup:N\u0026gt; The N-th capture group of the cgroup (useful to shorten the container ID) . \u0026lt;hostname\u0026gt; Full hostname of the host running the agent (UTS namespaces not supported). \u0026lt;hostname:1\u0026gt; Hostname up to the first dot (UTS namespaces not supported). \u0026lt;ENV_VAR_NAME\u0026gt; The process’s matching environment variable, or an empty string if unset. \u0026lt;MATCHED_ENV_VAR_NAME:N\u0026gt; The N-th capture group of the given process\u0026rsquo;s matching environment variable. Incremental Metadata ScansBy default, metadata is taken only from the first process that matches the conditions, provided it has a non-empty container name. In some cases, that process may not supply all the metadata defined in the configuration. To handle this, enable custom_container.incremental_metadata = true as described below, which allows the agent to continue searching all the metadata in other matching processes:\nhost: additional_settings: custom_container: incremental_metadata: true metadata_deadline_secs: 10 # maximum time to retrieve container metadata from processes when metadata is incomplete. Defaults to `10`. ExampleWith the following sample configuration, processes that match both the cgroup and environment rules will be assigned to containers with:\nContainer ID: The cgroup path captured by the cgroup capture group Container Name: The value of the CUSTOMER_CONTAINER_NAME environment variable Container Image: A string formed by concatenating the static prefix image- with the first capture group from the MY_VAR environment variable Label: The pair name: static_string host: additional_settings: custom_container: enabled: true limit: 50 max_id_length: 50 incremental_metadata: true match: cgroup: ^/custom/(.*) environ: CUSTOM_CONTAINER_NAME: (.*) MY_VAR: container_([a-z]*) id: \u0026lt;cgroup:1\u0026gt; name: \u0026lt;CUSTOM_CONTAINER_NAME\u0026gt; image: image-\u0026lt;MY_VAR:1\u0026gt; labels: name: static_string Limitations The custom container runtime supports: Up to 150 containers per host. Container IDs up to 100 characters in length. Container-aware filters (for example, container.id, container.name) are not available in system captures. The characters \u0026lt; and \u0026gt; are reserved by the template parameters and cannot be used in container data. Any character other than ASCII letters (A–Z, a–z), digits (0–9), :, _, or . will be replaced with an underscore (_). ","url":"https://docs.sysdig.com/en/sysdig-secure/install-shield-linux-kubernetes/"},{"id":49,"title":"Linux on Kubernetes","content":"The Sysdig Helm chart sysdig-deploy includes configuration options for customizing the agent\u0026rsquo;s behavior and integrating with other Sysdig components. By using the Helm chart, you can easily deploy the Sysdig Agent on Kubernetes and take advantage of Sysdig\u0026rsquo;s powerful monitoring and security capabilities.\nIf you are migrating from previously installed Sysdig components to Cluster Shield, see Cluster Shield.\nPrerequisites Review the Installation Requirements before getting started.\nKubectl installed\nHelm v3.8 and above\nYour agent access key\nSysdig SaaS region\nFull DeployThis command installs the Sysdig Cluster Shield and the additional components to deliver runtime threat detection, host scanning, runtime image scanning, and compliance, or Kubernetes Security Posture Management (KSPM).\nIt uses the Helm chart sysdig-deploy.\nHelm values.sysdig.yaml helm repo add sysdig https://charts.sysdig.com helm repo update helm install sysdig-agent --namespace sysdig-agent --create-namespace \\ --set global.sysdig.accessKey=\u0026lt;ACCESS_KEY\u0026gt; \\ --set global.sysdig.region=\u0026lt;SAAS_REGION\u0026gt; \\ --set nodeAnalyzer.secure.vulnerabilityManagement.newEngineOnly=true \\ --set global.kspm.deploy=true \\ --set nodeAnalyzer.nodeAnalyzer.benchmarkRunner.deploy=false \\ --set nodeAnalyzer.nodeAnalyzer.hostScanner.deploy=true \\ --set global.clusterConfig.name=\u0026lt;CLUSTER_NAME\u0026gt; \\ sysdig/sysdig-deploy ## Create a values.sysdig.yaml file with the following: global: sysdig: accessKey: \u0026lt;ACCESS_KEY\u0026gt; region: \u0026lt;SAAS_REGION\u0026gt; kspm: deploy: true clusterConfig: name: \u0026lt;CLUSTER_NAME\u0026gt; nodeAnalyzer: secure: vulnerabilityManagement: newEngineOnly: true nodeAnalyzer: benchmarkRunner: deploy: false hostScanner: deploy: true ## Deploy the Chart helm repo add sysdig https://charts.sysdig.com helm install -n sysdig-agent sysdig sysdig/sysdig-deploy -f values.sysdig.yaml Runtime Threat Detection OnlyTo install only Runtime Threat Detection (Sysdig Agent), use:\nHelm values.sysdig.yaml helm repo add sysdig https://charts.sysdig.com helm install sysdig-agent --namespace sysdig-agent --create-namespace \\ --set global.sysdig.accessKey=\u0026lt;ACCESS_KEY\u0026gt; \\ --set global.sysdig.region=\u0026lt;SAAS_REGION\u0026gt; \\ --set nodeAnalyzer.enabled=false \\ --set global.clusterConfig.name=\u0026lt;CLUSTER_NAME\u0026gt; \\ sysdig/sysdig-deploy ## Create a values.sysdig.yaml file with the Following: global: sysdig: accessKey: \u0026lt;ACCESS_KEY\u0026gt; region: \u0026lt;SAAS_REGION\u0026gt; clusterConfig: name: \u0026lt;CLUSTER_NAME\u0026gt; nodeAnalyzer: enabled: false ## Then, install with the following: helm repo add sysdig https://charts.sysdig.com helm install -n sysdig-agent sysdig sysdig/sysdig-deploy -f values.sysdig.yaml Pod Security AdmissionIf you’re enforcing PSA, add the privileged policy to the sysdig-agent namespace:\nkubectl label --overwrite ns sysdig-agent pod-security.kubernetes.io/enforce=privileged Parameter DefinitionsThe command above specifies several options:\n--namespace sysdig-agent\nSpecifies that the Sysdig deployment should be installed in the \u0026ldquo;sysdig-agent\u0026rdquo; namespace. --set global.sysdig.accessKey=\u0026lt;ACCESS_KEY\u0026gt;\nSpecifies the Sysdig access key to use when connecting to the Sysdig backend. Replace \u0026lt;ACCESS_KEY\u0026gt; with your actual access key. --set global.sysdig.region=\u0026lt;SAAS_REGION\u0026gt;\nSpecifies the Sysdig region to use. Replace \u0026lt;SAAS_REGION\u0026gt; with the region where your Sysdig account is located. --set nodeAnalyzer.secure.vulnerabilityManagement.newEngineOnly=true\nEnables the new engine for vulnerability management in Sysdig Secure. --set global.kspm.deploy=true\nEnables the deployment of the KSPM Collector and Analyzer components. --set nodeAnalyzer.nodeAnalyzer.benchmarkRunner.deploy=false\nDisables the deployment of the legacy Node Analyzer Benchmark Runner component. --set nodeAnalyzer.nodeAnalyzer.hostScanner.deploy=true\nInstalls the Host Scanner. --set global.clusterConfig.name=\u0026lt;CLUSTER_NAME\u0026gt;\nSpecifies the name of your Kubernetes cluster. Replace \u0026lt;CLUSTER_NAME\u0026gt; with your actual cluster name. --set global.sysdig.tags.\u0026lt;myKey\u0026gt;=\u0026lt;myValue\u0026gt;\nOptionally, add user-defined tag by defining a Key:Value pair. Replace \u0026lt;myKey\u0026gt; with your tag key and \u0026lt;myValue\u0026gt; with your tag value. you could add multiple tags by adding another row per tag. After running these commands, the Sysdig Cluster Shield and associated components should be installed and running on your Kubernetes cluster, and will begin sending data to the Sysdig backend for analysis and monitoring.\nAbout Host ScannerThe runtime scanner and host scanner are deployed by default with the given Helm commands.\nOpting OutIf for some reason you don\u0026rsquo;t want to use host scanning, you can opt-out using the Helm chart flag:\n--set nodeAnalyzer.nodeAnalyzer.hostScanner.deploy=false Specific Kubernetes PlatformsOpenShift, GKE, OKE, and MKEIf you are using OpenShift, Google Kubernetes Engine (GKE) Standard, Oracle Kubernetes Engine (OKE), or Mirantis Kubernetes engine (MKE), enable eBPF with the following option:\n--set agent.ebpf.enabled=true GKE AutopilotIf you are using GKE autopilot, enable the following option:\n-–set agent.gke.autopilot=true Rancher Kubernetes Engine 1Rancher Kubernetes Engine V1 (RKE1) internally changes container names at the Docker layer in Kubernetes. For instance, while a container may be named nginx in your cluster, its underlying name in the Docker engine might resemble k8s_nginx_nginx_test-container-id-b277-3066f0a5-7115-48f0-bb2d-c48f71663087_9d80f7b5-1827-4a05-83. The Sysdig Agent communicates with the Docker engine to retrieve container names, and the internal names will be displayed in the Sysdig UI instead of the container name provided within the cluster.\nRancher Kubernetes Engine 2Rancher Kubernetes Engine V2(RKE2) uses a different containerd socket path, /run/k3s/containerd/containerd.sock, instead of the expected /var/run/containerd/containerd.sock. To accommodate this, ensure that you mount the alternative path into the runtime scanner via the chart\u0026rsquo;s values. This is necessary for the scanner to connect to the containerd socket and identify running containers for subsequent image scanning. Update the chart\u0026rsquo;s values accordingly.\nUsing the Key-Value Pair--set nodeAnalyzer.nodeAnalyzer.extraVolumes.volumes[0].name=socketpath \\ --set nodeAnalyzer.nodeAnalyzer.extraVolumes.volumes[0].hostPath.path=/run/k3s/containerd/containerd.sock \\ --set nodeAnalyzer.nodeAnalyzer.runtimeScanner.extraMounts[0].name=socketpath \\ --set nodeAnalyzer.nodeAnalyzer.runtimeScanner.extraMounts[0].mountPath=/var/run/containerd/containerd.sock \\ Using values.sysdig.yamlnodeAnalyzer: nodeAnalyzer: extraVolumes: volumes: - name: socketpath hostPath: path: /run/k3s/containerd/containerd.sock runtimeScanner: extraMounts: - name: socketpath mountPath: /var/run/containerd/containerd.sock Mirantis Kubernetes EngineThe Mirantis Kubernetes Engine uses Docker as its runtime, so to accommodate this, make sure you mount the Docker application path in the Agent via the chart\u0026rsquo;s values. This is necessary in order for the Agent to have malware detection and malware prevention to work properly. Update the chart\u0026rsquo;s values accordingly.\nUsing the Key-Value Pair--set agent.extraVolumes.volumes[0].name=sysdig-docker-apps \\ --set agent.extraVolumes.volumes[0].hostPath.path=/opt/apps/docker \\ --set agent.extraVolumes.mounts[0].mountPath=/host/opt/apps/docker \\ --set agent.extraVolumes.mounts[0].name=sysdig-docker-apps \\ --set agent.extraVolumes.mounts[0].readOnly=true Using values.sysdig.yamlagent: extraVolumes: volumes: - name: sysdig-docker-apps hostPath: path: /opt/apps/docker mounts: - mountPath: /host/opt/apps/docker name: sysdig-docker-apps readOnly: true Additional VolumesAdditional volumes might be required in the Sysdig Agent for mapping ConfigMaps, Secrets or additional host paths. In some specific cases, such as SLES15 on Rancher, the proper ld-linux-* library is under the host /lib64 so the kernel module build fails. To handle, add a specific volume mount /lib64 to /host/usr/lib64. For example:\nagent: daemonset: kmodule: extraVolumes: volumes: - name: lib64-vol hostPath: path: /lib64 mounts: - mountPath: /host/usr/lib64 name: lib64-vol While for the main Agent container you can specify the extraVolumes in the agent root like:\nagent: extraVolumes: volumes: - name: repo-new-cm configMap: name: my-cm optional: true - name: repo-new-secret secret: secretName: my-secret mounts: - mountPath: mount-path name: repo-new-cm - mountPath: mount-path name: repo-new-secret For additional configuration options, including on-premises or using a proxy, see the sysdig-deploy readme.\nYou can also use Helm to\nInstall Kubernetes Audit Logging (Admission Controller)\nInstall Rapid Response\nDeploy Sysdig Agent on Large Kubernetes ClustersSysdig Agent generates a significant load when running on large Kubernetes clusters to fetch the Kubernetes metadata used to enrich metrics and events. You can reduce this load with Backend Enrichment, whereby only Cluster Shield (or the delegated agent) collects the Kubernetes metadata and the data enrichment happens in the backend. We recommend you enable Backend Enrichment particularly for large clusters (\u0026gt;500 nodes), but it can be beneficial for smaller clusters too.\nEnable Backend EnrichmentBackend enrichment enablement in SaaS environments is controlled by Sysdig. Contact Sysdig Support to enable it in your environment.\nPrerequisites Linux Agent version 13.0.0 or later.\nThe Agent configuration be_enrichment.enabled set to true (default) to enable the negotiation with the Sysdig Backend.\nK8S_NODE environment variable set to the Kubernetes node name on the Sysdig Agent container. This is the default behavior when using the Sysdig Helm charts.\nSysdig strongly recommends deploying cluster-shield and enabling the kubernetes_metadata feature for sending the metadata used for backend enrichment.\nThis approach is preferred over using delegated agents.\nDeploy with Helm Charthelm install sysdig-agent \\ --namespace sysdig-agent \\ --set agent.sysdig.settings.be_enrichment=true \\ --set agent.sysdig.settings.k8s_delegated_nodes=0 \\ --set clusterShield.enabled=true \\ --set clusterShield.cluster_shield.features.kubernetes_metadata.enabled: true \\ sysdig/sysdig-deploy Additional Agent ConfigurationFor additional configuration settings, refer to the following list:\nbe_enrichment: enabled: true # Default since Agent version 13.0.0. override: true # (Optional) Enables backend enrichment mode in the Agent side regardless of the backend enablement. enforce: true # (Optional) The agent fails during the startup if backend enrichment is not enabled on the Sysdig backend side. k8s_delegated_nodes: 0 # Set the number of delegated agents to 0 when KubernetesMetadata component is used k8s_add_labels_to_container: true # (Optional) Add the extracted Kubernetes labels to containers during runtime. Useful when Local Forwarder or Audit tap are used. Setting the number of delegated nodes to 0 assumes that Cluster Shield is deployed with the Kubernetes Metadata component enabled. Advantages Offers improved scalability and performance in large Kuberentes clusters, minimizing the load the Agents put on the Kubernetes API server.\nEnhances the agent\u0026rsquo;s efficiency, particularly by reducing memory usage for caching Kubernetes metadata and minimizing egress traffic due to smaller metrics messages. The performance gain is proportional to the size and density of the cluster.\nHelps having a more uniform host agent resource consumption by eliminating the need for delegated agents.\nKnown Limitations A reduced set of Kubernetes labels is available when Local Forwarder or Audit Tap are used. ","url":"https://docs.sysdig.com/en/sysdig-secure/classic-k8s-agent/"},{"id":50,"title":"Manage Threat Detection Rules","content":"The main interface for managing Threat Detection rules in Sysdig is the Rules Library.\nThe Rules Library includes all created rules that can be referenced in policies. Out of the box, it provides a comprehensive runtime security library with specific rules developed by the Sysdig Threat Research team, Falco open source community rules, and international security benchmarks such as CIS or MITRE ATT\u0026amp;CK.\nTo access the Rules Library:\nLog in to Sysdig Secure. Select Policies \u0026gt; Rules \u0026gt; Rules Library. Explore the Rules LibraryAll available rules are displayed in a table, grouped by rule type. You can:\nFilter them using the available filters. Change the order by interacting with the columns. Expand or collapse the different groups. Open the rule details by clicking on a table row. Using the button in the top right, you can also add custom rules. See the dedicated section to learn more about this.\nFiltering rulesYou can use various filters to find rules in the Rules Library.\nThe first set of fields on the left allows you to search based on one or more values:\nRule name\nType\nUsage, defining whether a rule is Enabled in at least one policy, Disabled in all policies, or Not Used in any policy at all\nManaged Type\nMITRE Tags\nTags\nYou can also use different operators by clicking on them (=, !=, in, !in).\nUsing the second set, you can also filter by:\nNew, to find newly created rules Updated, for rules changed in the last 7 days Modified, selecting only rules that have exceptions or appends These attributes are all part of the rule detail and explained in the section about it.\nSortingBy clicking the \u0026ldquo;Type\u0026rdquo; column header, you can change the order of the groups, which is alphabetically ascending by default.\nBy interacting with the other headers, you can reorder the rules within each group. By default, rules are sorted alphabetically by name.\nOnly one sorting criterion can be applied at a time.\nReview the Rule DetailFrom the Rules Library list, select a rule to see its details, displayed in a panel on the right.\nFrom this panel, you can see 4 sections:\nRule summary, containing the main rule information and shown in the panel header:\nRule Name: The name of the rule. Type: The policy type. For example, List Matching or Kubernetes Audit. Rule ID: Used when managing the rule using APIs or Terraform. Managed Type: Indicates whether the rule was created by Sysdig (Managed) or by a user in the UI (Custom). Updated badge: Indicates that the rule has been changed recently (in the last 7 days). What, which contains:\nLast update, showing when the rule was last updated The View as Diff action, explained in the dedicated section A main body with the rule content, displayed as YAML and explained in the dedicated section The author, on the right: Secure UI, when the rule is custom or has been customized by a user Sysdig stateful, when it\u0026rsquo;s part of Sysdig\u0026rsquo;s managed behavioral analytics rules. These are managed by the Threat Research Team. In this case, an authoring version is also included, referencing a rule version as in the Behavioral Analytics changelog. Sysdig, when it\u0026rsquo;s part of Sysdig\u0026rsquo;s managed Falco rules. These are managed by the Threat Research Team. In this case, an authoring version is also included, referencing a rule version as in the Falco rules changelog. Tuner, when the rule was customized by the Sysdig Runtime Policy Tuner. See more in the dedicated page. If a rule has been extended, multiple sections will be displayed to differentiate the content managed by different authors.\nUsage, showing whether and in which policies the rule is used, and whether it\u0026rsquo;s enabled in any of them. The overall status is:\nEnabled: The rule is actively used, as it is enabled in one or more policies that are enabled. Disabled: The rule is not active. It is referenced in one or more policies, but none are active, or the rule isn\u0026rsquo;t active in any of them. Not Used: The rule is not included in any policy. You can see the details of the policies that include the rule and their status in the table below.\nTags, attached to this rule.\nYou can also find actions available in the Rule Detail:\nEdit, to review the rule content. Refer to the dedicated paragraph to understand what can be edited and how. Duplicate, to clone a rule and customize it. This copies the rule content to a new rule and is available for all rule types that can be customized. Refer to Add Rule to learn more. This is a useful action for customizing a managed rule to your needs. However, once you do this, you will need to maintain it like any other custom rule. Delete, available for custom rules. This cannot be completed if the rule is used by any policy. View rule history The rule history view is supported only on Falco rules. The feature is not available on Behavioral analytics and List matching rules.\nTo view the rule changelog:\nSelect Policies \u0026gt; Rules \u0026gt; Rules Library and select a rule.\nThe Rule Details panel opens on the right.\nIf the rule has changed, you will see a \u0026ldquo;View as Diff\u0026rdquo; button on the top right of the \u0026ldquo;What\u0026rdquo; section.\nBy default, you will see the current definition on the right and the previous on the left. Use the dropdowns to select different versions and compare the differences.\nSelect View as Default to return to the default view.\nAdd a RuleTo add a rule, you have two options:\nStart from scratch by clicking the \u0026ldquo;Add Rule\u0026rdquo; button in the top right. Clone an existing rule using the \u0026ldquo;Duplicate\u0026rdquo; function from the Rule Detail. See more in the dedicated paragraph. You can currently create custom rules in two families:\nList matching rules, including: Container File System Network Process Syscall Falco rules, including: AWS CloudTrail AWS GuardDuty Azure Platform Log GCP Audit Log GitHub Kubernetes Audit Microsoft Entra Okta Linux Workload Regardless of the selected type, you will need to provide the following details:\nName Description Tags Then, depending on the rule family and type, you will complete the rule definition. Refer to the dedicated section to learn more about it.\nEdit \u0026amp; Customize a RuleTo edit a rule:\nSelect Policies \u0026gt; Rules \u0026gt; Rules Library and select a rule.\nThe Rule Details panel opens on the right.\nFrom there, you can:\nEdit the rule definition by clicking the Edit button:\nFor a managed Falco rule, you can append a condition, append the output, create custom exceptions, or add values to existing exceptions. For a custom rule, you can edit its entire definition. In both cases, you can do this using a form that shows all the parameters in the rule definition or using the YAML format.\nFor Falco rules, edit the Lists and Macros included in the rule, which are highlighted by a grey, rounded background, by clicking on them:\nYou can append to Lists and Macros provided by Sysdig, as explained in the dedicated paragraph. You can edit custom Lists and Macros. See more in the dedicated section. For more information about the content that can be modified and how, see the Rule definition paragraph.\nWork with ExceptionsExceptions help reduce false positives and allow behaviors that should not trigger an event—either because they are expected and normal, or because they are unexpected and temporarily accepted—to reduce noise until they are addressed.\nExceptions are tied to rules. To work with them, select a rule and edit it. See the dedicated section to understand how.\nFor Falco rules, both managed and custom, you can define new exceptions or add values to existing exceptions.\nFor AWS Behavioral Analytics, you can add values to managed exceptions.\nEach exception defines the set of fields and operators that an event can be tuned with, along with values.\nExceptions can also be written in the condition in the form of and not clauses, but this would make the condition lengthy and harder to maintain.\nExceptions provide syntactic sugar to accomplish the same thing with a simpler and more straightforward structure.\nAn exception consists of:\nA name A set of fields A set of operators, one associated with each field A list called \u0026ldquo;values\u0026rdquo;, with each item containing a set of values (one per field and operator) Example:\n- name: sample_exception fields: [proc.name, container.image] comps: [=, in] values: - [my-proc, [nginx, alpine]] - [my-other-proc, [debian]] is equivalent to and not ((proc.name = \u0026quot;my-proc\u0026quot; and container.image in (\u0026quot;nginx\u0026quot;, \u0026quot;alpine\u0026quot;)) or (proc.name = \u0026quot;my-other-proc and container.image = \u0026quot;debian\u0026quot;)) in the condition\nWhen the exception evaluates to true, the rule will not trigger an event. You can read more about it in the official Falco documentation.\nTo work on exceptions, you first need to select the Falco rule for which you want to create an exception:\nSelect Policies \u0026gt; Rules \u0026gt; Rules Library and select a rule.\nThe Rule Details panel opens on the right.\nClick Edit.\nIf you\u0026rsquo;re in Form View, click Open Exception Editor. If you\u0026rsquo;re in YAML View, follow the manage rule exceptions in YAML section.\nCreate a Custom Exception Click Create Custom Exception. Define a name for the exception. Select the fields you want the exception to apply to and the corresponding operators. For each field, add a combination of values for which you don\u0026rsquo;t want the rule to trigger. Add Values to an ExceptionIf you have a predefined exception, you can add other combinations of values.\nFrom an existing exception, click the pencil icon on the right. At the bottom, select Add. Populate the values for each parameter. These parameters will define a new condition under which the rule will not produce an event.\nFalco Lists and MacrosThe default Falco rules have a variety of Macros and Lists embedded in them. These types of elements are useful for defining sets of values (lists) and common conditions (macros) that you can use in multiple rules, such as a list of trusted images or an outbound TCP connection macro.\nThe managed rules contain these elements for you to add well-known items in your environment. These elements all start with user_known, such as the user_known_ips list and the user_known_cron_jobs macro.\nA List is an element that you can reference within a comparison operation. Read more in the Falco documentation. A Macro is a logical operation and is therefore surrounded by logical operators. Read more in the Falco documentation.\nFrom the Lists and Macros pages (Policies \u0026gt; Rules \u0026gt; Falco Lists and Falco Macros), you can see all defined elements. Like the rules, elements published by Sysdig are provided, and you can only append to them. If an element is published by both Sysdig and Secure UI, it means that it has already been customized with an append, and the append can be edited. Elements published by Secure UI are custom and can be edited. Using the Add action at the top, you can add additional custom elements.\nCustomize Lists and MacrosYou can customize Lists and Macros in two ways:\nDirectly from the respective pages (Policies \u0026gt; Rules \u0026gt; Falco Lists and Falco Macros) by opening an element. From a rule detail by opening it directly (Policies \u0026gt; Rules \u0026gt; Rules Library, then select a rule) or from the events detail. You can visually identify rules using Lists and Macros by looking for elements in the condition with a grey background. Click on the element to customize it. The element content appears. For custom elements, you can Edit the definition, excluding the name.\n\u0026lt;img src=\u0026quot;/image/rule_db_condition.png\u0026quot; width=\u0026quot;500\u0026quot; /\u0026gt; For managed elements, you can Append content if it hasn\u0026rsquo;t been done already, or Edit Append if it has.\nAdd Custom Lists and MacrosFrom the Lists and Macros pages (Policies \u0026gt; Rules \u0026gt; Falco Lists and Falco Macros), click Add in the top right.\nFrom there, define a name and content.\nRemember that Lists are comma-separated sets of elements, while Macros are complete logical operations, similar to rule conditions.\nRule DefinitionThe first attribute of the rule definition is its type. It is defined by a combination of the engine the rule operates in and the raw event it applies to. It uniquely identifies a language, meaning a set of fields, conditions, and outputs that are available, either statically defined or customizable.\nThe main body content depends on the rule type and is explained in the following sections:\nBehavioral Analytics: All rules marked as Observation type, having awscloudtrail_stateful as the rule source, or published by Sysdig stateful (top right corner of the rule definition). List matching rules: All rules of type List Matching. Falco-based rules: All other rules. Rule Types CapabilitiesThe following table summarizes what actions can be performed on each rule type:\nRule Type View content Write custom rules Manage exceptions Falco - AWS CloudTrail ✓ ✓ ✓ Falco - AWS GuardDuty ✓ ✓ ✓ Falco - Azure Platform Log ✓ ✓ ✓ Falco - GCP Audit Log ✓ ✓ ✓ Falco - GitHub ✓ ✓ ✓ Falco - Kubernetes Audit ✓ ✓ ✓ Falco - Microsoft Entra ✓ ✓ ✓ Falco - Okta ✓ ✓ ✓ Falco - Linux Workload ✓ ✓ ✓ Falco - Windows Workload ✓ - ✓ Drift From policy - ✓ FIM From policy - ✓ Malware From policy - ✓ ML From policy - - Behavioral Analytics - AWS CloudTrail From policy - Add values only Behavioral Analytics - Linux Workload ✓ - - List Matching - Container ✓ Edit only - List Matching - File System ✓ Edit only - List Matching - Network ✓ Edit only - List Matching - Process ✓ Edit only - List Matching - Syscall ✓ Edit only - Notes:\nView content - From policy: The rule is embedded in the policy. Refer to the policies to manage these rules. Custom - Edit only: You can only customize the existing ones, cannot create new ones. Exceptions - Add values only: It\u0026rsquo;s only possible to add values to predefined exceptions. Falco-Based RulesFalco rules are composed of different elements:\nName: Falco rules are identified by a name, which uniquely represents a rule for each type. The name cannot be changed once the rule is created, as multiple elements can refer to it.\nDescription: Describes what the rule aims to detect and how.\nCondition: Describes a boolean condition using the Falco language. When this condition is matched, a raw event is transformed into a detection. The condition is written using Falco fields, which extract information from the raw event, and operators. Each rule type has different fields available. You can find them here. Note that not all operators are supported. Fields of type LIST support only in, exists, and intersects. You can read more about it in the Falco documentation.\nOutput: Constitutes the main part of the detection, as it contains all the details of What happened. This text can be enriched with values extracted from the raw event by using the Falco fields available for the rule type, prepending the field name with %.\nPriority: Defines the importance of a detection (i.e., the gravity of the condition being met). This should not be confused with the Policy\u0026rsquo;s Severity, which applies to a specific context.\nTags: Categorizes the event, usually by attack phases or according to a framework like MITRE ATT\u0026amp;CK.\nExceptions: Defines when the event should not trigger, suppressing false positives and reducing noise. Read more in the dedicated section.\nAdditional information about writing these rules is available in the Falco documentation.\nBehavioral AnalyticsBehavioral Analytics rules are more complex rules that match against multiple events with common attributes happening in a well-defined period of time and/or order. These rules are defined and managed by the Sysdig Threat Research team. They\u0026rsquo;re currently available for AWS CloudTrail and Linux Workloads.\nAs with Falco rules, the description explains what is matched and how, so you can understand the detection. In Linux Workload Behavioral Analytics, there is also a Falco-compatible output.\nUnlike Falco rules, the only customization available in AWS Behavioral Analytics rules is appending exception values.\nList Matching RulesList matching rules trigger an event when an activity of a given type matches against a specified list of attributes.\nEvery list matching rule contains:\nName Description Tags Refer to Falco-based rules to learn more about them.\nThen, the remaining attributes depend on the rule type and the activity it detects:\nContainer matches containers being started whose image (or components of it, like the name only, the repository, etc.) is (If Matching) or is not (If Not Matching) in the provided comma-separated list. File System matches files being opened, whose path is (If Matching) or is not (If Not Matching) in the provided path lists, based on the open mode (Read only or Read and Write). Network matches incoming and/or outgoing connections (Allow will not match) if the Server port is (If Matching) or is not (If Not Matching) in the provided TCP and UDP port lists. Process matches new processes being executed if their name is (If Matching) or is not (If Not Matching) in the provided list. Syscall matches syscalls executed if their name is (If Matching) or is not (If Not Matching) in the provided list. Rules Editor The rules editor is an advanced tool. We suggest using the other pages unless you’re confident with the Falco language.\nThe Rules Editor lets you freely create custom Falco elements like rules, lists, and macros, modify them and create appends, as you would do when using Falco directly, through a YAML ruleset.\nTo access the Rules Editor interface, select Policies \u0026gt; Rules \u0026gt; Rules Editor:\nThe right panel displays the various rulesets provided by Sysdig. You can select them by using the dropdown.\nOn the left side, you can see the custom elements you created.\nThe editor supports basic capabilities, like a find and replace function, accessible with Ctrl + F/Cmd + F or code completion upon writing.\nManage Rule Exceptions in YAMLTo define a custom exception in YAML, you can just reference an existing rule, by its name, source and add the exception, specifying also append: true.\nTo learn more about exceptions, see the dedicated section.\n- rule: my custom rule exceptions: - name: cmdline_writer fields: [proc.cmdline, fd.directory] comps: [startswith, =] source: syscall append: true The exception above doesn\u0026rsquo;t have values. It\u0026rsquo;s possible to add them in the same element or separately, with another append, as you would do with managed exceptions.\nAppend Values to an ExceptionYou can append values to the exception by specifying the rule name, the source and the exception name, without redefining the entire exception, just specifying also append: true.\n- rule: my custom rule exceptions: - name: cmdline_writer values: [httpd, /etc/shadow] source: syscall append: true After appending the values, you would get the same result as:\n- rule: my custom rule exceptions: - name: cmdline_writer fields: [proc.cmdline, fd.directory] comps: [startswith, =] values: [httpd, /etc/shadow] source: syscall append: true ","url":"https://docs.sysdig.com/en/sysdig-secure/manage_threat_detection_rules/"},{"id":51,"title":"Managed Kubernetes","content":"Review Managed KubernetesHere you can review details and instrument a cluster if needed.\nFiltering ActionsYou can:\nSearch by keyword Filter by platform or account number Sort by Status, Cluster Name, Account ID, or Region Use Instrumentation ModalFor un-instrumented clusters detected on an account, the modal under More helps speed the instrumentation process.\nClick Instructions to Instrument.\nThe instrumentation popup appears with your access key and cluster-specific data prefilled.\nFollow the instructions in the wizard using Helm or values.yaml.\n","url":"https://docs.sysdig.com/en/sysdig-secure/integrations--managed-k8s/"},{"id":52,"title":"Number","content":"Do not use this panel to see a trend, rather use it when you need to see the average of a value over the given time range. This is also useful for counting entities, such as the number of nodes in a cluster.\nFor information on configuring a panel, see Create a New Panel.\nMajor Features The default preset for the Number visualization is 1 hour.\nThe global default values for the threshold are overridable. The new value can be reset back to the global default.\nA comparison between two threshold values determines color-coding directions.\nThe Compare To functionality can be toggled between enabled and disabled.\nWhen the Compare To value is set, the preview is updated accordingly showing the comparison value and an arrow denoting the metric has increased or decreased.\nThe unit displayed for Thresholds is determined by the query.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/number/"},{"id":53,"title":"Onboarding for Sysdig Monitor","content":"If you are both a Sysdig Monitor and Secure user, follow the Sysdig Secure installation process to obtain the features of both products.\nCluster Shield and Host ShieldThe Sysdig Host Shield and Cluster Shield streamline the deployment, management, and configuration of the installation components of Sysdig Monitor. By consolidating multiple deployments into just two containerized components, the Host Shield and Cluster Shield simplify operations in Kubernetes environments, helping you review the components and choose an installation path that fits your environment. Sysdig Monitor collects system metrics and events and offers comprehensive visibility into your infrastructure.\nThe Sysdig Cluster Shield and Host Shield are the installation components of Sysdig Monitor. They unify multiple previously-separate agent deployments into a single containerized component.\nCluster Shield simplifies deploying, configuring, and managing the installation component of Sysdig Monitor at the cluster level, whereas Host Shield simplifies the installation in the host environment.\nPrometheus Remote WriteYou can use Prometheus Remote Write to collect Prometheus metrics from your Prometheus servers. This is best suited for environments where the Cluster Shield and Host Shield are not available. However, if you choose to use Prometheus Remote Write, the following features of Sysdig Monitor will not be available as it does not collect syscall() events.\nSystem metrics Extended Label Sets The Scope Tree IntegrationsIntegrations for Sysdig Monitor include application integrations, cloud integrations, and custom integrations.\nAdd Cloud Accounts Configure Monitoring Integrations Next Steps Install Cluster Shield Install Prometheus Remote Write Configure Integrations ","url":"https://docs.sysdig.com/en/sysdig-monitor/onboard-monitor/"},{"id":54,"title":"Onboarding for Sysdig Secure","content":"Sysdig ShieldHost Shield and Cluster Shield, known collectively as Sysdig Shield, are the installation components of Sysdig Secure. With two containerized components, Host Shield and Cluster Shield help you maintain the security and compliance posture of your systems, and streamline the deployment, management, and configuration of the Sysdig suite of tools.\nSysdig Shield is the new installation method, replacing Classic Agent installation with the following benefits:\nEasier installation and troubleshooting. Simplified architecture, with multiple components consolidated into just two containerized components. Improved compatibility and support across Sysdig platform. Centralized the feature updates of Kubernetes Security Posture Management(KSPM), Vulnerability Management (VM) and Runtime into Host Shield and Cluster Shield release notes. Host ShieldHost Shield consolidates the following features in one application:\nRuntime Threat Detection Host Vulnerability Scanning Kubernetes Security Posture Management (KSPM) for Hosts Rapid Response Cluster ShieldCluster Shield consolidates the following features in one application:\nContainer Vulnerability Scanning Kubernetes Audit Threat Detection Kubernetes Security Posture Management (KSPM) for Clusters Features OverviewThe following section describes Sysdig Secure features and the tools that provide them.\nThreat DetectionSysdig provides threat detection, which processes syscall events and metrics, creates capture files, and performs auditing and compliance. This provides detailed visibility into container and host activity, helping to detect and prevent threats.\nInstall Sysdig Shield on Kubernetes | Hosts.\nInstall Serverless Workload Agent for Linux on Serverless.\nThreat ResponseResponse ActionsSysdig allows you to execute inline Response Actions directly from the platform, to promptly stop threats with clear and straight-forward actions, or to collect additional data to support threat investigation.\nEnable Response Actions with Sysdig Shield following the instructions on the Response Actions page\nRapid ResponseSysdig Shield offers Rapid Response for Linux nodes and standalone hosts. Rapid Response lets designated advanced users investigate and troubleshoot events from a remote shell. This can help with quick incident response and resolution.\nEnable Rapid Response with Sysdig Shield on:\nLinux Nodes Containers on Linux Hosts Packages on Linux Hosts This feature is not available for Windows nodes.\nVulnerability ManagementVulnerability management is the systematic process of identifying, evaluating, and addressing security-related software bugs in your organization, as identified by trusted third-party vulnerability feeds. Key concepts areas of Vulnerability management include vulnerability identification, risk assessment and prioritization. Sysdig addresses vulnerability findings at each stage of the software lifecycle.\nPipeline ScanningThe Sysdig CLI Scanner lets you scan a container image stored locally, such as on a developer machine, or in a remote registry. You can also integrate the sysdig-cli-scanner into any instrumentation or CI/CD pipeline to scan any container image right after it is built. Native plugins for some CI/CD software, such as Jenkins, are also available directly from their marketplace.\nInstall Sysdig CLI Scanner. Registry ScanningThe Sysdig Registry Scanner scans container images stored in registries for vulnerabilities and compliance issues before they are deployed. You can deploy the Registry Scanner as a scheduled cron job in your Kubernetes cluster.\nInstall the Registry Scanner. Runtime ScanningThe Sysdig Runtime Scanner includes both Kubernetes workloads and hosts scanning with automatic updates. The scanner automatically observes and reports on all the runtime workloads in containers, keeping a close-to-real time view of images and workloads executing on the different Kubernetes scopes of your infrastructure. Perform periodic re-scans to ensure that the vulnerabilities associated with the runtime workloads and images are up-to-date with the latest vulnerabilities feed databases. It automatically matches a newly-reported vulnerability to your runtime workloads without requiring any additional user interaction.\nInstall the Sysdig Agent on Kubernetes | Hosts Host ScanningVulnerability Host Scanning analyzes software packages installed on hosts with periodic scans, and checks for newly-reported vulnerabilities\nInstall Sysdig Shield on Kubernetes | Hosts. Configure Vulnerability Management for AWS. Deploy the Host Scanner for non-Kubernetes containers. ComplianceSysdig Shield offers Compliance for Kubernetes and non-Kubernetes containers.\nKubernetes (KSPM)Sysdig Shield offers Kubernetes Security Posture Management (KSPM) with two features. The Collector collects Kubernetes resources manifests, and the Analyzer analyzes your host\u0026rsquo;s configuration. Sysdig evaluates these against Compliance policies, and the results are displayed in Sysdig Secure\u0026rsquo;s Compliance UI.\nInstall Sysdig Shield Kubernetes | Hosts. Containers (Non-Kubernetes)For hosts running Docker without a Kubernetes orchestrator, the Posture Host Analyzer scans and evaluates against Compliance policies, and displays scan results in Sysdig Secure\u0026rsquo;s Compliance UI.\nInstall on Linux Host running Docker\nAdmission ControllerKubernetes Audit LoggingThis feature deploys the Sysdig Admission Controller in your Kubernetes cluster to enable audit logging. It helps in enforcing security policies and preventing the deployment of vulnerable images.\nInstall on Kubernetes\nCloud Account FeaturesIntegrate Sysdig Secure features with your cloud environments to provide unified threat detection, compliance, forensics, and analysis. The Agentless CSPM and Threat Detection features are available on AWS, Azure, and GCP. CIEM (Identity and Access) is currently available on AWS.\nConnect Cloud Accounts\nAgentless CSPMThis includes:\nInventory: Search and gain visibility into resources across your cloud (GCP, Azure, and AWS) and Kubernetes environments. Each resource is enriched with a 360 degree overview - misconfigurations, compliance violations, vulnerabilities, and more. Compliance:: Review and remediate risk and compliance violations of your business zones against the policies with which you need to comply. IAC: Highlights and resolves misconfigurations and policy violations early in the development lifecycle, moving security as close to source as early as possible. Threat Detection for CloudThis feature provides:\nThreat Detection for Cloud: Use this to analyze cloud platform logs for known threats. Managed Threat Research: Discover new Zero Day Attacks against your cloud. Threat Response for CloudThis is available for AWS and provides Response Actions to react to threats happening on a cloud environment, executing containment actions or collecting data that supports your investigations.\nIdentity and Access (CIEM)Available for AWS: Identity and Access Management, also known as Cloud Infrastructure Entitlement Management (CIEM).\n","url":"https://docs.sysdig.com/en/sysdig-secure/onboarding/"},{"id":55,"title":"Posture Policies","content":"Use Posture Policies to:\nFind policies that meet your organization\u0026rsquo;s needs. Create custom policies and configure controls for each requirement. Review a policy\u0026rsquo;s structure and the controls connected to it. Enable/disable controls on policies. Filter controls by enablement status, violation severity, name, and control type. We add new policies regularly. You can find a comprehensive list of included posture policies on the Posture Policies page in Sysdig Secure.\nPrerequisitesThis feature requires the Compliance component.\nCompliance Installation Compliance | Evaluate and Remediate Navigate Policies List Log in to Sysdig Secure and select Policies \u0026gt; Posture Policies.\nReview the Policies list. Available policies are listed alphabetically.\nPolicy Name/Description: Displays the full policy name and description in accordance with the relevant authority, such as CIS or NIST. Click the arrow to link directly to the relevant standards website, where applicable.\nZones: Displays the resource scopes where this policy has been applied. To see results against the policy on the Compliance page, apply a policy to a zone.\nVersion: Lists the version of the standard published. It is not to be confused with the version, for example, of Kubernetes, listed in the policy name.\nDate Published: Date the policy was published. Until officially published, a policy under development is in Draft state.\nAuthor: Sysdig for default policies. Email address of creator for custom policies.\nClick a row to open the individual policy page.\nFilter Posture PoliciesYou can search or filter the Posture Policies list by:\nSearch: Free-text search for keywords. Zones: Select zones from the drop-down to filter policies by zones. Published/Draft: Toggle the buttons to filter by status. Custom policies can be in Draft state until the author publishes them. See Create a Custom Policy. ","url":"https://docs.sysdig.com/en/sysdig-secure/posture-policies/"},{"id":56,"title":"Dashboard Sections","content":"You can also create, manage, and organize dashboard sections using Dashboard Manager, if you have sufficient permissions.\nCreate a New SectionTo create a new section:\nOpen an existing dashboard or create a new one. In the top right corner, select Add. From the drop-down menu, select Add Section. A new section named NEW SECTION appears at the bottom of the dashboard. Add Panels to a SectionAdd an Existing PanelTo move an existing panel into a section:\nSelect the panel and drag it into the target section. Drop the panel in place. When prompted, choose whether to Save layout, Cancel, or use one of the Auto layout options to reorganize the panels. Add a New PanelTo add a new panel directly to a section:\nOpen the three-dot menu next to the section name. Select Add Panel. Rename a SectionTo rename a section:\nClick the section name. The inline editor opens. Type in the new name. Select the checkmark on the right to save your changes. Delete a SectionTo delete a section:\nOpen the three-dot menu to the right of the section name. Select Delete. If the section contains panels, choose one of the following options: Remove all panels: Deletes all panels along with the section. Move to ungrouped area: Moves the panels to the ungrouped area before deleting the section. Move to another section: Select a target section and move all panels there before deletion. If the section has no panels, a simple confirmation dialog appears. ","url":"https://docs.sysdig.com/en/sysdig-monitor/dashboard-sections/"},{"id":57,"title":"Understand Serverless Agent Drivers","content":"Serverless Agent ComponentsThe Serverless Workload Agent image includes several applications and libraries that are embedded within the Docker image of the application to be secured.\nThe key components are:\ninstrument | sidecar: Depending on the deployment strategy, the container entrypoint calls either instrument or sidecar, which is responsible for running pdig and the agent.\npdig: The driver that traces the user application and generates events for the agent.\nagentino: An agent responsible for several tasks, including gathering events from pdig, connecting to the collector, and performing policy matching.\nDriver OverviewWhen embedding the Workload Agent into the Docker image of the application to be secured, you modify the entrypoint to execute the Sysdig instrumentation. The entrypoint is responsible for starting both agentino and pdig.\nSince serverless platforms prevent host-level access, the pdig driver must operate within the same context as the user application to perform userspace-level instrumentation.\nOn the other hand, you can deploy the agent either within the same workload container or in a separate sidecar container, depending on the deployment strategy required for the use case.\nPlatform Limitations (FIPS Variant)The following limitations apply only to the FIPS-compliant variant of the Serverless Agent:\nFalco hashing enrichment is not available in the FIPS variant. Only the sidecar deployment model is supported. These are platform-level constraints, not product defects.\n","url":"https://docs.sysdig.com/en/sysdig-secure/understand-serverless-agent-drivers/"},{"id":58,"title":"Shield Health Metrics","content":"Prerequisites Cluster Shield 1.9.0 or later installed. Earlier versions of Cluster Shield do not expose health metrics. To populate the Cluster-Shield Monitoring dashboard in Sysdig Monitor with metrics, ensure Prometheus is enabled in your values.yaml file: features: monitor: prometheus: enabled: true Health Metrics AvailableCluster Shield exposes health metrics through the /metrics endpoint on port 8080.\nCollect Health MetricsTo enable Prometheus to scrape health metrics from Cluster Shield, use the following annotation in the values.yaml configuration file:\ncluster: pod_annotations: prometheus.io/scrape: \u0026#39;true\u0026#39; prometheus.io/port: \u0026#39;8080\u0026#39; prometheus.io/path: \u0026#39;/metrics\u0026#39; Once the annotation is applied, Prometheus scrapes these metrics using the specified endpoint and port.\nView MetricsSysdig MonitorTo view Cluster Shield health metrics, and check Prometheus is successfully scraping the metrics:\nLog in to Monitor. Go to Dashboards \u0026gt; Dashboards Manager. Locate the dashboard Cluster-Shield Monitoring. You can utilize the search bar. Select the dashboard. Host ShieldHost Shield exposes health metrics at the /metrics endpoint on port 9544.\nTo enable Host Shield metrics in your Shield Chart, use the following configuration:\nhost: additional_settings: prometheus_exporter: enabled: true export_health_metrics: true pod_annotations: prometheus.io/scrape: \u0026#39;true\u0026#39; prometheus.io/port: \u0026#39;9544\u0026#39; prometheus.io/path: \u0026#39;/metrics\u0026#39; The /metrics endpoint exposes metrics such as:\nsysdig_agent_connected\nsysdig_agent_healthy where\nValue 1: healthy Value 0: unhealthy An extensive list of metrics is available at Agent Health metrics page.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/shield-health-metrics/"},{"id":59,"title":"Shield Health Metrics","content":"Cluster ShieldCluster Shield exposes health metrics at the /metrics endpoint on port 8080.\nThe Helm chart for Cluster Shield sets cluster.enable_prometheus_scraping to true by default.\nThe /metrics endpoint exposes metrics such as:\nsysdig_cluster_shield_component_health_status where\nValue 1: healthy Value 0: unhealthy Viewing MetricsSysdig offers a simple method to monitor the Cluster Shield component, using Grafana dashboards. Go to Grafana dashboard to view the metrics.\nHost ShieldHost Shield exposes health metrics with the /metrics endpoint on port 9544.\nTo enable Host Shield metrics in your Shield Chart, use the following configuration:\nhost: additional_settings: prometheus_exporter: enabled: true export_health_metrics: true pod_annotations: prometheus.io/scrape: \u0026#39;true\u0026#39; prometheus.io/port: \u0026#39;9544\u0026#39; prometheus.io/path: \u0026#39;/metrics\u0026#39; The /metrics endpoint exposes metrics such as:\nsysdig_agent_connected\nsysdig_agent_healthy where\nValue 1: healthy Value 0: unhealthy An extensive list of metrics is available at Agent Health metrics page.\n","url":"https://docs.sysdig.com/en/sysdig-secure/shield-health-metrics/"},{"id":60,"title":"Retrieve the Sysdig API Token","content":"When using the Sysdig API with custom scripts or applications, an API security token, specific to each user and team, must be supplied. To retrieve your API security token:\nLog in to Sysdig Monitor or Sysdig Secure.\nSelect Settings from the user menu.\nSelect User Profile.\nThe Sysdig Monitor or Sysdig Secure API token is displayed depending on your interface and team.\nYou can Copy the token for use, or click the Reset Token button to generate a new one.\nWhen reset, the previous token will immediately become invalid and you will need to make appropriate changes to your programs or scripts.\nLearn More Team Service Accounts ","url":"https://docs.sysdig.com/en/administration/retrieve-the-sysdig-api-token/"},{"id":61,"title":"Sysdig MCP Server Integration","content":" For up-to-date information, refer to the Sysdig MCP Server GitHub repository. This documentation is based on version 0.1.1.\nThe Sysdig MCP Server bridges AI workflows and the Sysdig API, exposing tools, resources, and contextual data for informed AI-driven actions.\nIt enables AI clients to:\nQuery Sysdig Secure for runtime security events Retrieve process trees and event metadata Generate and execute SysQL queries via natural language Invoke Sysdig CLI scanning tools (when supported) Tie together AI prompts, context, and Sysdig data to assist decision-making It acts as an intermediary: clients speak MCP to your MCP server, which then calls the Sysdig APIs (or CLI) as needed to fulfill requests.\nFeaturesThe server currently supports the following capabilities:\nFeature Description Example Prompt get_event_info Get full details about a specific security event “Retrieve full details for event ID abc123” list_runtime_events List runtime security events, with optional filters “Show me high severity events in the last 2 hours in cluster1” get_event_process_tree Retrieve a process tree for a given event “Get the process tree for event ID xyz789” generate_and_run_sysql Translate natural language to SysQL and execute “List top 10 pods by memory usage in the last hour” run_sysql Execute a pre-written SysQL query directly (use only when user provides explicit query) MATCH CloudResource WHERE type = 'aws_s3_bucket' LIMIT 10 run_sysdig_cli_scanner Use Sysdig CLI scanner for vulnerability or IaC analysis (on stdio transport) “Scan image ubuntu:latest for vulnerabilities” The run_sysdig_cli_scanner tool is only available when using the stdio transport (that is, local usage).\nIt may not be available over HTTP or streaming transports.\nPrerequisites Python 3.10+ (or as specified in the project) Access to a Sysdig Secure instance with an API token Network connectivity from the MCP server to Sysdig (Optional) Docker for deployment For native/host runs: dependencies listed in pyproject.toml Development SetupUsing uvYou can use uv as a drop-in replacement for pip to create the virtual environment and install dependencies.\nIf you don’t have uv installed, follow the instructions on the uv project page.\nTo set up your local environment:\nuv venv source .venv/bin/activate This creates a virtual environment using uv and installs the required dependencies.\nConfigurationAPI TokenTo authenticate with the Sysdig Secure platform, you’ll need a Sysdig Secure API token.\nTo get your API token:\nLog in to your Sysdig Secure instance. Navigate to Settings \u0026gt; User Profile \u0026gt; Sysdig Secure API. Generate a new token or copy an existing one. This token is required to authenticate requests from the MCP server to the Sysdig Secure backend.\nEnvironment Variables Variable Description Example SYSDIG_MCP_API_HOST Sysdig Secure API base URL https://us2.app.sysdig.com SYSDIG_MCP_API_SECURE_TOKEN API token used to authenticate to Sysdig your-secure-token SYSDIG_MCP_TRANSPORT Transport mechanism (stdio, streamable-http, sse) stdio SYSDIG_MCP_MOUNT_PATH URL prefix for HTTP/SSE deployments /sysdig-mcp-server SYSDIG_MCP_LOGLEVEL Log level (DEBUG, INFO, WARNING, ERROR) INFO SYSDIG_MCP_LISTENING_PORT Port for HTTP/SSE servers 8080 SYSDIG_MCP_LISTENING_HOST Hostname for HTTP/SSE servers localhost You can set these variables in your shell or in a .env file.\nExample .env file:\n# Required Configuration SYSDIG_MCP_API_HOST=https://us2.app.sysdig.com SYSDIG_MCP_API_SECURE_TOKEN=your-api-token-here # Optional Configuration SYSDIG_MCP_TRANSPORT=stdio SYSDIG_MCP_LOGLEVEL=INFO SYSDIG_MCP_LISTENING_PORT=8080 SYSDIG_MCP_LISTENING_HOST=localhost SYSDIG_MCP_MOUNT_PATH=/sysdig-mcp-server API PermissionsThe API token must have permissions for the tools being used.\nMinimum Permissions Required Tool Category Required Permissions Sysdig UI Permission Names CLI Scanner secure.vm.cli-scanner.exec Vulnerability Management: CLI Execution Threat Detection (Events Feed) policy-events.read Threats: Policy Events (Read) SysQL sage.exec, risks.read Sysdig Sage: Use Sysdig Sage chat (EXEC) + Risks: Access to risk feature (Read) Additional recommended permissions:\nSettings: API Access Token (View, Read, Edit) Assign PermissionsTo assign these permissions to a user or service account, do the following:\nGo to Settings \u0026gt; Access \u0026amp; Secrets | Roles in Sysdig Secure. Create a role with the permissions listed in minimum permissions required. Assign the role to a Service Account or user. Use that account’s token with the MCP server. Service Account Limitation:\nThe generate_and_run_sysql tool does not currently work with Service Account tokens and will return a 500 error.\nUse an API token associated with a regular user account for this tool.\nRunning the MCP ServerDocker Deployment (Recommended)docker pull ghcr.io/sysdiglabs/sysdig-mcp-server:latest docker run -e SYSDIG_MCP_API_HOST=\u0026lt;your_sysdig_host\u0026gt; \\ -e SYSDIG_MCP_API_SECURE_TOKEN=\u0026lt;your_sysdig_secure_api_token\u0026gt; \\ -e SYSDIG_MCP_TRANSPORT=stdio \\ -p 8080:8080 \\ ghcr.io/sysdiglabs/sysdig-mcp-server:latest For HTTP/SSE Transportsdocker run -e SYSDIG_MCP_TRANSPORT=streamable-http \\ -e SYSDIG_MCP_API_HOST=\u0026lt;your_sysdig_host\u0026gt; \\ -e SYSDIG_MCP_API_SECURE_TOKEN=\u0026lt;your_sysdig_secure_api_token\u0026gt; \\ -p 8080:8080 \\ ghcr.io/sysdiglabs/sysdig-mcp-server:latest Client ConfigurationAuthenticationWhen using sse or streamable-http transport, the server expects a Bearer token in the HTTP header.\nExample headers:\nAuthorization: Bearer \u0026lt;your_sysdig_secure_api_token\u0026gt; X-Sysdig-Host: \u0026lt;your_sysdig_host\u0026gt; If X-Sysdig-Host is not provided, the server uses the host from SYSDIG_MCP_API_HOST.\nURLHTTP/SSE transports:http://\u0026lt;host\u0026gt;:\u0026lt;port\u0026gt;/sysdig-mcp-server/mcp Example:http://localhost:8080/sysdig-mcp-server/mcp Claude Desktop AppTo configure the Claude Desktop app manually, do the following:\nGo to Settings \u0026gt; Developer \u0026gt; Edit Config. Add the MCP configuration under mcpServers: { \u0026#34;mcpServers\u0026#34;: { \u0026#34;sysdig-mcp-server\u0026#34;: { \u0026#34;command\u0026#34;: \u0026#34;docker\u0026#34;, \u0026#34;args\u0026#34;: [ \u0026#34;run\u0026#34;, \u0026#34;-i\u0026#34;, \u0026#34;--rm\u0026#34;, \u0026#34;-e\u0026#34;, \u0026#34;SYSDIG_MCP_API_HOST\u0026#34;, \u0026#34;-e\u0026#34;, \u0026#34;SYSDIG_MCP_TRANSPORT\u0026#34;, \u0026#34;-e\u0026#34;, \u0026#34;SYSDIG_MCP_API_SECURE_TOKEN\u0026#34;, \u0026#34;ghcr.io/sysdiglabs/sysdig-mcp-server\u0026#34; ], \u0026#34;env\u0026#34;: { \u0026#34;SYSDIG_MCP_API_HOST\u0026#34;: \u0026#34;\u0026lt;your_sysdig_host\u0026gt;\u0026#34;, \u0026#34;SYSDIG_MCP_API_SECURE_TOKEN\u0026#34;: \u0026#34;\u0026lt;your_sysdig_secure_api_token\u0026gt;\u0026#34;, \u0026#34;SYSDIG_MCP_TRANSPORT\u0026#34;: \u0026#34;stdio\u0026#34; } } } } Replace placeholders (\u0026lt;your_sysdig_host\u0026gt;, \u0026lt;your_sysdig_secure_api_token\u0026gt;). Save and restart Claude Desktop. MCP Inspector Run MCP Inspector locally. Select the appropriate transport type and start your MCP server. Pass authentication headers (for HTTP/SSE) or environment variables (for stdio). Goose Agent Run goose configure and follow the steps to add the Sysdig MCP extension. Example ~/.config/goose/config.yaml snippet: extensions: sysdig-mcp-server: cmd: sysdig-mcp-server description: Sysdig MCP server enabled: true envs: SYSDIG_MCP_TRANSPORT: stdio env_keys: - SYSDIG_MCP_API_HOST - SYSDIG_MCP_API_SECURE_TOKEN - SYSDIG_MCP_TRANSPORT timeout: 300 type: stdio Examples and Use Cases Use Case Example Description Interactive Forensics • List runtime security events in the last hour in cluster A.\n• For event ID abc123, show the full process tree. Natural Language to SysQL • List top 5 containers by CPU usage in the last 15 minutes.\nThe MCP server converts the query to SysQL and returns results. Automated Response / Playbooks • If a cryptominer is running, open a ticket in JIRA with evidence. Vulnerability Scanning (local) • Scan image nginx:latest for vulnerabilities using the Sysdig CLI. Cloud Context Enrichment • Combine Sysdig runtime data with cloud metadata (for example, AWS tags) for context-aware remediation. Security Considerations Area Description Authentication \u0026amp; Token Management Use short-lived or rotating tokens. Avoid embedding static credentials. Input Validation \u0026amp; Prompt Sanitization Guard against prompt injection attacks. Validate and sanitize client inputs before execution. Least Privilege \u0026amp; Scope Limiting Grant only the minimal required permissions for each use case. Avoid administrative tokens. Context \u0026amp; Tenant Isolation Ensure clients and tenants are isolated to prevent data leakage across contexts. Audit Logging \u0026amp; Monitoring Log all client requests, tool invocations, and API interactions. Monitor anomalies or abuse. Tool Poisoning \u0026amp; Shadowing Risks Validate tool definitions and ensure immutability to prevent tampering or stealthy changes. Transport Security Use TLS and proper token handling for HTTP transports. Never send tokens in query parameters. Consider adding a Threat Model section to enumerate potential threats and mitigations.\n","url":"https://docs.sysdig.com/en/sysdig-secure/integrations/sysdig-mcp-server/"},{"id":62,"title":"Sysdig Monitor","content":" In the background, the Sysdig agent collects appropriate metrics and events from the hosts that are monitored. By default, it reports a comprehensive set of predefined metrics. You can extend its capabilities through agent configuration files and Monitoring and Cloud Integrations to gather additional metrics and custom parameters.\nNavigate TimeSysdig Monitor is designed around time. By default, the UI displays information in Live mode. Sysdig Monitor polls the infrastructure data every 10 seconds for each executed query and refreshes the metrics on the UI. This means that dashboards, Advisor, and the Explore views will be automatically updated with new data as time passes, and will display the most recent data available for the configured time window.\nYou can select how to view this gathered data by choosing a Preset interval and a time Range.\nThe time window navigation bar provides you with quick links to common time windows, as well as the ability to configure a custom time period in order to review historical data.\nIn addition, the navigation bar provides:\nQuick links for common time windows\nA custom time window configuration option.\nA pause/play button to exit Live mode and freeze the data to a time window, and to return to Live mode.\nStep back/forward buttons to jump through a time window to review historical data.\nZoom in/out buttons to increase/decrease the time window.\nPresetsPresets are a way of visualizing data that Sysdig Monitor gathers every 10 minutes. Select a preset to determine the data sample to be displayed. Overview supports the following presets:\n5 Minutes 1 Hour 6 Hour 12 Hour 1 Day 4 Day 1 Week 2 Weeks A preset that is 10 minutes or less is refreshed every 30 seconds. A preset that is greater than 10 minutes is refreshed at every 10 second intervals.\nPresets work in conjunction with Range selections. Selecting a particular preset interval refreshes Range selection and reloads the data subsequently. For example:\n10 Minutes: Resets the Range to December 9, 2.20 pm - December 9, 2.30 pm. 6 Hour: Resets the Range to December 9, 8.30 am - December 9, 2.30 pm. 1 Day: Resets the Range to December 8, 2.30 pm - December 9, 2.30 pm. RangeRange shows both date and time interval as well as the selected Presets in parenthesis. The Range indicated on the UI is determined by Presets. The time given is the closest time interval and by default, it is the current date and time preset by 1 hour.\nClick on the Range tab to open a calendar to select a range.\nSee Presets to understand how Range works with Presets.\nLiveThe Live badge shows if the data shown is Live or Paused.\nLive: the data is continuously updated. Paused: the data refresh pauses and live updates are stopped. Time FormatDashboards support UTC and PDT time formats. Use the toggle button next to Range to change the time format for the slot shown in Range. The default is PDT.\nConfigure a Custom Time PeriodUse the Time Navigation drop-down panel to configure a specific time range.\nSteps Preview Click the date and time indicator and configure the start and end date and time as desired. Click Save to save the changes. Use CasesKubernetes MonitoringTo get started with Kubernetes monitoring:\nSet up your data sources. Start monitoring your Kubernetes infrastructure: Use Dashboard Library to view workload and pod status; monitor resource availability in your cluster and workloads; perform cluster capacity planning and pod rightsizing. Set up Monitoring Integrations. Get started with PromQL. Discover issues with Advisor. Perform cost optimization using Cost Advisor. Cost OptimizationDiscover where you have wasted resources, how much you are spending on those environments, and the amount of potential savings you could get if you rightsize those environments to a more reasonable level. See Cost Advisor for more information.\nCloud Service MonitoringGain deep visibility into your Kubernetes environment regardless of the cloud platform you are running. Collect metrics from cloud providers for their managed services including CloudWatch, Stackdriver, or Azure Metrics, with curated Prometheus exporters and guided integration deployment.\nTo get started with Cloud Monitoring:\nSet up your data sources. Start monitoring the performance of your Cloud environment: Managed PrometheusA fully managed Prometheus monitoring service with enterprise features, such as automatic service detection and assisted integration deployment. To get started:\nSet up your Prometheus Remote Write. Start monitoring your service: Service discovery and assisted integration deployment. Set up your environment to collect Prometheus metrics. Check how PromQL can be used across Sysdig Monitor. Use PromQL Library and build dashboards and alerts. Application MonitoringCollect custom Prometheus metrics, StatsD metrics, and JMX metrics to increase visibility into the applications and objects that are unique to your infrastructure and see everything in context.\nTo get started:\nSet up your data sources. Configure custom integrations. Additional Operations Invite your team. Create a Notification Channel. Turn on Alerts. Warranty DisclaimerCustomer acknowledges and agrees that it is impossible under any current available technology for any security and/or monitoring software to identify one hundred percent (100%) of cloud threats and risks, vulnerabilities, Errors, malicious software, or an attacker’s behavior (collectively, the “Threats”). Sysdig Secure and Monitor (the “Services”) rely upon threat feeds, behavioral analysis, machine learning, and other techniques that are subject to the limitations set forth in this Documentation. However, these techniques may not be enough to discover all Threats. Further, Customer acknowledges and understands that the Sysdig Services may incorrectly identify Threats, resulting in a false positive. Lastly, Customer acknowledges and understands that by procuring Sysdig’s Services, the Services are just one tool in Customer’s overall cloud strategy and do not represent a shift in responsibility for Customer’s business. Customer remains responsible for ensuring that it has appropriate data security measures in place.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/"},{"id":63,"title":"SysQL API","content":"The SysQL public API supports the following operations:\nExecute SysQL statements and get the results Query the schema information about graph entities For more information on using the SysQL statements, see the SysQL Reference Library.\nAPI EndpointsTo execute a SysQL statement and retrieve the results, SysQL public API supports the following API endpoints:\nGET /api/sysql/v2/query POST /api/sysql/v2/query GET /api/sysql/v2/schema Prerequisites Retrieve the Sysdig API Token from the Sysdig UI to use with the API\nIdentify the Sysdig domain associated with your region\nRead permissions to Search / Inventory API.\nEnsure that you are assigned to a Custom Role with API permissions to Search / Inventory.\nGET Graph ResourcesYou can send a SysQL statement and retrieve the resource results using the /api/sysql/v2/query endpoint. Use GET method for simple queries where you can pass the parameters in the URL.\nRequest BodyGET /api/sysql/v2/query To authenticate the API request, set an Authorization header and provide a Bearer token:\ncurl -X GET -H \u0026#39;Authorization: Bearer \u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt;\u0026#39; https://\u0026lt;HOSTNAME\u0026gt;/api/sysql/v2/query Replace the following:\n\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; with the token you retrieved \u0026lt;HOSTNAME\u0026gt; with the Sysdig domain associated with your region Query Parameters Parameter Description q OR query Required parameter\nSpecifies the statement to execute. Include the SysQL statement in the URL query using either the q or query parameter, but not both simultaneously. If both are provided, a 400 Bad Request error will be returned. limit Optional parameter The limit parameter defines the maximum number of items returned in the result set, specifically within the items array in the response. The preferred and most idiomatic approach is to define the limit directly in the SysQL statement using the LIMIT clause. However, if you need to override the statement\u0026rsquo;s limit, you can specify it in the request URL, which will take precedence. The default value of LIMIT is 50. The limit can be set up to a maximum of 1,000 items per page. offset Optional parameter The offset parameter determines the number of result set objects to skip in a MATCH statement. Use this parameter when you want to omit the first few items in the resulting items array. The preferred and most idiomatic approach is to specify the offset directly in the SysQL statement using the OFFSET clause. However, if you need to override the statement’s offset, you can specify it in the request URL, which will take precedence. You can use both the limit and offset parameters or clauses in SysQL to paginate results—splitting the result set into pages, each containing a specified number of items for display purposes. The default value for offset is 0. The offset can be adjusted to paginate through results. Currently, there is no fixed upper limit on how far pagination can extend. deterministic_order Optional parameter The deterministic_order parameter controls whether consistent ordering is enforced in the result set. Ordering is implicitly applied when pagination options, such as limit and offset, are specified in the request. For more information, see SysQL Reference.\nSample RequestTo get vulnerabilities with high CVSS Score and Severity, run the following query encoded in URL format:\ncurl -X GET -H \u0026#39;Authorization: Bearer \u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt;\u0026#39; \u0026#34;https://\u0026lt;HOSTNAME\u0026gt;/api/sysql/v2/query?q=MATCH%20Vulnerability%20AS%20v%20RETURN%20v.name%20AS%20name%2C%20v.cvssScore%20AS%20cvssScore%2C%20v.severity%20AS%20severity%3B\u0026#34;| jq Sample ResponseIf the execution is successful, the response body contains the following properties:\nitems: JSON array with the requested data. entities: JSON map with metadata about the returned data. summary JSON map which contains: available_after: Time taken by the storage server to return the result (in milliseconds). consumed_after: Time taken by the query server to consume the result (in milliseconds). total_time: Total duration from query initiation to completion, including processing and result consumption (in milliseconds). fetched_items_count: Total number of items (for example, rows, records, or graph elements). The following JSON body is an example of the values returned in response:\n{ \u0026#34;entities\u0026#34;: { \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;alias\u0026#34;: \u0026#34;name\u0026#34;, \u0026#34;definition\u0026#34;: { \u0026#34;def_type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;String\u0026#34;, \u0026#34;hidden\u0026#34;: false } }, \u0026#34;cvssScore\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;alias\u0026#34;: \u0026#34;cvssScore\u0026#34;, \u0026#34;definition\u0026#34;: { \u0026#34;def_type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;cvssScore\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Float\u0026#34;, \u0026#34;hidden\u0026#34;: false } }, \u0026#34;severity\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;alias\u0026#34;: \u0026#34;severity\u0026#34;, \u0026#34;definition\u0026#34;: { \u0026#34;def_type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;severity\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Enum\u0026#34;, \u0026#34;hidden\u0026#34;: false } } }, \u0026#34;items\u0026#34;: [ { \u0026#34;severity\u0026#34;: \u0026#34;Medium\u0026#34;, \u0026#34;cvssScore\u0026#34;: 7.5, \u0026#34;name\u0026#34;: \u0026#34;CVE-2024-45491\u0026#34; }, { \u0026#34;severity\u0026#34;: \u0026#34;Medium\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;CVE-2024-45492\u0026#34;, \u0026#34;cvssScore\u0026#34;: 6.2 } ], \u0026#34;id\u0026#34;: \u0026#34;06261436-4083-4d21-af4d-1611596971da\u0026#34;, \u0026#34;summary\u0026#34;: { \u0026#34;available_after\u0026#34;: 65, \u0026#34;consumed_after\u0026#34;: 6, \u0026#34;total_time\u0026#34;: 73, \u0026#34;fetched_items_count\u0026#34;: 2 } } Sample Request for PaginationThe following request shows pagination and returns the results from 20 to 30:\ncurl -v -X POST \u0026#34;https://\u0026lt;HOSTNAME\u0026gt;/api/sysql/v1/query\u0026#34; \\ --header \u0026#34;content-type: application/json\u0026#34; \\ --header \u0026#34;Authorization: Bearer \u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt;\u0026#34; \\ --data \u0026#39;{\u0026#34;query\u0026#34;: \u0026#34;MATCH Vulnerability AS v RETURN v.name AS name, v.cvssScore AS cvssScore, v.severity AS severity LIMIT 10 OFFSET 20;\u0026#34;}\u0026#39; \\ | jq Response CodesThe operation can return the following response codes:\nHTTP Code Description 200 The operation was successful. 400 Bad Request. The request cannot be processed for one of the following reasons:\nthe statement contains a SysQL syntax error\nthe request has a missing or unrecognized HTTP parameter\nthe request is badly formatted — for example, the request body contains a JSON syntax error.\n401 Unauthorized. The credentials provided with the request are missing or invalid. 408 Request Timeout. The execution of the SysQL statement exceeded the timeout period. The execution of the statement was cancelled. 422 The 422 error typically occurs due to issues in constructing the SysQL statement, preventing the server from executing the query and retrieving results from the data store. 429 Too Many Requests. The request rate has exceeded the allowed limit. The application must reduce the frequency of requests to the API endpoints and implement retry logic with backoff. Using exponentially jittered backoff is recommended. This response may also occur if the server receives an excessive number of concurrent requests. API concurrency limits are governed by the restrictions enforced by Sysdig. 504 Gateway Timeout. The request could not be completed within the allowed timeout period. This may occur if the query is complex or if the data stored is experiencing heavy load. Try reducing the amount of data being queried. POST Graph ResourcesUse POST for larger and more complex queries in the request body. If you need to secure sensitive query parameters, use POST as it provides better security by keeping them out of the URL.\nYou can send a POST request to the /api/sysql/v2/query to retrieve the result .\nRequest BodyPOST /api/sysql/v2/query To authenticate the API request, set an Authorization header and provide a Bearer token:\ncurl -X POST -H \u0026#39;Authorization: Bearer \u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt;\u0026#39; https://\u0026lt;HOSTNAME\u0026gt;/api/sysql/v2/query Replace the following:\n\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; with the token you retrieved \u0026lt;HOSTNAME\u0026gt; with the Sysdig domain associated with your region Query ParametersSee Query Parameters.\nSample RequestRetrieve vulnerabilities in a Kubernetes workload that have exploits, ranked in descending order of high CVSS score:\ncurl -v -X POST \u0026#34;https://\u0026lt;HOSTNAME\u0026gt;/api/sysql/v1/query\u0026#34; \\ --header \u0026#34;content-type: application/json\u0026#34; \\ --header \u0026#34;Authorization: Bearer \u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt;\u0026#34; \\ --data \u0026#39;{\u0026#34;query\u0026#34;: \u0026#34;MATCH Vulnerability AS v AFFECTS KubeWorkload WHERE v.hasExploit = true and (v.cvssVersion = 1 or v.cvssScore \u0026gt; 7) RETURN v.customerId as customerId,v.name as name, v.cvssScore as cvssScore ORDER BY v.cvssScore DESC LIMIT 2;\u0026#34;}\u0026#39; \\ | jq Replace the following:\n\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; with the token you retrieved \u0026lt;HOSTNAME\u0026gt; with the Sysdig domain associated with your region Sample ResponseIf the execution is successful, the response body contains the following properties:\nitems: JSON array with the requested data. entities: JSON map with metadata about the returned data. summary JSON map which contains: available_after: Time taken by the storage server to return the result (in milliseconds). consumed_after: Time taken by the query server to consume the result (in milliseconds). total_time: Total duration from query initiation to completion, including processing and result consumption (in milliseconds). fetched_items_count: Total number of items (for example, rows, records, or graph elements). The following JSON body is an example of the values returned in response:\n{ \u0026#34;entities\u0026#34;: { \u0026#34;customerId\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;alias\u0026#34;: \u0026#34;customerId\u0026#34;, \u0026#34;definition\u0026#34;: { \u0026#34;def_type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;customerId\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;BigInt\u0026#34;, \u0026#34;hidden\u0026#34;: true } }, \u0026#34;name\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;alias\u0026#34;: \u0026#34;name\u0026#34;, \u0026#34;definition\u0026#34;: { \u0026#34;def_type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;name\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;String\u0026#34;, \u0026#34;hidden\u0026#34;: false } }, \u0026#34;cvssScore\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;alias\u0026#34;: \u0026#34;cvssScore\u0026#34;, \u0026#34;definition\u0026#34;: { \u0026#34;def_type\u0026#34;: \u0026#34;Field\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;cvssScore\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;Float\u0026#34;, \u0026#34;hidden\u0026#34;: false } } }, \u0026#34;items\u0026#34;: [ { \u0026#34;customerId\u0026#34;: 121517, \u0026#34;cvssScore\u0026#34;: 10.0, \u0026#34;name\u0026#34;: \u0026#34;CVE-2021-44228\u0026#34; }, { \u0026#34;cvssScore\u0026#34;: 9.9, \u0026#34;customerId\u0026#34;: 121517, \u0026#34;name\u0026#34;: \u0026#34;CVE-2024-41110\u0026#34; } ], \u0026#34;id\u0026#34;: \u0026#34;06261436-4083-4d21-af4d-1611596971da\u0026#34;, \u0026#34;summary\u0026#34;: { \u0026#34;available_after\u0026#34;: 65, \u0026#34;consumed_after\u0026#34;: 6, \u0026#34;total_time\u0026#34;: 73, \u0026#34;fetched_items_count\u0026#34;: 2 } } The sample schema response has been abbreviated due to its length.\nResponse CodesSee Response Codes.\nGET Graph Resource SchemaYou can send a GET request to the /api/sysql/v2/schema to retrieve the complete schema of the resources stored in the Graph database.\nRequest BodyGET /api/sysql/v2/schema To authenticate the API request, set an Authorization header and provide a Bearer token:\ncurl -X GET -H \u0026#39;Authorization: Bearer \u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt;\u0026#39; https://\u0026lt;HOSTNAME\u0026gt;/api/sysql/v2/schema Sample ResponseA successful response provides a YAML document that fully represents the Graph schema of the resources, including entities, fields, and relationships.\nA sample response is shown below:\nindex: - type: Entity name: KubeNode category: Kubernetes provider: Kubernetes description: A KubeNode represents a node in a Kubernetes cluster. fields: - name: category type: String description: The category of the node. - name: clusterName type: String description: The name of the cluster. - name: distribution type: String - name: externalDNS type: String description: The external DNS of the node. - name: isMaster type: Boolean description: Whether the node is a master node. - name: name type: String description: The name of the node. - name: operatingSystem type: String description: The operating system of the node. - name: osImage type: String description: The OS image of the node. - name: platform type: String description: The platform of the node. - name: type type: String description: The type of the node. - name: version type: String description: The version of the node. relationships: zones: entity: Zone relationship_name: IN display_name: With direction: out kubeClusters: entity: KubeCluster relationship_name: IN display_name: That Is In direction: out deployedOnCloudResource: entity: CloudResource relationship_name: DEPLOYED_ON display_name: That Is Deployed On direction: out regions: entity: Region relationship_name: IN display_name: That Is In direction: out is_virtual: true path: - deployedOnCloudResource - regions ... Response CodesThe operation can return the following response codes:\nHTTP Code Description 200 The operation was successful. 401 Unauthorized. The credentials provided with the request are missing or invalid. 408 Request Timeout. The execution of the SysQL statement exceeded the timeout period. The execution of the statement was cancelled. 429 Too Many Requests. The request rate has exceeded the allowed limit. The application must reduce the frequency of requests to the API endpoints and implement retry logic with backoff. Using exponentially jittered backoff is recommended. This response may also occur if the server receives an excessive number of concurrent requests. API concurrency limits are governed by the restrictions enforced by Sysdig. ","url":"https://docs.sysdig.com/en/developer-tools/sysql-api/"},{"id":64,"title":"Sysdig Sage for Threats","content":"Sysdig Sage for Threats primarily targets users investigating runtime threats within their infrastructure. It helps you understand the impact of threats and guides investigations by connecting related events, rules, and contextual data.\nFor example, Sysdig Sage for Threats can:\nExpand threat details with clear summaries of active threats Identify the specific threat you are investigating Surface related runtime events, rules, and impacted resources Provide contextual data to guide your investigation Recommend next steps to accelerate remediation Example Prompts PROMPT VALUE Summarize the latest threats\nTell me more about this threat Sysdig Sage can generate a title and summary of active threats and provide details from the Threats UI (Rules, Events, Resources tabs). What threat is this runtime event associated with? Sysdig Sage can identify whether a runtime event belongs to a threat and provide a direct link to that threat, reducing investigation time. Show me more details about this threat\nExpand event details Sysdig Sage allows you to expand threat or event information directly in the UI, surfacing deeper insights into rules, impacted resources, or attack patterns. What runtime events are associated with this threat? Sysdig Sage can retrieve and display a list of events tied to a selected threat, with direct navigation to each one. Who/what is impacted by this threat? Sysdig Sage can highlight impacted resources, helping analysts quickly understand scope and impact. ","url":"https://docs.sysdig.com/en/sysdig-secure/sysdig-sage-threats/"},{"id":65,"title":"Sysdig Sage for Vulnerability Management","content":"Sysdig Sage remediations are available in the drawer within the Resources window for images. You can also create Jira tickets to assign and track their implementation.\u0026quot;\nPrerequisites Vulnerability scanning is enabled and completed. Your Sysdig account is Sysdig Sage enabled. Jira integration is configured for ticketing. Guidelines and Best Practices for Remediation Use Sysdig Sage remediation suggestions as a baseline, and validate upgrades in development environments. Prioritize updating base images when possible, as this can resolve multiple CVEs in a single step. A remediation is persisted for the duration of your session. If you leave and return to the image within the same browser session, the existing remediation is reused. If you return in a new session, a new remediation is generated. Access a RemediationYou can generate a remediation using one of the following:\nSteps Preview Attack Surface \u0026gt; Vuln Runtime Findings \u0026gt; Group by Image Inventory \u0026gt; Search Attack Surface \u0026gt; Risks. Select an image Resource Details drawer Inventory \u0026gt; All Resources and filter by Resource Type = Image Generate a Remediation with Sysdig Sage Access remediation from the image drawer in the Resources section.\nClick the Remediate tab in the image view.\nIn the Sysdig Sage Strategies panel, click Generate Remediation.\nSysdig Sage analyzes the image and generates a remediation plan with:\nRecommended application/package upgrades\nRecommended base image updates\nAlternative OS package fixes if the base image cannot be updated\nReview the Remediation PlanThe remediation is typically divided into two sections:\nRemediation Types Preview Application and Language Layer Upgrade suggestions for libraries in runtime. For example, Java, Python, or Node.js\nDependency-aware and low-effort to apply\nBase Image and Operating System Layer\nSuggested base image upgrades. For example, alpine:3.18\nTargeted runtime package upgrades. For example, musl, libssl\nCreate a Jira Ticket (Optional)To assign the remediation plan by Sysdig Sage to engineering with a pre-filled ticket:\nOn the remediation panel, click Create Ticket.\nAn Open Jira Ticket screen appears.\nSelect a Project and enter Issue Type.\nClick Create to generate a pre-filled ticket with a summary and description that covers the following :\nSuggested upgrades Paths to vulnerable packages Example commands Applying and Validating Fixes Apply the recommended changes in your image build pipeline. Push the updated image to scan it again. Revisit the Findings page and check the image view to confirm that the CVEs have been resolved. ","url":"https://docs.sysdig.com/en/sysdig-secure/sysdig-sage-vm/"},{"id":66,"title":"Configure Sysdig Windows Agent","content":"The agent relies on a configuration file named dragent.yaml to describe the configuration that influences the behavior of the Windows Agent. This file is located in the %ProgramFiles%\\Sysdig\\Agent\\Config directory. You can add configuration parameters directly in YAML as key-value pairs.\nEnvironmentsHostsIf Sysdig Windows Agent is installed in a Windows host, edit the dragent.yaml file directly.\nEdit the Configuration Filedragent.yaml Log in to the host where the agent is installed.\nOpen %ProgramFiles%\\Sysdig\\Agent\\Config\\dragent.yaml.\nEdit the file using proper YAML syntax.\nRestart the agent service for changes to take effect.\n\u0026gt; Restart-Service -DisplayName \u0026#34;Sysdig Agent\u0026#34; ","url":"https://docs.sysdig.com/en/sysdig-secure/configure-windows/"},{"id":67,"title":"Terraform","content":"Prerequisites Review the Installation Requirements before getting started.\nFor details about the Resources, Inputs, and Outputs, see the Fargate Workload Agent Terraform registry.\nFor the images pulled from private registries, explicitly provide the Entrypoint and Command in the related container definition, or the instrumentation will not be completed.\nDeploy the AgentAn example deployment for the Workload Agent can be found in the Sysdig Terraform provider: Workload Agent example.\nThe Sysdig instrumentation will go over the original task definition to instrument it. The process includes replacing the original entry point and command of the containers.\nWorkload Agent Deployment TypesYou can deploy the Workload Agent to run in the workload container or in a sidecar container. The latter is the default mode for version 5.0.0 onwards. By default, the agent will detect the runtime configuration and deploy itself accordingly.\nThe pid_mode parameter in a task definition will influence how the agent is deployed. To deploy in a sidecar container, set this parameter to task. Any other value will deploy in the workload.\nAdvanced Configuration for Workload AgentUse the following advanced options to fine-tune the Workload Agent :\nPriority: Supported options are availability (by default) or security. In security mode the Workload Agent processes every syscall event and prevents the workloads from running unsecured. Consequently, secured applications will not execute until the Workload Agent receives the runtime policies. The availability mode instead facilitates resource sharing between the Workload Agent and the workload containers, enabling the Workload Agent to detect when resource pressure exceeds configurable limits and pause event processing to reduce pressure. Instrumentation essential: If marked as essential, ECS will stop all containers in the task if the sidecar exits. The sidecar container is marked as essential in security mode by default to prevent secured workloads from running unsecured. Instrumentation cpu/memory configuration: The settings can be adjusted to allocate dedicated CPU units and memory resources/limits to the sidecar container. Upgrade the AgentThe Workload agent can be upgraded individually by redeploying its stack. If the stack was deploying using the latest tag, redeploying the existing Terraform will reference the new version.\nFor example, to upgrade v4.2.0 to v5.0.0, you will add the following in your task definition:\ndata \u0026#34;sysdig_fargate_workload_agent\u0026#34; \u0026#34;containers_instrumented\u0026#34; { ... workload_agent_image = \u0026#34;quay.io/sysdig/workload-agent:5.0.0\u0026#34; ... } To upgrade to v5.0.0, you also add a parameter pid_mode and set it to task. For example:\nresource \u0026#34;aws_ecs_task_definition\u0026#34; \u0026#34;task_definition\u0026#34; { family = \u0026#34;${var.prefix}-instrumented-task-definition\u0026#34; task_role_arn = aws_iam_role.task_role.arn execution_role_arn = aws_iam_role.execution_role.arn cpu = \u0026#34;256\u0026#34; memory = \u0026#34;512\u0026#34; network_mode = \u0026#34;awsvpc\u0026#34; requires_compatibilities = [\u0026#34;FARGATE\u0026#34;] pid_mode = \u0026#34;task\u0026#34; workload_agent_image = \u0026#34;quay.io/sysdig/workload-agent:5.0.0\u0026#34; container_definitions = data.sysdig_fargate_workload_agent.containers_instrumented.output_container_definitions } Next StepsAfter the deployment completes, security-related events will be visible in the Sysdig Secure Events feed.\nOptionally, you can perform advanced Configuration to fine-tune the agent.\n","url":"https://docs.sysdig.com/en/sysdig-secure/install-ecs-serverless-tf/"},{"id":68,"title":"Third-Party Integrations for Sysdig Secure","content":"Third-Party Integrations Container Registries: Scan registries and enable agentless scanning to connect to your registries.\nIdentity and Audit Logs: Ingests event logs into Sysdig Secure to correlate user identity and access information with observed activity within cloud and container environments, enhancing threat detection and incident investigation.\nNotification Channels: Get real-time Sysdig alert notifications delivered to a wide range of systems. Sysdig Monitor notification channels must be configured separately and are accessed from the Monitor UI.\nRisk Spotlight Integration: Risk Spotlight integrations allow Third-Party solution to enrich vulnerability information using the runtime findings provided by Sysdig.\nSource Code Management: Scan container images for vulnerabilities directly within GitHub, Bitbucket, GitLab, or Azure DevOps, providing feedback early in the development cycle.\nSIEM and Data Platforms: Forward Sysdig security events, audit logs, and compliance findings to a range of external tools such as Splunk, Elasticsearch, and Syslog.\nTicketing Integrations: Automatically create Jira issues from Sysdig findings (security events, vulnerabilities, compliance violations) to track remediation within your existing project management workflows.\n","url":"https://docs.sysdig.com/en/sysdig-secure/third-party-integrations/"},{"id":69,"title":"Understand Agent Drivers","content":"The Sysdig Agent can receive system call events from the Linux kernel via one of three different drivers:\nUniversal eBPF Kernel module (kmod) Legacy eBPF Each driver has its own prerequisites, advantages, and trade-offs. All three drivers share common features, but differ in the way they implement these common features.\nDriver Comparison Table Driver Name Minimum Compatible Kernel Version Requires Kernel Headers Event Buffer User Space Memory Footprint Ideal Use Case Universal eBPF 5.8 No 8MiB * Number of CPU cores / 2 New agent installations on systems with Linux kernel version 5.8 or newer. Kernel Module 3.10 Yes N/A Systems with pre-5.8 Linux kernels Legacy eBPF 4.14 Yes 8MiB per CPU core x86 systems with Linux kernel version 4.14 to 5.7 where third-party kernel modules are not allowed. Agent driver compatibility is described in terms of upstream or “vanilla” kernel versions because some popular Linux distributions back-port features from newer kernels into the older kernel versions they ship with their distributions. Red Hat Enterprise Linux (RHEL) is especially well-known for this practice.\nUniversal eBPFThe Universal eBPF driver is the preferred method for running the Sysdig Agent. This driver includes a series of programs that function within a specialized sandboxed virtual machine inside the Linux kernel, which reduces attack surfaces and enhances system stability.\neBPF programs exchange data with user space and with each other using eBPF-specific data structures, such as maps and ring buffers. The Universal eBPF driver is pre-built and embedded directly into the agent binary, eliminating the need for kernel headers from the target system.\nPrerequisitesKernel version 5.8 and later While kernel versions 5.8 and later generally support the Universal eBPF probe, the probe does not strictly require kernel version 5.8. You can backport the necessary features to earlier kernel versions. However, even kernel versions 5.8 and later may occasionally lack certain required features. The key requirements are:\nBPF ring buffer support A kernel that exposes BTF (BPF Type Format) The Sysdig agent can automatically detect if the features are available on the running machine and notify you if something is missing. Alternatively, you can use bpftool to manually check for the required features by running the following commands:\nsudo bpftool feature probe kernel | grep -q \u0026#34;map_type ringbuf is available\u0026#34; \u0026amp;\u0026amp; echo \u0026#34;true\u0026#34; || echo \u0026#34;false\u0026#34; sudo bpftool feature probe kernel | grep -q \u0026#34;program_type tracing is available\u0026#34; \u0026amp;\u0026amp; echo \u0026#34;true\u0026#34; || echo \u0026#34;false\u0026#34; Helm Installationshield Charthost: driver: universal_ebpf For more information, see the Helm chart.\nsysdig-deploy Chartagent: ebpf: enabled: true kind: universal_ebpf For more information, see the Helm chart.\nHost-Based Installation./install_agent.sh --universal_ebpf ... During Agent installation process on Linux nodes, you can define the --universal_ebpf setting to install the agent with eBPF support. For more information, see onboarding workflow.\nMemory Accounting in the Linux Kernel When inspecting memory usage using tools like pmap or by checking /proc/\u0026lt;PID\u0026gt;/smaps, you may notice that the Resident Set Size (RSS) appears to double-account for the eBPF ring buffer maps. This can lead to an inflated memory footprint. The visible memory footprint is 16MiB per ring buffer map, not 8MiB as expected.\nThe memory statistics can give a false impression that the agent using eBPF drivers consumes more memory than an agent using the kernel module due to how the Linux kernel accounts for memory.\nIn Linux containerized environments, a kernel feature called cgroups is used to measure, limit and isolate resources consumed by the group of processes forming the container.\nStarting with version 5.11, the Linux kernel switched from rlimits to memory cgroup (memcg) accounting for managing memory limits on processes handling eBPF objects in the kernel. For this reason, when using Universal eBPF driver, the memory consumed by the eBPF ring buffer maps should be considered when setting the memory limit for the agent container.\nKernel ModuleThe kernel module driver is what its name suggests: an additional driver that is inserted into the Linux kernel. It implements kernel event handlers and a custom channel for sending event data to the agent\u0026rsquo;s user space program. It must be built against the headers for the specific kernel it will run on. The kernel module also allocates its event buffers from kernel memory, giving it the lowest user-visible memory footprint.\nHelm Installationshield Charthost: driver: kmod For more information, see the Helm chart.\nsysdig-deploy Chartagent: ebpf: enabled: false For more information, see the Helm chart.\nLegacy eBPF Deprecation Notice Support Ending\nThis driver will be retired on December 4, 2026. We recommend migrating to Universal eBPF.\nThe Legacy eBPF driver uses the same runtime and kernel instrumentation techniques as Universal eBPF. However, it relies on older kernel features which limits its efficiency and capabilities. Like the kernel module driver, the eBPF driver must be built against headers for the specific kernel it will run on. It differs, however, in that the eBPF driver must allocate event buffers from memory in user space. This increases the eBPF driver\u0026rsquo;s user-visible memory footprint by 8MiB per CPU, relative to the kernel module.\nHelm Installationshield Charthost: driver: legacy_ebpf For more information, see the Helm chart.\nsysdig-deploy Chartagent: ebpf: enabled: true kind: legacy_ebpf For more information, see the Helm chart.\nHost-Based Installation./install_agent.sh --bpf ... Learn More What is eBPF? An Introduction and Deep Dive into eBPF the Technology What is the Difference Between User Space and Kernel Space in Linux Prefixes for binary multiples ","url":"https://docs.sysdig.com/en/sysdig-secure/classic-agent-drivers/"},{"id":70,"title":"Use PromQL","content":" Sysdig Monitor is designed to be fully PromQL compliant and is periodically validated against the official PromQL Compliance Tester as part of our release process.\nIn practice, this means that PromQL queries written for a standard Prometheus environment are expected to work in Sysdig Monitor without modification, subject to the same PromQL versions and features covered by our compliance testing. On top of this, Sysdig Monitor automatically enriches your metrics with Kubernetes and infrastructure context through the Extended Label Set. For most use cases, labels like cluster, namespace, pod, and deployment are already present on your metrics, so you can filter and aggregate directly without writing joins. Before writing any query, it is worth reading the Extended Label Set page to understand which labels are available and how they affect query structure.\nPromQL queries in Sysdig Monitor can be used in Dashboards, Alerts, and via the Prometheus Public API.\nLearn PromQLIf you are new to PromQL or want to deepen your knowledge, the following resources are a good starting point:\nPrometheus Query Basics Prometheus Monitoring Guide To explore and build queries in Sysdig Monitor specifically:\nPromQL Query Explorer PromQL Library — Curated query library with sample dashboards Prometheus Alerts Vector Matching for Advanced Label EnrichmentThe Extended Label Set covers the vast majority of Kubernetes and infrastructure label needs. For cases it does not cover, you can enrich metrics manually using vector matching.\nVector matching works similarly to an SQL join: it lets you attach labels from one metric onto another by matching on a shared label.\nInfo MetricsInfo metrics are a Prometheus convention for exposing metadata that is not naturally attached to your application metrics. They always carry a value of 1 and hold context such as Kubernetes object properties or cloud provider details as labels. On their own, info metrics are not particularly useful — their value comes from joining their labels onto other metrics, allowing you to correlate a metric\u0026rsquo;s value with infrastructure, application, or deployment context that would otherwise be unavailable on that metric. Because their value is always 1, multiplying an info metric against a target metric grafts its labels onto the result without changing the underlying value.\nInfo metrics in Sysdig are typically generated by kube-state-metrics or by Sysdig\u0026rsquo;s own ingestion pipeline, not by the application being monitored. See Mapping Between Classic Metrics and PromQL Metrics for a list of available info metrics.\nVector matching with info metrics is still needed in the following common cases:\nEnriching metrics with cloud provider labels such as AWS account ID and region Joining custom application metrics with infrastructure metadata not in the extended set Traversing non-standard Kubernetes ownership chains Example 1: Average CPU Used Percent in AWS HostsCloud provider labels such as account_id and region are not part of the Kubernetes metadata provided by the Extended Label Set, making this a case where vector matching is still required. The following query calculates average CPU used percent per AWS account and region, filtered by dashboard scope variables:\navg by (region, account_id) ( sysdig_host_cpu_used_percent * on(host_mac) group_left(region, account_id) sysdig_cloud_provider_info{account_id=~$AWS_account, region=~$AWS_region} ) The query performs the following operations:\nFilters sysdig_cloud_provider_info based on the account_id and region labels from the dashboard scope variables. Matches sysdig_host_cpu_used_percent with sysdig_cloud_provider_info on host_mac, carrying over region and account_id labels to the result. Calculates the average of the resulting metrics grouped by account_id and region. Example 2: Vector Matching vs. Extended Label SetTo illustrate the difference in query complexity, consider calculating total CPU usage per deployment. Without the Extended Label Set, this requires chaining two vector matches — first joining container metrics to pod metadata, then joining pod metadata to ownership information:\nsum by (cluster, namespace, owner_name) ( sysdig_container_cpu_cores_used * on(container_id) group_left(pod, namespace, cluster) kube_pod_container_info * on(pod, namespace, cluster) group_left(owner_name) kube_pod_owner{ owner_kind=\u0026#34;Deployment\u0026#34;, owner_name=~$deployment, cluster=~$cluster, namespace=~$namespace } ) With the Extended Label Set, the same result is expressed as:\nsum by (kube_cluster_name, kube_namespace_name, kube_deployment_name) ( sysdig_container_cpu_cores_used{ kube_cluster_name=~$cluster, kube_namespace_name=~$namespace, kube_deployment_name=~$deployment } ) The Extended Label Set version is not only shorter — it is also easier to reason about. Filtering on infrastructure labels becomes a straightforward label selector on the metric itself, rather than a condition buried inside a chain of joins.\nFor more before-and-after examples like this, see Extended Label Set.\nRange Interval BehaviorIn Prometheus 2, range selectors such as [10s] were inclusive on both sides, effectively capturing 11 seconds of data. Prometheus 3 changed this so the left side is exclusive. Sysdig Monitor intentionally preserves the Prometheus 2 behavior by default. This decision was driven by customer feedback — switching to the new behavior would silently break a large number of existing alerts and dashboards that were written against Prometheus 2 semantics. If you need Prometheus 3 range behavior for consistency with a self-hosted environment, this can be changed on request.\nFormattingSysdig Monitor supports percentages only as 0-100 values. In calculated ratios, you can skip multiplying the whole query times 100 by selecting percentage as a 0-1 value.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/use-promql/"},{"id":71,"title":"View CVE Details","content":"OverviewThis page offers a comprehensive investigation panel for a specific CVE, including:\nVulnerability metadata and affected asset metadata. Full vulnerability description and CVE background. Context indicators like exploitability and fix availability. Threat intelligence insights (CISA KEV, ransomware use). Remediation guidance for the individualized Vulnerability across your infrastructure. Actions like Create Ticket and Accept Finding are readily available to initiate workflows and drive Remediation. HighlightsThe Highlights section of the CVE Details drawer is an overview of the Vulnerability in your environment, providing context to help you prioritize and understand the risk of the Vulnerability as it relates to your infrastructure.\nAll Affected Resource Summary Total Resources : The number of affected Resources with a link to (Impacted Resources)[#impacted-resources] Sources: The count of unique Sources of the Vulnerability inside your environment. Remediations: The count of total remediations for the Vulnerability across all its findings. If a fix is available provides a navigation to the (Remediations)[#remediations] section of the CVE Details drawer. Zones: the Affected Resources belong to. Zones are in Technical Preview. To enable Zones, go to Settings \u0026gt; User Profile. Under Sysdig Labs, toggle Zones scoping for all features on. If Zones is not available from your User Profile, contact your Sysdig representative.\nDescriptionThis section provides a detailed information about the vulnerability including high level overviews provided by Sysdig Vulnerability Feeds including but not limited to:\nBackground on the software or component affected Description of how the vulnerability can be exploited Timeline of discovery, fixes, or regressions Recommendations for mitigating risk if immediate patching is not possible CVE Details Field Value Description Finding Name CVE-2024-41110 The official CVE identifier assigned to this vulnerability. Severity Critical The risk level of the vulnerability based on CVSS score and external feeds, provides a clickable link to the Vulnerability Feeds section. For more information see Vulnerability Feeds. Context Exploitable, Has Fix, In-Use Indicates whether the vulnerability is actively exploitable and if a fix is available, or is In-Use in any Impacted Resource. Disclosure Date Tue, Jul 30, 2024 at 03:18:57 AM The date the vulnerability was publicly disclosed by the matched vendor, for more information see Vulnerability Feeds. EPSS 0.00% The Exploit Prediction Scoring System score, estimating the probability of exploitation. EPSS Percentile 0.00% The percentile rank of this CVE relative to other known vulnerabilities. RemediationsCVE remediations are specific to the CVE across all impacted resources. It provides the following data related to the underlying issue and fix version provided by the matched vendor.\nField Example Value Description Fix Available Since July 22, 2024 The date when a vendor-provided or validated fix became available for this vulnerability from the matched vendor. For more information see Vulnerability Feeds. Fix Suggestion Upgrade package to v25.0.6 Recommended action to remediate the vulnerability, typically by upgrading to a fixed version. For more information see Vulnerability Feeds. Resource to Fix registry.k8s.io/kops/kops-controller:1.28.5@sha256:07e40a04b4f8f3dfedfdfff6... The specific container image or runtime resource where the fix should be applied. Package github.com/docker/docker The affected software package that should be updated. Package Path /ko-app/kops-controller Filesystem location within the container or runtime where the package is installed. Package Type Golang The programming language or ecosystem the package belongs to. For example, Golang, Debian, RPM. Security FeedsSysdig consolidates insights from multiple trusted security feeds to enhance vulnerability context. On the CVE Detail drawer, each vulnerability includes detailed information sourced from all available feeds to support faster, more informed decision-making.\nEach feed includes the following data:\nField Example Value Description Feed VulnDB The security feed that provided this vulnerability information. Severity Critical The severity level assigned by the feed based on its own scoring methodology. CVSS Score v3 9.8 (v3.1) CVSS v3 score as provided by the feed, if available, indicating criticality using the older scoring system. CVSS Score v2 9.3 (v2) CVSS v2 score assigned to the vulnerability if available, indicating criticality using the older scoring system. Vendor Links CVE-2024-41110 Links to external vendor advisories, if provided by the feed. Published Date 17/04/2024 The date the vulnerability information was published by the feed. For more information see Vulnerability Feeds.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/vulnerability-findings/cve-panel/"},{"id":72,"title":"View Findings Details","content":"OverviewThis page offers a comprehensive investigation panel for a specific finding, including:\nFinding metadata and affected asset metadata. Full vulnerability description and CVE background. Context indicators like exploitability and fix availability. Threat intelligence insights (CISA KEV, ransomware use). Remediation guidance for the individualized Finding. Actions like Create Ticket and Accept Finding are readily available to initiate workflows and drive Remediation. HighlightsThe Highlights section of the Findings Details drawer is an overview of the Vulnerability in your environnment, providing context to help you prioritize and understand the risk of the Finding as it relates to your infrastructure.\nAll Affected Resource Summary Affected Resource: Provides the affected resources name and navigate to the Resource Details drawer. Remediations: If a fix is available provides a navigation to the (Remediations)[#remediations] section of the Findings Details drawer. Zones: The zone the resource belongs to. Zones are in Technical Preview. To enable Zones, go to Settings \u0026gt; User Profile. Under Sysdig Labs, toggle Zones scoping for all features on. If Zones is not available from your User Profile, contact your Sysdig representative.\nDescriptionThis section provides a detailed narrative about the vulnerability including high level overviews provided by Sysdig\u0026rsquo;s Vulnerability Feeds including but not limited to:\nBackground on the software or component affected Description of how the vulnerability can be exploited Timeline of discovery, fixes, or regressions Recommendations for mitigating risk if immediate patching is not possible CVE Details Field Value Description Finding Name CVE-2024-41110 The official CVE identifier assigned to this vulnerability, providing a link to CVE 360. Severity Critical The risk level of the vulnerability based on CVSS score and external feeds, provides a clickable link to the Vulnerability Feeds section. For more information see Vulnerability Feeds. Context Exploitable, Has Fix, In-Use Indicates whether the vulnerability is actively exploitable and if a fix is available, or is In-Use. Disclosure Date Tue, Jul 30, 2024 at 03:18:57 AM The date the vulnerability was publicly disclosed by the matched vendor, for more information see Vulnerability Feeds. EPSS 0.00% The Exploit Prediction Scoring System score, estimating the probability of exploitation. EPSS Percentile 0.00% The percentile rank of this CVE relative to other known vulnerabilities. Package github.com/docker/docker v24.0.7+incompatible The software package and version in which the vulnerability exists. Package Type Golang The language or ecosystem of the affected package. Package Path /usr/bin/dive The filesystem location where the package was detected on the impacted resource. Finding Discovered Mon, Apr 28, 2025 at 09:08:18 AM Timestamp when this specific finding was first observed in your environment on the affected resource. Fix Available Since Mon, Jul 22, 2024 at 05:00:00 PM Date and time when a fix became available for this CVE from the matched vendor. For more information see Vulnerability Feeds. RemediationsVulnerability Finding remediations are specific to the individual Finding. It provides the following data related to the underlying issue and fix version provided by the matched vendor.\nField Example Value Description Fix Available Since July 22, 2024 The date when a vendor-provided or validated fix became available for this vulnerability from the matched vendor. For more information see Vulnerability Feeds. Fix Suggestion Upgrade package to v25.0.6 Recommended action to remediate the vulnerability, typically by upgrading to a fixed version. For more information see Vulnerability Feeds. Resource to Fix registry.k8s.io/kops/kops-controller:1.28.5@sha256:07e40a04b4f8f3dfedfdfff6... The specific container image or runtime resource where the fix should be applied. Package github.com/docker/docker The affected software package that should be updated. Package Path /ko-app/kops-controller Filesystem location within the container or runtime where the package is installed. Package Type Golang The programming language or ecosystem the package belongs to (e.g., Golang, Debian, RPM). Security FeedsSysdig consolidates insights from multiple trusted security feeds to enhance vulnerability context. On the Vulnerability Findings page, each vulnerability includes detailed information sourced from all available feeds to support faster, more informed decision-making.\nEach feed includes the following data:\nField Example Value Description Feed VulnDB The security feed that provided this vulnerability information. Severity Critical The severity level assigned by the feed based on its own scoring methodology. CVSS Score v3 9.8 (v3.1) CVSS v3 score as provided by the feed, if available, indicating criticality using the older scoring system. CVSS Score v2 9.3 (v2) CVSS v2 score assigned to the vulnerability if available, indicating criticality using the older scoring system. Vendor Links CVE-2024-41110 Links to external vendor advisories, if provided by the feed. Published Date 17/04/2024 The date the vulnerability information was published by the feed. For more information see Vulnerability Feeds.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/vulnerability-findings/findings-panel/"},{"id":73,"title":"Vulnerability Findings","content":"Understand Vulnerability FindingsThe Vulnerability Findings view provides a detailed, sortable list of all discovered vulnerabilities across your infrastructure. This table is designed for analysts and engineers to drill into specific findings, understand context, and take remediation action.\nEach row in the table represents a unique vulnerability finding, identified by:\nTitle Description CVE ID Common Vulnerabilities and Exposures identifier assigned to the vulnerability. Clicking the CVE navigates to the Vulnerability Findings page for full context. Affected Resource The asset where the vulnerability was detected, such as a container, host, or Kubernetes workload. See Supported Resources for more details. Affected Package and Version The software package and specific version containing the vulnerability. Severity The CVE Severity sourced from the detected context. Where possible, severity is sourced from the vendor. If unavailable, we fall back to NVD, and then VulnDB. For more information, see Vulnerability Feeds. Context Security attributes including: Has Fix – Fix available, In Use – Package is active at runtime, Exploitable – Public exploit exists, Risk Accepted – Finding has been reviewed and accepted. CISA Kev Indicates the vulnerability is part of the CISA KEV Catalog, meaning it\u0026rsquo;s confirmed to be exploited in the wild and should be prioritized. EPSS Score EPSS (Exploit Prediction Scoring System) indicates the likelihood (%) that a vulnerability will be exploited in the next 30 days. Higher scores signal higher real-world risk. Zones Indicates the number of Sysdig Zones the affected resource is part of. More zones may suggest broader infrastructure impact and remediation urgency. Zones are in Technical Preview. To enable Zones, go to Settings \u0026gt; User Profile. Under Sysdig Labs, toggle Zones scoping for all features on.\nIf Zones is not available from your User Profile, contact your Sysdig representative. First Seen Shows the first time the finding or affected resource was discovered by Sysdig components. Useful for identifying aging risks or recent introductions.\nCalculation varies by grouping:\n- None – Time the finding was first seen on the associated resource.\n- CVE – First time the CVE was seen in the environment.\n- Image – First time the affected image was seen.\n- Runtime Resource – First time the specific resource (e.g., container or host) was seen. Number of Findings Count of vulnerability instances for the given resource or grouping. Available when using Groupings. Status Marks findings first detected in the last 24 hours. Useful for identifying recently disovered or published vulnerabilities.. Use this view to:\nReview your findings by scanning severity, exploitability, and runtime context Prioritize what’s real, fixable, and likely to be exploited Grouping FindingsThere are four groupings available within the Vulnerability Findings to select from, they are:\nNone – Every finding is displayed as a single entity (CVE × Package × Resource). CVE – All findings grouped by CVE ID. Image – All findings grouped by the underlying container image from runtime resources. Runtime Resource – All findings grouped by the resource (e.g., pod, container, host, workload) they were detected on. Grouping allows you to pivot your view based on how you prefer to triage and understand the spread of vulnerabilities across your infrastructure.\nThe Vulnerability Findings Pages currently shows Findings only from Runtime Resources. The current Runtime Resources supported are as follows:\nKubernetes Workloads Container Workloads Hosts Prioritizing with FiltersUse filters to focus on the vulnerabilities that matter most, such as those that are in use, exploitable, and have a fix available.\nYou can also refine results using metadata from your runtime resources, such as clusters, namespaces, images, or applications.\nThis helps you cut through the noise and surface only the findings that are real, actionable, and impacting your most critical assets.\nSupported Filters Filter Key Example Description Zone name Production Name of the logical grouping or environment. For example, staging and production. Crit true Filters for critical severity vulnerabilities. High true Filters for high severity vulnerabilities. Med true Filters for medium severity vulnerabilities. Low true Filters for low severity vulnerabilities. Neg true Filters for negligible severity vulnerabilities. Vulnerability hasExploit true Indicates whether a known exploit exists. Vulnerability inUse true Indicates whether the vulnerable package is in use. Vulnerability hasFix true Indicates whether a fix is available for the vulnerability. Vulnerability AcceptedRisk true Indicates if the vulnerability is marked as accepted risk. RuntimeMetadata architecture x86_64 System architecture of the runtime resource. RuntimeMetadata category container Category of the runtime. For example, container and VM. RuntimeMetadata containerName nginx Name of the container. RuntimeMetadata imageId sha256:abc123... Unique ID of the container image. RuntimeMetadata imageReference registry.io/nginx:latest Full container image reference. RuntimeMetadata imageRegistry registry.io Registry where the image is hosted. RuntimeMetadata imageRepository nginx Repository name of the container image. RuntimeMetadata imageTag 1.0 Tag of the container image. RuntimeMetadata manifestDigest sha256:... Digest of the image manifest. RuntimeMetadata operatingSystem redhat 9.5 Operating system used by the container image. RuntimeMetadata platform GCP Cloud platform where the runtime is deployed. RuntimeMetadata type Cloud Run Job Type of runtime metadata source. RuntimeResource accountId 123456789012 Cloud account ID where the resource resides. RuntimeResource clusterName prod-cluster Name of the Kubernetes cluster. RuntimeResource containerId abcdef123456 Container instance identifier. RuntimeResource hostname node-1 Hostname of the runtime node. RuntimeResource isExposed true Indicates if the resource is externally accessible. RuntimeResource location us-west1 Cloud region or location. RuntimeResource name nginx-deployment Resource name within the environment. RuntimeResource namespace default Namespace for the Kubernetes resource. RuntimeResource organization engineering Organizational unit responsible for the resource. RuntimeResource platform eks Platform where the runtime resource is hosted. RuntimeResource projectId my-project Identifier for the cloud project. RuntimeResource status running Current status of the runtime resource. RuntimeResource subscriptionId sub-001 Subscription ID for cloud billing/accounting. RuntimeResource taskDefinitionFamily web-task Task definition family for ECS resources. RuntimeResource taskDefinitionArn arn:aws:ecs:... Full ARN of the ECS task definition. Vulnerability cvssScore 9.8 CVSS base score of the vulnerability. Vulnerability epssPercentile 0.95 Percentile rank of the EPSS score. Vulnerability epssScore 0.82 Likelihood of exploitation based on EPSS. Vulnerability knownRansomwareCampaignUse true Flags if the CVE has been used in ransomware campaigns. Vulnerability name CVE-2024-12345 CVE identifier of the vulnerability. Vulnerability packageName libssl1.1 Name of the vulnerable package. Vulnerability packageType Java Package type. For example, Java, Golang, and OS. Reviewing Findings in DetailEach row in the table is clickable. Clicking a finding opens Findings, where you’ll see in-depth context including affected packages, runtime usage, exposure indicators, and remediation actions.\nUse this to investigate:\nWhat exactly is affected Whether it\u0026rsquo;s active in runtime If it has an exploit or known fix Which environments or Zones it spans This flow helps teams move from detection to action with full visibility and confidence.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/vulnerability-findings/"},{"id":74,"title":"Agent Release Notes 2022","content":"12.10.1 December 20, 2022This hotfix fixes the issues discovered in the YAML tab of Advisor in Sysdig Monitor. Clicking the YAML tab now works as expected and continues to display YAML configuration for pods.\n12.10.0 December 15, 2022Feature EnhancementsSupport for Secure Light ModesA new agent mode, secure_light, has been introduced to provide you with a limited set of secure features. The features supported in this mode are:\nRuntime Policies Activity Audit (only executed commands) Captures Sysdig agents running in secure_light mode consume fewer resources than those running in secure mode.\nFor more information, see Secure Light.\nAdd Agent Configuration to Prevent Container OperationsA new agent-level configuration, ignore_container_action, has been added to prevent Sysdig agent from taking potentially disruptive container operations, such as kill, pause, stop, regardless of the policy.\nThis configuration is disabled by default. To enable it, add the following to the dragent.yaml file:\nsecurity: ignore_container_action: true When the configuration is enabled and a policy instructs the agent to perform a container operation, the agent ignores the policy and creates an Info log message explaining the agent did not perform the action because of the configuration.\nSee also: Manage Threat Detection Policies | Containers\nImproved Scope MatchingThe scope matching for runtime policies has been improved by using equivalent container labels when corresponding kubernetes labels are temporarily not available.\nThe following settings determine the behavior. The example shows the default values.\nsecurity: use-container-labels-mapping: true container_labels_map: - \u0026#34;kubernetes.pod.name: container.label.io.kubernetes.pod.name\u0026#34; - \u0026#34;kubernetes.namespace.name: container.label.io.kubernetes.pod.namespace\u0026#34; IMDSv2 Support on AWS DeploymentsA new agent-level .yaml configuration, imds_version, should be set to 2 on all the deployments that require token-based communication with the Amazon Web Service (AWS) metadata service IMDSv2:\nimds_version: 2 To continue using the IMDSv1 style AWS metadata requests, leave the configuration unchanged or set it to 1.\nimds_version: 1 Fix Vulnerabilities Updated the Go version used for Promscrape to 1.18.7 to resolve Common Vulnerabilities and Exposure (CVEs). Updated Jackson library to resolve CVE-2022-42003 and CVE-2022-42004. Upgraded snakeyaml to 1.32 in sdjagent to address CVE-2022-38752. Disabled Superfluous Memory Consumption ChecksDisabled the agent watchdog from checking memory consumption when running in Kubernetes since Kubernetes has its own resource management. If you wish to re-enable the agent watchdog to check memory consumption when running in Kubernetes, set the following config parameter:\nwatchdog: check_memory_for_k8s: true Report Additional Labels for Cost AdvisorModified the default Kubernetes label filters to allow the collection of additional labels to identify the instance, region, zone, and the operating system of the nodes. The additional labels help to calculate costs associated with your infrastructure.\nIdentify Delegated AgentsAdded the statsd_dragent_subproc_cointerface_delegated metric to indicate whether the agent is delegated or not.\nImproved Retrieval of Container MetadataImproved fetching container metadata when both Docker and CRI runtimes are available. This reduces problems where runtime policy events have missing container information.\nKnown IssuesThe YAML tab in Advisor in Sysdig Monitor that displays pod structure, similar to a kubectl describe operation, might not work as expected. Clicking the YAML tab can lead to an agent restart, and as a result, a temporary loss of metrics.\nAs a workaround, disable it in the dragent.yaml file as follows:\nk8s_command: enabled: false Defect FixesReport all Storage ClassesThe agent now reports all storage classes instead of just one. Earlier, the agent only sent one storage class from global_kubernetes in the metrics protobuf even when multiple storage classes existed in the cluster.\nMatch Group Name and User Name Appropriately in EventsEvents now reports group.name and user.name correctly. Previously, there was an issue where root ID got resolved as N/A for containers in some cases.\nContainer Terminal Shell No Longer Returns N/AImplemented container password and group lookup to prevent terminal shell in container returning N/A for the user.name.\nGenerate Command Execution Records for ARMFixed an issue with the activity audit where command execution records were not being generated on ARM processor systems, for top-level processes executed within a container, and with no associated TTY.\nReports Labels Correctly on Pod RedeploymentFixed an issue with promscrape where the agent would report the old pod UID when a pod is redeployed. This led to having all the labels missing from the timeseries scraped from that pod.\nFix JMX Monitoring on Newer JRE VersionsFixed an issue where JMX monitoring did not work correctly on newer JRE versions due to sdjagent exceptions\n12.9.1 November 14, 2022Defect FixesFixed Legacy Proxy Connection Between Agent and CollectorThe legacy mode of the proxy connection between the agent and the collector works as expected. You can continue to configure if need be.\nFix Enriching Prometheus Metrics with Labels PeriodicallyFixed an issue where most labels would be dropped from Prometheus metrics every 5 minutes. This issue only affected the Kubelet jobs associated with Prometheus Integrations as well as the custom job configuration declared by the user.\nFix VulnerabilitiesFixed the following vulnerabilities:\nCVE-2022-42003 CVE-2022-42004 CVE-2022-40674 CVE-2022-3515 CVE-2022-32149 12.9.0 October 11, 2022Feature EnhancementsAdded New KSM MetricsSysdig agent now collects the following Kube-State-Metrics (KSM) ingress metrics:\nkube_ingress_info kube_ingress_labels kube_ingress_created kube_ingress_path kube_ingress_tls Also, the Sysdig agent collects the following KSM certificate signing request metrics:\nkube_certificatesigningrequest_created kube_certificatesigningrequest_condition kube_certificatesigningrequest_labels kube_certificatesigningrequest_cert_length Expanded Node Resource MetricsThe Sysdig agent now sends all the Kubernetes node resource metrics to the Sysdig backend, rather than just CPU, memory, and pods. This allows you to query kube_node_status_capacity and kube_node_status_allocatable node metrics for the following resources.\ncpu=\u0026lt;core\u0026gt; ephemeral_storage=\u0026lt;byte\u0026gt; pods=\u0026lt;integer\u0026gt; attachable_volumes_*=\u0026lt;byte\u0026gt; hugepages_*=\u0026lt;byte\u0026gt; memory=\u0026lt;byte\u0026gt; Additionally, the agent now supports a configuration to collect extended resource metrics on a node. To enable the agent to collect the extended resources, add the following to the dragent.yaml file:\nk8s_node: extended_resources: true Upgraded Vulnerable Go Packages in Promscrape v1Upgraded Prometheus version and resolved vulnerabilities in Promscrape v1.\nRetry CRI API Calls After Failed Async AttemptsThe Sysdig agent now automatically retries querying the CRI API server after a failed attempt, with a backoff timeout strategy. This improves upon the former strategy of trying only once with a configurable delay value (cri:delay).\nAdded Error Traces when Open SSL Connection FailsAdded new error messages in the agent log to help identify the nature of connection problems in the collector, when they arise.\nReport Taint Information for Kubernetes NodesThe Sysdig agent will now send taint information associated with Kubernetes nodes. This enables you to query node taints using the kube_node_spec_taint metric in Sysdig Monitor.\nKnown IssuesThe s390x architecture image is not available for v12.9.0; therefore, this version of the agent cannot be installed in zLinux. Note that using the latest tag for agent images on zLinux will not work until the next agent version is released.\nDefect FixesRestarting Agent No Longer Causes Kernel PanicFixed an issue in the Sysdig agent\u0026rsquo;s kernel module that could cause a kernel panic when the agent was restarted.\nSupport Arbitrary Java Command NamesAdded a configuration parameter to allow you to specify the command names to launch Java processes. This helps detect Java processes for JMX metric collection.\nFor example, if you want the agent to detect a process by the name of jsivm , while still detecting the other commands, add the following to dragent.yaml:\njmx: java_commands: - java - jsvc - jsivm The values specified in dragent.yaml will override the default values, therefore, you need to include the defaults if you want to continue detecting them.\nCaptures No Longer Corrupted in Certain HostsSysdig Monitor no longer produces corrupted Capture files in certain hosts in a cluster. Previously the Capture files were found corrupted when generated on a host selected from Explore \u0026gt; Hosts \u0026amp; Container.\nReport Containers as ExpectedFixed an issue where containers would not be reported if the agent had issues communicating with the Kubernetes API server.\nUpgraded psycopg2 ModuleUpgraded psycopg2 module to v2.8.6 to fix issue where Postgres AppCheck fails to start due to missing libpq.\nBuild Kernel Modules on RHEL6Fixed an issue preventing the kernel module from building on RHEL6 and other kernels of similar vintage.\nReport Unschedulable PodsFixed an issue where unschedulable pods would not be reported by the agent.\nInitialize Agent on Latest KernelsPreviously, the agent failed to initialize on the latest kernels, such as Ubuntu v22.04 and Fedora 35 and 36, with the following error:\ngcc: error: unrecognized command-line option '-mharden-sls=all'\nThis has been fixed.\nDisabled the Policy Scope CacheThe scope cache has been disabled by default to prevent it from getting stuck due to longer completion periods for Infra state.\nUpdated kube-bench and kubectl BinariesUpdated the Go version used for building kubectl and kube-bench binaries to address vulnerabilities.\nFixed Output Message in the Launch Sensitive Mount Container RuleThe Launch Sensitive Mount Container rule in the Suspicious Container Activity 2 policy no longer shows incorrect information in its output.\nFixed Output Fields in Custom RulesFixed an issue where not all the required secure event output fields were being generated by the agent.\n12.8.1 August 29, 2022Defect FixesFix Vulnerabilities in Promscrape v1Upgraded the Prometheus version and resolved vulnerabilities in Promscrape v1.\nRemoved Symbolic Link to /etc in the Agent ContainerThe agent can now read information on users and groups from /host/etc/passwd and /host/etc/group when the agent is running as a container.\nShow Falco Events as ExpectedFixed a bug where the Falco output string for a rule would be cut on the first absent or empty field.\n12.8.0 August 02, 2022Feature EnhancementsAdded a New Metric for Retrieving Kubernetes StateAdded an internal metric, statsd_dragent_subproc_cointerface_ready, to indicate when the agent has pulled Kubernetes state from the API server.\nRead Certificate ChainImproved the agent\u0026rsquo;s handling of certificate chains. Previously, the agent would only accept the first certificate in a certificate chain and would attempt to verify all other certificates from the configured certificate store. This behavior is compliant with the TLS specification, but idiomatic usage in the wild requires the agent to accept intermediate certificates provided in the handshake as well. The agent will now accept these certificates when provided.\nFalco Rules OptimizerThe optional feature Falco Rules Optimizer is now available. This feature increases the speed of syscalls evaluation against Falco rules by introducing indexing on the rules conditions and by caching partial rule condition evaluations. This feature is available in Sysdig agent, but not in open-source Falco.\nTo enable the feature:\nSet falco_optimizer.enabled to true (default value is false). New Falco Rules ParserStarting from version 12.8.0, Sysdig agent will use a new Falco rules parser from OSS (open-source software) Falco. The new OSS Falco parser performs stricter grammar parsing and would fail on the following cases:\nwhen \\n is used instead of , in a list when \u0026quot;[\u0026quot; is present in a rule definition when \\034 surrounded by \u0026quot; is present in a rule definition when the or operation is used between lists instead of with the in operator. For example: condition: open_write and fd.filename is (list1 or list2) When any of the above cases are present in a custom rules file, the agent fails to parse the respective rule and returns the following error:\nError, security_mgr:791: Could not load policies_v2 message:.\nIn such cases, edit the custom rules to correct or remove unparsable grammar.\nDefect FixesProcess Kubernetes Audit Events as ExpectedAgent no longer throw errors while processing Kubernetes audit events when Kubernetes audit rules contain the endswith condition.\nUpgraded Go Language PackagesGo language packages have been upgraded to fix vulnerabilities\nFix VulnerabilitiesFixed the following vulnerabilities with Promscrape v2:\nCVE-2015-3627 CVE-2021-3121 CVE-2020-14040 CVE-2014-6407 CVE-2014-9356 CVE-2014-9357 CVE-2022-23648 CVE-2022-27191 CVE-2021-41103 CVE-2020-15257 CVE-2014-9358 CVE-2021-21334 CVE-2020-13401 CVE-2014-5277 CVE-2020-13401 CVE-2020-8565 CVE-2021-32760 CVE-2021-20329 CVE-2019-11254 CVE-2021-4189 CVE-2020-8565 CVE-2021-4189 CVE-2021-3737 CVE-2021-3634 CVE-2021-3634 CVE-2021-3737 CVE-2022-1996 Detect Prometheus Targets CorrectlyFixed a problem that was causing new Prometheus targets to not be detected until an agent restart.\nIntermittent Scraping Failure No Longer Causes Missing MetricsFixed an issue of missing metrics caused by intermittent metrics scraping failures.\nShow Falco Events as ExpectedSysdig agent now throttles redundant secure events for compliance policies reducing the event noise.\nShow Username Correctly in Policy EventsFixed an agent build issue that rendered password and group functions unavailable. Linked the password and group from /host/etc inside the agent container so the username is correctly shown in policy events.\nFixed a Logging Issue in Promscrape v2Fixed a logging issue with Promscrape v2. Log levels now take effect as expected when passed in with --log.level.\nFixed Agent BehaviourFixed an issue that might cause all the agents to behave as delegated.\n12.7.1 July 06, 2022Defect FixesFixed memdump.size IssueFixed the memdump.size configuration, which was not accepted earlier.\nFixed Promscrape Crash IssueFixed an issue in Promscrape v2 where a node with a large number of pods and multiple containers per pod could crash.\nFixed Issue Affecting Two Agent ModesFixed a problem that caused agent subprocesses to be killed in nodriver mode. This affects the custom-metrics-only and monitor_light modes. For more information, see Configure Agent Modes.\n12.7.0 June 28, 2022Feature EnhancementsNew Helm ChartSysdig released a unified Helm chart, sysdig-deploy with the following benefits:\nEasier to deploy multiple components with one chart, rather than using multiple separate charts Fewer errors by way of using common configuration for components Auto-detection of certain configurations, including eBPF for Google Kubernetes Engine (GKE) Contained-Optimized OS (COS) and endpoint region. We will maintain the old version of Helm chart, sysdig chart for a period of six months. In this period, the Sysdig chart will be updated with new component versions and defect fixes.\nLive LogsSysdig Monitor displays Live Logs in Advisor to help you troubleshoot Kubernetes, which is the equivalent of running kubectl logs. Live logs are displayed on-demand and not stored by Sysdig.\nSupport Prometheus v2.32Updated Prometheus scraper to version 2.32.\nMetrics Collected in Custom Metrics Only ModeWhen custom-metrics-only mode is used, no process metrics are collected. Additionally, only the metrics related to resources (for example, CPU and memory) are collected for containers and host.\nKnown IssuesWhile the agent is running, you might encounter an error similar to the following:\nError, security_rule:610: Could not parse rule xx from rules json array\nThe rule number in the error message might change depending on how many rules are defined.\nThis is a known issue related to failing to parse an experimental rule. The parser will skip this rule and will log the error message as above. The agent performance and policy evaluation will not be affected.\nDefect FixesRemove Ceph App ChecksFixed a problem where errors for obsoleted app checks would be shown when Ceph was running on the host.\nDisable Timeseries CachingRemoved a configuration option that stopped Prometheus jobs reporting timeseries when the scrape failed temporarily.\nBuilds eBPF Probes in BottlerocketFixed an issue that prevented eBPF probes from being built by the agent in Bottlerocket Environments.\nReports Infrastructure State CorrectlyFixed an issue where the Sysdig agent would opens a stream to Cointerface even when it is disabled. This resolves the issue of infrastructure state constantly resetting.\nSend Only Supported Metrics in Nodriver ModeFixed an issue where unused container and process metrics were sent while in nodriver mode.\nChange Log Level to DEBUG When Excessive Log Level OccursThe excessive logging level occurs under specific conditions, for example, a pod whose used memory results in zero. This case seems to be normal for small pods using very little memory. A fix has been provided so that, when these conditions are detected, the log level for the message that is polluting the logs is brought from INFO to DEBUG.\nReport Container Resource Limits and Requests CorrectlyFixed an issue where container resource limits and requests would appear as zero when no limit or request was configured.\n12.6.0 May 16, 2022Defect FixesReloading Promscrape v2 No Longer Causes Dropping Scrape TargetsReloading Promscrape v2 no longer causes some scrape targets to be dropped from sending metrics.\nPrevented Duplicate Node EventsResolved an issue where duplicate events were generated when a Kubernetes node was lost.\nAgents Connect to SaaS Backend Through HTTP Proxy on Older HostsFixed an issue related to SSL certificate verification when connecting through an HTTP proxy on an older host OS, such as CentOS 7.\nAgent Refreshes Service Account Token as ExpectedConnection with the Kubernetes API Server now works as expected. The Kubernetes client is configured to refresh the bearer token.\n12.5.0 May 02, 2022Feature EnhancementsDefault Availability of Slim AgentThe agent installation defaults to the slim agent. The slim agent reduces the surface area for potential vulnerabilities as compared to the full agent, which implies increased security for your monitoring environment. For more information, see Agent Installation.\nTo continue using the regular agent:\nSet slim.enabled to false in your Helm chart. Monitoring Kubernetes ResourcesSysdig agent v12.5.0 and above no longer collects the Horizontal Pod Autoscaling (HPA) kube state metrics by default. To enable the agent to collect HPA kube state metrics, you must edit the agent configuration file, dragent.yaml, and include it along with the other resources you would like to collect. For more information, see Enable Kube State Metrics.\nContainer DriftControl: Detect and Prevent Drift in Container RuntimeSysdig agent can now detect when a new executable was added to a container after a container has started up. The agent collects when a file was downloaded and made executable. When using prevention mode, the agent can also deny the process from ever running. A policy can also be used to define binaries that should be denied/excluded from being denied if they have been added after the container has started.\nSee also: Drift Policy\nDisable Syscalls for Secure ModesSwitch syscall events are disabled for secure and secure light modes.\nKnown issues An error message is displayed when the agent detects Ceph and attempts to run an obsoleted app check. The Sysdig agent for ARM can restart when multiple containers are started in rapid succession on the host. Defect FixesAgent on zLinux No Longer Restarts Due to Incorrect Detection of tid CollisionsThe agent on s390x architecture (zLinux) has been fixed so the agent does not restart needlessly due to incorrect detection of too many tid collisions.\nReports Correct CronJob Version When Adding CronJob ParentsFixed an issue causing CronJobs not to be reported as the parents of Job objects.\nAgent No Longer Crashes During Abnormal TerminationFixed an issue causing the agent to crash with a stack backtrace during certain abnormal termination situations.\nSlow-Starting JVMs are Terminated CorrectlyAn incorrect detection of too many tid collisions on s390x architecture (zLinux) will no Longer cause the agent to restart periodically.\nFixed Kubernetes Fetch IssueFixed an issue that could prevent Kubernetes events from being correctly fetched.\nDisable Watching HorizontalPodAutoscalerWatching Horizontal Pod Autoscalers has been disabled by default to decrease load on Kubernetes API server. For more information, see Enable Kube State Metrics.\nFalse Positive CVEs for Go Packages No Longer ReportedThe Go compiler version has been upgraded to prevent being flagged with false-positive CVEs associated with older Go versions.\nSecure Events Reports Correct Cluster InformationSecure events no longer report Kubernetes cluster name default when no cluster exists in the environment.\n12.4.0 April 04, 2022Feature EnhancementsSupport for New ArchitecturesInstalling agent on the following architecture are supported:\nARM (aarch64)\naarch64 environments support AWS Graviton.\ns390x (zLinux)\nFor more information, see Host Requirements for Agent Installation.\nARM support includes AWS EC2 Graviton platform\nCustom-Metrics-Only ModeA new agent mode, custom-metrics-only, has been introduced. It enables all custom metrics and Kubernetes state metrics but disables all the driver-based metrics.\nPrevented Unnecessary MessagesFixed a case where a message would be sent to reduce CPU usage when no changes were required.\nKnown IssuesConfigure Node Lease to Decrease Resource ConsumptionIncorrect configuration of Kubernetes lease can result in elevated memory usage in the Sysdig agent pods as well as increased load on the Kubernetes API server due to multiple agents querying for more information simultaneously. This also results in a significant amount of additional and unnecessary load on the Sysdig backend.\nTo decrease resource consumption:\nUpgrade to Sysdig agent 12.5.0 which adapts to the non-optimal Kubernetes configuration. Configure the Kubernetes lease functionality. If you are using Helm, the latest versions of the Sysdig Agent Helm chart defaults to configuring the lease functionality automatically. If you do not use Helm, the DaemonSet and ClusterRole YAML files are available in our gitbub repository. For further assistance, contact Sysdig Support.\nPrevent Periodic Agent Restarts on zLinuxAn incorrect detection of too many tid collisions on s390x architecture (zLinux) can cause the agent to restart periodically.\nTo workaround this issue, set the following configuration option:\nwatchdog: analyzer_tid_collision_check_interval_s: 86400 This reduces the number of restarts to once a day instead of every ten minutes, which is the default value for the above configuration option. The value is in seconds; there are 86,400 seconds in a day.\nThis issue has been fixed in Sysdig agent v12.5.0.\nDefect FixesValidate Promscrape Scrape JobsFixed an issue causing errors with scrape jobs. Scrape jobs associated with Promscrape are now validated before scraping the endpoints.\nRemoved Irrelevant Warning Messages about App ChecksRemoved unnecessary warning messages about app checks limits when app checks are disabled.\nSlow-Starting JVMs Are No Longer TerminatedSlow starting JVMs can be terminated by sdjagent. For example, -XX:+AlwaysPreTouch with large heaps. This fix introduces additional configuration options to tune the delay between sdjagent detecting a started JVM process and an attempt to connect.\njmx: monitor_connect_timeout_ms: 5000 management_agent_connect_delay_ms: 0 EVE Connector Works as Expected in KubernetesFixed metadata incompatibility in profiling with Kubernetes versions above 1.20.\nName Change to Configuration ParameterThe falcobasline.max_drops_buffer_rate_percentage parameter has been corrected to falcobaseline.max_drops_buffer_rate_percentage. Notice the missing e in falcobasline in falcobasline.max_drops_buffer_rate_percentage. However, backward compatibility is ensured, and therefore, falcobasline.max_drops_buffer_rate_percentage can still be used.\n12.3.1 March 03, 2022Defect FixesNoisy Messages SilencedRemoved a kernel message from the driver that could generate spam when the syscall event buffer is full.\n12.3.0 February 17, 2022Feature EnhancementsBinaries Category for Falco BaselineAdded a new category, binaries, to the Falco baselines feature.\nSupport for Workload Information in Falco BaselineAdded workload information to Kubernetes context for Falco baselines.\nDefault Monitoring of Kubernetes ResourcesThe following Kubernetes resources are now monitored by default:\n- persistentvolumeclaims - persistentvolumes - storageclasses - horizontalpodautoscalers Known IssuesIPv6 Addresses Are Saved Incorrectly When Adding RulesAdding a new rule causes problem saving IPv6 address for both fd.net and fd.ip.\nDefect FixesFix Truncated Capture FilesFixed a problem which caused the agent to generate truncated capture files.\nContainer Action Pause Work on Kops/GKE ClustersFixed the logic that determines the cgroup path for a container in containerd and made the freezer subsystem available to the agent in order to be able to pause and unpause it.\nAgent Profiling Works as ExpectedHigh CPU load no longer prevents CPU and memory profiles from being generated in the agent.\nAgents Are Not Reset with Signal 11Large and negative file descriptors are handled correctly so agents are no longer reset with signal 11.\n12.2.1 February 07, 2022Feature EnhancementsManage Collecting Metadata from Individual Container EnginesAccess to individual container engines from within the agent for fetching metadata can now be disabled via agent configuration.\nFor example, to disable docker, use the following configuration:\ncontainer_engines: docker: false Known IssuesThe Pause policy action is not working as expected in GKE, Elastic Kubernetes Service (EKS), and Openshift4 environments.\nDefect FixesPolicy Action \u0026ldquo;Kill\u0026rdquo; Is Correctly Triggered in GKE EnvironmentsPolicy action on GKE with containerd works as expected:\nThe container is stopped if HTTP proxy is enabled. The status of the container is checked upon stop requests. If the status is not CONTAINER_EXITING, termination of the container is attempted with exponential backoff. Agents Assign Username Correctly for Container EventsFixed an issue that prevented the proc.name field from extracting the right user from the container started events. This issue was found in agent versions 12.2.0 and above.\n12.2.0 January 25, 2022Feature EnhancementsImprove Install Script to Support eBPFA new option, bpf or -b is added to the native install script of Sysdig agent to support eBPF.\nEnable 10s Flush by DefaultBy default, the agent collects metrics at 1-second granularity, then aggregates and sends them to the backend in 10-seconds intervals. If you want to use agent versions 12.2.0 or above with the on-prem Sysdig Platform versions below 3.5.0, set the 10s_flush_enable configuration to false to prevent compatibility issues.\nThe backend in our SaaS deployments continues to enable 10-second flush automatically for all agent versions 10.0.0 or above.\nImproved Log MessagesImproved the log messages to report the errors encountered while configuring subprocess_resource_limits.\nHandling Incorrect Metric FormatWhen scraping Prometheus metrics, the agent will set the type to PROMETHEUS_TYPE_INVALID if the metric is exported in an incorrect format or without a specified type. The metric will still be ingested by Sysdig and the query will fallback to gauge.\nKnown IssuesProcessing Secure policy updates in the agent can take longer than it did in the previous releases, and, in some rare scenarios, it causes agent restarts.\nDefect FixesFix CVE-2020-29652 in CointerfaceUpdated crypto go module to fix CVE-2020-29652.\nPromscrape V2 No Longer Crashes on Pods with Multiple ContainersPrevent promscrape_v2 from crashing when a pod has multiple containers.\nskip_events_by_type Works as ExpectedFixed an issue in the kernel probe, which prevented the skip_events_by_type feature from correctly filtering events by system call type.\nKubernetes State Is Transmitted as ExpectedFixed an issue where Kubernetes information and metrics would not be sent from the agent. This scenario arose when the agent was deployed in a namespace other than sysdig-agent, and the agent daemonset did not include the podinfo volume.\nAgent Successfully Connects to JMXFixed an issue where agent wouldn\u0026rsquo;t connect to JMX on some applications/JVMs. This issue was originally observed on the WebSphere application and Liberty JVM.\nAgent Updates Container Status as ExpectedFixed an issue where the agent would not update the container status it first received from the API server. The agent now updates the container statuses as it receives them from the API server.\nCheck for Invalid Log Level in sdjagentFixed an issue where using a log level of none caused sdjagent to crash.\nApp Checks Run as Expected on Non-Containerized Agent InstallationsFixed an issue preventing app checks running on non-containerized agent installation.\nNative Install Doesn\u0026rsquo;t Support eBPFNative install prevents insertion of Sysdig probe kernel module when the agent is installed with eBPF by using rpm or deb package.\nPrevents Connection Attempts When Agent Encounters ErrorsConnection attempts are prevented when the agent encounters errors while handling handshake messages.\n","url":"https://docs.sysdig.com/en/release-notes/linux-agent-release-notes/2022-archive/"},{"id":75,"title":"Secure SaaS Release Notes 2023","content":"December 21, 2023Inventory General Availability (GA)Sysdig is pleased to make our Inventory feature available by default to all Secure SaaS customers with the following capabilities:\nUnified Data - leveraging our Cloud Attack Graph to combine posture, vulnerability, configuration, and network exposure findings as well as runtime insights on your resources\n“Featured Filters” panel - to ease your search experience\nImage as a Resource - container images are returned as a first-class citizen\nImage and Workload Vulnerabilities - view and search on vulnerability data (CVE, Package, Exploit, Fix, In Use\u0026hellip;)\nNetwork Exposure on Vanilla K8s Workloads, AWS EC2s and S3 buckets, Azure VMs, and Blob Containers - display and query resources that are directly or ingress-exposed to the internet\nNew resource metadata is available:\nSearch for Containers and Image Pullstrings on K8s Workloads Search by Namespace for IaC K8s Workloads Search for cloud resources by ARN for AWS or Resource ID for GCP and Azure Unique URL for each resource (in addition to applied search filters) which can be shared with your teammates/ colleagues.\nSee Inventory for details.\nHost Scanner v0.7.2Released Host Scanner v0.7.2. This update fixes an issue that can occur when scanning Podman v3 containers using Non-Kubernetes Container Scanning configuration.\nDecember 20, 2023Improved Jira IntegrationVulnerability Management (VM) has now been fully integrated with Jira. Click on any vulnerability in the the VM module to create a fully-fleshed out Jira ticket, which you can assign to a colleague from the comfort of the Sysdig UI. Sysdig will then remember which vulnerabilities have Jira tickets.\nSee Remediate with Jira for details.\nSplunk IntegrationSplunk has been integrated with Vulnerability, joining the ranks of Jenkins and ServiceNow. Fetch, triage and orchestrate Sysdig runtime vulnerabilities in Splunk with a Technical Add-On (TA). The Splunk TA enables the extraction of all Runtime scan results.\nDownload the Sysdig Vulnerabilities add-on from Splunkbase to get started, as described in Vulnerability Integrations |Splunk.\nNon-Kubernetes Container ScanningScan Docker and Podman containers for vulnerabilities with Sysdig Secure.\nFor more information, see Non-Kubernetes Container Scanning.\nDecember 18, 2023Agentless Host Scanning (Technical Preview)On AWS EC2 hosts, you can now perform agentless runtime vulnerability scanning. You can also view all discovered hosts, get real-time status updates, and troubleshoot issues with the Cloud Hosts page in Data Sources.\nSee AWS Agentless Installation for details.\nRuntime Scanner v1.6.7 ReleasedIntroduced an environment variable to override the containers-storage configuration to prevent cri-o crashes.\nDecember 15, 2023Risk Spotlight General Availability (GA)The Vulnerability Management team is excited to announce the official release of Risk Spotlight (aka EVE or “In Use”). After several iterations of the agent, profiling service, and vulnerability management integration stages to address accuracy and computational requirements, the Risk Spotlight service is officially GA.\nWith Sysdig agent v12.15+ and runtime vulnerability management scanning, you can identify and prioritize packages that are both vulnerable and actively “In Use” in runtime workloads.\nWe also enable external integrations with partners that use this data, such as Snyk and Docker.\nSee Risk Spotlight (In Use) and Risk Spotlight Integrations for details.\nDecember 13, 2023Leverage Artificial Intelligence for AWS Console Login Anomaly DetectionWith the AWS Machine Learning (ML) policy, you can detect anomalous AWS Console login events in connected AWS cloud accounts.\nThis policy allows you to understand why an event is considered anomalous compared to the expected behavior. In addition, you get visibility into the most influential contributing factors and the confidence level of the detection accuracy.\nFor details, see the AWS ML Policy documentation.\nDecember 12, 2023Inline Scanner v1.6.3 ReleasedCorrected the format of the publish date of a vulnerability in the JSON output.\nRuntime Scanner v1.6.6 Released Updated label processing logic\nAdded the published date of a vulnerability\nDecember 4, 2023Extend Posture to Use Auto-Remediation with AWS Cloud ResourcesThis feature allows you to automate the process of maintaining and improving the security and compliance posture of your AWS infrastructure, reducing the risk of security breaches and operational disruptions. This extends remediation to AWS Terraform resources.\nFirst, create Terraform configuration files that define the desired state of your AWS resources. Sysdig provides automated remediation for fixing risks by opening a PR directly on the IaC code files for your acceptance.\nFor details, see Compliance - Evaluate and Remediate.\nRBAC Permissions available in Posture for Accept Risk, Open PRAdministrators can now define which roles are permitted to accept risks, manage accepted risks, and open pull requests for posture/compliance findings, using granular permission items under\nSysdig Secure → Posture:\nCompliance → Read: Access compliance results Risk Acceptance → Read, Edit: View, manage, revoke, and edit Posture risk acceptance Open PR → Edit: Set up a pull request for posture findings remediation Existing Default Roles: Team Manager and Advanced User now have Edit permission for Posture Risk Acceptance and Open PR.\nFor details, see Detailed Role Permissions.\nDecember 1, 2023Inline Scanner v1.6.2 Released Fixed a defect that could cause missing accept risk results with packages including a release and epoch in package version Added the publish date of a vulnerability in the JSON output Updated dependencies to address security vulnerabilities November 22, 2023Event Forwarding Directly from Sysdig AgentWith Sysdig agent v. 12.18+, it is possible to send Runtime Policy Events and Activity Audit events to SIEM platforms and logging tools directly from the agent. This enables event forwarding without exposing the data collection tool on the internet.\nFor details, see Agent Local Forwarding.\nReport Policy Actions in Kubernetes EventsWith Sysdig Agent v.12.18, Sysdig Secure now supports reporting threat detection policy actions in Kubernetes events.\nWhen the agent performs a stop, pause, or kill container action as defined in a rule, the agent will generate a Kubernetes event with the triggering action details and rule name. You can then see why actions were taken directly from the kubectl events, without having to explore the event feed in Sysdig Secure.\nFor details, see Report Policy Actions.\nLegacy Inline Scanner v 2.4.26 ReleasedFixesVulnerability fixes for the following high-severity CVEs:\nCVE-2023-39325 CVE-2023-44487 CVE-2023-43804 CVE-2023-40217 CVE-2023-46136 November 16, 2023Runtime Scanner v1.6.4 ReleasedUpdated dependencies to address security vulnerabilities.\nNovember 13, 2023Improved Home PageSysdig is pleased to announce a new and improved Home page! The Home page offers a clean, visual representation of the most important issues in your environment and a curated list of the top tasks required. The default tab Home encompasses the Dashboards and the other tab contains Recommendations.\nFor the Home page dashboards to display data, you must have completed basic onboarding and at least one data source must be connected. Otherwise, the page will provide prompts for completing those setup tasks.\nWhat is displayed in Dashboards is dependent on what has been installed.\nFor details, see the Home page documentation.\nStar Favorite Compliance ViewsYou can now select specific Policy + Zone combinations you want to see tracked on the Home page.\nFor details, see the Compliance documentation.\nOctober 26, 2023Custom Posture Controls AvailableYou can now tune your compliance results by customizing your posture controls.\nTo edit evaluation parameters on select Posture Controls, see configure evaluation parameters.\nRuntime Scanner v1.6.3 ReleasedUpdated several dependencies to address security vulnerabilities.\nOctober 20, 2023VM Registry Scanner v0.2.50 with Google Artifact Registry and Sonatype Nexus Repository SupportSysdig is pleased to announce the release of the registry scanner v0.2.50 with chart v1.1.11. The new version offers the following:\nSupport for Google Artifact Registry (new registryType=gar) Support for Sonatype Nexus Repository (new registryType=nexus) For more information, see Install Registry Scanner.\nInline Scanner v1.6.1 Released Added a link to the Red Hat Security Advisory in the JSON output of the scan result Updated dependencies to address security vulnerabilities Runtime Scanner v1.6.2 Released Fixed a misbehavior that could lead to erroneous \u0026ldquo;in use\u0026rdquo; results for Python-related vulnerabilities Updated to use vulnerability database v2 by default Updated dependencies to address security vulnerabilities October 17, 2023Legacy Inline Scanner v 2.4.25 ReleasedFixesVulnerability fixes for the following CVEs:\nCVE-2023-3899 CVE-2023-37920 October 10, 2023Reporting for Image Pipeline Vulnerability ScanningThe Vulnerability Management (VM) team is pleased to announce the release of Reporting for Image Pipeline scanning.\nThe Vulnerability Management engine now provides reporting for all scanning functionality (Runtime, Registry, Host, and Pipeline). Pipeline reporting mirrors the Runtime and Registry reports, with just a change in the scoping context.\nThis feature enables the easy collection and reporting on Pipeline scans over a given time period. With this addition, we have completed normalizing the data output functions across the Vulnerabilities scanning set.\nFor more details, see Reporting for Image Pipeline scanning.\nInline Scanner v1.6.0 Released Updated dependencies to address security vulnerabilities Updated to use vulnerability database v2 by default September 28, 2023Admission Controller v0.14.9 ReleasedKubernetes audit events are now enriched with container metadata to give additional insight into your infrastructure. With this enhancement, all the pod events now display container.name, pod.name, and pod.namespace labels. You can view these labels on the Secure Event detail panel for events such as Create HostNetwork Pod and Attach/Exec Pod.\nSeptember 27, 2023Customize Posture Controls SeverityAll Posture Controls can now be configured to edit the control severity.\nAdministrators can control which roles are permitted to see and edit posture controls using a new permission item under Sysdig Secure \u0026gt; Policies \u0026gt; Posture Controls (Read, Edit).\nExisting Default Roles: Team Manager and Advanced User now have Edit permission for Posture Controls.\nFor details, see Configure Severity.\nSeptember 26, 2023Exception UI Improvements for Threat Detection RulesSysdig has introduced a new, user-friendly exception builder. The new exception UI, built into the Rules Editor, helps users create, update, modify, and delete exceptions for threat detection rules.\nFor more information, see Manage Threat Detection Rules.\nSeptember 21, 2023Cloud LogsSysdig has introduced a new product bundle intended for users who are interested in Cloud Detection and Response (CDR) for Cloud Logs but do not want to use Cloud Security Posture Management (CSPM). For more information, see Cloud Logs.\nSeptember 20, 2023Agent Tags Support through Zone Scopes in PostureDo you need to scope your Zones using the Agent Tags applied to your hosts and clusters?\nYou can now add Zone scopes: Kubernetes and Host with Agent Tags attributes. Add Agent Tags Key:Value pairs just as you add Labels.\nFor details, see Posture Host Analyzer installation.\nSeptember 14, 2023Runtime Scanner v1.5.7 ReleasedRenamed the environment variable VULNERABILITY_DB_VERSION to USE_MAINDB_V2 for consistency with the rest of the client components.\nSeptember 7, 2023Advanced Users Can Apply Tuning Suggestions (Preview)To simplify identifying and applying exceptions, we are enabling the ability for Advanced Users and Team Managers to see and apply tuning suggestions from Insights and Event detail pages.\nTo enable:\nLog in to Sysdig Secure as Admin and go to Settings. Toggle Advanced User Tuner Enablement on. This will become default behavior starting Oct 15th, 2023.\nSeptember 6, 2023Sysdig Secure Support for Rancher Kubernetes Engine (RKE2)We are happy to announce the support for Rancher Kubernetes Engine (RKE2) which, lacking an official Center for Internet Security (CIS) benchmark, is supported by the addition of a new in-house policy.\nSysdig Secure Coverage Improvement for AWSThe Sysdig Secure posture control library has been expanded to improve its Amazon Web Services (AWS) resource coverage. The control library now includes 26 new controls providing support for 17 new resource types (both deployed and from Terraform code) across the following AWS services:\nAmazon DynamoDB Amazon EC2 Amazon Elastic File System (EFS) Amazon Kinesis Amazon RDS Amazon SageMaker Amazon Simple Queue Service (SQS) AWS Elastic Beanstalk AWS Network Firewall AWS Systems Manager (SSM) See also: Compliance.\nOOTB Policy Content UpdatesThe following policies have gone through updates:\nSysdig Mirantis Kubernetes Engine (MKE) Benchmark v1.1.0\nIn collaboration with Mirantis, we have updated some of the audits in order to provide more accurate results.\nAWS Well Architected Framework\nThe Well Architected Framework has been augmented with 26 new controls providing support for the recently added resource types, as well as for some of the already existing.\nAs a fundamental part of the support for Rancher Kubernetes Engine, Sysdig now provides the following new policy:\nSysdig Rancher Kubernetes Engine (RKE2) Benchmark v1.6.0\nThe hardening guide provides prescriptive guidance for hardening a production installation of RKE2, and this benchmark guide is meant to help you evaluate the level of security of the hardened cluster against each control in the CIS Kubernetes benchmark. It is to be used by RKE2 operators, security teams, auditors, and decision makers. Runtime Scanner v1.5.6 ReleasedUpdated the dependencies to address security vulnerabilities.\nAugust 30, 2023Runtime Scanner v1.5.5 ReleasedFixed a defect that could cause the runtime scanner to perform unnecessary scans.\nInline Scanner v1.5.2 Released Updated golang.org/x/net to fix CVE-2023-3978 Fixed a misbehavior that could cause false positives due to wrong handling of opaque directories August 24, 2023Agentless Threat Detection for GitHub (CA)Your GitHub organizations can be now secured with Sysdig agentless cloud dection and response (CDR), which extends its capabilities adding the first Git provider to the list of supported sources. By installing the Sysdig app on GitHub, it will be possible to enable our Falco-powered threat detection capabilities. You will also find policies and rules provided and maintained constantly by our Threat Research Team, along with the possibility to create your own custom ones.\nFor installation instructions, see Git Integrations.\nThis feature is currently in controlled availability (CA).\nRuntime Scanner v1.5.4 Released Corrected a misbehavior that could cause wrong handling of symbolic links Fixed a misbehavior that could cause false positives due to wrong handling of opaque directories August 21, 2023Agentless Threat Detection for Okta (Preview)Sysdig agentless CDR extends its coverage by adding support for Okta, the first identity provider (IdP) in the list of supported sources. You can now connect Okta organizations to Sysdig and use the power of Falco rules to detect threats in your environment. Along with the customizability of Falco rules, Sysdig provides managed policies and rules that are constantly being updated.\nAugust 10, 2023Control Access to Zones and Posture PoliciesSysdig is introducing two new permission items under Sysdig Secure Policies:\nZones (Read, Edit) Posture Policies (Read, Edit) These permission items enable administrators to control who can edit access to Zones and Posture Policies, including APIs.\nExisting roles are updated with the following permissions:\nDefault Roles; Team Manager, Advanced User: Zones: Edit Posture Policies: Edit All Existing Custom Roles and Default Roles; Service Manager, Standard User, View Only: Zones: Read Posture Policies: Read For more information, see Secure Team Roles.\nAugust 7, 2023Runtime Rule Tuner UpdatedSimplified and improved the interface of the Runtime Rule Tuner:\nException information is now presented in easy-to-understand name/value pairs.\nValues can be freely edited.\nAdded explicit Apply buttons for each exception, making the choices conscious and avoiding security blindspots.\nIf you are using Terraform to manage exceptions, you can now view the suggested exception as Terraform snippet and copy/paste it in to your Terraform file.\nImpacted policies and any already-applied exceptions are displayed to help you make more informed decisions.\nSee how to use the improved feature in the Events feed. You can also access it from Insights.\nAugust 2, 2023CLI Scanner v1.5.1 ReleasedSysdig released the new version of cli-scanner with a breaking change in tech preview. The format of the JSON scan result has been changed in command line (CLI) Scanner v1.5.1.\nWhen you run cli-scanner with the --json-scan-result parameter, the severities in JSON keys are not capitalized anymore. For example:\n\u0026#34;vulnTotalBySeverity\u0026#34;: { \u0026#34;Critical\u0026#34;: 2, \u0026#34;High\u0026#34;: 65, \u0026#34;Low\u0026#34;: 24, \u0026#34;Medium\u0026#34;: 107, \u0026#34;Negligible\u0026#34;: 417 }, has been changed to:\n\u0026#34;vulnTotalBySeverity\u0026#34;: { \u0026#34;critical\u0026#34;: 2, \u0026#34;high\u0026#34;: 65, \u0026#34;low\u0026#34;: 24, \u0026#34;medium\u0026#34;: 107, \u0026#34;negligible\u0026#34;: 417 }, This change impacts the following JSON objects:\nvulnTotalBySeverity fixableVulnTotalBySeverity Runtime Scanner v1.5.2 Released Added an environment variable to configure the timeout for the initial scan operation Added a flag to use vulnerability database v2 Updated dependencies to address security vulnerabilities July 26, 2023Detect Fileless Attacks with New RuleSysdig Secure has added the ability to detect fileless attacks using a new Falco rule on the managed policy called Sysdig Threat Detection.\nRequirements:\nAgent version 12.15+ installed Sysdig Threat Detection policy enabled See this blog post for details on Sysdig\u0026rsquo;s solution to fileless malware detection.\nJuly 25, 2023Admission Controller v0.11.8 ReleasedChanged the title for scan events in Sysdig Secure to the format \u0026lt;policy\u0026gt; | \u0026lt;rule\u0026gt;, fixing a bug in the user interface (UI) when using filters from the title in the event feed.\nInline Scaner v1.5.1 Released Corrected the reporting of severities by the inline scanner to ensure they are consistently in lower case Added a feature flag to activate the vulnerabilities database v2 in preview Runtime Scanner v1.5.1 ReleasedUpdated dependencies to address security vulnerabilities.\nJuly 24, 2023OpenID Single Logout SupportSysdig added support for OpenID Single Logout. Using Single Logout, a user can initiate a logout and terminate all sessions without having to log out from each one individually.\nFor more information, see Configure OpenID Single Logout.\nEnhanced Sysdig Platform AuditThe Sysdig Platform Audit has been enhanced to include username and team name in the audit information in addition to user ID and team ID. The feature is Generally Available (GA).\nFor more information, see Sysdig Platform Audit.\\\nJuly 20, 2023Legacy Inline Scanner v 2.4.24 ReleasedFixesVulnerability fixes for the following CVEs:\nCVE-2020-24736 CVE-2023-1667 CVE-2023-2283 CVE-2023-26604 July 19, 2023Sysdig Secure Live Is Enabled for All UsersSysdig Secure Live has been enabled for all users. For more information on this feature, see the following:\nSecure Live Secure Live - Preview July 18, 2023Policy Scope Deprecation: Kubernetes Workload LabelsDeprecation Notice: To improve agent performance and decrease load on the Kubernetes API, the Kubernetes workload metadata will no longer be a valid scope configuration, starting October 18, 2023.\nWhy: When a policy with one of these scopes is applied, every agent must request the metadata from the Kubernetes API for all clusters. We have found that most policies are created for namespaces, clusters, or other metadata local to the agent. Many of the policies that used this metadata in the scope were used to make an exception for all rules in that policy. Sysdig supports Falco exceptions that are more targeted to a process, container, image, and so on, in a specific rule, making for more targeted security rules that provide better performance and security coverage.\nWhat: The following workload metadata will be deprecated from policy scoping:\nkubernetes.daemonset.name kubernetes.deployment.name kubernetes.statefulset.name kubernetes.replicaset.name kubernetes.cronjob.name kubernetes.cron.name* Outcome: Existing policies with these scopes will continue to work but cannot be modified with the same labels. New policies cannot be created with these labels in the scope.\nRecommendation: If you have used one of these scopes to apply a rule or set of rules, replace with scope for kubernetes.namespace.name + container.name\nExample replacing kubernetes.deployment.name\nOld scope:\nkubernetes.namespace.name = default AND kubernetes.deployment.name = nginx Supposing a container called nginx exists inside the deployment nginx, replace it with:\nkubernetes.namespace.name = default AND container.name = nginx You can also get more specific by using images:\nkubernetes.namespace.name = default AND container.name = nginx AND container.image.repo = quay.io/nginx July 14, 2023Admission Controller v0.11.3 ReleasedAdmission Controller v0.11.3 is released. This release removes the Kubernetes workload name from legacy scan secure events, allowing those events to be aggregated in the Secure Events Overview dashboard.\nGeneral Availability of Runtime Events DashboardsSysdig is pleased to announce the General Availability (GA) of Runtime Events dashboards. These dashboards respect team scopes and remove the Tech Preview limitation in which teams had to be scoped to \u0026ldquo;entire infrastructure\u0026rdquo; to be able to see the dashboards.\nJuly 04, 2023Vulnerability Management APIs AddedThe following new API endpoints have been released in Technical Preview to list and filter vulnerability scan results for Pipeline, Registry, and Runtime as well as to fetch detailed scan results in JSON format:\nGet a list of pipeline scan results: GET /secure/vulnerability/v1beta1/pipeline-results Get a list of registry scan results: GET /secure/vulnerability/v1beta1/registry-results Get a list of runtime scan results: GET /secure/vulnerability/v1beta1/runtime-results Get full scan results: GET /secure/vulnerability/v1beta1/results These API endpoints are applicable only to the current Vulnerability scanning engine.\nFor more information on accessing the API, see Developer Tools.\nJune 23, 2023Process Tree Visualization in Events Feed (Preview)Sysdig has eleased the technical preview of the Process Tree feature in the Sysdig Secure events feed. This feature visually unveils the context in which a process was launched. It displays process lineage for security practitioners in a familiar EDR format to help users easily understand the relationships and dependencies between processes to accelerate incident response.\nThis feature requires Sysdig agent v12.15 and must be manually enabled.\nFor more information, see Process Tree.\nJune 27, 2023Investigate Rule Change DetailsIn addition to the Updated badge that is now appended to Threat Detection rules, you can now also use a comparison panel to review the precise changes that were made. This applies to changes made to managed rules set by the Sysdig Threat Detection team, as well as customizations made by users.\nFor details, see View Recent Changes to a Rule.\nJune 26, 2023Improved AWS Cloud Account OnboardingSysdig has launched an improved onboarding experience for AWS Cloud Accounts, enabling users to specify their installation preferences regarding type, method, and desired features. Sysdig then guides you through the installation process step-by-step, ensuring a seamless and personalized experience.\nIn addition, Sysdig\u0026rsquo;s agentless CDR now supports threat detection on AWS CloudTrail, eliminating the need for additional computational resources. By leveraging Falco and its constantly updated rules managed by the Sysdig Threat Research Team, as well as custom rules tailored to specific environments and security requirements, users can connect their AWS accounts and organizations effortlessly while benefiting from robust event processing.\nFor details, see the AWS Onboarding documentation.\nJune 20, 2023Sysdig Secure Live - PreviewSecure Live is a powerful tool that assists in the response and investigation into security events, vulnerabilities, and misconfigurations in your infrastructure under one pane of glass, with a simple way to scope on the part of the infrastructure you are investigating.\nHow Does It Work?\nSecure Live presents the last 24 hours of your infrastructure by scopes based on the hierarchy, such as cluster, namespace, and workloads. Selecting one of these scopes presents existing data from different parts of Sysdig Secure in a curated set of panels and tabs that are specific to that scope. As this feature evolves, more panels and \u0026ldquo;Live\u0026rdquo; views will be added, such as Posture Tab and Cloud Live.\nWhat are the Benefits?\nSysdig Secure Live provides a number of benefits, including:\nIncreased visibility: Secure Live provides a unified view of your infrastructure, making it easier to identify and respond to security threats. Improved efficiency: Secure Live can help you to automate many of the tasks involved in security operations, freeing up your team to focus on more strategic work. Reduced risk: Secure Live can help you to reduce the risk of security breaches by providing you with the information you need to identify and address vulnerabilities before they are exploited. What are the Limitations?\nSysdig Secure Live is still under development, so there are a few limitations to be aware of:\nLimited data retention: Secure Live only stores data for the last 24 hours. No customization: The scopes, panels, and tabs in Secure Live cannot be customized at this time. What\u0026rsquo;s Next?\nSysdig is committed to continuously improving Sysdig Secure Live. In the future, we plan to add new features and functionality, such as:\nSupport for more cloud providers: Sysdig Secure Live currently supports AWS, Azure, and Google Cloud Platform (GCP). We plan to add support for more cloud providers in the future. Integrations with other security tools: Sysdig Secure Live can be integrated with other datasources from Falco, such as Okta and GitHub. This will allow users to get a more comprehensive view of their overall cloud native security To enable the feature, see Secure Live.\nJune 16, 2023Jenkins Plugin v2.3.0 Released Added support to apply image-based accepts for the following: All the versions of an image Images in a specific registry and repository Images that contain wildcards for a customized subset of the environment Updated the analyzer to inspect the vendor directory for packages. Shows Pipeline results in the Vulnerability Management Overview page. Unified Subscription PageThe Subscription page has been enhanced to provide a unified look and feel for both Sysdig Monitor and Sysdig Secure. This improvement is particularly useful to Sysdig Platform users as it now shows all the relevant subscription information, regardless of which product is currently selected. The feature is Generally Available.\nFor more information, see Subscription.\nJune 13, 2023CLI Scanner v1.5.0 ReleasedSysdig released the new version of cli-scanner. The CLI Scanner v1.5.0 introduces the following:\nAdded support to apply image-based accepts for the following: All the versions of an image Images in a specific registry and repository Images that contain wildcards for a customized subset of the environment Updated the analyzer to inspect the vendor directory for packages Upgraded several dependencies to fix high and medium CVEs: CVE-2023-2253 CVE-2023-28642 CVE-2023-28840 CVE-2023-25809 CVE-2023-28841 CVE-2023-28842 Accept Risk Feature UpdatedSysdig is pleased to announce the update of the Accept Risk feature for Vulnerability Management. This update enables users to extend risk acceptance in several customizable ways to allow for more controlled acceptance scope.\nPreviously, accepted risk scopes for a CVE, image, or host were either global or per individual asset.\nImprovements\nAdded support to apply image-based accepts for:\nAll versions of an image Images in a specific registry and repo Images that contain strings for customized subsets of the environment For details, see Accept Risk.\nJune 12, 2023Notification Formats Update 2The notification format for the Slack and MS Teams notification channels was updated with the ability to choose either a brief or detailed version of the notification message. For newly created channels, the shortened version is the default. Users who currently have the detailed version can edit the channel and change their selection if desired.\nFor details, see Notification Channels\nJune 7, 2023Runtime Events DashboardsThe technical preview of the Runtime Events Dashboards is now available in Sysdig Secure. The dashboards provide a summary view as well as a trend view of all events in your infrastructure. They highlight security hotspots, and the filtering capabilities allow you to focus on a specific part of the infrastructure.\nThis release makes the following dashboards available:\nEvents Overview Kubernetes Events Cloud Events Host and Container Events Only teams that are scoped to the entire infrastructure will see the dashboards.\nFor details, see Runtime Events Dashboards.\nJune 5, 2023Posture: Standalone Install Available for Linux and Docker HostsWhile Helm is the recommended installation method for Kubernetes clusters, if you want to scan a host that is not running Kubernetes, we also offer a stand-alone analyzer for compliance violations on Linux hosts.\nOOTB Policy Content UpdatesWe are happy to announce the update of the following out-of-the-box (OOTB) policies:\nCenter for Internet Security (CIS) Google Cloud Platform Foundation Benchmark v2.0.0 (latest) CIS Microsoft Azure Benchmark v2.0.0 (latest) ISO/IEC 27001:2022 (latest) Lockheed Martin Cyber Kill Chain Sysdig Secure Coverage Improvement for AWSSysdig Secure Posture control library has been expanded to improve its Amazon Web Services (AWS) resources coverage. The control library now includes new controls for the following resource types:\nAmazon Elastic Container Service (ECS) ECS Cluster ECS Service ECS Fargate Service ECS Fargate Task Definition Amazon Elastic Kubernetes Service (EKS) EKS Cluster EKS Fargate Profile See also: Compliance.\nSysdig Secure Coverage Improvement for GCPSysdig Secure has been expanded to improve its Google Cloud Platform (GCP) resources coverage adding a total of 229 new resource types for the following services:\nAI and Machine Learning Cloud Tensor Processing Units (TPUs) Dialogflow Document AI Speech-to-Text Vertex AI API Management API Gateway Cloud Healthcare API Compute Compute Engine Containers Artifact Registry Container Engine Container Registry Google Kubernetes Engine (GKE) Data Analytics BigQuery Cloud Composer Cloud Data Fusion Dataflow Dataplex Dataproc Pub/Sub Databases Cloud SQL Cloud Bigtable Cloud Spanner Database Migration Service Datastream Firestore Memorystore Hybrid and Multicloud Anthos Management Tools Deployment Manager Google Cloud Billing API Service Management API Media and Gaming Game Servers Transcoder API Networking Cloud Domains Cloud Intrusion Detection System (IDS) Google Cloud Virtual Network Network Connectivity Network Management Network Services Service Directory Operations Cloud Logging Security and Identity Assured Workloads BeyondCorp Enterprise Certificate Authority Service Cloud Data Loss Prevention Cloud Key Management Service (KMS) Cloud Resource Manager Secret Manager Serverless Computing App Engine Cloud Functions Cloud Run Workflows Storage Filestore Additional Google Products Eventarc Integration Connectors Managed Service for Microsoft Active Directory (Managed Microsoft AD) Organization Policy API May 30, 2023VM Registry Scanner 0.2.39 Supports .Net Packages and Centos OSWe are pleased to announce the release of our updated registry scanner 0.2.39 with chart 1.0.12 with the following features:\nAllowing internal environment variable (ENV var) to allow pageSize setup on the Artifactory client (v0.2.39) Registry scanning library bump, to add vulnerability management support for .Net packages and Centos OS (v0.2.38) Be aware that by incorporating this new source, you may discover previously unidentified vulnerabilities in assets that have already been scanned.\nCLI Scanner v1.4.0 ReleasedSysdig released the new version of cli-scanner. The command-line interface (CLI) Scanner v1.4.0 introduces the following:\nPipeline results shown in the Vulnerability Management Overview page. Beta support for the Scan result in JSON format through the --json-scan-result=path/to/scanresult.json flag. May 23, 2023Vulnerability Management Landing Page for TrendsSysdig has released the Vulnerability Management Landing Page. This page helps users to see trends, priorities, and top action items on the vulnerability risks in their environment.\nVulnerability Managers gain insight into vulnerability changes and trends (Risk Posture), the latest and most pervasive CVEs and which infrastructure segments are most vulnerable.\nProgram Mangers gain clearer insight into the implications of these findings for policy.\nArchitects gain easy access to data regarding scan counts and adoption rates.\nThe Vulnerability Management team, as a whole, gains an easy place to start to prioritizing and managing vulnerabilities at a program level.\nAdditional Notes:\nAll widgets enable a workflow to take action or export data to the user\u0026rsquo;s native information security tool ecosystem. Coming soon: addition of zones, native integration to ticketing, and more sophisticated prioritization through Image Genealogy. For details, see Vulnerability Management Overview.\nMay 18, 2023Legacy Inline Scanner v 2.4.23 ReleasedChanges Updated anchore to 0.8.1-59 (May 2023) FixesVulnerability fixes for the following CVEs:\nCVE-2023-30861 CVE-2023-28840 May 16, 2023Accepted Risks Management for Posture Added (Preview)A dedicated Accepted Risk page has been added under the Policies UI in Sysdig Secure, with the following features:\nA new Posture Tab with the list of accepted Posture/Compliance violations (in addition to the Vulnerabilities accepted risks tab) The ability to search for risks that were accepted and to filter by various parameters The ability to review a specific acceptance, revoke or edit it This feature is in Technical Preview status.\nFor details, see the Risk page.\nMay 15, 2023Sysdig Secure Coverage Improvement for AWSSysdig Secure Posture control library has been expanded to improve its AWS resources coverage. The control library now includes new controls for the following services:\nAccount AWS CloudFormation Amazon CloudFront AWS CodeBuild Amazon Elastic Compute Cloud (EC2) Auto Scaling Amazon Elastic Container Service (ECS) Amazon Elastic Load Balancer (ELB) Amazon ElastiCache Amazon Elasticsearch Service AWS Identity and Access Management (IAM) AWS Key Management Service (KMS) AWS Lambda Amazon OpenSearch Service Amazon RDS Amazon Redshift AWS Secrets Manager Amazon Simple Notification Service (SNS) See also: Compliance.\nMay 11, 2023Inventory Now Supports Git IntegrationsInfrasture as code (IaC) resources, supported by our Git-integrated scanner, are now available in Sysdig Secure’s Inventory. This allows you to:\nEasily differentiate your code from your deployed resources with our updated resource cards.\nSearch and filter for IaC resources using attributes like Resource Origin, Source Type, Location, Git Integration and Repository.\nAccess a 360-view of each code resource, which includes:\nresource metadata configuration details posture violations that can be remediated with automated workflows Query the Secure API to get a list of multiple IaC resources or retrieve a single one.\nMay 8, 2023OOTB Policy Content UpdatesWe are happy to announce the update of the following policies:\nCenter for Internet Security (CIS) Amazon Elastic Kubernetes Service (EKS) Benchmark v1.2.0 (latest) CIS Azure Kubernetes Service (AKS) Benchmark v1.3.0 (latest) CIS Docker Benchmark v1.5.0 (latest) CIS Google Kubernetes Engine (GKE) Benchmark v1.4.0 (latest) Registry Scanner 0.2.32 Update AvailableFixes Added support for http protocol registries Changed to honor maxRepositoriesPerRegistry on aws.org In chart 1.0.5\nMay 3, 2023Vulnerability Management Rules ImprovementUpdated Sysdig Secure\u0026rsquo;s default set of rules for vulnerability management, Severe vulnerabilities with a Fix. The necessary condition \u0026ldquo;has a fix\u0026rdquo; was previously missing from one of these rules, which might have impacted the accuracy of identified policy violations. This issue has now been corrected.\nPlease note that as a result of this improvement, some vulnerabilities previously marked as policy violations may no longer be considered as such.\nGroups Page added to CIEMThe newly added Groups page provides numerous ways to sort, filter, and rank the detected group information to quickly remediate identity risks associated with the group’s users and policies.\nLeast Permissive Policy Suggestions for a group takes into account all of the group’s attached user’s activity within the scope of all attached policies. Utilizing Sysdig’s Optimized Policy Suggestion can enable you to create one policy for the group that is Least Permissive.\nFor details, see Groups.\nNotification Formats UpdatedThe notification format for the Slack and Microsoft Teams notification channels has been simplified for ease of use. The notifications now contain just the rule, policy name and context information about where the event took place. When available, a Runbook Link and Action Taken are displayed. Click the link to reach the event with full details in the Sysdig UI.\nFor details, see Notification Channels.\nMay 2, 2023Threat Detection Policy and Rule Pages Show Update BadgeBadges are now displayed on the Runtime Policies and Rule Library pages to indicate that a rule has been added or updated in the past 7 days. This includes updates performed by Sysdig\u0026rsquo;s threat research team as well as customization added by users, for example, when specifying exception values.\nSee also: Threat Detection Policies and Manage Rules.\nApril 28, 2023Legacy Inline Scanner v 2.4.22 ReleasedChanges Updated anchore to 0.8.1-58 (April 2023) FixesVulnerability fixes for the following CVEs:\nCVE-2023-0286 CVE-2023-27561 April 25, 2023Cloud Account Compute Resource Shown in SubscriptionThe Subscription page now includes Compute Resources information to allow tracking of Enterprise Cloud Security usage.\nSee also: Subscriptions.\nApril 21, 2023VM Runtime Scanner v1.4.10, Host Scanner v0.3.9, CLI Scanner v1.3.8We are pleased to announce the release of three updated versions of our scanning tools:\nVM Runtime Scanner v1.4.10 Host Scanner v0.3.9 CLI Scanner v1.3.8 Apart from the usual bug fixing and updates, the most significant improvement in this release is the expanded support for detecting and scanning .NET packages:\nWhile we previously could parse packages.lock.json files, we have now added the capability to parse .deps.json files. This enhancement will enable us to identify broader vulnerabilities within the .NET ecosystem. Please be aware that by incorporating this new source, you may discover previously unidentified vulnerabilities in assets that have already been scanned.\nApril 19, 2023Container Registry ScanningThe Image Registry Scanning functionality is now generally available as part of our Vulnerability Management suite.\nThis feature provides an added layer of security between the pipeline and runtime stages, allowing you to gain complete visibility into potential vulnerabilities before deploying to production.\nSupported Vendors AWS Elastic Container Registry (ECR) - Single Registry and Organizational JFrog Artifactory - SaaS and On-Premises Azure Container Registry (ACR) - Single Registry IBM Container Registry (ICR) Quay.io - SaaS Harbor Once the container registry is instrumented and analyzed, you can generate registry reports to extract, forward, and post-process the vulnerability information.\nFor more information, see Registry Scanning and Reports.\nInterested in trying it out live? Sysdig offers a hands-on training lab to launch directly from your web browser.\nApril 5, 2023Cli-Scanner 1.3.7 ReleasedFixesFixed a parsing error that caused RedHat modules to be incorrectly matched when scanned.\nSee Running the CLI Scanner for details on downloading and running the cli-scanner.\nMarch 23, 2023Risk Scores Explanations Enhanced in CIEMUnderstand a breakdown of your Cloud Infrastructure Entitlement Management (CIEM) Risk Scores with Overview explanations.\nWithin the Posture tab, you’ll find different Identity and Access resources with Risk Scores. Select an entity from the list in the table and a drawer appears providing a detailed breakdown of the entity’s risk score, including the specific attributes and permissions that have contributed to it.\nLearn more about how risk scores are calculated.\nSupport for CIS Critical Security Controls v8The CIS Critical Security Controls (CIS Controls) are a prioritized set of Safeguards to mitigate the most prevalent cyber-attacks against systems and networks. They are mapped to and referenced by multiple legal, regulatory, and policy frameworks. CIS Controls v8 (latest) has been enhanced to keep up with modern systems and software. Movement to cloud-based computing, virtualization, mobility, outsourcing, Work-from-Home, and changing attacker tactics prompted the update, which supports enterprises as they move to both fully cloud and hybrid environments.\nThis policy, with 1,316 controls classified into 18 requirement groups, is now available as part of Sysdig\u0026rsquo;s posture offering.\nSupport for OWASP Kubernetes Top TenThe OWASP Kubernetes Top Ten is aimed at helping security practitioners, system administrators, and software developers prioritize risks around the Kubernetes ecosystem. The Top Ten is a prioritized list of these risks. This policy, containing 344 controls classified into 10 requirements, is now available in Secure.\nMore information about this policy can be found in OWASP Kubernetes Top 10.\nUpdated CIS Amazon Web Services Foundations Benchmark to v1.5.0 (latest)Updated the existing CIS Amazon Web Services Foundations Benchmark policy to its latest version at the time (v1.5.0). This new version include a new resource type, Elastic File System (EFS), for greater coverage, as well as new controls for the Amazon EFS and Amazon Relational Database Service (RDS) services. The total number of controls in this new update has raised up to 79.\nMarch 22, 2023Git Scope for ZonesWe have extended the flexibility of Zones for Posture to also support Git integrations and IaC (Infrastructure as Code) scanning.\nWith the introduction of Git scope for zones, users can include the new Git scope types as part of the zone definition and configure the policies that apply for that zone.\nNote: Git sources have a new user-defined name field. Existing Git sources will automatically get a name like \u0026ldquo;Source 1\u0026rdquo;, \u0026ldquo;Source 2\u0026rdquo;, or the like.\nFor more information see the Zones and IaC Security documentation.\nHelm Chart 1.5.80+ and Cli-Scanner 1.3.6 ReleasedFixes RELEASE suffix in Java packages leading to false negatives resolved\nSpecific Java packages containing a .RELEASE suffix were not correctly matched against their existing vulnerabilities, for example:\nhttps://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-web/1.2.2.RELEASE\nwas not correctly parsed and matched against the relevant vulnerabilities. This case is particularly common for spring-boot libraries.\nThis fix will remove false negatives, thus uncovering real vulnerabilities that were present in those packages but not previously listed\nThis could lead to an increase in the number of vulnerabilities and policy violations.\nImprovements Display full path for jar-in-jar libraries\nWhen a jar library is found inside another jar container, Sysdig will now display the absolute and relative path inside the jar, using the colon as separator:\nBefore: /SpringHelloWorld-0.0.1.jar After: /SpringHelloWorld-0.0.1.jar:BOOT-INF/lib/spring-core-5.3.16.jar See Running the CLI Scanner for details on downloading and running the cli-scanner.\nMarch 14, 2023Legacy Inline Scanner v 2.4.21 ReleasedChanges Updated anchore to 0.8.1-57 (March 2023) Added support for OpenContainers Image (OCI) manifest list: parse and scan images built with attestation storage FixesVulnerability fixes for the following high-severity CVEs:\nCVE-2022-41723 CVE-2022-47629 CVE-2023-24329 CVE-2023-25577 March 9, 2023Inventory Released as Tech PreviewInventory has been made generally available as a new-top level menu item.\nWith this feature you can:\nSearch and filter for resources based on a growing list of attributes such as Labels, Zones, and Posture information (policy, requirement, control, accepted risk, control severity).\nAccess a 360-view of each resource, which includes its posture violations, metadata, and configuration details.\nReview resources\u0026rsquo; posture violations and remediate them by opening a Pull Request or manually applying a patch.\nQuery the Secure API to get a list of multiple resources or retrieve a single one.\n(For API doc links for additional regions, or steps to access them from within the Sysdig Secure UI, see the Developer Tools overview.)\nInventory is a SaaS-only feature of Sysdig Secure.\nFor details, see Inventory.\nMarch 6, 2023CLI Scanner 1.3.4 ReleasedReleased version 1.3.4 version of the cli-scanner.\nMarch 8, 2023KSPM policy for CIS Kubernetes V1.24 Benchmark releasedA new Posture policy has been released following the CIS Kubernetes V1.24 Benchmark. This policy provides prescriptive guidance for establishing a secure configuration posture for Kubernetes 1.24 and includes 13 new controls.\nMarch 1, 2023Improved Search of Posture ControlsOur 1,000 Posture Controls are now easier to find, by their Name, Description, Severity, Type and Target platform or distribution, anywhere you are looking for them:\nFilter for controls in the Control library Filter in the Policies library, including while editing your custom policy We also added enhanced visibility of control targets by showing the supported platform and distributions on each control.\nFor more information, see Posture Controls.\nSupport for OCP, IKS and MKEWe have added Posture support for new Kubernetes distributions:\nSupport for Red Hat OpenShift Container Platform 4 (OCP4):\nCIS Red Hat OpenShift Container Platform Benchmark policy. Support for IBM Cloud Kubernetes Service (IKS):\nSysdig IKS Benchmark policy. Support for Mirantis Kubernetes Engine (MKE):\nSysdig MKE Benchmark policy. February 28, 2023New Page for Privacy SettingsA new Privacy Settings page has been added under Administration Settings.\nFebruary 27, 2023New Filter and Grouping for Threat Detection PoliciesThis release enhances the Threat Detection policies by showing the policies in a grouped manner and adding the ability to filter policies by type.\nAdditionally, badges on the list now alert you when rules have been added or updated in managed policies.\nFebruary 17, 2023Posture Now Supports Red Hat OpenShift Container Platform (OCP4)Added support for the OpenShift platform. The CIS Red Hat OpenShift Container Platform Benchmark policy is now available, with 181 controls (145 of which are exclusive to OpenShift), using a new Cluster resource type which is of paramount importance in OCP4 due to the nature of the platform.\nFebruary 16, 2023View Insights Grouped by UserThe Insights vizualization now permits viewing events grouped by user, greatly improving the ability to spot outliers. You can also see all events from a particular user in reverse chronological order. See Group by User | Rule for details.\nFebruary 14, 2023New Filter and Grouping for Rules LibraryThis release enhances the Threat Detection rules library by showing the rules in a grouped manner and adding the ability to view only custom rules.\nFebruary 2, 2023VM Reports Now Include Risk Spotlight (In Use) and Accepted RisksAdded Risk Spotlight (In Use) and Accepted Risks to VM Reporting as both an additional metadata column and a configurable filter.\nEvery matching vulnerability will have these two new additional columns, as well as the matching true/false filters.\nJanuary 25, 2023CLI Scanner 1.3.3 and Jenkins Plugin 2.2.7 ReleasedSysdig has released version 1.3.3 version of the cli-scanner and 2.2.7 version of the Jenkins Plugin.\nScanner Update Bug fixes, some of which were impacting policy evaluations. Plugin Update Updates to the scanner Adjustments to the string representation of some policy rules in the report section Several bug fixes, including one that caused the build to fail when it shouldn\u0026rsquo;t Non-Containerized Install Available for Host ScanningWhile Helm is the recommended installation method, if you want to scan a host without using containers at all, we also offer a standalone binary and an RPM package. To review methods, see Host Scanning.\nLiveness and Readiness Probes Added to Helm ChartStarting from sysdig-deploy Helm chart version 1.5.34, we have added livenessProbe and readinessProbe, which check for vulnerability runtime scanner component health, in agreement with the Kubernetes monitoring and scheduling practice.\nBe aware, this requires having a vuln-runtime-scanner version of at least v1.4.4.\nJanuary 2023Inventory Released as Controlled AvailabilitySysdig Secure now offers an Inventory, so you can gain visibility into resources across your cloud (GCP, Azure, and AWS) and Kubernetes environments. With this feature you can:\nSearch and filter for resources based on their metadata Get a high-level overview of resources’ compliance violations Access a 360-view of each resource, starting with its configuration details and facilitated by the unification of Sysdig’s data View and share resources’ configurations January 19, 2023CLI Scanner v1.3.2 ReleasedReleased a new version of cli-scanner. CLI Scanner v1.3.2 introduces a new configuration parameter, --override-pullstring, that allows you to specify a custom image name to be displayed on the Sysdig Secure UI. For more information, see Install Vulnerability CLI Scanner.\nHost Scanning Enhancements and General AvailabilityVulnerability management for Hosts has received several upgrades and is now generally available.\nNewly supported Host OSes Alibaba Cloud Linux (also know as Aliyun Linux) Google Container-Optimized OS (COS), build 89+ See all supported Host OSes.\nHost Vulnerability ReportingIt is now possible to create scheduled vulnerability reports targeting the Hosts which are scanned with the Sysdig product.\nFrom the Reports function in Sysdig Secure, select if you want to target the Runtime Workloads or Runtime Host.\nNote that scope labels and report columns will follow the Host Scanning metadata, as in HostName or Cloud Provider Region.\nJanuary 17, 2023CSPM Compliance GA ReleasedSysdig is pleased to announce the general availability (GA) release of the new CSPM Compliance module. This feature helps you prioritise compliance results on your most important environments and applications.\nNew features A compliance page ordered by your zones. CSPM Zones Management A default Entire Infrastructure zone is created for each customer Create your own zone: Define scopes for the resources you want to evaluate Apply a policy to your zone to add it to the compliance page Over 40 new Risk and Compliance Policies included To get to know our path from detection to remediation, risk acceptance, zones management, installation and migration guidelines, please review the documentation.\nThe new compliance module is not available for IBM Cloud and OnPrem users. They should continue taking advantage of Unified Compliance.\nJanuary 5, 2023IaC Scanning now Supports Terraform AWSAdded support for Terraform resources from the AWS Provider. If you have implemented Git IaC Scanning, then pull-request checks will now scan AWS resources and report any violations of the CIS AWS Foundations Benchmark.\nThe list of supported resource and source types is now:\nKubernetes workloads in YAML manifests Kubernetes workloads in Kustomize Kubernetes workloads in Helm charts Kubernetes workloads in Terraform AWS cloud resources in Terraform Other changes in the release include improved Kubernetes resources scanning in Terraform to support additional use cases.\nFor more information, see Git Integrations.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/2023-archive/"},{"id":76,"title":"Monitor SaaS Release Notes 2024","content":"November 27, 2024Service Account Expiry NotificationsWe have expanded the Sysdig Monitor UI to support configuring notifications for expiring Team Based Service Accounts. This builds on existing API capabilities, making token management more accessible for all users.\nBy enabling these notifications, you can ensure your service account tokens are renewed on time.\nFor more details, see Expiry Notifications.\nNovember 18, 2024Alert Terminology The Over the Last parameter in Threshold Alerts, defining the time window for metric aggregation, is now called Time Aggregation. The For the Last parameter in Event Alerts, defining the time window that events are counted, is now called Count Over Last. Embedded Images in Alert Notifications now supported for Microsoft Teams Threshold Alerts forwarding to Microsoft Teams now include an image of the time series data that triggered the alert rule. This feature was previously available only for Slack, Email, and Pagerduty. October 14, 2024The second set of usability enhancements for Dashboards is now available:\nDashboard Popularity: Dashboard Manager now surfaces the popularity of a dashboard across your Sysdig team. Dashboard popularity is calculated based on several factors, including the number of visits, how recently it was visited, and number of unique users who visit. Fuzzy Search for Dashboards: Dashboard search now supports partial matches, misspellings, and approximate terms. You can also search by metrics, dashboard descriptions, as well as dashboard panels. The shared by my team section of the Dashboards navigation menu has been replaced by Most popular with my team. October 7, 2024Terraform Support for AWS Cloud AccountsYou can now integrate between AWS CloudWatch Metric Streams and Sysdig Monitor with the AWS CloudWatch Metrics Terraform Module. To forward CloudWatch metrics to Sysdig Monitor, see CloudWatch Monitoring.\nOctober 4, 2024Dashboard Quality of Life EnhancementsThe first set of usability enhancements for Dashboards is now available:\nRecently Selected Values: Dashboard label values previously chosen will now be saved and displayed as “Recently Selected”, streamlining troubleshooting and allowing quicker access to recently used values. Dashboard Visibility: We’ve improved the distinction between private dashboards, shared dashboards, and those from the Library, making it easier to identify and manage different types of dashboards. These updates are designed to enhance the overall dashboard experience and improve efficiency.\nAugust 8, 2024Alert Terminology Metric Alerts are now called Threshold Alerts. Threshold Alerts now include a Duration setting, specifying how long an alert condition must be continuously satisfied before triggering the alert rule. PromQL Alerts are now called Prometheus Alerts. Standardized terminology: Range refers to the time period over which a metric is aggregated. The Alert Editor still refers to this field with \u0026ldquo;over the last\u0026rdquo;. Duration refers to how long an alert condition must be continuously met to trigger an alert rule. Standardized API fields to duration_seconds and range_seconds for consistency. August 2, 2024Microsoft Deprecates Office 365 ConnectorsMicrosoft is deprecating Office 365 Connectors for Microsoft Teams notifications. According to the official deprecation notice, new connectors cannot be created after August 15, 2024, and existing ones will require a URL update to function after December 31, 2024. To avoid any interruption in notifications, see migrate from Office 365 Connects to Power Automate.\nJuly 30, 2024Alert InhibitionYou can now set up Alert Inhibition rules for Prometheus alerts. This feature stops secondary alert notifications from being forwarded if an upstream alert occurrence is already active. This helps reduce alert noise by preventing notifications from known downstream effects. To learn more, see Alert inhibition.\nAlert Inhibition can only be configured via the API and is only available for Prometheus Alert Rules.\nImproved Alert Preview AccuracyThe Alert preview for Metric Alerts and PromQL Alerts now more accurately reflects alert rule checks. The data points in the alert preview aligns with the actual alert evaluation intervals, ensuring a realistic representation of alert behavior, since each point in the alert preview corresponds to an actual alert rule check.\nUnified SearchThe Event feed now integrates scope-based search and free-text search in the same search bar, allowing you to filter events by both criteria from one convenient location.\nDisable Metric Collection for a Prometheus JobYou can now exclude metrics from being collected by the Sysdig Agent via Metrics Usage or the Metrics Collection API. This feature is useful for managing integrations or Prometheus jobs that collect a large number of metrics, helping to reduce time series consumption.See Disable Collection of a Single Metric for a specific Prometheus job.\nMetrics consumed with Prometheus Remote Write and Sysdig Agent metrics such as sysdig_container_cpu_used_percent are not eligible for filtering.\nJuly 26, 2024Metric And Events Retention IncreaseSysdig has increased the data retention default for Monitor Metrics and Events.\nMetrics Retention Increases Details Metric Retention changes currently only applies to AWS regions: US East (Virginia), US West AWS (Oregon), AP Australia (Sydney), European Union (Frankfurt).\n10s samples from 4 hours to 7 days. 1m samples from 2 days to 14 days. 10m samples from 14 days to 30 days. Events Retention Increases Details Total Limit from 1 Million to 2 Million events. Custom Events Retention from 14 days to 30 days. For more details, see Data Retention Limits.\nJune 20, 2024New Costs Metrics with Custom Labels SupportCost Explorer, part of the Costs module has been upgraded with new cost metrics, bringing support for Custom Kubernetes Labels from workloads and namespaces. For teams tagging their workloads, this enables more detailed cost breakdown.\nAdditionally, you can easily query cost metrics, thanks to the new simplified metrics. Dashboards and Alerts (Sysdig Cost Advisor section) have been added to the Library to showcase these new capabilities.\nJune 10, 2024New UI ThemesSysdig introduces new themes for the Sysdig Monitor UI, featuring new colors, shapes, typefaces, and artwork in both Light and Dark modes.\nWith the introduction of the new themes, you can experience a cleaner and more contemporary user interface, enhancing the data narrative. The refined lines of the new font and the minimalist color palette aim to provide additional space for the story Sysdig wants to convey with your data.\nThe older Light and Dark themes are automatically updated to the new ones, so no action is required on your part. The previous themes will remain accessible as Light - Legacy and Dark - Legacy for the next few months.\nApril 12, 2024Alert EditorWhen creating alerts, the Alert Editor displays the optimal time window for your alert rule, and every data point in the alert preview corresponds to an evaluation of an alert rule. You can also Explore Historical Data for Threshold Alerts.\nMarch 15, 2024Cost Advisor Adds Custom Pricing SupportYou can now refine the pricing of your on-prem clusters for more control and precision. See Billing Profiles.\nGlobal Service AccountsSysdig has extended the functionality of team-based service accounts with global service accounts. Unlike team-based service accounts, global service accounts can perform actions that require system level permissions. Admins can create a global service account through the API. See Global Service Accounts\nMarch 5, 2024Deactivate User OptionSysdig has added the ability to configure a period of inactivity for a user, after which the user is deactivated. This helps large enterprises manage users automatically rather than manually deleting users from Sysdig.\nThis feature is deactivated by default. Currently, it can be enabled via API only.\nFor details, access the API documentation under User-Deactivation.\nFebruary 22, 2024Label Enrichment in Alert NotificationsSysdig has enriched labels for Metric and PromQL Alerts. This feature enhances alert notifications by automatically appending contextual labels upon triggering an alert rule. Beyond user-defined segmentation labels, it enriches notifications with useful contextual labels such as host_hostname, cloud_provider_region, and kube_cluster_name. This additional context aids in faster issue identification, troubleshooting, and resolution.\nJanuary 29, 2024Metrics Usage ImprovementsMetrics Usage has been improved to help you navigate and understand your metrics more intuitively. Now, labels are automatically sorted by their cardinality for any given metric. This refinement streamlines analyzing Custom Metrics, making it simpler to pinpoint labels responsible for high cardinality.\nJanuary 17, 2024Sysdig Default Pricing for Cost AdvisorCost Advisor will now use Sysdig Default prices in instances where pricing information is unavailable, such as when viewing on-premises Kubernetes clusters. Additionally, Cost Advisor has been enhanced to help you identify the billing profile associated with a specific Kubernetes cluster.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-monitor-release-notes/2024-archive/"},{"id":77,"title":"Serverless Agent Release Notes 2024","content":" Deprecation Notice Upcoming Changes to Sysdig Product Line\nIn upcoming releases, the following change will take effect:\nRetirement Plan for Serverless Orchestrator Agent The Orchestrator Agent entered its deprecation phase with Serverless Agent 5.3.0 and was fully deprecated as of July 2025, with the release of Serverless Agent 6.0.0. After the release of 6.0.0, the Orchestrator will no longer receive updates, including development, maintenance, bug fixes, or security patches. Upcoming releases will equip the Serverless Workload Agent with the capabilities currently offered by the Orchestrator Agent, including options for using custom certificates and proxies to connect to the collector. Before 6.0.0 is released in July 2025, you must migrate all your Workload Agents away from the Orchestrator. For guidance, see Migrate from Orchestrator. For further assistance with migration, contact Sysdig Support.\nServerless Agent 5.3.0 December 17, 2024EnhancementsControlled Availability for Google Cloud Run SupportThe Serverless Agent now supports securing containers running as a Google Cloud Run Service. Contact your Sysdig representative to enroll. For more information, see Cloud Run Service.\nDefault Availability of Falco HashingHash enrichment is now enabled by default. The workload agent computes a SHA256 hash for each binary executed by the entry point and attaches it to policy events.\nTo disable this feature, set hash_detection.enabled: false in the configuration.\nOn-Demand Security Policy LoadingThe workload agent now fetches security policies only at startup or when changes are detected in the Sysdig backend.\nThis reduces network bandwidth usage and minimizes the performance impact of periodic policy updates. On-demand policy loading is enabled by default for workload agents directly connected to the collector.\nReduced Instrumentation OverheadInstrumentation overhead has been optimized for workloads with high clone operations, improving performance.\nDefect FixesAvailability mode is now enabled only when the agent is provided with the environment variable SYSDIG_PRIORITY=\u0026quot;availability\u0026quot;.\nVulnerability FixesAddressed the following CVE in the Orchestrator Agent:\nCVE-2024-10963 Serverless Agent 5.2.1 November 25, 2024Defect Fixes The workload agent starts properly when the instrumented containers include multiple EFS mount points Fixed the Ring buffer corruption issues Fixed issues in multithreaded processes on ARM64 Vulnerability FixesAddressed the following vulnerabilities in the Orchestrator Agent:\nCVE-2024-3596 CVE-2023-5363 CVE-2024-26462 CVE-2024-50602 CVE-2024-6119 CVE-2024-6232 CVE-2024-8088 CVE-2023-2975 CVE-2023-3446 CVE-2023-3817 CVE-2023-5678 CVE-2023-6129 CVE-2023-6237 CVE-2024-0727 CVE-2024-2511 CVE-2024-26458 CVE-2024-26461 CVE-2024-4603 CVE-2024-4741 CVE-2024-5535 Serverless Agent 5.2.0 October 28, 2024EnhancementsControlled Availability for Graviton (ARM64) SupportUsers running Gravition workloads in ECS Fargate can now secure them with the Serverless Agent. Contact your Sysdig representative to enroll.\nMulti-Arch Manifest ListThe Serverless Agent is now distributed via a manifest list and it includes images for both x86_64 and arm64 architectures.\nServerless Patcher 5.2.0 October 23, 2024Multi-Arch Manifest ListThe serverless-patcher is now distributed via a manifest list and it includes images for both x86_64 and arm64 architectures.\nServerless Agent 5.1.1 October 14, 2024Defect Fixes Resolved an intermittent ring buffer issue that could lead to unexpected task shutdowns. Fixed occasional startup delays caused by timing issues when fetching task metadata. Serverless Patcher 5.1.1 September 20, 2024This release updates only the Serverless Patcher to address the vulnerabilities.\nDefect FixesVulnerability FixesAddressed the following vulnerabilities:\nCVE-2024-34155 CVE-2024-34156 CVE-2024-34158 Serverless Agent 5.1.0 September 18, 2024This release updates the Serverless Agent and the CloudFormation templates.\nFeature Enhancements Added support for DNS detection in runtime workload policies. Optimized CPU and memory usage for more efficient instrumentation of short-lived binaries. Increased robustness in handling invalid memory references passed as system call arguments. Defect Fixes Reduced memory consumption during instrumentation when handling fatal signals from workloads. Resolved occasional stack pointer corruption when creating new threads. Fixed an issue that prevented the workload agent from starting correctly when the workload image working directory had restricted permissions. Vulnerability FixesAddressed the following vulnerabilities:\norchestrator-agent\nCVE-2024-34155 CVE-2024-34156 CVE-2024-34158 CVE-2024-24791 CVE-2024-6104 workload-agent\nCVE-2024-2398 CVE-2024-34397 CVE-2024-37370 CVE-2024-37371 Serverless Patcher 5.1.0 August 19, 2024This release updates only the Serverless Patcher to address the vulnerabilities.\nDefect FixesVulnerability FixesAddressed the following vulnerability:\nCVE-2024-41110 Serverless Agent 5.0.2 June 25, 2024Feature EnhancementsEnhanced Process LoggingProcess logging has been improved to reduce the memory usage. The agent now retains only the latest fatal log while discarding the previous ones. This bounds the potential memory used for crash logs and expresses the intent better, since if multiple fatal signals were received, the earlier ones weren\u0026rsquo;t actually fatal but handled by the process.\nPreviously, all fatal signals for a process generated detailed reports with stack trace and memory map when the process was terminated because of the signal. This caused potentially unbounded memory growth because all the logs in memory were stored to log them when the process exited.\nImproved Memory UsageReduced memory usage in the binpatch performance library.\nDefect Fixes Fixed missing process information for processes where the clone or fork event was missing. The max_n_proc_lookups parameter controls the maximum number of proc filesystem lookups performed. This change sets it to -1, meaning that no limit is applied to the number of proc scans. Previously, it was set to 1, meaning that only a single scan was allowed. The memdump.size setting was ignored in previous versions, leading to potentially excessive memory consumption up to 300 MB. The setting works as expected now, and the default is changed to 32 MB. Addressed a defect in which the event Process Tree fields were missing data. Vulnerability FixesAddressed the following vulnerabilities:\nCVE-2024-2961 CVE-2024-33599 CVE-2024-33600 CVE-2024-33601 CVE-2024-33602 Serverless Agent 5.0.1 June 07, 2024Defect Fixes Improved performance in terms of CPU and memory usage for processing policy updates Fixed excessive memory usage with workloads starting many child processes on musl-based images, such as Alpine Linux, and with Go applications Reduced memory usage in the binpatch performance library Serverless Agent 5.0.0 April 08, 2024Feature EnhancementsChanges to Deploying the Serverless Agent To prioritize between Security and Availability in deployments, configurable Serverless Agent Priority Modes have been introduced. For more information, see Configure Priority Modes.\nTo reduce the load on the Orchestrator Agent, the following changes are introduced:\nA single Workload Agent sidecar will now secure all containers within a task, whereas before each container would run its own Workload Agent. The Workload Agent now runs within the sidecar container with only the pdig instrumentation stack remaining in the workload container. For this enhancements to work, your system requires one of the following:\nserverless-patcher v5.0.0 or above for CloudFormation template Terraform provider v1.23.3 or above Availability of sysdig_serverless_agent_infoServerless Agent now exposes the Prometheus metric, sysdig_serverless_agent_info. This metric provides the following labels:\nagent_type container_id serverless_account_id serverless_cloud_vendor serverless_cluster_id serverless_task_id serverless_version Known IssuesThe Workload Agent versions 4.2 and prior will not receive policies when connected to the Orchestrator v5.0.0.\nFor more information, see the Compatibility Matrix.\nDefect FixesVulnerability FixesFixed the following vulnerabilities:\nserverless-patcher\nCVE-2024-24557 orchestrator-agent\nCVE-2021-35937 CVE-2021-35938 CVE-2021-35939 CVE-2023-46218 CVE-2023-5363 CVE-2023-5981 CVE-2023-7104 CVE-2024-0553 CVE-2024-0567 Serverless Agent 4.3.2 Hotfix Jan 12, 2024This hotfix updated the CloudFormation template, orchestrator-agent.yaml, to include default values for autoscaling. When autoscaling is disabled, the autoscaling parameters now default to 0.\nServerless Agent 4.3.2 Jan 11, 2024Defect FixesImproved Agent Error LoggingEnhanced error message clarity for cases where the Workload Agent fails to start the workload task.\nMake signal handling more robustFixed an edge case in handling signals while running instrumentation code.\nImprove ELF format compatibilityFixed instrumentation crashes associated with specific workloads, such as Chromium webdriver, that occurred when loading ELF binaries with a particular structure.\n","url":"https://docs.sysdig.com/en/release-notes/serverless-agent-release-notes/2024-archive/"},{"id":78,"title":"On-Prem Release Notes 2024","content":"6.15.1 Release, December 2024Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig PlatformJira IntegrationYou can now integrate both Jira Cloud and Jira Data center with Sysdig. This lets you open Jira tickets from within the Sysdig Secure UI and assign them to team members directly.\nSysdig SecureNavigation ReorganizationSysdig has streamlined and updated the UI navigation menus to help you access our security platform faster. For more information, see Navigation Reorganization.\nHome PageThe new Home page offers an at-a-glance, visual representation of the most important issues in your environment. You can view your Runtime Detections and Vulnerabilities Dashboards in the default Home tab. For more information, see Home.\nPackage Deny ListSysdig has added a new package deny rule that lets you control which packages are allowed in your codebase. You can add a specific package or a specific version of a package in a comma-separated list to the rule bundle. By defining these rules, you can enforce stricter security measures and maintain tighter control over your software artifacts.\nConfigurable Image tags for Falco-rules and Artifact-deployerYou can now set specific version tags for the falco-rules-installer and artifact-deployer images to deploy in airgapped environments. By default, these images are configured to use the latest versions, ensuring you have the most up-to-date falco rules and artifacts, such as malware hashes. For more information, see Configuration Parameters\n6.14.0 Release, September 2024Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig SecureAccept Risk for RulesSysdig now offers its Risk Acceptance capabilities for Rules with customizable risk management scopes. This enhancement allows you to extend risk acceptance in both broad and granular ways, giving you greater control over your security policies. Previously, accepted risk was scoped only for a CVE, image, or host.\nFor more information, see Accept Risk.\nDownload Vulnerability Scanning Results in CSV FormatYou can now download vulnerability reports in CSV format. This enhancement allows you to quickly and accurately export vulnerability data for analysis, reporting, or integration with other systems, thereby enhancing productivity and reducing the risk of data mishandling download capability.\nFor more information, see Download Vulnerability Scanning Results in CSV Format.\n6.13.0 Release, July 2024Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig PlatformNotify Expiration of Team-Based Service TokenYou will now receive alert notifications when team-based service token is about to expire.\nOptimized Sysdig InstallerThe Installer has been optimized to improve the installation time by 20%.\nPublic API SupportSysdig Public APIs for Sysdig Monitor, Sysdig Secure, and Sysdig Platform are now supported in on-prem environments. Contact Sysdig Support for details.\nSysdig SecureLayered AnalysisSysdig extends its power of container image scanning toolkit to include Layered Analysis to provide insight into image hierarchy and explore every layer. Layered analysis offers:\nImproved Ownership and Remediation: Differentiate between base image and application layers to streamline routing and remediation. The security team can update base images to newer versions, while development teams handle vulnerabilities in the application layers.\nEnhanced Investigation and Research: Browse and analyze base images and each layer individually and see the packages and vulnerabilities included in each image and layer. This helps gain insights into when and how vulnerabilities were introduced. See the exact Dockerfile command related to each vulnerability layer for a deeper understanding.\nFor information, see Layered Analysis.\nCSAF-VEX as the Primary Data Source for Redhat VulnerabilitiesSysdig has transitioned from using Redhat OVAL (Open Vulnerability and Assessment Language) as the primary data source for Redhat vulnerabilities to the new CSAF-VEX (Common Security Advisory Framework Vulnerability Exploitability eXchange). This change is aimed at enhancing the vulnerability matching accuracy, improving data quality, and streamlining Sysdig’s overall security processes. Here are the key changes introduced by CSAF-VEX:\nEnhanced Data Accuracy and Quality: CSAF-VEX provides more precise and comprehensive vulnerability information. The structured format ensures that data is presented consistently, making it easier to interpret and act upon.\nImproved Vulnerability Assessment: The transition to CSAF-VEX will enable more detailed vulnerability assessments, including specific exploitability information. This will allow for more informed decision-making regarding vulnerability prioritization and remediation.\nBetter Compatibility and Future-Proofing: CSAF-VEX is aligned with modern security standards and practices, ensuring better compatibility with other security frameworks and tools. This transition positions us to adapt more readily to future advancements in vulnerability management.\nSupport for Rocky LinuxThe new Vulnerability Management engine supports Rocky Linux versions 8 and 9.\nDefect Fixes Fixed the issue where Secure API documentation does not load as expected. Cluster Scanner retrieves the label owner from scanned clusters as expected. 6.12.0 Release, June 2024Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nUpgraded to OpenSearch v2For fresh installations and upgrades to version v6.12.0, OpenSearch v2 is included. If you are currently using on-prem version 5.x and plan to upgrade to v6.12.0, ensure that you have first migrated your environment to OpenSearch v1 by upgrading to any on-prem 6.x before proceeding with the upgrade to version v6.12.0.\nSysdig SecureDownload Scan Results in PDF FormatYou can now download scan results in PDF format showing the top 100 packages and vulnerabilities. For more information, see Download Scan Results.\nManual Scanning of Registry ImagesYou can use the Scan Now UI to manually scan the registry images. The results are displayed on the Registry page on the Sysdig Secure UI.\nDisplay Container Information in Runtime Scan ResultsRuntime Scan results will now include the following container information, in addition to the existing metadata:\nContainer.name Container.ID container.runtime.type You can also use them while scoping the scan results.\nAPI Docs in Airgap EnvironmentsAPI documentation for Sysdig Secure is now supported in Airgap Environments.\nDefect Fixes Fixed the issue in Sysdig Secure where total agent count is not shown in the Agents Dashboard.\nFixed the issue where the Cluster name is not auto-populated when creating a Vulnerability report for runtime workloads.\nFixed the issue in Installer where proxy settings where not honoured.\nTo help remove the proxy settings, a new CLI option, \u0026ndash;disable-proxy, has been added to the installer. Use this option when you want to remove an existing proxy. To remove the existing proxy setting:\nRemove the relevant entries from the values.yaml file. Use the --disable-proxy when running the installer commands, such as generate, diff, and deploy 6.11.0 Release, April 2024Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig SecureNew VM Risk Acceptance Public APIFormerly accessible solely through the UI, the Risk Acceptance feature has now been exposed via a robust Public API, granting you unparalleled control over risk acceptance. The Risk Acceptance API adheres to the rigorous standards, ensuring seamless integration and alignment with industry best practices. For more information, please Contact Support.\nRBAC Permissions Available in Vulnerability ManagementAdministrators can now define which roles are permitted to access the Vulnerability Management, Policy, Reporting and Risk Acceptance functions. For more information, see Custom Roles.\nDefect FixesFixed the issue in Installer where helm charts were not specifying node affinity, causing workloads to not be scheduled correctly.\n6.10.0 Release, April 2024Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig PlatformEnhanced Team SettingsEnterprise accounts with a large number of users within a single Team can now efficiently manage their users by using the enhanced Team Settings interface. The Teams interface, including the List and Team Edit pages have been upgraded to provide a more streamlined Team and User management experience. For more information, see Manage Teams, Roles, and Service Accounts.\nUpgrade sysdig-mini-ubi to v1.3.15The Installer has been updated with the base image v1.3.15.\nPrevent Malware Communication to Agent from CollectorDue to a race condition defect in processing malware messages in agent versions below v13.0.0, malware-related communication from the collector to the agent is prevented, even if the agent requests it.\nSysdig SecureVulnerability Feeds in Airgap EnvironmentsWhen updating the sysdigcloud-scanningv2-airgap-vuln-feeds deployment with a new image tag, the old replicas will remain available until the new one is fully operational. This feature is beneficial in cases where pulling a new image from a registry fails.\nPreviously, only one replica was active, and the pod would terminate first before the new one was created. This process could lead to backend failures if the image retrieval failed during this transition.\nDefect Fixes Fixed the issue where RKE2 clusters were missing most ingresses, resulting in the cluster failing to access different endpoints and returning a 404 error on request. Fixed an issue where Sysdig app status was visible in on-prem installations. Fixed an issue where installation was failing on OpenShift due to insufficient wait time for sysdigcloud-postgres-operator. 6.4.6 Hotfix Release, April 2024This hotfix addresses the issue of the Secure login page not being displayed after restarting the sysdigcloud-api pod.\nUpgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository includes the on-premises Installation documentation.\n6.9.1 Hotfix Release, March 2024This hotfix addresses the following:\nUpdate the rules validator for the policies backend service to allow users to upgrade their default rules to the latest available ruleset\nThe error during the upgrade process, caused by a missing import code for pvStorageSize.cassandra, has been fixed.\nThe issue where the installer incorrectly added a \\n (line feed) to the context when current-context is used but the context is not specified in the values.yaml or on the installer command line has been resolved.\nCassandra failure during the Zookeeper upgrade process in the installer when override fields are used. To fix the issue, remove the customOverride field:\ncassandra: jvmOptions: -Xms6G -Xmx8G # customOverrides: | # compaction_throughput_mb_per_sec: 300 Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\n6.7.1 Hotfix Release, March 2024This hotfix addresses an issue encountered during the zookeeper upgrade process in the installer, providing improved upgrade efficiency and speed.\nUpgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\n6.4.5 Hotfix Release, March 2024This hotfix fixes an issue with the slowness in the Secure UI.\nUpgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\n6.9.0 Release, February 2024Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nBackup and Restore PostgreSQLSysdig provides support to back up and restore the configurations data stored in high availability PostgreSQL clusters. See Backup and Restore High Availability PostgreSQL Clusters.\nUpgraded to Cassandra v4For fresh installations and upgrades to v6.9.0, Cassandra v4 will be included. If you are currently using on-prem version 5.x and plan to upgrade to v6.9.0, ensure you have upgraded your data store to Cassandra v3 before proceeding with the upgrade to v6.9.0.\nSysdig SecureMalware DetectionSysdig Secure now has the ability to detect fileless attacks using a new Falco rule on the managed policy called Sysdig Threat Detection.\nTo use this feature, your system must meet the following requirements:\nAgent version 13.0.1+ installed Sysdig Threat Detection policy enabled For more information on Sysdig solution for fileless malware detection, see Fileless Malware Detection.\nContact Sysdig representative to enable this feature in your on-prem environment.\nDefect Fixes Fixed an issue where agents were restarted when deployed on the same nodes as Cassandra instances. Fixed an issue where the scan results are not displayed on the Vulnerability Management UI. Fixed an issue where error messages continued to be displayed while viewing the Group Mappings that had not been activated. Fixed an issue where upgrading to version v6.x.0 with service accounts triggered a faulty migration that displayed the v6.4.2 UI. Fixed an issue where Data Sources UI not reflecting the connected Sysdig Agents correctly. Fixed an issue where Token, Index, and Source Type of an already-configured Splunk integration for Event Forwarding is not displayed in the Sysdig Secure UI. 6.4.4 Hotfix Release, February 2024This hotfix fixes an option to not display the Sysdig Secure API token in the UI.\nUpgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\n6.8.0 Release, January 2024Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nVulnerability Management Support for Report Generation in Zip FormatWhen you create or edit a report, you can choose JSON, NDJSON, or CSV format and you can also choose Gzip or ZIP compression format. For more information, see Reporting\npostgres-ha Operator UpgradeThe postgres-ha operator has been updated to the latest upstream version.\n5.1.12 Hotfix Release, January 2024This hotfix corrects an issue that causes failures when scanning manifests with reference to non-Linux images.\n6.4.3 Hotfix Release, January 2024This hotfix provides the option to restrict the roles that the Service Manager can assign. With this option on, the Service Manager can only assign Standard User roles to Service Developers and Service Manager roles to Service Administrators. It prevents them from assigning Advanced User, Team Manager, or any other custom roles to users.\n6.4.2 Hotfix Release, December 2023This hotfix introduces the ability to count and segment Runtime events by specific labels.\nSupport for Sysdig Terraform Provider v1.10.0The Sysdig Terraform Provider v1.10.0 is compatible with Sysdig on-prem version 6.4.0.\nUpgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nDefect Fixes Fixed reported errors in Captures at Secure-Only on-prem environments. Readiness Probe in Sysdig Agent v12.15.0 works as expected. Retrieving images and Installers works as expected. Audit logs are generated and reported after forwarding to Syslog. ","url":"https://docs.sysdig.com/en/release-notes/sysdig-on-premises-release-notes/2024-archive/"},{"id":79,"title":"Advisor","content":"Advisor provides a focused view of Kubernetes metrics, alerts, events, and advisories to help you monitor and investigate the operational health of your clusters.\u0026quot;\nAdvisor is only available to SaaS users. The feature is not currently available for on-prem environments.\nAdvisor presents your infrastructure grouped by cluster, namespace, workload, and pod.\nThe time window of metrics displayed on Advisor is the last 1 hour of collected data. To see historical values for a metric, drill down to a related dashboard or explore a metric using the Explore UI.\nLearn More Kubernetes CrashLoopBackOff Troubleshooting Kubernetes Kubernetes Capacity Planning ","url":"https://docs.sysdig.com/en/sysdig-monitor/advisor/"},{"id":80,"title":"Agent Access Keys","content":"Non-Admin UsersThe Agent Access Keys page provides a shortcut to copy the default agent access key, which is hidden behind asterisks.\nAdministrators can choose to hide this page from non-admin users. For more information, see Change Admin Settings.\nRetrieve the Agent Access KeyTo retrieve the agent access key:\nLog in to Sysdig Monitor or Sysdig Secure as an administrator.\nSelect Settings \u0026gt; Agent Access Keys.\nClick the view icon to see the access key.\nClick the copy icon to copy the access key.\nAdmin UsersIn addition to viewing the default access key, the admin users have the ability to view and manage additional access keys.\nConnecting Agents with Access KeyHere are two ways to connect agents using an access key:\nLimit: The maximum number of agents allowed to connect with this access key. This number can be greater than the number of agents available in the license (reservation + on-demand).\nReservation: The number of agent licenses that will always be available to this access key. This will directly count against the maximum available number of agent licenses. Reservations cannot exceed the maximum number of available agent licenses.\nView Access KeysThe Access Keys overview page provides a list of all the available access keys.\nYou can see the following statistics:\nAgent keys: The total number of available access keys.\nAgent keys enabled: The number of access keys that are enabled.\nTotal agents limit: The sum of all the defined limits.\nTotal agents reservation: The sum of all defined reservations.\nTotal agents connected: The sum of all currently connected agents.\nAccess Key DetailsSelecting a row from the list shows the following information for the selected access key:\nStatus Team Metadata Agents limit Agents reservation On the top right-hand side of the view, you can use the appropriate icons to edit or copy the access key, or close the panel.\nCreate and Edit Access KeyOn the The Access Keys overview page, select the three-dot menu corresponding to an access key to:\nCopy the agent key Edit the agent key Delete the agent key Only disabled agent keys can be deleted.\nWhen you add or edit an access key, provide the following information:\nStatus: The access key status toggle and indication.\nLimit: Specify the maximum number of agents.\nReservation: Specify the reserved agent count.\nTeam: Assign an access key to a team.\nYou can track their usage in the Dashboards with the label team_name for sysdig_agent_info metric.\nMetadata: You can add key-value pair for each access key. Click the Add new field option to do so. You can assign up to 20 key-value pairs for each access key.\nEnable and Disable the Access KeyYou can enable or disable an access key directly from the Access Keys overview page by selecting the toggle from the Enabled column. Selecting the toggle shows a confirmation dialog to avoid accidental enabling or disabling of access keys.\n","url":"https://docs.sysdig.com/en/administration/agent_access_key/"},{"id":81,"title":"Cloud Hosts","content":"You can:\nConfirm that the onboarding of agentless vulnerability scanning succeeded. Review the list of hosts, VPCs, and resource groups that Sysdig discovered. Validate the scope of your agentless scan and troubleshoot issues. View Host DetailsSelect Integrations \u0026gt; Cloud Hosts.\nThis page provides a host scanning summary and the details about all discovered hosts.\nHost Scanning SummaryThe at-a-glance graph at the top of the page summarizes the scanning status of all discovered hosts. The status can be:\nScanned: A Software Bill of Materials (SBOM) was successfully generated for the host. Pending: The host has been discovered and is pending SBOM extraction. Not Scanned: There was an issue performing SBOM extraction. You can hover over the status to get more information. Skipped: An administrator has chosen to skip the host from scanning. For information on skipping hosts, see Tagging Semantics. Not Supported: Scanning this host is not supported. You can hover over the status to get more information or see the list of supported hosts. Total Hosts is the cumulative number of hosts displayed with the current filters.\nHost DetailsHost details include:\nPlatform: The cloud provider of the host (AWS, GCP, Azure) Hostname: The public or private hostname Instance ID: The unique host identifier Status: The Last known state of the host Account ID: The AWS Account ID, GCP Project number, or Azure Subscription ID Region: The region in which the host is located VPC / Group: The AWS/GCP VPC or Azure Resource Group Last Seen: Time since the last Status change View VPCs and Resource Groups DetailsSelect Integrations \u0026gt; Cloud Hosts and choose the VPC/Resource Groups tab.\nAvailable StatusesVPCs or Resource Groups can have one of two statuses:\nDetected: The VPC / Resource Group was successfully detected. Skipped: An administrator has chosen to skip the VPC/Resource Group from scanning. For information on skipping, see Tagging Semantics. DetailsVPC and Resource Group details include:\nVPC/Group Name: The given identifier Status: Detected or skipped Account ID: The AWS Account ID, GCP Project number, or Azure Subscription ID Region: The region in which the VPC or Resource Group is located Filter ResultsBoth pages have the same filtering options. You can use free text search to filter the list of hosts by Hostname and Instance ID or VPCs / Resource Groups by their Name. You can also filter by:\nPlatform Account ID Region Status ","url":"https://docs.sysdig.com/en/sysdig-secure/integrations-cloud-hosts/"},{"id":82,"title":"Form and PromQL Editors","content":" Automatic Query TranslationWhen you use the Form editor, Form queries are automatically translated into an equivalent PromQL query (applying the same translation logic triggered by the Translate to PromQL button), before Sysdig forwards them to the Sysdig Prometheus API server. Regardless of whether you are building a query by using the Form or the PromQL editor, the system will therefore retrieve data by using the Sysdig Prometheus APIs.\nLegacy API and Sysdig Prometheus APIBefore automatic query translation was introduced, Form queries were sent to the legacy API, and only PromQL queries would be sent to the Sysdig Prometheus API.\nThe most important difference between data queried by the legacy API and data produced by the Sysdig Prometheus API is granularity. The data produced by the queries configured by using the Form editor will have the same granularity as the PromQL Editor.\nFor example, a 1-hour time selection will now display metrics with 10-second granularity while before this enhancement, you would only get 1-minute granularity.\nTranslation LimitationsSysdig translates Form queries to PromQL as faithfully as possible.However, some scenarios pose problems, because of the inherent differences between the two models. The following sections outline such cases and describe relevant differences between data produced by our legacy API and data produced by Sysdig Prometheus API for equivalent PromQL queries.\nClick Translate to PromQL to make further edits to the query in PromQL.\nTranslating Aggregate FunctionsTime AggregationWhen configuring a query using the Form editor and defining a time aggregation, Sysdig automatically translates the chosen time aggregation function into the equivalent Prometheus aggregation function according to the following tables.\nThe Prometheus aggregation function varies according to the type of the selected metric:\nGauge metrics that represent a single numerical value that can arbitrarily fluctuate over time, for example, CPU usage.\nCounter metrics that help you record how many times something has happened, for example, a user login.\nSee Metric Types.\nGauge Metrics Time Aggregation in Legacy API Time Aggregation in Sysdig Prometheus API avg avg_over_time sum sum_over_time min min_over_time max max_over_time rate sum_over_time / $__interval_sec roc (rate of change) deriv See: deriv Counter MetricsSysdig distinguishes counter metrics as follows and the difference between the two counter types is in the way they store values:\nPrometheus counter metrics that Sysdig refers to as prom counters.\nProm counters are monotonically increasing cumulative metrics and report the total number of events since the event reporter started. The value always increases except when the reporter restarts/reboots. This is called a reset.\nStatsD-style counter metrics that Sysdig refers to as delta counters.\nDelta counters report the number of events in the current time window\nAs an example, consider the following table that shows what a delta and prom counters would store for the same sequence of events occurrences:\nTime 10 20 30 40 50 60 delta 1 2 2 4 4 3 prom 1 3 5 4 8 11 To ensure that the same information is stored, consider the following question: how many events occurred after t=10 up to and including t=60?\nFor delta counters you sum the numbers: 2+2+4+4+3 = 15 For prom counters you have to perform: (3-1)+(5-3)+4+(8-4)+(11-8) = 15 where (3-1) is the number of events at t=20, (5-3) is the number of events at t=30, and so on. The prom counter resets between t=30 and t=40 (in fact, its value is decreased), therefore, the number of events at t=40 is just the value at t=40, which is 4 Because of the difference in the way these two counter types store values, Susdig translates the rate and sum time aggregations in two different ways based on the counter type.\nFor prom counter metrics:\nTime Aggregation in Legacy API Time Aggregation in Sysdig Prometheus API rate rate sum increase For delta counter metrics:\nTime Aggregation in Legacy API Time Aggregation in Sysdig Prometheus API rate sum_over_time / $__interval_sec sum sum_over_time For additional details about the Prometheus functions, see Query Functions.\nGroup AggregationWhen configuring a query using the Form editor and defining a Group Aggregation, Sysdig automatically translates the chosen group aggregation function into the equivalent Prometheus aggregation function. Group Aggregation function names and meanings don\u0026rsquo;t change. For example, avg stays avg in PromQL as well and it has exactly the same meaning.\nUsing top(k) / bottom(k)When a group aggregation is defined, you can explicitly select a set of aggregation labels. When this happens, data tends to become bulky and less readable on the charts. For this reason, when an aggregation label is configured, the Form editor automatically selects and returns the top 10 time series. How this selection happens in the Prometheus system is what makes the two models different.\nAs an example, imagine your data looks like the chart below, where you have four time series, represented using the colors green, blue, red, and orange.\nWhen applying the Prometheus function top(2), Prometheus independently selects the top 2 time series for each point in time on the graph. Each point in time on the graph will have its own set of top 2 time series.\nt0 t1 t2 t3 t4 t5 t6 t7 t8 t9 t10 t11 top1 blue green green green green blue orange orange orange blue green orange top2 green blue blue orange blue green green green green green orange green The output of the top(2) function applied to the time series above will therefore be represented as follows.\nNote that:\nThe green time series stays the same because its points are part of all top(2) sets. The red time series disappears because it is not part of any top(2) set. The blue and orange time series get some gaps and some isolated points, according to their presence in the various top(2) sets. Using the Latest Displayed Value with Sparse MetricTranslated spare metric queries will look like this:\navg(avg_over_time(my_metric_name[$__interval])) Sysdig uses a range vector, my_metric_name[$__interval], and therefore, Prometheus will only take the data points comprised within the $__interval into account.\nWhen displaying a sparse metric, for example, reporting values every 2 minutes, with a small time range, such as 10m, 1h, or 6h, the panel might display No Data because $__interval does not include any non-null values, while previous Form panels had a static interval of 5 minutes.\nTo see data in such cases you can:\nTranslate the Form panel to PromQL and set the Min. interval to an appropriate value. For example, 5m. Switch from Latest to Entire range. This will apply the time aggregation to all points within the selected time range. ","url":"https://docs.sysdig.com/en/sysdig-monitor/form-vs-promql/"},{"id":83,"title":"Gauge","content":"OverviewThe Gauge visualization is most effective when used to represent single data points. It provides a concise and clear display, making it easy to understand the status and value of a metric or PromQL query at a glance. The key features of the Gauge visualization include:\nCompact display: The Gauge takes up minimal screen space, making it suitable for displaying multiple metrics in a limited area. Threshold support: You can define thresholds to visually indicate when a metric exceeds or falls below certain values. This helps in quickly identifying critical conditions. Emphasis on deviation: The Gauge visualization highlights deviations from normal values, making it easier to spot anomalies and performance issues. Unit support: You can choose the appropriate unit for your metric, whether it\u0026rsquo;s a percentage, a number, a byte, a rate, or a dollar value. UsageConfigure ThresholdsTo configure thresholds for a Gauge visualization:\nClick the Thresholds tab in the Gauge configuration. Define the desired thresholds by specifying the limits. Save the configuration. Configure Minimum and MaximumTo configure the minimum and maximum values for a Gauge visualization:\nClick the Query tab in the Gauge configuration. Click the Min and Max values. Define the desired minimum and maximum values. Save the configuration. Configure UnitsTo configure the unit for a Gauge visualization:\nClick the Query tab in the Gauge configuration. Click Options. Define the desired unit for the metric. Save the configuration. Use CasesView CPU Usage of a HostTo view the CPU usage of a host using the Gauge visualization:\nStep Preview Click Add Panel to add a new panel to your dashboard. Create a New Panel Select Gauge as the visualization type. Choose the sysdig_host_cpu_used_percent metric to monitor the CPU usage of a host. Optional: In the Scope section, restrict this panel to a specific host by choosing \u0026ldquo;host_hostname is \u0026lt;your-host-name\u0026gt;\u0026rdquo;. Define four thresholds: 25, 50, 75, and 100. Thresholds indicate different levels of CPU usage. View Available to Desired Ratio of PodsTo visualize the ratio between available and desired pods in a Kubernetes cluster:\nStep Preview Click the PromQL tab. Enter the following PromQL query: sum(avg(kube_namespace_sysdig_pod_available_count{$__scope})) / sum(avg(kube_namespace_sysdig_pod_desired_count{$__scope})) * 100 Define a threshold of 75 to indicate the threshold for the pods available versus the desired ratio. Define a dashboard parameter to scope the dashboard to a cluster of your choice. ","url":"https://docs.sysdig.com/en/sysdig-monitor/gauge/"},{"id":84,"title":"Home","content":"For the Home page dashboards to display data, ensure that you complete basic onboarding and connect at least one data source; otherwise, the page provides prompts to complete the setup tasks.\nCheck the Data Source StatusYou can view and check a status summary of data sources at the top right of the page. These include:\nDetected cloud accounts Sysdig agents status, based on nodes where agents have been or could be deployed. View Cloud AccountsSelect the AWS, GCP,or Azure icon to connect a cloud account, or to see the status of connected accounts.\nFor connected accounts, you can see:\nThe number of accounts, projects, or subscriptions connected The connection status of the cluster A link to the Data Sources page, where you can take action View Sysdig AgentsSelect the Sysdig Agents icon to see:\nThe number of agents connected The nodes that require attention because their agents are out of date or almost out of date The agent status A link to the Data Sources page, where you can take action View Runtime EventsAfter you set up Threat Detection using either the Sysdig Agent or Agentless Threat Detection, you can view Runtime event trends broken down by Severity in this section.\nCheck VulnerabilitiesYou can view various charts in this section based on the scanning you set up in your environment, such as:\nruntime scanner host scanner pipeline scanning registry scanning agentless scanning The charts highlight the most critical vulnerabilities in your environment.\nPostureTo view posture data, you should set up at least one of the following: CSPM, KSPM, or CIEM.\nDepending on what is installed, you can view a breakdown of your evaluated resources by category, trends of unused permissions, poor identity hygiene practices, and trends of passing compliance requirements for your starred policies.\nYou can change starred policies/compliance trends on the Compliance page.\nIf you have not starred any policies as favorites, then the line graph displays the results from the three policies with the lowest passing scores.\n","url":"https://docs.sysdig.com/en/sysdig-secure/home/"},{"id":85,"title":"Install Shields on Hosts","content":"Sysdig Host Shield provides a comprehensive monitoring, troubleshooting, and alerting solution, delivering deep, process-level visibility into dynamic, distributed production environments. Sysdig Monitor captures and correlates full-stack data, allowing you to visualize real-time metrics through customizable dashboards. It helps optimize costs by identifying resource inefficiencies and proactively detects issues through automated alerts and anomaly detection.\nFor detailed installation instructions based on your host’s operating system, refer to:\nSysdig Monitor Host Shield for Containers Sysdig Monitor Host Shield for Packages ","url":"https://docs.sysdig.com/en/sysdig-monitor/install-hosts/"},{"id":86,"title":"Install Shield on Hosts","content":"For detailed installation instructions based on your host’s operating system, see:\nSysdig Shield for Linux hosts Sysdig Shield for Windows hosts System Requirements A Sysdig account and agent access key.\nA supported distribution or Kubernetes platform\nPort 6443 open for outbound traffic\nThe Host Shield communicates with the collector on port 6443. If you\u0026rsquo;re using a firewall, make sure to open port 6443 for outbound traffic so that the Host Shield can communicate with the collector.\nAllow traffic on port 12000 to communicate within the cluster for Kubernetes Security Posture Management (KSPM).\nLinux DistributionsThe supported Linux distributions are:\nDebian Ubuntu 18.04 and above Ubuntu (Amazon) CentOS 7 and above Alma Linux Rocky Linux Red Hat Enterprise Linux (RHEL) 7 and above SuSE Linux Enterprise Server* RHEL CoreOS (RHCOS) Fedora Fedora CoreOS Linux Mint Amazon Linux (Original) Amazon Linux 2 (AL2) Amazon Linux 2023 (AL2023) Amazon Bottlerocket Google Container Optimized OS (COS) Oracle Linux (UEH) Oracle Linux (RHCK) Azure Linux 3 EulerOS ArchLinux Flatcar Alpine Linux 3.20 and above We may support additional Linux distributions depending on the feature required. For more details, Contact Sysdig Support.\nCPU ArchitecturesThe supported CPU architectures are:\nX86 ARM Support PolicySysdig is committed to providing reliable and efficient support for its edge components, Cluster Shield and Host Shield, collectively known as Sysdig Shield.\nMonthly Release CadenceSysdig updates Sysdig Shield approximately once a month. Each release may include new features, enhancements, defect fixes, performance improvements, and CVE fixes.\nVersioning SystemSysdig Shield uses semantic (X.Y.Z) versioning:\nMajor Versions (X): Often include major new features or functionality changes, and may also include bug fixes and CVE fixes. Significant updates may require changes to usage or configuration. Minor Versions (Y): Typically introduce new features and enhancements, expanding Sysdig Shield\u0026rsquo;s capabilities without disrupting existing configurations. May also include bug fixes and CVE fixes. Hoftix Versions (Z): Primarily focus on CVE fixes and bug fixes to improve the stability of major or minor releases. You can apply them without impacting current usage or configuration. Hotfix versions are rare and are only released to address any serious issues. Version SupportSysdig provides support for major and minor versions of Sysdig Shield for 12 months from their release date, regardless of whether the Shield is deployed with Sysdig SaaS or Sysdig on-premises. Support includes fixes for any issues, and If an issue is resolved in a later version of Shield, you must upgrade to that version to receive the fix.\nSysdig does not provide hotfixes, bug fixes, or CVE patches for any version other than the latest release. Customers using the on-premises version of Sysdig may be required to upgrade to the latest release to address certain issues.\nCustomers running Shield versions older than 12 months will not receive troubleshooting support for any issues and will be requested to upgrade to the latest versions of Sysdig before any troubleshooting is done. A patch version (Z) for a major or minor release will not reset the 12 month support clock.\nCustomers running Shield versions older than 12 months will not receive:\nTroubleshooting support for any issues: Upgrade to the latest versions of Sysdig to receive troubleshooting. Prebuilt kernel probe binaries. New detection rules (Standard or Custom). VulnerabilitiesSysdig promptly addresses vulnerabilities in the Sysdig Agent and Shield. CVE fixes are provided in the a release within the following target timeframes (starting when a fix is available in a released package):\nCritical: 30 days High: 30 days Medium: 90 days Low: 180 days Sysdig does not provide CVE fixes as patches to older Shield releases.\nUpgrade OftenSysdig strongly recommends you upgrade Sysdig Shield at least once every 3 months to benefit from the latest enhancements, new features and CVE fixes.\nEnd of SupportAs part of our commitment to continuously improve the Sysdig platform, Sysdig may deprecate features or functionality over time.\nWhen a feature in Shield is scheduled for deprecation, Sysdig provides 12 months advance notice before the feature is removed. This notice period is intended to give you sufficient time to evaluate, plan, and transition to recommended alternatives, when available.\nFor details about deprecation, see Deprecation Policy.\n","url":"https://docs.sysdig.com/en/sysdig-secure/install-host-shield/"},{"id":87,"title":"How to Integrate with RHTAS for Image Signature Validation","content":"OverviewThe Red Hat Trusted Artifact Signer (RHTAS) provides an enterprise-grade, Red Hat-supported implementation of the Sigstore project for securely signing and verifying container images and other software artifacts.\nWhen integrated with Kubernetes or OpenShift admission control, RHTAS enables organizations to enforce signature verification policies that ensure only trusted and verifiable images are admitted to clusters.\nRHTAS includes the full Sigstore stack:\nFulcio: issues short-lived, OIDC-based signing certificates. Rekor: records immutable transparency logs of signing events. TUF: distributes and manages trust roots for verification. Together, these components create a verifiable chain of trust that prevents tampering, strengthens supply chain integrity, and simplifies compliance for signed artifacts.\nFor more information, see the Red Hat Trusted Artifact Signer.\nPurpose of Admission Control IntegrationIntegrating RHTAS with Sysdig allows Kubernetes and OpenShift administrators to enforce admission-time verification of container images.\nThis ensures that only signatures issued by your RHTAS instance and by your organization’s trusted identities are accepted.\nDuring deployment, Sysdig verifies each image against the configured RHTAS trust root and OIDC identity to ensure that:\nOnly verified images signed through RHTAS are admitted to the cluster. Supply chain integrity is maintained from build to production. Tampering and substitution attacks are blocked before execution. Compliance frameworks (for example, SLSA or NIST 800-204D) are supported through transparent verification and logging. Benefits Capability Description Policy-driven enforcement Integrates with Sysdig Admission Control to automatically reject unsigned or invalid images. Identity-based verification Uses Fulcio-issued short-lived certificates tied to developer or system OIDC identities. Immutable transparency logs Rekor maintains tamper-evident logs for all signing events. Consistent trust model Applies the same RHTAS trust root across build, registry, and runtime environments. Operational simplicity Red Hat manages and supports the Sigstore components, reducing PKI complexity. SummaryIntegrating RHTAS with Sysdig Cluster Shield extends software supply chain trust directly into Kubernetes and OpenShift admission control.\nThis ensures that only authentic, verifiable container images signed by your RHTAS instance are deployed. It strengthens runtime security and maintains a provable chain of custody from build to production.\nConfigurationCluster ShieldTo enable verification against your RHTAS instance, configure Sysdig Cluster Shield with your RHTAS trust root details.\nCluster Shield performs runtime verification using the TUF root and checksum you provide.\nYou need the following from your RHTAS deployment:\nRHTAS hostname (for example: rhtas.apps.acme-cluster.example.com) TUF root file URL (for example: https://tuf.rhtas.apps.acme-cluster.example.com/root.json) TUF root checksum (SHA-256 or SHA-512 format) Using the Sysdig Shield Helm chart, configure the following parameters:\nfeatures: supply_chain: enabled: true image_signature: cosign: mirror: https://tuf.rhtas.apps.acme-cluster.example.com # Optional: only override if your root differs from the default RHTAS location root: https://tuf.rhtas.apps.acme-cluster.example.com/example/root.json root_checksum: sha256:8d31cb9e6b5f89c224e621e1eac5e4d3bcd20a02e31d69394f0f8b62f88e743c Policy ConfigurationAll trust and identity settings for signature verification are defined in the Sysdig backend Image Signature Validation Policy.\nTo validate signatures created by RHTAS, configure your policy using the OIDC Provider mechanism:\nSet the OIDC Issuer to match your RHTAS Fulcio issuer endpoint (for example, https://keycloak.rhtas.apps.acme-cluster.example.com/realms/trusted-artifacts). Define the Certificate Identity corresponding to the signing user, service account, or build system (regex supported). Optionally provide a Certificate Chain in PEM format to override the default TUF-rooted trust chain used by Cluster Shield. Example\nField Example Value Description OIDC Issuer ^https://keycloak.rhtas.apps.acme-cluster.example.com/realms/trusted-artifacts$ OIDC issuer used by your RHTAS Fulcio instance. Certificate Identity ^system:serviceaccount:ci-pipeline:signer$ Identity pattern for the signer. Certificate Chain (optional) PEM-encoded chain of intermediate and root certs. Used to override the default trust chain if required. Example Certificate Chain in PEM Format\n-----BEGIN CERTIFICATE----- MIIGczCCBJegAwIBAgIQDk... (Server Certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIF7jCCA9mgAwIBAgIQ... (Intermediate Certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIF7jCCA9mgAwIBAgIQ... (Root Certificate) -----END CERTIFICATE----- Example Use Cases Enforce all workloads running in production are signed by your internal RHTAS instance. Prevent deployment of unsigned or third-party images. Support compliance frameworks requiring verifiable software provenance and signing attestations. See Also Image Signature Validation Policy Red Hat Trusted Artifact Signer Documentation Cosign Verification Reference Sigstore Project Overview ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/policies/supply_chain_policies/how-to-rhtas/"},{"id":88,"title":"Enable HTTP Proxy for Linux Agents","content":"Agent BehaviourThe agent can connect to the collector through an HTTP proxy by sending an HTTP CONNECT message and receiving a response. The proxy then initiates a TCP connection to the collector. These two connections form a tunnel that acts like one logical connection.\nBy default, the agent will encrypt all messages sent through this tunnel. This means that after the initial CONNECT message and response, all the communication on that tunnel is encrypted by SSL end-to-end. This encryption is controlled by the top-level ssl parameter in the agent configuration.\nOptionally, the agent can add a second layer of encryption, securing the CONNECT message and response. This second layer of encryption may be desired in the case of HTTP authentication if there is a concern that network packet sniffing could be used to determine the user\u0026rsquo;s credentials. This second layer of encryption is enabled by setting the ssl parameter to true in the http_proxy section of the agent configuration. See Examples for details.\nConfigurationYou specify the following parameters at the same level as http_proxy in the dragent.yaml file. These existing configuration options affect the communication between the agent and collector (both with and without a proxy).\nssl: Default: true. It is not recommended to change this setting. If set to false, the metrics sent from the agent to the collector are unencrypted.\nssl_verify_certificate: Determines whether the agent verifies the SSL certificate sent from the collector (default is true).\nThe following configuration options affect the behavior of the HTTP Proxy setting. You specify them under the http_proxy heading in the dragent.yaml file.\nproxy_host: Indicates the hostname of the proxy server. The default is an empty string, which implies communication through an HTTP proxy is disabled.\nproxy_port: Specifies the port on the proxy server the agent should connect to. The default is 0, which indicates that the HTTP proxy is disabled.\nproxy_user : Required if HTTP authentication is configured. This option specifies the username for the HTTP authentication. The default is an empty string, which indicates that authentication is not configured.\nproxy_password : Required if HTTP authentication is configured. This option specifies the password for the HTTP authentication. The default is an empty string. Specifying proxy_user with no proxy_password is allowed.\nssl: Default: false. If set to true, the connection between the agent and the proxy server is encrypted.\nNote that this parameter requires the top-level ssl parameter to be enabled, as the agent does not support SSL to the proxy but unencrypted traffic to the collector. This additional security prevents you from misconfiguring the agent assuming the metrics are as well encrypted end-to-end when they are not.\nssl_verify_certificate: Determines whether the agent will verify the certificate presented by the proxy.\nThis option is configured independently of the top-level ssl_verify_certificate parameter. This option is enabled by default. If the provided certificate is not correct, this option can cause the connection to the proxy server to fail.\nca_certificate: The path to the CA certificate for the proxy server. If ssl_verify_certificate is enabled, the CA certificate must be signed appropriately.\nExamplesSSL Between Proxy and CollectorIn this example, SSL is enabled only between the proxy server and the collector.\ncollector_port: 6443 ssl: true ssl_verify_certificate: true http_proxy: proxy_host: squid.yourdomain.com proxy_port: 3128 SSLThe following example shows SSL is enabled between the agent and the proxy server as well as between the proxy server and the collector.\ncollector_port: 6443 ssl: true http_proxy: proxy_host: squid.yourdomain.com proxy_port: 3129 ssl: true ssl_verify_certificate: true ca_certificate: /usr/proxy/proxy.crt SSL with Username and PasswordThe following configuration instructs the agent to connect to a proxy server located at squid.yourdomain.com on port 3128. The agent will request the proxy server to establish an HTTP tunnel to the Sysdig collector at collector-your.sysdigcloud.com on port 6443. The agent will authenticate with the proxy server using the given user and password combination.\ncollector: collector-your.sysdigcloud.com collector_port: 6443 http_proxy: proxy_host: squid.yourdomain.com proxy_port: 3128 proxy_user: sysdig_customer proxy_password: 12345 ssl: true ssl_verify_certificate: true ca_certificate: /usr/proxy/proxy_cert.crt ## Learn More To use a proxy on the Serverless Workload Agent, see [Enable HTTP Proxy for the Serverless Workload Agent](/en/sysdig-secure/http-proxy-for-serverless-agents/). ","url":"https://docs.sysdig.com/en/sysdig-secure/http-proxy-classic-agents/"},{"id":89,"title":"Linux Hosts","content":"ContainersFor all the supported Sysdig Secure features on hosts using containers, you are required to install the following Agent components on hosts:\nAgent Vulnerability Host scanner Posture Host Analyzer Rapid Response PackagesFor all the supported Sysdig Secure features on hosts using a package, you are required to install the following Agent components on hosts:\nAgent Host scanner Next StepsInstall the agent components using container\nInstall the agent components using a package\n","url":"https://docs.sysdig.com/en/sysdig-secure/install-agent-components/hosts/"},{"id":90,"title":"Manual Task Instrumentation","content":"Secure the Containers with the Workload AgentCompatible with: Workload Agent version 5.0 and later\nTo secure your containers with Workload Agent, do the following:\nEnable task pid mode at the task level:\n{ \u0026#34;containerDefinitions\u0026#34;: [...], + \u0026#34;pidMode\u0026#34;: \u0026#34;task\u0026#34; } Add the Sysdig sidecar container to your existing containerDefinitions.\nThis Sysdig sidecar container initiates the Workload Agent to secure the containers specified in the task.\nGive it a name, such as sysdigInstrumentation.\nUse the quay.io/sysdig/workload-agent:latest image for this container, and leave the entryPoint and command fields empty.\nProvide the sidecar container with the following environment variables:\nSYSDIG_COLLECTOR, SYSDIG_COLLECTOR_PORT and SYSDIG_ACCESS_KEY\nSYSDIG_PRIORITY: Specify either availability or security, depending on your use case.\nSYSDIG_SIDECAR : Set to auto.\nThis allows the Workload Agent to reach the Sysdig Collector.\n{ ... \u0026#34;containerDefinitions\u0026#34;: [ ... + { + \u0026#34;name\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, + \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/workload-agent:latest\u0026#34; + \u0026#34;environment\u0026#34;: [ + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;collector.sysdigcloud.com\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR_PORT\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;6443\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_ACCESS_KEY\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;access_key\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_PRIORITY\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;availability\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_SIDECAR\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;auto\u0026#34; + } + ] + } ] } For each container you want to secure, add a volume mount from the sysdigInstrumentation sidecar container to your container.\nThis provides the Sysdig\u0026rsquo;s userspace instrumentation to the container.\n{ ... \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-container-1\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;myapp:latest\u0026#34;, \u0026#34;entryPoint\u0026#34;: [\u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;entryPoint\u0026#34;], ... + \u0026#34;volumesFrom\u0026#34;: [ + { + \u0026#34;sourceContainer\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, + \u0026#34;readOnly\u0026#34;: true + } + ] } ] } For each container you want to secure, add the SYS_PTRACE Linux capability to enable userspace instrumentation.\n{ ... \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-container-1\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;myapp:latest\u0026#34;, \u0026#34;entryPoint\u0026#34;: [\u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;entryPoint\u0026#34;], ... \u0026#34;volumesFrom\u0026#34;: [ { \u0026#34;sourceContainer\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, \u0026#34;readOnly\u0026#34;: true } ], + \u0026#34;linuxParameters\u0026#34;: { + \u0026#34;capabilities\u0026#34;: { + \u0026#34;add\u0026#34;: [\u0026#34;SYS_PTRACE\u0026#34;] + } + } } ] } For each container you want to secure, prepend /opt/draios/bin/instrument to the entryPoint.\n{ ... \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-container-1\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;myapp:latest\u0026#34;, + \u0026#34;entryPoint\u0026#34;: [\u0026#34;/opt/draios/bin/instrument\u0026#34;, \u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;entryPoint\u0026#34;], ... \u0026#34;volumesFrom\u0026#34;: [ { \u0026#34;sourceContainer\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, \u0026#34;readOnly\u0026#34;: true } ], \u0026#34;linuxParameters\u0026#34;: { \u0026#34;capabilities\u0026#34;: { \u0026#34;add\u0026#34;: [\u0026#34;SYS_PTRACE\u0026#34;] } } } ] } This enables the Sysdig instrumentation to run in the secured container.\nProvide each container you want to secure with the following environment variables:\nSYSDIG_SIDECAR set to auto SYSDIG_PRIORITY set to either availability or security, depending on your use case. { ... \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-container-1\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;myapp:latest\u0026#34;, \u0026#34;entryPoint\u0026#34;: [\u0026#34;/opt/draios/bin/instrument\u0026#34;, \u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;entryPoint\u0026#34;], ... \u0026#34;volumesFrom\u0026#34;: [ { \u0026#34;sourceContainer\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, \u0026#34;readOnly\u0026#34;: true } ], \u0026#34;linuxParameters\u0026#34;: { \u0026#34;capabilities\u0026#34;: { \u0026#34;add\u0026#34;: [\u0026#34;SYS_PTRACE\u0026#34;] } }, \u0026#34;environment\u0026#34;: [ ... + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_SIDECAR\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;auto\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_PRIORITY\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;availability\u0026#34; + } ] } ] } Save your updated task definition, and then deploy it to your ECS cluster.\nExample InstrumentationThe example guides you through manually instrumenting your task definition to deploy the Sysdig Workload Agent in availability mode. While this method demands more manual configuration compared to using serverless-patcher or embedding the Sysdig Workload Agent in your container image, it offers greater control over the instrumentation process.\nFor the following generic task definition:\n{ \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-container-1\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;myapp:latest\u0026#34;, \u0026#34;entryPoint\u0026#34;: [\u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;entryPoint\u0026#34;], \u0026#34;command\u0026#34;: [\u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;command\u0026#34;], \u0026#34;environment\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-envar\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;my-value\u0026#34; } ] } ] } The instrumented version is:\n{ \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-container-1\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;myapp:latest\u0026#34;, + \u0026#34;entryPoint\u0026#34;: [\u0026#34;/opt/draios/bin/instrument\u0026#34;, \u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;entryPoint\u0026#34;], \u0026#34;command\u0026#34;: [\u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;command\u0026#34;] \u0026#34;environment\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-envar\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;my-value\u0026#34; }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_SIDECAR\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;auto\u0026#34;, + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_PRIORITY\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;availability\u0026#34;, + } ], + \u0026#34;linuxParameters\u0026#34;: { + \u0026#34;capabilities\u0026#34;: { + \u0026#34;add\u0026#34;: [\u0026#34;SYS_PTRACE\u0026#34;] + } + }, + \u0026#34;volumesFrom\u0026#34;: [ + { + \u0026#34;sourceContainer\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, + \u0026#34;readOnly\u0026#34;: true + } + ] }, + { + \u0026#34;name\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, + \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/workload-agent:latest\u0026#34; + \u0026#34;environment\u0026#34;: [ + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;collector.sysdigcloud.com\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR_PORT\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;6443\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_ACCESS_KEY\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;0123456789abcdef\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_PRIORITY\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;availability\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_SIDECAR\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;auto\u0026#34; + } + ] + } + ], + \u0026#34;pidMode\u0026#34;: \u0026#34;task\u0026#34; } Upgrade Workload Agent v4.x to 5.0Given a generic task definition secured by the Workload Agent 4.x as the following:\n{ \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-container-1\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;myapp:latest\u0026#34;, \u0026#34;entryPoint\u0026#34;: [\u0026#34;/opt/draios/bin/instrument\u0026#34;, \u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;entryPoint\u0026#34;], \u0026#34;command\u0026#34;: [\u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;command\u0026#34;] \u0026#34;environment\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-envar\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;my-value\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;collector.sysdig.com\u0026#34;, }, { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR_PORT\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;6443\u0026#34;, }, { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_ACCESS_KEY\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;0123456789abcdef\u0026#34; } ], \u0026#34;linuxParameters\u0026#34;: { \u0026#34;capabilities\u0026#34;: { \u0026#34;add\u0026#34;: [\u0026#34;SYS_PTRACE\u0026#34;] } }, \u0026#34;volumesFrom\u0026#34;: [ { \u0026#34;sourceContainer\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, \u0026#34;readOnly\u0026#34;: true } ] }, { \u0026#34;name\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/workload-agent:4.3.2\u0026#34; } ] } Turn on the task pid mode at the task level:\n{ \u0026#34;containerDefinitions\u0026#34;: [...], + \u0026#34;pidMode\u0026#34;: \u0026#34;task\u0026#34; } Update the Workload Agent image to v5.0.0:\n{ \u0026#34;containerDefinitions\u0026#34;: [ ..., { \u0026#34;name\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, + \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/workload-agent:5.0.0\u0026#34; } ], \u0026#34;pidMode\u0026#34;: \u0026#34;task\u0026#34; } Provide the following environment variables to the Sysdig sidecar container:\nSYSDIG_COLLECTOR, SYSDIG_COLLECTOR_PORT and SYSDIG_ACCESS_KEY\nSYSDIG_PRIORITY : Specify either availability or security, depending on your use case.\nSYSDIG_SIDECAR: Set to to auto.\n{ \u0026#34;containerDefinitions\u0026#34;: [ ..., { \u0026#34;name\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/workload-agent:5.0.0\u0026#34; + \u0026#34;environment\u0026#34;: [ + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;collector.sysdig.com\u0026#34;, + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR_PORT\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;6443\u0026#34;, + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_ACCESS_KEY\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;0123456789abcdef\u0026#34;, + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_PRIORITY\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;availability\u0026#34; + }, + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_SIDECAR\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;auto\u0026#34; + } + ], } ] } Add the environment variable, SYSDIG_SIDECAR=\u0026quot;auto\u0026quot;, to the secured container:\n{ \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;my-container-1\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;myapp:latest\u0026#34;, \u0026#34;entryPoint\u0026#34;: [\u0026#34;/opt/draios/bin/instrument\u0026#34;, \u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;entryPoint\u0026#34;], \u0026#34;command\u0026#34;: [\u0026#34;my\u0026#34;, \u0026#34;original\u0026#34;, \u0026#34;command\u0026#34;] \u0026#34;environment\u0026#34;: [ ..., + { + \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_SIDECAR\u0026#34;, + \u0026#34;value\u0026#34;: \u0026#34;auto\u0026#34;, + } ], \u0026#34;linuxParameters\u0026#34;: { \u0026#34;capabilities\u0026#34;: { \u0026#34;add\u0026#34;: [\u0026#34;SYS_PTRACE\u0026#34;] } }, \u0026#34;volumesFrom\u0026#34;: [ { \u0026#34;sourceContainer\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, \u0026#34;readOnly\u0026#34;: true } ] }, { \u0026#34;name\u0026#34;: \u0026#34;sysdigInstrumentation\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/workload-agent:5.0.0\u0026#34; \u0026#34;environment\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;collector.sysdig.com\u0026#34;, }, { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_COLLECTOR_PORT\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;6443\u0026#34;, }, { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_ACCESS_KEY\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;0123456789abcdef\u0026#34;, }, { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_PRIORITY\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;availability\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_SIDECAR\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;auto\u0026#34; } ], } ] } Next StepsAfter the deployment is completed, security-related events will be visible in the Sysdig Secure Events feed.\nOptionally, you can perform advanced Configuration steps.\n","url":"https://docs.sysdig.com/en/sysdig-secure/ecs-fargate-manual/"},{"id":91,"title":"Network","content":"PrerequisitesSysdig agent: 10.7.0+\nSupported CNI Plugins:\nCalico Weave Cilium OVS Coverage Limits\nCommunications to/from k8s nodes are not recorded. Workloads with no recorded communications are not present in the workloads list. Understand the Network Security Policy ToolBy default, all pods in a Kubernetes cluster can communicate with each other without any restrictions. Kubernetes Network Policies help you isolate the microservice applications from each other, to limit the blast radius and improve the overall security posture.\nWith the Network Security Policy tool, you can generate and fine-tune Kubernetes network policies within Sysdig Secure. Use it to generate a \u0026ldquo;least-privilege\u0026rdquo; policy to protect your workloads, or view existing network policies that have been applied to your workloads. Sysdig leverages native Kubernetes features and doesn\u0026rsquo;t require any additional networking requirements other than the CNIs already supported.\nBenefitsSysdig Network Security tool provides:\nOut-of-the-box visibility into network traffic between applications and services, with a visual topology map to help identify communications. A baseline network policy that you can directly refine and modify to match your desired declarative state. Automated KNP generation based on the network communication baseline + user-defined adjustments. Least-privilege: KNPs follow an allow-only model - it forbids any communication that is not explicitly allowed. Enforcement delegated to the Kubernetes control plane, avoiding additional instrumentation or directly tampering with the host\u0026rsquo;s network configuration Map workloads to network policies applied to your cluster, helping operators and developers understand why a pods communication may or may not be blocked. The ability to view the network policies applied to a cluster for a particular workload or workloads, with drill-down details to the raw yaml. Access the ToolTo access Network:\nLog in to Sysdig Secure.\nSelect Inventory \u0026gt; Network.\nSysdig will prompt you to Select a cluster + namespace + workload then displays the Network Security Policies page.\nYou can now generate policies, review and tune them, and finesse configurations or troubleshoot.\n","url":"https://docs.sysdig.com/en/sysdig-secure/network/"},{"id":92,"title":"Piechart","content":"UsageConfigure your queryTo create a Pie Chart visualization, you must configure a query with a grouping function to define the segments of the chart:\nOpen or create a dashboard in the Dashboards module.\nThe metrics query page appears.\nSelect the visualization type Piechart.\nDefine a metric you want to visualize as a Piechart.\nApply a grouping function such as avg, max, or sum to determine how each entity is calculated.\nChoose labels to segment the Piechart, such as kube_namespace_name or kube_node_name.\nFor Displayed Value, decide whether the Piechart should show the latest value for each segment or an aggregated value across the entire range of the selected time frame.\nConfigure UnitsTo display your Piechart with a specific unit, such as seconds, dollars, or percent:\nSelect the Query tab in the metric configuration. Click Options. Define the desired unit for the metric. Save your changes. Use CasesView Container CPU Usage broken down by NamespaceTo view the CPU usage of a host using the Piechart visualization:\nStep Preview Click Add Panel to add a new panel to your dashboard. Create a New Panel Select Piechart as the visualization type. Choose the sysdig_container_cpu_used_percent metric to monitor the CPU usage of a container. Select the kube_namespace_name label to visualize this metric broken down by namespace Save the chart in order to visualize your container CPU utilization sliced by namespace ","url":"https://docs.sysdig.com/en/sysdig-monitor/piechart/"},{"id":93,"title":"Plugin Library for Sysdig Secure","content":" Jenkins GitHub Action GitLab Backstage Visual Studio Code ServiceNow Splunk Azure Pipelines AWS Codepipeline CircleCI Tekton Pipelines ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/integrations-for-sysdig-secure/plugin-library/"},{"id":94,"title":"Scanning Guidelines","content":"Host ScanningA host is any runtime entity where you could execute the Sysdig agent. This includes virtual machines, Kubernetes nodes, bare metal, and cloud-managed hosts, such as EC2. Sysdig offers different ways to scan the host in your environment. You can install Sysdig Shield, or connect a cloud account. Sysdig recommends you install Sysdig Shield on hosts.\nEnable Host ScanningSysdig Shield can scan hosts for vulnerabilities.\nYou can install Sysdig Shield on Kubernetes or Hosts.\nScanning Non-Kubernetes ContainersYou can also extend the \u0026ldquo;host scanner\u0026rdquo; to scan for non-Kubernetes containers.\nFor more details, see Container Scanning.\nAgentless Host ScanningYou can deploy agentless vulnerability management host scanning in AWS, GCP, or Azure using the Cloud Account onboarding wizard.\nNote: You can apply tags to limit the scope on VPC/instance/disk access on your infrastructure. Do it before connecting the account, as described in the Prerequisites, or later on.\nSee Connect Cloud Accounts for AWS, GCP, or Azure, for installation details.\nSee Integrations \u0026gt; SIEM \u0026amp; Data Platforms | Cloud Hosts to check the status of the discovered resources.\nView Scan Results in the UIAgent-Based If the default parameter nodeAnalyzer.nodeAnalyzer.hostScanner.scanOnStart=true is set, then a scan will start just after the pod is ready. You can expect the results in a few minutes, ~15 minutes max. If this parameter is not set, results will be shown ~11 hours from installation. In all cases, scans are refreshed every 12 hours. Helm chart and Docker container installations behave the same. Agentless It could take up to 15 minutes before scan results appear in Runtime. Scans are refreshed every 24 hours. See Integrations \u0026gt; SIEM \u0026amp; Data Platforms | Cloud Hosts to check the status of the discovered resources.\nUsageOnce you have deployed the host scanner in your environment, the Runtime UI will integrate the findings alongside the runtime workload results, based on an out-of-the-box Vulnerability policy.\nFilter for HostsYou can filter to find results of host scanning using the quick links in the banner at the top of the page, and/or the filter bar.\nAgent-Based Result Filters Kubernetes cluster name Cloud account id Cloud account region Host Name Agent tags Agentless Result Filters Cloud account id Cloud account region Host Name Cloud instance ID (text search) See Vulnerability Policies|Runtime.\nDownload ReportsYou can schedule and download reports for scanning done on hosts as well as containers. See Reporting for more information.\nContainer ScanningTo manage container vulnerabilities in your runtime environment, you can extend the Host Scanner to scan for Docker and Podman containers present within the host file system. Sysdig provides a list of vulnerabilities, policy evaluations, has-fix, and has-exploit information to help you focus on the most critical vulnerabilities in your environment.\nSysdig supports the following container scanning types :\nKubernetes containers: The runtime scanner installed with the Sysdig agent scans for runtime vulnerabilities in Kubernetes workloads. Non-Kubernetes containers: To scan non-Kubernetes containers such as Docker, you can extend any of the three non-Kubernetes host scanning configurations, as described below. This section covers non-Kubernetes container scanning. For information on Kubernetes container scanning, see Cluster Shield.\nPrerequisites Sysdig Secure SaaS, running the Vulnerability Management engine\nHost Scanner v.0.7.0+\nSupported Container Versions Docker Engine API Version v1.21 (introduced in Docker Engine 1.9.0) and above. Podman version 3.1+ LimitationsReporting features are not yet supported for non-Kubernetes container scanning. Risk Spotlight (In-Use) is supported when using Sysdig Host Shield.\nInstall on a Host as a ContainerTo install on a host as a container:\nRun the following Docker command to deploy the Sysdig Host Scanning container:\ndocker run --detach -e HOST_FS_MOUNT_PATH=/host -e SYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; -e SYSDIG_API_URL=\u0026lt;sysdig-secure-endpoint\u0026gt; -e SCAN_CONTAINERS_ENABLED=true -e SCAN_ON_START=true -v /:/host:ro -v /var/run:/host/var/run:ro --uts=host --net=host quay.io/sysdig/vuln-host-scanner:$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt) This command downloads and starts the Sysdig Host Scanning container.\nReplace with your agent access key, and with the URL for your Sysdig Secure endpoint by region. Once the container is running, the scanner begins scanning your host for vulnerabilities and providing security recommendations. You can view the results in the Sysdig Secure UI after 12 hours of installation as scans are refreshed every 12 hours.\nContainer scans will be shown within 30 minutes of installation. They are refreshed four times per day if new vulnerabilities are added to Sysdig\u0026rsquo;s vulnerability database.\nBy default, the host scanner attempts to connect to the following sockets:\nDocker Unix socket /var/run/docker.sock Podman Unix socket /var/run/podman.sock If it cannot connect to either Docker and Podman Sockets the host-scanner will exit with an error, unless you specify the -e IGNORE_CONTAINER_SCAN_INIT_FAILURE=true environment variable.\n(Optional) If you have a custom socket location, you can override it by setting a custom socket location with environment variables:\n-e DOCKER_SOCKET_PATHS=unix:///var/run/docker.sock -e PODMAN_SOCKET_PATHS=unix:///var/run/podman.sock Install as an RPM PackageTo install as an RPM package:\nConfigure the RPM repository and Sysdig GPG key:\nsudo rpm --import https://download.sysdig.com/DRAIOS-GPG-KEY.public sudo curl -o /etc/yum.repos.d/draios.repo https://download.sysdig.com/stable/rpm/draios.repo Install the vuln-host-scanner package:\nsudo yum install vuln-host-scanner --refresh -y Note: On RHEL/CentOS platforms, use sudo yum clean expire-cache \u0026amp;\u0026amp; sudo yum install vuln-host-scanner -y\nCreate the vuln-host-scanner configuration file:\ncat \u0026lt;\u0026lt; EOF | sudo tee /opt/draios/etc/vuln-host-scanner/env SYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; SYSDIG_API_URL=\u0026lt;api-url\u0026gt; # optional SCAN_ON_START=true # container scanning options SCAN_CONTAINERS_ENABLED=true # optional container scanning parameters. # Uncomment and provide them only if your docker / podman setup have a # different socket path # DOCKER_SOCKET_PATHS=unix:///var/run/docker.sock # PODMAN_SOCKET_PATHS=unix:///var/run/podman.sock # # Uncomment the following if you want the host-scanner to scan the host anyway # in case it cannot connect to both Docker and Podman sockets # IGNORE_CONTAINER_SCAN_INIT_FAILURE=true EOF Enable and start the vuln-host-scanner.service service:\nsudo systemctl enable --now vuln-host-scanner.service Check logs to verify your configuration:\nsudo journalctl -fu vuln-host-scanner.service Install as a Binary ApplicationTo install your container as a binary application:\nDownload the latest version of sysdig-host-scanner with:\nIntel Processor (AMD64)\ncurl -LO \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-host-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)/linux/amd64/sysdig-host-scanner\u0026#34; ARM Processor (ARM64)\ncurl -LO \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-host-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)/linux/arm64/sysdig-host-scanner\u0026#34; Optionally, you can check the sha256sum as follows:\nIntel Processor (AMD64)\nsha256sum -c \u0026lt;(curl -sL \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-host-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)/linux/amd64/sysdig-host-scanner.sha256\u0026#34;) ARM Processor (ARM64)\nsha256sum -c \u0026lt;(curl -sL \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-host-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)/linux/arm64/sysdig-host-scanner.sha256\u0026#34;) Set the executable flag on the file:\nchmod +x ./sysdig-host-scanner You only need to download and set the executable once.\nYou can scan the host by running the sysdig-host-scanner command:\nSYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; SYSDIG_API_URL=\u0026lt;api-url\u0026gt; ./sysdig-host-scanner Optionally, create an environment file to store the configuration and a systemd unit file to run the binary as a service:\nsudo mv ./sysdig-host-scanner /usr/local/bin/vuln-host-scanner sudo restorecon -Rv /usr/local/bin/vuln-host-scanner sudo mkdir -p /opt/draios/etc/vuln-host-scanner/ cat \u0026lt;\u0026lt; EOF | sudo tee /opt/draios/etc/vuln-host-scanner/env SYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; SYSDIG_API_URL=\u0026lt;api-url\u0026gt; # optional SCAN_ON_START=true EOF cat \u0026lt;\u0026lt; EOF | sudo tee /etc/systemd/system/vuln-host-scanner.service [Unit] Description=Sysdig Vuln Host Scanner component [Service] EnvironmentFile=/opt/draios/etc/vuln-host-scanner/env ExecStart=/usr/local/bin/vuln-host-scanner [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now vuln-host-scanner.service Add Custom Sockets (Optional)By default, the host scanner attempts to connect to the following sockets:\nDocker Unix socket /var/run/docker.sock Podman Unix socket /var/run/podman.sock If you have a custom socket location, you can override it by setting the following environment variables:\n-e DOCKER_SOCKET_PATHS=unix:///var/run/docker.sock -e PODMAN_SOCKET_PATHS=unix:///var/run/podman.sock as follows:\nSYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; SYSDIG_API_URL=\u0026lt;api-url\u0026gt; SCAN_CONTAINERS_ENABLED=true DOCKER_SOCKET_PATHS=unix:///var/run/docker.sock PODMAN_SOCKET_PATHS=unix:///var/run/podman.sock ./sysdig-host-scanner If it cannot connect to either Docker or Podman the host-scanner will exit with an error, unless you specify the IGNORE_CONTAINER_SCAN_INIT_FAILURE=true environment variable.\nEnvironment FileIf you are creating the environment file to store the configuration and a systemd unit file to run the binary as a service, add the following to the /opt/draios/etc/vuln-host-scanner/env section:\n\\# optional container scanning parameters. \\# Uncomment and provide them only if your docker / podman setup have a \\# different socket path \\# DOCKER_SOCKET_PATHS=unix:///var/run/docker.sock \\# PODMAN_SOCKET_PATHS=unix:///var/run/podman.sock Container Scanning via Agentless Host ScanningTo enable container scanning through Sysdig Agentless Host Scanning:\nConnect your cloud account with Agentless Scanning enabled. See Connect Cloud Accounts\nNavigate to your cloud account under Cloud Accounts and locate your specific cloud provider.\nNavigate to the individual account, select it, and enable the Container Scanning check box.\nLimitations Risk Spotlight and In Use integration is not supported. Machines where Docker is configured to use the containerd snapshotter are not supported. This is the default configuration starting with Docker Engine version 29. Unscanned WorkloadsSometimes, Host Shield or Cluster Shield cannot successfully scan a workload.\nView Unscanned WorkloadsTo view unscanned workloads in the UI:\nLog in to Sysdig Secure.\nNavigate to Graph Search.\nSearch using the following query:\nMATCH ScanStatus WHERE ScanStatus.status = \u0026#39;error\u0026#39;; The search results show which workloads were not successfully scanned.\nError CodesScans might fail for various reasons. You can use the associated error code to investigate the reason for failure. You can find these codes in the ScanStatus Code column of the Search results in the Sysdig UI.\nError codes include:\nError Code Description 4000 Generic error. Ths scan on this resource failed. Check the logs for the source component for more details. 4001 SBOM Extraction Failed. 401 Unauthorized. The system was unable to access the registry. Check the credentials for the client component. 4002 SBOM Extraction Failed. 403 Forbidden. The system was unable to access the registry. Check the credentials for the client component. 4003 SBOM Extraction Failed. 503 Registry unavailable. The system was unable to contact the registry. Check your network connectivity. 4004 SBOM Extraction Failed. 404 Image not found. Check your registry or credential setup. 4006 SBOM Extraction Failed. No Response. Check the registry\u0026rsquo;s status and configuration. 4010 The Software Bill of Material (SBOM) extraction couldn\u0026rsquo;t be completed. Contact support for assistance. 4011 The Software Bill of Material (SBOM) upload couldn\u0026rsquo;t be completed. Contact support for assistance. For further information and assistance with scanning, Contact Support.\n","url":"https://docs.sysdig.com/en/sysdig-secure/scanning-usecases/"},{"id":95,"title":"Threat Intelligence","content":"Access Threat IntelligenceTo access Threat Intelligence in the Secure UI:\nLog in to Secure.\nNavigate to Threat Intelligence.\nThe Threat Intelligence page appears.\nReview Threat Intelligence DetailsOn the Threat Intelligence page, you can see all the entries created by our threat research team.\nEach item includes a link to the source of the finding.\nThe right column lists the number of workloads, hosts, packages or threats impacted by this security item.\nSearch and FilterYou can search the Threat Intelligence feed with the free-text search bar.\nYou can filter the feed to find out which entries impact you.\nSelect Impacted Only to filter the feed. Entries are tagged Impacted when the threat is detected in your environment. Select the number of affected workloads or hosts in the right column to open a filtered Search. The search lists the affected resources. Select a resource to open the Resource Details panel and continue your investigation and remediation process. Click Reset to erase your current search and filtering.\n","url":"https://docs.sysdig.com/en/sysdig-secure/threat-intelligence/"},{"id":96,"title":"Tune Runtime Threat Detection Policies","content":"When auto-tune is enabled, exceptions are automatically added to Falco policy rules to remove noisy sets of events and leave lower-volume events for later analysis.\nAdditionally, event details (accessed either in Events feed or the Insights panels) may include Tunable Exception suggestions which can be ignored, applied, or edited and applied.\nThe tuner can be especially helpful when deploying Sysdig Secure runtime policies in a new environment. Your environment may include applications that legitimately perform actions such as running Docker clients in containers, changing namespaces, or writing below binary directories, but which trigger unwanted floods of related policy events in the default policies and rules provided by Sysdig.\nOnly users with the Admin user role are permitted to perform the actions in this section directly on the Tuner page.\nUse the Runtime Policy TunerThere are two ways to use the policy tuner:\nAuto-Tune: enable/disable Tunable Exceptions: Accessed in the Secure Events feed and Insights, these features do not require the auto-tuning feature to be enabled. Enable/Disable Auto TuningYou can enable and disable the tuner as needed to tame false positives and optimize the use of the Events feed. Auto tuning is enabled by default.\nLog in to Sysdig Secure as Admin and choose Policies \u0026gt; Runtime Policy Tuning.\nEnable or disable the feature with the Auto Tuning toggle.\nIt may take up to 24 hours for the initial Applied Tuning Exceptions to appear on the left panel.\nIn the background, the tuner will evaluate policy events as they are received by the Sysdig backend, find applicable exceptions values, and add them. The Applied Tuning Exceptions file is passed along to all Sysdig agents, along with the rules and policies.\nToggle the Tuning Engine off when you feel the feature has addressed the most commonly occurring or unnecessary policy events.\nTo start over from scratch, clear the Applied Tuning Exceptions text and re-enable the Tuning Engine toggle.\nTurning the auto tuner off does not disable the exceptions that were added by the auto tuner, nor any exceptions manually added from the tuner suggestions.\nEdit \u0026amp; Review ExceptionsEdit in Runtime Policy Tuning Page: After an exception is added by either the auto tuning feature or tunable exceptions, admins can directly edit or review the exceptions in the editor file in the Runtime Policy Tuning page. If you are happy with the changes you have made, click Save. Otherwise, select Discard Changes to undo your edits.\nReview in the Rules Library: View rules that have been tuned by selecting those that have \u0026ldquo;Published By: Tuner 0.0.0\u0026rdquo;\nUnderstand How the Tuning Engine WorksWhen Does the Tuner Add Exceptions?The Policy Tuning feature is conservative, only adding exceptions for commonly occurring events from a single rule with similar attributes.\nAll the conditions must be met:\nThe rule has generated at least 25 policy events in the past hour.\nA candidate set of exception values is applicable to at least 25% of the events in the past hour.\nThis ensures the tuning feature only adds exceptions for high-volume sets of events that can be easily addressed with a single set of exception values.\nExceptions Behind the ScenesTo understand the process of exception insertion by the tuner, consider a sample rule:\n- rule: Write below root desc: an attempt to write to any file directly below / or /root condition: root_dir and evt.dir = \u0026lt; and open_write exceptions: - name: proc_writer fields: [proc.name, fd.filename] And a stream of policy events with outputs such as:\nFile below / or /root opened for writing (user=root user_loginuid=-1 command=/usr/local/bin/my-app-server parent=java file=/state.txt program=my-app-server container_id=a97d44bbe437 image=my-registry/app-server:latest File below / or /root opened for writing (user=root user_loginuid=-1 command=/usr/local/bin/my-app-server parent=java file=/state.txt program=my-app-server container_id=a97d44bbe437 image=my-registry/app-server:latest File below / or /root opened for writing (user=root user_loginuid=-1 command=/usr/local/bin/my-app-server parent=java file=/state.txt program=my-app-server container_id=a97d44bbe437 image=my-registry/app-server:latest File below / or /root opened for writing (user=root user_loginuid=-1 command=/usr/local/bin/my-app-server parent=java file=/state.txt program=my-app-server container_id=a97d44bbe437 image=my-registry/app-server:latest Then the tuner would add the following exception values to address the false positives:\n- rule: Write below root exceptions: - name: proc_writer values: - [my-app-server, /state.txt] append: true For more background information on using exceptions, see the Falco proposal\nTuning Best PracticesAuto TuningLearning/Onboarding to Sysdig SecureThe auto-tuner is best used when you are onboarding to Sysdig Secure with environments that have a lot of tooling. These might be flagged as nefarious actions, despite being benign. A database backup tool, for example, can trigger certain rules that are monitoring for data exfiltration.\nIn many instances, exceptions are added out of the box and auto tuning is not needed.\nAlternative ActionsIn most cases, you may only get a handful of alerts from the same rule for the same workloads. See the best practices for tunable exceptions.\nUse Insights and review a grouped set of rules, using the Tunable Exceptions to add exceptions for your workloads or applications Use the Events feed and review an event within a grouped policy, using the Tunable Exceptions to add exceptions for your workloads or applications Review the auto-tuned exceptions after a learning/onboarding period\nAfter or during the auto-tuning period, you can review rules that have been modified in the Rules Library by viewing the rules that have \u0026ldquo;Published By: Tuner 0.0.0\u0026rdquo; How long should I leave auto-tuning on to learn about my environment?\nIn many cases, a week should suffice, as most workloads would have likely taken any actions that were required\nTunable ExceptionsThe tunable exceptions feature is available in the Secure Events feed and Insights. When you select tunable exceptions a modal will open.\nShould I apply all suggestions?\nNo, in most cases the first suggestion will create an exception that will encompass all of the other suggestions. If the number of events shown on the top right of each suggestion are the same, it\u0026rsquo;s likely that you are just duplicating exceptions. This is because the top suggestion targets a combination of the most events with the most targeted set of fields and values.\nTake, for example, the following suggestions for the rule Read sensitive file trusted after startup.\nThe first suggestion successfully stops alerting for all fifteen events by specifying an exception, known_sensitive_reader with a specified process, httpd, when reading a specific type of password file, /etc/shadow.\nThe second suggestion targets the same 15 events, but specifies only the process httpd. If implemented, this would prevent Read sensitive file trusted after startup rule from triggering for any httpd process, including if the process opened other sensitive files such as /etc/password.\n","url":"https://docs.sysdig.com/en/sysdig-secure/runtime_policy_tuning/"},{"id":97,"title":"Install Shield on Windows Nodes","content":"In addition to providing instructions for freshly installing the shield chart, this topic also guides you through migrating from previously installed Sysdig components deployed with the sysdig-deploy chart to the Host Shield and Cluster Shield components.\nPrerequisites Kubectl installed Helm version 3.10 and later Your agent access key Sysdig Secure Endpoint for your Sysdig SaaS region Windows Server 2019 and above Administrator permissions to perform the operations System Requirements A supported distribution or Kubernetes platform. Port 443 and 6443 open for outbound traffic. Coverage Map Platform Threat Detection and Response Vulnerability Management Posture Management EKS ✅ ✅ (Hosts Only) ❌ AKS ✅ ✅ (Hosts Only) ❌ GKE ✅ ✅ (Hosts Only) ❌ Openshift (OCP4) ✅ ✅ (Hosts Only) ❌ Migrate to the Shield ChartSysdig introduces a new chart, shield, to install Host Shield components. If you have previously installed Sysdig components in your cluster or are considering a fresh installation, use the shield chart instead of sysdig-deploy.\nSince the Host Shield replace all the components previously deployed using the sysdig-deploy chart, uninstall any existing installations before proceeding. This will prevent encountering duplicate entity errors.\nBefore uninstalling, make sure to take a backup of your Sysdig deployment to preserve configurations and data.\nhelm get values {RELEASE_NAME} -n {NAMESPACE} \u0026gt; sysdig-agent-backup.yaml To remove an existing installation, run the following command:\nhelm uninstall sysdig-agent --namespace sysdig-agent If you are doing a fresh installation, you can ignore this requirement.\nInstall Using HelmConfiguration FileTo install Host Shield and Cluster Shield, you can use the following values.yaml file:\ncluster_config: name: \u0026lt;your-cluster-name\u0026gt; # The name of the cluster sysdig_endpoint: region: \u0026lt;your-sysdig-region\u0026gt; # Sysdig Secure instance location region. Defaults to `custom` if not specified. access_key: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx # Access key for Sysdig Secure instance features: kubernetes_metadata: enabled: true # Enable Kubernetes metadata collection for the cluster posture: host_posture: enabled: true # Enable host posture assessment cluster_posture: enabled: true # Enable cluster posture assessment vulnerability_management: host_vulnerability_management: enabled: true # Enable host vulnerability management container_vulnerability_management: enabled: true # Enable container vulnerability management in_use: enabled: true # Enable retrieval of in-use packages detections: drift_control: enabled: true # Enable Drift Detection malware_control: enabled: true # Enable malware control detection ml_policies: enabled: true # Enable machine learning policies kubernetes_audit: enabled: true # Enable Kubernetes audit logging investigations: activity_audit: enabled: true # Enable activity audit live_logs: enabled: true # Enable Kubernetes live logs captures: enabled: true # Enable System captures host: driver: universal_ebpf # Driver for the host agent (Accepted Values: kmod, legacy_ebpf, universal_ebpf (Linux Kernel ≥ 5. 8)) host_windows: # Windows Host settings enabled: true #Enable Windows Host Shield deployment custom Region ConfigurationIf you are using a Sysdig Secure instance in a custom region, use the following configuration:\ncluster_config: name: \u0026lt;your-cluster-name\u0026gt; # The name of the cluster sysdig_endpoint: region: \u0026lt;your-sysdig-region\u0026gt; # Sysdig Secure instance location region. Defaults to `custom` if not specified. access_key: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx # Access key for Sysdig Secure instance # When the region is `custom`, the following configuration is required. api_url: \u0026lt;your-api-url\u0026gt; # Sysdig Secure API URL. For example, https://secure.sysdig.com/api collector: host: \u0026lt;your-collector-hostname\u0026gt; # Sysdig Secure collector hostname. port: \u0026lt;your-collector-port\u0026gt; # Sysdig Secure collector port. Installationhelm repo add sysdig https://charts.sysdig.com helm repo update helm upgrade --install --atomic --create-namespace \\ -n sysdig \\ -f values.yaml \\ shield \\ sysdig/shield The \u0026ndash;atomic flag should be replaced with \u0026ndash;rollback-on-failure when Helm 4 is used.\nParameters: http_proxy: Specifies the URL for the HTTP proxy server. https_proxy: Specifies the URL for the HTTPS proxy server. no_proxy: A comma-separated list of hosts or domains to bypass the proxy. For example: localhost,127.0.0.1,. my-cluster.local Feature ManagementFeature management in Sysdig Host and Cluster Shield is handled through a values.yaml configuration file, where you can enable or disable specific features like posture, vulnerability management and detection capabilities. Each feature has associated options, allowing customization to fit your environment’s security and compliance needs.\nFor example, you can enable host scanning with the following snippet:\nfeatures: vulnerability_management: host_vulnerability_management: enabled: true This setup activates host vulnerability scanning, allowing you to identify and address potential security risks on your cluster’s nodes.\nAdditional FeaturesTo enable the additional features, edit the values.yaml file to use the following configuration:\nPosture Managementfeatures: posture: host_posture: enabled: true Proxy SettingsIf your environment requires internet access through a proxy server, you can configure proxy settings in the values.yaml file. These settings ensure that Sysdig Host and Cluster Shield can communicate with Sysdig.\nAdd the following configuration under the proxy section:\nproxy: http_proxy: http://customer-proxy https_proxy: http://customer-proxy no_proxy: \u0026lt;comma-separated-list-of-hosts-or-domains\u0026gt; Advanced SettingsYou can use the additional_settings section to configure advanced debugging options, such as log levels. It is recommended to use these settings with caution and contact Sysdig Support for guidance.\nFor the detailed information on configuring the shield chart, see shield.\nScan Directory ConfigurationThe dirs_to_scan sets the list of folders to be included in the scan.\nhost_windows: additional_settings: vulnerability_management: host_vulnerability_management: enabled: true # The maximum size of a file considered for VM analysis max_file_size_bytes: 104857600 # The maximum size for in-memory evaluation, larger files will be offloaded to disk max_in_memory_file_size_bytes: 26214400 # The maximum number of (image) layers being analyzed in parallel max_parallel_layers: 5 # host-scanning feature host: enabled: true # folders to be included in the analysis dirs_to_scan: - C:\\Users Setting Log LevelThe log_level sets the minimum log level for messages displayed in the console.\nhost_windows: additional_settings: log_level: warn # or debug, info, warn, err ","url":"https://docs.sysdig.com/en/sysdig-secure/windows-on-kubernetes/"},{"id":98,"title":"Agent Release Notes 2021","content":"12.1.1 November 22, 2021Defect FixesFalco Action Works as ExpectedThe kill container Falco action works as expected for containerd in Azure.\n12.1.0 November 08, 2021Feature EnhancementsAbility to Build eBPF Probes for Debian 11 KernelsThe agent container has been enhanced to build probes for Debian 11 kernels.\nPrebuilt Probes for Debian 11 KernelsPrebuilt probes are added for Debian 11 kernels.\nPrebuilt Probes for Fedora KernelsPrebuilt probes are added for latest Fedora kernels.\nAbility to Build eBPF Probes for Linux Kernel v5.10The agent container can now build eBPF probes for Linux kernel version 5.10.\nEnhanced Agent Containers for Probes on New Kernels with glibc v2.33The agent container has been enhanced to build probes for new kernel versions that use glibc v2.33.\nFile Metrics in Audit TapMetrics related to file are included in audit tap.\nPromscrape Memory Usage LimitYou can now limit the promscrape memory usage. The default is set to 640 MB.\nRemove Self-Signed Certificate for Agent to Collector ConnectionSelf-signed certificate support has been removed for agent connection to the collector. See End of Support.\nDefect FixesImage Profile Shows Results CorrectlyThe imageid is reported correctly when using a CRI engine.\nDuplicate Environment Variable Hashes No Longer Appear in Audit TapThe discrepancy between reported environment variables and hash in audit tap has been fixed.\nKubernetes Daemonset and Replicaset Association Works as ExpectedFixed an issue that could invalidate the association between Kubernetes Daemonset and Replicaset.\nAgent Updates Prometheus Configurations CorrectlyFixed a problem that was causing Prometheus configurations to be merged incorrectly when certain integrations were updated from the backend.\n12.0.4 October 29, 2021Defect FixesSecure Policies Load as ExpectedFixed an issue present in 12.0.3 where Secure policies might not be loaded correctly by the agent.\n12.0.3 October 22, 2021Defect FixesLeases Fallback Works as Expected on OpenShift v3Fixed an issue where Kubernetes clusters that don\u0026rsquo;t support leases failed to report Kubernetes data due to not falling back to the previous behavior.\nUpdate the Cluster Install Scripts for Leases on OpenShiftModified the OpenShift agent installer to add the sysdig-agent cluster role and to assign it to the sysdig-agent service account. The new cluster role allows the agent to utilize the coldstart leases.\n12.0.2 September 30, 2021Defect FixesNetwork Security Communication Works As ExpectedIn some environments Sysdig agents could not send any Network Security (Kubernetes Network Policies) communications upon not completing CIDR auto-discovery. This issue has been fixed.\nAgent No Longer Crashes in Orchestrated EnvironmentsFixed a problem related to a race condition in orchestrated environments, such as OpenShift v3, due to which the agent might crash repeatedly at the agent start.\n12.0.1 September 27, 2021Defect FixesOpenShift 4 Clusters Able To Retrieve Metadata Without LeasesFixed an issue where OpenShift clusters would fail to report Kubernetes data when the agent service-account did not have the permission to create leases. With this fix, the Sysdig agent falls back to the previous behavior to retrieve the metadata.\n12.0.0 September 15, 2021Feature EnhancementsAllow Sysdig Backend to Manage Prometheus ConfigurationAllow Sysdig backend to manage Prometheus configuration. For more information, see the following:\nConfigure Monitoring Integrations\nMonitoring Integration\nPrometheus Monitoring with Sysdig\nAgent Console Supports Troubleshooting Prometheus ConfigurationThe Agent Console now supports troubleshooting Prometheus configuration.\nTo support this feature, Agent Console is enabled by default. This helps both users and Sysdig support to troubleshoot Sysdig agent issues. Sensitive user configuration is obfuscated and not viewable.\nFor more information, see Using the Agent Console.\nSupport for Node LeasesSysdig agent supports using Kubernetes Lease to control how and when connections are made to the Kubernetes API Server.\nFor more information, see the following:\nUsing Node Leases\nTroubleshooting Node Leases\nSupport for Podman EnvironmentsSysdig agent is supported in Podman environments. For more information, see Prerequisites for Podman Environments.\nAdd Startup Delay to Agent to Kubernetes API Server ConnectionAdded a delay prior to the agent connecting to the Kubernetes API server. The delay time is set based on the number of nodes in the cluster to prevent overloading the API server. This is to support environments where node leases cannot be used.\nKnown IssuesNone\nDefect FixesStale Capture Files No Longer Exhaust Local File SystemPrevent incomplete and stale capture files from being left behind and thereby avoiding storage consumption for such files.\nHonor CPU QuotasMoved the main dragent process to the default cgroup so that CPU quotas can cover all the agent processes.\nContainers Are Detected as ExpectedFixed issue where containers are not detected if SystemdCgroup = true is not enabled in the containerd configuration.\nReport Correct Container MetadataFixed a problem that caused some container metadata such as the image repository and image tag to be reported incorrectly.\nUpgrading from 10.8.0 to 11.3.0 No Longer FailsProvide a http_proxy configuration option to address connection problems post-OpenSSL upgrade from v11.0 to v11.1.\n11.4.1 August 03, 2021This is a hotfix release.\nDefect FixesFixed a problem that broke app checks in agent-slim by adding the missing dependencies.\n11.4.0 July 28, 2021Feature EnhancementsProbe BuilderThe probe builder can now be used to build kernel modules for the Sysdig agent. It can run on any host with Docker installed, including (with some preparation) airgapped hosts.\nProbe Builder is now enabled and available at https://github.com/draios/probe-builder. See the Readme for more information.\nPromscrape v2Promscrape v2 (used when prom_service_discovery is enabled for Prometheus) has been changed to discover only Kubernetes pods running on the same node as the agent. This should help reduce the load on the Kubernetes API servers in large clusters.\nAdded Missing Fields for Unified Workload MetricsAdded Kubernetes metric fields indicating the availability of daemon sets (status.numberAvailable, status.numberUnavailable, and status.updatedNumberScheduled) and replica sets (status.availableReplicas) to support workload-level metrics (SaaS only).\nKnown IssuesApp checks in agent-slim don\u0026rsquo;t work due to missing dependencies. This problem will be addressed in an upcoming hotfix release.\nDefect FixesMultiple Hosts No Longer Report the Same PodFixed an issue causing multiple hosts to report the same pod if its UUID is the same on both hosts.\nDuplicate StasD Metrics Are Reported CorrectlyFixed an issue related to handling duplicate StatsD metrics corresponding to a container that is reported by a host.\nStale Markers Are Sent properly for Dropped TargetsProperly generate stale markers for Prometheus metrics when a scrape target is no longer available and when using promscrape.v1.\nReport a Positive Time Delta ValueFixed a defect that could result in an invalid file.time.in, file.time.out, file.time.other, and file.time.total values.\nAgent No Longer Crashes When App Check or Prometheus Is EnabledFixed a defect that could cause crashing the agent when app checks or Prometheus is enabled.\nSecure Captures No Longer Causes Host ShutdownPrevent agent restarts caused by apparent stalls encountered in the sample handler thread.\n11.3.0 June 10, 2021Feature EnhancementsConsole LoggingIntroduced per-component-level console logging feature. See Manage Console Logging for Agent Components.\nSlim Agent for eBPF Probesagent-kmodule and agent-kmodule-thin can now be used to build eBPF probes.\nReplication Controller FieldsAdded missing replication controller fields to the aggregator Actions.\nNon-Delegated Agents Retrieve Less Data From the API ServerUse Kubernetes leases to better control the load on the Kubernetes API Server. This is disabled by default.\nDefect FixesAgent No Longer Generates Core Dumps on JavaPrevents java process core dumps caused by the Sysdig agent while trying to access /tmp directory.\nSupport Container Action on ContainerdContainer actions are now properly supported on containerd (CRI-O and other CRI engines that already had support). Actions for unsupported container engines are now properly reported to the Sysdig backend and a warning message is logged in the agent logs.\nRecovery During Agent ShutdownIntroduced a detection and recovery mechanism for hangs during agent shutdown.\nPromscrape V2 Termination No Longer Causes Agent CrashFixed a problem causing the agent to crash after promscrape_v2 is terminated.\nAgent No Longer Restarts in Kubernetes EnvironmentThe agent tries to fetch the metadata of the AWS instance in which it is running in order to tag metrics generated with the information unique to the AWS instance. If the metadata structure is not as expected, the agent continuously restarts due to an error in fetching such metadata. This issue has been fixed.\nProfiling Works as ExpectedFixed an issue that disabled support for performance profiles in the agent.\n11.2.1 May 06, 2021This is a hotfix release.\nDefect FixesReport Container User InformationStart tracking container user information and make that information accessible in container events. These events denote having a container started. This feature works for Docker as well as CRI-O container engines.\nReporting container user information does not work in OpenShift 4.x because it does not provide necessary CRI-O information.\n11.2.0 April 26, 2021Feature EnhancementsAgent CLISysdig supports Agent CLI, a command-line interactive tool, to troubleshoot agents. This tool helps Sysdig support to solve user issues quickly and efficiently. It is currently disabled by default and requires the customer to turn it on.\nFor more information, see Using the Agent Console\nScraping Prometheus MetricsScraping Prometheus metrics is supported in the following cases:\nAdvertised ports on container IP addresses\nAdvertised ports on host IP addresses\nAdvertised ports on pod IP addresses\nSlim Agent for IKSUse the following:\nFor OCP, use the new daemonset for OCP For IKS, the agent is installed by default using IKS Agent Script\nUse the -af option to install the full agent.\nReduce Load on Kubernetes API ServerTerminated pods are no longer collected in order to reduce the load on the Kubernetes API server.\nAudit Server Listens on All InterfacesThe audit server now by default listens on all the interfaces for Kubernetes audit events. This makes integration with Kubernetes audit events in the agent easier without the need for configuration changes.\nImproved Noise-Reduction Filter for Activity AuditsThe noise-reduction filter for Activity Audit has been improved. All the filtered data is duplicated.\nDefect FixesCRI-O Versions Report Correct Image IDThe new CRI-O versions (1.19+, possibly 1.18) now properly report container.image.id.\nLog Level Changes for Duplicate Host Container GroupsDemoted logs about duplicate host container_groups from warning to debug level\nFix CVE-2021-28831Fix CVE-2021-28831 in the Slim Agent container.\n11.1.3 April 13, 2021This is a hotfix release.\nDefect FixesPrevent Agent CrashLoopBackoff Error Caused by Smaller initialDelaySeconds ValuesThe readiness probe improvement in version 11.1.2 delayed the transition of the agent pod to a ready state until communication with the Kubernetes API server was established. But this delay could cause a CrashLoopBackoff due to liveness or readiness probes configured with an initialDelaySeconds set to less than 90.\nIn Agent version 11.1.3 the transition to the ready state does not wait for communication with the Kubernetes API server to be established unless the behavior is enabled via a new configuration option: k8s_wait_before_ready.\n11.1.2 March 30, 2021Known IssuesPrevent Agent CrashLoopBackoff Error Caused by Smaller initialDelaySeconds ValuesThe readiness probe improvement in version 11.1.2 delayed the transition of the agent pod to a ready state until communication with the Kubernetes API server was established. But this delay could cause a CrashLoopBackoff due to liveness or readiness probes configured with an initialDelaySeconds set to less than 90.\nWorkaround\nIf you are using agent version 11.1.2, set initialDelaySeconds for both liveness and readiness probes to a value that is greater than or equal to 90.\nFeature EnhancementsEnhanced Connection with Kubernetes API ServerKubernetes reconnect logic has been improved to automatically backoff (1 min, 2 min, 4 min\u0026hellip; 1hr) if the connection is continuously dropped when using Thin Cointerface. This reduces the load that the agent imposes on the Kubernetes API Server in clusters with heavily burdened API servers.\nReduced Load on Kubernetes API ServerThe agent\u0026rsquo;s readiness probe has been improved to not report ready until after the agent connects to the Kubernetes API server. This reduces the load that the agent imposes on the Kubernetes API server when starting up during RollingUpdate.\n11.1.1 March 26, 2021Defect FixesAgent Reports Memory Usage Accurately for ContainersFixed an issue where the agent would incorrectly report memory.bytes.used for containers that use more than 4GB.\nRuntime Policies Work as ExpectedThe runtime policies that have a policy type and capture action are handled as expected.\n11.1.0 March 23, 2021Defect FixesAgent Tags in Policy ScopesAgent tags are supported in runtime policy scopes.\nMetric Limits Are Updated As ExpectedFixed a problem where metric limits were not updated from the defaults. This is unlikely to happen if agents are connected to the SaaS backend.\nConfigured Tags in Prometheus ScraperFixed a problem in the old Prometheus scraper (used when promscrape is disabled) to ensure that configured tags are properly added to the metrics.\nJMX Metrics for Short-Lived Java ProcessesFixed an issue where short-lived Java processes could cause the Sysdig Agent to stop collecting JMX metrics.\nMisconfiguration No Longer Leads to Agent Constantly Querying Kubernetes API ServerFixed a problem where the agent would continuously send requests to the Kubernetes API server to query the endpoints API. This occurs when the agent\u0026rsquo;s clusterrole is incorrectly configured. With this fix, the agent will no longer repeat the attempt if it is unable to connect to the Kubernetes API during boot.\nScope Runtime PoliciesThe runtime policies are now correctly scoped by kubernetes.cluster.name. The fix in 10.6.0 was incomplete.\nAgent Correctly Reports ReplicasetsFixed an issue where the agent could lose track of a replicaset and report incomplete metadata.\nAgent Issues Over HTTP Proxy Fixed an agent connection issue over plaintext HTTP proxy with encryption.\nFixed an agent connection issue via HTTP proxy connections over SSL.\n11.0.0 February 18, 2021Feature EnhancementsThin Cointerface to Reduce Memory UsageThin cointerface reduces the memory required to handle the Kubernetes metadata on both the agent and the Kubernetes API Server. The reduction in memory usage is significant for Kubernetes clusters with a large number of pods (in the range of 10,000 or more) or clusters that heavily use Replication Controllers.\nUsing this feature returns the same data to the Sysdig backend and does not affect any Sysdig features. The thin cointerface feature is disabled by default.\nTo enable:\nAdd the following in either the sysdig-agent\u0026rsquo;s configmap or via the dragent.yaml file:\nthin_cointerface_enabled: true Restart the agent.\nReduce the Volume of Agent Log MessagesSome high-frequency information level log messages are converted to debug level to reduce the volume of messages generated at the default information level.\nFile Logging CapabilityPer-component file logging capability for an additional set of agent components has been enabled.\nFor more information, see Manage File Logging for Agent Components.\nReduce Agent Memory Consumed by PrometheusThe number of Prometheus time series ingested has been limited to reduce agent memory consumption. This limit is applied after Prometheus relabeling rules are applied but before the agent\u0026rsquo;s metric filter and metric limit.\nDefect FixesMissing Metrics Due to Aggregation in Agent FixedFixed an issue where processes with certain names were improperly aggregated, which in turn caused missing metrics in certain situations.\nCointerface FixFixed an issue that caused the agent\u0026rsquo;s cointerface process to restart continuously while processing kubernetes label selectors.\n10.9.1 January 21, 2021Defect FixesThin Cointerface Works as ExpectedFixed a defect in the Thin Cointerface feature which could cause Kubernetes metadata to stop updating. Because Thin Cointerface is turned off by default, the change affects only a small number of users who have this feature turned on.\n10.9.0 January 13, 2021Feature ImprovementsSupport for Kubernetes CronjobsKubernetes cronJobs are supported when reporting network communications.\nDefect FixesRuntime Policies and Rules Are Loaded with No ErrorsFixed a race condition that could prevent runtime policies and rules from being loaded properly if multiple messages from the Sysdig backend are received consecutively.\nCluster Overview Displays Compliance ScoreFixed an issue where Statsd metrics related to compliance would have no associated Kubernetes metadata and were not visible on Cluster Overview.\n","url":"https://docs.sysdig.com/en/release-notes/linux-agent-release-notes/2021-archive/"},{"id":99,"title":"Secure SaaS Release Notes 2022","content":"December 21, 2022Additional Feeds for Golang Added to Vulnerability ManagementSysdig has added feeds to detect a wider range of Golang-related vulnerabilities. By extracting the packages declared in Golang binaries, we are surfacing vulnerabilities in the libraries used to build those binaries. In particular:\nGitLab advisory database Go Vulnerability database This feature, once added, may detect new vulnerabilities in assets that were previously analyzed.\nDecember 20, 2022Vulnerability Host Scanning for Google COS AddedGoogle Container-Optimized OS (COS) support has been added to Host Scanning (preview feature).\nHost Scanning is installed by default when deploying with the Helm chart sysdig-deploy version 1.5.0+.\nNote that Google COS support requires HostScanner container version 0.3.1+. The new directories added to the default set scanned include:\nGeneric binaries (such as docker/containerd and infra tooling):\n/bin,/sbin,/usr/bin,/usr/sbin,/usr/share,/usr/local\nLibraries (such as default python libs):\n/usr/lib,/usr/lib64\nGoogleCOS tooling directories:\n/var/lib/google,/var/lib/toolbox,/var/lib/cloud\nDecember 15, 2022Sysdig Agent Health Dashboards EnhancedWe are happy to announce that the Sysdig Agents page under Data Sources has been updated to enhance visibility into the health of Sysdig Agents. Now you can:\nFilter Agents by their health status, version, and environment, including Account ID, cluster, and node. View your Total Connected Agent Count over time December 13, 2022Platform Audit UIWe are happy to announce that the Sysdig Platform Audit now has a UI within the Sysdig application, in addition to the existing API.\nWith the UI you can:\nFilter audit data based on multiple criteria for easier searching Filter within a specific date range View full details of a given audit event December 1, 2022Vulnerability Management for Hosts (Preview)Sysdig is deploying all-new host scanning capabilities for vulnerability management. The hosts that support your workloads and containers are a critical part of your infrastructure security. They can offer an even more attractive target for attackers than containerized software, due to the lateral movement possibilities they offer.\nSysdig\u0026rsquo;s host scanning and integrated vulnerability management features unify runtime workloads and their associated hosts under a single streamlined interface and user flow. The provide visibility over the full infrastructure security posture.\nHost Scanning is installed by default when deploying with the Helm chart sysdig-deploy version 1.5.0+.\nSee Host Scanning for more about the supported Host OSes, CPU architectures, alternative installation methods, and how to use the feature.\nNovember 30, 2022JIRA Ticketing IntegrationSysdig is pleased to announce the release of the JIRA Ticketing feature. Users can now open JIRA tickets within the Secure UI and assign them to team members directly. The first iteration will allow customers to open tickets from Identity Recommendations on the Home page.\nSee how to set up this JIRA Ticketing Integration.\nVulnerability Management Accept Risk (Exceptions)Sysdig\u0026rsquo;s Vulnerability Management policies already allow a user to configure thresholds to surface the most relevant data, for example, critical vulnerabilities with an available fix. Still, complex organizations also require the ability to introduce exceptions in the case of false positives, preconditions that don\u0026rsquo;t apply, and so on.\nAccepting the Risk is now available as a Vulnerability Management feature in Sysdig Secure.\nYou can accept the risk of individual CVEs or entire hosts or container images, and can define specific contexts such as package types and expirations dates. The Sysdig UI highlights the risks that have been accepted and can filter for them.\nThis feature requires that you have deployed Sysdig with sysdig-deploy Helm chart version v1.5.0+, vuln-runtime-scanner version 1.4.0+ and sysdig-cli scanner v1.3.0+.\nSee Enablement Prerequisities to check your versions and upgrade if needed.\nNovember 21, 2022CSPM Compliance: Reporting \u0026amp; API Preview ReleasedSysdig is pleased to announce the preview release of CSPM Compliance Reporting and API.\nThis feature allows you to:\nDownload CSV directly from the compliance results view Download CSV directly from the results view of a specific control Receive JSON of compliance results directly via API for: Compliance Overview Compliance Results Control Resource Lists For further reading, see Create and Download a Report and the CSPM API Documentation for developers\nLink Policies to Your Organization\u0026rsquo;s RunbooksSysdig Threat Detection policies now include the option to specify a Runbook link with each policy. If the policy triggers an event, the Runbook link will be displayed in the event details, as well as in the notification. This allows users to tie their security triage processes directly into Sysdig Secure.\nSee Manage Policies: Define the Basic Parameters and Secure Events: Detail Panel.\nNovember 7, 2022Usability Improvements for Secure EventsLink Events to Network Activity, Tuner, View RuleTo help security investigators distinguish false positives from real issues, it can be helpful to review the associated network activity. We are adding a link to Sysdig\u0026rsquo;s Network Typology visualization directly into relevant event details, under the Respond button.\nSimilarly, where applicable, the Runtime Policy Tuning feature will show up under the Respond button. The user can go through the flow to add exceptions and reduce false positives.\nFinally, we\u0026rsquo;ve added the ability to view the rule definition from the event details panel. You can see the event details and the rule definition side-by-side.\nSee Secure Events for details.\nRule Names Added to Event NotificationsThe notifications for runtime events have been enhanced to include a rule name. For Email, Slack, and Microsoft Team, the rule name will be a link to the rule definition.\nOctober 26, 2022New Secure Event Forwarder Integration: Google Security Command CenterA new integration has been released for Sysdig Secure\u0026rsquo;s Event Forwarder functionality: Google Security Command Center (SCC)\nOctober 24, 2022New Home PageUpdated the Home page for all customers. The new Home page offers a clean, visually intuitive representation of the most important issues in your environment and a curated list of the top tasks required. The top half encompasses the Dashboards and includes:\nVisual charts highlighting areas of concern within your environments that can be filtered The ability to drill down into relevant product areas with a click Full screen Dashboard capabilities The bottom half encompasses the To Do Recommendations list and will:\nGuide you to take the most impactful actions to reduce security risks in your environments Offer tailored recommendations with aggregated and prioritized tasks The Getting Started page is being deprecated with this release; see Home and Data Sources for more detail.\nSeptember 20, 2022Disable a Rule within a PolicyStarting today, you can disable (and re-enable) individual rules within threat detection policies. This allows you to:\nUse a subset of rules within a managed policy or managed ruleset without giving up the ability to receive new rule updates. Temporarily disable a noisy rule until the cause is investigated or an appropriate exception is put in place. September 19, 2022Actionable Compliance - Control Library Preview ReleasedSysdig is pleased to announce the preview release of CSPM Control Library in Actionable Compliance.\nThis is a technical preview release and the feature is open for all customers. It offers:\nVisibility of all available controls The ability to filter for specific controls by control attributes August 29, 2022Actionable Compliance - Custom Policies Preview ReleasedSysdig is pleased to announce the preview release of CSPM Custom Policies in Actionable Compliance.\nThis is a technical preview release and the feature is open for all customers.\nWith this feature you can:\nClone an existing policy and edit its metadata Create, edit and delete a custom policy Create, edit and delete requirements in a custom policy Link and unlink available controls to policy requirements Coming soon in Actionable Compliance:\nControl Library Creating your own custom control in a custom policy August 17, 2022New Permission for Changing Team RolesTeam management has been improved with the addition of the new permission, Team Membership Roles. This permission will allow you to change the roles of team members separately while adding users to the teams.\nFor more information, see:\nCustom Roles and Privileges Add and Configure Team Members August 10, 2022Machine Learning PoliciesA new machine-learning-based detection capability is available in Sysdig Secure.\nWhile we strongly believe in our Falco-based rule approach, and do not consider machine learning to be the best way to detect every threat, we understand that specific use cases such as Cryptominer detections require a different approach. This is the first detection capability available in our Machine Learning policies.\nTo read more about how to configure them and how they work, see Machine Learning and our press release.\nAugust 4, 2022Agent Overview Page Released in Data Sources (Preview)An Agents overview page in the Data Sources | Integrations interface has been made available as a technical preview for all customers. This new page shows all of the Sysdig Agents that have reported to the Sysdig backend, and enables you to quickly determine:\nWhich agents are up-to-date, out of date, or approaching being out of date Which managed clusters have been detected in your cloud environment, but have not yet been instrumented with the Sysdig agent The feature will remain in technical preview, as we add additional functionality and refine the workflows within the page.\nSee also: Data Sources | Sysdig Agents\nActionable Compliance - CSPM Policies Preview ReleasedSysdig is pleased to announce the preview release of CSPM Policies in Actionable Compliance. This is a technical preview release, and the feature is open for all customers.\nWith this feature you can:\nSee what is being evaluated by the Actionable Compliance feature in the context of compliance standards (CIS, NIST, and so on) Review the policy structure and the controls connected to it Enable/disable controls Filter controls by enablement status, violation severity, name, and control type The features are under development and will soon include the ability to create custom CSPM policies as well.\nRead more in CSPM Policies (Preview).\nJuly 28, 2022Managed Threat Detection PoliciesFrom today, you will see all existing policies labeled as Custom Policies and with a list of disabled Managed Policies. The existing custom policies work exactly as they have always worked, and do not require any action from you. However, to take advantage of the Sysdig Threat Research team, we recommending moving over to the new managed policies. To read more about the different types of managed policies, see Threat Detection Policies.\nJuly 21, 2022Actionable Compliance - Accept Risk Preview ReleasedSysdig is pleased to announce the preview release of Risk Acceptance in Actionable Compliance. This is a technical preview release, and the feature is open for all customers.\nThis feature allows you to:\nImprove compliance score by Accepting a risk on a failing resource in a control Register an acceptance reason and expiration date Edit and revoke acceptance See a summary of accepted risks in Compliance Filter by accepted resources in the mini-inventory of violation results You can read more about the feature in Compliance.\nJune 23, 2022New Secure Event Forwarder Integrations: Elasticsearch \u0026amp; Microsoft SentinelTwo new integrations have been released for Sysdig Secure\u0026rsquo;s Event Forwarder functionality:\nElasticsearch Microsoft Sentinel June 2, 2022Actionable Compliance Preview ReleasedReleased the first preview of Actionable Compliance, the next phase of the Sysdig Secure\u0026rsquo;s compliance offering and the first capability to support Kubernetes Security Posture Management (KSPM), and in the future also Cloud Security Posture Management (CSPM).\nThis is a technical preview release, and the feature is open for all customers.This feature includes:\nCompliance views - a redesigned summary view for each built-in policy Violation results - the first-ever mini-inventory to show violated resources with filtering capabilities Actionable Remediation - automatically open a Pull Request to remediate a resource violation in its git stored source file (Infrastructure as Code) Technical highlights:\nInventory based collection - a paradigm shift in how we collect CSPM data. New agent collector - gathers all Kubernetes objects (workloads, subjects, roles, and so on) from the customer for future Inventory use New node-analyzer container - collects the node’s Kubernetes, Linux and docker configurations Eight new micro-services OPA based policies - built-in policies (previously benchmarks) with OPA controls (previously rules) for Kubernetes, docker \u0026amp; Linux You can read more about the feature in Compliance\nMay 23, 2022Custom RolesA custom role is an admin-defined role that allows Sysdig administrators to bundle a set of permissions and assign those permissions to individual users or teams. Custom roles allow for finer-grained definition beyond the standard out-of-the-box Sysdig Roles. Once defined, a custom role can be assigned to any user inside a particular team, and configured as the default role for new users in that team. For more information, see Custom Roles.\nThe addition of custom roles into the platform is transparent, meaning that standard roles and assignments that already exist will not experience any changes.\nMay 19, 2022Menu Option to Display New and/or Old Scanning InterfacesTo facilitate a smooth transition from the Legacy Scanning Engine to the new Sysdig Secure Vulnerability Management, the Settings menu now provides options for displaying the UI for the new, legacy, or both scanning engines.\nSafe and transparent: This is a non-intrusive change; regardless of how you have the New Vulnerabilities engine toggle set, the Sysdig Secure navigation menu will not be modified without explicit user intervention. And the toggles will alter only the user interface and not impact the function or running of the engine itself.\nTo enable/disable: See Which Scanning Engine to Use\nIf both are enabled: The two sets of features are clearly distinguished in the Navigation menu.\nMay 18, 2022Policy Advisor Deprecation NoticeSysdig Policy Advisor will be removed from all Sysdig accounts on June 17, 2022.\nPolicy Advisor was built during a time when PodSecurityPolicies (PSPs) were the only way to add Security Policies to a Kubernetes workload. PSPs have now been deprecated in Kubernetes 1.21, released more than a year ago.\nMay 17, 2022Runtime Scanner 1.0.3 ReleasedOptimized requests performed on the Kubernetes API\nSee also: Vulnerabilities | Runtime\nMay 4, 2022Sysdig Platform AuditSysdig Platform now supports the capability of tracking, logging and reporting on all changes in the system.\nTrack all activities on the API level Retention period: 90 days Simple API for retrieving audit information (no UI) Events Forwarding support to be included in the near future (to be announced) Enabled by default for all SaaS customers See also: Sysdig Platform Audit\nSysdig Platform Login BannerSysdig Monitor and Secure now allow you to define a Login Message that will be presented to all users. Added to boost Sysdig compliance/enterprise readiness, requested originally by the IRS.\nUsers are not allowed to access the system until they acknowledge the message One login banner per customer Only Admin users can enable or update the message Single banner for both Monitor and Secure (for Platform customers) Available on SaaS for all customers See also: Configure Login Message\nMay 3, 2022Insights Feature GAThis release marks the general availability (GA) of the Secure Insights feature. Some of the changes introduced include:\nBetter support for Azure events Amazon Web Services (AWS) Identity Access Management (IAM) permission integration Fixed bugs in policy tuner flow Removed the limit for displaying events in a time range May 2, 2022DriftControl Policies: Detect and Prevent Drift in Container RuntimeSysdig agent can now detect when a new executable was added to a container after the container started up. The agent collects when a file was downloaded and made executable. When using prevention mode, the agent can also deny the process from ever running. A policy can be used to define binaries that should be denied or excluded from being denied if they have been added after the container has started.\nSee also: Drift Policy\nApril 28, 2022Component Security FixesThe following Sysdig Secure components were updated with the latest security patches (April 2022):\nquay.io/sysdig/secure-inline-scan version 2.4.10 (legacy scanner)\nquay.io/sysdig/host-analyzer version 0.1.7\nquay.io/sysdig/node-image-analyzer version 0.1.17\nApril 20, 2022New Vulnerability Management EngineSysdig is pleased to announce the new Vulnerability Management engine, a major upgrade to the vulnerability and image scanning functionality for the Sysdig Secure product.\nMajor Highlights Scanning times have been drastically reduced. The average scan is now eight times faster.\nAdditional data is provided for vulnerabilities and remediation\nCVSS scores and metrics: Network Attack Vector, Privileges required, etc. Flagging of publicly available code Exploits Suggested package fix version Risk spotlight: Focus on the vulnerabilities that Sysdig detects in active packages at runtime.\nThis is a new filter that only shows CVEs with active packages, to save time browsing infrastructure and to help you focus on high-impact CVEs New Vulnerability Reporting module\nUp to 14 days retention of individual reports Generate now allows scheduling directly from the UI Flexible policies that can be attached to the different runtime and security contexts\nHow to Move to the New Scanning EngineThe new vulnerability management engine uses a different data storage, API, host components, and user interfaces than the legacy scanning.\nContact your Sysdig representative. They will guide you through the process of migrating your subscription and vulnerability management configuration to the new engine. For further reading, see Vulnerability Management.\nMarch 8, 2022Scanning Component UpdatesThe following components have been upgraded to the listed versions with bug fixes and security updates:\nnode-image-analyzer:0.1.16 secure-inline-scan:2.4.9 host-analyzer:0.1.6 The latest Helm chart includes these versions for Node Image Analyzer and Host Analyzer. Follow the Quick Start documentation to upgrade the inline scanner.\nMarch 3, 2022New CIEM FeaturesUser Risk LabelsRisk Labels are now surfaced to highlight insecure attributes of specific Users and Roles. They are listed within the Users \u0026amp; Roles page and within the User Details tab of a specific user.\nTrend Charts in OverviewTime charts are now available within the Overview tab of Identity and Access. These help to visualize your permission trends over time for Users, Policies, and Resources.\nCSV Report ExportAll of the pages within Identity and Access can now be exported as a CSV file. Select the Download CSV button found at the top right corner of all pages.\nEffective Permission CalculationAWS supports different types of policies to limit permissions on different scopes. Sysdig has added support for calculating effective permissions based on permission boundaries and organization level service control policy (SCP). This gives additional context when viewing permissions based on identities. For example, an identity that has been given administrator level identity policy will be limited in overall permissions if there is a permission boundary policy attached to it.\nCIEM Data in InsightsWithin the Cloud Activity and User Activity views in Insights, there is now an Identity and Access tab. This will help investigative flows to understand the context from an IAM perspective.\nMarch 1, 2022New: Data Sources InstrumentationOn the Data Sources \u0026gt; Managed Kubernetes page: For unconnected clusters, Sysdig has added quick instrumentation instructions using the known details about the cluster, such as the cloud account, region, and cluster name.\nFebruary 28, 2022New: Data Sources FeaturesCluster StatusThe Data Sources page now tracks all Managed Kubernetes Clusters, and whether they are connected or not connected. This can help determine if Sysdig Agent is no longer reporting to the Sysdig backend, for example, if it did not have enough resources to install. Each node will also report on the agent version installed at that time.\nInstrumentation InstructionsSysdig now adds quick instrumentation instruction to a Managed Kubernetes Cluster using the known details about the cluster, such as the cloud account, region, and cluster name.\nFebruary 10, 2022Improved Usability with New NavigationSysdig\u0026rsquo;s new navigation improves the usability of the left-hand navigation for faster and easier navigation.\nFor a demonstration of the new feature, see the video walk-through.\nImproved Menu Handling Hoverable Sub-Menu: With each module that has additional menu options, hover over the respective module to quickly navigate.\nCollapsible Main Menu: Save space with the collapsible left-hand navigation.\nNew Menu Option: IntegrationsA dedicated Integrations menu option provides an easy way to access both inbound and outbound integrations.\nInbound Access the Cloud Accounts page to quickly understand which applications and services are running, and where the Sysdig agent is installed. Access Managed Kubernetes to get a catalog for all the managed Kubernetes clusters in your environment. The status connected/unconnected is based on whether the agent is installed or not. 3rd Party: Manage your Git Integrations Outbound: Manage your Event Forwarding, Notification Channels, and S3 Capture Storage\n3rd Party: Manage your Git Integrations\nRevamped User MenuNow all the settings options are collected and available in one large menu.\nFebruary 2, 2022Enhanced Unified Filter for Event FeedA new unified filtering experience of the Event Feed is now available for Secure SaaS accounts.\nEasily toggle from the original to the enhanced version, where you will find:\nUnified scopes, free text and any other filterable/searchable attributes on a single bar Autocomplete on keys and values Autocomplete/suggest operands One-click quick filtering directly from the list of displayed elements Saved filters in various formats\u0026ndash; no more retyping common filter expressions Favorite filters, stored per user and feature Default filters, per user and feature Recent filters, per user and feature See also: Secure Events\nJanuary 26, 2022Unified Compliance ReportingReleased a rework of our Compliance and Benchmarking capabilities. This change brings a number of improvements:\nCompliance and Benchmark tasks are now scheduled, managed, and generate reports in an updated and unified interface, with simpler pathways to remediation and easier-to-navigate reports. The logic used to check individual controls now checks for events signalling control failures, as well as ensuring the correct Runtime rules are configured to detect these events. This leads to a more comprehensive audit that captures activity as well as configuration. New compliance standards and platforms added: For workload, AWS, GCP, and Azure: NIST 800-82 Rev2 For workload and AWS: Fedramp (workload and AWS only) HITRUST CSF 9.4.2 (workload and AWS only) For GCP and Azure GDPR HIPAA ISO 27001:2003 NIST 800-53 Rev4 NIST 800-53 Rev5 NIST 800-171 NIST 800-190 PCI / DSS v3.2.1 SOC 2 Prerequisites Agent version 12.0.4 or higher\nIf necessary, install or upgrade your agent to the appropriate version.\nNode analyzer installed\nIf you are upgrading from an earlier version of Sysdig Secure, your existing compliance and benchmark records will be migrated to the new version and retained on the same schedule as before.\nSee also: Compliance\nNew Feature: Review Applied Kubernetes Network PoliciesSysdig Secure has added the ability to view the Kubernetes Network Policies (KNPs) that have been applied directly from the Network Security Policy UI.\nYou can:\nReview the relevant policies applied to the pod-to-pod communication for the current view\nClick View Policy to see the raw yaml output of the network policy applied to that workload.\nSee also: Netsec Policy Generation\nJanuary 2, 2022Welcome Infrastructure-as-CodeInfrastructure-as-Code (IaC) is an important part of today\u0026rsquo;s cloud-native infrastructure. We at Sysdig know that the earlier you identify possible posture issues, the better off you are.\nThe new feature allows you to integrate Kubernetes IaC checks into your Git pipeline. With just a few clicks, the standard compliance checks will be integrated into the Pull Request (PR) flow and alert developers to policy violations before they merge.\nSupportability \u0026amp; RequirementsThe new capability will use either an application or a webhook in your respective git provider.\nGitHub - GitHub Application GitLab - Webhook Azure DevOps - Webhook Bitbucket - Webhook For each provider you can define the repos and folders to protect, as well as branches on which to perform the evaluation.\nSee also: Git IaC Scanning\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/2022-archive/"},{"id":100,"title":"Monitor SaaS Release Notes 2023 Archive","content":"December 22, 2023Panel Search Is Generally AvailableDashboards have been enhanced with a Panel Search capability. It\u0026rsquo;s an effective and fast way to find metrics, labels, and text within a given Dashboard.\nGroup Outlier Alerts Is Generally AvailableGroup Outlier Alerts are now available as a new alert type in Sysdig Monitor, allowing users to identify entities that deviate significantly from the group\u0026rsquo;s normative behavior. Use Group Outlier Alerts to pinpoint web servers, containers, or databases exhibiting atypical behavior.\nEmbedded Images in Alert Notifications Supported in Slack, Email, and PagerDutyAlert Notifications for Threshold Alerts sent to Slack, Email, and Pagerduty include a snapshot of the time series that triggered the alert rule. This provides visual insight into the entities that trigger the alert rules, facilitating faster responses and reducing the need for context switching. This also applies to Threshold Alerts configured with Form or with PromQL.\nEnriched Kubernetes Troubleshooting with Labels and AnnotationsKubernetes Troubleshooting now displays your Kubernetes Metadata. View Labels and Annotations for each cluster, namespace, and workload in your Kubernetes environment by accessing the Overview tab in Troubleshooting. This additional context helps you to identify different parts of your infrastructure and understand their importance.\nOctober 12, 2023Enhanced Metrics UsageMetrics Usage now displays which Dashboards and Alerts are using a given metric, enabling you to better understand the value a given metric provides.\nSeptember 19, 2023Controlled Availability of Notification SnapshotMetric Alert notifications forwarded to Slack or Email now offer a snapshot of the triggering time series data.\nFor the Slack notification channels, you can toggle the snapshot within the notification channel settings. When the channel is configured to Notify when Resolved, a snapshot of the time series data that resolves the alert is also provided in the notification.\nThis feature is released as controlled availability.\nSeptember 6, 2023General Availability of Cost AdvisorCost Advisor is now generally available boasting significant improvements. This feature enables teams to optimize visibility and reduce their Kubernetes costs.\nPrivate BillingPrivate Billing, currently available for Amazon Web Services (AWS), reconciles costs with your specific AWS billing agreements. Usage of reserved and spot instances, as well as savings plans and other discounts, will be used to calculate costs. This integration will be useful for users who want accurate costs instead of relying on public on-demand pricing.\nYou can view storage, load balancer, and idle costs. This paints a fuller picture of your Kubernetes costs where workloads are leveraging persistent volumes and load balancers, and idle costs give platform teams insights into the cost of used cluster capacity—a great indicator as to whether a cluster can be reshaped or scaled down.\nCost ExplorerCost Explorer empowers you to explore costs in detail with granular segmentation. This helps you understand, for example, the cost of a workload that is running across multiple clusters.\nCost ReportsCost Reports streamlines cost reporting processes with the ability to set up period report generation that can be exported to third-party systems, Slack, and email notifications, which in turn helps create a culture of cost discipline.\nWorkload rightsizing has been improved to give you more control over the recommendations provided. Depending on whether a workload is production or HA (high availability) grade, in staging or development setup, you can choose between more conservative or aggressive recommendations when rightsizing a workload.\nQuerying ImprovementsPromQL Query When adding a label to a metric, the query builder takes the metric into account and prompts you with only relevant labels and label values. Previously, all the labels in the system were displayed.\nWhen writing a query, the query builder automatically selects all the labels used in the query and displays them in the table. This improves the user experience, allowing you to explore further based on the used label.\ncloud_provider_* metricsThe label autocomplete capability has been enhanced for cloud metrics to display only relevant labels for a given metric. For cloud metrics, such as cloud_provider_*, you no longer see a long list of labels for every metric, which in turn improves the accuracy of label autocomplete and makes the search faster.\nAugust 09, 2023Metrics UsageMetrics Usage has been updated with a detailed per-metric view offering two new capabilities:\nTime Series Churn Over Time Label Exploration Resolve Alert Occurrence ManuallySysdig supports manually resolving a single alerting segment, all alerting segments for an alert rule, or even resolving every single alert in your infrastructure with bulk actions. For more information, see Manual Alert Resolution.\nDeactivating Orphaned Alert Occurrences AutomaticallyIf you don\u0026rsquo;t want to resolve alerts manually, you can configure Sysdig Monitor to do it automatically. Sysdig can now automatically mark orphaned alert occurrences as deactivated. Orphaned alert occurrences are alerts triggered by entities that no longer report data. This can happen when cloud infrastructure is cycled, creating potentially outdated and obsolete alert occurrences. By leveraging this feature, you can ensure that alert occurrences are coming from entities that are actually reporting data into the system, instead of the database that was decommissioned months ago. See Orphaned Alerts.\nDeprecation Notice In the following weeks, the Legacy Explore module will be decommissioned from Sysdig Monitor. Sysdig recommends that you use Explore going forward.\nUsers wanting access to the Agent Console page, see Sysdig Agents.\nAugust 04, 2023Metrics Usage TS countMetrics Usage has been enhanced with a \u0026ldquo;Total in the last 20 minutes\u0026rdquo; Time Series (TS) count.\nAlert Resolution DelayAlert Resolution Delay is available for Prometheus Alerts. This feature helps prevent noisy alert resolutions by ensuring that an alert condition has been resolved for a custom time before marking the alert as resolved. For more information, see Alert Resolution Delay.\nMonitoring Integrations Added support for Istio 1.16. Added an option in Windows Installer to change the Prometheus agent port. Added time charts for CPU and Memory usage in Cluster Capacity Planning Dashboard. July 24, 2023Metrics UsageSysdig introduces Metrics Usage providing insights into your metrics cardinality and thus helping you understand which custom metrics are responsible for your time series usage and which are being scraped across your entire environment. See Metrics Usage for more information.\nOpenID Single Logout SupportSysdig added support for OpenID Single Logout. With Single Logout, a user can initiate a logout and terminate all sessions without having to log out from each one individually.\nFor more information, see Configure OpenID Single Logout.\nEnhanced Sysdig Platform AuditThe Sysdig Platform Audit has been enhanced to include username and team name in the audit information in addition to user ID and team ID. The feature is now Generally Available.\nFor more information, see Sysdig Platform Audit.\nSupport for Inspecting and Initiating CapturesThe Captures page has been improved by providing you with the ability to inspect captures as well as initiate captures. Earlier, you could initiate captures only in the old Explore.\nFor more information, see Captures.\nJune 16, 2023Unified Subscription PageThe Subscription page has been enhanced to provide a unified look and feel for both Sysdig Monitor and Sysdig Secure. This improvement is particularly useful to Sysdig Platform users as it now shows all the relevant subscription information, regardless of which product is currently selected. The feature is Generally Available.\nFor more information, see Subscription.\nJune 06, 2023Change AlertsSysdig introduces a new alert type, Change Alerts, to help you receive alerts when a metric dynamically changes over time. Change Alerts detect cases such as sudden spikes in network traffic or a sharp fall in the number of healthy nodes.\nChange Alerts have advantages over alerts based on static threshold in the following scenarios:\nDistributed infrastructure that has varying levels of traffic across different regions. In regions with significant activity, you may need to set different static thresholds for your alerts compared to the regions with lower levels of traffic. Change Alerts allow you to configure a more generic alert and to be notified when the database disk usage decreases 20% over the last 1 hour compared to the last 24 hours.\nStatic thresholds can be less useful when dealing with seasonal traffic patterns. In such cases, it is effective to focus on monitoring changes rather than relying on fixed thresholds.\nFor more information, see Change Alerts.\nGroup Mapping Settings APISysdig introduced a configuration API for Group Mapping. The API allows you to define how the Group Mapping will behave when the user has no groups or when conflicting groups exist. For example, in cases where several groups place the user in the same team with a different role. For more information, see the Group Mapping API.\nThe feature is Generally Available.\nEnhanced Agent Licenses Management APIThe Agent Licenses Management API has been enhanced with several features. The API allows you to define limits, reservations, team ownership, and metadata for each access key. For more information, see Manage Access Keys.\nThe feature is Generally Available.\nSilence by AlertSilence rules have been enhanced by introducing the ability to silence alert notifications by alerts in addition to alert silences by scope. For more information, see Silence Alert Notifications.\nService Limit for AlertsService limits are the usage thresholds to help ensure that your Sysdig Monitor environment stays healthy and performs optimally. Alerts that exceed service limits will result in alert deactivation. For the conditions and service limits, see Service Limits.\nMonitoring integrationsIntegrations Introduced the new Rancher Kubernetes Control Plane (API Server, cAdvisor, Controller Manager, Scheduler, CoreDNS) integrations. Added support for Redis Cluster option in the Redis integration. Enhanced the Windows Prometheus bundle. Added PromQL filters and troubleshooting metrics to Kubernetes Control Plane integrations. Modified the configuration for Prometheus integrations jobs that use pod discovery to scrape running pods. IBM Cloud Integrations IBM Cloud VMware shared IBM Cloud VPC VSI Dashboards and Alerts Added timecharts for CPU and Memory usage in Cluster Capacity Planning dashboard. Added alert for Sysdig Monitor entitlement. Added go_info metric to the Go integration. For more information, see Integration Library.\nApril 26, 2023Availability of Sysdig Agent Overview Page in Data SourcesThe Sysdig Agents page is now available in Sysdig Monitor. The page allows you to quickly determine which Agents are up to date, out of date, or soon to be out of date. For more information, see Sysdig Agents. The feature is Generally Available.\nApril 04, 2023Translate Metric Alerts to PromQLMetric alerts configured in form-based query can now be translated to PromQL, allowing you to choose between the convenience of Form and the flexibility of PromQL. Translation to PromQL allows you to define more complex and composite queries to create alerts that are not possible with Form. For more information, see Translate Metric Alerts to PromQL.\nMonitoring integrationsIntegrations k8s-cAdvisor Microsoft IIS Microsoft SQL Server Exporter KNative (integration with jobs only) Added the following: Zone label to the GCP integrations Security updates to the UBI image of exporters New ports and certificate path to the Etcd default job IBM Cloud IntegrationsThe IBM cloud Integrations add new easy-to-use dashboards, focused on relevant metrics, and support specific alerts for these integrations.\nIBM Cloud PostgreSQL IBM Cloud MongoDB Dashboards and Alerts Improved the CoreDNS integration dashboard and alerts with latency metrics. Deprecated the Linux Memory Usage dashboard. Moved the Linux Host Integration dashboard to the Host Infrastructure category. Improved the Memory Usage dashboard for Linux VMs. Removed the _AWS CloudWatch: DynamoDB Overview By Operation dashboard. For more information, see Integration Library.\nJanuary 30, 2023Cost AdvisorCost Advisor, the predictable cost analysis tool for Kubernetes is available in preview. Cost Advisor features include:\nVisibility into Kubernetes cost allocation by team and business unit. Exportable reports with detailed spending data to include in your chargeback model. Easy identification of areas in your Kubernetes environments that can be optimized. Recommendations to reduce wasted resources by an average of 40%. Cost advisor is currently supported only in AWS Environments.\nAdvisor EnhancementsAdvisor has been improved to provide you the ability to:\nNavigate from a pod to Metrics Explorer without losing context. Create a scoped alert directly from an Advisory. View pod YAML, which is similar to kubectl get pod \u0026lt;pod\u0026gt; -o yaml. (Pod YAML requires agent 12.9.0 or newer) Custom Webhook Notification ChannelYou can now create a Custom Webhook Notification Channel and fully customize the HTTP payload of an alert notification forwarded to a third party webhook-based integration. Using Sysdig Templating Language, you can dynamically interpolate alert metadata such as alert name and severity as well as event context such as infrastructure labels and timestamp. This allows users to integrate with integrations beyond those natively supported by Sysdig Monitor.\nMulti-Threshold AlertsYou can now configure optional warning threshold for metrics and events. For more information, see Multi-Threshold Alerts.\nAlert on No DataWhen a metric stops reporting, Sysdig Monitor shows no data where you would normally expect data points. To detect incidents that fail silently, you can configure alerts to notify you when a metric ceases to report data. For more information, see Create an Alert on No Data.\nDashboards \u0026amp; Explore enhancementsDashboards have been improved to provide you the ability to:\nFind dashboards that you have recently accessed via the navigation menu. Delete dashboards in bulk. Alternate between viewing one or all segments in Timecharts with contextual tooltips. Find, search and understand labels easily with the refreshed PromQL Query Explorer module. Monitoring integrationsIntegrationsFixed the following images with critical vulnerabilities:\npromcat-jmx-exporter postgresql-exporter Added the following integrations:\nLinux Host GCP Memorystore for Redis GCP Cloud SQL MySQL GCP Cloud SQL PostgreSQL GCP Cloud SQL SQLServer GCP Compute Engine Dashboards and AlertsThe following changes were made to Dashboards and Alerts:\nUpdated the VM dashboards with new panels in the Windows and Linux dashboards. Added “Exporter Down” alert to detect offline exporters before you notice missing metrics. Added additional Windows alerts using Windows default metrics and process collector metrics. Added new Cloud Provider labels to help scoping for Time Series (TS) consumption and AWS dashboards. Added new TS dashboard (Agents and Jobs Time Series) for tracking TS consumption from Monitor Integrations. Refreshed Red Hat OpenShift (RHOS) dashboards and alerts. ","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-monitor-release-notes/2023-archive/"},{"id":101,"title":"Serverless Agent Release Notes 2023","content":"4.3.1 Dec 05, 2023Defect FixesImproved Agent Logging Debugging information related to a process crashing from a fatal signal will now only be logged if the process indeed crashes due to the signal. Reduced the verbosity of repeated log messages from the Workload Agent. Silenced unnecessary error logs from the Orchestrator Agent. VulnerabilitiesFixed the following vulnerabilities for the Orchestrator Agent:\nCVE-2023-38545 CVE-2023-44487 CVE-2023-27536 CVE-2023-29491 CVE-2023-36054 CVE-2023-39975 CVE-2021-43618 CVE-2023-27533 CVE-2023-27534 CVE-2023-27538 CVE-2023-29499 CVE-2023-32611 CVE-2023-32665 CVE-2023-38546 CVE-2023-4016 CVE-2023-4641 Fixed the following vulnerabilities in the Serverless Patcher:\nCVE-2023-38545 CVE-2021-42694 CVE-2018-19211 CVE-2018-19217 CVE-2018-20657 CVE-2019-14250 CVE-2020-19185 CVE-2020-19186 CVE-2020-19187 CVE-2020-19188 CVE-2020-19189 CVE-2020-19190 CVE-2021-39537 4.3.0 Hotfix Nov 08, 2023This hotfix updated the CloudFormation template, orchestrator-agent.yaml, to include default values for autoscaling. When autoscaling is disabled, the autoscaling parameters now default to 0.\n4.3.0 Oct 27, 2023End of LifeThe stack serverless-instrumentation.yaml and the related container image quay.io/sysdig/serverless-instrumentation reached EOL and are no longer supported.\nNew FeaturesOrchestrator Agent Performance ImprovementsThe performance and stability of the Orchestrator agent have been improved and the Orchestrator is now capable of maintaining up to 3000 Workload agents.\nSupport for Auto ScalingTarget Tracking configuration is available in Orchestrator CloudFormation template and Terraform Provider for handling target scaling.\nProcess treeProcess lineage will be available for every event and is enabled by default starting from this version of the serverless agent. The process tree will be visible in the Events detail pane for events related to workloads that are triggered from that point on.\nDefect FixesWorkload Agent Stability ImprovementsFixed Workload Agent stability issues associated with given workloads.\nWorkload Agent Logging ImprovementsImprove readability and separation of information and error level logging.\nVulnerabilitiesFixed the following vulnerabilities with the Orchestrator agent:\nCVE-2023-39325 CVE-2023-44487 CVE-2023-3978 4.2.2 Oct 19, 2023Defect FixesVulnerabilitiesFixed the following vulnerabilities in the Orchestrator Agent:\nCVE-2023-38545 CVE-2023-4911 CVE-2023-2603 CVE-2023-4527 CVE-2023-4806 CVE-2023-4813 CVE-2023-2602 CVE-2023-38546 Fixed the following vulnerabilities in the Serverless Patcher:\nCVE-2023-38545 CVE-2023-44487 CVE-2023-4911 CVE-2021-35937 CVE-2021-35938 CVE-2021-35939 CVE-2021-3997 CVE-2023-2603 CVE-2023-27536 CVE-2023-28321 CVE-2023-28484 CVE-2023-29469 CVE-2023-29491 CVE-2023-30571 CVE-2023-36054 CVE-2023-39615 CVE-2023-39975 CVE-2023-4527 CVE-2023-45853 CVE-2023-4806 CVE-2023-4813 CVE-2021-43618 CVE-2022-29458 CVE-2022-48554 CVE-2023-2602 CVE-2023-27533 CVE-2023-27534 CVE-2023-27538 CVE-2023-28322 CVE-2023-29499 CVE-2023-2953 CVE-2023-2975 CVE-2023-32611 CVE-2023-32636 CVE-2023-32665 CVE-2023-3446 CVE-2023-3817 CVE-2023-38546 CVE-2023-4016 CVE-2023-4156 Improved Workload Instrumentation Stability with Highly Threaded WorkloadsFixed crashes in workload processes with a large number of threads.\n4.2.1 Sep 7, 2023Defect FixesEnsured Workload Instrumentation Handles Signals ConsistentlyImproved workload instrumentation performance by ensuring the stack pointer always points to a valid stack area, as required by signal handlers.\nVulnerabilitiesFixed the following vulnerabilities with the orchestrator agent:\nCVE-2023-30079 CVE-2023-22652 CVE-2023-28321 CVE-2023-28484 CVE-2023-29469 CVE-2023-34969 CVE-2023-28322 Fixed the following vulnerabilities with the serverless instrumentation:\nCVE-2023-28321 CVE-2023-28484 CVE-2023-29469 CVE-2023-28322 4.2.0 Aug 1, 2023Defect FixesEnsured Graceful Termination of the Instrumented WorkloadThe runtime instrumentation ensures the graceful termination of the instrumented workload when the container receives a termination signal (SIGTERM).\nImproved Workload Agent StabilityThe workload agent no longer fails to handle the syscall bpf(2).\nVulnerabilitiesFixed the following vulnerabilities with the orchestrator agent:\nCVE-2018-20839 CVE-2019-12904 CVE-2019-17543 CVE-2020-17049 CVE-2020-24736 CVE-2021-39537 CVE-2021-42694 CVE-2022-23990 CVE-2023-1667 CVE-2023-2253 CVE-2023-2283 CVE-2023-26604 Fixed the following vulnerabilities with the serverless patcher:\nCVE-2018-20839 CVE-2019-12904 CVE-2019-17543 CVE-2020-17049 CVE-2020-24736 CVE-2021-39537 CVE-2021-42694 CVE-2023-0361 CVE-2023-1667 CVE-2023-2253 CVE-2023-2283 CVE-2023-26604 CVE-2023-27535 Fixed the following vulnerabilities with the serverless instrumentation:\nCVE-2018-20839 CVE-2019-12904 CVE-2019-17543 CVE-2020-17049 CVE-2020-24736 CVE-2021-39537 CVE-2021-42694 CVE-2022-23990 CVE-2023-1667 CVE-2023-2283 CVE-2023-24329 CVE-2023-26604 CVE-2023-34969 4.1.2 Jun 1, 2023Defect FixesVulnerabilitiesFixed the following vulnerabilities with the orchestrator agent:\nCVE-2023-27535 CVE-2023-24329 CVE-2022-43552 CVE-2022-35252 CVE-2019-20916 Fixed the following vulnerabilities with the serverless instrumentation:\nCVE-2023-27535 CVE-2022-43552 CVE-2022-35252 Improved Workload Agent StabilityThe workload agent no longer fails to handle the capset syscall.\nImproved Orchestrator Agent Secure FeaturesThe orchestrator agent no longer fails to start when the collector enables falcobaseline.\n4.1.1 May 15, 2023Defect FixesVulnerabilitiesFixed the following vulnerabilities with the serverless patcher:\nCVE-2023-28840 CVE-2023-28841 CVE-2023-28842 4.1.0 May 2, 2023Cross-CompatibilityThe orchestrator agent 4.1.0 is compatible with the workload agent 4.0.0 and vice versa.\nNew FeaturesDisable AWS ContainerInsightsThe CloudFormation templates orchestrator-agent.yaml and serverless-instrumentation.yaml support disabling Container Insights.\nDefect FixesFixed CapturesCaptures no longer fail to start and complete.\nKilt Recipe/Definition CustomizationThe Kilt Recipe/Definition in the instrumentation.yaml can now be customized.\nVulnerabilitiesFixed the following vulnerabilities with the orchestrator agent:\nCVE-2022-41723 CVE-2023-0286 Fixed the following vulnerabilities with the serverless patcher:\nCVE-2023-0286 Fixed the following vulnerabilities with the serverless instrumentation:\nCVE-2023-24329 CVE-2023-0286 4.0.0 February 10, 2023End of LifeThe local installer used to deploy the instrumentation stack is no longer supported.\nDeprecation NoticeThe CloudFormation template serverless-instrumentation.yaml has been deprecated.\nNew FeaturesServerless PatcherThe Serverless Agent 4.0.0 provides serverless-patcher, a new containerized template patcher that can run locally and be integrated into CI/CD pipelines.\nAddedinstrumentation.yaml to the CloudFormation TemplateThe Serverless Agent 4.0.0 provides instrumentation.yaml, a new CloudFormation template to deploy the automation to instrument (that is, to patch) templates on Cloud.\nSecretsManager Support for the Orchestrator AgentSecrets like the Access Key and the Proxy Password can now be automatically fetched and provided to the orchestrator agent at deployment time.\nCustom CA Certificates Support for the Orchestrator AgentThe orchestrator agent supports the uploading of custom CA(certificate authority) certificates. That allows for the SSL(Secure Sockets Layer) certificate verification of OnPrem backends and proxies.\nImproved Fine-Tuning of the Workload Agent LogsLogs can be tuned and controlled at the fine-grained component level. This can avoid excessive logging from certain components, or enable extra logging from specific components for troubleshooting.\nDefect FixesRuntime Instrumentation ExitsThe runtime instrumentation now exits when the main process exits, thus avoiding waiting for other processes to finish and keeping the container alive.\nRenamed Parameter in the orchestrator-agent.yamlThe Gateway parameter has been renamed to NetworkType in the orchestrator-agent.yaml corresponding to the Cloud Formation Template.\nExact Image TagsThe CloudFormation stacks use exact tags now, instead of latest.\nRemoved Redundant Wildcard PermissionsRedundant wildcard permissions have been removed from the TaskRole of the orchestrator-agent.\nSIGINT/SIGTERM PropagationThe runtime instrumentation propagates SIGINT and SIGTERM signals to the instrumented workload now.\nHonor Log Silent Mode in the Workload AgentThe silent log mode now prevents environment variables from being printed.\nList Separator to OptIn/OptOut Containers to be/from being InstrumentedColons (:) are now required as list separators to OptIn/OptOut containers. Commas (,) are no longer supported.\nExampleIn the TaskDefinition, Tags can be leveraged to explicitly instrument some containers of the task, or prevent a number of them from being instrumented.\nFor example, the following tag prevents myContainer1 and myContainer2 from being instrumented when the template patching runs in OptOut mode (default):\nTags: - Name: \u0026#34;kilt-ignore-containers\u0026#34; Value: \u0026#34;myContainer1:myContainer2\u0026#34; VulnerabilitiesFixed the following vulnerabilities with the orchestrator agent:\nCVE-2022-28948 CVE-2022-47629 CVE-2022-41721 Fixed the following vulnerabilities with the workload agent:\nCVE-2022-47629 ","url":"https://docs.sysdig.com/en/release-notes/serverless-agent-release-notes/2023-archive/"},{"id":102,"title":"On-Prem Release Notes 2023","content":"6.7.0 Release, December 2023Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nBreaking Changes During Upgrade from On-Prem v6.5.X or v6.6.X to v6.7.0 or HigherIn v6.7.0, the nats.js PVC requirements have been increased. As a result, it is necessary to resize the PVCs before initiating the installer upgrade.\nOpen a support case for guidance and assistance with the upgrade process.\nSysdig SecureTransitioned Vulnerability Management Services to Use NATS-JSAll the Vulnerability Management services have been migrated to NATS-JS from the legacy NATS.\nCollector API\nScanResults\nRiskManager\nReporting\nRegistry Scanner\nScan Engine\nVulnerability API\nRuntimeView\nScanRequestor\nSbom API\nSysdig PlatformImproved Administration SettingsThe Settings page in Sysdig Secure and Monitor has been enhanced to provide you with a superior user experience.\nReorganized the Settings menu Added unified page headers Moved the buttons to the top of the pages Support for Sysdig Terraform Provider v1.18.1The Sysdig Terraform Provider v1.18.1 is compatible with Sysdig on-prem version 6.7.0.\nDefect Fixes Removed the Events \u0026amp; Logs option from Data Sources in Sysdig Secure. Made the Risk Acceptance page under Vulnerabilities accessible as expected in Sysdig Secure. Made NFS file mount points visible post upgrade to Sysdig Agent v12.17 and Sydig backend v6.7.0. sysdig_host_device_file_in_bytes will report the NFS mount points. 6.6.0 Release, November 2023Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises Installation documentation.\nSysdig SecureNexus and Google Support for Container Registry ScanningThe Image Registry Scanning functionality in the Sysdig Vulnerability Management engine has been updated to support scanning for the Nexus Repository and the Google Artifact Registry (GAR).\nFor more information on running the scanner, see the Registry Scanner documentation.\nReporting for Image Pipeline Vulnerability ScanningThe Vulnerability Management engine now supports Reporting for Image Pipeline scanning. This enables the easy collection and reporting of Pipeline scans over a given time.\nWith this addition, the engine can now report on every type of scan (Runtime, Registry, Host, and Pipeline). Pipeline reports mirror the Runtime and Registry reports, with just a change in the scoping context.\nException UI Improvements for Threat Detection RulesSysdig is introducing a new user-friendly exception builder. The new exception UI, built into the Rules Editor, helps you create, update, modify, and delete exceptions for threat detection rules.\nFor more information, see Rule Exceptions.\nAdvanced Users Can Apply Tuning SuggestionsTo make it easier to identify and apply exceptions, we have added the option to give Advanced Users and Team Managers permission to see and apply Tuning suggestions from the Insights and Event detail pages.\nTo enable this:\nLog in to Sysdig Secure as Admin and go to Settings. Toggle Advanced User Tuner Enablement on. Sysdig MonitorMetrics Usage Enhanced with Dashboards and Alerts Usage MetadataMetrics Usage now displays which Dashboards and Alerts use a given metric. This gives you better understanding of the value provided by a given metric.\nUX Improvements for PromQL Query ExplorerUpdated the PromQL Query Explorer with quality of life improvements while running queries:\nNow, only labels relevant to the query metrics are displayed in the autocomplete prompt. Labels are automatically selected and displayed in the query results table. Notification Snapshot for Metric Alert NotificationsThreshold Alert notifications forwarded to Slack or Email now include a snapshot of the triggering time series data. For Slack Notification channels, you can toggle the snapshot within the notification channel settings. When the channel is configured to Notify when Resolved, a snapshot of the time series data that resolves the alert is also provided in the notification.\nSysdig PlatformSettings Page RefreshThe Settings page in Sysdig Secure and Monitor has been enhanced to provide you with a superior user experience:\nImproved color scheme for the dark mode. Unified layout and components to establish consistency between Sysdig products. Better navigation through the new header component. Defect Fixes Fixed an issue in the Explore module where promlegacy_* metrics could prevent metric counts from loading. 6.5.1 Hotfix Release, October 2023Supported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the On-Premises Install Documentation. This repository also includes the on-premises installation documentation.\nDefect Fixes Fixed an issue where PostgreSQL stopped responding on Google Kubernetes Engine (GKE) environments with High Availability (HA) configuration.\nFixed the secure-diff installer command to correctly redact the secrets in the log.\n6.5.0 Release, September 2023Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem installation instructions.\nUse of MinIOStarting from release v6.5.0, MinIO has been added to the on-prem stack, specifically importing the MinIO binary from the upstream, for use in conjunction with Sysdig services.\nYou can download the MinIO source code in this repository. It is licensed under the AGPL 3.0.\nThis product includes software developed at MinIO, Inc. Copyright: MinIO Project, (C) 2015-2023 MinIO, Inc.\nSysdig SecureVulnerability Management Landing PageThe new Vulnerability Management landing page offers a place to identify, track, and initiate vulnerability management workflows. Here, you can see trends, priorities, and top action items among the vulnerability risks in your environment. The landing page covers all the scanning capabilities for images, workloads, and hosts, as collected by the installed scanners: vulnerability command-line interface (CLI), registry, host, and runtime. Widgets on the page enable you to take action or export data to your native information security tool ecosystem.\nThis feature enables:\nVulnerability Managers to easily identify changes in Risk Posture (trends), the most pervasive vulnerabilities, the latest vulnerabilities, and infrastructure segments with the most exposure to risk. Program Managers to get easy insight into Policy posture. Architects to easily access the data regarding scan counts and adoption rates. The Vulnerability Management team to prioritize and manage vulnerabilities at a program level. Container Registry ScanningImage Registry Scanning functionality is available as part of the Sysdig Vulnerability Management suite in on-prem deployments.\nThis feature provides an added layer of security between the pipeline and runtime stages, allowing you to gain complete visibility into potential vulnerabilities before deployment.\nThe supported vendors are:\nAWS Elastic Container Registry (ECR) - Single Registry and Organizational JFrog Artifactory - SaaS and On-Premises Azure Container Registry (ACR) - Single Registry IBM Container Registry (ICR) Quay.io - SaaS Harbor Once the container registry is instrumented and analyzed, you can generate registry reports to extract, forward, and post-process the vulnerability information.\nAdded Vulnerability Management APIsThe following API endpoints have been released in Technical Preview to list and filter vulnerability scan results for Pipeline, Registry, and Runtime as well as to fetch detailed scan results in JSON format:\nGet a list of pipeline scan results: GET /secure/vulnerability/v1beta1/pipeline-results Get a list of registry scan results: GET /secure/vulnerability/v1beta1/registry-results Get a list of runtime scan results: GET /secure/vulnerability/v1beta1/runtime-results Get full scan results: GET /secure/vulnerability/v1beta1/results These API endpoints are applicable only to the current Vulnerability scanning engine.\nFor more information on accessing the API, see developer tools.\nNew Vulnerability Management Engine for Airgap EnvironmentsThe New Vulnerability Management engine, a major upgrade to the vulnerability and image scanning functionality for the Sysdig Secure product, is available in airgapped on-prem deployments. Contact your Sysdig representative for technical support.\nMajor Highlights Reduced scanning time. It is now eight times faster on average.\nAdded more data for vulnerabilities and remediation.\nCVSS scores and metrics: Network Attack Vector, Privileges required, and so on Flagging of publicly available code exploits Suggested package fix version Added Risk spotlight, a new filter that only shows CVEs with active packages, to save time browsing infrastructure and focus on high-impact CVEs.\nThe New Vulnerability Reporting module now offers:\nUp to 14 days retention of individual reports. Immediate scheduling is directly available from the UI; just click Generate now. Flexible policies can now be attached to the different runtime and security contexts\nMigrate to the New Scanning EngineThe new vulnerability management engine uses a different data storage, API, host components, and user interfaces than the legacy scanning.\nContact your Sysdig representative to be guided through the process of migrating your subscription and vulnerability management configuration to the new engine. For more information, see Vulnerabilities.\nDefect Fixes Addressed several critical and high vulnerabilities. Fixed the issue where Compliance v2 reports return 204 status. Fixed the issue where you are forced to use the email address format for login when Lightweight Directory Access Protocol (LDAP) is enabled. You can now log in with your username. Post GKE Nodepool upgrade elastic search pods no longer fail to start. Added support for Linux cgroup v2 to the Sysdig PostgreSQL implementation for memory optimization. 5.1.11 Hotfix Release, September 2023This hotfix release fixes the errors reported in Rule Library and Runtime Policies post-upgrade.\nUpgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nDefect Fixes Post successful upgrade, the Rule library pages, and Runtime Policies no longer report errors while enabling and disabling certain policies. 5.1.10 Hotfix Release, September 2023This hotfix release certifies the support for Kubernetes versions 1.25, 1.26, and 1.27 on Sysdig Platform v5.1.10 and above.\nUpgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nDefect Fixes Events are detected as expected after an agent upgrade to v12.15.0. 6.4.1 Release, August 2023Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the Release notes. This repository also includes the on-prem Installation instructions.\nFor the v6.4.1 release, the Vulnerabilities module (built on the ScanningV2 engine) is not supported in airgapped environments.\nDefect FixesRemove Email Enforcement in LDAP LoginWhen LDAP authentication is enabled, the username field in the login screen is of input type text instead of email.\n6.4.0 Release, July 2023Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nPlatform Fixes Fixed an issue with fresh installations and upgrades with FIPS(Federal Information Processing Standards) mode enabled on backend hosts. Fixed an intermittent issue accessing the Sysdig UI when using a newly created Team. Fixed an init container issue for the sysdigcloud-feeds-db deployment that would use the wrong mount point. 6.3.0 Release, July 2023Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nSysdig SecureRisk SpotlightThe Risk Spotlight feature is now available for on-premises deployments. For more information, see Risk Spotlight Integrations.\nProcess Tree Visualization in Events Feed (Preview)The Process Tree feature in the Sysdig Secure events feed is now available in Technical Preview for on-premises deployments. This feature visually unveils the context in which a process was launched. It displays process lineage for security practitioners in a familiar EDR(Electronic Document Review) format to help users easily understand the relationships and dependencies between processes to accelerate incident response.\nThis feature requires Sysdig agent v12.15 and must be manually enabled.\n6.2.1 Release, June 2023Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.x\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nNote: Use Unifed Compliance on v6.2.1. To enable Unified Compliance, ensure that you set sysdig.secure.cloudsec.enabled to true in the values.yaml while upgrading.\nSysdig SecureVulnerability Management Scanning EngineSysdig now provides the Vulnerability Management Scanning engine for all on-premises users. This scanning engine was released in April 2022 and brings the latest vulnerability features and improvements.\nFor 6.2.1 fresh installations, the Vulnerability Management engine will be the only scanning engine provided. For customers upgrading from 5.0.x, 5.1.x, or 6.x versions, both the Legacy Scanning engine and the newer Vulnerability Management engine are available.\nExpanded Support for OpenShift 4 in Unified ComplianceSysdig Secure support for CIS RedHat OpenShift Container Platform v4 Benchmark has been expanded in Unified Complience. This includes 13 new controls in Sections 1-4 for 92% coverage, and 11 new controls in Section 5 for overall coverage of 74%.\nInfrastructure Resource ChangesWith version 6.2.1, the number of components the Sysdig Platform requires to run both Sysdig Secure and Sysdig Monitor is nearly doubled. This release introduces new product features in both products, as well as upgrades and enhancements of the datastores from the last major release in September 2021.\nSysdig has provided general testing with Platform configurations on 5.1.x and 6.0.x branches. The table below compares the CPU and memory requirements for a Sysdig backend with 600 agents connected to each.\nVersion CPU Requirements Memory Requirements v5 167 Cores 286 GB v6 134 Cores 372 GB The usage for each on-premises installation is different, so your load and sizing requirements may differ from the table above. To prepare for your upgrade from 5.x to 6.x, reach out to your account team for assistance to ensure your infrastructure meets requirements.\nSecure-Only Backend Enablement OptimizedFor users who enable a backend deployment with the Secure-Only configuration set to true, the footprint of Monitor components has been further reduced and minimized. However, for those upgrading from 5.x+, the addition of features and components in 6.2.1 has a complex effect on the overall resource usage.\nIn general, 6.0.0 requires less CPU and slightly more memory than 5.+. As version 6.2.1 has more components than 5.1.x, this means that the shared components (the ones used in both versions) require fewer resources in version 6.2.1. If you are upgrading from an existing branch with the legacy scanning engine, running both scanning engine components will require the most resources. For users with limited infrastructure resources who only use Sysdig Secure, please contact customer support or your Sysdig account team with your infrastructure node count and node size to ensure that the Secure-Only mode is the right deployment type for your needs.\nInternal Agent Dashboards Added (On-Prem Only)An Internal Agents Dashboard has been added under Integrations \u0026gt; Data Sources in Sysdig Secure for viewing granular information about the agents deployed in your environment.\nKnown Defects For 6.2.1 fresh installs, a few compliance checks that used the legacy scanner will not be available until a later release. Reach out to your account team for the full list of which checks are unavailable. The Get Started page doesn\u0026rsquo;t work in a 6.2.1 fresh install as it relies on a legacy scanning endpoint that is not longer available. This will be patched in a future release. If your agents are installed in Secure mode, some of the panels in the new Internal Agents Dashboard are missing data. This will be corrected in a future agent release. The affected panels are: Kubernetes Metadata Up to Date, CPU Usage, Memory Usage, and Total Agents without Cluster. The new Internal Agents Dashboard will not load properly if the Cloudsec service is not enabled. This service can be enabled through a flag in the Installer: sysdig.secure.cloudsec.enabled = true. 6.1.2 Release, May 2023Upgrade ProcessSupported Upgrades From: 5.0.x, 5.1.x, 6.0\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nDefect Fixes Refined the upgrade process for users upgrading from 6.0 or 5.1.X branches.\nFixed an issue where some values.yaml configurations were not kept during an upgrade.\n6.1.1 Release, May 2023Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nSysdig SecureDaily Updates of Managed Policies and RulesIn Sysdig Secure Threat Detection, managed policies and rule definitions are now updated from Sysdig daily at midnight UTC via a new cronjob service, sysdigcloud-falco-rules-deployer. See Manage Daily Updates (On-Prem Only) if you need to change the schedule or disable the feature.\nSysdig MonitorCloud Metrics Supports the following features:\nCloud Metrics UI\nCloud Integrations for AWS CloudWatch Metric Streams.\nFor more information on enabling CloudWatch Metric Streams, see Enable Cloud Metrics Streams in On-Prem Deployments.\nCloud Integrations for Azure\nFor users upgrading from 5.x.x to 6.x.x on-prem versions, the AWS CloudWatch API metrics will be converted from Sysdig notation to Prometheus. All the dashboards and alerts will be converted automatically.\nAWS CloudWatch API metrics will still be available in the Sysdig notation (aws.*)if the metrics are queried directly via the API. However, aws.*.latency metrics will be reported in seconds instead of nanoseconds, which was required for consistency between the AWS CloudWatch API metrics and AWS CloudWatch Metric Streams metrics. Users querying the aws.*.latency metrics directly via API from Grafana should change the time unit to seconds.\nDefect Fixes Fixed the Integrations without workload type. Fixed the list alerts API for summary information Changed icons in Event feed for policy type. Fixed an issue in which an appended rule could result in empty tags. Fixed a wrong label value order to report retention as label value. Fixed an issue on user provisioning. Fixed a problem with metrics that have new categories. 5.1.9 Hotfix Release, April 2023Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nDefect Fixes Added Alert group name to the Webhook notification channel payload. Retention manager now removes spurious images. Images with the tag SHA256 are now re-evaluated. Consolidated scan results between API and UI. 6.0.2 Hotfix Release, April 2023Upgrade ProcessThis release only supports fresh installations of the Sysdig platform into your cloud or environment.\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nDefect Fixes Enabled Internal Agents Dashboard.\nAdded CPU Usage and Memory Usage panels to Internal Agents Dashboard.\n6.0.0 Release, April 2023Upgrade ProcessThis release only supports fresh installations of the Sysdig platform into your cloud or on-premises environment.\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nMonitorSysdig has migrated to a Prometheus-native data store and is now available for on-premises deployments. This release adds several product offerings that are available on the Sysdig SaaS platform for the Monitor product. The following features are now available in the fresh installation of the 6.0.0 on-premises release:\nAdvisor Advisor Advisories Live Logs YAML Configuration Dashboards Dashboard Manager Dashboard Library Explore Metrics Explorer PromQL Query Explorer PromQL Library Alerts New Alerts Editor Alerts Library Integrations Monitoring Integrations Grafana Plugin AWS Cloudwatch Metrics The AWS CloudWatch API metrics will be available in Prometheus format. For more information, see AWS CloudWatch API Metrics. Notification ChannelsTwo new notification channels have been added:\nPrometheus Alert Manager Google Chat SecureInsightsIntroduced Insights, a powerful visualization tool for threat detection, investigation, and risk prioritization. All findings generated by Sysdig across workloads and cloud environments are aggregated into a visual platform that streamlines threat detection and forensic analysis. Insights helps you identify compliance anomalies and ongoing threats to your environment\nComplianceNew report types have been added to Unified Compliance:\nGoogle Cloud Platform (GCP) Azure Kubernetes Docker Linux Threat Detection Policies and RulesThreat detection policies now have three “flavors”, following the same model as our SaaS platform.\nDefault/Managed Policies Managed Ruleset Policies Custom Policies For a full description of policy types, see Threat Detection Policies.\nIntegrations Managed Kubernetes\nSysdig Agents\nPlatformCustom RolesA custom role is an admin-defined role which allows Sysdig administrators to bundle a set of permissions and allocate it to one or more users or teams. This features has been available in SaaS and is now released for our on-premises users. Fore more information, see Custom Roles.\nGroup MappingsGroup mappings allow you to connect groups from your identity provider (IdP) to the roles and teams associated with your Sysdig account.\nLogin MessageYou can now configure a custom login message to help maintain security standards based on your organization.\nPlatform AuditSysdig provides both a UI and a set of APIs for auditing and reporting on the use of the Sysdig platform itself. By default, the UI is disabled to minimize resource usage. The API is enabled by default. For more information, see Sysdig Platform Audit.\nPrivacy SettingsYou can choose to opt in or out of sharing usage data with Sysdig.\n5.1.8 Hotfix Release, February 2023Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes. This repository also includes the on-prem Installation instructions.\nDefect Fixes Fixed a time unit issue for Elasticsearch resolvers.\nFixed an issue where container metadata labels missing for Java virtual machine (JVM) metrics.\nFixed an issue where sysdig_fs_* metrics were not being discovered.\n5.1.7 Hotfix Release, January 2023Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Installation instructions.\nDefect Fixes Fixed an issue where images would not be scanned or re-evaluated with an alert configured with four or more scopes.\nFixed an issue where Captures from a runtime policy would not display in the Inspect UI.\nSysdig Platform Updated several containers that were mistakenly running as root. All containers now run using an unprivileged user. Updated the apiVersion of all Cronjobs from batch/v1beta1 to batch/v1. Fixed an issue that would sometimes result in a 413 Payload Too Large HTTP response to the Sysdig API. Fixed an issue with some Sysdig templates missing nodeSelectorTerms although nodeaffinityLabel is specified. 5.1.6 Hotfix Release, January 2023Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Installation instructions.\nDefect Fixes Fixed a privacy setting issue that would revert the admin setting after an update to the values.yaml file. Fixed a sidepanel interface bug that would appear under Scan Results. Fixed an issue with the metadata service sometimes returning an empty string as a value for some metrics, causing a banner to display saying A new version of Sysdig is available. Fixed an Anchore issue that would show vulnerabilities in packages that should not have been present. Updated the Anchore image with the latest code and security updates. ","url":"https://docs.sysdig.com/en/release-notes/sysdig-on-premises-release-notes/2023-archive/"},{"id":103,"title":"Configuration Library for Cluster Shield","content":"Generic Configuration Property Description Required Default cache Configuration for the cluster shield cache. No cluster_config The name of the cluster. Set a unique value for all the clusters being inspected. Yes features Features configurations. Yes kubernetes Kubernetes configurations. Yes log_level The minimum log severity to be reported in logs. Expected one of the following: err ,warn ,info ,debug ,trace. Yes warn monitoring_port The HTTP Server port used to expose healthcheck and prometheus metrics. No 8080 ssl SSL configurations. Yes sysdig_endpoint The configuration for the sysdig services. Yes Features Property Description Type Required Default Example admission_control Configurations for the admission control feature. This feature is in active development. See Admission Control. Admission Control Yes audit Configurations for the audit feature. Audit Yes container_vulnerability_management Configurations for the container vulnerability management feature. Container Vulnerability Management Yes kubernetes_metadata Configurations for the Kubernetes metadata feature. Kubernetes Metadata Yes posture Configurations for the posture feature. Posture Yes Kubernetes Property Description Type Required Default Example ca_cert_file Path to the CA Certificate file. string No /cert/ca.crt root_namespace Root namespace to use for the kubernetes resources. string No kube-system kube-system running_namespace Current namespace to use for the kubernetes resources. string No sysdig-agent tls_cert_file Path to the TLS Certificate file. string No /cert/tls.crt tls_private_key_file Path to the TLS Private Key file. string No /cert/tls.key SSL Property Description Type Required Default Example verify Define if the client must verify the backend SSL certificate. boolean Yes true Sysdig Endpoint Property Description Type Required Default Example access_key Sysdig Agent Access Key. string Yes 12345678-1234-1234-1234-123456789012 api_url Sysdig backend host. Expected format: uri. string Yes https://www.example.com collector Host and port to access Sysdig Collector endpoint. Expected format: hostport. string No collector.example.com:6443 region The region where the collector is located. Expected one of: custom ,au-syd-monitor ,au-syd-private-monitor ,au-syd-private-secure ,au-syd-secure ,au1 ,br-sao-monitor ,br-sao-private-monitor ,br-sao-private-secure ,br-sao-secure ,ca-tor-monitor ,ca-tor-private-monitor ,ca-tor-private-secure ,ca-tor-secure ,eu-de-monitor ,eu-de-private-monitor ,eu-de-private-secure ,eu-de-secure ,eu-gb-monitor ,eu-gb-private-monitor ,eu-gb-private-secure ,eu-gb-secure ,eu1 ,in1 ,jp-osa-monitor ,jp-osa-private-monitor ,jp-osa-private-secure ,jp-osa-secure ,jp-tok-monitor ,jp-tok-private-monitor ,jp-tok-private-secure ,jp-tok-secure ,me2 ,us-east-monitor ,us-east-private-monitor ,us-east-private-secure ,us-east-secure ,us-south-monitor ,us-south-private-monitor ,us-south-private-secure ,us-south-secure ,us1 ,us2 ,us3 ,us4. string Yes custom secure_api_token The API Token to access Sysdig Secure. string No 12345678-1234-1234-1234-123456789012 Admission Control Property Description Type Required Default Example dry_run Dry Run requests. boolean No true enabled Specify if the Admission Control is enabled. boolean Yes false excluded_namespaces List of namespaces to exclude from the admission control feature. array[string] No [] failure_policy The policy to apply when a request is denied. Expected one of: Ignore ,Fail. string Yes Ignore http_port The HTTP Server port to expose the webhook web server. integer Yes 8443 timeout The number of seconds for the request to time out. integer No 5 container_vulnerability_management Configurations for the container vulnerability management feature. AdmissionControlContainerVulnerabilityManagement Yes AdmissionControlContainerVulnerabilityManagement Property Description Type Required Default Example enabled Enable container vulnerability management checks. boolean No false Audit Property Description Type Required Default Example enabled Specify if the audit feature is enabled. boolean Yes false excluded_namespaces List of namespaces to exclude from the audit feature. array[string] No [] http_port HTTP Server port used to expose the webhook web server. integer Yes 6443 timeout The number of seconds for the request to time out. integer Yes 5 webhook_rules List of rules used to determine if a request should be audited. array[object] No [map[apiGroups:[ apps autoscaling batch networking.k8s.io rbac.authorization.k8s.io extensions] apiVersions:[*] operations:[*] resources:[*/*] scope:*]] Cluster Configuration Property Description Type Required Default Example name The name of the cluster. Make sure to set a unique value for all the clusters being inspected. string Yes my-cluster tags Tags you want to apply to the metadata sent to the Sysdig BE. They are used for instance as additional labels to the KSM metrics. object No Container Vulnerability Management Property Description Type Required Default Example enabled Specify if the scanning feature is enabled. boolean Yes false target_workloads Configuration for how and where workloads are scanned. ContainerVulnerabilityManagementTargetWorkloads No filters Filters to apply to the images you want to scan. ContainerVulnerabilityManagementFilter No in_use ContainerVulnerabilityManagementInUse Yes local_cluster ContainerVulnerabilityManagementLocal Yes max_file_size_bytes The maximum size in bytes allowed for a file to be analyzed. integer No 104857600 max_file_size_bytes_in_memory The maximum size in bytes for a file to be analyzed in memory. The files larger than this size are temporarily copied to the filesystem. integer No 26214400 memory_optimized_k8s_mode Enables memory-optimized access to Kubernetes API. Enabled by default, this property queries K8s using the Metadata API for all resources but Pods. Set this to false if you need to see the replica counters, but it will require more memory. boolean No true parallel_files_analysis_count The maximum number of files that are analyzed in parallel. integer No 5 platform_services_enabled Specify if the platform services are enabled. boolean No true registry_ssl Verify SSL certificate when connecting to the registry. SSL Yes ContainerVulnerabilityManagementTargetWorkloadsUse target_workloads to configure the type of workloads to scan for vulnerabilities, either kubernetes or non_orchestrated_containers. When kubernetes is selected for vulnerability scanning, it allows you to define how and from where container images are sourced. By default, Kubernetes workload images are pulled from container registries. To enable Local Scanning, instead, set image_source to node so images are directly read from the container runtime, on each Kubernetes node.\nProperty Description Type Required Default Example kubernetes Kubernetes-specific scanning configuration, to use when targeting workloads running in Kubernetes ContainerVulnerabilityManagementTargetWorkloadsKubernetes No non_orchestrated_containers Configuration to use when scanning containers running on hosts/nodes, not being controlled by a Kubernetes orchestrator ContainerVulnerabilityManagementTargetWorkloadsNonOrchestrated No ContainerVulnerabilityManagementTargetWorkloadsKubernetes Property Description Type Required Default Example enabled Enable vulnerability scanning of Kubernetes workloads. boolean No true image_source Defines from where the scanner should pull the image. Use node to enable Local Scanning, which fetches images directly from the node container runtime. Accepted values: registry, node. string No registry node ContainerVulnerabilityManagementTargetWorkloadsNonOrchestrated Property Description Type Required Default Example enabled Enable vulnerability scanning of non-orchestrated containers. Cannot be enabled if Kubernetes target workloads are enabled boolean No false ignore_init_failures Instructs the Container Vulnerability Management feature to ignore errors on container scanning initialization and fallback on host-only scanning. boolean No false true ContainerVulnerabilityManagementFilter Property Description Type Required Default Example rules The list of filter rules array ContainerVulnerabilityManagementFilterRules No ContainerVulnerabilityManagementFilterRules Property Description Type Required Default Example type The type of the filter. Expected one of: include ,exclude. string Yes exclude field The field to run the filter against. Expected one of: k8s.container.image. string No k8s.container.image k8s.container.image value The value to run the filter against string No docker.io* ContainerVulnerabilityManagementInUse Property Description Type Required Default Example enabled Retrieve in-use information from the backend and aggregate them on the scan results. boolean Yes true integration_enabled Share in-use information with the external integrations. boolean Yes false ContainerVulnerabilityManagementLocal Property Description Type Required Default Example registry_secrets ContainerVulnerabilityManagementLocalRegistrySecret No ContainerVulnerabilityManagementLocalRegistrySecret Property Description Type Required Default Example namespace string Yes secrets array[string] Yes Kubernetes Metadata Property Description Type Required Default Example enabled Specify if the Kubernetes Metadata feature is enabled. boolean Yes false annotations_allowlist List of Kubernetes annotations keys that will be sent to the Sysdig BE e.g. for generating KSM metrics. To include them, provide a list of resource names in their plural form and Kubernetes annotation keys you would like to allow for them. Annotation keys can contain wildcard character *. A single * can be provided per resource to allow any annotation. By default, no annotations are allowed for any resource. object No {} Posture Property Description Type Required Default Example enabled Specify if the Posture feature is enabled. boolean Yes false Cache Property Description Type Required Default Example backend Define the cache backend to use. Expected one of: redis. string No redis Configuration for the cluster shield redis cache. CacheRedis No CacheRedis Property Description Type Required Default Example address string No database string No password string No prefix string No sentinel_addresses string No sentinel_master string No tls_ca string No tls_enabled boolean No tls_skip boolean No ttl string No username string No ","url":"https://docs.sysdig.com/en/sysdig-secure/configure-cluster-shield/"},{"id":104,"title":"Customer ID, Name, and External ID","content":" For on-premises environments, the customer ID will typically be 1.\nTo retrieve the information:\nLog into the Sysdig interface.\nSelect one of the following from the user menu:\nAuthentication (SSO)\nSettings \u0026gt; Authentication (SSO).\nThe Authentication section lists the Customer ID, Customer Name, and External ID associated with your account.\nIf you need your Customer Name and it is blank, contact Sysdig Support to have your Customer Name set.\n","url":"https://docs.sysdig.com/en/administration/find-your-customer-id-and-name/"},{"id":105,"title":"Embed Workload Agent in an Image","content":"Embed the Workload Agent in your container imageThe following steps are generic and apply to any Dockerfile.\nFor this example, we will use the falcosecurity/event-generator image as the original workload to secure. This sample image is designed to generate secure events for testing purposes.\nGiven the original Dockerfile:\nFROM falcosecurity/event-generator:latest ENTRYPOINT [\u0026#34;/bin/event-generator\u0026#34;] CMD [\u0026#34;run\u0026#34;, \u0026#34;syscall\u0026#34;, \u0026#34;--all\u0026#34;, \u0026#34;--loop\u0026#34;] The resulting Dockerfile will be:\n+FROM quay.io/sysdig/workload-agent:latest AS workload-agent FROM falcosecurity/event-generator:latest +COPY --from=workload-agent /opt/draios /opt/draios +ENTRYPOINT [\u0026#34;/opt/draios/bin/instrument\u0026#34;, \u0026#34;/bin/event-generator\u0026#34;] CMD [\u0026#34;run\u0026#34;, \u0026#34;syscall\u0026#34;, \u0026#34;--all\u0026#34;, \u0026#34;--loop\u0026#34;] In detail:\nThe Sysdig Workload Agent is added as a separate layer, and then copied into the image file system under /opt/draios. The Sysdig application /opt/draios/bin/instrument is prepended to the original ENTRYPOINT to secure the original workload application at runtime. The secured container image is now ready to be built and pushed to your registry.\nDeploy the secured imageThe secured container image can be deployed like the original, with the additional Sysdig environment variables required for the Workload Agent to connect to the Sysdig Collector:\nSYSDIG_COLLECTOR and SYSDIG_COLLECTOR_PORT (SaaS Regions and IP Ranges). SYSDIG_ACCESS_KEY (Sysdig Access Key). These variables should be provided to the container in the deployment configuration, either as plain environment variables or secrets.\nNext StepsAfter the deployment is complete:\nThe workload agent will appear on the Sysdig Agent page in the Integrations Data Sources feed. Security-related events will be visible in the Sysdig Secure Events feed, provided that Runtime Policies matching the syscalls made by the workload are enabled. For falcosecurity/event-generator used in this sample, events can be triggered by enabling the Managed Policy Sysdig Runtime Notable Events. Workloads making syscalls that do not match the enabled Runtime Policies will not generate security events. Optionally, you can perform Advanced Configuration Steps.\n","url":"https://docs.sysdig.com/en/sysdig-secure/install-agent-components/install-agent-components/linux-on-serverless/embedded-container-image/"},{"id":106,"title":"Enrich Secure Events with Labels","content":"Add Custom Labels with the Tag AttributeThe agent has a set of default labels. Use tags to include additional labels and/or exclude labels from the default set.\nevent_labels: exclude: - custom.label.to.exclude event_labels: include: - custom.label.to.include The following is an example of an enriched event being sent to Splunk:\n{ agentId: 1658033 category: runtime containerId: d9f5e4a9aedd content: { baselineId: falsePositive: false fields: { container.id: d9f5e4a9aedd container.image.repository: sysdiglabs/example-voting-app-voter container.name: k8s_voter_voter-77d98548bc-hmkpc_example-voting-app_d27f532a-41f5-49f3-a140-99afccbac5e4_63603 evt.category: process falco.rule: Launch Root User Container fd.rip: \u0026lt;NA\u0026gt; fd.rport: \u0026lt;NA\u0026gt; proc.cmdline: container:d9f5e4a9aedd proc.name: container:d9f5e4a9aedd proc.pid: -1 proc.pname: \u0026lt;NA\u0026gt; proc.ppid: -1 } matchedOnDefault: false output: Outbound connection to IP/Port flagged by container:d9f5e4a9aedd (command=container:d9f5e4a9aedd port=\u0026lt;NA\u0026gt; ip=\u0026lt;NA\u0026gt; container=k8s_voter_voter-77d98548bc-hmkpc_example-voting-app_d27f532a-41f5-49f3-a140-99afccbac5e4_63603 (id=d9f5e4a9aedd) image=sysdiglabs/example-voting-app-voter) extra fields = (\u0026lt;NA\u0026gt; -1 process -1 container:d9f5e4a9aeddproc.aname container:d9f5e4a9aedd -1proc.apid ) policyId: 10009837 policyOrigin: Sysdig policyVersion: 37 ruleName: Launch Root User Container ruleTags: [ network mitre_execution ] ruleType: RULE_TYPE_FALCO } description: This Notable Events policy contains rules which may indicate undesired behavior including security threats. The rules are more generalized than Threat Detection policies and may result in more noise. Tuning will likely be required for the events generated from this policy. id: 1726f87daaaee3960301e17f9b06c3cf labels: { agent.tag.role: demo-kube-eks aws.accountId: \u0026lt;account-id\u0026gt; aws.instanceId: \u0026lt;instance-id\u0026gt; aws.region: us-east-1 container.image.digest: \u0026lt;sha-256\u0026gt; container.image.id: \u0026lt;image-id\u0026gt; container.image.repo: sysdiglabs/example-voting-app-voter container.image.tag: 0.1 container.label.io.kubernetes.container.name: voter container.label.io.kubernetes.pod.name: voter-77d98548bc-hmkpc container.label.io.kubernetes.pod.namespace: example-voting-app container.name: k8s_voter_voter-77d98548bc-hmkpc_example-voting-app_d27f532a-41f5-49f3-a140-99afccbac5e4_63603 host.hostName: \u0026lt;host-name\u0026gt; host.mac: 0a:a2:c4:d3:fd:ef kubernetes.cluster.name: demo-kube-eks kubernetes.deployment.name: voter kubernetes.namespace.name: example-voting-app kubernetes.node.name: \u0026lt;node-name\u0026gt; kubernetes.pod.name: voter-77d98548bc-hmkpc kubernetes.replicaSet.name: voter-77d98548bc } machineId: 0a:a2:c4:d3:fd:ef name: Sysdig Runtime Notable Events originator: policy severity: 4 source: syscall timestamp: 1668293930605536300 timestampRFC3339Nano: 2022-11-12T22:58:50.60553615Z type: policy } Add Custom Labels with the Event Labels AttributeIn addition to custom static tags added with the tags attribute in the agent configuration, you can use the event_labels attribute to include any label present in the system call. Note the agent will only collect and store events handled by the Sysdig backend.\nagent.tag.Tag agent.tag.cluster agent.tag.environment agent.tag.role agent.tag.sysdig_secure.enabled gcp.projectId host.hostName aws.user container.label.io.kubernetes.pod.namespace host.mac kubernetes.statefulSet.name container.image.repo container.label.io.kubernetes.pod.name aws.accountId gcp.user gcp.region container.label.maintainer kubernetes.service.name container.image.tag kubernetes.cluster.name kubernetes.deployment.name kubernetes.namespace.label.project container.label.io.kubernetes.container.name container.name kubernetes.pod.name aws.fargate.task.arn container.image.digest kubernetes.daemonSet.name kubernetes.job.name kubernetes.namespace.label.field.cattle.io/projectId kubernetes.namespace.name kubernetes.node.name kubernetes.replicaSet.name aws.region container.image.id kubernetes.cronJob.name aws.fargate.cluster.arn aws.availabilityZone Disable Label CollectionSysdig Agent collects Secure Events labels by default. To disable the feature: disable the feature, change true to false:\nevent_labels: enabled: true ","url":"https://docs.sysdig.com/en/sysdig-secure/enrich-secure-events-with-agent-labels/"},{"id":107,"title":"How to Integrate with GitHub + Sigstore for Image Signature Validation","content":"OverviewSigstore provides a way to sign and verify container images using short-lived, identity-bound certificates through OIDC. GitHub integrates with Sigstore’s public services, allowing images built in GitHub Actions to be signed keylessly.\nWith Sysdig Secure, verification occurs automatically during cluster admission based on policy rules you define in the backend. No Sigstore service deployment is required.\nPurpose of IntegrationUse GitHub and Sigstore to ensure that only images signed by trusted GitHub workflows are admitted to your Kubernetes or OpenShift clusters. Admission control rejects unsigned or incorrectly signed images, improving provenance, compliance, and supply chain security.\nBenefits Capability Description Policy-driven verification Trust rules are defined in the Sysdig Image Signature Validation policy. Keyless OIDC signing Trust GitHub Actions identities without managing long-lived private keys. No infrastructure to host Uses public Sigstore services; Fulcio, Rekor, or TUF hosting is not required. Admission enforcement Blocks non-conforming images before deployment. SummaryThis integration verifies container images signed in GitHub Actions using OIDC identities.\nVerification criteria are defined in the Sysdig Image Signature Validation policy, and Cluster Shield enforces those rules during admission.\nConfigurationCluster ShieldNo GitHub or Sigstore configuration is required in Helm values.\nYou can enable signature checks globally. The backend policy determines verification behavior.\nfeatures: supply_chain: enabled: true image_signature: cosign: enabled: true Policy ConfigurationUse the Image Signature Validation Policy to define how Sysdig verifies image signatures. You can choose between two mutually exclusive verification mechanisms:\nPublic Key verification (PKI-based)\nProvide a PEM-encoded public key. Sysdig verifies images signed with the corresponding private key. Use this method when you control your own signing keys, such as in a non-keyless CI setup. Example\n-----BEGIN PUBLIC KEY----- MFswDQYJKoZIhvcNAQEBBQADSgAwRwJAXWRPQyGlEY+SXz8Uslhe+MLjTgWd8lf/ nA0hgCm9JFKC1tq1S73cQ9naClNXsMqY7pwPt1bSY8jYRqHHbdoUvwIDAQAB -----END PUBLIC KEY----- OIDC Provider (GitHub/Sigstore keyless verification)\nSpecify the OIDC Issuer, for example https://token.actions.githubusercontent.com. Define the Certificate Identity using a regular expression that matches the signer identity (for example, a GitHub repo/workflow path, service account, or email). Optionally, provide a Certificate Chain (PEM) to override the default chain. This is useful if you have a custom TUF root or want to pin or override a chain for the policy. Examples\nOIDC Issuer (regexp supported): ^https://token.actions.githubusercontent.com$ Certificate Identity (regexp supported): ^https://github.com/my-org/my-repo/.github/workflows/build\\.yml@refs/heads/main$ or ^https://github.com/my-org/.* or ^system:serviceaccount:my-ns:my-sa$ or ^user@example\\.com$ Choose either Public Key or OIDC Provider in a single policy. They are mutually exclusive.\nExample Use Cases Allow only images signed by the my-org/my-repo main branch workflow in production namespaces. Block all third-party images unless signed by your central build key (Public Key mode). Allow platform namespaces to deploy images signed by a service account identity via OIDC. See Also Image Signature Validation Policy cosign verify documentation GitHub Actions OIDC hardening ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/policies/supply_chain_policies/how-to-github-sigstore/"},{"id":108,"title":"Inventory","content":" Resources: View cloud, Kubernetes, and container environments and respond to compliance and vulnerability findings. Kubernetes Live: View information about the last 24 hours in your Kubernetes environments. Network: Track ingress and egress communication from every pod in your network. Zones: Control access to different parts of your environments. ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/inventory/"},{"id":109,"title":"Vulnerability Management Overviews","content":"The Vulnerability Management Overview page enables rapid identification of:\nVulnerability Management (VM) trends Pervasive vulnerabilities and policy failures New risks Riskiest segments of your environment The Overview provides reportable trend analysis that you can download as reports, export to create tickets, or share with team members. From the Overview, you can pivot into remediation workflows for specific CVEs, policies, architecture segments or coverage gaps.\nThe Vulnerability Management Overview page is refreshed daily. Data might take up to 24 hours to appear.\nPrerequisites Sysdig Secure using current Vulnerability Management engine.\nA current Sysdig agent that includes the Vulnerability Management engine.\nThe Host Scanner.\nThe Runtime Scanner for Runtime.\nSysdig CLI Scanner for Pipeline.\nContainer Registry Scanner for Registry.\nAdvanced User permissions or higher.\nZones enabled to scope by zone. To enable Zones, go to Settings \u0026gt; User Profile. Under Sysdig Labs, toggle Zones scoping for all features on\nGetting Started with Vulnerability ManagementTo explore Vulnerability Management overviews:\nLog in to Sysdig Secure.\nSelect Vulnerabilities \u0026gt; Overviews | All Vulnerabilities.\nIf you click the title (Vulnerability Management Overview), you will be able to scope the data by:\nPipeline Registry Runtime Select the icon in the top left corner to take a screenshot of the page.\nUse the drop-down bar to scope findings by zone.\nYou can also filter by severity, or whether the vulnerability is in use, has an exploit, or has a fix.\nUnderstand the UI Log in to Sysdig Secure.\nUnder Vulnerabilities | Overviews, select one of the following:\nAll Vulnerabilities Pipeline Registry Runtime Each page shows corresponding trend analysis that you can download as reports, export to create tickets, or pivot into remediation workflows for specific CVEs, policies, architecture segments or coverage gaps.\nPipelineThe Vulnerability Management Pipeline page provides a quick overview of the pipeline scanning results.\nYou can filter the results by Zones and Pullstrings to narrow your search. You can also use additional filters to further refine the results by severity, vulnerability type, or policy.\nZones are in Technical Preview. To enable Zones, go to Settings \u0026gt; User Profile. Under Sysdig Labs, toggle Zones scoping for all features on. If Zones is not available from your User Profile, contact your Sysdig representative.\nRegistryThe Vulnerability Management Registry page gives you a quick overview of the results from the registry scanning.\nYou can filter by Zones, Vendors, and Registry to narrow the results. You can also use additional filters to further refine the results by severity, vulnerability type, or policy.\nZones are in Technical Preview. To enable Zones, go to Settings \u0026gt; User Profile. Under Sysdig Labs, toggle Zones scoping for all features on. If Zones is not available from your User Profile, contact your Sysdig representative.\nRuntimeThe Vulnerability Management Runtime page gives you a quick overview of the results from runtime scanning.\nTo narrow the results, you can filter by the following:\nResource Types : Host, Workload, and Container Cluster : Kubernetes Cluster Namespace: Kubernetes Namespace Hostname: The available hosts in your Cloud or Kubernetes environment Zones: The Zones created in your environment Zones are in Technical Preview. To enable Zones, go to Settings \u0026gt; User Profile. Under Sysdig Labs, toggle Zones scoping for all features on. If Zones is not available from your User Profile, contact your Sysdig representative.\nAdditional filters are also available to further refine the results by severity, vulnerability type, or policy.\nFiltersSelect top-level filters to focus on a particular subset of vulnerability or policy data: severity and type.\nSeveritySelect any or all criticality level: Critical, High, Medium\nTypeSelect the package and CVE context variables: Has Exploit, In Use, and Has Fix\nDateThe CVE trend chart displays data from the past 30 days. You can use the date selector or double-click on a day to see the Vulnerability panel results filtered for just that day.\nNote that runtime and pipeline scans are performed twice a day, while registry scans are only performed after an action.\nAll context filters apply to the widget on the page, the drill-down drawers, and exports of data.\nRisk AcceptanceFilter out accepted risks to help you focus on active, unresolved issues. Select one of the following options:\nAll Risks: See all the risks. Risks Accepted : View only accepted risks. Risks Not Accepted: Hide all the accepted risks. These filters are available also in the Vulnerabilities tab in the scan result page.\nScan Data TimelinesEach panel reports on the behavior of scans for the past 30 days. Individual scan data from:\nRuntime is retained for 14 days Registry and Pipeline is retained for 90 days Package Details in the the drill-down is available for 48 hours Use CasesVulnerability Management UsageThe top panel is designed to guide Vulnerability Management workflows.\nThis panel gives an overview of:\nTrends of Unique Vulnerabilities in the environment over the past 30 days Most Pervasive vulnerabilities Recently Released vulnerabilities, and Namespaces with the most vulnerability detections These let you answer questions about their risk posture, such as:\nAre my CVE detection trending down? What are the most pervasive vulnerabilities? What are the most recent vulnerabilities (log4j-type event)? What is my most vulnerable application, segment or zone? Each line item expands to a detail panel for further investigation.\nThe identified resources, vulnerabilities, or policies in the dropdown can be further filtered and exported via the Sysdig reporting or through a .csv file.\nPolicy and Risk Management UsageThe Compliance Manager asks three fundamental questions.\nWhich of my Compliance programs is struggling with control failures? Which of the controls is failing the most? Which of my applications, segments, or zones is failing the most policies? The Policy Panel provides insight to all of these questions via the widgets:\nTop Failing Policies Top Failing Assets Top Failing Rule Sets Dropdowns provide for more information and options to export.\nSample FlowsIdentify Progress through Metrics Choose a Filters for Phase (if applicable). Choose CVE type filters. Filter on segments of the infrastructure (if necessary). Review the metrics graph to see trends. Click on days to identify the difference between them. Export any data to .csv from a subpanel. Export the page including the graph to PDF for reports to executive. Identify a Problematic CVE Filter by Has Fix, Has Exploit, and possibly In Use. Filter by desired severity. Review the Top Recent or Top Pervasive widget. Identify a New or Particularly pervasive CVE. Click into the dropdown. View the assets and associated packages. Choose: Create a Report Export the list of assets and packages to CSV Click through to the results page of a single asset. Reports and ExportsThere are various ways that the Vulnerability Management Dashboard can support your workflows through data exports.\nDownload Scan ResultsYou can download scan results for pipeline, runtime, and registry scanning in PDF, CSV, and Zip format.\nPDFThe downloaded file includes up to 100 rows and is sorted by severity. To download the desired scan results, use the Download PDF button found across the Overview, Vulnerabilities, Content, Policies, and Detail tabs.\nCSVYou can download vulnerability report in CSV and Zip format for Pipeline, Registry, and Runtime scanning results.\nSelect the asset and click the Vulnerabilities tab.\nClick Export data.\nThe Export Data screen appears.\nSelect either CSV or Zip.\nClick Export.\nExecutive ReportsThe dashboard can be scoped and filtered to support a focused view of trending and critical issues. Once filtered, you can export the Dashboard to PDF for inclusion in executive reports, audit artifacts, or briefings.\nCritical Vulnerability or Policy TablesYou can export data in tabular form from any of the widgets or panels on the VM Dashboard using the cloud download button on the panel. You can use this data in business intelligence or tracking tools.\n","url":"https://docs.sysdig.com/en/sysdig-secure/vm-overviews/"},{"id":110,"title":"Configure Prometheus Remote Write","content":" Use Prometheus Remote Write to access metrics from:\nAn existing Prometheus server\nAdditional environments, such as:\nWindows\nManaged Cloud Environments, such as AWS and IBM\nFargate\nInternet of things (IoT)\nUse the Sysdig agent in environments where an agent can be installed. However, use the Prometheus Remote Write to collect metrics from ephemeral or batch jobs that may not exist long enough to be scraped by the agent.\nWith Prometheus Remote Write, you can either analyze metrics through the Sysdig Monitor UI, or you can use PromQL, the standard Prometheus query language, to query the data.\nPrerequisites Ensure you have a Prometheus server set up and collecting metrics. Collect your Sysdig API key. Confirm your endpoints and region. Endpoints and RegionsPrometheus Remote Write resides in the ingest endpoints for each region under /prometheus/remote/write. The public Prometheus Remote Write endpoints for each region are listed in SaaS Regions and IP Ranges.\nConfigure Remote Write in a Prometheus ServerYou need to configure remote_write in your Prometheus server to send metrics to Sysdig via Prometheus Remote Write.\nThe configuration of your Prometheus server depends on your installation. In general, you configure the remote_write section in the prometheus.yml configuration file:\nglobal: external_labels: [ \u0026lt;labelname\u0026gt;: \u0026lt;labelvalue\u0026gt; ... ] remote_write: - url: \u0026#34;https://\u0026lt;region-url\u0026gt;/prometheus/remote/write\u0026#34; bearer_token: \u0026#34;\u0026lt;your API Token\u0026gt;\u0026#34; The communication between your Prometheus server and Prometheus Remote Write should use the authorization header with the Sysdig API key (not the agent access key) as the bearer token.\nAlternatively, you can also use the bearer_token_file entry to refer to a file instead of directly including the API token.\nPrometheus does not reveal the bearer_token value in the UI.\nCustomize MetricsTo enable customization, Sysdig provides additional options to control which metrics you want to send to Prometheus Remote Write.\nManage MetricsPrometheus Remote Write by default sends all the metrics to Sysdig Prometheus Remote Write. These metrics are sent with a remote_write: true label appended to it so you can easily identify them.\nLabel MetricsYou can specify custom label-value pairs and send them with each time series to the Prometheus Remote Write. Use the external_labels block in the global section in the Prometheus configuration file. This is similar to setting an agent tag and allowing you to filter or scope the metrics in Sysdig Monitor.\nFor example, if you have two Prometheus servers configured to remote write to Prometheus Remote Write, you can include an external label to identify them easily:\nPrometheus 1 global: external_labels: provider: prometheus1 remote_write: - url: ... Prometheus 2 global: external_labels: provider: prometheus2 remote_write: - url: ... Filter MetricsWith the default configuration, all the metrics are remotely written to Prometheus Remote Write. You can control the metrics that you collect and send to Sysdig. To select which series and labels to collect, drop, or replace, and reduce the number of active series that are sent to Sysdig, set up relabel configurations by using the write_relabel_configs block within your remote_write section.\nFor example, you can send metrics from one specific namespace called myapp-ns as follows:\nremote_write: - url: https://\u0026lt;region-url\u0026gt;/prometheus/remote/write bearer_token_file: /etc/secrets/sysdig-api-token write_relabel_configs: - source_labels: [__meta_kubernetes_namespace] regex: \u0026#39;myapp-ns\u0026#39; action: keep Verify InstallationTo verify that the Prometheus Remote Write has been installed correctly:\nLog in to Sysdig Monitor.\nDo one of the following:\nOpen Explore \u0026gt; PromQL Query and runt the following query:\nsum(sysdig_ts_usage{metric_category=\u0026quot;PROMETHEUS_REMOTE_WRITE\u0026quot;})\nYou will see the time series usage graph on the screen.\nOpen Dashboards \u0026gt; Sysdig Monitor \u0026gt; Time Series Usage.\n​ Under the Number of time series ingested per category panel, check the time series category.\n​ ​ You will see PROMETHEUS_REMOTE_WRITE as one of the categories.\nRate LimitThe default limits for each user can be raised as required. The defaults are good for most users, and the limits help protect against any misconfigurations.\nFeature\nLimit\nParallel writes\n100 concurrent requests.\nThis doesn't necessarily mean 100 Prometheus servers because the time at which the data is written is distributed.\nData points per minute\nOne million.\nThe number of data points sent depends on how often metrics are submitted to Sysdig. A scrape interval of 10s will submit more DPM than an interval of 60s.\nNumber of writes per minute\n10,000\nTeam ScopingIt is possible to scope a Sysdig Team to only access metrics matching certain labels sent via Prometheus Remote Write. See Manage Teams and Roles\nLimitations Alerts based on metrics ingested through Prometheus Remote Write will be delayed by approximately 5 minutes to ensure all the data has been correctly ingested.\nMetrics sent to Prometheus Remote Write can be accessed in Explore, but they are not compatible with the scope tree.\nLabel enrichment is unavailable. Only labels collected at the source can be used. Add additional labels to perform further scoping or pivoting in Sysdig.\nRemote write functionality does not support sending metric metadata.\nSuffix the metric name with _total, _sum , or _count to store them as a counter. Otherwise, the metrics will be handled as a gauge.\nUnits can be set in Dashboards manually.\nLearn More Using PromQL\nRun PromQL Queries Faster with Extended Label Set\nPromQL Query Explorer\nPromQL Library\nPrometheus Alerts\n","url":"https://docs.sysdig.com/en/sysdig-monitor/install-prometheus-remote-write/"},{"id":111,"title":"Rule Bundles","content":"Rule Bundle Guidelines Default Sysdig rule bundles (indicated by the Sysdig shovel icon) cannot be deleted.\nYou can duplicate these default bundles to use as templates for new rule bundles. A single rule bundle can be assigned to multiple policies.\nThe order of rules within a bundle does not impact how they are evaluated. You may reorder rules for clarity or personal preference in the UI.\nMultiple instances of the same rule type are allowed in a single rule bundle.\nFor example, you can add several rules of the type Vulnerabilities: Severities and Threats within one bundle. Conditions within a single rule are evaluated using AND logic.\nA vulnerability must meet all specified conditions in a rule to be considered a violation. Rules within a rule bundle are evaluated using OR logic:\nIf any rule in the bundle is violated, the entire rule bundle is considered in violation. If any rule bundle is in violation, the associated policy is considered failed. Create a Rule BundleWhen creating a Rule Bundle, follow these steps to ensure all required items and options are addressed before being allowed to save the bundle.\nLog in to Sysdig Secure.\nNavigate to Policies \u0026gt; Vulnerability Rule Bundles.\nSelect Add Rule Bundle.\nFill in the required fields:\nName: Specify a unique name to identify the rule bundle. Description: Enter a brief description detailing the purpose or scope of the rule bundle. Rules: Add one or more scanning rules to the bundle. Each rule is displayed as a \u0026ldquo;card\u0026rdquo; in the UI and can be created or configured using the visual editor. Select Save.\nThe rule bundle is now defined.\nAttach a Rule Bundle to a VM PolicyTo attach a rule bundle to Sysdig Vulnerability Management Policies:\nLog in to Sysdig Secure.\nSelect Policies \u0026gt; Vulnerability Policies.\nSelect an existing policy or create a new policy.\nThe policy configuration page appears.\nIn the Rules section, select a rule bundle from the drop-down.\nComplete the policy configuration and select Save.\nLearn MoreFor available rules and configuration checks, see Vulnerability, Image Configuration and Image Content Rules.\n","url":"https://docs.sysdig.com/en/sysdig-secure/vm_policies/rule_bundles/"},{"id":112,"title":"Sysdig Agents (Secure)","content":"Use this page to determine:\nWhich agents are up-to-date, out-of-date, or approaching being out-of-date Which managed clusters have been detected in your cloud environment, but have not yet been instrumented with the Sysdig agent What environment the agents are running in, containerized or non-containerized Review EnvironmentSelect Integrations \u0026gt; Environments | Sysdig Agents.\nThe resulting page shows all detected nodes in your environment and the status of the agents installed on them, or not. The view shows nodes detected from previously installed agents on hosts and from connected cloud accounts.\nPlease note that for agents deployed in a Managed Cluster (EKS/GKE/AKS), the Cluster Name displayed will be the value retrieved from the cloud as opposed to the value configured in the agent configmap.\nYou can:\nSee at a Glance: Quickly identify where agents are installed: by node, cluster name, or cloud account ID. Know the Status: Check agent connection status and age. Search or Filter: Narrow the view by searching or filtering on node name, cluster name, Account ID, agent version, or agent Status. Agent Count: View your total connected agent count over time. Understand Deployment Type: Check the agent breakdown per deployment type. Install or Troubleshoot: Link to quick steps for adding an agent or troubleshooting disconnected nodes. Summary The Summary panel includes counts of the following:\nTotal Connected Agents: The total number of agents connected to Sysdig. This includes serverless agents, but not Cluster Shield connections. Containerised Connected Agents: The number of agents deployed in a containerized environment. Up to Date: The number of agents that are up to date and running the latest Agent version. Almost Out of Date: The number of agents that will be deprecated in the next release. Agent support is provided for the last three minor version releases. Out of Date: The number of deprecated agents. Total Connected Agents Count The Total Connected Agent Count chart displays the number of agents connected to Sysdig over time. The data is aggregated in 24-hour intervals. Metrics data may take up to 24 hours to appear. The count is segmented into containerized and non-containerized environments.\nUnderstand Agent Status Status Description Notes Never Connected Cloud Accounts only. Detects nodes in a managed cluster in a cloud account connected to Sysdig, where an agent has not been deployed Hover over the status to link to the Helm-based agent install instructions. Out of date Agent version is older than 12 months. Hover over the status for information on upgrading the agent. Almost out of date Agent version is between 4 and 12 months old. Hover over the status for information on upgrading the agent. Disconnected A Sysdig agent on a registered Kubernetes node lost connection to Sysdig. Hover over the status for information on how to troubleshoot an agent installation Up to date Agent version is current or up to 3 months old. Connected The agent is connected. This status includes agents that are Up to date, Almost out of date and Out of date. Understand Deployment Type Deployment Type Description host The host agent did not detect containerized environment: virtual machine, host, bare metal server host, containerised The host agent detected the Kubernetes environment by identifying the presence of KUBERNETES_SERVICE_HOST environment variable. fargate Fargate Agent Agent version 12.18.0 or greater is required in order to show environment type (containerised/non-containerised).\nOptions to Add Agent Go to Integrations \u0026gt; Environments | Sysdig Agents.\nFrom the Summary panel, select Add Agent.\nSelect whether your environment is Kubernetes, Linux, Docker or Fargate.\nFollow the wizard instructions.\nViewing Total Connected AgentsYou can also view total connected agents from other parts of the UI. A different calculation may be used in these places.\nSubscription Page Sysdig Secure Home Sysdig Secure Integrations \u0026gt; Environments | Sysdig Agents ","url":"https://docs.sysdig.com/en/sysdig-secure/integrations-sysdig-agents/"},{"id":113,"title":"Threat Exclusions","content":"When a Threat exclusion rule is active, the underlying events still occur, but the associated threat is not created on the Threats page, and thus, alert notifications will not be sent.\nUse CasesYou can use threat exclusion rules to reduce the noise from a variety of sources that do not constitute real threats. These may include:\nKnown benign activities that consistently trigger Threats, such as routine admin activities in development or pre-production environments. Example: Actions performed by a role like my_role frequently creating VPCs and deleting flow logs. Activities occurring in specific environments, such as dev or pre-prod, where Threats are irrelevant or expected. Example: Cryptocurrency mining detected in a sandbox or test environment specifically set up for resource load testing. Activities performed by known, trusted identities / users / service accounts. Example: A known and trusted admin user performing high-privileged actions. Known noisy rules that consistently generate non-actionable Threats. Example: Rules detecting Delete VPC Flow Log actions that are part of automated cleanup processes. Routine or expected package installations, software updates, or environment configuration activities. Example: apt-get update -y and apt install Python commands frequently triggered by deployment processes. Create an ExclusionYou can create a threat exclusion from either the Threat Exclusion page or directly from a Threat.\nTo create it from the Threat Exclusion page:\nLog in to Sysdig Secure.\nNavigate to Detection \u0026amp; Response \u0026gt; Threat Exclusions.\nSelect New Exclusion Rule.\nEnter a Name and select the Criteria. For details, see Define Criteria.\nTo create an exclusion from an occurrence of a Threat:\nLog in to Sysdig Secure.\nNavigate to Detection \u0026amp; Response \u0026gt; Threats.\nIdentify a threat you wish to make an exclusion rule for.\nSelect the three-dot menu icon.\nSelect Create Exclusion Rule.\nThe Exclusion Rule modal appears.\nEnter a Name, review the Criteria, and edit as you wish. For details, see Define Criteria.\nSelect Save.\nCreated exclusions appear on the Threat Exclusion page. Here, you can enable or disable them with the toggle, and review their details, such as the creation date.\nDefine CriteriaIn the Criteria section of the Exclusion Rule modal, you can define the exact threat you wish to ignore.\nUse this when you always want to suppress Threats from particular clusters, users, workloads, or processes. You can combine multiple labels to target specific resources.\n","url":"https://docs.sysdig.com/en/sysdig-secure/threat-exclusions/"},{"id":114,"title":"Toplist","content":"Major Features Toplist supports executing multiple queries.\nSegmentation is supported for all queries.\nText displayed on the bars in the chart is based on queries and segmentation.\nIf there is a single query without segmentation, the query name is displayed.\nIf there is a single query and multiple segmentations are selected, segmentation texts separated by \u0026gt; sign are displayed.\nIf there are multiple queries, the query name is displayed on the bar.\nSegmentationYou can use multiple objects to simultaneously segment a single metric. For example, cpu.used.percent segmented by kubernetes.cluster.name, kubernetes.namespace.name, and kubernetes.deployment.name.\nIn this example, deployments are sequentially listed in the order of resource consumption. Use Display to toggle between descending (Top) and ascending order (Bottom).\nConfigure Display FieldsWhen you specify the time display fields of a Toplist query, you can configure the time series display name using text and values of any of the configured segments as variables, for example, CPU usage % for {{host_hostname}}. In addition to segments as variables, you can also display the value of the query, for example, CPU usage % with value: {{__values__}}\n","url":"https://docs.sysdig.com/en/sysdig-monitor/toplist/"},{"id":115,"title":"Agent Release Notes 2020","content":"10.8.0 December 18, 2020Defect FixesFiltering Long Container LabelsFiltering long container labels works as expected with no parsing failures or undesirable agent restarts.\nCorrect kubernetes.pod.restart.rate MetricFixed an issue that could cause kubernetes.pod.restart.rate metric to be incorrect.\nPrometheus Metrics With Multiple Process Listening ConcurrentlyFixed a problem that caused scraping Prometheus metrics to fail when another process was listening to the TCP port 9090 on a host interface.\nStatsD Metrics Reports Correct ValueFixed a problem that caused Statsd metrics to report incorrect values.\nCorrect Environment Variable Hash in Audit TapFixed an issue that could cause the environment variable hash associated with the exported processes in audit tap to have an incorrect value.\nImprove JMX Availability CheckThe sdjagent process in the agent no longer consumes excessive CPU resources.\n10.7.0 November 20, 2020Feature ImprovementsPolicies and Baselines V1 Messages Are DeprecatedSysdig agent no longer supports the old backend message types that were originally deprecated in on-prem release 2.4.0 (August 2019).\nLoad Falco Rules on a Separate ThreadPartially load Falco rules in the background to avoid interrupting event processing.\nWorkflow for Unacknowledged MetricsThe agent is restarted if a metrics acknowledgment hasn\u0026rsquo;t been received from the Sysdig backend components in 8 minutes. This can happen if networking issues cause the agent to believe it has an active connection when the backend has closed the connection.\nRun Single Agent RPM Per HostPrevents multiple agent services from being launched on the same RHEL-based hosts.\nKnown IssuesThe host.container.start.count metric acts as a counter metric and its value increases monotonically.\nDefect FixesOpenShift Hardening Guide Correctly Detects Master and Worker NodesRunning the OpenShift Hardening Guide functionality of the Kubernetes Benchmark will now correctly detect master vs worker nodes, and run the appropriate Benchmark tests.\nAgent No Longer Terminates Non-Agent ProcessesIn some rare situations when process creation in the Agent\u0026rsquo;s JMX module failed due to issues caused by resource limits, it could inadvertently stop unrelated processes running on the host. This problem has been fixed.\n10.6.0 October 30, 2020Feature ImprovementsPython 2.7 Is No Longer Supported in Agent ContainersPython 2.7 has been removed from the agent and agent-slim containers.\nThis is a breaking change for users who are using an agent container and have set the python_binary configuration to /usr/bin/python2.7.\nTo prevent breaking the setup, do one of the following:\nRemove the python_binary configuration option.\nSet python_binary to /usr/bin/python3.\nSysdig agent continues to support python 2.7 if installed as a service and the host has python 2.7.\nKubernetes BenchmarksUpdated kube-bench to support Kubernetes benchmarks and targets. For a complete list of benchmarks, see Benchmarks (Legacy) .\nKubernetes benchmark 1.6\nMaster\nControl plane\nNode\netcd\nPolicies\nGoogle Kubernetes Engine (GKE) Benchmark 1.0\nMaster\nControl plane\nNode\netcd\nPolicies\nManaged services\nAmazon Elastic Kubernetes Service (EKS) Benchmark 1.0\nControl plane\nNode\nPolicies\nManaged services\nConfiguring Prometheus Metric Expiration TimeConfiguring metrics expiration time is supported by promscrape.v2 for Prometheus metrics gathered by using Prometheus service discovery.\nSupport for Scoping Policies by Kubernetes Cluster NameAdd support for scoping policies by kubernetes.cluster.name. The cluster name must still be manually configured by using the configuration option, k8s_cluster_name: \u0026lt;CLUSTER NAME\u0026gt;.\nImproved Prometheus Service DiscoveryMade kubernetes node matching more reliable for Prometheus Service Discovery by comparing IP addresses as opposed to node names in the default configuration.\nDefect FixesCVE FixesAddressed a known vulnerability in the jackson-databind package version 2.9.10.6 by upgrading to version 2.11.3 in agent containers.\nReduce Severity of NoClassDefFoundError Log from Error to InfoChanged the java NoClassDefFoundError class from Error to Info to reduce spamming the logs at the Error level. This happens commonly when the agent attempts to read metrics from a java v11 application which was not started with the com.sun.management.jmxremote option.\nStatsD Metrics No Longer Show Larger Than Expected ValuesFixed a problem that caused StatsD metrics to be double the expected value.\nRemove Warning LogsRemoved warning logs about ambiguous source labels when using the Prometheus service discovery with multi-container pods.\n10.5.2 October 21, 2020Defect FixesMemory Leak No Longer Occurs in the AgentFixed an issue that could potentially cause a slow increase in the agent\u0026rsquo;s memory usage over time when the thin_cointerface_enabled configuration option is enabled.\n10.5.1 October 08, 2020Feature ImprovementsAdded New Rules to the Prometheus Configuration to Honor Pod AnnotationsImproved the default Prometheus configuration for promscrape.v2 to honor pod annotations.\nKnown IssuesLogs warning messages in the agent log file when promscrape.v2 is enabled.\nDefect FixesPods Are No Longer Associated with Incorrect DeploymentsFixed a problem that could cause a pod to be associated with incorrect deployments.\n10.5.0 September 24, 2020New FeaturesEnable Communication Between Agent and Collector Through a Proxy ServerSysdig agent to the collector communication can be established via an HTTP or an HTTPS Proxy server.\nFor more information, see Enable HTTP Proxy for Agents.\nDefault Prometheus Configuration FileA new version of promscrape, promscrape.v2 , has been introduced to offer native Prometheus service discovery capabilities. To support this, a default prometheus.yaml file has been added with Kubernetes pod discovery rules to use when native Prometheus service discovery is enabled. See Enable Prometheus Native Service Discovery for more information.\nSecure ModeSysdig agent now supports secure mode that offers Secure only features. See Secure Mode for more information.\nKnown IssuesNone.\nDefect FixesCVE FixesAddressed vulnerabilities reported in the agent and agent-slim containers, including the one for CVE-2017-18640 in a dependency library related to image scanning.\nAgent No Longer Hangs While Handling Connection ErrorsFixed an issue that caused the agent to hang while handling some types of connection errors. When this issue is encountered, restarting the agent will allow it to reconnect.\nUpgrading to Sysdig agent v10.5.0 or higher is strongly recommended to avoid this problem.\nScraping Prometheus Endpoints in Docker ContainersPrometheus metrics can now be scraped from endpoints in Docker containers with remapped port numbers.\nPrevent Agent Crashes in Large SystemsThe agent now starts faster on systems with thousands of processes and hundreds of containers.\nWarning for Prometheus Metric LimitThe agent logs a warning once in a minute when the Prometheus metric limit is reached.\nTransmitting Prometheus Metrics Works As Expected When Service Discovery Is EnabledFixed a problem that could randomly result in Prometheus metrics not being sent when Prometheus service discovery is enabled.\nAppcheck Metrics No Longer Go MissingFixed a problem that would cause certain app check metrics to be missing when 10-second aggregation in the agent is enabled.\nAgent Now Times Out If Connection Attempt to Collector Does Not WorkAdded a timeout to the handshake protocol between agent and collector.\nAgent Now Collects JMX Metrics from New Process Following a Java Service RestartFixed a problem that randomly caused JMX metrics to be not collected due to transient errors encountered during the startup of new Java processes.\nPod to Service ConnectionFixed a problem that caused the UI to show a pod under an incorrect service if other services exist in different namespaces with the same selectors. This happened when the thin_cointerface_enabled property was set to true.\nSyscall Fast Rule Triggers as ExpectedFixed the evaluation of secure fast engine syscall rules when the If Not Matching rule is selected.\n10.4.1 August 26, 2020Defect FixesKubernetes Pods No Longer Lose Association with ResourcesFixed a problem that could cause Kubernetes pods to lose association with their deployment or other related resources.\n10.4.0 August 19, 2020New FeaturesAbility to Scrape Prometheus Metrics from Container IP AddressesThe agent can now scrape Prometheus metrics from the docker containers that expose ports only on specific IP addresses besides the localhost.\nUse Forwarder Is Enabled by DefaultThe use_forwarder option is now enabled by default. See Collect StatsD Metrics Under Load.\nSet JMX LimitsThe default value (300) of per-process JMX bean limits can now be changed as follows:\njmx: max_per_process_beans: 500 Known IssuesHandling Benchmark Task When StatsD Metrics Collection Is DisabledWhen Statsd is disabled, do not attempt to send metrics related to benchmarks tasks. This also means that benchmarks dashboards will not have data when Statsd is disabled.\nKubernetes Pods Can Lose Association with ResourcesA problem that could cause Kubernetes pods to lose association with their deployment or other related resources has been identified in Agent version 10.4.0. A new version, 10.4.1, that will address this problem is currently in development.\nDefect FixesKubernetes Audit Server and Agent Process Restart CongruentlyEmbedded web server for Kubernetes audit events restarts as expected when the agent process is restarted.\nCVE Fixes Related to Slim Agent v10.3.0Updated the version of the jackson-databind package to fix vulnerabilities discovered in the slim agent v10.3.0\n10.3.1 August 06, 2020Defect FixesKubernetes Benchmark Tasks No Longer FailThe kube-bench binary that was identified as broken due to the change in the output format has been fixed.\nkube-bench that performs the Kubernetes Benchmarks tasks has changed the output format, causing the existing Benchmark tasks to fail in v10.3.0. With this fix, the agent will no longer throw errors related to this issue and the new Kubernetes Benchmark results will appear in the UI as expected.\nProbes Works As Expected for v5.8 KernelsFixed an issue with building probes for Linux v5.8.0 kernel.\n10.3.0 July 28, 2020New Features and EnhancementsChanges to the Monitor ModeURL segmentation for metrics has been moved from the default monitor mode to the troubleshooting mode. Due to this change, dashboard panels with per URL metric will show no data. See Additional Metrics Values Available in Troubleshooting.\nSysdig Probe Location ChangesThe Sysdig probe URL is changed to download.sysdig.com.\nIf the Sysdig probe URL is included in the allow list for outbound firewall access, you must change the endpoints to reflect the new probe location.\nAgent Connects to Promscrape through UNIX Socket By DefaultThe agent now connects to promscrape through a UNIX socket by default as opposed to the TCP port 9876.\nNew Configuration File Paths for Kube ProxyThe version of kube-bench has been upgraded to 0.2.4. The changes include an additional configuration file path for Hyperkube kube-proxy to support OpenShift.\nKnown IssuesKubernetes Benchmark Tasks FailThe kube-bench binary is broken due to the change in the output format and the issue will be fixed in an upcoming release.\nkube-bench that performed the Kubernetes Benchmarks tasks changed the output format, causing the existing Benchmark tasks to fail. The new Kubernetes benchmark results will not appear in the UI, and the agent will report errors related to Kubernetes benchmark tasks.\nDefect FixesEndPoints-Independent Metrics Limits for PrometheusPrometheus metric limits have been modified to ensure that endpoints with fewer timeseries are not affected when another endpoint hits the limit. Reporting of Prometheus timeseries statistics has also been updated.\nPrometheus Count Metrics for Summary and HistogramThe calculated Prometheus _count metrics are reported for summaries and histograms even when the _sum values are missing. This feature is not applicable to raw metrics.\nA .count metric (which is the rate of change of _count values) and a .avg (which is the average of new samples when _count increases) are calculated for summaries and histograms. Earlier, those .count and .avg metrics are reported only if the raw Prometheus metrics include both _sum and _count values. In this release, changes have been made such that _sum values are no longer required to calculate Prometheus _count metrics for summaries and histograms.\nReporting Running Pod CountsFixed an issue pertaining to the reporting of running pod counts for replication controllers, deployments, and ReplicaSets.\nSegmenting Kubernetes Jobs Metrics By NamespaceFixed an issue that prevented having Kubernetes jobs segmented by namespace.\nAgent No Longer Stalls Under High LoadFixed an issue that caused the agent to stall under high load.\nRestarting Agent No Longer Causes ExceptionFixed an issue that caused an exception at agent restart while collecting CPU metrics.\n10.2.0 June 25, 2020New Features and EnhancementsPrometheus ScrapingPeriodic logging of statistics for Prometheus timeseries has been added. When a metric limit is hit, all the timeseries metrics associated with the endpoint are dropped.\nApp Checks and Prometheus MetricsProcesses with app checks or Prometheus metrics are now included by default in the top processes to be sent to the Sysdig collector.\nPerformance ImprovementA variety of performance improvements have been rolled out to accelerate the evaluation of Falco rules and fast engine rules for the common case of events not matching any rules/policies.\nDetect JSVC Processes as Java ProgramsThe agent has been enhanced to detect JSVC processes as java programs to enable the collection of JMX metrics.\nTroubleshooting Metrics Removed from Default ModeThe net.mongodb.* and net.sql.* metrics have been moved from the default monitor mode to the troubleshooting mode. For more information, see Additional Metrics Values Available in Troubleshooting.\nDeprecated MetricsThe following deprecated App Checks have been removed and will no longer be supported.\nNetwork\nRiakCS\nTokuMX\nCeph\nGearmand\nGunicorn\nKyoto Tycoon\nTeamcity\nRiak\nSolr\nOpenStack\nDefect FixesFixed a Race ConditionFixed a potential race condition that could occur when receiving multiple policies and related messages from the Sysdig collector at nearly the same time.\nBenchmark Task ConfigurationThe agent no longer runs a built-in set of benchmark tasks. The agent will only run benchmark tasks when configured to do so by a Sysdig Secure backend.\nPrometheus Metrics From Idle Processes Are No Longer DroppedPrometheus metrics from idle processes are no longer dropped even if the target processes are not active enough to be in the top processes. Additionally, the app_checks_always_send parameter, which can force report the idle processes with metrics, now works as expected for metrics gathered by promscrape.\nRemoved Authentication CredentialsRemoved sensitive authentication credentials related to app checks from debug log messages.\nKubernetes Events Are No Longer DroppedKubernetes events are no longer dropped under some high load conditions.\nMemcached App Checks Collects Slabs and Items StatsFixed a problem that prevented the collection of slab and item stats in the Memcache app checks in certain Python environments.\nMetrics No Longer Report Incorrect Zero ValuesThe following metrics now no longer return incorrect zero values:\nkubernetes.resourcequota.cpu.requests.hard\nkubernetes.resourcequota.cpu.requests.used\nkubernetes.resourcequota.memory.requests.hard\nkubernetes.resourcequota.memory.requests.used\nAgent Automatically Restarts Upon Protocol Mismatch ErrorsThe agent used to require manual intervention to recover from protocol mismatch errors received from the Sysdig Backend. This error can occur when the agent and Sysdig Backend are not in sync. The agent has been enhanced to automatically restart when this error is encountered, so manual intervention is no longer required.\n10.1.1 June 02, 2020Defect FixesEnable Network TopologyNetwork stats metrics that were moved to the troubleshooting mode in Agent v10.1.0 have been re-enabled by default. The metrics will now be available in the monitor mode, which in turn will enable the network topology by default.\nFor information on agent modes, see Configure Agent Modes.\n10.1.0 June 01, 2020New FeaturesSupport for Linux v5.6 KernelsAdded support for Linux 5.6 kernels.\nJMX Support for Java v11, 12, 13 and 14 JREAdded JMX support for Java 11, 12, 13, and 14 JRE. For containerized Java apps with JRE, run the app with the -Dcom.sun.management.jmxremote option.\nAdded Rate Limiting ConfigurationsAdded rate limiting configurations to the agent to avoid connection timeouts for metrics and secure messages.\nAdded New MetricsAdded a new metric to display the kernel version of the host where the agent is running.\nhost.uname\nThis metric can be segmented by host.uname.kernel.name, host.uname.kernel.release , and host.uname.kernel.version.\nAdded Container Name to the Containerd Event DescriptionAdded container name to the containerd events description. In some rare cases, the container name associated with a containerd event might be unavailable due to metadata lookup delay.\nRemoved Authentication CredentialsRemoved sensitive authentication credentials related to app checks from debug log messages.\nRemoval of Deprecated App ChecksThe following deprecated app checks will be removed in an upcoming release:\nNetwork\nRiakCS\nTokuMX\nCeph\nGearmand\nGunicorn\nKyoto Tycoon\nTeamcity\nRiak\nSolr\nOpenStack\nEnable Removed MetricsSome metrics related to network and file will not be available by default. You can enable them by editing the dragent.yaml file.\nEdit the Configuration File Open the dragent.yaml file.\nAdd the following configuration parameter:\nfeature: mode: troubleshooting Restart the agent.\nRemoved Metrics in Agent v10.1.0The following metrics will not be reported by default in agent v10.1. When segmented by a particular label, these metrics will not have some values. The table summarizes the metrics and missing values when they are segmented by a particular label.\nMetrics Unreported Metrics Values When Segmented by file.error.total.count file.name and file.mount labels file.bytes.total file.bytes.in file.bytes.out file.open.count file.time.total host.count host.error.count proc.count proc.start.count net.bytes.in net.connection.server, net.connection.direction, net.connection.l4proto and net.connection.clientlabels net.bytes.out net.connection.count.total net.connection.count.in net.connection.count.out net.request.count net.request.count.in net.request.count.out net.request.time net.request.time.in net.request.time.out net.bytes.total Defect FixesPromscrape No Longer Breaks Metrics Collection Over HTTPSFixed promscrape to honor the ssl_verify configuration option.\nSlim Agent Container No Longer Prevents Certain App Checks From Emitting MetricsFixed an issue with the agent-slim container that prevented postgres and pgbouncer app checks from emitting metrics.\nReduced the Frequency of Log MessagesReduced the frequency of a log message to reduce spam and enhanced a statsd related log message to provide more information about incorrectly formatted strings.\nUse Exact Rule Names When Adding Rules to Runtime PoliciesConsider only exact matches when linking secure runtime policies to Falco rules to fix this issue.\nCorrected Calculation of net.bytes.* MetricsFixed calculation of net.bytes.* metrics at the host level when using calico interfaces or VPN tunnels.\n10.0.0 May 01, 2020New FeaturesKubernetes Benchmark Master ProgramsAdded the ability to run Kubernetes Benchmark Master Programs on additional Kubernetes distributions.\nNew Scraping Mechanism for PrometheusA new process, called promscrape, has been introduced to scrape Prometheus metrics by default. The mechanism, based on the open-source Prometheus, improves compatibility and performance. It also allows per-endpoint metric filtering and relabeling through metric_relabel_configs.\nFor more information, see Working with Prometheus Metrics.\nNon-Root Access to Log FilesAdded the ability to make draios.log files readable by users other than root. This can be enabled with the following configuration in dragent.yaml.\nlog: globally_readable: true New Runtime Policy ActionAdded the ability to kill containers as a runtime policy action. See Manage Policies for details.\nDefect FixesFixed the Path Parameter Issue in Prometheus ConfigurationFixed the use of the path parameter in Prometheus configuration when using promscrape. With this fix, the configured path is passed to promscrape by the agent when it is set up for a target rule in dragent.yaml.\nService Annotation Based Prometheus ScrapingPrometheus scraping can now be triggered based on service annotations by default.\nAdded a Missing Module to the agent-slim ContainerAdded the missing posix-ipc module to the slim agent. This fixed an issue that prevented App Checks from running in the agent-slim container on v9.9.0.\nNo Metric Limit on Scraped Prometheus MetadataPrometheus scraping metadata is no longer counted toward, or limited by, metric limits when using promscrape.\nFix for Percentile MetricsFixed a defect that caused percentile metrics to not work properly.\n9.9.1 April 16, 2020Defect FixesAdded the Missing Module to the Slim AgentAdded the missing Posix module to the slim agent. This fixed an issue that prevented App Checks from running in the agent-slim container on v9.9.0.\n9.9.0 April 13, 2020Core Features and FixesPython 3 Set as Default and Some App Checks DeprecatedPython 3 is the new default Python version for app checks, instead of Python 2. Python 2 can still be used by setting the following option in your dragent.yaml:\npython_binary: \u0026lt;path to python 2.7 binary\u0026gt;\nFor containerized agents, this path will be:/usr/bin/python2.7\nThe following app checks are deprecated as of 9.9.0:\nNetwork\nRiakCS\nTokuMX\nCeph\nGearmand\nGunicorn\nKyoto Tycoon\nTeamcity\nRiak\nSolr\nOpenstack\nSee Integrate Applications (Default App Checks).\nFixed Kernel Issue when Deploying Agent on GKEFixed a potential CPU stall on kernels with versions greater \u0026gt;= 4.19 using eBPF probe.\nFixed Flooded Agent LogsFixed an issue that caused excessive logging in the agent log file.\n9.8.0 March 31, 2020 All the public-facing URLs that were pointing to https://s3.amazonaws.com/download.draios.com/ have been updated to point to https://download.sysdig.com/.\nChange the URL in the whitelisting firewall/proxy setting to reflect https://download.sysdig.com/. Otherwise, the agent install on Linux will fail.\nFixesMetrics Reporting\nFixed an issue in the agent wherein the kubernetes.namespace.pod.desired.count and kubernetes.namespace.pod.available.count metrics were not reporting any values.\nHDFS App Check Deprecated\nThe HDFS (Hadoop Distributed File System) App Check had been deprecated and removed. Users of the HDFS App Check can switch to hdfs_namenode and hdfs_datanode App Checks.\nMetric Calculation\nFixed an issue related to calculating the kubernetes.pod.restart.rate metric.\nNetwork Congestion\nIsolated the Kubernetes Audit HTTP server from the Audit Event processing path to reduce the chances of slowing down the connections from the Kubernetes API server. This should reduce the likelihood of multiple outstanding connections from the Kubernetes API server.\nCertifi Python Module\nAdded a missing certifi Python module to the agent container.\n9.7.0 March 09, 2020New FeaturesSupport for OpenShift Hardening GuideAdded OpenShift Hardening Guide as a benchmark program. It is available as an option for CIS Kubernetes Benchmark.\nSupport for Linux BenchmarkAdded Linux benchmarking as an available benchmark program.\nNew Metrics for Redis and MongoDB App ChecksThe following metrics are introduced:\nRedisDB\nredis.mem.startup\nredis.mem.overhead\nMongoDB\nmongodb.tcmalloc.generic.current_allocated_bytes\nmongodb.tcmalloc.generic.heap_size\nmongodb.tcmalloc.tcmalloc.aggressive_memory_decommit\nmongodb.tcmalloc.tcmalloc.central_cache_free_bytes\nmongodb.tcmalloc.tcmalloc.current_total_thread_cache_bytes\nmongodb.tcmalloc.tcmalloc.max_total_thread_cache_bytes\nmongodb.tcmalloc.tcmalloc.pageheap_free_bytes\nmongodb.tcmalloc.tcmalloc.pageheap_unmapped_bytes\nmongodb.tcmalloc.tcmalloc.spinlock_total_delay_ns\nmongodb.tcmalloc.tcmalloc.thread_cache_free_bytes\nmongodb.tcmalloc.tcmalloc.transfer_cache_free_bytes\nFixesSlim Agent VulnerabilitiesFixed the vulnerabilities detected in the agent-slim v9.6.1 image. These issues are related to the python2 and jackson-databind packages. These packages were upgraded to the versions with fixes.\nRun App Checks on Hosts with Python 2.6Fixed a defect that prevented app checks from running on hosts that install Python 2.6.\n9.6.1 February 28, 2020FixesMetrics calculation\nFixed an issue that caused an error in the calculation of some metrics such asnet.* in agent version 9.6.0.\nRed Hat-based host issue\nFixed an issue that caused the kernel module build associated with agent version 9.6.0 to fail on Red Hat-based hosts.\n9.6.0 February 26, 2020UpgradesIntegrations improved\nAdded new metrics and configuration options for HAProxy and Consul app check integrations. See HAProxy, and Consul for details.\nFixed a problem with Go app check which caused it to fail with an exception error.\nMetrics added\nAdded Kubernetes metric kubernetes.namespace.pod.running.countto track the number of pods in running state. See Kubernetes Dashboards.\nReduced load on the Kubernetes API server\nThe version of client-go was updated and now defaults to encoded protobuf messaging instead of JSON to improve performance.\nConfiguration option new_k8s now enabled by default.\nDefault collector port changed\nThe default port for the collector was changed from 6666 to 6443.\nThis could affect your firewall port settings; you may want to review them before upgrading the agent.\nFix for the dynamic back-end configuration of Kubernetes Audit Logging caused some agent deploys to fail\nThe agent is enhanced to listen on /k8s-auditfor Kubernetes audit events and the path can be configured via the config option security:{k8s_audit_server_path_uris: [path1, path2]}.\nFixesPrometheus metrics fix\nFixed a problem that inhibited the agent from scraping multiple ports on a single process for Prometheus metrics.\nInaccurate cpu.used reporting fixed\nFixed a problem that caused the agent to erroneously report very high CPU usage in some environments.\n9.5.0 January 28, 2020 Note that the versioning scheme for agent releases has been updated with this release. Previous versions used the format 0.\u0026lt;version number\u0026gt;\u0026lt;hotfix\u0026gt;, such as 0.94.0.\nSysdig is aligning version numbers to the rest of the product. The new version number reflects the maturity of the Agent software over the last several years. Going forward, all Agent versions will be numbered as Major.minor.hotfix.\nWe encourage users to be on the latest version of the Agent. Starting with the next release of the Agent, we will support n-3 versions back based on the minor number. For example, if the next release is v 9.6.0, we will support n-3 versions back, e.g to 9.3.0 (old version scheme = 0.93.0).\nFixes and UpgradesAdded new configuration option and metrics for Elasticsearch integrations\nIn the Elasticsearch app check, the parameter index_stats can be used to collect metrics from individual indices. See Example 4 in Elasticsearch and Elasticsearch Metrics for details.\nAdded new metrics for NGINX Plus integrations\nMore than 60 new metrics have been added to the NGINX app check. See NGINX Plus Metrics for details.\nMade Go-based event handling the default\nSee Process Kubernetes Events. As of agent 9.5.0, the default setting for go_k8s_user_events is true and there is no need explicitly to enable it. To switch back to the older events monitoring (C++ based), set the value to false in your agent config (dragent.yaml).\nEnhanced log tracing for include/exclude processes filter.\nNo user action is required; see Include/Exclude Processes to use the filter.\nFixed agent termination issue\nFixed a problem that was causing an internal process within the agent to repeatedly restart.\nImproved memory buffer handling\nThe agent will now auto-disable memdump functionality when the memory buffer is too small.\nAgent start/stop improvements on CRI-O and OpenShift 4.x\nThe agent can now correctly perform the pause and stop container actions on clusters running OpenShift 4.x and CRI-O.\n","url":"https://docs.sysdig.com/en/release-notes/linux-agent-release-notes/2020-archive/"},{"id":116,"title":"Secure SaaS Release Notes 2021","content":"December 17, 2021Update on Log4j Vulnerability (CVE-2021-44228)Sysdig confirms that all services that compose Sysdig\u0026rsquo;s Cloud Platform running Apache\u0026rsquo;s vulnerable Log4j library have been patched to 2.16. We have not detected any successful attempts at exploitation of this attack vector during that time window.\nDecember 15, 2021Update on Log4j Vulnerability (CVE-2021-44228)The sysdig agent does not include the Log4j library\nSysdig is using an alternative framework for logging called Logback. The logback framework isn\u0026rsquo;t vulnerable to this issue.\nSysdig components include a log4j library in our standard distribution that was vulnerable. This library is included for compatibility reasons only, is not used for primary logging, and our security team has determined we are not vulnerable based on our application architecture and existing mitigating controls.\nSysdig can confirm that all services that compose Sysdig\u0026rsquo;s Cloud Platform running Apache\u0026rsquo;s vulnerable Log4j library have been patched to the latest version or adds additional mitigating controls suggested by vendors. We have not detected any successful attempts at exploitation of this attack vector during that time window.\nDetails regarding upgrades We:\nexplicitly set commonsLog4jVersion = 2.15.0 update all of log4j-to-slf4j, log4j-api, and log4j-core to version 2.15.0 December 15, 2021Sysdig Secure for AzureSysdig is pleased to announce the general availability of the Sysdig Secure for cloud capabilities for Azure.\nCloud Security Posture Management (CSPM): Based on CIS benchmarks tailored for your assets Cloud Threat Detection: Identify threats in your Azure environment using Falco rules for Azure Event Hub: Fully managed, real-time data ingestion service that\u0026rsquo;s simple, trusted, and scalable Image Vulnerability Scanning: Automatic vulnerability scanning of images pushed to Azure Container Registry and images executed on Azure Container Instance Group. For details, see Deploy Sysdig Secure for cloud on Azure.\nDecember 12, 2021A Statement on Log4j vulnerability (CVE-2021-44228)Security researchers recently disclosed the vulnerability CVE-2021-44228 in Apache\u0026rsquo;s log4j, which is a common Java-based library used for logging purposes\nSysdig is using an alternative framework for logging called Logback. The logback framework isn\u0026rsquo;t vulnerable to this issue.\nSysdig components include a log4j library in our standard distribution that appears to be vulnerable. It has been confirmed that this library is included for compatibility reasons only and is not used for primary logging. As a result this should not pose any risks.\nPatches will be provided to upgrade the log4j libraries that are included for compatibility reasons.\nIf you have any questions or concerns, please reach out to your Sysdig contact.\nDecember 1, 2021Image Analyzer 0.1.15 Inline Scanner 2.4.8 ReleasedRelease 0.1.15 of the Node Image Analyzer\nRelease 2.4.8 of the Sysdig Inline Scanner\nUpdated to the latest security fixes Fixed support for COPY, USER, and other instructions when the image is built using buildkit November 5, 2021Improved Handling of Forwarded Benchmark EventsForwarded benchmark events now include AWS tags as key-value pairs (rather than a flattened string), making them easier to consume.\nNovember 2, 2021Inline Scanner 2.4.7 UpdateRequirements\nlibseccomp \u0026gt;= 2.3.3 (on the Host/JenkinsWorker - where the docker command is executed) docker version \u0026gt; v18.05.0-ce Fixes\nFixed support for COPY, USER, and other instructions when image is built.\nOctober 27, 2021Cloud Infrastructure Entitlements Management (CIEM) for AWSSysdig Secure has added Permissions and Entitlements Management functionality. You can find it under Posture menu tab.\nBy combining the CIEM capabilities announced today with Sysdig\u0026rsquo;s existing capabilities, Sysdig customers can proactively prevent cloud permissions risks, scan for vulnerabilities and misconfigurations, and detect and respond to attacks across container and cloud environments.\nGain visibility into all cloud identities and their privileges: get a comprehensive view into access permissions across all AWS users and services Enforce least privilege: eliminate excessive permissions by applying least-privilege policies to users and services with automatically generated IAM policies. Sysdig proposes policies based on analyzing which entitlements are granted versus which are actually used. Simplify audit of access controls to meet compliance requirements: use reports for regular access reviews to evaluate active and inactive user permissions and activity. Additional Information:\nDocumentation: Permissions and Entitlements. Watch: Remediating Excessive IAM permissions in less than 2 minutes with Sysdig Secure Blog: Cloud Infrastructure Entitlements Management (CIEM) with Sysdig Secure Learn more about Sysdig CIEM capabilities • https://sysdig.com/use-cases/ciem-cloud-infrastructure-entitlements-management/) October 26, 2021New Secure Event Forwarder Integrations: Google Chronicle, Google Pub/Sub \u0026amp; Amazon SQSAn extended set of output data integrations has been added to Sysdig Secure\u0026rsquo;s Event Forwarder functionality, in particular:\nIntegration with Google Chronicle. NOTE: Only Runtime policy events are available as data to send at this moment. Integration with Google Pub/Sub and Amazon SQS, which can be used as temporary storage that will adapt the EFO push behaviour into a data pull endpoint. See also:\nForwarding to Google PubSub Forwarding to Google Chronicle Forwarding to Amazon SQS October 25, 2021Sysdig Secure for GCPSysdig is pleased to announce the general availability of the Sysdig Secure for cloud capabilities for GCP.\nCloud Security Posture Management (CSPM): Based on CIS benchmarks tailored for your assets Cloud Threat Detection: Identify threats in your GCP environment using Falco rules for GCP Audit Logs: Google Security Command Center integration to forward threats identified by Falco rules. Image Vulnerability Scanning: Automatic vulnerability scanning of images pushed to Google Container Registry, Google Artifact Registry and images executed on Google Cloud Run. Chronicle Integration: Events forwarding to Google Chronicle. Installation via GCP Marketplace: You can install Sysdig from the GCP marketplace and pay using the payment method and credit of your GCP account. See full details: Sysdig Secure for Cloud and Deploy Sysdig Secure for cloud on GCP.\nOctober 13, 2021New Scanning Engine (Technology Preview)Sysdig Secure is developing a new scanning engine that will deliver major improvements, additional capabilities, and scanning-centric workflows.\nThe first iteration is available to test and provides:\nMuch faster scan times: 4x to 10x faster initial image analysis Extended vulnerability data, including CVSS scores, vectors containing the full exploitability data, availability of an associated public exploit, etc. Inline scanner available as a stand-alone binary, no longer requires spawning a container Better remediation advice, including \u0026lsquo;Which packages are the worst offenders in my image? Considering all the possible fix versions, which one should I apply?\u0026rsquo; Improved, more intuitive user experience, with faster response times Important: The new engine is still on \u0026ldquo;Preview\u0026rdquo; phase.\nThis means:\nNot suitable for production. There is no forward compatibility guarantee for the data or configuration (yet) Testing the new scanning preview will NOT affect any existing scanning workflows that leverage the current scanning backend. It is safe to enable the preview on any account. Additional fundamental components are still in development; they will be released in an upcoming version. To test the new engine, simply enable the flag under Settings \u0026gt;User Profile\u0026gt;Sysdig Labs.\nSee New Scanning Engine to download the Inline Scanner binary and begin.\nSeptember 17, 2021Date Columns Added for Scheduled Scanning ReportsIn Sysdig Secure, the Scheduled Reports for Scanning now display additional vulnerability metadata for both runtime and registry reports.\nSpecifically:\nDisclosure date: Time when the vulnerability information was registered in the feed Solution date: Time when the fix version for this vulnerability (if any) was registered in the feed To avoid breaking compatibility with existing reports and external instrumentation, these fields will only be available for newly created reports; existing Scheduled reports (even if they are modified and saved again) will not contain these columns.\nSeptember 8, 2021New and Updated Compliance StandardsSysdig Secure has added three new compliance standards and updated another. See also: Compliance\nUpdates to PCI DSS v3.2.1 Compliance for WorkloadWe have implemented some changes to the PCI DSS v3.2.1 for workload compliance checks. The control coverage for PCI is now: 1.1.2, 1.1.3, 1.1.5, 1.1.6.b, 2.2, 2.2.a, 2.2.1, 2.2.2, 2.4, 2.6, 4.1, 6.1, 6.2, 6.4.2, 6.5.1, 6.5.6, 6.5.8, 7.2.3, 10.1, 10.2, 10.2.1, 10.2.5, 10.2.7, 10.5.5, 11.5.1\nChecks added:\nCheck for Network Security enabled added to controls 1.1.2, 1.1.3 and 1.1.5\nCheck for Kubernetes audit enabled added to controls 4.1, 6.4.2 and 6.5.8\nRules added:\nRule Outbound or Inbound Traffic not to Authorized Server Process and Port added to control 2.2.1\nRule Attach to cluster-admin Role added to controls 7.2.3 and 10.5.5\nRules EphemeralContainers Created and Terminal shell in containeradded to controls 10.1 and 10.2.1\nRules ClusterRole With Pod Exec Created , ClusterRole With Wildcard Created and ClusterRole With Write Privileges Created added to control 10.2\nRule Launch Privileged Container added to control 10.2.5\nRules Container Drift Detected (chmod) and Container Drift Detected (open+create) added to control 11.5.1\nRules removed:\nRule All K8s Audit Events rule removed from controls 10.1, 10.2, 10.2.1, 10.2.7 New PCI DSS v3.2.1 Compliance for AWSThe PCI Quick Reference describes the full range of controls required to pass a PCI 3.2 audit. In this release, Sysdig Secure will add the following controls.\nFor AWS protection: 2.2, 2.2.2, 10.1, 10.2.1, 10.2.2, 10.2.5, 10.2.6, 10.2.7, 10.5.5, 11.4\nNew AWS Well Architected Framework ComplianceThe AWS Well Architected Framework whitepaper defines best practices to build secure, high-performing, resilient, and efficient infrastructure for applications and workloads.\nFor workload protection, Sysdig Secure will check the following sections: OPS 4, OPS 5, OPS 6, OPS 7, OPS 8, SEC 1, SEC 5, SEC 6, SEC 7, REL 2, REL 4, REL 5, REL 6, REL 10, PERF 5, PERF 6, PERF 7\nFor AWS protection, Sysdig Secure will check the following sectionsOPS 6, SEC 1, SEC 2, SEC 3, SEC 8, SEC 9, REL 2, REL 9, REL 10\nNew AWS Foundational Security Best Practices v1 (FSBP) ComplianceAWS Foundational Security Best Practices v1 (FSBP) describes the full range of controls to detect when your deployed accounts and resources deviate from security best practices.\nFor AWS protection, Sysdig Secure will check the following sections: AutoScaling.1, CloudTrail.1, Config.1, EC2.6, CloudTrail.2, DMS.1, EC2.1, EC2.2, EC2.3, ES.1, IAM.1, IAM.2, IAM.4, IAM.5, IAM.6, IAM.7, Lambda.2, GuardDuty.1\nNew NIST 800-171 rev2 ComplianceThe National Institute of Standards and Technology (NIST) Special Publication 800-171 rev2 describes the full range of controls required to pass a NIST 800-171 audit. It provides agencies with recommended security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when the information is resident in nonfederal systems and organizations.\nFor workload protection, Sysdig Secure will check the following sections:3.1.1, 3.1.2, 3.1.3, 3.1.5, 3.1.6, 3.1.7, 3.1.12, 3.1.13, 3.1.14, 3.1.15, 3.1.16, 3.1.17, 3.1.20, 3.3.1, 3.3.2, 3.3.5, 3.3.8, 3.3.9, 3.4.3, 3.4.5, 3.4.6, 3.4.7, 3.4.9, 3.5.1, 3.5.2, 3.11.2, 3.12.1, 3.13.1, 3.13.2, 3.13.3, 3.13.4, 3.13.5, 3.13.6, 3.13.8, 3.14.1, 3.14.2, 3.14.3, 3.14.4, 3.14.5, 3.14.6, 3.14.7\nFor AWS protection, Sysdig Secure will check the following sections:3.1.1, 3.1.2, 3.1.3, 3.3.1, 3.3.2, 3.3.7, 3.5.7, 3.5.8, 3.14.6, 3.14.7\nSeptember 2, 2021New Terraform Onboarding Options for Secure for cloudUsers can now onboard Sysdig Secure for cloud with their AWS accounts (single or organizational) using Terraform. See the feature description and the deployment/onboarding instructions.\nAugust 12, 2021Inline Scanner 2.4.6 ReleasedVersion 2.4.6 of the inline scanner container has been released. See also: Integrate with CI/CD Tools.\nFeature:\nAdded support for images with the (deprecated) manifest schema V1 July 30, 2021Inline Scanner 2.4.5 releasedVersion 2.4.5 of the inline scanner container has been released. See also: Integrate with CI/CD Tools.\nFix:\nFixed an edge case in which using the --verbose flag with --format json caused a corrupted JSON output July 28, 2021Inline Scanner v2.4.4 ReleasedVersion 2.4.4of the inline scanner container has been released. See also: Integrate with CI/CD Tools.\nFixes:\nBumped ClamAV version to latest (0.103.3).\nUpdated base image to get updated security fixes (July 2021)\nAdded retry mechanism when pulling images from registries\nAdded --write-json PATH option to permit storing json log to file\nFixed Malware scan fails when image has not read the permissions on files\nFixed failure in getting images for registries that do not support tag listing\nJuly 27, 2021Admission Controller with Kubernetes Audit (k8s_auditFalco rules)Today we announce the general availability of the Kubernetes Audit functionality as part of the Sysdig Secure Admission Controller.\nBackground:\nKubernetes admission controllers provide operators the ability to validate and/or mutate incoming API requests. Admission controllers are a core functionality of Kubernetes, and many are enabled by default.\nSysdig Secure has long provided Kubernetes API security using k8s_audit Falco rules to create policies against Kubernetes audit logs. However, there have been some complications:\nDiverse setup requirements:\nMany Kubernetes distros are opinionated in the way to collect and access logs, some using dynamic backends (deprecated in Kubernetes 1.19, but still available in OCP up to 4.3), while more vanilla approaches use webhooks, and cloud providers require a bridge to collect logs via their own logging streams.\nDistros diverging from Falco:\nWith OCP 4.4+, we had no clear way to collect and validate audit logs against our Falco rules.\nThe Solution?\nTap directly in the Kubernetes API request via Admission Controllers and use the existing k8s_audit rules our customers have relied on for so long. See the installation instructions.\nJuly 2, 2021Inline Scanner 2.4.3 ReleasedChange:\nUpdated base image to get updated security fixes (June 2021). Fixed:\nFixed incorrect version detection for Apache Struts 2 packages which was leading to false positives. July 1, 2021Node Image Analyzer v0.1.13 ReleasedVersion 0.1.13 of the Node Image Analyzer has been released.\nThis release comes with the following improvements:\nFixed:\nFixed a GKE- and ContainerID-specific bug where the node image analyzer couldn\u0026rsquo;t scan the image due to missing blobs\nImplemented a few-second pause at startup to allow for Istio sidecars to complete the initialization before creating connections\nNew\nWe use the Universal Base Image (UBI) Sysdig-approved image as the base, in order to ensure the highest patch level approved by our security team. June 23, 2021Enhancements to Compliance Module Terminology note: Compliance standards are scoped to different platforms depending on the specific security rules they include, Broadly, these are divided into:\nWorkload types: Including any Falco rules for kernel system calls, Falco rules for Kubernetes audit logs, host benchmarks, and security features that affect hosts, containers, and kubernetes clusters\nAWS/cloud type: Falco rules for CloudTrail and Cloud Custodian rules on Amazon Web Services\nSee also: Compliance.\nExtended Existing Compliance Standards to AWSFor the following existing compliance standards, we have added rules for AWS cloud provider:\nNIST 800-53 rev4 for AWS\nNIST 800-53 rev5 for AWS\nISO 27001:2013 for AWS\nSOC2 for AWS\nHIPAA for AWS\nAdded New Compliance StandardsWe have also added the following new compliance standards to Sysdig Secure\u0026rsquo;s offerings:\nGDPR for AWS\nGDPR for workload\nNIST 800-190 for workload\nTrimmed Excess Rules from Some StandardsCertain rules have been re-evaluated and were removed because they did not significantly contribute to the security posture:\nLogged in without Using MFA (merged with Console Login Without MFA)\nInterpreted procs outbound network activity\nLaunch Suspicious Network Tool in Container\nAll K8s Audit Events\nJune 14, 2021CIS RedHat OpenShift Container Platform v4 BenchmarkSupport for CIS RedHat OpenShift Container Platform v4 Benchmark has been added to Sysdig Secure.\nAs part of this release Sysdig is allowing you to scan and validate compliance with 112 controls included in the CIS Bencmark requirements.\nSee also: Benchmarks\nJune 9, 2021Sysdig Secure UX Improvements: \u0026ldquo;Investigate\u0026rdquo; Navigation \u0026amp; Activity AuditMenu NavigationSysdig navigation just got a facelift. To help our Sysdig Secure users navigate easily, we:\nAdded the new menu item Network (previously found under the Policies menu), and\nGrouped Activity Audit + Captures into Investigation to better describe the use-case it helps users resolve.\nActivity AuditThe Activity Audit module also got several interface and user experience improvements:\nRuntime scope moved to the top to align with other Secure interfaces and allow more space for activity data\nActivity types (network, file, kubectl, command) can now be filtered directly from the graph using the legend\nAttributes of the displayed elements can be filtered directly from the list, without displaying the side detail panel\nJune 4, 2021Kubernetes Network Security: New Configuration and Improved User ExperienceSysdig\u0026rsquo;s Kubernetes Network Policy tool has been updated to include additional fine-tuning configurations and an improved user experience.\nAdditional Configuration Panel Workload Labels: Depending on your workload labelling policy, some labels may not be relevant for generating a KNP policy. Use the additional config to include/exclude a particular set of labels per cluster/namespace to declutter your UI and the resulting policy.\nUnresolved IP Configuration: Now it is possible to label raw IPs that are not mapping to your Kubernetes/OpenShift entities, i.e. external cloud provider services, so these labels will be automatically applied to the topology and ingress / egress tables.\nCluster CIDR configuration: If the CIDR configuration is not automatically detected by the agent, you can now directly configure internal subnets per cluster using the Sysdig interface.\nImproved UX Topology map: Additional information pop-up when hovering over a network connection or a network node, such as server process, source, destination, and more.\nUnresolved IP filtering: In the ingress and egress tables, by type or using free text search.\nAdditionally, Network is now presented as a top-level item in the Sysdig Secure navigation.\nMay 27, 2021Falco Policy Tuner - BetaSysdig is now releasing a managed version of the standalone Falco Tuner.\nPreviously, you had to run the tuner in your local environment, print suggestions, and manually update a rule with those suggestions. The new feature runs in the background and automatically tunes noisy rules and false positives. To streamline the creation of these exceptions, we\u0026rsquo;ve created a new object within Falco called exceptions.\nNote: To enable the tuner, Admin access rights to Sysdig Secure are required.\nFeature Enhancement: Falco ExceptionsPreviously, exceptions were created using and not conditions inside a Falco rule, e.g.\n- rule: Write below binary dir ... condition: \u0026gt; bin_dir and evt.dir = \u0026lt; and open_write and not package_mgmt_procs and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not user_known_write_below_binary_dir_activities .... However, this process can be unwieldy and can result in unintended behavior. The new format, using exceptions, looks like this:\n- rule: Write below binary dir ... condition: bin_dir and evt.dir = \u0026lt; and open_write .... exceptions: - name: package_mgmt_procs fields: proc.name comps: in values: package_mgmt_binaries # list of known binaries ... See the full documentation here.\nMay 19, 2021Regulatory Compliance for ISO27001:2013 and HIPAA Now AvailableTwo new compliance standards have been added to Sysdig Secure\u0026rsquo;s compliance feature:\nISO27001:2013\nHIPAA (Health Insurance Portability and Accountability Act)\nSee also:Compliance for information about the specific controls Sysdig covers for each security standard.\nInline Scanner v2.4.1 ReleasedVersion 2.4.1 of the inline scanner container has been released. See also: Integrate with CI/CD Tools.\nFixes:\nUpdated ClamAV version to 0.103.2 to avoid end-of-life problems present in the former version, such as failure in updating the antivirus database Additional type Descriptor Forwarding Activity Audit through Event ForwarderThe JSON payload when sending Activity Audit elements through the Event Forwarder will now contain an additional field name: type. This describes the type of the entry, respectively: command, connection, fileaccess, or kubernetes.\nSee also: Event Forwarding.\nMay 18, 2021New and Improved Host OS and Container Scanning ToolsWe at Sysdig are working hard to improve your security posture and compliance experience. As part of this commitment we are implementing a new framework to generate host benchmark results, introducing host scanning, and making backend improvements to the image scanning mechanism.\nInstallation StepsThe new features require a new component to be installed called the Node Analyzer. We\u0026rsquo;ve provided an installation script to automate the installation or to upgrade an existing Node Image Analyzer daemonset, if applicable.\nOnce you\u0026rsquo;ve installed or updated the components, the UI will automatically show Host Scanning and new Benchmarks functionality (Legacy Benchmarkscan still be accessed.)\nHost Scanning: NewIn addition to Sysdig Secure\u0026rsquo;s rich array of tools for scanning container images, you can now scan the hosts as well.\nScan hosts for vulnerabilities, and detailed Software Bill of Materials (SBoM)\nSupport for OS (e.g. rpm) and non-OS (e.g. Java, Ruby, Python) packages\nCompare and diff scan results\nHost Benchmarks: Updated More checks\nBetter results\nClustered aggregations - understand the posture of your environments, not just a single entity\nImage Scanning: Updated Automatically scan images if they have not been scanned April 29, 2021New Scan Results Page LayoutWe have reorganized the visual layout of the Scan Results summaries to clearly distinguish policy evaluation from vulnerability matching and to better summarize the information.\nImprovements include:\nVulnerabilities and Policies are now two different sections in the UI\nVulnerability match update time is displayed to further distinguish from the Policy Evaluation time\nPolicy breakdown is collapsed by default to reduce cognitive load\nRe-evaluate policies button is now located in the impacted section only, as opposed to whole page\nApart from the vulnerability update time, the data remains unchanged from previous versions\nSee also: Review Scan Results.\nApril 26, 2021Inline Scanner v2.4.0 ReleasedVersion 2.4.0 of the inline scanner container has been released. See also: Integrate with CI/CD Tools.\nChanges:\nUpdated base image to get updated security fixes. New\nAdded HTTP_PROXYand HTTPS_PROXY environment variables support for malware scanning mode. This is required if you want to retrieve the malware database inline behind a proxy.\nAdded support for.dockercfgrepository auth method, accessible via the--registry-auth-dockercfgCLI flag.\nFixes:\nNow using HTTP1.1 by default to bypass a cURL bug.\nProvided fix for an error when using the docker-daemon storage type with a docker UID different than 1000.\nMarch 30, 2021Sysdig Secure for cloudSysdig Secure for cloudis available with Cloud Risk Insights for AWS, Cloud Security Posture Management based on Cloud Custodian for AWS and multi-cloud threat detection for AWS using Falco.\nWhat\u0026rsquo;s Included in this release:\nInsights: a powerful new visualization tool for threat detection, investigation, and risk prioritization, to help identify compliance anomalies and ongoing threats to your environment. With Insights, all findings generated by Sysdig across both workload and cloud environments are aggregated into a visual platform that streamlines threat detection and forensic analysis.\nThreat Detection based on AWS CloudTrail: To detect threats, anomalies and suspicious activities with the flexible Falco engine. See also: Sept 29, 2020.\nCloud Security Posture Management with AWS Benchmarks: The AWS CIS Benchmarks assessment evaluates your AWS services against the benchmark requirements and returns the results and remediation activities you need to fix misconfigurations in your cloud environment.\nWe\u0026rsquo;ve included several UI improvements to provide additional details such as: control descriptions, affected resources, failing assets, and guided remediation steps, both manual and CLI-based.\nImage Scanning for ECR and Fargate: one-click deployment \u0026ndash; see also ECR April 13, 2020 and Fargate Sept. 28, 2020.\nFree-Forever Cloud Security TierSysdig is launching a new Free-forever cloud security tier for one single account.\nhttps://sysdig.com/company/start-free/\nEasy onboarding in minutes\nManage cloud posture with a daily run of CIS Benchmarks\nDetect threats with out-of-the-box CloudTrail detection rules based on Falco\nScan containers (ECR/Fargate scanning) automatically and within your cloud environment for upto 250 images a month\nMarch 24, 2021Image Scanning Reports v3 [BETA]The Image Scanning Reports feature has been thoroughly updated and has moved from a synchronous model to an asynchronous mode, in which you schedule the reports you need and then receive them through your normal notification channels (email, Slack, webhook.). The new version also includes:\nA preview function to check report structure in the UI\nA more advanced query builder\nExtended set of data columns (i.e. CVSS base score and vector) and extended set of available filters (i.e. package type)\nReporting v3 supports two different types or reports:\nVulnerability report: Containing vulnerability, package and image data\nI.e. Vulnerabilities in my runtime with Severity ≥ High, a Fix available and not included in a vuln exception list.\nPolicy report: Containing scanning policies and evaluated images data\nI.e. Images in my internal registry failing the \u0026ldquo;NIST\u0026rdquo; scanning policy.\nYou need to enable this feature from the Sysdig Labs setting on the User Profile page.\nSee Scheduled Reports for more detail.\nMarch 22, 2021Feature Enhancement: Falco Policy TypesSysdig Secure has introduced Policy Types\u0026ndash; a separation of policies into logical groups, based on the sources used in the policy engine. When creating a policy, you choose a type and then only the relevant scopes and container actions will be presented.\nWe have also introduced a new policy type to support threat detection with AWS CloudTrail rules.\nMarch 17, 2021Scan Results: UX Enhancements \u0026amp; Added FunctionalityScan Results List\nSummarized views based on image count, image fail / pass distribution and image origin distribution.\nRegistry filter dropdown, multi-select\nVisible image counters: Images shown in the page vs total number of images available after applying filters\nVisual charts: Pass/fail and origin distribution (also respecting filters)\nVulnerability List:\nNew table design to offer additional visual feedback and reduce data redundancy, plus additional vulnerability data.\nNew functionality:\nIndividual vulnerabilities can now be clicked to display additional information in a side panel:\nThe vulnerability feed source that was used for the matching\nA description of the vulnerability\nMarch 15, 2021Sysdig Serverless Agent 1.0.0 for Fargate ECSThe \u0026ldquo;container-as-a-service\u0026rdquo; serverless environment calls for new agent models, and Sysdig provides them. Whereas in ECS, users still manage the underlying instances, with AWS Fargate the host is never visible and users simply run their workloads. And while this model is convenient, it can introduce risk as many people leave the containers unattended, without monitoring security events within that can exfiltrate secrets, compromise business data, impact performance, and increase their AWS costs. In addition, it is not possible to install a standard agent in an environment where you do not have access to a host.\nFor these reasons, Sysdig has introduced a new \u0026ldquo;serverless agent\u0026rdquo; model that can be deployed in these container-based cloud environments. The first implementation is for Fargate (ECS).\nSysdig will be rolling out security features on the serverless agent over time. In v1.0.0, users will see:\nRuntime Policies and Rules\nSecure Events\nTo obtain secure event information and the associated Falco policies and rules in the Sysdig Secure UI from a Fargate environment, users install the serverless agent using a CloudFormation Template. Then log in to Sysdig Secure and review the events in the UI.\nSee also: AWS Fargate Serverless Agents and Serverless Agent Release Notes (for future updates).\nMarch 12, 2021Deprecation Notice: Legacy Commands Audit \u0026amp; Legacy Policy events The Commands Audit feature was deprecated in favor of Activity Audit in November 2019. This feature will be completely removed from the SaaS product April 2021.\nSysdig agent version 0.93+, released in November 2019, is required by the Activity Audit feature.\nThe \u0026ldquo;Policy Events\u0026rdquo; feature was deprecated in favor of the new Events feed in June 2020. This feature will be completely removed from the SaaS product April 2021.\nSysdig agent version 10.3.0+ is recommended.\nUI Improvement on Rules Library and Rule DetailsUsability improvements that display the policies in which a rule is used, from both the Rules Library list and the Rule Detail view. See Manage Rules for details.\nMarch 2, 2021Regulatory Compliance for SOC 2, NIST 800-53 rev4 and rev5Three new compliance standards have been added to Sysdig compliance feature: SOC 2, NIST 800-53 rev4 and NIST 800-53 rev5.\nThe compliance validator now also includes new checks for the following features: Admission Controller, Network Security Policies and Node Analyzer.\nSee the Compliance documentation for usage details and the controls implemented.\nFebruary 23, 2021Windows Scanning ReleasedA beta version of the Windows Scanning Inspector has been released. This is a new feature from Sysdig for scanning Windows containers.\nThis is a standalone scanning engine. There is no centralized UI, management, or historical data. These features are planned for a future release.\nSee also: Windows Container Image Scanning [BETA].\nFeatures Identify Windows container image vulnerabilities from:\nWindows OS CVEs Windows or Linux hosts\nReports in JSON and PDF\nPolicy support\nSeverity\nFix available\nDays since fixed\nUI-Based Admission Controller ReleasedKubernetes\u0026rsquo; admission controllers help you define and customize which requests are allowed on your cluster. An admission controller intercepts and processes requests to the Kubernetes API prior to persistence of the object, but after the request is authenticated and authorized.\nSysdig\u0026rsquo;s Admission Controller (UI-based) builds upon Kubernetes and enhances the capacity of the image scanner to check images for Common Vulnerabilities and Exposures (CVEs), misconfigurations, outdated images, etc., elevating the scan policies from detection to actual prevention. Container images that do not fulfill the configured admission policies will be rejected from the cluster before being assigned to a node and allowed to run.\nSee also: Admission Controller.\nMain Features Granular admission policies: Defining a global policy per cluster, but also at the level of particular namespaces or image paths (i.e. registries) Registry and repository whitelist\nOnly allow images that pass the scanning evaluation criteria\nOnly allow images that have been evaluated recently\nOnly allow images that have been scanned before creation is requested to Kubernetes\nRegistry and repository whitelist\nScan unscanned requested images immediately (optional)\nFebruary 20, 2021Network Micro-Segmentation: Support for CronJobs, Weave, \u0026amp; Cilium CNIsThe Sysdig Network Security Policy Tool has been upgraded to add support for CronJob pod Owners.\nWith the addition of CronJob support, communication is aggregated to the CronJob (scheduler) level, rather than the Job. Therefore, when administrators review the activity in the Network Security Policy menu, they will see the higher-level CronJobs listed, and not an excess number of individual Job entries.\nThis update also adds support for Weave and Cilium CNIs on top of Calico support.\nMalware Detection during Inline Image AnalysisAs part of the inline scanner version 2.3.1 release, malware scanning was added as a configurable detection that can be performed during inline analysis.\nThe default behavior if this feature is enabled and malware is found is to consider the scanning failed, report malware details, and abort analysis:\nSee Perform Inline Malware Scanning for recommended parameters and output options.\nFebruary 16, 2021Registry Credentials: Support for Multiple CredentialsSysdig Secure now supports assigning multiple credentials to the same registry depending on the relative internal registry path that is used to pull the image.\nA wildcard can be added to the end of the path, indicating that any image located under the partial path inside the registry (/rg-2-1er in the example) will use the registry credentials configured here. This additional flexibility is useful, for example, for IBM registries which can have a different set of permissions depending on the namespace.\nSee also: Manage Registry Credentials.\nFebruary 10, 2021Inline Scanner v2.3 ReleasedVersion 2.3 of the Inline Scanner has been released.\nFixes:\nAvoid prefixing the image names with localbuild when not strictly necessary New:\nImproved version detection for specific software packages: logback, SpringFramework and Tomcat Java\nAllow setting of openssl security level via OPENSSL_SECLEVEL env var to support old certificates\nMore robust image ID identifier, avoiding unnecessary image re-scans along the container lifecycle\nAdded malware detection feature\nFebruary 4, 2021Enhanced Activity Audit FiltersWe have improved the noise-reduction filter for the Activity Auditfeature in Sysdig Secure. The feed will now automatically filter out duplicate entries with a high number of occurrences. No information is lost, as the filtered noise is only duplications of entries in the feed.\nA sudden reduction in the number of Activity Audit entries per time slot is expected as a result of this filter.\nJanuary 28, 2021Node Image Analyzer v0.1.9 ReleasedVersion 0.1.9 of the Node Image Analyzer has been released.\nThis release comes with the following improvements:\nFixes:\nFixed an issue that prevented some images from being processed on GKE clusters using Docker and Containerd\nFixed an issue that prevented some images that don\u0026rsquo;t have full tags from being processed on OpenShift\nImproved version detection for Logback, SpringFramework and Tomcat Java packages\nFixed an issue that resulted in the image analyzer crashing without a proper error message when an incorrect Docker socket path was provided\nNew:\nAdded support for running the Node Image Analyzer in non-Kubernetes environments. ","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/2021-archive/"},{"id":117,"title":"Monitor SaaS Release Notes 2022","content":"December 12, 2022Integrate with Azure Cloud MetricsSysdig now supports Azure Cloud Metrics. Sysdig Monitor now can ingest metrics directly from Azure, allowing you to fully integrate all your existing Azure service metrics into Sysdig Monitor. For more information, see Azure Account\nIf you wish to monitor Azure Resource Quotas, you must manually enable that feature by using the Sysdig API (until this option is available in the Cloud Metrics Integrations UI. To learn about enabling pulling Azure Resource Quotas in your Sysdig Monitor account, see Monitor Azure Resource Quotas.\nAWS Lambda Telemetry API Support for Sysdig MonitorSysdig has rolled out preview availability of the new Sysdig Monitor Lambda Extension for AWS Lambda Telemetry API. This new Lambda extension allows Sysdig Monitor users to consume metrics directly from Lambda events as functions are executed, bypassing the need to route Lambda metrics through another platform such as AWS CloudWatch.\nThe normal way Lambda users receive function metrics is by connecting Lambda to AWS CloudWatch. The Sysdig Monitor users can then consume the pre-configured metrics from Lambda using the CloudWatch API/Streams integration but with a certain latency CloudWatch routing entails and collecting the extra metrics which may not be necessary. With the Sysdig Monitor Lambda Extension for AWS Lambda Telemetry API, you can consume the most critical function execution metrics with an up to 85% reduction is metrics ingestion latency.\nFor more information, see AWS Lambda.\nPromQL Query InspectorQuery Inspector helps you understand the underlying causes of a No Data message in Dashboards. For more information, see Query Inspector.\nSupport for New KSM MetricsSysdig Monitor supports the following:\nKSM ingress metrics\nkube_ingress_info kube_ingress_labels kube_ingress_created kube_ingress_path kube_ingress_tls KSM certificate signing request metrics\nkube_certificatesigningrequest_created kube_certificatesigningrequest_condition kube_certificatesigningrequest_labels kube_certificatesigningrequest_cert_length Taint metrics\nkube_node_spec_taint Monitoring IntegrationsIntegrations Added the following integrations:\nAWS Lambda AWS MetricsStream CloudFront Azure API Management Azure Synapse Analytics Azure AKS Azure Cluster AutoScaler Azure Blob Storage Azure Files Azure Queue Storage Azure SQL Azure Storage Accounts Azure Table Storage Dashboards and Alerts Added a new alert to Redis to test lack of data alerts. Add a new alert to detect exporter down in alerts templates Removed deprecated storage metrics from alerts library The Event Feed now displays tags associated with Custom Events Richer Query Syntax for EventsQueries in the Event Feed and Event Overlay now support a richer query syntax.\nNovember 08, 2022New AdvisoriesThe following new Advisories have been introduced:\nCluster pod capacity - cluster is reaching pod capacity, when this happens new pods cannot be scheduled. Replicas unavailable - a workload has unavailable replicas which can affect app availability Cluster CPU overcommitment - cluster is overcommitting CPU which may affect availability Cluster memory overcommitment - cluster is overcommitting memory which may affect availability Filtering AWS Cloudwatch Metric StreamsSysdig now provides you the ability to filter (drop) metrics that are coming from AWS CloudWatch Metric Streams via Kinesis Firehose, providing our AWS users full control over what metrics are coming from Streams are ingested and stored by Sysdig Monitor. AWS currently does not offer the ability to filter CloudWatch Streams metrics that are pushed to an endpoint like Sysdig Monitor. With CloudWatch Steams Metrics Filtering, you can now choose to only ingest and store the metrics that are important for you, on a per-service basis, thereby, reducing the data storage cost. You can include or exclude specific metrics from individual AWS namespaces as they are ingested.\nDashboard Enhancements Minimum Interval for PromQL Queries: You can now define a minimum interval for PromQL Queries, which is handy when working with scarce metrics. For more information, see Define Minimum Interval for PromQL Queries. Bulk Delete Dashboards: Dashboard Manager now gives you the ability to bulk delete dashboards. see Dashboard Manager. Alert EnhancementsWhen a metric stops reporting data, you now have the option to ignore or notify on the notification channel associated with the alert threshold.\nNotification ChannelsSysdig now allows you to refine which sections are used when sending a Slack notifications. See Customize Notifications.\nMonitoring IntegrationsIntegrations Added the following integrations:\nOpenShift 4 Scheduler OpenShift 4 Controller Manager OpenShift 4 API Server OpenShift 4 Kubelet Azure Virtual Machines Azure Virtual Machine Scale Sets Enable OpenShift CoreDNS job\nAdd support for OpenShift in Fluentd integration\nUpdate the postgresql-exporter and elasticsearch-exporter images with critical vulnerability fixes\nDashboards and Alerts Added openshift-api scopes in OpenShift v4 API Server Dashboard Added the minimum interval option in AWS MetricsStream dashboard templates September 29, 2022Mapping IdP Groups to Roles and TeamsThe IdP (Identity Provider) integration has been improved by supporting the ability to map groups to roles and teams.\nIdP group can be mapped to a single role and one or more teams Only team users can be mapped. No support for admin users at the moment. SAML 2.0 is supported For more information, see Group Mappings.\nSAML Single LogoutSAML single logout, the facility to terminate multiple Sysdig user sessions simultaneously, is now available on all the regions. Furthermore, Sysdig now supports Okta for SAML single logout in federated authentication environments.\nCase Sensitive Labels in PromQL QueriesTo comply with PromQL specification for filtration expressions, label names in PromQL filtering expressions in Sysdig Monitor will be case sensitive. If the casing of a filtering label is incorrect, the query will return an empty response.\nAs majority of PromQL queries were crafted using auto-complete for existing label names, changes to the label casing will not have a major impact. However, there could be rare cases where auto-complete is ignored or PromQL queries are crafted via API, which should be reviewed to make sure casing is correct.\nFor example:\nIf the given label name is ‘host_hostname’, and you want to match the time series of the ‘sysdig_host_cpu_used_percent’ metric to the host ‘foo’, the correct query would be:\nsysdig_host_cpu_used_percent{host_hostname='foo'}\nPreviously, both the following queries returned results.\nsysdig_host_cpu_used_percent{HOST_hostname=\u0026#39;foo\u0026#39;} sysdig_host_cpu_used_percent{HoSt_HoStNamE=‘foo\u0026#39;} The following are unimpacted by this change:\nThe alert and dashboard queries created by using the Form UI\nLabel values\nLabel values are already case sensitive in Sysdig Monitor.\nGoogle Chat IntegrationYou can now use Google Chat as a notification channel in Sysdig Monitor. See Configure a Google Chat Channel for more details.\nStacked BarsTimechart panels support creating statcked bar charts. For more information, see Timechart.\nMonitoring IntegrationsRename Dashboard Templates to Dashboard LibraryIn order to align with the rest of Monitor, Dashboard Templates has been renamed to Dashboard Library.\nIntegrations Added the following integrations:\nOpenShift API Server OpenShift 4 CoreDNS OpenShift 4 etcd Calico Cassandra Split the k8s-control-plane integration to different integrations per application\nImproved the Troubleshooting guide by removing scope from the promQL queries.\nDashboards and Alerts Added OpenShift v4 API Server dashboard including the openshift-api scopes Made Etcd and CoreDNS dashboards compatible with Kubernetes and OpenShift v4 (both OKD and ROKS) Changed the AWS Metrics ECS MetricStream template to include ECS in the name Promcat.io Updated Cassandra integration details with JMX exporter August 17, 2022New Permission for Changing Team RolesTeam management has been improved with the addition of the new permission, Team Membership Roles. This new permission will allow you to change the roles of team members separately while adding users to the teams.\nFor more information, see:\nCustom Roles and Privileges Add and Configure Team Members August 08, 2022AdvisorAccelerate Troubleshooting by Up to 10x with AdvisoriesAdvisories evaluate the thousands of data points being collected by the Sysdig agent, and displays a prioritized view of key problems in your infrastructure that affect the health and availability of your clusters and the workloads running on them.\nSee Sysdig Advisor: Making Kubernetes troubleshooting effortless on the Sysdig blog.\nEntire Infrastructure OverviewEntire Infrastructure shows an aggregated view of all Advisories, active alerts, events, and a quick snapshot of the state of your Kubernetes infrastructure. This is shown before selecting a cluster or workload, and is the new default landing page of the Monitor product.\nDisplay ImprovementsDisplay and representation of data has been improved, including the use of new panel types. Information such as workload availability or resource limits are now displayed as a table instead of a chart.\nDashboard ManagerSysdig introduces Dashboard Manager to organizes all the dashboards associated with your account. The page acts as the repository for all the dashboards that you have created, that your teams have shared with you, and that you have marked as favorite, as well as the dashboard templates available to you.\nFor more information, see Dashboard Manager.\nPrometheus Alertmanager NotificationsYou can now integrate Prometheus Alertmanager as a notification channel in Sysdig Monitor. See Prometheus Alertmanager Notifications for more details.\nContextual TooltipThe Contextual Tooltip has been enhanced to display all segments. To enable this feature, toggle the Contextual Tooltip in Dashboards in the Settings \u0026gt; User Profile screen. The option is found under the Beta Features section.\nEnhanced Label SelectorThe label selector in Dashboards and Metrics Explorer has been enriched with the following sought after features:\nLabel documentation Preview of label values Suggested labels New PromQL VariablesThe following PromQL variables have been added:\n$__interval_sec $__range_sec They are used for translating the rate time aggregation in a Form query into a PromQL query. For example:\navg(sum_over_time(sysdig_container_cpu_used_percent{$__scope}[$__interval])) / $__interval_sec For more information, see Using PromQL.\nEvents Feed EnhancementsThe Events module has been refreshed to show metrics and labels in Prometheus notation.\nMonitoring IntegrationsIntegrations Added the following integrations:\nHAProxy OpenShift integration Istio integration Removed metrics filtering in envoy job in Istio agent configuration. This will allow for collecting other custom metrics merged into the Envoy sidecar.\nEnhanced the OpenShift HAProxy configuration to use ClusterRole\nAdded the following to Promcat.io:\nHAProxy OpenShift 4.7 Istio 1.14 Dashboards and Alerts Enhanced RDS description for PostgreSQL\nEnhanced the calculation of used vs request/limits in Kubernetes Capacity Planning Dashboard\nEnhanced promQL in Kubernetes Dashboards to avoid operations occuring in ephemeral containers\nAdded updated Time Series Usage Dashboard Template to the repository\nRemoved the deprecated \u0026lsquo;OutOfDisk\u0026rsquo; condition on Node Status and Performance Dashboard\nUpdated Kubelet metrics for Kubernetes v1.19 and above in Dashboard Templates\nkubelet_running_container_count to kubelet_running_containers kubelet_running_pod_count to kubelet_running_pods Removed duplicated Dashboard Templates\nExporter Upgraded exporters Jenkinsfile for scratch and ubi images Fixed the error in JMX exporter image. Fixed port information in Memcached exporter scratch image. Added the following Security updates in UBI images of all the exporters: Apache\nquay.io/sysdig/apache-exporter:v0.11.1-ubi\nquay.io/sysdig/apache-exporter:v0.11.1\nElasticsearch\nquay.io/sysdig/elasticsearch-exporter:v1.3.4-ubi\nquay.io/sysdig/elasticsearch-exporter:v1.3.4\nGrok\nquay.io/sysdig/sysdig/grok-exporter:v1.0.4-ubi\nquay.io/sysdig/sysdig/grok-exporter:v1.0.4\nJMX\nquay.io/sysdig/promcat-jmx-exporter:v0.17.3-ubi\nquay.io/sysdig/promcat-jmx-exporter:v0.17.3\nMemcached\nquay.io/sysdig/memcached-exporter:v0.10.2-ubi\nquay.io/sysdig/memcached-exporter:v0.10.2\nMongoDB\nquay.io/sysdig/mongodb-exporter:v0.11.9-ubi\nquay.io/sysdig/mongodb-exporter:v0.11.9\nMySQL\nquay.io/sysdig/mysql-exporter:v0.14.1-ubi\nquay.io/sysdig/mysql-exporter:v0.14.1\nNGINX\nquay.io/sysdig/nginx-exporter:v0.10.1-ubi\nquay.io/sysdig/nginx-exporter:v0.10.1\nNode exporter\nquay.io/sysdig/node-exporter:v1.2.4-ubi\nquay.io/sysdig/node-exporter:v1.2.4\nNTP\nquay.io/sysdig/ntp-exporter:v2.0.4-ubi\nquay.io/sysdig/ntp-exporter:v2.0.4\nPHP-FPM\nquay.io/sysdig/php-fpm-exporter:v2.3.2-ubi\nquay.io/sysdig/php-fpm-exporter:v2.3.2\nPostgreSQL\nquay.io/sysdig/postgresql-exporter:v0.10.8-ubi\nquay.io/sysdig/postgresql-exporter:v0.10.8\nRedis\nquay.io/sysdig/redis-exporter:v1.43.1-ubi\nquay.io/sysdig/redis-exporter:v1.43.1\nJuly 13, 2022Integrate AWS CloudWatch Metric StreamsSysdig has rolled out support for AWS CloudWatch Metric Streams. Based on Kinesis Firehose, AWS CloudWatch Metric Streams is a real-time metrics aggregation and delivery tool for AWS cloud services. Sysdig Monitor now can ingest metrics directly from Kinesis Firehose, allowing you to fully integrate all your existing AWS service metrics into Sysdig Monitor. Configuring AWS CloudWatch Metric Streams to send metrics to Sysdig can either be done by using the AWS CloudFormation template available directly on the Monitor UI, by manually deploying the CloudFormation template, or by manually selecting Sysdig as an HTTP receiver through the AWS Kinesis Fire configuration.\nIn addition, we have also released 9 out-of-the-box dashboards and alerts for the following AWS CloudWatch Metric Streams services: AWS ALB AWS EBS AWS ELB AWS Fargate AWS Lamda AWS RDS AWS S3 AWS SQS For other services, custom dashboards and alerts can be configured for all the service metrics coming in from AWS CloudWatch Metric Streams.\nFor more information, see Cloud Integrations.\nJuly 06, 2022Live LogsSysdig introduces Live logs support for Kubernetes in Advisor to help you debug infrastructure problems. Advisor displays live logs for a container, which is the equivalent of running kubectl logs. This strengthens Sysdig Monitor capabilities for troubleshooting, allowing you to debug problems, such as pods in a CrashLoopBackOff state and consolidates tooling, and reducing the need to switch to other tools for troubleshooting and root cause analysis.\nLive logs requires Sysdig agent v12.7.0 or above. For more information, see Live Logs.\nEnhanced Alerts EditorSysdig introduces a new Alert Editor with an improved user experience thanks to a redesigned look and feel. We\u0026rsquo;ve also added the ability to link a dashboard and a runbook to the alert definition to expedite troubleshooting.\nWe are deprecating the existing Anomaly Detection and Group Outlier alert types. Previously created alerts of this type can still be viewed and edited. We will be bringing new alert types in the future.\nThe new Alerts Editor will be available only in environments where the new metric store is enabled. For more information, see Alerts.\nPromQL Panel EnhancementsThe Compare To function is now supported in Timechart and Number PromQL panels.\nMonitoring IntegrationsIntegrations Added the following integrations: HaProxy PHP-fpm Split Kubelet PVC-and-Storage integration into two different integrations, PVC and Storage. Enabled Kubelet-PVC metrics by default. Updated agent jobs for kube-controller-manager and kube-scheduler to support HTTPS and authentication. Added Helm chart for ElasticSearch exporter with CA certificates option. Dashboards and Alerts Added dashboard and alert templates for HAProxy Changed the rules to toggle showing Kubernetes dashboards to prevent hiding when encountering unstable metrics or disconnected agents Fixed waiting time in Portworx alert templates with predict linear functions Fixed used request in the Cluster Capacity Planning dashboard Exporter New exporter image for PHP-FPM: quay.io/sysdig/php-fpm-exporter:v2.3.0 quay.io/sysdig/php-fpm-exporter:v2.3.0-ubi Updated the JMX exporter image quay.io/sysdig/promcat-jmx-exporter:v0.17.0 quay.io/sysdig/promcat-jmx-exporter:v0.17.0-ubi June 7, 2022Enhanced Metric and Label SelectionThe metric and label selectors in Dashboards and Metrics Explorer have been improved to provide easier search and find what you are looking for.\nImprovements include:\nSuggested labels now show only relevant labels for a selected metric. Displays 500 labels by default for a selected metric. Previously it was 50. Supports inline editing of metric and label names. Provides improved search relevancy. Dashboard enhancementsTranslate Form-Query to PromQLYou no longer require advanced Prometheus knowledge to build complex PromQL queries in Sysdig Monitor. With a single click, you can translate form query to PromQL, and build PromQL-based dashboards in no time. For more information, see Build PromQL Panels from Form Query.\nPromQL Support for ToplistToplist panels support running PromQL queries.\nMulti-Query Support for Stacked Area ChartsTimechart now supports visualizing multiple queries as stacked areas in the same y-axis.\nWith this feature, it\u0026rsquo;s easier to visualize and compare sparse metrics.\nLazy Loading of Dashboard PanelsDashboards now supports lazy loading panels. Lazy loading greatly reduces the initial page loading time by only loading panels once they become visible on screen.\nMonitoring IntegrationsIntegrations Added the following integrations:\nFluentd NTP Improved CoreDNS Prometheus job to be detected in IKS clusters\nChanged troubleshooting metrics in some integrations for metrics inside the filter of the Prometheus job\nDashboards and Alerts Added the following templates for dashboard and alert:\nFluentd NTP Changed OOTB K8s dashboards to use \u0026ldquo;is\u0026rdquo; vs \u0026ldquo;in\u0026rdquo; scoping to improve performance.\nChanged the following dashboards:\nCluster/Namespace Available Resources Cluster Capacity Planning Pod Rightsizing \u0026amp; Workload Capacity Optimization Pod Scheduling Troubleshooting Kubernetes HPA Added the containers with limits/requests only in certain panels in the Cluster Capacity Planing dashboard\nLimited the use of the label job to some panels in the Kubernetes CoreDNS dashboard\nExporters Added support for CA files in ElasticSearch exporter Helm chart Removed duplicated securityContext in ElasticSearch exporter Helm chart Changed the ElasticSearch wizard and Helm chart to use secrets for URL of the ElasticSearch server Bumped Helm chart repository version to include NTP exporter and fixes in Elasticsearch The following Exporter images for NTP exporter have been added: quay.io/repository/sysdig/ntp-exporter:v2.0.3 quay.io/repository/sysdig/ntp-exporter:v2.0.3-ubi New version of grok exporter with security updates: quay.io/sysdig/grok-exporter:v1.0.2 quay.io/sysdig/grok-exporter:v1.0.2-ubi May 23, 2022Custom RolesA custom role is an admin-defined role that allows Sysdig administrators to bundle a set of permissions and assign those permissions to individual users or teams. Custom roles allow for finer-grained definition beyond the standard out-of-the-box Sysdig Roles. Once defined, a custom role can be assigned to any user inside a particular team, and also be configured as the default role for new users in that team. For more information, see Custom Roles.\nThe addition of custom roles into the platform is transparent, meaning that standard roles and assignments that already exist will not experience any changes.\nMay 4, 2022Sysdig Platform AuditWe are glad to announce that Sysdig Platform now supports the capability of tracking, logging, and reporting on all changes in the system.\nTrack all activities on the API level Retention period: 90 days Simple API for retrieving audit information (no UI) Events Forwarding support to be included in the near future (to be announced) Enabled by default for all SaaS users See Sysdig Platform Audit for more information.\nSysdig Platform Login BannerWe would like to announce that Sysdig Monitor and Secure now allow you to define a Login Message that will be presented to all users. Added to boost Sysdig compliance/enterprise readiness, requested originally by the IRS.\nUsers are not allowed to access the system until they acknowledge the message One login banner per account Only Admin users can enable/update the message Single banner for both Monitor and Secure (for Platform customers) Available on SaaS for all users See Configure Login Message for more information.\nApril 13, 2022AdvisorAdvisor brings your metrics, alerts, and events into a focused and curated view to help you operate and troubleshoot Kubernetes infrastructure. To help you solve problems faster, over time, Advisor will surface your infrastructure issues that you should pay attention to. For more information, see Advisor.\nMetrics ExplorerMetrics Explorer has been rebuilt from the ground up to focus on advanced metric exploration and querying.\nImprovements to Metrics Explorer include: Simple querying that builds PromQL queries under the hood. Metrics Explorer is the easiest way to build PromQL queries. Graph multiple metrics at once for correlation. For example, CPU usage vs Kubernetes limits. Queries are ungrouped by default, showing the individual time series for a metric. This allows you to spot any problems faster. For example, 1 of 50 Cassandra nodes with high pending compactions. Instead of segmenting, you now group by one or more labels, for example, workload, pod, and container. When selecting a scope in the tree, only those metrics that are applicable to that entity are displayed. Metrics are now more logically categorized by metric namespace (prefix). Resolution has been improved. For example a 1-hour view now shows 10-seconds data. Additionally, the concept of time re-alignment has been removed. For more information, see Explorer.\nFebruary 10, 2022Improved Usability with New NavigationThe Sysdig Monitor UI has been enhanced to provide you with a smoother and smarter left-hand navigation experience.\nCheck out a video walk-through of the new feature!\nCollapsible main menu: Allows you to toggle the visibility of menu options. The collapsible left-hand navigation prevents long lists from displaying by default and gives you a clear structure that is easy to scan and locate.\nHoverable sub-menu: With each module that has additional menu options, hover over the respective module to quickly navigate.\nNew Menu Option for IntegrationsA dedicated Integrations menu option provides an easy way to access both inbound and outbound integrations with Sysdig.\nInbound: Access Monitoring Integrations quickly and understand which applications and services are running. You can also manage your AWS Account and review the Sysdig agent installation. Outbound: Manage the Notification Channels and S3 Capture Storage. Revamped User MenuThe User menu provides the following:\nOption to efficiently switch between Sysdig Teams. Access Management to the Administrator. Sysdig API Tokens to the authenticated user. Documentation and What\u0026rsquo;s new links The Settings sub-menu link is provided to review all the available options for the current user.\nJanuary 26, 2022Support for PVC Metrics Contact your Sysdig representative or Sysdig Support to enable PVC metrics in your environment.\nWith Sysdig agent v12.2.0 or above installed in your monitoring environment, Sysdig Monitor can help you surveil your Kubernetes PV/PVCs objects. Use the PVC dashboard and alert templates to get an insight into your PV usage, such as disk usage, inodes, storage latency, errors, and so on.\nFor more information, see Configure PVC Metrics.\nNew KSM Troubleshooting MetricsSysdig provides the following new troubleshooting metrics:\nkube_workload_pod_status_phase kube_workload_pod_status_reason kube_pod_status_unschedulable kube_pod_container_status_waiting kube_pod_container_status_waiting_reason kube_pod_container_status_terminated kube_pod_container_status_terminated_reason These metrics give insights into why pods are stuck or crashing (CrashLoopBackOff, OOMKilled, DeadlineExceeded etc.). To support this:\nThe Kubernetes Alerts Library has been updated to provide additional alerts for errors such as CrashLoopBackOff.\nNew panels has been added to the Kubernetes Workload Status \u0026amp; Performance dashboard.\nIn environments running older versions of Sysdig agent, the Kubernetes Dashboards will display a banner prompting you to upgrade to agent v12.2.0 or above for these metrics to be automatically collected.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-monitor-release-notes/2022-archive/"},{"id":118,"title":"Serverless Agent Release Notes 2022","content":"3.0.5 December 07, 2022Defect FixesFixed the following vulnerabilities with the orchestrator agent:\nCVE-2014-6407 CVE-2014-3499 CVE-2014-9356 CVE-2014-9357 CVE-2015-3627 CVE-2022-32149 CVE-2022-42898 Fixed the following vulnerabilities with the workload agent:\nCVE-2021-42836 CVE-2021-42248 Fixed the following vulnerabilities with the serverless instrumentation:\nCVE-2022-42898 3.0.4 November 17, 2022Defect FixesFixed Tag Value Reference FailureThe Instrumentation Lambda in the CloudFormation stack no longer fails when the workload to be instrumented contains references for tags values.\nReduced Broad Stack PermissionsPermissions were reduced in the CloudFormation stack.\nFixed Proxy Password Obfuscation FailureOrchestrator and Instrumentation logs no longer contain plaintext proxy passwords.\n3.0.3 September 19, 2022New FeatureAdded task label to the metric serverlessdragent.workload_agent.count to enable grouping multiple containers in a single task.\n3.0.2 September 02, 2022Defect FixesPrevented Workload StarvationThe instrumentation can now start the workload even if security policies are not in place.\nTo configure the starting policy, see configure workload starting policy.\nFixed Workload-starvation-detection WatchdogInstrumentation watchdog no longer needs to be configured via the watchdog.sinsp_worker_timeout_s parameter.\nFixed the /proc Scan FailureInstrumentation /proc scan no longer fails when the Systems Manager Agent (SSM Agent) runs as root and the instrumented task runs as non-root user.\nNew Instrumentation Logging Level ParameterThe instrumentation logging level can now be easily configured via a new parameter exposed in the Instrumentation stack.\n3.0.1 June 30, 2022Defect FixesUpdated Log LevelsThe instrumentation logger for the Fargate Serverless Agent can now be configured to the following log levels:\nsilent error warning info debug trace 3.0.0 June 17, 2022Defect FixesFixed DEBUG Logging ErrorThe instrumented task should no longer be blocked from starting when using DEBUG logging with log-forwarding enabled, and better error messages have been added for failures when log-forwarding.\nFixed Termination ErrorInstrumentation tasks now terminate correctly on fatal errors and trigger the Elastic Container Service (ECS) restart policy.\nCleaned Up Serverless Agent MetadataRedundancies in the serverless agent metadata, including labels and tags, were corrected:\nAWS-related metadata are grouped below aws.* tags Container-related metadata are grouped below container.* tags Custom tags are grouped below agent.* tags New FeaturesNew Container-Based InstallerThe Serverless Agent 3.0.0 provides a new container-based installer to simplify the deployment of the instrumentation and orchestration stacks. Serverless Agent 3.0.0 also supports the existing command-line-based installer.\nSee AWS Fargate Serverless Agents.\nInstrumentation Logs FormatThe Serverless Agent 3.0.0 supports both the json and text format for the forwarded instrumentation logs.\nSee Manage Serverless Agent Logs for more information.\n2.3.0 March 15, 2022Defect FixesContainer Metadata Now Automatically Provided to Avoid ErrorsThe following metadata values are now automatically passed by serverless agents:\n- container.image.repo* - container.image.tag** - container.image.digest** - container.image.id* * value is always provided in same way\n** value depends on how the image is referred to when deploying the instrumented container. For example, repo:tag vs repo@digest.\nExample:latest\nWhen specifying an image such as falcosecurity/event-generator:latest the metadata configuration is:\n- container.image.repo = falcosecurity/event-generator - container.image.tag = latest - container.image.digest = null - container.image.id = sha256:aaabbbcccddd :named image\nWhen specifying an image such asfalcosecurity/event-generator@sha256:aaabbbcccddd the metadata configuration is:\n- container.image.repo = falcosecurity/event-generator - container.image.tag = null - container.image.digest = sha256:aaabbbcccddd - container.image.id = sha256:aaabbbcccddd Fixed Display Problem in Insights Composite View for Fargate EventsSecure events from the Fargate serverless agent are now correctly labeled with Account ID and Region, allowing them be grouped correctly in the Insights Composite view.\nFixed Occasional Problem with Starting Instrumented TasksAdded retry and fallback logic to avoid restarts when a log-forwarding endpoint isn\u0026rsquo;t present.\nManual Instrumentation of Workload AgentsImproved documentation for manual instrumentation of workload agents, including handling logs.\n","url":"https://docs.sysdig.com/en/release-notes/serverless-agent-release-notes/2022-archive/"},{"id":119,"title":"On-Prem Release Notes 2022","content":"5.1.5 Hotfix Release, December 2022Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Installation instructions.\nDefect Fixes Fixed an issue where Sysdigcloud-api would fail to connect to Cassandra when a column name already exists. Fixed an invalid Cassandra StatefulSet YAML issue in multi-AZ deployments. 5.1.4 Hotfix Release, November 2022Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Install instructions.\nSecure Removed the Legacy Benchmarks button from the Secure UI.\nThe feature will soon be deprecated in on-premises deployments.\nAdded the Shared with Team permission in Group Mappings to the ServiceManager role.\nDefect Fixes Fixed an issue where a scanned image would not correctly report a vulnerability detected in kernel-headers packages. Fixed a Secure scanning issue where an image was scanned by multiple sources, such as Inline Scanner and Node Analyzer, and the UI would redirect the user to the incorrect source. Fixed a Team Scope issue in Secure where the agent.tag.accountid scope was configured and users could not see Host scanning results. Updated the Secure Only on-premises setting for aggregation interval set to 60 seconds to help reduce the number of stream resetting log warnings in the Sysdig backend. 5.1.3 Hotfix Release, September 2022Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Installation instructions.\nDefect Fixes Fixed an Elasticsearch issue that occurred during upgrades, causing pods to end in a CrashLoopBackOff state. This fix will improve overall Elasticsearch resiliency for users. 4.0.8 Hotfix Release, July 2022Supported Upgrades From: 3.6.X\nDefect Fixes Fixed an issue with persistent volume claim (PVC) metrics not displaying properly in the UI.\nFixed a filtering issue where relational database service (RDS) metrics would not populate in the RDS Overview Dashboard.\n5.1.2-2 Hotfix Release, July 2022Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nSysdig Platform Added support for OpenShift 4.10. 5.1.2 Hotfix Release, May 2022Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Installation instructions.\nSecure Feature: Reporting Added the Run Now and Download(s) menu items. Defect Fixes Fixed an Unable to load latest task result bug when accessing compliance benchmarks results. 5.1.1 Hotfix Release, May 2022Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Installation instructions.\nSysdig Platform Added the RelayState parameter optional for SAML configuration.\nUpgraded the Spring Framework to version 5.2.20 in the sysdig-backend container.\nMonitor Added the ability to choose regions with Capture Storage. Installer Improvements Fixed an issue with MultiAZ GCP/GKE platforms that would prevent Elasticsearch from starting.\nFixed an ingress permissions issue when upgrading from 5.0.4 to 5.1.0 that would result in the Sysdig UI generating a 404 Not Found error.\nFixed an installer bug when cloudProvider.name was set and cloudProvider.region was not set.\nFixed a Kafka/Zookeeper statefulset naming issue when installing or upgrading Sysdig on-premises.\nDefect Fixes Monitor Alert re-notification messages now provide the latest metric value instead of the metric value at time of triggering. Fixed a Runtime scan page issue not displaying image results based on specific Team scopes. 5.0.5 Hotfix Release for CVE-2022-22965Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the ReleaseNotes on GitHub. There you will also find important Installation instructions.\nImprovementsThis hotfix upgrades the Spring Framework to version 5.2.20 in the sysdig-backend container.\n5.1.0 Release, March 2022Upgrade ProcessSupported Upgrades From: 4.0.x, 5.0.x\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Installation instructions.\nSysdig PlatformInstaller Improvements Kubernetes versions 1.22 and 1.23 are now supported. An optional cronjob for the falco-rules-installer, which runs once a month, can now be created through the installer values file. Users operating their own ingress controller, such as Rancher, are no longer need to manually create Ingress Objects Go HTTP APIs. Note that the Collector uses TCP and will need external configuration. The Installer now has a pre-flight check to verify the kubectl and Kubernetes versions of the cluster with the context provided by the user. SecureAPI Docs API documentation for Sysdig Secure is now enabled by default. Defect Fixes Fixed an issue with Secure Events not displaying the correct number of events in the dashboard. Fixed an issue that prevented Rapid Response from being enabled with a Secure Team created with LDAP. Fixed a network issue that would sometimes occur during an upgrade which would cause PostgreSQL to timeout. Fixed an issue where the nats-streaming-init container failed to start due to permission problem when storageClassProvisioner is set to hostPath. Fixed a Compliance Database Password issue during upgrades from on-prem 4.0.x to on-prem 5.0.x Fixed an issue with the StatefulSet definition when upgrading from 4.0.x to 5.0.x on a Kubernetes cluster prior to 1.18.x 4.0.7/5.0.4 Hotfix Release for CVE-2021-44228 in Apache’s log4j (3.6.4, 4.0.7, 5.0.4)The patch relese upgrades all components that compose Sysdig\u0026rsquo;s Platform running Apache\u0026rsquo;s vulnerable Log4j library to 2.16.\nNote on ElasticSearch: This is using Log4j v2.11.1. An additional JVM parameter has been added through the Installer in accordance with the recommendations from Elastic. In addition, the impacted class from the Log4j library has been removed completely. Security scanners may still list this as vulnerable but in this case it will be a false positive. Elastic currently does not offer a way to fully remove or upgrade this component.\n4.0.6/5.0.3 Hotfix Release for CVE-2021-44228 in Apache\u0026rsquo;s log4j (3.6.3, 4.0.6, 5.0.3)Security researchers recently disclosed the vulnerability CVE-2021-44228 in Apache\u0026rsquo;s log4j, which is a common Java-based library used for logging purposes Sysdig is using an alternative framework for logging called Logback. The logback framework isn\u0026rsquo;t vulnerable to this issue.\nSysdig components include a log4j library in our standard distribution that was vulnerable. This library is included for compatibility reasons only and is not used for primary logging. Sysdig has determined that our products are not vulnerable based on our application architecture and mitigating controls.\nWe have released a patch version of our self hosted-software which upgrades the vulnerable version of log4j or adds additional mitigating controls suggested by vendors.\n3.6.3 4.0.6 5.0.3 Please reach out to support or the customer success team for assistance with your upgrade.\n","url":"https://docs.sysdig.com/en/release-notes/sysdig-on-premises-release-notes/2022-archive/"},{"id":120,"title":"Enhanced Metric Store Release Notes","content":"June 2022New Features and EnhancementsPrometheus-Compatible Naming Conventions for Metrics \u0026amp; LabelsIn prior versions of Sysdig Monitor, metrics were inconsistent between PromQL and Form querying. This behavior has been changed. Metrics are now unified — all the metrics are now presented in a Prometheus compatible naming convention, as opposed to the previous statsd compatible naming convention. For example, underscore is used instead of dot notation as given below:\nkubernetes.node.allocatable.cpuCores will be mapped to kube_node_status_allocatable_cpu_cores and kubernetes.namespace.name to kube_namespace_name.\nYour existing dashboards, alerts and notifications will be automatically migrated to the new naming convention. Sysdig APIs support metrics and labels in both old and new naming conventions. Note that for the initial release, Labels will not be migrated to the new naming convention in the old explore, events, and team settings.\nNotifications sent via alerts (webhooks, PagerDuty, and so on) will use the new label and metric conventions. If you are performing further processing to parse the metric or label names within these notification messages, update your scripts as appropriate.\nFor metrics mapping, see Metrics and Label Mapping.\nContext-Specific MetricsMetrics such as cpu.used.percent would previously show values from a process, container, or host, depending on your query segmentation and scope. This has been improved by creating new sets of context-specific metrics and resource specific semantics of Prometheus naming convention. For example:\nClassic Metrics New Metrics cpu.used.percent sysdig_program_cpu_used_percent sysdig_container_cpu_used_percent\nsysdig_host_cpu_used_percent uptime sysdig_program_up sysdig_container_up sysdig_host_up Network metrics previously would either be showing values from a host, container, program, or connection depending on your query segmentation or scope. This has been improved by creating a new sets of context-explicit metrics, in this case per connection metrics:\nClassic Metrics New Metrics net.bytes.in sysdig_connection_net_in_bytes\nsysdig_container_net_in_bytes\nsysdig_host_net_in_bytes\nsysdig_program_net_in_bytes Your existing dashboards, alerts and notifications will be automatically migrated to the new naming convention. Sysdig APIs support metrics in both old and new naming conventions.\nFor the complete list of context-specific metrics, see Mapping Classic Metrics with Context-Specific PromQL Metrics.\nFaster Query PerformanceQueries now perform faster and handle larger volumes of data. You can expect queries executed in Sysdig Monitor to be noticeably faster.\nSingle Stat Panels Displays Latest ValueNumber panels, tables, histograms, and toplist panels can now show the latest value for an entity. This can be done without having to aggregate multiple values over the time selection.\nOverview Displays Latest DataOverview pages now shows the latest data as opposed to an aggregated value for widgets over the time window selected. Time navigation has been removed to focus this view on the live (latest) status of your infrastructure.\nScope Variable in PromQL DashboardYou can easily reference a dashboard scope in PromQL queries. To do so, use the reserved $__scope variable as shown below:\nUnder the hood $__scope will be substituted with the expression specified in the dashboard scope. This is achieved by leveraging Sysdig ServiceVision technology which allows for automatically enriching metrics with Kubernetes and application context. To learn more, see ServiceVision.\nMixed-Metric GranularitySysdig Monitor can now display metrics scraped at different intervals, for example 10s and 1m, on the same graph.\nImproved Granularity for PromQL panelsGranularity of graphs has been improved for promQL panels. For example, a 1 hour selection now shows metrics with 10 second intervals. In prior versions, 1-hour selection in Dashboards showed metrics in 1-minute interval.\nRemoved Re-AlignmentPreviously, Sysdig Monitor would re-align time selections in graphs due to certain performance limitations. This has been removed to show more up-to-date metrics.\nTroubleshooting MetricsTroubleshooting metrics, such as program metrics, connection-level network metrics, and Kubernetes troubleshooting metrics, are being reported on a granular level at 10s and will be stored for 4 days. For the list of troubleshooting metrics and the labels that you can use to segment them, see Troubleshooting Metrics.\nDiscontinued FeaturesDiscontinued Metrics and LabelsBelow is the list of metrics and labels that are going to be discontinued. We made an effort to not deprecate any metrics or labels used in existing alerts, but contact us if you encounter any issues.\nIt is important to note that we have applied automatic mapping of all net.*.request.time.worst metrics to net.*.request.time, as max aggregation gives equivalent results and it was almost exclusively used in combination with these metrics.\nDiscontinued MetricsThe following metrics are no longer supported:\nnet.request.time.file net.request.time.file.percent net.request.time.local net.request.time.local.percent net.request.time.net net.request.time.net.percent net.request.time.nextTiers net.request.time.nextTiers.percent net.request.time.processing net.request.time.processing.percent net.request.time.worst.in net.request.time.worst.out net.incomplete.connection.count.total net.http.request.time.worst net.mongodb.request.time.worst net.sql.request.time.worst net.link.clientServer.bytes net.link.delay.perRequest net.link.serverClient.bytes Discontinued LabelsThe following labels are no longer supported:\nnet.connection.client net.connection.client.pid net.connection.direction net.connection.endpoint.tcp net.connection.udp.inverted net.connection.errorCode net.connection.l4proto net.connection.server net.connection.server.pid net.connection.state net.role cloudProvider.resource.endPoint host.container.mappings host.ip.all host.ip.private host.ip.public host.server.port host.isClientServer host.isInstrumented host.isInternal host.procList.main host_domain proc.id proc.name.client proc.name.server program.environment program.usernames mesos_cluster mesos_node mesos_pid In addition to this, composite labels ending with the .label string will no longer be supported. For example kubernetes.service.label will be deprecated, but kubernetes.service.label.* will continue to be supported.\nRemoved FeaturesTopology MapsTopology Maps will be deprecated due to their incompatibility with the new data store and their limitations at scale for certain users.\nAgent PercentilesAgent derived percentiles will be deprecated. If you have been using these, your query will stop working and you will have to manually migrate your queries to leverage Prometheus histograms or PromQL functions such as histogram_quantile.\nChange in FunctionalityUsage of Labels in Table PanelOnly Infrastructure labels can be used to query metrics. Build table panels with:\nHost level labels (such as agent tags) AWS tags (such as region) Kubernetes labels (such as workload) Known Issue for Non TimechartsDue to the underlying changes we made to our core metric ingestion engine, charts that are not Timecharts (for example, Number panels) will sometimes fail to display aggregated data for the full requested time range. In this case, we will:\nAggregate a portion of data spanning a minimum of two weeks. Clearly define the time range for which we were able to aggregate in the warning message. This is a transient side effect, and will be less likely to happen over time.\nContact UsIf you have any questions or comments about these changes, contact your Sysdig representative or Sysdig Support.\n","url":"https://docs.sysdig.com/en/release-notes/enhanced-metric-store/"},{"id":121,"title":"Cluster Shield Release Notes 2025","content":"1.18.1 December 18, 2025Supported shield chart version: 1.25.2\nDefect Fixes Fixed incorrect resolution of image signature references with pullstrings that contain a digest. This caused supply-chain policy evaluations to fail and resulted in denied admission requests due to missing image signatures. Fixed an issue where Admission Control did not honor the features.container_vulnerability_management.registry_ssl.verify configuration value. Fixed a bug in Container Vulnerability Management that could prevent Cluster Shield from correctly retrieving images from public registries. Vulnerability FixesThis release addresses the following vulnerabilities:\nCVE-2025-47914 CVE-2025-58181 CVE-2025-59375 CVE-2025-61727 CVE-2025-61729 CVE-2025-4598 CVE-2025-9714 1.18.0 November 27, 2025Supported shield chart version: 1.24.0\nEnhancementsAdded cert-manager Integration in the Shield ChartThe shield chart can now use cert-manager to generate certificates required by the Audit and Admission Control features.\nSee the cert-manager configuration in values.yaml for details.\nIf you deploy the chart without using Helm directly (for example, when deploying with Argo CD) and enable this capability, note that cluster-shield will no longer restart on every deployment. Previous restarts were caused by certificates being regenerated on each deployment.\nDefect Fixes Fixed an issue in Cluster Shield where configuration updates were not correctly loaded by the application. 1.17.0 October 31, 2025Supported shield chart version: 1.22.0\nEnhancementsImage Signature Validation for Admission Control of Kubernetes WorkloadsSysdig Secure now supports Image Signature Validation to ensure that only trusted and verifiable container images are deployed to your Kubernetes and OpenShift clusters. This new capability, powered by Cosign, lets you enforce signature verification at admission using trusted sources like Red Hat Trusted Artifact Signer (RHTAS), GitHub + Sigstore, or a self-hosted Sigstore instance.\nAvailable starting with Cluster Shield 1.17.0, Image Signature Validation integrates with the Sysdig Admission Controller to strengthen supply chain security by preventing unsigned or tampered images before they reach your critical environments.\nFor more information, see the Image Signature Validation Policy.\nDefect Fixes Fixed an issue which could cause Container Vulnerability Management functionality to not increment the load_image_result prometheus metrics. Fixed an issue that could cause posture feature ignore the skip SSL verification setting for a subset of calls to sysdig backend. 1.16.1 October 17, 2025Supported shield chart version: 1.21.2\nDefect Fixes Fixed an issue that could cause the Admission Control and Vulnerability Management features to ignore the container_vulnerability_management.local_cluster.registry_secrets configuration option. 1.16.0 September 29, 2025Supported shield chart version: 1.20.0\nEnhancementsCertificate Hot ReloadAdmission Control can now hot reload updated certificates. You don\u0026rsquo;t have to restart the application. For more information, see Cert-manager integration.\nInit Container Support for Vulnerability ScanningSysdig now scans init containers as part of Kubernetes workloads and returns vulnerability scan results for affected resources.\nFor more information, see Sysdig Vulnerability Management.\nImproved CronJob ScanningImproved vulnerability scanning for Kubernetes CronJobs to retain CronJobs that run during the Cluster Shield discovery period. CronJobs executed within a cluster during this time now appear as running workloads in Vulnerability Findings, providing more accurate visibility.\nFor more information, see Sysdig Vulnerability Management.\nDefect Fixes Fixed an issue that could cause the Cluster Shield\u0026rsquo;s Vulnerability Management feature to behave unexpectedly when using Redis as a remote cache for intermediate results. Fixed VulnerabilitiesThis release addresses the following vulnerabilities:\nCVE-2025-32988 CVE-2025-32989 CVE-2025-32990 CVE-2025-6395 CVE-2025-8194 1.15.0 August 28, 2025Supported shield chart version: 1.17.0\nDefect Fixes Fixed a bug where Cluster Shield ignored the value of features.container_vulnerability_management.registry_ssl.verify setting. Fixed a bug that could prevent customers from seeing posture results. Services could fail to restart if their cgroup was deleted during the backoff delay. Cluster Shield now checks for the service’s cgroup and recreates it if missing before starting the service. Removed an incorrect error log message that some on-premises customers could encounter. Fixed VulnerabilitiesThis release addresses the following vulnerabilities:\nCVE-2025-5914 CVE-2025-5994 CVE-2025-6965 CVE-2025-7425 CVE-2025-32414 CVE-2025-32415 CVE-2025-47907 CVE-2025-54388 CVE-2025-8058 CVE-2022-29458 1.14.0 July 31, 2025Supported shield chart version: 1.15.1\nEnhancementsImproved Memory Reservation in Cluster ShieldRefined Cluster Shield memory reservation logic to maximize resource efficiency and improve overall reliability.\nFor additional information on how to fine-tune your Cluster Shield memory configuration, contact your Sysdig account representative.\nDocker Mirrors AuthenticationAdded support for authenticating against Docker mirrors.\nEnhanced Scanner Events MetadataUpdated source info in Scanner Events to include Cluster Shield version and the feature generating events.\nImproved Logging for Unsupported K8s ResourcesContainer Vulnerability Management now logs the type of unsupported Kubernetes resources it detects.\nDefect Fixes Fixed authentication issue in Container Vulnerability Management when using Google credential helper (for example, Workload Identity Federation). Added logs for NATS reconnection failures. Namespace entities now correctly populate the namespace property to avoid no-name entries in Inventory. Fixed OS package detection issues in Wolfi-based images. Resolved incorrect classification of RHEL-EUS as standard RHEL. Initialized logger correctly in Container Vulnerability Management Controller for Admission Controller image scans. Fixed an issue during SBOM extraction for Container Vulnerability Management that could cause a misconfiguration for on-prem customers. Updated the image loader to use the same configuration as Container Vulnerability Management component. Fixed VulnerabilitiesThis release addresses the following vulnerabilities:\nCVE-2024-12718 CVE-2025-4138 CVE-2025-4517 CVE-2025-49794 CVE-2025-49796 CVE-2024-52533 CVE-2025-25724 CVE-2025-3576 CVE-2025-4330 CVE-2025-4373 CVE-2025-4435 CVE-2025-47273 CVE-2025-5702 CVE-2025-6021 1.13.0 June 26, 2025Supported shield chart version: 1.12.2\nEnhancements You can now monitor Shield health metrics of Cluster Shield on Sysdig Secure and Monitor. The shield and sysdig-deploy charts now support the creation and management of Pod Disruption Budgets for Cluster Shield. Defect Fixes Fixed an issue that prevented the reporting of the Kubernetes distribution when using vanilla Kubernetes. Fixed Vulnerabilities CVE-2025-4802 1.12.1 June 11, 2025Supported shield chart version: 1.8.1\nDefect Fixes Fixed an issue where legacy Kubernetes metrics were unexpectedly missing from some namespaces. Fixed Vulnerabilities CVE-2025-22874 CVE-2025-4673 CVE-2025-0913 1.12.0 June 5, 2025Supported shield chart version: 1.8.0\nEnhancementsImproved Audit Logging Efficiency Enhanced Kubernetes Audit Logging to reduce API server noise caused by idle connection handling and to improve request logic, helping to prevent API rate limit issues. Expanded Support for Kubernetes Distributions Extended support for Kubernetes distributions to include Oracle Kubernetes Engine (OKE), Rancher Kubernetes Engine (RKE2), and Mirantis Kubernetes Engine (MKE). Added Support for Network Security.You can enable Network Security by configuring the existing investigations section under features.\nFixed Vulnerabilities CVE-2025-46569 1.11.0 May 07, 2025Enhancements The audit feature now detects when certificates have been updated and reloads them automatically, so there is no need to restart the application.\nAdded support for reporting the kube_job_spec_active_deadline_seconds metric for Kubernetes Job objects.\nAdded the following configuration to enable the collection of Kubernetes State Metrics (KSM), which were previously collected by default when you enabled the kubernetes_metadata feature.\nfeatures: monitor: kube_state_metrics: enabled: true Added the following configuration to enable the collection of Kubernetes events for Sysdig Monitor, previously enabled by default with the kubernetes_metadata feature. For more details, see Process Kubernetes Events.\nfeatures: monitor: kubernetes_events: enabled: true The kube_state_metrics and kubernetes_events features now replace the functionality previously provided by the kubernetes_metadata feature in Sysdig Monitor, which is a breaking change. If you were using kubernetes_metadata to collect Kubernetes state metrics (KSM) and events, you must now explicitly enable the new features to continue collecting this data. For example,\nfeatures: monitor: kube_state_metrics: enabled: true kubernetes_events: enabled: true Fixed Vulnerabilities CVE-2025-30215 CVE-2025-22872 CVE-2025-22871 CVE-2025-0395 Defect FixesFixed an issue in Container Vulnerability Management that could cause the component to be terminated by the operating system when interacting with Amazon ECR on EKS clusters.\n1.10.0 April 03, 2025EnhancementsDetections of Vulnerabilities on Operating SystemsWe have added detections for the following Operating system level vulnerabilities\nPhotonOS CBL Mariner Azure Linux Suse Enterprise Linux 12 and 15 Suse Micro Linux For additional information please refer to our Vulnerability Feeds documentation.\nNew Metrics for Cluster Shield Metric Name Description num_of_workloads_detected Number of all detected workloads obtained by interacting with the K8s API, including filtered, running and stopped workloads. num_of_workloads_filtered Number of filtered workloads, i.e., that will not be scanned. num_of_workloads_running Number of currently running workloads. num_of_workloads_stopped Number of currently stopped workloads. num_of_workloads_with_a_SBOM_extracted Number of workloads for which a SBOM has been extracted at least once. num_of_workloads_with_a_SBOM_fresh Number of workloads for which a SBOM has been extracted recently and is still valid. num_of_workloads_without_SBOM Number of workloads for which a SBOM has never been extracted. num_of_workloads_in_SBOM_extraction_queue Number of workloads in queue for SBOM extraction. num_of_workloads_with_SBOM_extraction_error Number of workloads for which the last SBOM extraction attempt failed. These workloads may include entries for which the SBOM has been extracted in the past. num_of_workloads_sent_to_collector Number of workloads successfully sent to collector in the last cycle (including running, stopped and short-lived workloads). is_last_send_to_collector_successful Boolean value indicating whether the last send to collector was successful. agent_kube_metadata_state_objects_count Tracks the number of Kubernetes resources sent in each message, categorized by resource type. agent_kube_metadata_connected Indicates the current connection state with the Sysdig backend (0 = Disconnected, 1 = Connected). agent_kube_metadata_connection_attempts_total Tracks the total number of connection attempts to the Sysdig backend. Fixed Vulnerabilities CVE-2025-30204 CVE-2025-29923 Defect FixesIn certain registry implementations, the registry returns a 400 status code rather than standard HTTP error codes for Authentication Failures when attempting to authenticate. Cluster Shield will now retry authentication with alternative credentials provided as dockerconfigjson K8s Secrets or acquired via the integrated support for Credential Helpers for AWS, GCP, and Azure.\n1.9.1 Mar 21, 2025Fixed Vulnerabilities CVE-2025-22870 Defect Fixes Fixed an issue causing cluster-shield components to restart upon failure without applying the expected exponential backoff delay. Fixed a timing issue in Cluster Shield that caused the SBOM extractor to trigger excessive SBOM extractions that the Runtime component could not process. 1.9.0 Mar 11, 2025Feature Enhancements Added a gauge metric sysdig_cluster_shield_component_health_status to represent the health status of each enabled component. This is now available through the /metrics endpoint on port 8080\nA metric value of 1 indicates a healthy component, while 0 signifies an unhealthy one.\nCluster Shield now attempts to restart unhealthy components after 100 seconds.\n1.8.2 Feb 28, 2025Fixed Vulnerabilities CVE-2025-22869 CVE-2025-22868 CVE-2020-11023 1.8.1 Feb 25, 2025Defect Fixes Fixed an issue that prevented the Container Vulnerability Management feature to authenticate to the registry and process the images as expected. Fixed an issue where Cluster Shield reported invalid prometheus metrics. 1.8.0 Feb 4, 2025Feature Enhancements Optimized memory usage of the container-vulnerability-management-controller component. Added support for multiple candidate pull-strings per workload to resolve scanning failures caused by alias references from non-pullable locations. Added the ability to filter the images for scanning as part of the container vulnerability management feature. See Container Filtering for more details. Defect Fixes Resolved an issue in which Kubernetes metadata inaccurately reported parent service links when a pod was exposed by multiple services. The pod is now correctly associated with all relevant services. Fixed a bug that caused unexpected lags when pulling images. The issue occurred because features.container_vulnerability_management.registry_ssl.verify was set to true, enforcing SSL certificate verification. 1.7.1 Jan 10, 2025Fixed Vulnerabilities CVE-2024-45338 1.7.0 Jan 07, 2025Feature Enhancements The Container Vulnerability Management feature now supports mirrors and insecure registries configurations for image scanning. Defect Fixes Fixed an issue that prevented the Container Vulnerability Management feature to correctly authenticate and process the image when candidate pull secrets have been found. ","url":"https://docs.sysdig.com/en/release-notes/sysdig-cluster-shield-release-notes/2025-archive/"},{"id":122,"title":"Costs","content":" Costs help you get insights into the following use cases:\nDetermining the cost of running compute, such as EC2 instances, within a Kubernetes cluster. Determining the cost of running Compute required for an application, workload, and namespace. Reducing the cost of running workloads by rightsizing. Key FeaturesCosts have multiple features to help you monitor and manage Kubernetes costs:\nCost Advisor: Provides an overview of your costs, drill into clusters, namespaces, and workloads; presents insights and recommendations into where you can optimize and reduce your costs. Cost Explorer: Presents a powerful exploration tool for costs; give you the ability to slice and dice by Kubernetes labels, browse historical costs, and spot anomalies. Reports: Automate reporting of costs with Slack and email integrations, and generate periodic JSON/CSV exports for integration with third party tooling. Supported Environments The Sysdig Agent is required for Costs.\nThe agent collects resource usage information that is augmented with billing data. There is no explicit configuration required for Costs if you are only interested in seeing costs based on public, on-demand pricing.\n(Optional) Integrate with your cloud provider to reconcile cost data with your specific costs, factoring in saving plans, reserved instances, and other discounts.\nKubernetes clusters must be running in AWS, GCP, or Azure. Both managed clusters, such as EKS, and vanilla Kubernetes such as KOPS, are supported.\nLearn More Costs Kubernetes Cost Optimization ","url":"https://docs.sysdig.com/en/sysdig-monitor/costs/"},{"id":123,"title":"Histogram","content":" The Histogram panel type on the Dashboard: Histogram panels allow you to visualize the distribution of metric values for large datasets. The histogram panel helps understand value across different segments. For example, CPU usage percent by containers across your hosts gives you the aggregated value across the selected time. Use Histograms for any metric, Sysdig native or custom, counter or gauge, segmented by a dimension/label.\nTo create a Histogram panel, Create a new dashboard or select an existing dashboard and click Add Panel. Select the visualization icon, which defaults to Timechart. Under Select Visualization, choose Histogram. Customize your Histogram with the Metric \u0026amp; Grouping controls, ensuring you select at least one label. When you\u0026rsquo;re done, click Save.\nLegacy Prometheus histogram collection: This implementation of legacy Prometheus Histograms is deprecated.\nTo create a Histogram, use the Prometheus integration to collect histogram metrics and use the PromQL panel with the histogram_quantile function.\nHistograms are not reported by default in Prometheus. This is configured in dragent.default/yaml:\nprometheus: # enabled: false interval: 10 log_errors: true max_metrics: 1000 max_metrics_per_process: 1000 max_tags_per_metric: 40 histograms: false timeout: 1 To report histogram metrics, edit this to read histograms: true.\nPrometheus histograms (collected as raw metrics): The legacy Prometheus histogram collection is replaced by the new Prometheus histogram. You can natively collect histogram metrics, and for visualization, use timechart:\nFor example, run the following query to build a timechart:\nsum(histogram_metrics_bucket{kubernetes_cluster_name=\u0026#34;prod\u0026#34;}) by (le) ","url":"https://docs.sysdig.com/en/sysdig-monitor/histogram/"},{"id":124,"title":"How to Integrate with a Self-Hosted Sigstore Instance for Image Signature Validation","content":"OverviewA self-hosted Sigstore deployment allows your organization to control all signing and verification infrastructure, including Fulcio, Rekor, and TUF services.\nWhen integrated with Sysdig Secure, this configuration enables verification of container images signed within your internal CI/CD pipelines using your own OIDC provider or managed signing keys.\nSysdig leverages Cosign to verify signatures at admission.\nAll verification logic is defined within the backend Image Signature Validation Policy—no Fulcio, Rekor, or OIDC configuration is required in the Cluster Shield chart.\nPurposeA self-hosted Sigstore instance provides full control over your signing and trust domain.\nIntegrating it with Sysdig ensures that only images signed through your internal trust root are admitted to your clusters.\nDuring deployment, Sysdig verifies each image against your configured trust root and OIDC identity to ensure that:\nOnly verified images signed through your internal Sigstore instance are admitted to the cluster. Supply chain integrity is maintained from build to production. Tampering and substitution attacks are blocked before execution. Compliance frameworks (for example, SLSA or NIST 800-204D) are supported through transparent verification and logging. Benefits Capability Description Private signing authority Uses your internal Fulcio CA and Rekor log instead of the public Sigstore services. Flexible identity verification Validates signatures using your enterprise OIDC provider or managed signing keys. Policy-driven enforcement Defines trust roots and identities in Sysdig Supply Chain Policies, not runtime configuration. Admission-time protection Enforces policy decisions during Kubernetes admission control through Cluster Shield. SummaryIntegrating a self-hosted Sigstore instance with Sysdig Cluster Shield allows your organization to enforce container signature verification under your own trust and identity systems. Sysdig performs verification through Cosign using policy-defined parameters for OIDC or Public Key validation. Both mechanisms are supported but mutually exclusive.\nConfigurationCluster ShieldYou don’t need to configure Sigstore endpoints or OIDC values directly in Cluster Shield.\nInstead, enable signature verification globally. Sysdig performs Cosign verification based on the backend policy.\nfeatures: supply_chain: enabled: true image_signature: cosign: enabled: true mirror: https://tuf.example-trusted-artifacts.sysdig.com ## Optional: set only if root.json differs from the default Sigstore location. root: https://tuf.example-trusted-artifacts.sysdig.com/example/root.json root_checksum: sha256:8d31cb9e6b5f89c224e621e1eac5e4d3bcd20a02e31d69394f0f8b62f88e743c Cluster Shield handles enforcement at runtime. The verification method (OIDC or key-based) and trust root are configured in the policy.\nPolicy Configuration (Backend)Configure verification parameters within the Image Signature Validation Policy. You can use one of two mutually exclusive mechanisms:\n1. Public Key Verification\nUse public key verification if your build pipeline signs images with a managed or long-lived key pair. Provide the PEM-encoded public key in the policy:\n-----BEGIN PUBLIC KEY----- MFswDQYJKoZIhvcNAQEBBQADSgAwRwJAXWRPQyGlEY+SXz8Uslhe+MLjTgWd8lf/ nA0hgCm9JFKC1tq1S73cQ9naClNXsMqY7pwPt1bSY8jYRqHHbdoUvwIDAQAB -----END PUBLIC KEY----- Sysdig verifies signatures against this key during admission control.\n2. OIDC Provider Verification\nUse when your self-hosted Sigstore issues certificates through an enterprise OIDC provider such as Keycloak, Okta, or Azure AD.\nConfigure the following fields in the policy:\nField Example Value Description OIDC Issuer https://keycloak.ci.internal/realms/build The OIDC issuer URL used by your Fulcio CA. Certificate Identity ^system:serviceaccount:ci-pipeline:signer$ Regex for the signer identity within your organization. Certificate Chain (optional) PEM-encoded chain to override the default TUF root. Example chain:\n-----BEGIN CERTIFICATE----- MIIGczCCBJegAwIBAgIQDk... (Server Certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIF7jCCA9mgAwIBAgIQ... (Intermediate Certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIF7jCCA9mgAwIBAgIQ... (Root Certificate) -----END CERTIFICATE----- Note: The Certificate Chain override is optional and used only if you want to pin Sysdig’s verification to a specific Fulcio/TUF root different from the Cluster Shield-configured root.\nExample Use Cases Enforce that all internal workloads are signed by your enterprise Fulcio OIDC CA. Pin signature verification to your internal TUF root for air-gapped clusters. Prevent images signed through public Sigstore infrastructure from running in restricted clusters. See Also Image Signature Validation Policy Sigstore Project Documentation Cosign Verification Reference Fulcio Documentation Rekor Documentation ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/policies/supply_chain_policies/how-to-self-hosted-sigstore/"},{"id":125,"title":"Risk","content":"Supported Data SourcesThe Risks module presents findings from the following connected data sources:\nKubernetes AWS Cloud Accounts Google Cloud Platform Microsoft Azure PrerequisitesBy default, Sysdig SaaS users assigned to the following roles are granted READ access to the Risks page:\nStandard User Advanced User Team Manager Service Manager If you have custom user roles that should be given read access, or if you want to define a group of users who should not have access to the Risk page, you must create a custom role and assign Risks permission to it.\nFor more information, see Custom Roles.\nAccess Risks Log in to Sysdig Secure and click Risks.\nThe Risks page appears.\nNavigate the Risks PageOn the Risks page:\nSelect the More button at the top right corner to: Navigate to the Automations Go to the Create Query page. Create a New Custom Risk. Click a Risk Definition in the table to expand the row and see the specific Findings. Click a Finding row to open a Risk Findings panel containing a preview of the Attack Path, a summary of the finding, and additional details about the associated findings and impacted resources. Filter RisksUse the filters at the top of the Risks page to drill into the detected Risk Findings. Not all filters listed below are shown by default; click the + Add button to enable them. Click the Reset button to remove any applied filters and set the filters shown to the default state.\nSearchFilter for Risk Findings with the given string in the name of the Risk Definition.\nZoneThe Risk page is filtered to reflect your Team Scopes, including zones. Filter by detected zones using the drop-down. For setup details, see Zones.\nSeveritySysdig has established three tiers to gauge the Severity of identified issues.\nTier 1: Severity levels\nIn Tier 1, risks are categorized based on their severity levels. A risk\u0026rsquo;s severity matches the highest tier of one of its findings:\nCritical: is assigned when findings include a high-confidence detection or a critical vulnerability from an In Use package. High: is assigned when a critical vulnerability has an exploit. Medium: is assigned when Compute has access to storage, critical unused permissions exist, or an insecure storage configuration accepts HTTP. Low: is assigned if none of the above conditions are met. Use the filter buttons to focus on specific severity levels. Risk Definitions at the same severity level are sorted by additional criteria described below.\nTier 2: Prioritizing between Risks of the same severity\nIn Tier 2, risks tagged Live are prioritized higher. This means they have an affected resource with a high-confidence event that occurred within the past three hours. The number of component findings comprising risks also play a crucial role in prioritization.\nTier 3: Prioritizing between Risks of same severity and finding count\nIn Tier 3, risks are prioritized by the number of affected resources. The higher the number of impacted resources, the higher the priority for mitigation efforts.\nUnderstand the Risk Definition TableThe Risks table is organized through a number of columns.\nRisk DefinitionsOut of the box, Sysdig delivers a range of finding combinations called Risk Definitions. These are defined using SysQL, and generate Risk Findings on any resources that match the query. For certain Risk Findings, multiple resources may be affected and will be visualized as part of the Risk Finding\u0026rsquo;s attack path. However, any given finding has only one \u0026ldquo;anchor\u0026rdquo; resource – the first resource matched by the SysQL query. This is the resource displayed in the table on the Risks page when expanding a Risk Definition.\nExamples Risk Definition Associated Finding Types Anchor Resource Type Exposed Workload with Critical In Use Exploitable Vulnerability Publicly ExposedCritical Vulnerability Workload Publicly Exposed EC2 with Critical Vulnerability and High Confidence Detection Publicly ExposedCritical VulnerabilityHigh Confidence Event AWS EC2 Publicly Exposed S3 Accessed by Suspicious IP Publicly ExposedAccessed by Suspicious IP AWS S3 Publicly Exposed S3 with High Confidence Detection Publicly ExposedHigh Confidence Event AWS S3 Publicly Exposed EC2 has Access to S3 Bucket(s) through IAM Role with Critical Permissions Publicly ExposedEC2 Has Access to S3 via IAM Role or attached bucket policyCritical Permissions AWS EC2 Exposed Workload Contains AI Package Publicly ExposedContains AI Package Workload Risky AWS IAM User Risky IAM PermissionsNo MFAAccess Keys Not Rotated AWS IAM Role Potentially Compromised User Potentially CompromisedCritical Permissions AWS User Sysdig regularly adds new managed Risk Definitions to surface problematic combinations of findings.\nRisk Definitions assess data coming from CSPM, KSPM, Cloud Log Ingestion, CIEM, Vulnerability Management, and Agent-Based Threat Detection. Risk definitions require some or all of these components to be deployed to be evaluated. For example:\nType of Resource or Finding Sysdig Feature Installation Kubernetes clusters KSPM (Compliance) KSPM AWS cloud resources CSPM (Cloud compliance) Agentless AWS high-confidence event detection CSPM + Threat Detection (Cloud compliance + Threat Detection) Agentless Insecure Identity findings CSPM + CIEM (Cloud compliance + Identity and Access) Agentless Packages in runtime with vulnerabilities Compliance + In Use In Use Finding CategoriesFinding Categories refer to the different types of security issues that contribute to a risk. Current categories include:\nExposed: An affected resource is exposed to the public internet. Vulnerability: A vulnerability was detected in a package or image. Configuration: A Posture control failed in a Compliance check. Identity: Identity and Access (CIEM) permissions irregularities were detected. Detection: A high-confidence event was detected from a Sysdig Threat Intelligence or Threat Detection policy. These are managed by the Sysdig Threat Research team, contain only high-severity rules, and have a low level of false positives. AI: A finding related to an AI package or workload. Sensitive Data: An affected resource contains Personally Identifiable Information (PII), Protected Health Information (PHI), or financial data. ContextFilter based on vulnerability findings with specific context.\nIn Use: Packages which are executed at runtime and contain vulnerabilities. Has Exploit: Vulnerabilities detected that have a known method of exploitation. New/LiveThe New/Live column indicates the status of the Risk Definition:\nLive: A high-confidence event was detected within the last 3 hours. A high-confidence event refers to an event that is detected by a Sysdig Threat Intelligence or Threat Detection policy. New: A Risk is tagged as New if previously we had no affected resources match this risk, and now at least one does. A Risk is considered New for 7 days. TypeYou can filter Risk Definitions by Managed or Custom. The former are created by Sysdig, and the latter are created by users through the UI.\nUnderstand the Risk Findings TableSelect a Risk Definition to open the Risk Findings table.\nRisk Finding StatusRisk findings status defaults to Open, and may be changed to In Progress. Sysdig will move the status to Closed when the system no longer detects the issue.\nLabelsFilter for Risks where the affected anchor resource has the specified label(s).\nResource TypeFilter by anchor resource type, such as Compute, Environment, Identity, Kubernetes, or Storage.\nRisk definition tagFilter for Risks where the definition has the specified tag(s).\nReview the Affected ResourceOpen a Risk Definition to review the affected resource.\nReview the findings for critical issues.\nHover over zone findings to:\nGet a list of the affected zones for that resource. Use arrow links to the zone pages. Copy zone information, for example, to paste in the Inventory filter bar. Click an affected resource to open the Risk Finding drawer, including the Attack Path visualization, the Findings tab, and Impacted Resources tab.\nOptionally, you can change the status to In Progress to indicate that the finding is under review.\nThe default status is Open. Only Sysdig can move the status to Closed when the system can no longer detect the issue.\nReview the Attack Path Select a Risk Finding to open its detail drawer.\nThe Highlights tab of the drawer includes a preview of the attack path, as well as the risk status, risk description, anchor resource details, and risk summary.\nSelect Explore to enlarge the Attack Path pane.\nYou can use the using the + icon or the full-screen icons to explore the attack path.\nClick on each icon for details and relevant mitigation steps.\nExampleFor example, in the image above, you can see:\nPublic Exposure: The resource is exposed to the internet and details on the Load Balancer icon explain why.\nWorkload: The workload has a large number of findings, organized by Insecure Configurations, Vulnerabilities, and Events.\nSelect an Insecure Configuration icon to see the explanation, and click View More to manage the Control as you would in the Compliance module. You can accept risks, apply code to update the control, create a pull request, and other posture-related actions.\nSelect one of the Vulnerabilities icons to see the explanation, and click View More to review the full package and CVE details and to manage as you would in the Vulnerabilities module. Select an Event icon to see the explanation and click View More to review the full details and manage as you would in the Runtime Events module. Review the FindingsThe All Findings tab helps you understand all findings comprising a particular Risk Finding. Sysdig highlights the highest-impact component findings and suggests fixes to reduce the most risk with the least effort.\nSelect a Risk Finding to open its detail drawer and select the All Findings tab.\nReview Suggested Fixes to Reduce Risk.\nThese are the most impactful fixes suggested by Sysdig.\nReview Findings by Resource Type.\nThis provides a comprehensive list of all the findings associated with this Risk on all the resources in the Risk path, divided by Resource Types.\nSelect any row to open a drawer showing finding details, including remediation guidance.\nReview the Impacted ResourcesThe Impacted Resources tab helps you understand all resources involved in a specific Risk Finding. Click a resource in the table to open its resource details drawer, with a comprehensive view of everything Sysdig knows about the resource.\nUse Case: Compromised AWS IAM UserOverly permissive credentials can lead to lateral movement and privilege escalation, resulting in cloud breaches. The Risks module helps prevent attacks by detecting anomalous or suspicious user actions and enabling real-time incident response. You can use the Potentially Compromised User identity finding to correlate user activities to cloud breaches.\nPotentially Compromised User: Misconfigured identities and secrets, combined with certain operation patterns, often indicate a breach. Sysdig flags these as potentially compromised, helping you start investigating promptly. You can then determine to mark it as Compromised User. Potentially Compromised is the finding that is triggered when Sysdig detects anomalous or suspicious user actions. It indicates that you should investigate this user. See Risk Definitions to understand the findings and impacted resources.\nCompromised User: You have the capability to flag a user as Confirmed Compromised and it serves as a clear signal that the incident has been thoroughly triaged and is not a false positive. You can then take appropriate actions, such as deleting access keys, or deactivating or deleting the user. Sysdig provides recommendations for each option, guiding you through the necessary steps to address the compromise. You see these recommendations when a user is flagged as Potentially Compromised, and they remain the same even if you mark the user as Compromised.\nAdditionally, you can also view potentially compromised users in the Identity module.\nCorrelate Risk Findings to IdentitiesWhen a potential identity breach occurs, Sysdig Risks page shows the detected risk. Click the Compromised User to see affected resources.\nAdditionally, you can also view incidents related to potentially compromised users in the Events Feeds.\nTriage the Affected ResourcesYou can then triage the event as follows:\nClick one of the resources to open the Risk Details panel. Click the Findings tab. You can see all the resources in the risk path and findings by resource type. Clicking Resources takes you to the Inventory page.\nClick one of the IAM User Findings or the user under Suggested Fixes to Reduce Risk.\nThe Policy Details page appears. On this page, you can review the policy, rules, AWS user details, cloud account details, IP address, and API calls to gain insight into the affected resource.\nClick on an Event finding in the IAM User Findings section.\nOn the Event Details panel, click Investigate.\nYou are directed to the Identity 360 panel for that user, where you can see the cloud account, IP address, AWS region, user in question, and the user activities.\nClick the user to:\nSummary: View a summary of unused permissions, total permissions, criticality of permissions and unused permissions. The criticality is determined by the excessive permission granted to the user through the roles attached to the User. The details panel also shows when the user was last active, User ARN, and account ID. The Summary tab also shows that if the user is Compromised or Potential Compromised.\nSysdig does not automatically mark a user as Compromised. After you review a Potentially Compromised User in the Identity 360 panel, you can use the status actions to keep the user\u0026rsquo;s state and the associated Risk finding in sync:\nRespond:\nMark as Compromised – confirm that the user is compromised. Mark as Compromise Resolved – indicate that you have completed remediation and the compromise has been addressed. Remove Potentially Compromised flag – clear the flag if you determine it was a false positive; this also clears the associated Potentially Compromised User Risk finding. Remove Compromised Flag – revert a user from Compromised back to Potentially Compromised when appropriate. Remediation Strategies: Provides two high level strategies to mitigate the risk.\nIn the Identity 360 panel for a Potentially Compromised or Compromised user, the Remediate tab shows the Contain Compromise remediation strategy, including the following options: * Add Restrictive Policy for IP * Deactivate User * Delete User * Force Password Reset * Delete \u0026amp; Create New Access Keys\nConsolidate and Reduce Permissions : Create a new custom IAM Policy for the User with a subset of only used permissions. Select a strategy you prefer.\nFor example, if you decide to delete the user, mouse over Delete User and click View Remediation.\nView the remediation instructions for both AWS Management Console and AWS CLI. Click Open in Console to open the AWS Management Console to perform the actions given in the remediation instructions. Optionally, you can perform the operations using the AWS CLI.\nIf you want to consolidate and reduce the permissions assigned to the user, click View Remediation button next to the Create a new custom IAM Policy for this User with a subset of only used permissions option.\nReview the IAM policies and instructions to create a new IAM policy. Click Open in Console to open the AWS Management Console to perform the actions given in the remediation instructions. Return to Sysdig Secure UI and mark the AWS IAM user as Compromise Resolved, as given in step 5.\nRisks Terminology Term Definition Finding A resource and its condition or behavior. For example, a cloud resource and its misconfiguration, or a container with a vulnerability. Finding Categories The different types of security issues that contribute to a risk. Current categories include: VulnerabilityDetectionInsecure ConfigurationInsecure IdentityPublicly ExposedAISensitive Data Finding Type An instance of a finding category. For example: Finding Category = Insecure Config Finding Types = Failed control “S3 bucket accepts HTTP”, failed control “EC2 is permissive”\nFinding Category = Insecure Identity\nFinding Types = Role with unused critical permissions, User without MFA High-Confidence Event An event detected from a Sysdig Threat Intelligence or Threat Detection policy. These are managed by the Sysdig Threat Research team, contain only high-severity rules, and have a low level of false positives. Live A high-confidence event was detected within the last 3 hours. Risk Definition The explicit combination of findings that, when matched, will generate a risk finding. This can be either a Managed or Custom definition. Severity Significance of a risk, expressed in terms of the combination of consequences to the business and the likelihood of those consequences. Zones A business group of resources, defined by a collection of scopes of various resource types. For example: Dev- all my development resources. ","url":"https://docs.sysdig.com/en/sysdig-secure/risks/"},{"id":126,"title":"Secure Subscription","content":"To access the Subscription page:\nLog in as administrator to Sysdig Secure.\nSelect Settings \u0026gt; Subscription via the user menu in the bottom left corner.\nYour current subscription information is displayed.\nIf you also have access to Sysdig Monitor, you can see its subscription details by clicking the Go to Monitor button on the top right. Read about the content of that page in Monitor Subscription.\nSubscription DetailsUnder Subscription Details, you can find:\nYour product: Sysdig Monitor, or Sysdig Platform (Sysdig Secure and Sysdig Monitor). Your tier. The contract billing cycle. The number of reserved and on-demand resources included in your Sysdig subscription. Specifically regarding the Secure product: Units Host Agents (alternative to Units) Serverless agents (alternative to Units) Sysdig Sage prompts Runtime Data Retention Download UsageOn the Subscription page, click Download Usage to download usage history for:\nThe current month to date. The current month to date \u0026amp; the previous month. The current month to date \u0026amp; the previous two months. The current month to date \u0026amp; the previous six months. This information is formatted as a comma-separated values (CSV) file. Details about the content are available in Reference: Usage report content.\nUsageUnder the Subscription Details section, you can find the usage for each resource included in your subscription, depending on the product.\nPlatform subscriptions will have Monitor and Secure resources in their entitlement.\nMonitor and Secure resources (related to both, depending on the Product and Tier):\nHost Agents: Reserved and on-demand host agents. See Host Agent Licenses. Active host agents deployment type overview: Currently connected agents breakdown per deployment type. See Active host agents deployment type overview. Host Agents - Previous Hour: Reserved and on-demand for the previous hour. Monitor resources:\nTime Series - Previous Hour: Applicable to Monitor only. See Time Series Billing. Secure resources:\nUnits: Number of units connected. See Units. Compute Resources: Number of Compute Resources across all Cloud accounts. See Compute Resources. Cloud Logs - Month to Date: Number of analyzed log events per month. See Cloud Logs. Container as a Service usage: Container as a Service (CaaS) usage month to date (AWS Fargate, Google Cloud Run, and Azure Container Apps). Applicable to Secure only. See CaaS usage. Sysdig Sage: Number of prompts submitted for the current month, over the available entitlement. For more details, see Sysdig Sage. UnitsDepending on your subscription tier, the Unit section may be visible. Here, you can compare Unit usage and entitlement.\nThe bar on the left shows the connected Units over those reserved. The bar on the right on the right shows the on-demand Units, if included in the subscription. Units exceeding the reserved entitlement will show up as On-demand Units being used. The bottom left displays a resource breakdown. Use this to learn how the Units are allocated across the different resource types in the environment: Hosts, Serverless Container instances and Serverless Functions The bottom right illustrates a further break down where you can see how units are connected for each different resource type. This helps you getting the most of your licensing, ensuring all the resources have the full coverage. Units round up to the nearest whole number.\nHistoricalAt the bottom of the Units section, you can review how unit consumption has evolved over time to monitor trends, evaluate changes in entitlement, or forecast future needs.\nView daily usage for the last 30 days or monthly usage for the last 6 months. Analyze usage by resource type, for example, Hosts, Serverless Containers, and Serverless Functions. You can also switch the view to by integration type to compare Shield and Agentless Unit consumption.\nBy Resource By Integration Host AgentsHost agents entitlement and usage is reported in two sections:\nHost Agents - Current Usage Active host agents deployment type overview Current UsageThe section displays the number of currently connected agents, compared to the entitlement.\nThe bar on the left represents the agents included in the subscription, showing you how many slots you're currently using, compared to those that are available.\nOn the right, the on-demand bar shows you how many additional agents you can connect, on top of the reserved entitlement. If your contract doesn't include on-demand usage, this will be disabled, meaning that you can only fill the reserved available slots, after which, additional connections will be refused.\nActive Host Agents Deployment Type Overview This bar breaks down the currently deployed agents into different types:\nContainerised: The number of agents running in a containerized environment. Non-containerised - The number of agents running in a non-containerised environment. Unspecified - The number of agents running in an unknown environment. Update Sysdig Agent to version 12.18.0 or later to receive environment information. Agent ConnectionsAgents connect on a first-come, first-served basis. In the event of an over-subscription (more agents wanting to communicate than are licensed), they will attempt to reconnect on a periodic basis. Once an existing communicating instance goes down and disconnects, the next agent in the queue will connect.\nWhen shutting down a host for any reason, the agent's license will not be immediately released. This permits the agent to retain its licensing slot for short outages or a reboot. The time-out interval can take up to 20 minutes, and if the connection has not been re-established within the interval the license will be released for use by the next host waiting to connect.\nThe distinction between reserved and on-demand agents is financial, not technical; when on-demand agents are used they perform exactly like reserved agents.\nCompute ResourcesThe Compute Resources bar displays the number of compute instances in the connected Cloud accounts and the Compute Resources in your entitlement.\nThis amount is regularly refreshed and based on the resources in Inventory.\nCloud LogsThe Cloud Logs section displays the amount of logs processed based on your entitlement and the integrations enabled in your environment.\nDepending on your subscription, you can view different indicators:\nMonth to Date: Shows the logs processed in the current month compared to your total entitlement. Monthly Trend: Shows how log usage has evolved across different cloud providers over the last 6 months. Month to Date Monthly Trend The amount this entitlement refers to is the number of log entries the customer sends from their environment to Sysdig for processing. This therefore doesn\u0026rsquo;t include anything processed locally by components such as the Sysdig Shield.\nUsing the three-dots menu on the right, you can download a 6-month usage report, including the data up to the current month-to-date.\nFor more details about the content available, see Reference: Usage report content.\nContainer as a Service usageThe Container as a Service (CaaS) usage bars display the individual usage of each CaaS type, and the remaining availability, for the current month to date.\nThree types of CaaS are supported by Sysdig:\nAWS ECS Fargate, metered per Task Google Cloud Run Container-type Services, metered per instance Azure Container Apps, metered per replica Sysdig only displays the types that are applicable to you, for which we have recorded usage.\nThe entitlement is provided in instances-hours for the month. Each instance connected consumes this availability, with minute-level granularity:\n2 instances connected for 60 minutes count as 2-instances-hour 2 instances, connected for a total of 30 minutes during the hour, each, count as 1-instance-hour See Linux on Serverless for more information about serverless agents.\nSysdig SageSysdig Sage is metered per prompt. The bar will show the prompts inputted by users over those included in the subscription for the current month.\nThe following chart displays the Used vs. Available interactions over the last 6 months. You can monitor usage trends and plan for additional add-ons if needed.\nLearn more about Sysdig Sage in here.\nReference: Usage report contentThe Usage report contains data across all the different meters in the page, therefore being based on what\u0026rsquo;s included in the entitlement:\nStandard Columns, available to everyone Time Series Billing Columns, available when Time Series billing is enabled (Platform customers only) Container as a Service Columns, available when Serverless agents are included in the subscription Sysdig Sage Columns, available when Sysdig Sage is included in the subscription The report has one row per hour, sorted from the most to the least recent. Standard ColumnsEvery usage history CSV file has the following columns:\nField name Description customer_id Internal Customer ID time_from Start time for the hourly usage record (UTC) time_to End time for the hourly usage record (UTC) units_used Units connected, across all resources and integrations reserved_agents Agents included in the license base entitlement on_demand_agents_connected Connected on-demand agents for the given period total_agents_connected Connected agents, either reserved or on-demand on_demand_agents_limit Limit of additional on-demand agents that can be connected cloud_logs_used Volume of logs ingested since the beginning of the month compute_resource_limit Compute resources included in the entitlement. 0 for Unit-based licenses ec2_instances_used Number of AWS hosts connected as of the last scan compute_instances_used Number of GCP and OCP hosts connected as of the last scan virtual_machines_used Number of Azure hosts as of the last scan cspm_total_compute_resource_count Total amount of Cloud hosts connected as of the last scan, for Unit-based licenses agentless_ecs_container_count Number of ECS Fargate Tasks connected as of the last scan, for Unit-based licenses agentless_cloud_run_container_count Number of Google Cloud Run container instances as of the last scan, for Unit-based licenses agentless_azure_container_count Number of Azure Container Apps, as of the last scan, for Unit-based licenses agentless_caas_count Total number of Container as a Service instances as of the last scan, for Unit-based licenses agentless_lambda_function_count Number of FaaS instances in AWS as of the last scan, for Unit-based licenses agentless_cloud_function_count Number of FaaS instances in GCP as of the last scan, for Unit-based licenses agentless_azure_function_count Number of FaaS instances in Azure as of the last scan, for Unit-based licenses agentless_faas_count Total amount of FaaS instances connected as of the last scan, for Unit-based licenses Time Series Billing ColumnsThe following columns are found in the usage history file when time series billing is enabled, in Platform subscriptions:\nField name Description included_timeseries_per_agent Time series per hour included in the agent price prepaid_timeseries Pre-paid time series per hour total_reserved_timeseries Total entitled time series per hour (included in the agent price and pre-paid) total_used_timeseries Time series ingested during the hour used_timeseries_over_reserved Time series overage (over total entitled) Container as a Service ColumnsThe following columns are available in the usage history file when Container as a Service (CaaS) billing is enabled, for non-Units-based subscriptions:\nField name Description ecs_fargate_agent_usage_minutes Sum of all Fargate Agent workload minutes during the hour gcp_run_agent_usage_minutes Sum of all Google Cloud Run Agent minutes during the hour aca_agent_usage_minutes Sum of all Amazon Container Apps Agent minutes during the hour agent_caas_minutes Sum of all Amazon Container Apps Agent minutes during the hour Sysdig Sage ColumnsThe following columns are available in the usage history file when Sysdig Sage is enabled:\nField name Description sage_prompts_limit Maximum number of allowed prompts sage_prompts_used Used number of prompts Reference: Cloud Logs report contentThe report contains a row per day, with the sum of cloud logs Sysdig received for that day The following columns are available in the Cloud Logs usage report:\nField name Description date Day the logs refer to cloud_logs_used Log volume for date across all integrations ","url":"https://docs.sysdig.com/en/docs/administration/subscription/secure-sub/"},{"id":127,"title":"Linux on Serverless","content":"The Serverless Agent comes as a single Docker image called workload-agent, available at quay.io/sysdig/workload-agent.\nSysdig provides several deployment options for the Serverless Agent, tailored to various serverless environments.\nAs an alternative to the platform-specific methods, the Serverless Workload Agent can be even integrated into the workload container image during the build process, allowing for seamless deployment. For guidance on this integration approach, see Embed Workload Agent.\nTo better understand how the Serverless Agent operates in serverless environments, see Understand Serverless Agent Drivers.\nSupported Platforms Install on Azure Container Apps Install on Google Cloud Run Service Install on AWS ECS Fargate ","url":"https://docs.sysdig.com/en/sysdig-secure/linux-on-serverless/"},{"id":128,"title":"Source Code Management","content":"IntroductionDepending on the scan results, organizations can configure their repository platform to either allow or block the merging of the PR. Additionally, the information provided within the PR highlights specific areas of concern, assisting you in timely remediation.\nFor more information:\nSee the Iac Supportability Matrix to review the resources and file types currently supported.\nSee IaC Policy Controls for policy details.\nBenefits and Use CasesInfrastructure as Code helps move security protocols and standards down into the development pipeline, highlighting and resolving potential issues as early as possible in the development process. This benefits many players within the organization:\nSecurity and compliance personnel see reductions in violations and security risks DevOps managers can streamline processes and secure the pipeline Developers can detect issues early and have clear guidance on how to remediate them with minimal effort. Process OverviewSysdig currently supports GitHub, Bitbucket, GitLab, and Azure DevOps integrations.\nConfigure the Integration\nAn administrator configures an integration from the Source Code Management (SCM) page and sets up the parameters for the supported providers. When the SCM integration is ready, add Git Sources that define the parts of the source to protect.\nThe repositories (selected from the list) The folders within each repo (or all folders using/) The branch pattern (for pull request evaluations only) Run Scan and Check Results\nWhen you configure an integration and run a scan, the Pull Request Check Report contains the results in, for example, GitHub.\nSet up a Git Integration Log in to Sysdig Secure as administrator and select Integrations \u0026gt; Source Code Management.\nIf no integration has ever been added, the page is empty.\nIf integrations already exist, the Git Integrations List page is displayed showing the Integration name, the Status, and the availability of IaC Scanning and Threat Detection.\nClick Add Git Integration.\nSelect the relevant integration type from the drop-down and begin the configuration, depending on the provider type.\nGitHub The setup steps must be completed by an Admin both of the target GitHub organization and of Sysdig Secure.\nThreat detection is not available on personal accounts.\nThis configuration toggles between the Sysdig Secure interface and the GitHub interface.\nFrom the Git Integrations List page, choose GitHub and:\nSelect if you want to enable both IaC and Threat Detection or only IaC.\nEnter an Integration Name and click Complete in GitHub.\nThe GitHub interface opens in a new tab.\nSign in to GitHub, select where to install the Sysdig GitHub app, and select the target organization.\nSelect All Repositories or define chosen repos and click Install.\nYou will be redirected to the Integrations page in Sysdig Secure when installation is complete. The Integration Status should show Active. Continue with Validation and Add Git Sources.\nBitbucketPrerequisites Open your Bitbucket organization and create a designated account for Sysdig. Configure the account\u0026rsquo;s access for the relevant workspace. Create a new app password for the account: Navigate to Personal Settings \u0026gt; App passwords, then click Create app password. Assign the following permissions: Account: Read Repositories: Read, Write, Admin Pull requests: Read, Write Webhooks: Read and write Click Create. Add Bitbucket Integration In Sysdig, navigate to the Git Integration screen.\nClick Add Git Integration and choose Bitbucket.\nFill in the details including the created app password from the prerequisites step. You can find the Workspace ID in the Bitbucket workspace settings:\nClick Add to complete.\nYou will be redirected to the Integrations page in Sysdig Secure when installation is complete. The Integration Status should show Active. Continue with Validation and Add Git Sources.\nGitLabPrerequisites in GitLab UI: Log in to your GitLab organization and create a designated account for Sysdig Secure Configure the account\u0026rsquo;s access for Projects Create a unique personal access token, setting a: Unique name for the token Token expiration date The following scopes for the token: api read_repository write_repository Copy the token value Add the IntegrationFrom the Git Integrations List page, choose GitLab and:\nEnter an Integration Name and the Token from the prerequisite step.\nClick Test Connection, then click Add. You will be redirected to the Integrations page in Sysdig Secure when installation is complete. The Integration Status should show Active. Continue with Validation and Add Git Sources.\nAzure DevOpsPrerequisites in Azure DevOps UI Log in to your Azure DevOps organization and create a designated account for Sysdig Secure.\nAccount Access: Configure the account\u0026rsquo;s access for Repositories and Projects\nAccount Subscription Permissions: Assign View, Edit, and Delete subscriptions permissions to the account.\nHINT: To grant the required subscription access using the Azure CLI:\nServiceHooks Namespace: Run az devops security permission namespace list --output table and record the ServiceHooks namespace ID. PublisherSecurity Token: Run az devops security permission update --allow-bit 7 --namespace-id {{ServiceHooks namespace Id}} --subject {{accountUserEmail}} --token PublisherSecurity --output table Personal Access Token: Retrieve a unique personal access token Record the token value Token Scope: Set to Custom Defined. Code Scope: Choose Read, Write, and Status permissions. Extensions Scope: Choose Read permission. For additional help, see the Azure DevOps documentation. Add the IntegrationFrom the Git Integrations List page, choose Azure DevOps and:\nEnter an Integration Name, Organization Name, and Personal Access Token` from the prerequisite step.\nClick Test Connection, then click Add. You will be redirected to the Integrations page in Sysdig Secure when installation is complete. The Integration Status should show Active. Continue with Validation and Adding Git Sources.\nValidate the Git IntegrationAfter adding a Git Integration, you will need to add Git Sources for IaC.\nAll configured integrations are also visible in the Integrations \u0026gt; Source Code Management page. Click an entry to open the configuration page for the integration.\nThe status and details of the Git Integration are displayed both at the top of the configuration page and in the list.\nIntegration StatusYou can review the Status field as a column on the Integrations List page or the configuration page. It shows any issues in the connection between Sysdig Secure and the Sysdig Git provider:\nActive: Everything is working as expected. Not Installed (Only GitHub): The Sysdig GitHub App is not installed. Suspended (Only GitHub): The Sysdig GitHub App is suspended and needs to be resumed. The Threat Detection column can have the following statuses:\nNot available: Threat Detection is not supported (only GitHub currently). Not Enabled: See Enable or Disable Threat Detection Enabled: Threat Detection is enabled and receiving events. Error: See Troubleshoot Threat Detection Last Scanned DateAs soon as the integration is fully configured and active, a scan will be run. The Last Scanned field is updated after every scan (every 24 hours by default).\nAdditional OptionsFrom the Integrations List page, you can use the burger (3-dot) menu for additional options on an integration.\nManage Integration: Open the Git integration configuration page (click on the row in the list).\nStart Code Scan: Use this option to manually trigger a scan before the default 24-hour time is reached.\nEnable/Disable Threat Detection (GitHub only): See the Enable or Disable Threat Detection paragraph\nConfigure in GitHub (GitHub Only): Open the Sysdig application configuration page in GitHub.\nDelete: This action deletes the Git integration and all the associated sources as well.\nAdd Git SourcesGit Sources let you define the repositories, folders, and branch patterns to scan within. First, you need to connect with a Git Provider as described above. Then, you can add Git Sources from the Git Integration configuration page:\nLog in to Sysdig Secure, and select Integrations \u0026gt; Source Code Management.\nSelect a Git Integration from the list.\nThe Git Integration configuration page will open.\nClick Add Source.\nProvide a Name for the source. The name will help you identify this source and can be anything such as Prod us-east cloud resources.\nChoose a Repository and one or more Folders to be scanned. The system automatically checks that valid folder names have been entered.\nDefine the Branches where Sysdig should run a Pull Request evaluation check. You need to provide a regular expression, and Sysdig will run the check on every branch having a name that matches the regular expression. You can use the expression .* to check PRs on all branches or use a fixed name such as main.\nClick Add Source. The new source will be displayed in the list.\nRepeat to add as many sources as needed and click Close when done.\nThreat Detection OptionEnable or Disable Threat DetectionOnly available for GitHub. Enable Threat Detection to to forward GitHub events to Sysdig, and perform Threat Detection on events.\nIn Sysdig Secure, go to Integrations \u0026gt; Source Code Management.\nClick the three dot menu icon.\nSelect Enable/Disable Threat Detection.\nThreat Detection will stop working if you choose Disable, but your data and related information for IaC scanning will remain available.\nThreat Detection on GitHubSysdig relies on an additional organizational webhook to perform threat detection on your GitHub organization. GitHub sends events of different event categories through organizational webhooks. Sysdig configures the webhook to receive events of the following categories:\nBranch protection rule Code scanning alert Check run Check suite Deploy key Deployment Fork Membership Organization Org block Page build Public Pull request Push Release Repository Repository advisory Repository imports Security and analysis Secret scanning alert Secret scanning alert location Team Team add Workflow run This means that you will be able to perform detection on these categories of events, either through managed or custom rules. See GitHub documentation.\nTroubleshoot Threat DetectionIf Threat Detection for GitHub is not working as expected, troubleshoot using the following steps:\nCheck the Sysdig Application is installed in your GitHub Organization. Log in as the Org Administrator and navigate to GitHub Apps under your organization\u0026rsquo;s Developer Settings Ensure the Sysdig GitHub application is installed. Check the webhook is present and correctly configured Log in as the Org Administrator and navigate to Webhooks under your organization\u0026rsquo;s Developer Settings Ensure a webhook exists with a Payload URL pointing to a Sysdig domain. Click Edit on the webhook and ensure the following: The Payload URL points to the Sysdig domain for the correct Sysdig region. Under Event Types, Let me select individual events is selected, and the selected event types match the list above. The webhook is active. Pull Request Policy EvaluationFor the branches defined in Git Sources, Sysdig will run a Pull Request Policy Evaluation check. The check scans the Infrastructure-as-Code files in the pull request and identifies violations against the predefined policies.\nThe result of the check contains the list of violations, their severity, and the failed resources list per file.\nExample output for GitHub:\n","url":"https://docs.sysdig.com/en/sysdig-secure/source-code-management/"},{"id":129,"title":"Subscription","content":"To access the Subscription page:\nLog in as administrator to Sysdig Monitor or Sysdig Secure.\nSelect Settings \u0026gt; Subscription via the user menu in the bottom left corner.\nYour current subscription information is displayed.\nSubscription DetailsUnder Subscription Details, you can find:\nYour product: Sysdig Monitor, or Sysdig Platform (Sysdig Secure and Sysdig Monitor). Your tier. The contract billing cycle. The type and number of reserved and on-demand resources included in your Sysdig subscription. UsageUnder the Subscription Details section, you can find the usage for each resource included in your subscription, depending on the product.\nPlatform subscriptions will have Monitor and Secure resources in their entitlement.\nMonitor and Secure resources (related to both, depending on the Product and Tier):\nHost Agents: Reserved and on-demand host agents. See Host Agent Licenses. Active host agents deployment type overview: Currently connected agents breakdown per deployment type. See Active host agents deployment type overview. Host Agents - Previous Hour: Reserved and on-demand for the previous hour. Monitor resources:\nTime Series - Previous Hour: Applicable to Monitor only. See Time Series Billing. Secure resources:\nUnits: Number of units connected. See Units. Compute Resources: Number of Compute Resources across all Cloud accounts. See Compute Resources. Sysdig Sage: Number of used interactions for the current month, over the entitlement. For more details, see Sysdig Sage. Cloud Logs - Month to Date: Number of analyzed log events per month. See Cloud Logs. Container as a Service usage: Container as a Service (CaaS) usage month to date (AWS Fargate, Google Cloud Run, and Azure Container Apps). Applicable to Secure only. See CaaS usage. Sysdig Sage: Number of prompts submitted for the current month, over the available entitlement. For more details, see Sysdig Sage. Host AgentsHost agents entitlement and usage is reported in two sections:\nHost Agents - Current Usage Active host agents deployment type overview Current UsageThe section displays the number of currently connected agents, compared to the entitlement.\nThe bar on the left represents the agents included in the subscription, showing you how many slots you're currently using, compared to those that are available.\nOn the right, the on-demand bar shows you how many additional agents you can connect, on top of the reserved entitlement. If your contract doesn't include on-demand usage, this will be disabled, meaning that you can only fill the reserved available slots, after which, additional connections will be refused.\nActive Host Agents Deployment Type Overview This bar breaks down the currently deployed agents into different types:\nContainerised: The number of agents running in a containerized environment. Non-containerised - The number of agents running in a non-containerised environment. Unspecified - The number of agents running in an unknown environment. Update Sysdig Agent to version 12.18.0 or later to receive environment information. Agent ConnectionsAgents connect on a first-come, first-served basis. In the event of an over-subscription (more agents wanting to communicate than are licensed), they will attempt to reconnect on a periodic basis. Once an existing communicating instance goes down and disconnects, the next agent in the queue will connect.\nWhen shutting down a host for any reason, the agent's license will not be immediately released. This permits the agent to retain its licensing slot for short outages or a reboot. The time-out interval can take up to 20 minutes, and if the connection has not been re-established within the interval the license will be released for use by the next host waiting to connect.\nThe distinction between reserved and on-demand agents is financial, not technical; when on-demand agents are used they perform exactly like reserved agents.\n","url":"https://docs.sysdig.com/en/administration/subscription/"},{"id":130,"title":"Troubleshoot Cluster Shield","content":"For an overview of Cluster Shield and installation instructions, see Install Shield on Kubernetes.\nAPI Slowness in EKSOverviewIf you experience slowness with the Kubernetes API server in an Elastic Kubernetes Service (EKS) cluster, and you have Cluster Shield with the Audit feature enabled, the issue could be related to connectivity problems between the EKS control plane and the audit webhook endpoint.\nAPI slowness occurs because every API call to the Kubernetes API server must be validated by admission controllers before processing. These controllers enforce security and compliance checks on incoming requests.\nIf the admission controllers are unreachable—often due to networking issues preventing the EKS control plane from reaching the webhook endpoints—the API server waits while attempting to contact them. This waiting leads to retries and timeouts, significantly slowing down API response times. To prevent this, ensure that the admission controllers are accessible and properly connected.\nSolutionTo ensure proper connectivity and prevent slowness, do the following:\nAllow API Server Connectivity to Pods:\nFor Cluster Shield\u0026rsquo;s Audit feature to function efficiently, the Kubernetes API server must be able to connect to the webhook endpoint.\nIn EKS, where a custom Container Network Interface (CNI) may block direct communication, ensure that the necessary ports are open and accessible\nAudit uses the port 6443 by default. Admission Control uses the port 8443 by default. To customize these ports, see CNI on EKS.\nUpdate Security Group Rules:\nUpdate the inbound rules for the Security Group associated with your EKS worker nodes to allow TCP traffic on the Audit port. 6443 is the default port used by Cluster Shield Audit. Ensure that the source of this traffic is the EKS cluster\u0026rsquo;s control plane security group. This configuration allows the API server to reach the audit webhook endpoint without unnecessary delays.\nSecurity Group Inbound Rule Requirements:\nProtocol: TCP Port: The port you specified for Cluster Shield Audit. 6443 is the default port. Source: The EKS cluster\u0026rsquo;s control plane security group If you have also enabled the admission control feature of Cluster Shield, ensure that the TCP traffic on the admission controller port is allowed. 8443 is the default port for admission controller.\nCNI on EKSAt times, you may need to change the default ports for Cluster Shield\u0026rsquo;s Audit and Admission Controller.\nFor instance, when using a custom Container Network Interface (CNI) on EKS, the API server may not be able to reach the webhook endpoint. This occurs because the control plane cannot be configured to run on a custom CNI in EKS.\nTo resolve this issue, when installing Cluster Shield via Helm, apply the following configurations:\ncluster: host_network: true features: admission_control: enabled: true http_port: 6000 # Or any other open and unused port \u0026gt; 1024 detections: kubernetes_audit: enabled: true http_port: 5000 # Or any other open and unused port \u0026gt; 1024 Update the inbound rule in the EKS worker nodes security group, allowing TCP communication on the ports you specified from the EKS cluster security group. In this example, the ports you allow TCP communication are 5000 and 6000.\nFailure Creating/Updating Control Plane NodesOverviewSome Kubernetes distributions started using Cluster API and allow kubeadm to talk directly with the local node API, making it unnecessary to wait for the CNI to come up before provisioning the node. Consequently, this means that the resources start getting created and reach out to the ValidatingWebhook for approval. Our ValidatingWebhook is implemented as a Deployment, and it doesn\u0026rsquo;t need to be on every node, or consume all those resources. This means the CNI needs to be available for a new node to contact it. The ValidatingWebhook should be configured to ignore failures, but due to concurrent timeouts, in some cases that might make the node provisioning fail.\nSee the related KB article for vSphere Kubernetes here.\nSolution 1 - Temporarily Disable the ValidatingWebhookBefore provisioning new Control plane nodes (which includes upgrading them), you can temporarily disable the ValidatingWebhook and re-enable it afterward.\nSet the features.detections.kubernetes_audit.enabled to false features: detections: kubernetes_audit: enabled: false Provision the new node and wait for it to be ready Revert the change made at point 1: set features.detections.kubernetes_audit.enabled to true features: detections: kubernetes_audit: enabled: true This is a temporary solution, that must be executed every time you provision new nodes that are part of the Control plane. It creates a complete blind spot on detections based on Kubernetes actions, but only for a short time.\nSolution 2 - Exclude Sensitive Namespaces from the ValidatingWebhookYou can tune the ValidatingWebhook to be bypassed for components required for node provisioning. This can be done either by ignoring namespaces, or by refining the ValidatingWebhook rule. The resources to bypass and how to bypass them depend on each single distribution. To understand it, you need to inspect the logs and see what resources fail to be provisioned.\nTo ignore namespaces, use features.detections.kubernetes_audit.excluded_namespaces attribute in the Shield chart and add those you want to exclude. For instance, with kube-system:\nfeatures: detections: kubernetes_audit: excluded_namespaces: - kube-system You can also customize the ValidatingWebhook rule. For instance, to exclude Cluster-scoped resources:\nfeatures: detections: kubernetes_audit: webhook_rules: # +doc-gen:break - apiGroups: - \u0026#34;\u0026#34; - apps - autoscaling - batch - networking.k8s.io - rbac.authorization.k8s.io - extensions apiVersions: - \u0026#39;*\u0026#39; operations: - \u0026#39;*\u0026#39; resources: - \u0026#39;*/*\u0026#39; scope: Namespaced This is a longer-term solution, but it requires more effort and tuning to be set up. It\u0026rsquo;s also creating a persistent blind-spot, even if narrower.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/onboarding/kubernetes/cluster-shield-troubleshooting/"},{"id":131,"title":"View Agent Health","content":"Readiness Probe for Sysdig AgentKubernetes uses readiness or liveness probes to determine the readiness or live status of a pod. Similar functionality is present in Sysdig Agent versions preceding v12.17.0, where the readiness state of the agent pod can be determined by checking for the existence of a file named running in the /opt/draios/logs directory. The presence of the running file indicates that the agent is connected both to the Sysdig backend and the Kubernetes API server.\nIn Sysdig Agent version 12.17.0, an HTTP port can be employed to query its health status, aligning with the convention followed by typical Kubernetes services. Beyond assessing backend and API server connectivity, this health status considers the stability and running status of all its sub-processes. In version 12.17.0, the health service defaults to listening on port 24483 across all host interface addresses.\nStarting from agent version 12.19.0, the default behavior was modified to have the health service exclusively listen on the localhost (127.0.0.1) address.\nTo adjust the host address to listen to, specify the the following configuration in the dragent.yaml file.\nstatus_host: 127.0.0.1 To change the port to listen to, add the following:\nstatus_port: 24483 Starting from Helm chart v1.18.1, the new HTTP-based readiness endpoint is enabled by default.\nIf you are not using our Helm charts to install the agent, you can configure the readiness probe manually by adding the following configuration to the daemonset specification:\nreadinessProbe: failureThreshold: 3 httpGet: host: 127.0.0.1 path: /healthz port: 24483 initialDelaySeconds: 90 periodSeconds: 10 timeoutSeconds: 2 The initial delay can be customized depending on the typical time it takes for the agents to become ready in your cluster. This duration typically varies based on cluster size and the number of entities that the agents need to download initially to obtain the complete state of the cluster.\nCollect Agent Health MetricsYou can export agent metrics using the Sysdig Agent Prometheus exporter. These metrics serve as a valuable tool for troubleshooting and retrieving status information from the agent, especially in scenarios where it encounters difficulties connecting to the backend.\nEnable the Agent Prometheus ExporterTo enable the exporter using our Helm chart, set the following in your values.yaml:\nagent: sysdig: settings: prometheus_exporter: enabled: true export_health_metrics: true To enable the exporter, add the following to the dragent.yaml:\nprometheus_exporter: enabled: true By default the prometheus exporter will listen on port 9544 by using the standard path, /metrics.\nTo change the port or IP address to listen to, you can use the listen_url configuration parameter. For example:\nprometheus_exporter: listen_url: 127.0.0.1:9544 Enable AuthenticationTo enable basic authentication in Prometheus Exporter, add the following to your values.yaml file:\nagent: sysdig: settings: prometheus_exporter: enabled: true export_health_metrics: true basic_auth_users: \u0026lt;promuser\u0026gt;: \u0026lt;bcrypt-password-hash\u0026gt; Replace and with the the credentials required to connect to Prometheus. Passwords must be hashed with bcrypt.\nEnable TLS AuthenticationTo enable TLS authentication in Prometheus Exporter, add the following to your values.yaml file:\nagent: sysdig: settings: prometheus_exporter: enabled: true export_health_metrics: true basic_auth_users: \u0026lt;promuser\u0026gt;: \u0026lt;bcrypt-password-hash\u0026gt; tls_server_config: cert_file: /opt/draios/etc/kubernetes/certs/example.com/example.com.crt key_file: /opt/draios/etc/kubernetes/certs/example.com/example.com.key client_ca_file: /opt/draios/etc/kubernetes/certs/client.com/ca.pem client_auth_type: RequireAndVerifyClientCert Replace and with the the credentials required to connect to Prometheus. Passwords must be hashed with bcrypt.\nFor more information on basic_auth_users and tls_server_config, see web configuration.\nAgent Health MetricsOnce enabled, the agent\u0026rsquo;s Prometheus exporter will automatically export the following metrics:\ncontainer_cpu_used_percent container_file_time_in container_file_time_other container_file_time_out container_memory_bytes_used container_memory_swap_bytes_used host_cpu_idle_percent host_cpu_iowait_percent host_cpu_nice_percent host_cpu_stolen_percent host_cpu_system_percent host_cpu_used_percent host_cpu_user_percent host_file_time_in host_file_time_other host_file_time_out host_memory_bytes_available host_memory_bytes_total host_memory_bytes_used host_memory_bytes_virtual host_memory_swap_bytes_available host_memory_swap_bytes_total host_memory_swap_bytes_used promhttp_metric_handler_requests_in_flight promhttp_metric_handler_requests_total sysdig_sampling_ratio sysdig_up As of agent v12.19.0, you can export additional health metrics with:\nprometheus_exporter: enabled: true export_health_metrics: true You need to add the prometheus.io/scrape: \u0026quot;true\u0026quot; and prometheus.io/port: 9544 annotations to the agent daemonSet to allow the Agent’s Prometheus native service discovery to find the endpoint.\nThe additional metrics you can retrieve are:\nsysdig_agent_host_info: 1.0 host_hostname cluster_name agent_version agent_mode sysdig_agent_healthy: 1/0 sysdig_agent_connected: 1/0 sysdig_agent_connection_error_code: [0-5] agent_error backend_error_code backend_error_msg sysdig_agent_unlicensed: 1/0 sysdig_agent_analyzer_num_evts: \u0026lt;number\u0026gt; sysdig_agent_analyzer_dropped_evts: \u0026lt;number\u0026gt; host_uname: 1.0 machine_type kernel_name kernel_release kernel_version sysdig_agent_process_memory_kb: \u0026lt;memory used in kilo bytes \u0026gt; agent_process sysdig_agent_feature_enabled: \u0026lt;Use the agent_feature label to retrieve the list of features enabled\u0026gt; sysdig_agent_process_uptime_s: \u0026lt;Use the agent_process label to retrieve the process uptime in seconds\u0026gt; sysdig_agent_analyzer_num_evts sysdig_agent_analyzer_dropped_evts where\nsysdig_agent_host_info: always return a value of 1.\nsysdig_agent_healthy: returns either 1 or 0. 1 indicates that it is healthy.\nsysdig_agent_connected: returns either 1 or 0. 1 indicates that it is connected.\nsysdig_agent_unlicensed: returns either 1 or 0. 1 indicates that it is unlicensed.\nsysdig_agent_feature_enabled: returns either 1 or 0. 1 indicates that the feature is enabled.\nFor example:\nsysdig_agent_feature_enabled{agent_feature=\u0026quot;cointerface\u0026quot;} 1 sysdig_agent_feature_enabled{agent_feature=\u0026quot;jmx\u0026quot;} 0 [0-5] represents error codes returned by sysdig_agent_connection_error_code :\n0 - No Error 1 - I/O Exception 2 - Connection timed out 3 - Invalid argument 4 - Handshake error 5 - Invalid message received 6 - Error received from collector or backend ","url":"https://docs.sysdig.com/en/sysdig-secure/classic-agent-health/"},{"id":132,"title":"Vulnerability, Image Configuration and Content Rules","content":"Vulnerability RulesSeverities and ThreatsWhile scanning for vulnerabilities in software is a primary concern, it\u0026rsquo;s essential to recognize that reported vulnerabilities may not always be relevant to the specific production environment being analyzed. Moreover, achieving an environment completely devoid of vulnerabilities for a particular software package is unrealistic. Therefore, each organization establishes an acceptable risk threshold for a vulnerability. This threshold helps determine whether the evaluated asset falls within acceptable boundaries or should be considered non-compliant.\nSysdig enables you to assess severities and threats in hosts and workloads against the following conditions:\nParameter Condition(s) Description Severity - Equals\n- Greater than or equals Severity levels to verify against:\n- Critical\n- High\n- Medium\n- Low\n- Negligible CVSS Score - Equals\n- Greater than or equals CVSS scores to verify against numerical thresholds such as 5, 9.8, 10 Disclosure Date - Days\n- Date Range - Days: The number of days since the vulnerability was publicly disclosed. Specify when the disclosure date is older than or equal to this value.\n- Date Range: Choose a specific range of disclosure dates (e.g., Jun 01, 2025 to Jun 25, 2025). In Use True or False Detects at runtime only if the affected package is actively in use, as detected by Sysdig In-Use. Fixable - Days\n- Boolean\n- Boolean + Days Specify if and when a fix is available:\n- Boolean: Checks if a fix exists for the vulnerability.\n- Boolean + Days: Checks if a fix exists and if it has been available for a certain number of days. Rule fails if threshold is exceeded. Exploitability Metrics - Public exploit available\n- No administrative privileges required\n- No user interaction required\n- Network attack vector required\n- Packages - Public exploit available: Triggers rule if exploit code/tool exists.\n- No admin privileges: Rule fails if no admin privileges are needed to exploit.\n- No user interaction: Rule fails if no user interaction is needed.\n- Network attack vector: Rule fails if exploitable via the network.\nSee CVSS for details. Included in CISA KEV Rule/Filter Description Included in CISA KEV Flags vulnerabilities listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. CISA KEV available since X days ago Filters vulnerabilities based on how long they have been in the KEV Catalog, measured in days. CISA KEV due date in X days Flags on CISA-KEV Vulnerabilities that have a due date within the specified time, measured in days. Known to be used in Ransomware Campaigns Flags vulnerabilities that are known to be leveraged in ransomware attacks. Exploit Prediction Scoring System Rule/Filter Description EPSS Flags vulnerabilities with an Exploit Prediction Scoring System (EPSS) score, helping assess the likelihood of real-world exploitation. EPSS Score greater than or equals X % Filters vulnerabilities where the EPSS probability score meets or exceeds the specified percentage, indicating higher likelihood of exploitation. EPSS Percentile greater than or equals X % Filters vulnerabilities that fall within the top specified percentile of EPSS scores, focusing on vulnerabilities with the highest risk of exploitation. CVE Deny ListIf any vulnerability listed in this rule is detected, the rule will fail, regardless of severity or any other vulnerability attribute. e.g. CVE-2025-1974\nImage Configuration RulesAn OCI Image Configuration is a JSON document describing images for use with a container runtime and execution tool, and their relationship to filesystem changes. It comprises of image configuration details and metadata.\nFor example:\nEntrypoint / CMD Configured user Environment variables Labels Author Creation time Build history Dockerfiles VS Image Configuration: Dockerfiles specify a language used to generate the resulting image, which contain the mentioned Image Configuration file inside. Although Dockerfiles and Image Configuration files are closely related, they are not the same concept. Compliant Image Configuration files can be generated using development tools other than Docker/Dockerfiles.\nDefault UserThe default user configured to run the entrypoint or CMD.\nDefaulting to root is discouraged, as it can grant unnecessary privileges and make it easier for an attacker to escalate privileges or move laterally if successfully exploited.\nApart from avoiding root, this rule also allows specifying a particular user, for example jenkins, that must be set. Failing to set a user will result in rule failure.\nThe rule includes the following condition types that cause the policy to fail if detected:\nUser is root: Enforces not using root as the user of your container images. User is not: Enforces the usage of a specific user in the configuration. User in/not in: Enforces the usage or blocking of specific users in the configuration. Image LabelCheck for labels configured in the Image Configuration file.\nEnvironment VariablesCheck for environment variables configured in the Image Configuration file.\nRecommended InstructionsSysdig does not recommend use of the ADD instruction is discouraged. COPY is more predictable and less error prone.\nPackage Manager InstructionsThis rule prohibits the use of package manager instructions, following recommended security practices. Directly fetching the latest available version of a package using a package manager during image build can lead to non-reproducible builds, and therefore the practice is discouraged.\nThe following package managers and update subcommands are currently detected from the image build history:\nPackage Manager Upgrade Command Regex apk .apk upgrade. apt .apt-get upgrade. .apt upgrade. yum .yum upgrade. rpm .*rpm (\u0026ndash;upgrade pip .pip3 install (\u0026ndash;upgrade pipenv .pipenv update. poetry .poetry update. npm .npm update. yarn .yarn update. composer .composer update. cargo .cargo update. bundle .bundle update. gem .gem update. Image Creation DateThe creation date of an image can serve as an indicator that the image has become stale. The date is created as per OCI Image Configuration. As the image creation date is an optional attribute, this rule also fails if the date is not declared.\nSensitive Information and SecretsLeaking sensitive information is one of the most severe security issues and has often led to actual security breaches. By enabling this rule, the Image Configuration metadata will be parsed for sensitive strings.\nFor example, violation of an AWS secret found in the image label AWS_TOKEN includes the following:\nSecret Type Detection Pattern / Description AWS Secret - AKIA keys: AKIA[0-9A-Z]{16}\n- Any other key: aws.{0,20}?(?:key|pwd|pw|password|pass|token).{0,20}? Azure Storage Key N/A Basic Auth Detects [http,ssh]://user@pass:domain.com JWT Token N/A Private Keys Checks if string contains:\n- BEGIN DSA PRIVATE KEY\n- BEGIN EC PRIVATE KEY\n- BEGIN OPENSSH PRIVATE KEY\n- BEGIN PGP PRIVATE KEY BLOCK\n- BEGIN PRIVATE KEY\n- BEGIN RSA PRIVATE KEY\n- BEGIN SSH2 ENCRYPTED PRIVATE KEY\n- PuTTY-User-Key-File-2 The current implementation uses a simple pattern matching technique with a regex check for keywords. Consequently, there is a risk of false positives if the keywords appear elsewhere in the metadata, such as in a filename.\nImage ContentPackage Deny ListBlocks one or more packages. You can provide a specific version of a package. Enter the package using packagename or packagename x.x.x (including the version) format. Press tab or enter after each entry. When including the version, make sure to separate the package name and version with a single space, not a dash (-) or any other character. For example, libgnutls30 3.7.1-5+deb11u2.\n","url":"https://docs.sysdig.com/en/sysdig-secure/policies/vulnerability_policies/rules/"},{"id":133,"title":"Zones","content":"PrerequisitesBefore you create a zone, connect a Data Source to scan your infrastructure for the necessary data. See Enable Inventory Resources.\nIf you intend to filter by team, ensure you Enable Team Zones.\nDefault ZonesSysdig provides two zones by default:\nEntire Infrastructure: This applies to connected data sources. Create a new zone to update findings that are reported on the Compliance page. Entire Git: If you have configured Infrastructure as Code (IaC) scanning with Git integrations to your development pipeline in Git, then the Entire Git zone is automatically applied to those source repositories. You can also create more targeted zones for selected Git sources. You can create more Zones to suit your organization\u0026rsquo;s needs.\nCreate and Configure a ZoneA completed Zone includes:\nZone name and description Zone scope (the area of business to be included) To create a Zone:\nLog in to Sysdig Secure, and navigate to Inventory \u0026gt; Zones.\nClick New Zone.\nEnter a Name for the new zone.\n(Optional) Enter a Description.\nIn the Scope section, select Add Scope.\nSelect from the available platforms. These include AWS, GCP, Kubernetes, Git, and more.\nUse the All Resources toggle to determine whether the zone should include all the resources within the selected platform. It is enabled by default.\nTo define a more granular scope, toggle All Resources off. Then, specify the resources to include as key-value pairs. To define a more specific scope using key-value pairs, do the following:\nSelect a key/attribute:\nResource: These are pre-defined, and vary depending on the platform. For example, Account(AWS), Subscription (Azure),and Project (GCP). These align with cloud provider best practices and help prevent visibility gaps. For available resources, see Available Scope Rule Attributes Custom Label: Scope with tags and labels. This option is less optimal than scoping with platform-native resources. Select an operator:\nin: For exact matches. is not: For excluding matches. contains: For substring matches. does not contain: For excluding substring matches. For more details, see Use Operators and Values Enter one or more values.\nYou can define multiple scopes. They are combined using OR. Attributes within a scope are combined using AND. Click Save to save the Zone.\nYour saved zone will appear in the list on the main Zones page. Data from Zones may take up to 24 hours to appear in other modules, such as Inventory \u0026gt; All Resources.\nUse of the Region scope may result in more data being shown to users in the Posture \u0026gt; Identity Management pages than defined in the Zone.\nAvailable Scope Rule AttributesSupported scope rule attributes vary according to platform:\nAWS\nOrganization Account Region Labels Azure\nOrganization Subscription Region Labels GCP\nOrganization Project Region Labels OCI\nTenancy Compartment Region Labels Host\nCluster Host Name (for Docker, Linux hosts) Shield Tags Kubernetes\nDistribution (AKS, GKE, EKS, Vanilla Kubernetes) Cluster name Namespace Labels Shield Tags Git\nGit integration Git source(s) Image\nRegistry Repository Use Operators and ValuesAfter the key, you can use operators and values.\nSysdig supports the following operators:\nin Matches exact values. Use this to scope specific cluster names. For example, defining a scope, Cluster + in + prd, will only match the cluster prd, if it exists. You can match multiple values. For example, use the scope, Cluster + in + prd + demo, to include the clusters prd and demo. Cluster in prd includes only the prd cluster. Supports multiple values, For example, Cluster in prd, demo. contains Matches a value inside a string. Use this to scope cluster names containing a given value. Cluster contains prd matches clusters named myApp-prd, prd1, prd-sysdig. For example, defining a scope, Cluster + contains + prd, will include clusters such as myApp-prd, prd1, and prd-sysdig. is not Excludes resources that exactly match the specified value(s). Example: Cluster + is not + prd excludes the prd cluster from the Zone scope. does not contain Excludes resources containing the specified substring. Example: Cluster + does not contain + prd excludes clusters like test-prd or prd-east, and includes all others. Combining negative operators (is not, does not contain) with positive operators (in, contains) lets you define inclusion and exclusion rules for label-based scoping within a Zone.\nTo achieve finer control or more specific segmentation, use supported labels designed for Zones filtering (for example, kubernetes.namespace.name, cloud.account.id, etc.), rather than relying solely on negative operators.\nAfter the operator, select a value. Each value field has a limitation of 2048 characters per row. For longer values, consider adding scopes. This improves readability and maintenance of your scopes.\nAuto-complete values will be based on resources that were scanned and listed in the Inventory.\nKnown LimitationsThere are limits to the number of platforms, keys, and values supported per zone, as well as the number of zones supported per team. For example, you can define up to 25 keys (for example, Region) per zone. Each key can have one or more specific values (for example: Region in eu-central-1). You can define up to 50 values per key. In summary:\nThe maximum number of platforms that can be supported per zone is 20. The maximum number of keys that can be supported per zone is 25. The maximum number of values that can be supported per key is 50. Team Zones (CA) Team Zones is in Controlled Availability. Contact Sysdig Support to request access. This is an experimental feature, and will not work for Vulnerability Management (VM) and Threat Detection.\nTeam Zones allow you to limit the scope of certain teams, restricting what a team can see to what is strictly necessary. This boosts security, following the principle of minimal privilege.\nZones are designed to replace Team Scopes. Unlike Team Scopes, Zones only have to be defined once, and can then be applied at will. Zones work for agentless cloud resources, as well as agent resources.\nEnable Team ZonesOnce Sysdig Support has granted you access to this feature, Admin users can enable Team Zones:\nLog in to Sysdig Secure as an Admin.\nSelect Settings \u0026gt; User Profile.\nUnder Sysdig Labs, enable Zones based team scoping and Zones scoping for all features.\nClick Save.\nZones based team scoping is now enabled.\nApply a Team ZoneTo apply zones to teams:\nLog in to Sysdig Secure.\nSelect Settings \u0026gt; Teams\nSelect an existing team, or select Add team to create a new team.\nThe Team configuration page appears.\nUnder Zones, select All Zones, or select one or more zones under Selected Zones. If you do not select a zone, the scope will default to the configuration entered under Team Scopes.\n","url":"https://docs.sysdig.com/en/sysdig-secure/zones/"},{"id":134,"title":"Secure SaaS Release Notes","content":"December 23, 2020Sysdig Secure Jenkins Plugin v 2.1 ReleasedVersion 2.1 of the Sysdig Secure Jenkins Plugin has been released!\nNew\nSysdig Jenkins Plugin 2.1 leverages the inline scanner v2 under the hood, which improves the scanning performance and execution times.\nThis version also introduces proxy support for both master and worker nodes.\nDecember 16, 2020Node Image Analyzer v 0.1.7 ReleasedVersion 0.1.7 of the Node Image Analyzer has been released.\nThis release fixes image analysis errors for OpenShift clusters configured in FIPS mode.\nStatement RE: Solarwinds and Sysdig\u0026rsquo;s SecurityWe have seen requests for statements regarding tooling in the wake of the Solarwinds and related compromises. Sysdig does not use these tools internally. To maintain a secure SDLC process for own product we use Sysdig Secure as well as source code analysis tools. We also maintain our own branch of key OSS components to ensure software is fully vetted before it\u0026rsquo;s delivered to customers.\nDecember 14, 2020Perform Image Scanning as a GitHub ActionA new version of the Sysdig Secure inline scanning action has been released. This GitHub action allows you to perform image analysis on locally built container images.\nThe action uses the new secure-inline-scan 2.x, which provides better performance and more input options. See Inline Scan 2.2 Release Note.\nThe action provides the following benefits:\nImage evaluation results can be consumed using the Sysdig Secure UI or locally as check-run annotations.\nSupport for SARIF report output.\nThis provides native integration with GitHub\u0026rsquo;s code scanning, for example: executing the codeql-action/upload-sarif action.\nDecember 11, 2020New Runtime Policy Events JSON FormatThe JSON format for the runtime policy events has been upgraded to include full scope information, rule labels, and a single-line representation for the event field\u0026rsquo;s keys and values.\nTo preserve backwards compatibility with existing integrations, the former JSON format is still available (and used by default on migration).\nFrom the Event Forwarder page, under \u0026ldquo;Data to Send,\u0026rdquo; the old JSON format is labeled \u0026ldquo;Policy Events (Legacy)\u0026rdquo; and the new one as \u0026ldquo;Runtime Policy Events.\u0026rdquo;\nSee also: Event Forwarding.\nDecember 7, 2020Node Image Analyzer v 0.1.6 ReleasedVersion 0.1.6of the Node Image Analyzer has been released.\nNew\nProxy configuration supportRunning Node Image Analyzer Behind a Proxy\nAdded support to scan images that lack a Repo tag, such as OpenShift 4.x distribution images.\nFixes\nUpdated dependencies and base images to keep up with latest fixes December 2, 2020Inline Scanner v2.2Version 2.2 of the Inline Scanner has been released.\nNew:\nThe vulnerability report information has been added to the container output, together with the image details and policy evaluation\nWhen scanning an image using the digest pullstring, it will be stored using the truncated digest as a tag. For example:\npostgres@sha256:839d6212e7aadb9612fd216374279b72f494c9c4ec517b8e98d768ac9dd74a15 will show up in the interface as postgres:839d6212e7aa Fixed:\nFixed a permissions issue when running the container with a user other than root.\nNovember 23, 2020Inline Scanner v2.1V2.1 of the inline scanner container has been released.\nNew: Ability to analyze scratch-based images\nFixes:\nFixed a bug retrieving the PDF output for previously scanned images\nAddressed several vulnerabilities found in the inline scanner container\nNovember 19, 2020Kubernetes-Native Network Security with Sysdig Secure (Beta)A new feature has been added to Sysdig Secure for authoring and refining Kubernetes network policies (KNPs) that:\nAutomatically extracts the connection information, by observing the cluster networks and microservices communications\nOffers a visual flow to fine-tune the Kubernetes network policies, incorporating the user\u0026rsquo;s adjustments\nAutomatically generates the KNP YAML to be applied, without requiring previous Kubernetes policy knowledge from the user.\nAs soon as the feature is enabled, the Sysdig agent starts collecting and processing application communications, which are then enriched using Kubernetes metadata and presented in two different ways:\nTopology maps: a visual representation of the network flow between the Kubernetes entities (Services, Deployments, StatefulSets, DaemonSets, Jobs)\nIngress / Egress tables: for additional detail on each inbound/outbound communication and policy tuning.\nOnce the user has finished editing the desired policy, Sysdig will automatically compute the associated KNP YAML:\nEnforcement is delegated to the Kubernetes control plane, favoring policy-as-code and avoiding direct tampering with cluster communications\nAllow-only approach ensures that any communication which is not explicitly allowed by the policy will be forbidden\nPrerequisitesSysdig agent version 10.7+\nSupported Orchestrator Distributions and CNI Plugins:\nVanilla Kubernetes (kops, kube-admin) using Calico\nOpenShift 4.x using OVS\nGoogle GKE using Calico\nAmazon EKS using Calico\nRancher Kubernetes using Calico\nPlease contact us to enable this feature for your Sysdig Secure accounts.\nSee also: Network Security Policy Tool .\nNovember 13, 2020Terraform Provider Update (v0.5.4)Terraform v0.5.4 update is available in Sysdig Labs.\nThe following minor bug fixes are included:\nsysdig_secure_policy resource can configure the response action Kill Container\nFixed severity field in sysdig_secure_policy resource, to accept all possible values\nOctober 29,2020Scan Results List UpdatedThe UI for the list of scanned images has been updated to include several functionality and design improvements:\nStatus column (Passed or Failed) is now filterable\nImage Origin (Inline Scanner, Node image analyzer, etc.) is now visible, filterable, and has multi-select option\nImage registry is now visible on the table\nAbility to sort by date-added (default) or image name\nFlexible free-text search: filter by registry/repo:tag, repo:tag, repo, etc.\nOctober 26, 2020Inline Scanner 2.0A new version of the Sysdig inline scanner script has been released.\nMajor improvements:\nThe inline analysis container doesn\u0026rsquo;t need to spawn any additional containers\nThis removes the requirement for the Docker client, docker-in-docker, etc.\nThis enables usage in environments where docker-in-docker is not feasible or hard to instrument (e.g., Tekton).\nAdditional analysis workflows and formats:\nAdded support to analyze a docker archive\nA .tar.gz file containing the image, i.e. the output from a \u0026ldquo;docker save\u0026rdquo;\nExample execution\nAdded support to analyze OCI images (both and directory and archive)\nUncompressed or compressed OCI image format\nExample Jenkins pipeline\nAdded support to retrieve an image from the container storage (CRI-O and others)\nExample execution Additional improvements:\nFaster image ingestion\nMore verbose logs available for troubleshooting and diagnosis\nMachine-readable JSON output via --format JSON command\nTo upgrade an earlier Sysdig Inline Scanning version to 2.0, you need to take into account the new invocation parameters, which are not backward compatible.\nSysdig Inline scanner can be used stand-alone or as a step inside a CI/CD pipeline (Jenkins, Tekton, CircleCI, etc). In the upcoming weeks, we will update the different integrations to provide out-of-the-box support for the 2.0 version.\nOctober 22, 2020Forwarding the Activity Audit InformationThe Sysdig Secure Event Forwarder has added support to forward Activity Audit data to external platforms.\nBenchmarks support for Kubernetes Benchmark 1.6 Kubernetes Bench upgraded to version 1.6\nUsing the Kubernetes benchmark, we now provide customer-selected benchmark checks for GKE and EKS (rather than just the Kubernetes default).\nOctober 9, 2020Regulatory Compliance Control Validation \u0026amp; PCI ChecksA new feature has been added to Sysdig Secure for checking controls from various compliance standards. For the first release, we provide checks against specific controls in PCI 3.2. Future releases will include SOC2, NIST-800-53, and more. See also: Compliance in Sysdig documentation.\nCompliance Validator and ReportsThe validator checks many Sysdig Secure features, including: image scanning policies, Falco runtime policies and rules, scheduled benchmark testing, Admission Controller, Network Security Policies, Node Image Analyzer, and more. Over time we will add new compliance coverage.\nDisclaimer: Sysdig cannot check all controls within a framework, such as those related to physical security.\nThis feature is a beta release. A Sysdig Secure admin must enable it from the Sysdig Labs interface under Settings.\nPCI Control DetailsThe PCI Quick Reference describes the full range of controls required to pass a PCI 3.2 audit. In this release, Sysdig Secure will check the following subset:\nControls 1.1.2, 1.1.3, 1.1.6.b, 2.2, 2.2.1, 2.2.2, 2.2.a, 2.4, 2.6, 4.1, 6.1, 6.2, 6.4.2, 6.5.1, 6.5.6, 6.5.8, 7.1.2, 7.2.3, 10.1, 10.2, 10.2.1, 10.2.2, 10.2.3, 10.2.6, 10.2.7, 10.3, 10.5.5, 10.6.1, 11.4, 11.5.a, 11.5.b.\nOctober 2, 2020Event Forwarding: Kafka and Webhook AddedTwo new supported integrations have been added to the Sysdig Secure Event Forwarder:\nKafka topic\nGeneric webhook\nThe Kafka topic integration includes support for:\nMultiple Kafka brokers\nPartitioner/Balancer algorithms: Murmur2, Round robin, Least bytes, Hash, CRC32\nCompression algorithms: LZ4, Snappy, Gzip, Zstandard\nThe Webhook integration includes support for:\nAuthentication methods: Basic authentication, Bearer Token, and Signature Header\nCustom headers defined by the user to accommodate any additional parameter required on the receiving end\nSeptember 29, 2020Vulnerability Exceptions Handling EnhancedThe Vulnerability Exceptions feature in Sysdig Secure has been redesigned and enhanced.\nIt now offers:\nAdditional vulnerability and feed context\nPrecise mapping between images and their associated exceptions\nA better exception management lifecycle\nMultiple vulnerability lists, which can be flexibly assigned to different image sets (or just a particular image), using the scanning policy assignments\nAdditional information displayed to improve team awareness and security context\nVulnerability description\nUser-defined notes\nVulnerability feed info, with severities and links as provided per feed\nConfigurable expiration dates:\nAn exception is automatically disabled when the expiration date is met\nDay resolution, all times relative to 0:00 UTC\nEnhanced workflow integration with the \u0026ldquo;Scan results\u0026rdquo; page for an individual image, with the ability to quickly append a flagged vulnerability to a list.\nMigration: The exception and evaluation behavior in the current environment will be maintained after the feature upgrade. In particular:\nPre-existing vulnerability exceptions will be migrated to the \u0026ldquo;Default exceptions list\u0026rdquo;\nThe \u0026ldquo;Default exceptions list\u0026rdquo; will be assigned to every pre-existing policy assignment\nAll the pre-existing vulnerability exceptions expiration date will be set to \u0026ldquo;Never.\u0026rdquo;\nSee also: Manage Vulnerability Exceptions and Global Lists.\nAWS Threat Detection using CloudTrail and Sysdig SecureSysdig is happy to announce the general availability of a CloudFormation Template that will deploy a cloud-native operational security engine. By leveraging AWS CloudTrail and the Falco language, you can detect any unexpected or unwanted behavior in your AWS accounts.\nSysdig Cloud Connector leverages AWS CloudTrail as the source of truth for enabling governance, compliance, operational auditing, and risk auditing for your AWS account.\nEvery API action over your infrastructure resources is recorded as a set of CloudTrail entries. Once the integration is deployed in your infrastructure, the Sysdig Cloud Connector can analyze these entries in real-time and provide AWS threat detection by filtering them against a flexible set of security rules.\nExample detection rules included in this release:\nAttach a user to an Administrator Policy\nCreate an HTTP Target Group without SSL\nDeactivate MFA for user access\nDelete S3 bucket encryption\nSysdig Cloud Connector provides several notification options, including sending security findings to AWS CloudWatch and AWS Security Hub. When configured, you can consume the security events without leaving your cloud console.\nSee also: https://sysdiglabs.github.io/cloud-connector/.\nSeptember 28, 2020Automated Fargate Image ScanningSysdig is pleased to announce the general availability of a new integration leveraging the Sysdig Inline Scanning capabilities to automatically analyze the base images used for any task created using AWS Elastic Container Service (ECS or Fargate).\nStraightforward deployment using a CloudFormation template\nThe only mandatory parameter is the Sysdig API token.\nInline scanning living inside your AWS account means improved security:\nNo need to expose or configure private AWS registries\nOnly image metadata is sent to Sysdig Secure, not the actual image contents\nNo sensitive information ever leaves your AWS account\nAn ephemeral task will be spawned to analyze each discovered images, in parallel\nEach time you deploy a new task in AWS ECS/Fargate, an EventBridge event will be triggered and a lambda function will parse which images need to be analyzed by the CodeBuild pipeline job.\nFully automated\nScan results and scanning policies are still controlled from a single security governance point using Sysdig Secure\nNode Image Analyzer Version 0.1.3This version adds support for running the node image analyzer in Kubernetes environments with containerd, such as Google Kubernetes Engine configured with cos_containerd. See also: Scan Running Images.\nJuly 29, 2020Replacing RHSA Advisories with CVE AdvisoriesIn new images scanned, RHSA advisories will be replaced with CVE advisories. The results for existing images will be updated in the background over the next week.\nThis change provides better matches for CVEs that are not yet fixed or will not be fixed since those do not yet have RHSAs. It also makes the CVE the match key rather than RHSA for more consistent whitelisting and policy handling compared to other distros.\nScanning Adapter Available for HarborThe Sysdig Secure Harbor Scanner Adapter enables Harbor to use Sysdig Secure scanning engine to analyze the container images managed by the platform.\nThis adapter also provides a service that translates the Harbor scanning API requests into Sysdig Secure API calls, allowing Harbor to retrieve vulnerability reports and additional information from the scanning adapter. This will be presented transparently in the Harbor UI to the user.\nThe scanning adapter supports two operation modes:\nBackend Scanning: Image scanning happens in the Sysdig Secure backend\nInline Scanning: Image scanning happens in the infrastructure where Harbor is hosted\nTo learn more about this integration, read the documentation.\nJuly 28, 2020Captures Filter on the Policies PagePolicies can now be filtered to display if a capture is associated with an active or inactive policy.\nImage Exclusion on Policy EventsUsers often want to tune policy events. We\u0026rsquo;ve added a button on the event detail that will add an exclusion to a specific container.image.repo for the policy that triggered the event. Once that exclusion is applied to the scope, policies will no longer fire for that container.image.repo.\nJuly 26, 2020Sysdig EssentialsWe have introduced a new product tier, Sysdig Essentials. This tier includes everything required to achieve the five essential requirements for practicing Secure DevOps:\nImage Scanning\nRuntime Security\nCompliance\nKubernetes and container monitoring\nApplication and cloud service monitoring\nTo learn more about Essentials, register for our webinar, Deploy Faster by Automating Container Security, Monitoring and Compliance.\nWith the introduction of Essentials, It\u0026rsquo;s also easier to get started with a trial program and manage your Sysdig subscription.\nLearn the difference between Essentials and Enterprise, including pricing and features, at Pricing.\nSysdig Platform EnhancementsSAML Single Sign-OnThe initial email to the following types of users will take them directly to the Single-Sign-On URL, and not the registration page.\nSAML SSO Users\nThe users that are invited to the platform (as opposed to having them automatically created via Sysdig on-demand provisioning for SSO)\nEarlier, landing on the registration page was confusing to users because they had to set up their initial password.\nRebranded Login PageThe login page has been updated with the Sysdig Kraken and the new logo.\nJune 29, 2020New Sysdig Secure Overview PageThe Sysdig Secure Overview provides an at-a-glance view of the critical areas of your security posture.\nScopingPanels can be scoped by Cluster or Namespace. The scope will update all panels that are displaying run-time data and the corresponding drill-down views.\nPanels Build Time - Images Scanned: Image scan results for all static image scans\nDrill-down - To Image Scanning Reports page.\nBuild Time - CVEs Found by Severity: The total number of CVEs present in each image scanned.\nDrill-down - Available in a future release\nRun-time - Images Scanned: The pass/fail status of images running now and their trend over time.\nDrill-down - To Runtime Scanning Image page.\nRun-time - CVEs by Severity: The total number of CVEs present in each running image\nDrill-down - Available in a future release\nRun-time - Policy Events by Severity: The total number of policy events by severity.\nDrill-down - Secure Events page.\nBenchmarks Tests Failing: The total number of benchmark tests that have failed.\nDrill-down - Benchmarks Results page.\nJune 26, 2020Sysdig Secure\u0026rsquo;s Event Forwarder Now Supports IBM Cloud Pak for Multicloud Management and IBM QRadarIBM Cloud Pak for Multicloud Management centralizes visibility, governance, and automation for containerized workloads across clusters and clouds into a single dashboard.\nYou can now forward security events to an IBM MCM instance by accessing the Settings \u0026gt; Event Forwardingmenu and selecting IBM MCM from the dropdown:\nIBM QRadar Security Information and Event Management (SIEM) helps security teams accurately detect and prioritize threats across the enterprise and provides intelligent insights that enable teams to respond quickly to reduce the impact of incidents.\nYou can now forward security events to an IBM QRadar instance by accessing the Settings \u0026gt; Event Forwarding menu and selecting IBM QRadar from the dropdown.\nDeprecated March 8, 2023\nJune 23, 2020Secure Events Feed OverhaulThe Events feed in Sysdig Secure (formerly called Policy Events) has been redesigned, both visually and functionally.\nApart from the styling and user experience improvements, these are the major new features and use cases\nAdvanced FilteringWe are deprecating the grouping/clustering of events present in the old version in favor of a much more powerful set of filtering capabilities:\nSeverity filters: Presented as quick buttons at the top, supporting multi-select\nAttribute filters: Provide a simplified syntax to filter events by the attributes they contain. For example ruleType=\u0026quot;Falco - Syscall\u0026quot; or image.repo!=\u0026quot;sysdig/agent\u0026quot;\nOpen the event details side panel to find quick filtering widgets to include or exclude the attribute values associated with the displayed event Event type selector: Supports runtime scanning alerts on top of policy runtime events (see section below), with an easy multi-selector in the UI.\nFree text search: Allows you to search the event titles and scope label values. I.e. Terminal shell inor my-k8s-cluster.\nNew scope selector: Allows for additional selector logic (in, not in, contains, startswith, etc), improving the scoping flexibility over earlier versions. This scope selector also provides scope variables, allowing you to quickly switch between, for example, Kubernetes namespaces without having to edit the panel scope.\nAll these filters can be combined additively to further refine your search.\nMultiple Event TypesThe new event feed displays not only the policy runtime events, but also runtime image scanning alerts.\nThe backend architecture, filtering, and UX have been designed to accommodate additional types of security events that will be pushed to the Event Feed in the future, upgrading the interface from a policy-runtime-centric experience to a full security center control panel.\nAdditional Event DetailsPolicy runtime events: These now display the rule that was fired together with the rule labels. You can use the quick filters mentioned above to further refine the search.\nRicher scope: Every security event now displays all the scope labels retrieved for the event, not just those configured in the scope selector.\nSee also: Secure Events.\nAdditional Considerations/LimitationsEvents in the old and new format will be stored separately:\nNo event or event data will be lost during the transition\nEvents that were registered before the new feed is deployed can be browsed using the old feed interface, which is available from the burger menu in the top-right corner\nEvents that happen after the new feed is deployed will appear in the new event feed\nEventually, all events within the retention period will be present in the new interface, at which point the version switcher will disappear\nJune 17, 2020Menu UpdateThe ordering of the side menu has been changed.\nImage Scanning UpdatesThe image scanning navigation bar has changed.\nThe side menu is reorganized into Analyze and Configure sections\nAnalyze: Different areas of scanning that allow users to view scan results\nConfigure: The areas of scanning that involve the setup of the application\nWhitelist terminology with CVEs has been removed.\n\u0026ldquo;CVE whitelist\u0026rdquo; is now CVE Exceptions.\nTeam, Role, and Channel UpdatesA variety of enhancements have been added to the team, role, and notification channel options.\nService Manager Role Added to Sysdig SecureRBAC capability was previously added to Sysdig Secure. (See also January 27, 2020 and User and Team Administration.)\nNow a new role, Service Manager, is also available in Secure. It has the same permissions as the Standard User, plus the ability to invite existing users to the team and manage the notifications channels assigned to the team. See Team-Based Roles and Privileges\nConfigurable Default Team RoleYou can now define the default user role to apply when a new member is added to the team. The Admin can change this default on a per-team basis. See also: Create a Team.\nRBAC and Team Assignment for Notification ChannelsPreviously, notification channels in Sysdig Secure and Monitor were treated as global entities, visible and editable for most users of the platform regardless of team configurations.\nWe are enhancing the management and RBAC controls in the following ways:\nNotification channels can now be \u0026ldquo;global\u0026rdquo; or limited to a particular team\nGlobal channels can be managed by admins and can be viewed/used by other roles, while team-limited channels are available only to team members\nTeam Manager , Advanced User, and Service Manager (Secure) roles can create/update/delete team-scoped notification channels, they can also read and use the global ones\nStandard and View Only roles can read team-limited and global notification channels\nAdmins will be able to create global notification channels and migrate channels from \u0026ldquo;global\u0026rdquo; to \u0026ldquo;team-limited\u0026rdquo;, and also from one team to another.\nSee also: Set Up Notification Channels and the Share With field in each individual channel setting page.\nJune 12, 2020CLI-Based Admission Controller for Image ScanningAn additional tool for evaluating and admitting images is now available.\nSysdig Admission ControllerSysdig\u0026rsquo;s Admission Controller (UI-based) combines the Sysdig Secure image scanner with a policy language to evaluate scan results and the admission context, providing great flexibility in the admission decision. It also provides the first line of defense against image-based security threats.\nBy using Kubernetes API extensions to perform image scanning and other security checks on admission, we cover a major threat-prevention and hardening use case: \u0026ldquo;Only the images that are explicitly approved will be allowed to run on my cluster\u0026rdquo;.\nThe admission decision relies not only on the image name and tag but also on additional context from the admission review, including namespace, pod metadata, etc.\nFeatures\nRegistry and repository whitelist / blacklist\nGlobal and per-namespace admission configuration\nConfigurable pre-scan and post-scan behavior, i.e.:\nAccept only the images that pass the scan (default)\nDirectly reject non-whitelisted registries / repos, without scanning\nAccept the image even if it doesn\u0026rsquo;t pass the scan\nDo not accept any image that hasn\u0026rsquo;t been scanned already\nPod mutation: image tag is replaced by digest to prevent TOCTOU (Time of Check, Time of Use) issue if the tag is updated between the scan and the pod scheduling\nRequirements\nHelm 3\nKubernetes 1.15 or higher\nFor more information, see OPA Image Scanner.\nJune 4, 2020New Vulnerability Feed Available: VulnDBWe\u0026rsquo;ve added VulnDB as an additional 3rd-party vulnerability source to improve Sysdig\u0026rsquo;s coverage in non-OS package vulnerabilities.\nIn addition, a new page is available for each VULNDB-linked advisory. It lists the CVEs and details about the Common Vulnerability Scoring System (CVSS) scores and external references.\nSee also: Vulnerability Databases Used.\nMay 11, 2020Optimized Runtime PageWe\u0026rsquo;ve released a new Runtime page for the Image Scanning module within Sysdig Secure. Improvements include:\nFiltering based on pass/fail/unscanned\nThe ability to search results for a specific image\nOptimized queries to improve response times\nFor more information, see Review Scan Results.\nApril 20, 2020Added Automatic Image Scanning using Node AnalyzerThe (node) image analyzer (NIA) provides the capability to scan images as soon as they start running on hosts where the analyzer is installed. It is typically installed alongside the Sysdig agentcontainer.\nThis component was introduced to reduce dependencies on analyzing images within the Sysdig backend (SaaS or On-prem). Some advantages include:\nSharing credentials with the Sysdig backend in order to pull images is not required\nSharing the image content and potentially code with the Sysdig backend is not required; only metadata will be sent out\nOpening a network route to allow the Sysdig backend to reach the user\u0026rsquo;s registries is not required\nIf you have run the single line agent install with the --image-analyzer flag, then this component is already running in your infrastructure.\nThe feature is available for Kubernetes environments.\nFor more information, see Scan Running Images.\nApril 13, 2020Added Image Scanning Integration OptionsTwo new scanning integrations are available for CI/CD pipelines. Sysdig provides:\nA reference implementation with Tekton Pipelines (prototype)\nA fully supported integration with Amazon Elastic Container Registry (ECR) for triggering auto-scans from the registry\nIntegrating Secure Image Scanning with Tekton PipelinesTekton Pipelines allow you to implement CI/CD workflows using a highly modular, cloud-native approach that:\nUses containers as the building blocks for individual tasks\nRuns directly on Kubernetes/OpenShift without requiring a dedicated infrastructure\nUses tasks that are purely declarative and described using their own CRD, making them easily composable and reusable\nSysdig\u0026rsquo;s reference implementation details the prototype task to invoke Sysdig Secure image scanning as a pluggable step in your CI/CD pipeline with just a YAML file:\nLeveraging Tekton integration with the orchestration layer, you can retrieve the image scanning policy evaluation and state (pass/fail) directly from the logs of the task pod.\nRead the \u0026ldquo;Securing Tekton pipelines in OpenShift with Sysdig\u0026rdquo; blog post for additional details\nIntegrating Secure Image Scanning with Amazon ECRAutomatically scan images pushed to your Amazon Elastic Container Registry (ECR) using AWS-native technologies and Sysdig Secure.\nSysdig image scanner integration is deployed as a CloudFormation template that listens to ECR registry events and uses AWS resources to streamline the image scanning process.\nECR itself will trigger the scan, no need for your CI/CD pipelines to actively pull from the registry\nDeployed in a few clicks, you just provide basic configuration parameters such as the Sysdig API token or the Sysdig backend URL\nNo need to configure registry scanning credentials on the Sysdig Secure side\nThis integration offers two different operation modes\nInline scanning:\nScanning will be performed inside an AWS CodeBuild pipeline allocating ephemeral resources\nNo need to configure any registry credentials for Sysdig Secure\nNo need to expose your ECR registry to the Sysdig Secure backend\nSysdig Secure will not retrieve the image contents, only the metadata that is required to perform the policy evaluation\nBackend scanning:\nSysdig Secure will retrieve the full image contents in order to perform the scan\nYour ECR registry must be reachable by the Sysdig Secure backend\nRegistry credentials are required, but they are pushed automatically by a lambda function, no need for manual configuration\nApril 9, 2020Updates to Default Rules and PoliciesThe following changes have been made to default Policies in Sysdig Secure, and to default Falco rules:\nNew rule tags added that map Falco rules to PCI and NIST controls\nNew default policies added specifically for PIC/NIST compliance\nTuning modifications for:\nWrite below etc\nWrite below root\nChange thread namespace\nRun shell untrusted\nDetect outbound connections to common miner pool ports\nFor more information, see also Falco Rules Changelog.\nApril 7, 2020Updated Inline Scan Script Added header values for import API for better supportability.\nUpgraded to Anchore engine v0.6.1.\nUse docker:dindinstead of ubuntu for the base image. This reduces the image size and speeds up downloading.\nThe latest version of the inline script will always be available at https://download.sysdig.com/stable/inline_scan.sh\nLink to repo for script source code: https://github.com/sysdiglabs/secure-inline-scan\nMarch 12, 2020New Get Started PageThe Get Started page provides the key steps to ensure users are getting the most value out of Sysdig Secure. We\u0026rsquo;ll update this page with new steps as we add new features to Sysdig Secure.\nThe Get Started page also serves as a linking page for:\nDocumentation\nRelease Notes\nThe Sysdig Blog\nSelf-Paced Training\nSupport\nUsers can access the page at any time by clicking the rocketship in the side menu.\nLinux CIS Benchmark Test AddedSysdig Agents can run the Independent Linux benchmark against the underlying host where the agent is installed. The Linux benchmark can be scheduled to run at a chosen interval in your environment and emits results and metrics about the status of the tests.\nOpenShift Hardening GuideThe OpenShift hardening guide implements configuration checks run by the agent against OpenShift environments.\nSee https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html/container_security_guide/index\nNote: This is supported for 3.x versions of OpenShift. When OpenShift releases a hardening guide for 4.x versions, we will update the configuration checks.\nCaptures can be Routed to Specific Storage LocationsAs a user, you may have different S3 buckets where you\u0026rsquo;d like to store Sysdig captures, based on the environment where the policy event was triggered. New options are available for deciding what storage option you\u0026rsquo;d like to use for each policy event.\nFeeds Status Page AddedIt\u0026rsquo;s useful to understand the last time the feeds were updated, especially in self-hosted environments. The Feeds Status page shows the different vulnerability feeds we integrate with, their feed group (often the distro version), the time of the last sync, and how many CVE records are present in the feed group.\nSee also: Feeds Status.\nMarch 5, 2020Inline Scanning Reporting Improvements and DocumentationThis script from SysdigLabs is useful for performing image analysis on locally built container images and posts. The only dependency for this script is access to docker-engine, Sysdig Secure endpoint (with the API token) and network connectivity to post image analysis results.\nHere are examples of using the inline scanner in different pipelines:\nGitLab\nGitHub Actions\nAWS Codepipeline\nAzure Pipelines\nCircleCI\nPDF Reports from the Inline ScannerA new option\n-R [optional] Download scan result pdf report will generate a PDF artifact that is available for developers to consume in the pipeline.\nFebruary 6, 2020Data Retention Limits for Scan ResultsUse this feature to set limits on how long image scan metadata is stored, either by tags or days. This removes stale data and helps keep scan results easy to read.\nSee Data Retention for details.Data Retention\nJanuary 29, 2020Enhanced Kubernetes Audit Log IntegrationWe\u0026rsquo;ve extended our test and documentation coverage for various Kubernetes audit log integrations. This integration enables Sysdig Secure to use Kubernetes audit log data for Falco rules, activity audit, and to test the impact of Pod Security Policies.\nWe now have examples for:\nOpenShift\nMinishift\nKops\nGKE\nEKS\nRKE\nIKS\nMinikube\nRead more here: Kubernetes Audit Logging.\nVulnerability Scan Results ComparisonIn image scanning reports, the vulnerability comparison feature allows users to compare two different tags within the same repo to see which vulnerabilities are new or have been fixed in version X compared to version Y.\nThis allows developers easily to compare the latest image to a previous version to easily report on which vulnerabilities have been addressed and which are new.\nSee Review Vulnerability Summaries for details.Review Vulnerability Summaries\nJanuary 28, 2020File Data Source Support for Activity AuditSysdig Secure\u0026rsquo;s Activity Audit now supports a new data source element: File activity.\nSysdig agent version 9.5.0+ is required to enable this new data source.\nYou can now filter the audit trail by file type or specific file attributes:\nFile name\nDirectory\nCommand (used to access the file)\nAccess mode\nFile activity is also visible in the time-series graph at the top (pink color):\nActivity Audit will capture non-read file operations executed by interactive commands\nJanuary 27, 2020RBAC Capability Available in Sysdig SecureThe new role-based access control (RBAC) model available in Sysdig Secure allows you to define the access privileges granted to each user in a Sysdig Secure team.\nBesides the Admin role, which has full access and belongs to every team, there are four roles that can be assigned when adding a user to a team. (Note that the role names are the same in Monitor and Secure, but the privileges differ slightly. Users must be assigned Monitor team roles and Secure team roles separately.)\nView Only: Read access to every Secure feature within the team scope. A View Only user cannot modify runtime policies, image scanning policies, or any other content.\nStandard User: Can push container images to the scanning queue and view the image scanning reports. Standard Users can also display the runtime security events within the team scope. They cannot access the Benchmarks, Activity Audit. or Policy definition sections of the product.\nAdvanced User: Can access every Sysdig Secure feature within the team scope in read and write mode. Advanced Users can create, delete, or update runtime policies, image scanning policies or any other content. The Advanced User cannot manage other users.\nTeam Manager: Same permissions as the Advanced User + ability to add/delete team members or change team member permissions.\nTeam Managers only have user administration rights within the specific team(s) for which they are designated Managers.\nSee User and Team Administration for details.\nJanuary 16, 2020Redesigned Captures PageThe Captures function in Sysdig Secure has a new look and the following usability improvements:\nBulk deletion of capture files\nAbility to see whether a capture was triggered manually or by a policy\nSearch across all capture files\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/2020-archive/"},{"id":135,"title":"Serverless Agent Release Notes 2021","content":"2.2.0 December 2, 2021Defect FixesFixed Workload Agent Start IssueThe system no longer allows the workload agent to connect to the orchestrator agent if policies have not been loaded. This prevents the workload from starting without policies in place in the event of network disruption.\nNew FeaturesEasier Setup of Alternative Port for OrchestratorBecause the 6667 port is hardcoded in multiple places in the orchestrator CTF, users who needed to assign a different port to the orchestrator agent faced a cumbersome process. The orchestrator port can now be configured via either SYSDIG_ORCHESTRATOR_PORT (default) or the SysdigOrchestratorAgentPort (new) parameter in the CloudFormation template.\nInstrumentation Logs Collected Separately from Workload LogsFargate instrumentation logs are by default collected in a separate log group, which is created when installing the CFN instrumentation macro.\n2.1.0 September 27, 2021Defect FixesFixed Task Stall IssueFixed a memory leak in the Serverless Agent instrumentation that could cause the instrumented task to stall. The problem is more likely to be encountered when a large number of captures are generated in quick succession.\nResolved an Agent Error when Reading File DescriptorsReduced the log level of a benign warning message to debug.\n2.0.0 July 7, 2021New FeaturesCaptures AvailableAnnouncing the availability of the Captures feature in Fargate.\nDefect FixesFixed/Enabled Policy Scoping on Instrumented Fargate TasksAt this time, only container-related scope labels such as container.id or container.name are supported.\nDelay Event Source Startup by DefaultThe system now waits for policies to be available before launching the instrumented task, to fully secure workloads\nFixed Exit Codes for Faulty WorkloadsThe exit codes of the instrumented tasks are now faithfully propagated.\nBetter Handling of cmd and entrypoint ErrorsLog more informative errors when cmd and/or entrypoint are not available for serverless agent instrumentation.\nFixed S3 Bucket ErrorFixed an issue in the serverless agent installer that caused a failure while attempting to create an S3 bucket in us-east-1 region.\n1.0.1 April 15, 2021Segmentation Fault Error FixedFixed a problem that caused a segmentation fault error inside a Fargate task due to Sysdig instrumentation.\nContainer Definition Fields Now Support Complex ValuesAdded support for complex values inside Name and Image fields of the container definition. See also the ECS Task Definition docs from Amazon.\nMarch 15, 2021: Serverless Agents IntroducedSysdig Serverless Agent 1.0.0 for Fargate ECSThe \u0026ldquo;container-as-a-service\u0026rdquo; serverless environment calls for new agent models, and Sysdig provides them. Whereas in ECS, users still manage the underlying instances, with AWS Fargate the host is never visible and users simply run their workloads. And while this model is convenient, it can introduce risk as many people leave the containers unattended, without monitoring security events within that can exfiltrate secrets, compromise business data, impact performance, and increase their AWS costs. In addition, it is not possible to install a standard agent in an environment where you do not have access to a host.\nFor these reasons, Sysdig has introduced a new \u0026ldquo;serverless agent\u0026rdquo; model that can be deployed in these container-based cloud environments. The first implementation is for Fargate (ECS).\nSysdig will be rolling out security features on the serverless agent over time. In v1.0.0, users will see:\nRuntime Policies and Rules\nSecure Events\nTo obtain secure event information and the associated Falco policies and rules in the Sysdig Secure UI from a Fargate environment, users install the serverless agent using a CloudFormation Template. Then log in to Sysdig Secure and review the events in the UI.\nSee also: AWS Fargate Serverless Agents and Serverless Agent Release Notes (for future updates).\n","url":"https://docs.sysdig.com/en/release-notes/serverless-agent-release-notes/2021-archive/"},{"id":136,"title":"Table","content":"Use Table PanelUsing LinksThe PromQL panel supports the configuration of dynamic links. You can generate an external or internal URL using the label values returned by the PromQL query.\nTo add a link, open the Links tab and enter:\nthe URL template. In the URL you can reference a label value with {{label_name}}. the link title. If your URL contains the { and } character, escape it with \\.\nChanging Column Header LabelsYou can customize the labels shown in the column headers. If you leave Column Name blank, the table uses the default metric or label name. If you enter a value in Column Name, that value becomes the column header.\nYou can also reorder columns to adjust how data is displayed.\nUse CasesBuild an Aggregate View of Your Workloads Per Cluster and NamespaceThis example shows how to build a Form table panel to view a concatenated list of workloads per cluster and namespace.\nWhen configuring the panel options, choose:\nSegmentation: kube_cluster_name and kube_namespace_name Metrics/Labels: kube_workload_name Time aggregation: Concat You can then export the results as CSV for further exploration.\nView Resource Utilization of Your Kubernetes Workload Using a PromQL Table PanelThis example shows how to build a PromQL table panel to view resource utilization of your Kubernetes workload.\nFor demonstration, CPU and memory utilization is evaluated against the given quota in each workload, cluster, and namespace. The query displays top 10 segments that consume highest number of CPU cores and highest amount of memory.\nCPU Used Percent\ntopk(10,avg(avg_over_time(sysdig_container_cpu_used_percent{$__scope}[$__interval])) by (kube_cluster_name, kube_namespace_name, kube_workload_name)) CPU Quota\ntopk(10,avg(avg_over_time(sysdig_container_cpu_cores_quota_limit{$__scope}[$__interval])) by (kube_cluster_name, kube_namespace_name, kube_workload_name)) Memory Used Percent\ntopk(10,avg(avg_over_time(sysdig_container_memory_used_percent{$__scope}[$__interval])) by (kube_cluster_name, kube_namespace_name, kube_workload_name)) Memory Quota\ntopk(10,avg(avg_over_time(sysdig_container_memory_limit_bytes{$__scope}[$__interval])) by (kube_cluster_name, kube_namespace_name, kube_workload_name)) Select an appropriate unit of value for each query to return meaningful result. For example, use number for CPU quota, data for memory quota, and percent resource utilization metrics.\nTo scope down your selection, use the scope variable in combination with Team scope.\nIn this example, the panel scope is limited to two clusters (netsec-load-data, test-k8s-data), one namespace (kube-system), and one workload (coredns).\nExplore Kubernetes Objects from a PromQL TableThis example shows how to configure the table links to explore a Kubernetes object on Metrics Explorer:\nUse the URL that gives the Metrics Explorer default All Workloads: #/explore/metrics?last=3600\u0026amp;scope=kubernetes.cluster.name%20%3D%20%3F%20and%20kubernetes.namespace.name%20%3D%20%3F%20and%20kubernetes.workload.name%20%3D%20%3F%20and%20kubernetes.pod.name%20%3D%20%3F Apply the labels to the URL: Show cluster in Metrics Explorer:\n#/explore/metrics?last=3600\u0026amp;scope=kubernetes.cluster.name+%3D+\u0026#34;{{kube_cluster_name}}\u0026#34;+and+kubernetes.namespace.name+%3D+%3F+and+kubernetes.workload.name+%3D+%3F+and+kubernetes.pod.name+%3D+%3F Show namespace in Metrics Explorer:\n#/explore/metrics?last=3600\u0026amp;scope=kubernetes.cluster.name+%3D+\u0026#34;{{kube_cluster_name}}\u0026#34;+and+kubernetes.namespace.name+%3D+\u0026#34;{{kube_namespace_name}}\u0026#34;+and+kubernetes.workload.name+%3D+%3F+and+kubernetes.pod.name+%3D+%3F Show workload in Metrics Explorer:\n#/explore/metrics?last=3600\u0026amp;scope=kubernetes.cluster.name+%3D+\u0026#34;{{kube_cluster_name}}\u0026#34;+and+kubernetes.namespace.name+%3D+\u0026#34;{{kube_namespace_name}}\u0026#34;+and+kubernetes.workload.name+%3D+\u0026#34;{{kube_workload_name}}\u0026#34;+and+kubernetes.pod.name+%3D+%3F Show Host Logs on MezmoThis example shows how to configure the table links to show the host logs on Mezmo:\nUse the default URL of the company named Mezmo, where w52qwe12vv is the account id:\nhttps://app.mezmo.com/w52qwe12vv/logs/view\nApply the host label:\nhttps://app.mezmo.com/w52qwe12vv/logs/view?hosts={{host_hostname}}\nKnown LimitationsThe PromQL panel column order doesn\u0026rsquo;t honor the query segmentation order\nFeatures in Technical PreviewThe PromQL panel show a maximum of 250 rows. This limit can be changed with a beta flag in the User settings page:\n","url":"https://docs.sysdig.com/en/sysdig-monitor/table/"},{"id":137,"title":"Threats","content":"PrerequisitesSysdig Secure (SaaS) with data sources connected:\nKubernetes: Sysdig Agent installed with Kubernetes orchestrator Cloud Accounts: Integrated Cloud accounts Hosts and Containers: Containers deployed on hosts without Kubernetes orchestration ","url":"https://docs.sysdig.com/en/sysdig-secure/threats/"},{"id":138,"title":"User and Team Administration","content":"Understand Sysdig UsersUsers in Sysdig are identified by user name, email address, and password or by third-party authentication options.\nUsers are either:\nInvited manually by an Admin via the Sysdig UI\nAuthenticated through a third-party system\nEntered directly in the Sysdig database through the Admin API, which can bypass the invitation process if needed.\nWhen invited, the new user is created in the Sysdig database upon the user\u0026rsquo;s first successful login to the Sysdig UI. Before the user accepts the invitation, enters a password, and logs in, they have a \u0026ldquo;pending\u0026rdquo; status.\nSystem-Based PrivilegesFrom the outset, users in the Sysdig environment have one of three types of system privileges:\n(Super) Admin: This is the administrator whose email address is associated with the Sysdig billing account. This user has administrator access to everything. Most relevant in on-prem installations.\nAdministrator: Any administrator can grant Admin system privileges to any user. Administrators are automatically members of all teams.\nAdministrators can create/delete users; create/configure/delete teams; create/delete notification channels; manage licenses; and configure Agents from links in the Settings menu that are hidden from non-admins.\nUser (non-admin): By default, new users have read/write privileges to create, delete, and edit content in the Sysdig interface. They do not see options in the Settings menu that are restricted to Administrators.\nUser rights are further refined based on team and team role assignments, as described below.\nUpon creation, a user is automatically assigned to a default team, as described below.\nNotice that this default workflow grants all new users Edit access.\nSwitch TenantsA user with the same email address can log into multiple tenants.\nPrerequisites:\nThe tenants must be connected. To connect your tenants, reach out to your Sysdig Representative. The tenants must be in the same region. Users can log in locally, from your IdP by accessing the right tenant or from the Sydig login page by entering the customer name to log into.\nUsers can also switch between the available tenants from the Sysdig UI:\nNavigate to Settings \u0026gt; User Profile.\nSelect Switch. It is available just below User, Team, and Role indication in the UI.\nOnce the option is selected, you are presented with the list of available tenants.\nUnderstand Sysdig TeamsTeams can be thought of as service-based access control. Teams are created and assigned separately in Sysdig Monitor and Sysdig Secure.\nPurpose of TeamsOrganizing users into teams enables the enforcement of data-access security policies and improves users\u0026rsquo; workflows. There are different team roles, each of which has read/write access to different aspects of the app. This limits the exposure of data to those who actually need it, and also makes users more productive by focusing them on data that is relevant to them.\nIn addition to users, Sysdig Monitor and Secure also support team-based service accounts, which provide excellent automation capabilities. Each service account has its own team role, which allows you to define fine grained access and an expiry date for added security.\nUse Cases for TeamsThe following are some potential use cases for teams:\n\u0026ldquo;Dev\u0026rdquo; vs \u0026ldquo;Prod\u0026rdquo;: Many organizations prefer to limit access to production data. Permits isolating physical infrastructure and the applications on top.\nMicroservices: Scope data for individual dev teams to see their own dashboards and field their own alerts. Permits team creation based on logical isolation using orchestration or config management metadata in Sysdig Monitor.\nPlatform as a Service: Where Ops teams need to see the entire platform. Enable certain people to see all data for all services as well as the underlying hardware. This is perfect for managed service providers who are managing a multi-tenant environment, or DevOps teams using a similar model within their own organization.\nRestricted environments: Limit data access for security and compliance. Certain services, such as authentication and billing, may have a very specific set of individuals authorized to access them.\nOrganizations that need to segment monitoring for efficiency: Wide-ranging use case from very large organizations forming teams to simplify access, to smaller orgs creating ephemeral troubleshooting teams, to teams formed to optimize QA and Support access to system data.\nOperations Teams and Default TeamsOut of the box, the Sysdig Platform has one immutable team for each product. Depending on licensing, an organization may use one or both:\nMonitor Operations team\nSecure Operations team\nKey traits of the immutable Operations teams:\nThe teams cannot be deleted.\nUsers in Operations teams have full visibility to all resources in that product.\nAdministrators must switch to the Operations team before changing configuration settings for any team.\nAdministrators create additional teams and can designate any team to become the default team for that product.\nUsers entered in the Sysdig Monitor UI are auto-assigned to the Monitor default team; users entered in the Sysdig Secure UI are auto-assigned to the Secure default team.\nIf the Essentials tier is licensed, only the default teams and roles are enabled. See Subscription for more details.\nIf upgrading from Essentials to Enterprise, Capture functionality will become available. Users must go to Settings\u0026gt;Teams\u0026gt;Your Team and check the Enable Captures box. They must then log out and log in again.\nTeam-Based Roles and PrivilegesUsers can be assigned roles that expand or limit their basic system privileges on a per-team basis.\nSystem Role\nTeam Role\nAdmin\nMember of every team, with full permissions regardless of team assignment.\nCan create/delete/configure all users.\nCan create/delete/configure all teams.\nTeam Manager (Monitor)\nAdvanced User (Monitor)\nStandard User (Monitor)\nNon-Admin (Sysdig Monitor)\nCan create/edit/delete dashboards, alerts, or other content. Has the ability to add/delete team members or change team member permissions.\nNOTE: Team Managers only have user administration rights within the specific team(s) for which they are designated Managers. However, Team Manager users will see a list of users and teams they are assigned to, regardless of the team they have logged in to.\nCan create/edit/delete dashboards, alerts, or other content.\nEquivalent to an Advanced User with no access to the Explore page (for example, for developers who are not interested in Monitoring information).\nTeam Manager (Secure)\nAdvanced User (Secure)\nService Manager (Secure)\nStandard User (Secure)\nNon-Admin (Sysdig Secure)\nSame permissions as the Advanced User. Has the ability to add/delete team members or change team member permissions.\nNOTE: Team Managers only have user administration rights within the specific team(s) for which they are designated Managers. However, Team Manager users will see a list of users and teams they are assigned to, regardless of the team they have logged in to.\nCan access every Secure feature within the team scope in read/write mode. Advanced Users can create, delete, or update runtime policies, image scanning policies or any other content. The Advanced User cannot manage users.\nSame as Standard User, but with the ability to invite existing users to the team and manage the notifications channels assigned to the team.\nCan push container images to the scanning queue, view image scanning results, and display the runtime security events within the team scope. Standard Users cannot access Benchmarks, Activity Audit, Policy definitions, or certain write functions within other Secure features.\nFor a granular view of all the RBAC setting for default user and team roles, see Detailed Role Permissions.\nCustom RolesIf the default roles and permissions don\u0026rsquo;t meet the specific needs of your organization, you can create your own custom roles. See Manage Custom Roles.\nTeam Membership and Custom ViewsTeam membership affects user experience of the Sysdig Monitor or Sysdig Secure UIs in various ways.\nAt the highest level, the Events, Alerts and Dashboards you see are limited by the settings of the team you are switched to.\nIn more detail, team settings affect the following:\nDefault landing page: The UI entry point is set on a per-team basis.\nExplore tab and Dashboards (Monitor): These are set per-team, per-user and can be shared with the team.\nOn first login, all team members see the same Dashboards Assigned to Me view. If a user changes those dashboards, only that user will see the changes.\nDashboards created while part of a team are only visible to the user when logged in to that team, and if shared, are only visible to other team members.\nVisible data: A team\u0026rsquo;s scope settings limit the data visible to team members while they are switched to that team, even if a user belongs to other teams with different settings that reveal additional data. In Sysdig Secure, for example, only the policy events that fired within your scope will be visible.\nAlert and Event: These settings are team-wide. Any member of a team can change the team\u0026rsquo;s alert settings, and any additions or edits are visible to all members of the team.\nCaptures: Can only be taken on hosts/containers visible to team members, and members see only the list of captures initiated by other members who were switched to the current team.\nAPI Token: Note that the Sysdig Monitor API Token found under Settings \u0026gt; User Profile is unique per-user, per-team. See User Profile and Password. This is necessary to enable the generation of Custom Events via the API to target a specific team.\nSwitch Teams in the UIUsers can switch between all teams to which they\u0026rsquo;ve been assigned, and Administrators can switch between all teams that have been created.\nTo do so:\nClick the user menu in the lower-left corner of the navigation bar.\nThe assigned teams for this user are listed under My Teams.\nSearch a name, or scroll through the list to find it.\nClick the name of the team you want to switch to.\nA popup window gives an overview of the new team-based view of the environment. The UI changes according to the team settings.\nOnboarding Best PracticesPlan teams and roles strategically to isolate access to data, customize interfaces, and streamline workflows.\nIn general, administrators should:\nCreate teams, set roles, and invite users in a planned manner.\nStart at first with some dashboards and alerts for given teams.\nWhen a user logs in to a team for first time, they will see a wizard introducing dashboards, alerts, and other content specific to that team.\nRestricting New User Rights by DefaultBy default, new users are assigned Advanced User rights. If an administrator wants to limit new users\u0026rsquo; rights further, there are several ways to do so:\nBetween sending the invitation and the user\u0026rsquo;s first log in, change the user\u0026rsquo;s Role in the default Monitor team to Read User.\nNote there might be a lag in which the user will briefly have Edit status.\nIntegrate users into Sysdig via the Admin API and define read-only permissions upon import.\nCreate a default team, in either Sysdig Monitor or Sysdig Secure, with very limited scope and visibility. Manually assign users to additional teams with broader permissions as needed.\nIntegrating Users and Teams via APIIf you are working with Sysdig Support Engineers to provision users and teams via the Sysdig API, note how the user and team role names within the UI map to the API ROLE names.\nUser rolesRegular (non-admin) = ROLE_USER\nAdmin = ROLE_CUSTOMER\nTeam rolesAdvanced User = ROLE_TEAM_EDIT\nStandard User = ROLE_TEAM_STANDARD\nView-only User = ROLE_TEAM_READ\nTeam Manager = ROLE_TEAM_MANAGER\nService Manager (Sysdig Secure only) = ROLE_TEAM_SERVICE_MANAGER\n","url":"https://docs.sysdig.com/en/administration/user-and-team-administration/"},{"id":139,"title":"Vulnerability Management Policy Alerts","content":"Supported Notification Channels Email Slack Webhook Sysdig scans regularly through the day. Therefore, rescans of images will likely occur multiple times daily and continue throughout the image’s lifecycle. To avoid alert fatigue, align the type of policy alerting with the appropriate notification channel. As a best practice, set up a test channel first and check the volume and content of alerts are appropriate before connecting to live channels such as production Slack.\nSilence PeriodsA Silence Period prevents repeated alerts for the same resource and policy combination. This helps reduce alert fatigue and ensures notifications remain actionable.\nAvailable silence period options:\n15 Minutes 1 Hour 6 Hours 24 Hours Alert Configuration Guidelines Scope carefully: Consider both the number of images and workloads a policy applies to, as well as the constraints of attached rules. Both factors will influence the alert volume. Use silence periods: Set an appropriate silence period to control alert frequency for repeated failures on the same resource and policy. No new alert will be generated for that combination during the silence window. Start with a test channel: Always configure a test notification channel to observe alert volume and adjust your policy or silence periods as needed before activating notifications in production. Review policy and rule complexity: More permissive or broader-scoped rules may trigger more frequent alerts; fine-tune policies and rules to balance security needs with operational practicality. Document your alerting workflow: Ensure your team knows which channels are in use and how to respond to policy alerts for compliance or remediation. Create a Policy Alert Set up a supported notification channel, such as Email or Slack. On the Vulnerabilities Policies page, select a desired Pipeline or Runtime policy. On the Edit Policy screen, under Notifications, specify the following: Enable Notification by using the toggle. Frequency: Specify the frequency of notifications for failed policies. This is the silence period during which no additional notification will be generated. Channel: Select a notification channel. ","url":"https://docs.sysdig.com/en/sysdig-secure/vm_policies/alerts/"},{"id":140,"title":"Install Host Shield on Windows","content":"Installation RequirementsPrerequisites Windows Server 2019 or Windows Server 2022. ACCESS_KEY: The agent access key. REGION: us1, us2, us4, au1, eu1, me2, in1. For more information, see Sysdig SaaS region COLLECTOR: Use the collector address for your region. For more information, see SaaS Regions and IP Ranges. Administrator permissions to perform the operations. Coverage Map Platform Threat Detection and Response Vulnerability Management Posture Management Windows Server 2019 ✅ ✅ (Host Only) ✅ Windows Server 2022 ✅ ✅ (Host Only) ✅ Windows Server 2025 ✅ ✅ (Host Only) ❌ Install the Windows Host ShieldYou can install the Windows Host Shield using an MSI, which supports both GUI and CLI operation. Download the MSI package from the Sysdig download center.\nGUI InstallationYou can execute the MSI using a GUI and the installation process will prompt you to accept the EULA and enable the following applications Vulnerability Management and Posture Management.\nCLI Installation and ConfigurationRun the MSI in silent mode via CommandLine or PowerShell:\nmsiexec /i sysdig-host-shield.msi REGION=\u0026lt;region\u0026gt; ACCESS_KEY=\u0026lt;AGENT_ACCESS_KEY\u0026gt; VM_FEATURE_ENABLED=False POSTURE_FEATURE_ENABLED=False ACCEPT_TERMS_CONDITIONS=True /qn TagsAdd custom tags to categorize and filter hosts. Tags can be specified in both the MSI GUI wizard and via CLI as comma-separated key-value pairs.\nmsiexec /i sysdig-host-shield.msi REGION=us1 ACCESS_KEY=\u0026lt;AGENT_ACCESS_KEY\u0026gt; TAGS=\u0026#34;env:prod,team:backend\u0026#34; ACCEPT_TERMS_CONDITIONS=True /qn Using Certificate StorageWindows stores certificates locally in a storage location called the certificate store. This store may contain multiple certificates issued by different Certification Authorities (CAs).\nTo configure Sysdig Host Shield for certificate storage, set the following environment variables:\nCOLLECTOR_CERT=Certstore: Enables certificate storage usage COLLECTOR_CERTSTORE_NAME=\u0026lt;store_name\u0026gt;: Specifies the certificate store to use. Choose from: MY: Personal store ROOT: Trusted Root Certification Authorities CA: Intermediate Certification Authorities SPC: Software Publisher Certificates COLLECTOR_CERT_SUBJECT=\u0026lt;certificate_subject\u0026gt;: Specifies the Common Name (CN) of the certificate. This can be a full or partial string match. Example Configuration:\nCOLLECTOR_CERT=Certstore COLLECTOR_CERTSTORE_NAME=MY COLLECTOR_CERT_SUBJECT=SysdigAgentCert Using Custom CollectorIf you\u0026rsquo;re not using one of the following SaaS Regions, you must provide REGION=custom and the following variables:\nCOLLECTOR_URL: Specifies the custom collector host (for example, your.custom.host.com) COLLECTOR_PORT: Specifies the custom collector port (for example, 6443) API_URL: Specifies the custom api url (for example, https://your.custom.host.com) By setting ACCEPT_TERMS_CONDITIONS to True, you acknowledge and expressly agree that your use of or access to the Sysdig software is governed by the applicable terms and conditions located at Sysdig Legal Terms unless otherwise stated in a Sysdig Order Form or other written mutual agreement between Customer and Sysdig.\nProxy SettingsIf your environment requires internet access through a proxy server, you can configure proxy settings in the host-shield.yaml file. These settings ensure that Sysdig Host can communicate with Sysdig.\nproxy: http_proxy: http://customer-proxy https_proxy: http://customer-proxy After applying the changes, restart the Host Shield Windows service by running the following command from the PowerShell terminal:\n$ Restart-Service SysdigHostShield Antivirus and EDR ExceptionsSysdig Windows Host Shield may conflict when coexisting with Antivirus software or Endpoint Detection and Response (EDR) sensors. To prevent termination of the Sysdig Windows Host Shield processes, it is recommended to set up exclusions for the Host Shield root installation directory.\nCarbon Black Cloud From the Carbon Black Cloud Console go to Enforce \u0026gt; Policies. Select the desired Policy and click on the Prevention tab. Add a new Permission by clicking on the + sign. Add a new application path in the Permissions section and provide the directory exclusion *:\\Program Files\\Sysdig\\Shield\\**. Check Bypass option box for Performs Any Operation. Click Confirm. Windows Defender Open Windows Security \u0026gt; Virus \u0026amp; threat protection. Under Virus and threat protection settings, select Manage Settings. Under Exclusions select Add or remove exclusions. Click on the Add an exclusion button and choose Folder. Browse the drive where the Sysdig Windows Host Shield was installed, and select the Program Files\\Sysdig\\Shield directory. ","url":"https://docs.sysdig.com/en/sysdig-secure/windows-host/"},{"id":141,"title":"Secure SaaS Release Notes 2019","content":"November 13, 2019Activity Audit (Beta)The Activity Audit in Sysdig Secure allows you to browse a live stream of activity from your Kubernetes containers and nodes. Audit takes the highly detailed data from syscalls and Kubernetes audit logs captured at the agent level, and makes it always-on, searchable, and indexed against your cloud-native assets.\nThis stream includes executed commands, network activity, and kubectl exec requests to the Kubernetes API. The Activity Audit allows users to view different data sources in-depth for monitoring, troubleshooting, diagnostics, or to meet regulatory controls (SOC2, NIST, PCI, etc).\nFlexible filtering and scoping to help you focus on what\u0026rsquo;s relevant: Filters allow you to search, sort, and surface meaningful data and connections as they are needed. You can filter by data source type, data source attributes (like command name or Kubernetes user) and dynamic Kubernetes scope\nAutomatically trace a kubectl exec session : The built-in trace functionality allows you to isolate and trace akubectl exec access to a pod, automatically correlating the original Kubernetes user and IP that accessed the pod with the activity that was performed during the interactive session, including commands and network connections.\nKubernetes Policy Advisor (Beta)With the Kubernetes Policy Advisor, Sysdig Secure auto-generates Pod Security Policies (PSPs) to significantly decrease the time spent configuring Kubernetes Policies. Strict security policies reduce risk, but can also break applications. Sysdig tests the impact of pod security policies through simulations, enabling teams to adjust misconfigurations before shifting to production. There are three main features that comprise the Kubernetes Policy Advisor:\nAuto generation: Sysdig Secure can parse any Kubernetes yaml file that includes a pod spec to generate a tailor-made PSP based on the configuration.\nSimulations: Start a simulation of the auto-generated PSP or any user-inputted PSP to see what pods would have been blocked from running if this PSP had been actively applied to the cluster.\nEvents and tuning: Each pod/activity that would have violated the PSP will generate an event. Within the event details, users can see information about potential modifications they may need to make to the policy or the pod configuration.\nImage Scanning ImprovementSupport for images based on Google distro-less OS, including detection of base OS/version and installed OS dpkg packages.\nNovember 4, 2019Scanning ImprovementsNew Scanning Rules\nFile attributes can now be verified as part of the image scan analysis. A specific file can be validated against a node or sha256 hash.\nScale Improvements to Scanning Reporting\nNo query conditions are required as part of the Package and Policy Queries.\nOctober 10, 2019In-Line ScanningImages can now be analyzed locally before they are pushed to a registry. This has a couple key benefits to users.\nImages can be analyzed before they\u0026rsquo;re pushed to a registry and reduce registry cost\nCustomers using the Sysdig Secure SaaS offering don\u0026rsquo;t need to expose their registry to our SaaS for images to be scanned\nFor openshift customers the in-lince scan option can be integrated into the S2I process to scan images without needing to expose a local cluster registry via a route\nLearn more and access the script here: https://github.com/sysdiglabs/secure-inline-scan\nSysdig CLIThe Sysdig CLI provides an easy way to interact with the cli via the command line. Read more here.\nUsage\nRun it without parameters to get a list of all the commands.\n$ sdc-cli Usage: sdc-cli [OPTIONS] COMMAND [ARGS]... You can provide the monitor/secure tokens by the SDC_MONITOR_TOKEN and SDC_SECURE_TOKEN environment variables. Options: -c, --config TEXT Uses the provided file as a config file. If the config file is not provided, it will be searched at ~/.config/sdc-cli/config.yml and /etc/sdc-cli/config.yml. -e, --env TEXT Uses a preconfigured environment in the config file. If it\u0026#39;s not provided, it will use the \u0026#39;main\u0026#39; environment or retrieve it from the env var SDC_ENV. --json Output raw API JSON --version Show the version and exit. --help Show this message and exit. Commands: alert Sysdig Monitor alert operations backup Backup operations capture Sysdig capture operations command Sysdig Secure commands audit operations compliance Sysdig Secure compliance operations dashboard Sysdig Monitor dashboard operations event Sysdig Monitor events operations policy Sysdig Secure policy operations scanning Scanning operations settings Settings operations profile Profile operations New Package ReportsPackage name/version are now grouped together to provide easy parsing of all CVE\u0026rsquo;s associated with a package and the images using that package.\nSept 24, 2019New Trigger Parameters for CVSS ScoreImage Vulnerabilities can now be evaluated against their CVSS (Common Vulnerabilities Scoring System) score. If a vulnerability is =, \u0026lt;;\u0026gt;, \u0026lt;=, or\u0026gt;= to a specific score, then the rule can trigger a warn/stop action.\nSept 18, 2019Time Ranges UpdatedThe default time range options have been updated in Sysdig Secure.\nThe default time ranges are now set to:\n10 Minutes\n30 Minutes\n1 HR\n6 HRs\n1 Day\n3 Days\nTo look at a custom window of time, use the manual time window.\nSysdig Secure Summary Dashboard in Sysdig MonitorSysdig Monitor includes default dashboards that provide metrics about number of agents installed, active policies, events that have occurred, and the policies that have triggered them. Use these dashboards to identify trends, report on coverage, or facilitate the tuning process.\nAug 12, 2019Policy Editor*Please upgrade to an agent version 0.92.0 or greater\nThis UX overhaul brings three major improvements for every Sysdig Secure user:\nRuntime policies can import any number of security rules. You can scope the security policy using container, cloud and Kubernetes metadata.\nTighter Falco integration, directly from the web UI. You will be able to define a new trigger condition or append to the list of forbidden external IPs just clicking on the rule.\nA more structured way to group, classify and lookup rules, following the standard Cloud native procedure: tags and labels.\nRules LibraryVisualize your runtime rules properties in just a glance:\nWhere this rule comes from (Published By). The security team can instantly recognize whether a rule came from a specific Sysdig update, from a custom rules file created within the organization or from an external rules source (like the Falco community rules).\nWhen was the last time it was updated (Last Updated). You can use this information to audit your rules or if you schedule periodic updates, to confirm when last happened.\nRule tags: An effective method for organizing your rules. You can use these tags to describe the targeted entity (host, k8s, process), the compliance standard it belongs to (MITRE, PCI, CIS Kubernetes) or any other criteria you want to use to annotate your rules.\nFalco ListsEasily browse, append, and re-use lists to create new rules. Lists can also be updated directly via API if users want to add existing feeds of malicious domains, or IPs.\nFalco MacrosEasily browse, append, and re-use macros to create new rules.\nImage Scanning - View Scan ResultsScan Results Page - The existing repositories page has been renamed \u0026ldquo;Scan Results\u0026rdquo; this page also includes new capabilities to filter based on where the images are deployed, and to easily browse/expand the different repositories to see the image:tag\u0026rsquo;s that were evaluated and their results\nWhitelist labels available in vulnerabilities view - If a vulnerability has been added to a whitelist then that status is reflected in the Vulnerability report within the scan results.\nImage Scanning ReportsPlease contact Sysdig Support to enable this feature\nThe reports feature allows users to query the contents of a scan against a static or run-time scope to generate a report that shows the risk, exposure, or components of an image.\nUse cases could include:\nA new CVE has been announced, let me find all the running images in my US East Cluster that are exposed to that CVE\nShow me all images within my Google Container registry that have the tag prod and have a vulnerability with a fix that\u0026rsquo;s more than 30 days old\nShow me all images with a high severity vulnerability with a fix that are running in my billing namespace\nTypes of Scanning ReportsThere are three types of queries in the image scanning Reports:\nVulnerability Query TypeThis report returns rows of vulnerabilities mapped to packages within images in a static or run-time scope. In the example above we can see the two images that are actively running in my environment now that have the CVE - CVE-2017-8831\nPackage Query TypeThis report shows all images actively running in my environment that have a version of the bash package. It also shows if multiple images are running the same package name \u0026amp; version and if there are any CVE\u0026rsquo;s associated.\nPolicy ReportsPolicy reports show all the policy evaluations that have occured, whether or not they passed or failed, and the reason why an image may have passed or failed. Reasons for passing or failing could be because of, whitelists, blacklists, or just a standard policy evaluation.\nJuly 12, 2019Minor Improvements Compliance Dashboards in MonitorLink from Sysdig Secure now defaults to a 90-day view, to give users better visibility into how their posture is changing over time.\nImage ScanningNegligible vulnerabilities are now also shown as part of the scan results summary.\nJune 27, 2019Image Scanning: New Trigger Options New Image Analyzed - Send notifications to different channels when images with a particular registry, repo, tag are scanned.\nSome users implement these type of alerts for implementing workflows for image promotion, i.e.\n\u0026quot;Push an image from staging to prod registry after a webhook is sent that the image was scanned and it passed.\u0026quot; CVE Update - Be notified whenever a vulnerability is added, updated, or removed from an image within a registry.\nRepository AlertsReceive alerts about activity and changes that occur within yourregistry.\nSlack NotificationsSample output of a CVE alert:\nSample output of an image-analyzed alert:\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/2019-archive/"},{"id":142,"title":"Authentication and Authorization (SaaS)","content":"You can use Sysdig Monitor and Sysdig Secure with the following user authentication and authorization methods:\nType Enabled by Default Integration Requirements User Credentials Yes No Google OAuth No Yes SAML No Yes OpenID Connect No Yes Prerequisites and GuidelinesSysdig See SaaS Regions and IP Ranges before proceeding to configure authentication. Sysdig has assigned a Customer Name, Customer ID, and External ID for your account. You can view it on the Settings \u0026gt; Authentication (SSO) page. Identity Provider (IdP) Configure authentication separately for each Sysdig product: Sysdig Monitor and Sysdig Secure. Configure your Identify Provider (IdP) for the Sysdig application. Users must be assigned to the application in the IdP to be able to access Sysdig. Configure Single Sign-On Determine the Single Sign-On (SSO) and the IdP that your enterprise uses. Log in to the Sysdig application as an administrator. Open Settings \u0026gt; Authentication (SSO). On the Authentication page, select New Configuration or choose to edit an existing one When creating a new integration, select the type: OpenID or SAML Enter the required connection settings for the chosen SSO. If you are configuring only one integration the Integration Name can be omitted. Configure any associated IdP settings on the IdP side. If enabling both Sysdig Monitor and Sysdig Secure, repeat the process on the second application. Main Authentication SettingsThe main Authentication parameters are the same for all of the authentication protocols.\nOption Description Customer ID Unique customer identifier. Customer Name Unique customer name. External ID Unique customer External ID used in some SSO integrations. Manage SSO IntegrationsSysdig allows you to manage up to 10 SSO integrations in addition to the Google OAuth. You can create new integrations by selecting option New Configuration and then selecting the type SAML or OpenID.\nYou can edit an existing SSO integration either by selecting the row or by selecting the pencil icon on the right side.\nDeleting the configuration is possible by selecting the three dot menu on the right side and then option Delete Configuration. You can only delete inactive SSO integrations.\nAn integration is active when the slider on the left side is in the right position. Make sure at least one integration is enabled to be able to use it for logging users in.\nIntegration Name is not required if only one integration is set, but if multiple integrations are defined the integration name must be appended to the Metadata URL, Relay State, and Bookmark URL (if used).\nWhen you define an Integration Name for a SAML or OpenID SSO integration, users must enter this name on the Sysdig login screen to start the correct SSO flow. If users do not enter the Integration Name, Sysdig cannot begin authentication. Ensure that users know which Integration Name to use when multiple SSO integrations are configured.\nDisable Password Authentication For On-Prem environments, see Disable Password Authentication.\nTo disable password authentication through the UI:\nLog in to Sysdig Monitor or Sysdig Secure as administrator and select Settings from the user menu at the bottom left of the screen. Click Authentication(SSO). Scroll down and locate the Username and Password Login settings. Use the Username and Password Login slider to turn off password authentication. Click Save. For IdP Break-Glass scenario when Password Authentication is disabled, see Break-Glass scenario.\nConfigure Customized Session ExpirationTo do so:\nLog in to Sysdig Monitor or Sysdig Secure as administrator and select Settings. Select Authentication(SSO). Scroll down and locate the Session Expiration settings. Specify the Session Expiration setting: Enable session expiration by using the Inactive Session Expiration slider. Specify the time-out period in minutes. Click Save. Multi-Factor AuthenticationLimitations MFA only applies to local (username and password) user accounts.\nIf you need to use MFA when using an Identity Provider (IdP), look into your Single Sign-On (SSO) configuration. See Enable Single Sign-On. Administrators cannot enable MFA on user accounts. However, they can disable it.\nEnable MFAYou can enable MFA for your account from the User Profile page. Once enabled, you will be prompted to use MFA when you login.\nTo enable Multi-Factor Authentication:\nLog in to Sysdig Secure or Sysdig Monitor. Navigate to Settings \u0026gt; User Profile. In the Multi-Factor Authentication section, toggle Authenticator App MFA on. A modal appears. The modal has a QR code and a key. In your authenticator app, add a new account. Consult the documentation of your chosen app for precise instructions. Scan the QR code with your authenticator app. Alternatively, enter the key below the QR code manually. A verification code appears in your authenticator app. Enter the code into the text box in the modal, and click Confirm. Multi-factor authentication is now enabled.\nLog in with MFAOnce you have enabled MFA on an account, you can log in with MFA:\nGo to the Sysdig Secure or Sysdig Monitor login page. Enter your username and password. Select Log in. Open your authenticator app. A code will appears. Enter the code generated in your authenticator app. Select Verify. If the code is correct, your login will be successful.\nDisable MFA on your AccountTo disable MFA on your own account:\nLog in to Secure or Monitor. If you cannot log in, contact your administrator. Navigate to Settings \u0026gt; User Profile. In the Multi-Factor Authentication section, toggle Authenticator App MFA off. Select Confirm. Multi-factor authentication is now disabled. When you attempt a login, you will no longer need to user your authenticator app.\n(Admin) Disable MFA for a UserAdministrators can disable MFA for other users. This is useful, for example, if a user loses access to the authenticator app. To disable MFA on a user\u0026rsquo;s account as an Admin:\nLog in to Sysdig Secure or Sysdig Monitor as an Admin. Navigate to Settings \u0026gt; Users. Select a user from the list. The Edit User page appears. Toggle off Authenticator App MFA. MFA is now disabled for that user. Remember that Admins cannot toggle MFA on.\nLearn More Google OAuth SAML OpenID Connect Google OAuth Configure Customized Session Expiration ","url":"https://docs.sysdig.com/en/administration/authentication-and-authorization-saas/"},{"id":143,"title":"Automations","content":"An example work flow:\nSet up a filter to detect a new risk of critical severity in your team zone. If the resource type is in an S3 bucket, you can notify a certain team via Slack. Alternatively, if the resource type is an IAM Role or IAM User, you can notify another team via Email. PrerequisitesTo use Automations, you need:\nAdmin role permission or greater. GuidelinesUnderstand the terminology:\nAutomation: A workflow that automatically triggers when an event matches user-defined criteria.\nEvent: An atomic entity generated by the platform, such as the discovery or update of a risk.\nActions: Generic procedures performed within an automation. Each action leads to one or more outcomes: true, false, successful, or error. Note that not all actions support all outcome types.\nCondition Action: An action to filter or branch attributes based on specific criteria, resulting in either a true or false outcome.\nNotification Actions: The actions to send alerts to supported notification channels. You can append additional actions to these notifications. Subsequent actions are executed only after the notification action runs successfully.\nTrigger: An event listener that activates when all criteria of a filter are met. Once triggered, the automation executes the subsequent set of actions. You can define optional filters to reduce unnecessary automation runs. Each automation listens for only one event at a time; however, a single event can trigger multiple automations. For optimal performance, triggers should use the broadest filters necessary to complete the task efficiently.\nFor example:\nSend a Slack message for all critical risks by:\nSet the trigger filter to severity = critical. Add a single action to send the notification to Slack. Send a Slack message for all critical risks by:\nLeave the trigger filters empty. Add a condition action with severity = critical. Add a true action to send the notification to Slack. If there are 100 risk events, but only one is critical:\nThe first automation runs once and sends one Slack message. The second automation runs 100 times but still sends only one Slack message. Risk AutomationsCreate a Risk AutomationTo create an alert based on a risk or risk update:\nLog in to Sysdig Secure as an Admin.\nSelect Automations from the left navigation bar.\nThe Automations page appears.\nSelect New Automation \u0026gt; Risks.\nSelect a Trigger:\nRisks: Create an automation based on Risk events, such as elevated privileges or exposed containers. See Risk.\nRisks Updates: Create an automation when a new resource is added to a risk.\nThe Automations configuration page will open. Proceed to Configure an Automation.\nConfigure a Risk AutomationYou can build automations visually through logic chains of conditions and actions.\nSet the first automation condition to Trigger on:\nNew Risks: A new risk that is reported.\nRisk Updates: A risk you\u0026rsquo;ve seen before, but has updated.\nFor more information, see Example Automation Flow.\nChoose one or more of the available Filters:\nSeverity: A severity, such as Critical, High, Medium or Low.\nZones: A default Zone, such as Entire Infrastructure or Entire Git, or a custom Zone. For more details, see Zones.\nPlatform: Cloud platforms, such as GCP and Azure, or platforms such as Linux or containers.\nResource Type: Workload resource, such as Kubernetes Deployment, Kubernetes DaemonSet, Compute Instance, AWS IAM Role, or AWS S3 Bucket.\nSelect the plus icon under a condition box to select an action.\nActions include:\nAn additional Condition.\nA notification via Slack, MS Teams, Webhook, Email or PagerDuty.\nYou can link several actions to a single condition. Actions such as sending a notification will only occur if the \u0026ldquo;If\u0026rdquo; condition is met successfully.\nAdd additional conditions and actions until you have built a desired flow.\nTo create the new automation, select Save.\nExample: Notify Risk Updates to AWS ResourcesConsider you have set up the following automation flow:\nTrigger on: Risks Updates Filters: Resource Type in S3 Bucket, EC2 Instance, IAM User, IAM Role At 12:00 AM, the user environment has no reported Risks.\nAt 12:01 AM, a new risk is detected: Risk: Workload with critical vulnerabilities exposed to the internet Affected Resources:\nS3 Bucket EC2 Instance The user receives one alert for this new risk, listing all affected resources.\nAt 12:02 AM, the same risk persists, but two additional resources are affected:\nS3 Bucket EC2 Instance IAM User IAM Role The user receives two separate alerts for the risk updates:\nOne alert for IAM User One alert for IAM Role Since S3 Bucket and EC2 Instance were already included in the initial alert, they do not trigger new alerts.\nVulnerability Findings AutomationsCreate a Vulnerability Findings AutomationTo create an alert to notify you of a vulnerability issue:\nLog in to Sysdig Secure as an Admin.\nSelect Automations.\nThe Automations page appears.\nSelect New Automation \u0026gt; Vulnerabilities.\n​\tThe New Vulnerability Findings configuration panel appears. Proceed to Configure an Automation.\nConfigure a Vulnerability Findings AutomationYou can build automations visually through logic chains of conditions and actions.\nOn the New Vulnerability Findings panel, select one or more of the available Filters:\nSeverity: A severity, such as Critical, High, Medium or Low.\nEPSS Score: Choose between a score of 10% and 100%.\nCISA KEV: Select Yes or No.\nHas Exploit: Select Yes or No.\nHas Fix: Select Yes or No.\nSource: Select one of the following:\nKubernetes Runtime Host Runtime Zones: A default Zone, such as Entire Infrastructure or Entire Git, or a custom Zone.\nSee Zones.\nSelect Done.\nSelect the plus icon under a condition box to select an action.\nActions include:\nAn additional Condition. A notification via Slack, MS Teams, Webhook, Email or PagerDuty. A Tickets integration you have set up, such as Jira. To set up a Jira integration, see Jira Ticketing. When you select a Jira action, you must select the integration and the issue type. Optionally, you can select the assignee, along with a number of additional fields, allowing assignment and organization based on your existing workflows. You can also customize the ticket with variables. You can link several actions to a single condition. Actions such as sending a notification will only occur if the \u0026ldquo;If\u0026rdquo; condition is met successfully. Add additional conditions and actions until you have built a desired flow.\nTo complete creating the new automation, click Save.\nExample: Notify Critical Vulnerabilities with Exploits in a ZoneConsider you want to be alerted on critical vulnerabilities with exploits.\nClick New Automations and Select a Trigger for Vulnerabilities.\nFrom Filters select:\nSeverity in Critical\nHas Exploit = Yes\nSpecify the condition:\nSelect the Zone and click Done. Click TRUE. Select the Notification channel you prefer.\nWhen a critical vulnerability with exploits occur in the selected zone, you will be notified on the selected channel.\nCustomize Outputs with VariablesWhen creating a Vulnerability Findings automation, you can use variables to customize the output.\nVariables are placeholders that will be replaced with the real value of the variable at the time the automation is executed.\nFor example, if you use the variable {labels.agent.tag.region}, when the ticket is created it will show us1.\nYou can use the variable automation.id to label a Jira ticket with the ID of the automation that created it. When the automation executes, automation.id is replaced with the actual automation ID, which is a simple UUID. That means that in your Jira ticket you will have a label with a value like eb1ebe2b-e12b-1234-bfd1-1234dbfdbc12.\nGlobal VariablesGlobal variables are available across all applicable automation triggers and actions:\nautomation.id: The automation ID, which is a simple UUID. For example, eb1ebe2b-e12b-1234-bfd1-1234dbfdbc12. automation.name: The name of the automation. execution.id: The unique ID for each time an automation is executed. execution.startedAt: The date and time the automation was triggered. Asset and Dynamic VariablesThe asset variable trigger.asset.assetName will always be present on Vulnerability Findings automations, as all such automations are based on an asset.\ntrigger.asset.assetName: A string that depends on the resource type. For example, it could be quay.io/sysdig/vuln-host-scanner:0.13.4 for Kubernetes workloads, or i-0d1d23457b6b789e0 for a host. Some asset variables are dynamic; they may or may not be applicable to the automation resource and resource type:\ntrigger.asset.hostName trigger.asset.cluster trigger.asset.hostId trigger.asset.hostName trigger.asset.imageId trigger.asset.namespace trigger.asset.pullstring trigger.asset.workload If you select a variable which is not applicable, the output will be N/A.\nFinding VariablesFinding variable can be dynamic; they may or may not be applicable based on the type of trigger, resource or finding type.\nExamples of variables that are only available for vulnerability triggers include:\ntrigger.finding.cveName trigger.finding.cvssScore trigger.finding.severity Vulnerabilities Accepted Risk AutomationsYou can create an automation to trigger when Accepted Risks for vulnerabilities are created, updated, or deleted.\nCreate Vulnerabilities Accepted Risk AutomationTo create a Vulnerabilities Accepted Risks automation:\nLog in to Sysdig Secure as an Admin.\nNavigate to Automations.\nThe Automations page appears.\nSelect New Automation \u0026gt; Vulnerabilities Accepted Risk.\nThe configuration panel appears.\nProceed to Configure a Vulnerabilities Accepted Risk Automation.\nConfigure a Vulnerabilities Accepted Risk AutomationYou can build automations visually through logic chains of conditions and actions from the configuration panel:\nSet the first automation condition to Trigger on: Event based triggers such Risk Acceptance Created, Updated, Deleted or Expired, which happen when a risk acceptance change occurs. Such changes are typically user-driven.\nRisk Acceptance Expiring: Calculates the number of days until a risk expires. Use this be alerted 7, 30, 60, or 90 days before a risk expires.\nChoose one or more of the available Filters: Expires in: How many days the user has defined that the risk accepted will be expiring\nDays before expiration: Relative number of days before the risk acceptance will expire. Only available for the Risk Acceptance Expiring trigger.\nCreated By: The user who created the risk accepted.\nUpdated By: The user updating the risk accepted. Only available for the Risk Acceptance Updated trigger.\nReason: The reason selected by the user for performing the risk action. This includes custom reasons.\nSelect Done.\nSelect the + icon under a condition box to Select an Action. Actions include:\nCondition: An additional condition.\nNotifications via Slack, MS Teams, Webhook, Email or PagerDuty to notification channels you have created.\nYou can link several actions to a single condition. Actions, such as sending a notification, only occur when the If condition is met.\nAdd additional conditions and actions until you have built a desired flow.\nSelect whether to Enable the automation or not, and select Save.\nYou cannot save an automation if the configuration is incomplete. For example, if a Send Slack Message action has not been linked to a notification channel.\nExample: Alert Before a Risk ExpiresAs an example, imagine you want to be alerted on whenever a risk is set to expire in 7 days. To set this up from the Automations page:\nClick New Automation \u0026gt; Vulnerabilities Accepted Risks.\nFor Trigger on, select Risk Acceptance Expiring from the drop-down.\nFrom Filters select:\nDays before expiration = 5.\nYou can input the number as free text.\nSelect Done.\nSelect the + icon under the condition box.\nThe Select an Action modal appears.\nSelect the Notification channel you prefer.\nEnsure the automation is Enabled, and click Save.\nFive days before the accepted risk expires, the notification channel you selected will get an alert.\nRuntime Events AutomationYou can create an automation to trigger when a runtime policy generates an event.\nCreate a Runtime Event AutomationTo create a Runtime Event Automation:\nLog in to Sysdig Secure as an Admin.\nSelect Automations.\nThe Automations page appears.\nSelect New Automation \u0026gt; Runtime Events.\nThe configuration panel appears.\nProceed to Configure a Runtime Events Automation.\nConfigure a Runtime Events AutomationYou can build automations visually through logic chains of conditions and actions. To configure a Runtime Events Automation:\nFrom the configuration panel, select at least a Severity of Policy filter.\nOptionally, you can add other filters, such as:\nEvent Source, such as Syscall, K8s Audit and more Rule Name Zones Labels available from agent tags, Kubernetes labels and more Select Done.\nSelect the + icon under the condition box to Select an Action, such as:\nAn additional Condition.\nNotifications via Slack, MS Teams, Webhook, Email or PagerDuty to notification channels you have created.\nResponse Actions - see the Response Actions section.\nYou can link several actions to a single condition. Actions such as sending a notification will only occur when the If condition is met.\nAdd additional Conditions and Actions until you have built a desired flow.\nEnsure the automation is Enabled and select Save.\nResponse ActionsResponse Actions are a type of action allowing you to contain a threat, after it has been detected, or to collect additional data as a forensic proof or to support the investigation phase.\nFor Response Actions to work, they need to be set up in the environment where the trigger event takes place, in regard to the selected action. For instance:\nTrigger event on cluster foo, Container kill action, the host response actions need to be deployed and enabled on cluster foo Trigger event on host bar, Fetch Cloud logs action, the AWS account where bar is in needs to have Cloud Response actions deployed for the region where bar is. You can read more about Response Actions in the Response Actions page.\nAcquire FileThis action allows you to acquire different files that the Trigger Event refers to, if any:\nProcess binary Parent process binary File argument, for actions on a single file (i.e. create/open/write). For actions on multiple files, the target file if available in the event, the source file otherwise. Target file Source file The captures storage must be set up for this to be working, as a prerequisite.\nSee the Response Action documentation for additional information.\nKill ContainerKills the container that the event refers to, if any.\nSee the Response Action documentation for additional information.\nKill ProcessKills the process the event refers to or its parent, depending on your choice, if the event contains such data.\nSee the Response Action documentation for additional information.\nPause ContainerPauses the container the event refers to, if any.\nSee the Response Action documentation for additional information.\nQuarantine FileThis action allows you to quarantine different files that the Trigger Event refers to, if any:\nProcess binary Parent process binary File argument, for actions on a single file (i.e. create/open/write). For actions on multiple files, the target file if available in the event, the source file otherwise. Target file Source file See the Response Action documentation for additional information.\nStop ContainerStops the container the event refers to, if any.\nSee the Response Action documentation for additional information.\nDelete PodFor events referring to a Pod, this action proceeds to kill it.\nSee the Response Action documentation for additional information.\nGet LogsIf the event refers to a Workload, this action fetches its logs. You can select if you want the logs from all containers of all pods, or just the log from the single container the event refers to, if any.\nIt\u0026rsquo;s possible to get the logs from the latest execution or the previous instance. Like kubectl logs, the latest instance is the running one, if any, or the last one if none.\nThe captures storage must be set up for this to be working, as a prerequisite.\nSee the Response Action documentation for additional information.\nIsolate NetworkFor events about network traffic, this creates a Kubernetes Network Policy to deny it, based on the inputs and its configuration.\nDirection: you can select the direction of the connections that will be blocked. This will be used, regardless of the event. If you want to target connection events only, or a direction only, use a Condition box. Port: you can specify to use the port from the event or all of them. In the former case, the event will need to contain such information. IP: you can specify to use the IP from the event or all of them. In the former case, the event will need to contain such information. Protocol: you can specify to use the protocol (TCP/UDP) from the event or all of them. In the former case, the event will need to contain such information. See the Response Action documentation for additional information.\nRollout RestartThis action restarts the Kubernetes workload, if specified in the trigger event.\nSee the Response Action documentation for additional information.\nVolume SnapshotFor events about a Kubernetes workload with an attached volume, this creates a snapshot of such a volume.\nCurrently, only workloads with one volume are supported.\nSee the Response Action documentation for additional information.\nEBS Volume SnapshotThis action takes a Volume Snapshot on all EBS volumes attaches to the EC2 instance pertaining to the event.\nThe triggering event must refer to an EC2 instance for this action to take place.\nSee the Response Action documentation for additional information.\nFetch Cloud LogsFor events happening on AWS, you can fetch the CloudTrail logs to support further investigations. You can customize some options for this action:\nTime before the Event: Define when the query interval starts, based on the event. The interval ends on the event timestamp. User: Get only the actions from the user that generated the event or all. If you select \u0026ldquo;From the event\u0026rdquo;, the cloud user (or role) must be included in the trigger event for the action to take place. Event Source: Get only the action regarding the resource type that the event happened on or all. If you select \u0026ldquo;From the event\u0026rdquo;, the resource type must be included in the trigger event for the action to take place. Event Name: Fetch only the logs pertaining to the same action performed in the event, if any, or all. If you select \u0026ldquo;From the event\u0026rdquo;, the action name must be included in the trigger event for the action to take place. Your captures storage must be set up for this to be working, as a prerequisite.\nSee the Response Action documentation for additional information.\nRemove Public AccessFor events pertaining to an S3 bucket and/or an RDS instance, this removes the public access option, if set.\nFor this response action to be defined, the S3 bucket or RDS instance must be included in the trigger event.\nYou can select this action to be performed on either or both the resource types.\nSee the Response Action documentation for additional information.\nIAM QuarantineThrough this action you can quarantine an IAM User or Role, if included in the triggering event.\nIf selecting \u0026ldquo;Event Subject\u0026rdquo;, the actor that performed the original event, tracked on CloudTrail, will be quarantined (if any).\nBy selecting \u0026ldquo;Event Object\u0026rdquo;, you can instead quarantine a IAM object of an event, i.e. on which an operation is performed, like a permission grant.\nSee the Response Action documentation for additional information.\nExample: Alert for all High Severity Events in a Zone. Alert by Slack if there are Specific Labels.As an example of a Runtime Event Automation, you can be alerted via email about all high-severity events in your Prod Zone. Additionally, if the agent tag critical = true is detected in that zone, you can receive a Slack notification. To set up this automation:\nLog in to Sysdig Secure as an Admin.\nSelect Automations.\nThe Automations page appears.\nSelect New Automation \u0026gt; Runtime Events.\nThe configuration panel appears.\nFrom Filters select: Severity in High.\nZones in Prod.\nSelect Done.\nSelect the + icon under the condition box.\nThe Select an Action modal appears.\nUnder Notifications, select Email.\nFrom the Notification channel, select the email notification channel of your security team.\nSelect Done.\nUnder the original condition box, select the + icon.\nSelect Condition.\nThe If panel appears.\nFrom the Select Filter drop-down, add: agent.tag.critical in true Select Done.\nUnder the agent.tag.critical in true condition box, select the TRUE + icon.\nThe Select an Action modal appears.\nSelect Slack, and choose your Slack notification channel from the drop-down.\nClick Done.\nEnsure the automation is Enabled and select Save.\nThis automation would result in two alerts for the label agent.tag.critical; one to Slack and one to an email.\nThreats AutomationYou can create an automation that triggers when new threats are detected. For more details, see Threat Management.\nCreate a Threat AutomationTo create an automation for Threats:\nLog in to Sysdig Secure as an Admin.\nSelect Automations.\nThe Automations page appears.\nSelect New Automation \u0026gt; Threats.\nThe configuration panel appears.\nFrom Filters select from: Rule Name High Severity Only: Select Yes or No. Source: Select Workload, Host, Container or Cloud. Cluster Workload Cloud User: Select one or more cloud users. Cloud Provider When you\u0026rsquo;re finished choosing filters, select Done.\nSelect the + icon under the condition box.\nThe Select an Action modal appears. You can add another Condition or configure notifications with notification channels, such as Slack, MS Teams, and Email.\nWhen you are finished configuring actions and conditions, click Save.\nExecutionsYou can view Executions to see the history of your Automations and debug any problems they may have.\nEach time an automation is triggered, Sysdig logs the full path of the workflow to determine the state of each node (condition, action), and whether it was successful.\nYou can review the success of failure of Executions in the UI through a color-coded list:\nGreen: A successful action was taken, for actions like Email, Slack, or Jira. Red: The condition or action failed in some way. This may be due to incorrect use or invalid key or value, or incorrect action configuration, or because the notification channel failed to receive the response. Review ExecutionsTo review executions:\nLog in to Sysdig Secure.\nSelect Automations.\nSelect an existing Automation or create a new Automation.\nThe Editor | Executions tabs appear.\nSelect the Executions tab.\nThe executions provide the log history for each triggered automation. An execution only happens if all conditions in the trigger match as true.\nClick an execution to see a history of all executions that have succeeded.\nSelect an execution to view the path the execution took.\nYou can select each node to view the state of the node. This includes all the values that were checked against that condition node, as well as the configurations for that node at that time of the execution.\nIf one or more nodes have a failed state, it is logged as a failed execution\nDelete an AutomationTo delete an automation:\nLog in to Sysdig Secure as an Admin.\nSelect Automations from the left navigation bar.\nThe Automations page appears.\nOn the right side of an automation listing, select the three-dot menu icon.\nSelect Delete, and confirm Yes, delete.\n","url":"https://docs.sysdig.com/en/sysdig-secure/automations/"},{"id":144,"title":"Configure Sysdig Linux Agent","content":"Follow the instructions on this page to implement configurations found in the Configuration Library.\nFor the latest Helm-based configuration options, see the Shields chart.\nModify the dragent.yaml file to configure the agent. How you configure dragent.yaml depends on whether the agent was installed:\nIn a Kubernetes environment. In a non-orchestrated container, such as a Docker. As a Linux package. KubernetesIf Sysdig agent is installed in a Kubernetes environment with Helm, you can edit the dragent.yaml with Helm.\nTo edit dragent.yaml with Helm, you can:\nAdd configuration to values.yaml. Use key-values as inline arguments with helm install. For example, to edit dragent.yaml in Helm syntax:\nhelm install sysdig-agent \\ --namespace sysdig-agent \\ --set global.clusterConfig.name=\u0026#39;my_cluster\u0026#39; \\ --set global.sysdig.tags.{tag_name_1}={tag_value_1} \\ --set global.sysdig.tags.{tag_name_2}={tag_value_2} \\ --set global.sysdig.tags.{tag_name_3}={tag_value_3} \\ sysdig/sysdig-deploy where for each tag_name you have a specific tag_value like:\nhelm install sysdig-agent \\ --namespace sysdig-agent \\ --set global.clusterConfig.name=\u0026#39;my_cluster\u0026#39; \\ --set global.sysdig.tags.linux=ubuntu \\ --set global.sysdig.tags.dept=dev \\ --set global.sysdig.tags.local=nyc \\ sysdig/sysdig-deploy This command will be translated into the following:\ndata: dragent.yaml: | tags: linux:ubuntu,dept:dev,local:nyc k8s_cluster_name: my_cluster For more details, including instruction on utilizing values.yaml see Sysdig Deploy.\nContainerIf Sysdig agent is installed in a non-orchestrated environment such as Docker, you can edit the dragent.yaml file in one or more of the following ways:\nMount the dragent.yaml file as a Docker volume inside the container.\ndocker run -v /home/admin-user/config-files/sysdig-agent/dragent.yaml:/opt/draios/etc/dragent.yaml ... quay.io/sysdig/agent Pass parameters that will be appended to a dynamically generated dragent.yaml file via the ADDITIONAL_CONF environment variable.\ndocker run -e ADDITIONAL_CONF=\u0026#34;\u0026lt;dragent.yaml parameters\u0026gt;\u0026#34; ... quay.io/sysdig/agent If dragent.yaml is mounted as a Docker volume inside the container, the ADDITIONAL_CONF environment variable will be ignored.\nUse environment variables such as COLLECTOR, ACCESS_KEY, TAGS, and so on to add or override specific parameters in dragent.yaml.\nFormat the TAGS environment variable as a comma-separated list of key-value pairs in one line. For example, -e TAGS=\u0026quot;key1:value1,key2:value2,key3:value3\u0026quot;. Avoid using multiline values or line breaks, as they will result in a malformed dragent.yaml. Pass environment variables directly to the agent such as SYSDIG_AGENT_DRIVER or SYSDIG_BPF_PROBE. Edit dragent.yaml Mount dragent.yaml as a container.\nLog in to the host where the agent is installed.\nLocate and open dragent.yaml.\nIf dragent.yaml is mounted inside an agent container as a Docker volume, it may be located anywhere on the host that the administrator finds convenient.\nEdit the file using proper YAML syntax.\nFor changes to take effect, restart the agent with the command:\ndocker restart sysdig-agent docker runUse the docker run command with -e ADDITIONAL_CONF=\u0026quot;\u0026lt;VARIABLES\u0026gt;\u0026quot; where \u0026lt;VARIABLES\u0026gt; contains all the customized parameters you want to include.\nConvert YAML Parameters to Single-Line FormatTo insert ADDITIONAL_CONF parameters in a docker run command or a DaemonSet file, you must convert the YAML code into a single line. You can do the conversion manually for short snippets. To convert longer portions of YAML, use echo|sed commands:\nWrite your configuration in YAML, as it would be entered directly in dragent.yaml.\nIn a Bash shell, use echo and sed to convert to a single line:\necho \u0026#39;\u0026lt;YAML_CONTENT\u0026gt;\u0026#39; | sed -e \u0026#39;:a\u0026#39; -e \u0026#39;N\u0026#39; -e \u0026#39;$!ba\u0026#39; -e \u0026#39;s/\\n/\\\\n/g\u0026#39; Insert the resulting line into the docker run command or add it to the DaemonSet file as an ADDITIONAL_CONF.\nLinuxIf the Sysdig agent is installed in a Linux host via a .rpm or .deb package, edit dragent.yaml directly.\nOn .rpm installations, environment variables may be specified in /etc/sysconfig/dragent.\nOn .deb installations, environment variables may be specified in /etc/default/dragent.\nThe systemd supervisor does not support inline comments for environment variables. If you edit the file after setup, do not write comments on the same line where you define the environment variable.\nThe agent and its probe-loader shell script understand the following environment variables:\nSYSDIG_AGENT_DRIVER (12.17.0 and newer) SYSDIG_BPF_PROBE Use one of the following:\nAgent version 12.17.0 or newer SYSDIG_AGENT_DRIVER=universal_ebpf Agent versions before 12.17.0 export SYSDIG_BPF_PROBE=\u0026#34;\u0026#34; This environment file is sourced directly by the agent init script. For agent versions before 12.17.0, the export keyword is required.\nEdit dragent.yaml Log in to the host where the agent is installed.\nOpen /opt/draios/etc/dragent.yaml.\nEdit the file using proper YAML syntax. See Examples.\nFor changes to take effect, restart the agent with the command:\nservice dragent restart Environment Variables Used by Entry Point Script for Non-Orchestrated Containers Name\nValue\nDescription\nACCESS_KEY\nYour Sysdig access key.\nRequired.\nTAGS\nMeaningful tags you want applied to your instances.\nOptional. For example:\ntags: linux:ubuntu,dept:dev,local:nyc\nSee sysdig-agent-configmap.yaml.\nREGION\nThe region associated with your Sysdig SaaS application.\nEnter the SaaS region.\nCOLLECTOR\n\u0026lt;collector-hostname.com\u0026gt;\nEnter the hostname or IP address of the Sysdig collector service. Note that when used within dragent.yaml, it must be lowercase (collector).\nFor SaaS regions, see SaaS Regions and IP Ranges.\nFor SaaS applications, you must use either `REGION` or `COLLECTOR`.\nCOLLECTOR_PORT\n6443\nOn-prem only. The port used by the Sysdig collector service. Default: 6443.\nSECURE\ntrue\nUse SSL/TLS to connect to collector service, defaults to true. Set to false to use plaintext HTTP to communicate with the collector service, (not recommended).\nCHECK_CERTIFICATE\ntrue\nOn-prem only. Set to true when using SSL/TLS to connect to the collector service and should check for a valid SSL/TLS certificate.\nADDITIONAL_CONF\nOptional. A place to provide custom configuration values to the agent as environment variables. If `dragent.yaml` is mounted as a Docker volume inside the container, `ADDITIONAL_CONF` will be ignored.\nSYSDIG_PROBE_URL\nOptional. An alternative URL to download precompiled kernel modules.\nEnvironment Variables Used by the Agent Probe-Loader Shell Script Name\nValue\nDescription\nSYSDIG_AGENT_DRIVER\nkmod, universal_ebpf, or legacy_ebpf Optional. The syscall capture driver that is used by the agent. Agent defaults to `kmod` if this environment variable is not set.\nSYSDIG_BPF_PROBE\n\"\" or a path to a custom-built eBPF object file.\nOptional. Deprecated and superseded by SYSDIG_AGENT_DRIVER. The old environment variable that is used to force the agent to load the current eBPF driver. Note:The agent will exit with an error if SYSDIG_AGENT_DRIVER and SYSDIG_BPF_PROBE are set to conflicting values.\nHere is a sample Docker command using environment variables in an on-prem environment with a self-signed certificate:\ndocker run \\ --name sysdig-agent \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;ONPREM_COLLECTOR_HOST\u0026gt; \\ -e COLLECTOR_PORT=6443 \\ -e CHECK_CERTIFICATE=false \\ -e TAGS=\u0026#34;my_tag:value,my_tag2:value\u0026#34; \\ -e ADDITIONAL_CONF=\u0026#34;log:\\n file_priority: debug\\n console_priority: error\u0026#34; \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=350m \\ quay.io/sysdig/agent ","url":"https://docs.sysdig.com/en/sysdig-secure/configure-classic-agent/"},{"id":145,"title":"Dashboards","content":"OverviewWith Sysdig Monitor Dashboards you can:\nCreate queries using a guided mode, called Form-Mode. Create queries using PromQL. Configure the event overlay which lets you enhance dashboards with event information. Leverage different visualization types. Create a New DashboardYou can create a dashboard from scratch, or start with a template from the Dashboard Library.\nCreate a Dashboard from the LibraryIn the Dashboard Library, you can use templates to serve as starting points for your own dashboard:\nLog in to Sysdig Monitor.\nSelect Dashboards.\nSelect the Dashboard Library tab.\nSelect a template.\nThe Dashboard opens.\nTo customize the dashboard, select Copy to My Dashboards.\nEnter a name for the new Dashboard.\nSelect Create and Open.\nCreate a Dashboard from Dashboard ManagerEvery dashboard must have at least one panel. You can start to create a dashboard by creating a new panel:\nLog in to Sysdig Monitor.\nSelect Dashboards.\nThe Dashboard Manager opens.\nSelect Create a New Dashboard from the top right corner.\nThe New Panel page appears.\nDefine the metric and visualization type.\nSelect Save.\nThe dashboard is created with the panel you defined. You can add edit the dashboard\u0026rsquo;s name, or select Add Panel to add more panels.\nCreate a Dashboard from ExploreYou can create a dashboard from the Explore module to transfer your findings from a metric query into a dashboard:\nLog in to Sysdig Monitor.\nSelect Explore \u0026gt; Metrics Explorer.\nDefine a metric query.\nSelect Actions \u0026gt; Create Dashboard Panel from the top right corner.\nThe Copy Panel to Dashboard modal appears.\nSelect an existing dashboard from the drop-down, or enter a new name to create a new dashboard.\n(Optional) Check the box to Open the Dashboard after copying.\nSelect Copy.\nDelete a DashboardThe owner or the administrator of a shared dashboard can delete it.\nWhen a user duplicates a dashboard, they become the owner of the copy and can delete it freely.\nDashboards can be deleted from different locations:\nDashboard settings Dashboard Manager Define Dashboard ScopeTo configure the scope of a dashboard:\nClick the edit (pencil) icon beside the Dashboard\u0026rsquo;s current scope. The scope dropdown appears.\nThe scope editor dynamically filters the available label key-value pairs based on previous filter selections, so that only valid options are shown. For example, if the value of the kube_namespace_name label is kube-system, the values of the subsequent label, container_name will be filtered by kube-system. This means the containers rendered for filtering are only those that are part of the kube-system namespace.\nEdit VariablesIn the dashboard scope editor, you can select a label key such as kube_cluster_name and assign it a value like prod-cluster-01. This selection creates a variable $kube_namespace_name that you can use across your dashboard. Any panel that includes this variable in its query will automatically be scoped to the selected cluster, making it easy to apply consistent filtering across the entire dashboard.\nSet a Default DashboardYou can configure a default dashboard by setting the default entry point for a team. For more information on configuring a default entry point, see Team Settings - Default Entry Point.\nShare a Dashboard with TeamsYou can share a dashboard with your current team, allowing other team members to view the dashboard, as well as edit the panels if they have edit permissions within the team.\nYou can only share dashboards with teams you have membership for. Otherwise, the list of teams under Shared with may be empty. One workaround is to transfer dashboard ownership to an Admin user who has membership across all teams, or by requesting membership to other teams.\nIf a dashboard has been shared with another team, a user within that team can then copy it to make it their own if they wish.\nTo share a dashboard:\nSelect the dashboard you want to share.\nClick the Dashboard Settings (three dots) icon and select Dashboard Settings.\nIn the Dashboard Settings page, use the Shared With drop-down.\nSelect one of the three options:\nNot Shared: If selected, the specified Dashboard cannot be shared with a team or selected team the owner is a member of.\nAll Teams: If selected, the owners of the Dashboard can share with all the teams that they are part of.\nSelected Teams: If selected, the owner of the Dashboard can share with a selected list of teams. You can select one of the available teams in the drop-down, and select member permission:\nView Only: This permission allows members to view the Dashboard.\nCollaborator: A collaborator can edit the Dashboard.\nEnable Public SharingYou can share dashboards outside of the internal team by using public URLs. This allows external users to review the dashboard metrics while restricting access to changing panels and configurations. The scope parameters, including scope variables, are included in the Dashboard URL.\nTo enable sharing the public link of a dashboard, follow these steps:\nSelect the dashboard you want to share, click the Dashboard Settings (three dots) icon, and select Dashboard Settings. In the Dashboard Settings page, enable the Public Sharing slider. When enabled, the dashboard is visible with scope parameters to anyone with the link. If this setting is disabled, the link will no longer work, and the setting will need to be re-enabled and shared again in order for the dashboard to be accessed.\nTransfer Dashboard OwnershipDashboards have a single owner. Dashboard owners and administrators can transfer ownership of a dashboard through the UI.\nGeneral Guidelines When you delete a user through the UI, any shared dashboards they own or have created will be preserved by default, with the deactivated user still marked as the dashboard owner. Before you delete a user with the API, you must transfer any shared dashboards owned by the user to another user. Otherwise, the following error appears: {\u0026quot;type\u0026quot;:\u0026quot;bad_request\u0026quot;,\u0026quot;message\u0026quot;:\u0026quot;User owns shared or public dashboard, cannot proceed with delete\u0026quot;,\u0026quot;details\u0026quot;:[]} Administrators can only transfer dashboards belonging to other users if the dashboards are shared. Private dashboards cannot be seen by other users, including administrators, and therefore cannot be transferred. When editing a user, the administrator can transfer their shared dashboards to a new owner. Things to know before changing the dashboard ownership: It is a good practice to ensure that the new owner is a member of the same teams as the previous owner to avoid disrupting the flow. The administrator can preview the teams that will no longer be able to access the dashboard before confirming the transfer. It is not necessary for the new owner to be part of any teams the previous owner was part of, but in this case, the dashboard will no longer be shared with any of the teams it was shared with previously. Transfer Ownership as an Admin Log in to Sysdig Monitor and select Settings \u0026gt; Users.\nSelect the user from whom you want to transfer dashboard ownership.\nSelect the dashboards you want to re-assign.\nClick Transfer Ownership.\nThe Transfer Dashboard Ownership modal appears.\nSelect a new user and click Transfer.\nTransfer Ownership as a User In the Dashboards module, select the relevant dashboard from the left panel.\nClick the Settings (three dots) icon for the dashboard.\nSelect Transfer Ownership.\nThe Transfer Dashboard Ownership modal appears.\nSelect a new user.\nReview the details.\nThe teams indicated with cross-out text are the ones that had access to the dashboard earlier and will lose access to it after the transfer.\nThe dashboard will also be visible to all the teams that the new owner is part of. If you are not part of the teams that the new owner is a member of, you will no longer have the visibility to the dashboard.\nIf everything looks ok, click Transfer.\nSearch in DashboardsUse the / shortcut to invoke the panel search pane which enables you to find panels within a given dashboard. The search capabilities are:\nSearch by metric name Search by label name Search by Panel title or description When searching, partial names can be used, such as sysdig_container_ or Memory.\nDefine Minimum Interval for PromQL QueriesWhen working with PromQL queries you can use the $__interval variable and Sysdig will apply the most appropriate sampling corresponding to the time range you have selected. Sometimes you might have some metrics that report data with a coarser granularity and you want to apply an interval that is higher than the proposed.\nFor example, if you have a metric that reports data every 3m, and you have selected the 1h preset in the time navigation, the $__interval will be replaced with a time granularity of 10s. This will result in time charts with isolated data points instead of lines.\nYou can resolve this by setting the Default PromQL Query Min Interval option to 3m on the Dashboard Settings page.\nThe value must be expressed as a time granularity, for example: 10s, 1m, 1h, and must be between 10s and 1d.\nNote: If the proposed interval is greater than the minimum interval, the minimum interval will be ignored.\nThe setting will be applied to all the PromQL queries in the dashboard and it can be overridden by specifying a different value in the query options.\nUse CaseLeverage Event Overlay for Increased ContextExamine events directly on the dashboard panels and correlate anomalies and issues with the events. The height of the event bucket is proportional to the number of events and the color indicates the highest severity of the events present.\nThe following example shows how the presence of the event overlay lets you quickly spot that the drop in CPU Requested per Node, is actually due to a container dying (due to an OOM).\nWithout Context With Context To configure the Event Overlay, select the Dashboard Settings (three dots) \u0026gt; Events Display.\nThe following options are available when configuring the Events Display:\nOption Description Filter Filters events by the event search syntax and searched fields. Scope Determines whether the range of events displayed includes those for dashboard scope or team scope. Severity Determines whether only high severity events or all events are displayed. Event Type Determines what types of events to be displayed. The supported events types are alert, custom events, containers, or Kubernetes. Status Determines the state of events displayed. The supported status are Triggered, Resolved, Acknowledged, Un-acknowledged. ","url":"https://docs.sysdig.com/en/sysdig-monitor/dashboards/"},{"id":146,"title":"Data Retention","content":"Sysdig Secure Retention Limits Component Retention Activity Audit Kubernetes(kube) and Cmd (command) comply with the runtime data retention policy. Net (connection) and File (fileaccess) the minimum between 7 days and your runtime data retention policy subscription. Captures Sysdig Storage: Based on your runtime data retention policy subscription. Custom Storage: Unlimited. CSPM (Posture + Inventory) Resource data is refreshed every 24 hours when a posture evaluation is run. Stale data (data from a failed scan because of a disconnected/removed agent, deleted cluster/account, or because the account lost its permissions) is shown for 7 days since the last scan. Compliance data is stored for a year. Pipeline Results (cli-scan ) 90 days Policy Events Runtime data policy based on your subscription. Registry Scanning Results 90 days Reports 7 days for all reports generated as a PDF, CSV, or JSON. This includes Vulnerability Management (VM), Compliance, and Posture reporting. Runtime Reporting Available through VM reporting, this report includes workloads active when the report was created, as well as those terminated within the prior 24 hours. Runtime view Workloads disappear from the Runtime view within 15 minutes after termination. Workloads will never expire as long as they are running. Sysdig Platform Audit 90 days. Vulnerability Management Reports 14 days IAM Resources 24 hours. Runtime data retention policy is based on your subscription and available in your subscription page. In case this not specified in your contract, it\u0026rsquo;s 90 days.\nIf required, you can change the standard data retention settings using Sysdig REST API. Contact your Sysdig support team or professional services for assistance as there are a variety of storage and timeline implications to consider before making such a change.\nSysdig Monitor Metric Retention Limits Metric Granularity (Samples) Retention 10s 7 days 1m 14 days 10m 30 days 1h 3 months 1d 12 months Sysdig Monitor Events Retention Limits Components Retention All Events The total event limit includes all event types: Infrastructure, Alert, Sysdig, and Custom events. 2,000,000 Total Captures 90 days Custom Events 30 days Infrastructure Events 30 days Resolved Alert Events Acknowledged Alert Events 30 days Sysdig Platform Audit 90 days Unresolved Alert Events Unacknowledged Alert Events 30 days ","url":"https://docs.sysdig.com/en/administration/data-retention/"},{"id":147,"title":"ECS on EC2","content":" These instructions are valid only for ECS clusters using Elastic Compute Cloud (EC2) instances. For information on ECS Fargate clusters, see AWS Fargate Serverless Agents.\nPrerequisites Review Installation Requirements Understand Agent Drivers Collect the following: Sysdig access key Collector address Ensure you have an EC2 cluster set up in AWS. OverviewTo install the Sysdig agent on ECS, follow these steps:\nCreate an ECS task definition for the Sysdig agent. Register the task definition in your AWS account. Create a service with the previous task definition to run the Sysdig agent on each of the nodes of your ECS cluster. Deployment1. Create an ECS Task DefinitionUse the values from the prerequisites to customize the JSON snippet below and save it as a file named sysdig-agent-ecs.json.\nNote that memory and cpu have both been set to 1024; depending on the size of your cluster you might want to tune those values.\nUniversal eBPF Driver Expand { \u0026#34;family\u0026#34;: \u0026#34;sysdig-agent-ecs\u0026#34;, \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;sysdig-agent\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/agent-slim\u0026#34;, \u0026#34;cpu\u0026#34;: 1024, \u0026#34;memory\u0026#34;: 1024, \u0026#34;privileged\u0026#34;: true, \u0026#34;environment\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;ACCESS_KEY\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$ACCESS_KEY\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;COLLECTOR\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$COLLECTOR\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;TAGS\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$TAG1,TAG2\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_AGENT_DRIVER\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;universal_ebpf\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;ADDITIONAL_CONF\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;\u0026lt;config_yaml\u0026gt;\u0026#34; // Example: \u0026#34;value\u0026#34;: \u0026#34;malware_control\\n enabled: true\u0026#34; // Must be a valid YAML, converted into a single-line string with \\n for a newline } ], \u0026#34;mountPoints\u0026#34;: [ { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/dev\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;dev\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/proc\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;proc\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/var/run/docker.sock\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;sock\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/sys/kernel/debug\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;debug\u0026#34; } ] } ], \u0026#34;pidMode\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;networkMode\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;volumes\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;sock\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/var/run/docker.sock\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;dev\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/dev/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;proc\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/proc/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;debug\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/sys/kernel/debug\u0026#34; } } ], \u0026#34;requiresCompatibilities\u0026#34;: [ \u0026#34;EC2\u0026#34; ] } Kernel Module Driver Expand { \u0026#34;family\u0026#34;: \u0026#34;sysdig-agent-ecs\u0026#34;, \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;sysdig-agent\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/agent-slim\u0026#34;, \u0026#34;cpu\u0026#34;: 1024, \u0026#34;memory\u0026#34;: 1024, \u0026#34;privileged\u0026#34;: true, \u0026#34;environment\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;ACCESS_KEY\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$ACCESS_KEY\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;COLLECTOR\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$COLLECTOR\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;TAGS\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$TAG1,TAG2\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;ADDITIONAL_CONF\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;\u0026lt;config_yaml\u0026gt;\u0026#34; // Example: \u0026#34;value\u0026#34;: \u0026#34;malware_control\\n enabled: true\u0026#34; // Must be a valid YAML, converted into a single-line string with \\n for a newline } ], \u0026#34;mountPoints\u0026#34;: [ { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/boot\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;boot\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/dev\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;dev\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/lib/modules\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;modules\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/proc\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;proc\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/var/run/docker.sock\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;sock\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/usr\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;usr\u0026#34; } ], \u0026#34;dependsOn\u0026#34;: [ { \u0026#34;containerName\u0026#34;: \u0026#34;sysdig-agent-kmodule\u0026#34;, \u0026#34;condition\u0026#34;: \u0026#34;SUCCESS\u0026#34; } ] }, { \u0026#34;name\u0026#34;: \u0026#34;sysdig-agent-kmodule\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/agent-kmodule\u0026#34;, \u0026#34;memory\u0026#34;: 512, \u0026#34;privileged\u0026#34;: true, \u0026#34;essential\u0026#34;: false, \u0026#34;mountPoints\u0026#34;: [ { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/boot\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;boot\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/dev\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;dev\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/lib/modules\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;modules\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/proc\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;proc\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/var/run/docker.sock\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;sock\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/usr\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;usr\u0026#34; } ] } ], \u0026#34;pidMode\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;networkMode\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;volumes\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;sock\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/var/run/docker.sock\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;dev\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/dev/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;proc\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/proc/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;boot\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/boot/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;modules\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/lib/modules/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;usr\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/usr/\u0026#34; } } ], \u0026#34;requiresCompatibilities\u0026#34;: [ \u0026#34;EC2\u0026#34; ] } eBPF Driver Expand { \u0026#34;family\u0026#34;: \u0026#34;sysdig-agent-ecs\u0026#34;, \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;sysdig-agent\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/agent-slim\u0026#34;, \u0026#34;cpu\u0026#34;: 1024, \u0026#34;memory\u0026#34;: 1024, \u0026#34;privileged\u0026#34;: true, \u0026#34;environment\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;ACCESS_KEY\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$ACCESS_KEY\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;COLLECTOR\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$COLLECTOR\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;TAGS\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$TAG1,TAG2\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_BPF_PROBE\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;ADDITIONAL_CONF\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;\u0026lt;config_yaml\u0026gt;\u0026#34; // Example: \u0026#34;value\u0026#34;: \u0026#34;malware_control\\n enabled: true\u0026#34; // Must be a valid YAML, converted into a single-line string with \\n for a newline } ], \u0026#34;mountPoints\u0026#34;: [ { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/boot\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;boot\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/dev\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;dev\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/lib/modules\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;modules\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/proc\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;proc\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/var/run/docker.sock\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;sock\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/usr\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;usr\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/sys/kernel/debug\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;debug\u0026#34; } ], \u0026#34;dependsOn\u0026#34;: [ { \u0026#34;containerName\u0026#34;: \u0026#34;sysdig-agent-kmodule\u0026#34;, \u0026#34;condition\u0026#34;: \u0026#34;SUCCESS\u0026#34; } ] }, { \u0026#34;name\u0026#34;: \u0026#34;sysdig-agent-kmodule\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/agent-kmodule\u0026#34;, \u0026#34;memory\u0026#34;: 512, \u0026#34;privileged\u0026#34;: true, \u0026#34;environment\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_BPF_PROBE\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;\u0026#34; } ], \u0026#34;essential\u0026#34;: false, \u0026#34;mountPoints\u0026#34;: [ { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/boot\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;boot\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/dev\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;dev\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/lib/modules\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;modules\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/proc\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;proc\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/var/run/docker.sock\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;sock\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/usr\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;usr\u0026#34; } ] } ], \u0026#34;pidMode\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;networkMode\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;volumes\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;sock\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/var/run/docker.sock\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;dev\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/dev/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;proc\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/proc/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;boot\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/boot/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;modules\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/lib/modules/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;usr\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/usr/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;debug\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/sys/kernel/debug\u0026#34; } } ], \u0026#34;requiresCompatibilities\u0026#34;: [ \u0026#34;EC2\u0026#34; ] } 2. Register a Task DefinitionOnce your task definition is ready, ensure that you register it in your AWS account:\naws ecs register-task-definition \\ --cli-input-json file://sysdig-agent-ecs.json 3. Run the Agent as an ECS ServiceUsing the ECS task definition you have created, create a service in the cluster where you want Sysdig monitor and perform threat detection.\naws ecs create-service \\ --cluster $CLUSTER_NAME \\ --service-name sysdig-agent-svc \\ --launch-type EC2 \\ --task-definition sysdig-agent-ecs \\ --scheduling-strategy DAEMON With the agent installed, Sysdig will begin auto-discovering your containers and other resources of your ECS environment.\n","url":"https://docs.sysdig.com/en/sysdig-secure/install-agent-components/ecs-on-ec2/"},{"id":148,"title":"Monitor Subscription","content":"To access the Subscription page:\nLog in as administrator to Sysdig Monitor.\nSelect Settings \u0026gt; Subscription via the user menu in the bottom left corner.\nYour current subscription information is displayed.\nIf you also purchased Sysdig Secure, you will be able to see its subscription details by clicking the \u0026ldquo;Go to Secure\u0026rdquo; button on the top right. Read about the content of that page in Secuure Subscription.\nSubscription DetailsUnder Subscription Details, you can find:\nYour product: Sysdig Monitor, or Sysdig Platform (Sysdig Secure and Sysdig Monitor). Your tier. The contract billing cycle. The type and number of reserved and on-demand resources included in your Sysdig subscription. Specifically regarding the Monitor product: Host Agents Time Series UsageUnder the Subscription Details section, you can find the usage for each resource included in your subscription, depending on the product.\nPlatform subscriptions will have Monitor and Secure resources in their entitlement.\nMonitor and Secure resources (related to both, depending on the Product and Tier):\nHost Agents: Reserved and on-demand host agents. See Host Agent Licenses. Active host agents deployment type overview: Currently connected agents breakdown per deployment type. See Active host agents deployment type overview. Host Agents - Previous Hour: Reserved and on-demand for the previous hour. Monitor resources:\nTime Series - Previous Hour: Applicable to Monitor only. See Time Series Billing. Secure resources:\nCompute Resources: Number of Compute Resources across all Cloud accounts. See Compute Resources. Cloud Logs - Month to Date: Number of analyzed log events per month. See Cloud Logs. Container as a Service usage: Container as a Service (CaaS) usage month to date (AWS Fargate, Google Cloud Run, and Azure Container Apps). Applicable to Secure only. See CaaS usage. Sysdig Sage: Number of prompts submitted for the current month, over the available entitlement. For more details, see Sysdig Sage. Host AgentsHost agents entitlement and usage is reported in two sections:\nHost Agents - Current Usage Active host agents deployment type overview Current UsageThe section displays the number of currently connected agents, compared to the entitlement.\nThe bar on the left represents the agents included in the subscription, showing you how many slots you're currently using, compared to those that are available.\nOn the right, the on-demand bar shows you how many additional agents you can connect, on top of the reserved entitlement. If your contract doesn't include on-demand usage, this will be disabled, meaning that you can only fill the reserved available slots, after which, additional connections will be refused.\nActive Host Agents Deployment Type Overview This bar breaks down the currently deployed agents into different types:\nContainerised: The number of agents running in a containerized environment. Non-containerised - The number of agents running in a non-containerised environment. Unspecified - The number of agents running in an unknown environment. Update Sysdig Agent to version 12.18.0 or later to receive environment information. Agent ConnectionsAgents connect on a first-come, first-served basis. In the event of an over-subscription (more agents wanting to communicate than are licensed), they will attempt to reconnect on a periodic basis. Once an existing communicating instance goes down and disconnects, the next agent in the queue will connect.\nWhen shutting down a host for any reason, the agent's license will not be immediately released. This permits the agent to retain its licensing slot for short outages or a reboot. The time-out interval can take up to 20 minutes, and if the connection has not been re-established within the interval the license will be released for use by the next host waiting to connect.\nThe distinction between reserved and on-demand agents is financial, not technical; when on-demand agents are used they perform exactly like reserved agents.\n","url":"https://docs.sysdig.com/en/docs/administration/subscription/monitor-sub/"},{"id":149,"title":"SIEM and Data Platforms","content":"Sysdig supports:\nStandard event forwarding Agent local forwarding Supported Data TypesStandard event forwarding and agent local forwarding support different data types.\nSupported Data Types Standard Agent Local Notes Runtime Policy events ✅ ✅ Available in agent local forwarding only if generated by the agent. For details, see Agent Local Forwarding. Activity Audit ✅ ✅ kube activities are available for agent local forwarding when Kubernetes Audit Logging is installed with the AuditLog. Sysdig Platform Audit ✅ Monitor events ✅ If Sysdig Monitor is installed Standard Event ForwardingYou can use the Sysdig Secure UI to configure event forwarding to designated third-party systems, including open-ended integrations using Webhook or Syslog. These integrations pass the data through the Sysdig backend and forward to external systems using applicable APIs.\nPrerequisitesYou must be logged in to Sysdig Secure as an Administrator to access the event forwarding options.\nAdd Standard Integrations Log in to Sysdig Secure as an Admin.\nSelect Integrations \u0026gt; SIEM \u0026amp; Data Platforms.\nClick +Add Integration.\nChoose a listed integration, or Syslog or Webhook.\nComplete the relevant integration fields in UI.\nReview Integration StatusTo review the status of integrations:\nLog in to Sysdig Secure.\nSelect Integrations \u0026gt; SIEM \u0026amp; Data Platforms.\nIn the Status column, you will see one of the possible statuses:\nConnected: The integration is successful. No errors have been found in the last 24 hours. Not Connected: The integration has not been set up yet. Warning: The integration has had issues in the last 24 hours and the delivery of at least a message was retried. Error: When a message delivery fails after three attempts, the integration status appears as Error and the integration is inhibited for the next five minutes. This ensures the integration does not flood the receiver side with messages. To review an integration\u0026rsquo;s status in more detail:\nSelect an integration with a Warning or Error status.\nThe integration detail page opens.\nReview the history under the Status section. Here, you can find out when and why the integrations status changed.\nThis may be due to an application error, or too many message delivery failures.\nDelete Standard IntegrationsTo delete an existing integration:\nLog in to Sysdig Secure as Admin.\nSelect Settings \u0026gt; Event Forwarding or Integrations \u0026gt; Event Forwarding.\nClick the three-dot icon beside an integration.\nClick Delete Integration.\nTo confirm, select Yes, delete.\nAgent Local ForwardingWith agent v.12.18.0+, you can forward data directly from the Sysdig agent. With this method, the data reaches the target platform without passing through the Sysdig backend. This avoids exposing your SIEM to the internet.\nKey differences from the standard event forwarding option:\nThe local forwarder does not support X.509 authentication. Some labels available might not be available as they are populated in a post-processing phase. Description and agentId fields are not available. Requires manual configuration of agent config files rather than UI entry fields. Only the events generated by the agent are available: Workload events (Container Drift, List Matching, Malware and Workload policies/rules) Kubernetes audit, if installed with the AuditLog setup Configure Agent Local ForwardingSupported TypesThe following channels and types are supported:\nType Runtime policy events Activity Audit CHRONICLE ✅ ❌ ELASTIC ✅ ✅ KAFKA ✅ ✅ KINESIS_FIREHOSE ✅ ✅ KINESIS_DATA_STREAMS ✅ ✅ MCM ✅ ❌ PUBSUB ✅ ✅ QRADAR ✅ ✅ SCC ✅ ❌ SENTINEL ✅ ✅ SPLUNK ✅ ✅ SQS ✅ ✅ SYSLOG ✅ ✅ WEBHOOK ✅ ✅ Enable the ForwarderEdit the agent values.yaml (Helm) or dragent.yaml (non-Helm) to contain the settings to enable the forwarder and to define what data to send to it:\nFor values.yaml (Helm)\nlocalForwarder: enabled: true transmitMessageTypes: - POLICY_EVENTS - SECURE_AUDIT For dragent.yaml (non-Helm)\nlocal_forwarder: enabled: true transmit_message_types: - POLICY_EVENTS - SECURE_AUDIT Message_types can be either or both options.\nConfigure the Target ParametersAdd the configuration details for a selected integration.\nHelm: If you are using Helm, add to your values.yaml file under the Integrations config parameter. Non-Helm: If you are not using Helm, then add the configuration details in another file located in the same directory as the dragent.yaml: local_forwarder_config.yaml. The integration entries for each type follow this sample format:\nintegrations: - type: SPLUNK channels: - SECURE_EVENTS_POLICIES - ACTIVITY_AUDIT configuration: Index: indexname ServiceToken: *** ServiceURL: \u0026#34;https://yoursplunkurl.com\u0026#34; Check the Agent Local Forwarding section on each subpage for the details of that type. For example, see Splunk.\nReference: JSON Formats Used per Data SourceThis section is for reference only. In most cases, there is no need to change the default format.\nPolicy Event PayloadPolicy Event SeverityThe severity field in the payload is an integer. The following table shows different values event severities can have.\nEvent Severity JSON severity value High 0, 1, 2, 3 Medium 4, 5 Low 6 Info 7 There are two formats supported. See the Runtime Policy Events in JSON Format . The Legacy format has been deprecated as of Jan 18, 2024. See Data Types for Events Forwarding.\nTo learn about Sysdig Monitor event severity levels, see Severity and Status.\nRuntime Policy Events Payload{ \u0026#34;id\u0026#34;: \u0026#34;164ace360cc3cfbc26ec22d61b439500\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;policy\u0026#34;, \u0026#34;timestamp\u0026#34;: 1606322948648718268, \u0026#34;timestampRFC3339Nano\u0026#34;: \u0026#34;2020-11-25T16:49:08.648718268Z\u0026#34;, \u0026#34;originator\u0026#34;: \u0026#34;policy\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;runtime\u0026#34;, \u0026#34;source\u0026#34;: \u0026#34;syscall\u0026#34;, \u0026#34;rawEventOriginator\u0026#34;: \u0026#34;linuxAgent\u0026#34;, \u0026#34;rawEventCategory\u0026#34;: \u0026#34;runtime\u0026#34;, \u0026#34;sourceDetails\u0026#34;: { \u0026#34;sourceType\u0026#34;: \u0026#34;workload\u0026#34;, \u0026#34;sourceSubType\u0026#34;: \u0026#34;host\u0026#34; }, \u0026#34;engine\u0026#34;: \u0026#34;falco\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;Notable Filesystem Changes\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Identified notable filesystem activity that might change sensitive/important files. This differs from Suspicious Filesystem Changes in that it looks more broadly at filesystem activity, and might have more false positives as a result.\u0026#34;, \u0026#34;severity\u0026#34;: 0, \u0026#34;agentId\u0026#34;: 13530, \u0026#34;containerId\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;machineId\u0026#34;: \u0026#34;08:00:27:54:f3:9d\u0026#34;, \u0026#34;actions\u0026#34;: [ { \u0026#34;type\u0026#34;: \u0026#34;POLICY_ACTION_CAPTURE\u0026#34;, \u0026#34;successful\u0026#34;: true, \u0026#34;token\u0026#34;: \u0026#34;abffffdd-fba8-42c7-b922-85364b00eeeb\u0026#34;, \u0026#34;afterEventNs\u0026#34;: 5000000000, \u0026#34;beforeEventNs\u0026#34;: 5000000000 } ], \u0026#34;content\u0026#34;: { \u0026#34;policyId\u0026#34;: 544, \u0026#34;baselineId\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;ruleName\u0026#34;: \u0026#34;Write below etc\u0026#34;, \u0026#34;ruleType\u0026#34;: \u0026#34;RULE_TYPE_FALCO\u0026#34;, \u0026#34;ruleTags\u0026#34;: [ \u0026#34;NIST_800-190\u0026#34;, \u0026#34;NIST_800-53\u0026#34;, \u0026#34;ISO\u0026#34;, \u0026#34;NIST_800-53_CA-9\u0026#34;, \u0026#34;NIST_800-53_SC-4\u0026#34;, \u0026#34;NIST\u0026#34;, \u0026#34;ISO_27001\u0026#34;, \u0026#34;MITRE_T1552_unsecured_credentials\u0026#34;, \u0026#34;MITRE_T1552.001_credentials_in_files\u0026#34; ], \u0026#34;output\u0026#34;: \u0026#34;File below /etc opened for writing (user=root command=touch /etc/ard parent=bash pcmdline=bash file=/etc/ard program=touch gparent=su ggparent=sudo gggparent=bash container_id=host image=\u0026lt;NA\u0026gt;)\u0026#34;, \u0026#34;fields\u0026#34;: { \u0026#34;container.id\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;container.image.repository\u0026#34;: \u0026#34;\u0026lt;NA\u0026gt;\u0026#34;, \u0026#34;falco.rule\u0026#34;: \u0026#34;Write below etc\u0026#34;, \u0026#34;fd.directory\u0026#34;: \u0026#34;/etc/pam.d\u0026#34;, \u0026#34;fd.name\u0026#34;: \u0026#34;/etc/ard\u0026#34;, \u0026#34;group.gid\u0026#34;: \u0026#34;8589935592\u0026#34;, \u0026#34;group.name\u0026#34;: \u0026#34;sysdig\u0026#34;, \u0026#34;proc.aname[2]\u0026#34;: \u0026#34;su\u0026#34;, \u0026#34;proc.aname[3]\u0026#34;: \u0026#34;sudo\u0026#34;, \u0026#34;proc.aname[4]\u0026#34;: \u0026#34;bash\u0026#34;, \u0026#34;proc.cmdline\u0026#34;: \u0026#34;touch /etc/ard\u0026#34;, \u0026#34;proc.name\u0026#34;: \u0026#34;touch\u0026#34;, \u0026#34;proc.pcmdline\u0026#34;: \u0026#34;bash\u0026#34;, \u0026#34;proc.pname\u0026#34;: \u0026#34;bash\u0026#34;, \u0026#34;user.name\u0026#34;: \u0026#34;root\u0026#34; }, \u0026#34;falsePositive\u0026#34;: false, \u0026#34;matchedOnDefault\u0026#34;: false, \u0026#34;policyVersion\u0026#34;: 2, \u0026#34;policyOrigin\u0026#34;: \u0026#34;Sysdig\u0026#34; }, \u0026#34;labels\u0026#34;: { \u0026#34;host.hostName\u0026#34;: \u0026#34;ardbox\u0026#34;, \u0026#34;process.name\u0026#34;: \u0026#34;touch /etc/ard\u0026#34; } } Activity Audit Forwarding PayloadsEach of the activity audit types has its own JSON format.\nCommand (cmd) Payload{ \u0026#34;id\u0026#34;: \u0026#34;164806c17885b5615ba513135ea13d79\u0026#34;, \u0026#34;agentId\u0026#34;: 32212, \u0026#34;cmdline\u0026#34;: \u0026#34;calico-node -felix-ready -bird-ready\u0026#34;, \u0026#34;comm\u0026#34;: \u0026#34;calico-node\u0026#34;, \u0026#34;pcomm\u0026#34;: \u0026#34;apt-get\u0026#34;, \u0026#34;containerId\u0026#34;: \u0026#34;a407fb17332b\u0026#34;, \u0026#34;count\u0026#34;: 1, \u0026#34;customerId\u0026#34;: 1, \u0026#34;cwd\u0026#34;: \u0026#34;/\u0026#34;, \u0026#34;hostname\u0026#34;: \u0026#34;qa-k8smetrics\u0026#34;, \u0026#34;loginShellDistance\u0026#34;: 0, \u0026#34;loginShellId\u0026#34;: 0, \u0026#34;pid\u0026#34;: 29278, \u0026#34;ppid\u0026#34;: 29275, \u0026#34;procExepath\u0026#34;: \u0026#34;/usr/bin/calico-node\u0026#34;, \u0026#34;rxTimestamp\u0026#34;: 1606322949537513500, \u0026#34;timestamp\u0026#34;: 1606322948648718268, \u0026#34;timestampRFC3339Nano\u0026#34;: \u0026#34;2020-11-25T16:49:08.648718268Z\u0026#34;, \u0026#34;tty\u0026#34;: 34816, \u0026#34;type\u0026#34;: \u0026#34;command\u0026#34;, \u0026#34;uid\u0026#34;: 0, \u0026#34;username\u0026#34;: \u0026#34;root\u0026#34;, \u0026#34;userLoginUid\u0026#34;: 4294967295, \u0026#34;userLoginName\u0026#34;: \u0026#34;\u0026lt;NA\u0026gt;\u0026#34;, \u0026#34;labels\u0026#34;: { \u0026#34;aws.accountId\u0026#34;: \u0026#34;059797578166\u0026#34;, \u0026#34;aws.instanceId\u0026#34;: \u0026#34;i-053b1f0509fdbc15a\u0026#34;, \u0026#34;aws.region\u0026#34;: \u0026#34;us-east-1\u0026#34;, \u0026#34;container.image.digest\u0026#34;: \u0026#34;sha256:26c68657ccce2cb0a31b330cb0be2b5e108d467f641c62e13ab40cbec258c68d\u0026#34;, \u0026#34;container.image.id\u0026#34;: \u0026#34;d2e4e1f51132\u0026#34;, \u0026#34;container.label.io.kubernetes.pod.namespace\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;container.name\u0026#34;: \u0026#34;bash\u0026#34;, \u0026#34;host.hostName\u0026#34;: \u0026#34;ip-172-20-46-221\u0026#34;, \u0026#34;host.mac\u0026#34;: \u0026#34;12:9f:a1:c9:76:87\u0026#34;, \u0026#34;kubernetes.node.name\u0026#34;: \u0026#34;ip-172-20-46-221.ec2.internal\u0026#34;, \u0026#34;kubernetes.pod.name\u0026#34;: \u0026#34;bash\u0026#34; } } Network (net) Payload{ \u0026#34;id\u0026#34;: \u0026#34;164806f43b4d7e8c6708f40cdbb47838\u0026#34;, \u0026#34;agentId\u0026#34;: 32212, \u0026#34;clientIpv4\u0026#34;: 2886795285, \u0026#34;clientIpv4Dot\u0026#34;: \u0026#34;172.17.0.21\u0026#34;, \u0026#34;clientPort\u0026#34;: 60720, \u0026#34;comm\u0026#34;: \u0026#34;kubectl\u0026#34;, \u0026#34;containerId\u0026#34;: \u0026#34;da3abd373c7a\u0026#34;, \u0026#34;customerId\u0026#34;: 1, \u0026#34;direction\u0026#34;: \u0026#34;out\u0026#34;, \u0026#34;dnsDomains\u0026#34;: [ \u0026#34;api.openai.com\u0026#34; ], \u0026#34;errorCode\u0026#34;: 0, \u0026#34;hostname\u0026#34;: \u0026#34;qa-k8smetrics\u0026#34;, \u0026#34;l4protocol\u0026#34;: 6, \u0026#34;pid\u0026#34;: 2452, \u0026#34;processName\u0026#34;: \u0026#34;kubectl\u0026#34;, \u0026#34;rxTimestamp\u0026#34;: 0, \u0026#34;serverIpv4\u0026#34;: 174063617, \u0026#34;serverIpv4Dot\u0026#34;: \u0026#34;10.96.0.1\u0026#34;, \u0026#34;serverPort\u0026#34;: 443, \u0026#34;timestamp\u0026#34;: 1606322948648718268, \u0026#34;timestampRFC3339Nano\u0026#34;: \u0026#34;2020-11-25T16:49:08.648718268Z\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;connection\u0026#34; \u0026#34;tty\u0026#34;: 34816, \u0026#34;labels\u0026#34;: { \u0026#34;aws.accountId\u0026#34;: \u0026#34;059797578166\u0026#34;, \u0026#34;aws.instanceId\u0026#34;: \u0026#34;i-053b1f0509fdbc15a\u0026#34;, \u0026#34;aws.region\u0026#34;: \u0026#34;us-east-1\u0026#34;, \u0026#34;container.image.digest\u0026#34;: \u0026#34;sha256:26c68657ccce2cb0a31b330cb0be2b5e108d467f641c62e13ab40cbec258c68d\u0026#34;, \u0026#34;container.image.id\u0026#34;: \u0026#34;d2e4e1f51132\u0026#34;, \u0026#34;host.hostName\u0026#34;: \u0026#34;ip-172-20-46-221\u0026#34;, \u0026#34;host.mac\u0026#34;: \u0026#34;12:9f:a1:c9:76:87\u0026#34;, \u0026#34;kubernetes.cluster.name\u0026#34;: \u0026#34;k8s-onprem\u0026#34;, \u0026#34;kubernetes.namespace.name\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;kubernetes.node.name\u0026#34;: \u0026#34;ip-172-20-46-221.ec2.internal\u0026#34;, \u0026#34;kubernetes.pod.name\u0026#34;: \u0026#34;bash\u0026#34; } } File (file) Payload{ \u0026#34;id\u0026#34;: \u0026#34;164806c161a5dd221c4ee79d6b5dd1ce\u0026#34;, \u0026#34;agentId\u0026#34;: 32212, \u0026#34;containerId\u0026#34;: \u0026#34;a407fb17332b\u0026#34;, \u0026#34;directory\u0026#34;: \u0026#34;/var/lib/dpkg/updates/\u0026#34;, \u0026#34;filename\u0026#34;: \u0026#34;tmp.i\u0026#34;, \u0026#34;hostname\u0026#34;: \u0026#34;qa-k8smetrics\u0026#34;, \u0026#34;permissions\u0026#34;: \u0026#34;w\u0026#34;, \u0026#34;pid\u0026#34;: 414661, \u0026#34;comm\u0026#34;: \u0026#34;dpkg\u0026#34;, \u0026#34;timestamp\u0026#34;: 1606322948648718268, \u0026#34;timestampRFC3339Nano\u0026#34;: \u0026#34;2020-11-25T16:49:08.648718268Z\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;fileaccess\u0026#34;, \u0026#34;labels\u0026#34;: { \u0026#34;aws.accountId\u0026#34;: \u0026#34;059797578166\u0026#34;, \u0026#34;aws.instanceId\u0026#34;: \u0026#34;i-053b1f0509fdbc15a\u0026#34;, \u0026#34;aws.region\u0026#34;: \u0026#34;us-east-1\u0026#34;, \u0026#34;container.image.digest\u0026#34;: \u0026#34;sha256:26c68657ccce2cb0a31b330cb0be2b5e108d467f641c62e13ab40cbec258c68d\u0026#34;, \u0026#34;container.image.id\u0026#34;: \u0026#34;d2e4e1f51132\u0026#34;, \u0026#34;container.image.repo\u0026#34;: \u0026#34;docker.io/library/ubuntu\u0026#34;, \u0026#34;container.name\u0026#34;: \u0026#34;bash\u0026#34;, \u0026#34;host.hostName\u0026#34;: \u0026#34;ip-172-20-46-221\u0026#34;, \u0026#34;host.mac\u0026#34;: \u0026#34;12:9f:a1:c9:76:87\u0026#34;, \u0026#34;kubernetes.cluster.name\u0026#34;: \u0026#34;k8s-onprem\u0026#34;, \u0026#34;kubernetes.namespace.name\u0026#34;: \u0026#34;default\u0026#34;, \u0026#34;kubernetes.node.name\u0026#34;: \u0026#34;ip-172-20-46-221.ec2.internal\u0026#34;, \u0026#34;kubernetes.pod.name\u0026#34;: \u0026#34;bash\u0026#34; } } Kubernetes (kube exec) Payload{ \u0026#34;id\u0026#34;: \u0026#34;164806f4c47ad9101117d87f8b574ecf\u0026#34;, \u0026#34;agentId\u0026#34;: 32212, \u0026#34;args\u0026#34;: { \u0026#34;command\u0026#34;: \u0026#34;bash\u0026#34;, \u0026#34;container\u0026#34;: \u0026#34;nginx\u0026#34; }, \u0026#34;auditId\u0026#34;: \u0026#34;c474d1de-c764-445a-8142-a0142505868e\u0026#34;, \u0026#34;containerId\u0026#34;: \u0026#34;397be1762fba\u0026#34;, \u0026#34;hostname\u0026#34;: \u0026#34;qa-k8smetrics\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;nginx-76f9cf7469-k5kf7\u0026#34;, \u0026#34;namespace\u0026#34;: \u0026#34;nginx\u0026#34;, \u0026#34;resource\u0026#34;: \u0026#34;pods\u0026#34;, \u0026#34;sourceAddresses\u0026#34;: [ \u0026#34;172.17.0.21\u0026#34; ], \u0026#34;stages\u0026#34;: { \u0026#34;started\u0026#34;: 1605540915526159000, \u0026#34;completed\u0026#34;: 1605540915660084000 }, \u0026#34;subResource\u0026#34;: \u0026#34;exec\u0026#34;, \u0026#34;timestamp\u0026#34;: 1606322948648718268, \u0026#34;timestampRFC3339Nano\u0026#34;: \u0026#34;2020-11-25T16:49:08.648718268Z\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;kubernetes\u0026#34;, \u0026#34;user\u0026#34;: { \u0026#34;username\u0026#34;: \u0026#34;system:serviceaccount:default:default-kubectl-trigger\u0026#34;, \u0026#34;groups\u0026#34;: [ \u0026#34;system:serviceaccounts\u0026#34;, \u0026#34;system:serviceaccounts:default\u0026#34;, \u0026#34;system:authenticated\u0026#34; ] }, \u0026#34;userAgent\u0026#34;: \u0026#34;kubectl/v1.16.2 (linux/amd64) kubernetes/c97fe50\u0026#34;, \u0026#34;labels\u0026#34;: { \u0026#34;agent.tag.cluster\u0026#34;: \u0026#34;k8s-onprem\u0026#34;, \u0026#34;agent.tag.sysdig_secure.enabled\u0026#34;: \u0026#34;true\u0026#34;, \u0026#34;container.image.repo\u0026#34;: \u0026#34;docker.io/library/nginx\u0026#34;, \u0026#34;container.image.tag\u0026#34;: \u0026#34;1.21.6\u0026#34;, \u0026#34;container.label.io.kubernetes.container.name\u0026#34;: \u0026#34;nginx\u0026#34;, \u0026#34;container.label.io.kubernetes.pod.name\u0026#34;: \u0026#34;nginx-76f9cf7469-k5kf7\u0026#34;, \u0026#34;container.label.io.kubernetes.pod.namespace\u0026#34;: \u0026#34;nginx\u0026#34;, \u0026#34;container.name\u0026#34;: \u0026#34;nginx\u0026#34;, \u0026#34;host.hostName\u0026#34;: \u0026#34;qa-k8smetrics\u0026#34;, \u0026#34;host.mac\u0026#34;: \u0026#34;12:09:c7:7d:8b:25\u0026#34;, \u0026#34;kubernetes.cluster.name\u0026#34;: \u0026#34;demo-env-prom\u0026#34;, \u0026#34;kubernetes.deployment.name\u0026#34;: \u0026#34;nginx-deployment\u0026#34;, \u0026#34;kubernetes.namespace.name\u0026#34;: \u0026#34;nginx\u0026#34;, \u0026#34;kubernetes.pod.name\u0026#34;: \u0026#34;nginx-76f9cf7469-k5kf7\u0026#34;, \u0026#34;kubernetes.replicaSet.name\u0026#34;: \u0026#34;nginx-deployment-5677bff5b7\u0026#34; } } Sysdig Platform Audit Payload{ \u0026#34;id\u0026#34;: \u0026#34;16f43920a0d70f005f136173fcec3375\u0026#34;, \u0026#34;type\u0026#34;: \u0026#34;audittrail\u0026#34;, \u0026#34;timestamp\u0026#34;: 1606322948648718268, \u0026#34;timestampRFC3339Nano\u0026#34;: \u0026#34;2020-11-25T16:49:08.648718268Z\u0026#34;, \u0026#34;originator\u0026#34;: \u0026#34;ingestion\u0026#34;, \u0026#34;category\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;source\u0026#34;: \u0026#34;auditTrail\u0026#34;, \u0026#34;name\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;severity\u0026#34;: 0, \u0026#34;agentId\u0026#34;: 0, \u0026#34;containerId\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;machineId\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;content\u0026#34;: { \u0026#34;timestampNs\u0026#34;: 1654009775452000000, \u0026#34;customerId\u0026#34;: 1, \u0026#34;userId\u0026#34;: 454926, \u0026#34;teamId\u0026#34;: 46902, \u0026#34;requestMethod\u0026#34;: \u0026#34;GET\u0026#34;, \u0026#34;requestUri\u0026#34;: \u0026#34;/api/integrations/discovery/\u0026#34;, \u0026#34;userOriginIP\u0026#34;: \u0026#34;187.188.243.122\u0026#34;, \u0026#34;queryString\u0026#34;: \u0026#34;cluster=demo-env-prom\u0026amp;namespace=sysdig-agent\u0026#34;, \u0026#34;responseStatusCode\u0026#34;: 200, \u0026#34;entityType\u0026#34;: \u0026#34;integration\u0026#34;, \u0026#34;entityPayload\u0026#34;: \u0026#34;\u0026#34; }, \u0026#34;labels\u0026#34;: { \u0026#34;entityType\u0026#34;: \u0026#34;integration\u0026#34; } } ","url":"https://docs.sysdig.com/en/sysdig-secure/siem-data-platforms/"},{"id":150,"title":"Text","content":"The example below uses a text panel as a reminder list of the testing steps for a procedure.\nCreate a Text PanelTo create a Text panel in a dashboard:\nCreate a New Panel, whether from an existing dashboard, Dashboard Manager, or elsewhere.\nSelect the visualization icon, which is set to Timechart by default, and choose Text.\nEnter a title. This is hidden by default, but toggle on Show panel title to display it from the dashboard.\nEnter a description. This will be visible from the dashboard.\nToggle Transparent background and Auto-size text as desired.\nClick Save.\nText Panel MarkdownYou can format your text panels with Markdown syntax.\nLinksTo link to other dashboards, use a section of the dashboard url in the following format:\n[Pod Rightsizing \u0026amp; Capacity Optimization](#/dashboard-template/view.kubernetes.cluster.rightsizing) To find the correct link, navigate to the dashboard in the Monitor UI, and copy the first section of the url after .com/. There is no need to include any additional part of the url, such as the scope.\nThe url of templates in the Dashboard Library begin with #/dashboard-template/. User-created dashboards follow the format #/1234567. Private dashboards, or those not shared with all teams, may not be accessible to those without access, even if they have the link.\nHeaders# H1 ## H2 ### H3 #### H4 ##### H5 ###### H6 H1 ====== H2 ------ Emphasis*italics* or _italics_ **bold** or __bold__ **combined _emphasis_** ~~strikethrough~~ ListsGeneral guidelines for entering list information:\nList items can contain properly indented paragraphs, using white space.\nUnordered lists can use: *, -, or +.\nThe formatting defines the lists. You can type incorrect numbering and it will render correctly.\nLinebreaksThis is the first sentence. This line is separated from the one above by two newlines, so it will be a *separate paragraph*. This line is also a separate paragraph. This line is only separated by a single new line, so it\u0026#39;s a separate line in the *same paragraph*. Trailing spaces can be used for line breaks without creating a new paragraph. This behavior is contrary to the typical GFM line-break behavior, where trailing spaces are not required.\nLearn MoreFor more information on Markdown syntax, see Markdown Guide.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/text/"},{"id":151,"title":"Vulnerability Management","content":"OverviewSysdig Secure\u0026rsquo;s Vulnerability Management module provides:\nAccurate Vulnerability Risk Assessment at Scale: Provides precise insights into vulnerabilities within container images and running containers, including CVSS vector, score, fix age, and expert insights from sources such as VulnDB. Access to Public Exploits: Lets you identify known exploits to validate security controls and patch efficiently. Prioritized Risk Data: Focuses on the vulnerabilities tied to the packages loaded at runtime, ensuring the most critical threats are addressed first. Risk Acceptance: Ensures your feed is focused on what matters most and free from noise, by allowing you to accept risk when the vulnerability matching does not apply for your particular deployment, or you want to postpone remediation. The Vulnerability Management engine supports:\nCI/CD pipeline Scanning Registry Scanning Runtime Image Scanning Policies Notifications Reporting for runtime This module replaces the legacy Scanning module from earlier versions of Sysdig Secure.\nUnderstand Vulnerability Management StagesTo create an effective vulnerability management plan, it\u0026rsquo;s important to recognize the various stages of the lifecycle that need to be addressed.\nKey Concepts During the build phase, software vulnerabilities may be introduced when container images are defined and assembled. Container images are, by definition, immutable. Altering the contents of an image will update the ImageID and, thus, will be considered a different image by Sysdig Secure.\nEven though unique container images (ImageIDs) cannot be modified, Sysdig can identify new vulnerabilities in running containers (for example, in Kubernetes workloads) as security feeds are continuously updated. For instance, a container image with no known vulnerabilities during its build phase might be affected by a critical vulnerability discovered ten days after being deployed into the runtime. The image remains unchanged, but new security information related to the software it contains has been found.\nSysdig uses the same fundamental concepts to analyze the contents of an image (SBOM) and match vulnerabilities but treats images differently based on their location. Sysdig can analyze the vulnerabilities of images in a development pipeline, stored in a container image registry, or used as the template for a running container, known as runtime workloads.\nStages: Pipeline - Registry - RuntimePipelineAny analysis conducted before the registry phase is considered a pipeline. A clear example is CI/CD builds (Jenkins, GitHub, etc.), but also the execution of the sysdig-cli-scanner binary performed on a developer laptop or using a custom scanning script.\nPipeline images do not have runtime context. The scan happens outside of the execution nodes where the agent is installed: CI/CD External instrumentation Custom scripts or image scanning plugins Pipeline scans are one-off vulnerability reports; the information is a static snapshot with its corresponding execution date. If you want to evaluate a newer version of the image or reevaluate the same image with newer feed information, the analysis needs to be triggered again. Images analyzed using the sysdig-cli-scanner will show up in the Pipeline section of the vulnerability management interface. RegistryContainer Registry scanning allows you to integrate Sysdig with image registries from a range of vendors. Registry scanning provides an extra layer of defense between pipeline and runtime, where:\nSoftware that sits in the registry before being deployed is checked for newly discovered vulnerabilities Third-party software that may have been installed without going through pipeline scanning will be checked Registry scans occur as scheduled through a cron job in the installation Helm chart once per week (Saturdays at 6:00 AM) by default.\nBatch scanning is done asynchronously and separately from the development pipeline; regardless of the time it takes to scan the batch, the pipeline is unaffected. See Install Registry scanner(s).\nRuntimeRuntime workloads are executed using a container image. Accessing the Runtime section of the Vulnerabilities menu, you will be able to see those images and their vulnerability and policy evaluation.\nRuntime workloads are located in an execution node and are being monitored by a Sysdig agent/node analyzer, for example a Kubernetes node that is instrumented using the Sysdig agent bundle. Runtime workloads will offer a live, auto-refreshing state. This means: Workloads that are no longer running will be removed from the runtime view Vulnerabilities and policies evaluations will automatically refresh without any user interaction, offering always the most up-to-date information known. At least once per day Runtime workload have a runtime context associated with them, i.e. Kubernetes cluster and namespace. Workloads analyzed during runtime will show up in the Runtime section of the vulnerability management interface. See Runtime.\nAsset Types: Workload, Host, and ContainerThe way things are scanned and how results are filtered relies on how Sysdig defines and uses the concepts of \u0026ldquo;image,\u0026rdquo; \u0026ldquo;workload,\u0026rdquo; \u0026ldquo;host,\u0026rdquo; and \u0026ldquo;container.\u0026rdquo;\nImageImage is not officially an asset type, but is the primary unit underlying all types of scanning.\nIn Pipeline and Registry scanning, Sysdig scans images used in container-based environments.\nIn Runtime, images have the context of either Kubernetes or the container host environment.\nThese images are strictly evaluated based on the image definition without reference to the deployed context (neither runtime nor orchestrator).\nAll images are extracted into a Software Bill of Materials (SBOM) format that is compatible with the CycloneDX standard. See CycloneDX for details.\nWorkloadWhen scanning images that are deployed in Kubernetes environments, the scanner evaluates the image in the context of the container running in a Kubernetes workload. This context makes it contextually different from images and containers.\nHostA host is a full-stack Operating System (OS) running on virtual infrastructure such as Cloud IaaS or Virtual Machines. The host will also have an SBOM, without the layers that are seen in images. All the context data for a host is relative to a full-stack OS with network connectivity (OS, Host Name, IPs, etc.).\nContainerWhen Sysdig scans a container (either agentlessly or with the agent) it extracts a container from a Host image via the filesystem. In container scans, only the parent host context is available, not the runtime and orchestration context.\nTo be scanned by Sysdig, containers must all be compliant with the Open Container Initiative (OCI). See OCI for details.\nUsageWhen defining a Vulnerability policy or filtering Runtime vulnerability results, you can define the asset type to use.\n","url":"https://docs.sysdig.com/en/sysdig-secure/vulnerability-management/"},{"id":152,"title":"Agent Release Notes 2019","content":"0.94.0 December 20, 2019Fixes and UpgradesFixed issue in the agent install scripts\nThe agent install scripts have been updated to mount /etc/modprobe.d from the host into the agent container. This prevents a problem where the agent loaded drivers that were excluded from the host.\nAdded user events for additional resource types\nAdded events monitoring for statefulsets, services, and horizontal pod auto-scalers (HPAs) when the Golang-based events monitoring feature is enabled. To enable, see Process Kubernetes Events.\nAdded regex support for Kafka integrations\nAdded regex capability for consumer groups and topics in Apache Kafka configurations. See Example 6 in Apache Kafka.\nIncreased the Prometheus max_tags default value\nThe Prometheus max_tags configuration has been increased from 20 to 40.\nMade change to guarantee support for older cpuset configurations.\nChanged CRIO cpuset calculations to use the configured cpuset.cpus value instead of cpuset.effective_cpus. This guarantees support on older cpuset configurations.\nCorrected an issue that resulted in the suffix \u0026ldquo;_total\u0026rdquo; to be stripped to Prometheus counter metric names.\n0.93.1 November 25, 2019Fixes and UpdatesFixed installation issue on native RHEL 7.x installs\nThe agent installer script has been updated to refer to an updated epel repository.\nImproved JMX metrics reporting\nFixed an issue when retrieving JMX metrics which could result in missing samples.\n(Sysdig Secure): Improvement in Kubernetes Audit events\nFixed runtime policy scopes for Kubernetes audit events.\n(Sysdig Secure) Fixed audit event exception\nThe system now catches JSON object-type exceptions when parsing Kubernetes audit events.\nImproved error message\nImproved the error message reported when the Sysdig agent cannot find a pre-installed kernel header or cannot download a sysdigcloud-probe.\nPerformance improvement in dragent logging\n0.93.0.1 November 15, 2019FixesFixed issue with Prometheus metrics names\nCorrected a problem that resulted in the suffix _total to be removed from Prometheus counter metric names.\n0.93.0 November 6, 2019New FeaturesMask the customer ID in log files\nThe Customer ID is no longer output in the agent log, to avoid inadvertent exposure when sharing of log files.\nKubernetes role node label included by default\nThe kubernetes.node.label.kubernetes.io/role label is available by default\nUpdate Kubernetes API used, in order to expand support of Kubernetes v1.16\nReplaced usage of the extensions/v1beta1 Kubernetes API with apps/v1 in the agent. This is required for supporting Kubernetes v1.16 using the agent\u0026rsquo;s legacy Kubernetes integration (when new_k8s is not enabled).\nIntroduced a new config option in ElasticSearch app check\nIntroduced a new config option to generate cluster-wide primary shard metrics from a master node: pshard_stats_master_node_only. See Elasticsearch (Example 3).\nEnhanced Postgresql app check\nThe Postgres app check has been enhanced to provide new metrics and examples. See PostgreSQL.\nAgent preparation for upcoming Policy Advisor feature in Sysdig Secure\nThe agent will support new Rules generated by Sysdig\u0026rsquo;s Kubernetes Policy Advisor. This agent is the minimum version required to use the upcoming feature.\nUpdates and FixesImproved system events handling for Ubuntu 19.10\nOn kernels 5.1 and newer, some syscall events were incorrectly dropped. This has been fixed.\nStopped Kubernetes pause containers (pods) from being reported\nFixed an issue where Kubernetes pause containers were also showing up in Kubentes events. This fix filters them out from the events being reported.\nFixed rare issue on OpenShift\nFixed an issue where, in a rare case, a dropped event could cause a kernel deadlock and crash the node.\nFixed issue preventing kernel module creation for Debian Buster\nThis change adds support for building the Sysdig Monitor agent kernel module for Debian Buster.\nImproved event timestamp in Kubernetes\nThis fix ensures that user events get the correct timestamp with Kubernetes v1.16 when thego_k8s_user_events option is set to true.\nUpdated Kubernetes API used, in order to expand support of Kubernetes v1.16\nIn dragent.yaml, the Kubernetes API extensions/v1beta1 is updated to apps/v1. This enables agent support for Kubernetes v1.16 even when the new_k8s option is set to false.\nFixed a Kubernetes event reporting issue\nFixed an issue with Kubernetes Events where the host MAC scope was not populated correctly, resulting in not showing up on the dashboard.\nImproved Kubernetes events handling from delegated agents\nWhen using go_k8s_user_events, kubernetes events from non-delegated agents are no longer sent.\nEliminated legacy \u0026ldquo;BASELINES\u0026rdquo; message\nStopped processing legacy BASELINES messages from the backend collector.\nPerformance improvement at startup\nThe agent now defers initialization of Secure-related components slightly to reduce excess resource usage at startup.\n0.92.3 October 7, 2019Updates and Fixed IssuesIncluded Example of a Prometheus Matching Rule Using HTTPS\nThe Sysdig agent will use HTTPS for scraping when target\u0026rsquo;s annotation has \u0026ldquo;kuberentes.pod.annotation.prometheus.io/scheme: https\u0026rdquo;.\nKubernetes versions older than 1.9 no longer supported.\nThe Sysdig agent has replaced the use of the extensions/v1beta1 Kubernetes API with apps/v1.\nIncluded Example of a Prometheus Matching Rule Using HTTPS\nThe Sysdig agent will use HTTPS for scraping when target\u0026rsquo;s annotation has \u0026ldquo;kuberentes.pod.annotation.prometheus.io/scheme: https\u0026rdquo;.\nThe RabbitMQ app check has a new config option: filter_by_node\nWithout this option, each node reports cluster-wide information (as presented by rabbitmq itself). This option makes it easier to view the metrics in the UI by removing redundant information reported by individual nodes. See RabbitMQ for details.\n0.92.2 September 26, 2019New FeaturesAsynchronous metadata collection for CRI-O and containerd\nThe collection of container metadata from CRI-based runtimes was previously synchronous with other agent tasks.\n**Prioritize and filter how process metrics are reported in Sysdig Monitor. **\nIn addition to filtering data by container, it is also possible to filter independently by process. Broadly speaking, this refinement helps ensure that relevant data is reported while noise is reduced. See Include/Exclude Processes for details.\nAs of this version, App Checks on hosts with Python 2.6 will no longer be supported.\nFixed Issues **Fix for Agent termination during resource discovery from the Kubernetes API Server **\nFixed an issue where the Agent stopped and shut down if there an error occurred during resource discovery from the Kubernetes API Server. This fix simply reports the error and continues with the discovered resources.\nFix for Kubernetes delegation error\nFixed an issue that caused Kubernetes delegation to not work after the cointerface process restarts following a crash.\nFix for accounting Network errors\nNetwork-related errors are now correctly accounted for instead of being treated as file-open errors.\nNew Prometheus Client Version\nUpdated prometheus_client to version 0.7.1. This should result in improved performance while ingesting Prometheus metrics.\nFix for dropping StatsD Metrics\nA defect in earlier versions of Sysdig Monitor with the statsd.use_forwarderoption could drop some StatsD metrics from containers. This change resolves that problem; the agent will begin fetching metrics from containers 10 seconds after first identifying that the container exists. The 10 second delay allows containers to start StatsD servers within their network namespaces if they choose.\nThe timeout can be overridden using the statsd.container_server_creation_delay_s option, which specifies the delay in seconds.\nFixed resource metrics for CRI-O containers\nThe following metrics reporting correctly in the Monitor UI: memory.limit.bytes, memory.limit.used.percent, and cpu.quota.used.percent. The CRI extra_queries option now enabled by default. See Runtime Support: CRI-O and Containerd for details.\nSysdig Secure **Fix for enlarging Sysdig Capture **\nFixed an issue where a Sysdig capture would grow endlessly if a security policy was set to Capture 0 seconds after an event.\nFix for processing system events\nFixed problem where gettimeofday syscall was called in compliance code while processing system events. This could potentially cause performance problems in Linux distros that called down to the kernel for gettimeofday responses, such as some versions of Amazon Linux.\nSysdig Platform New RPM dependency\nChanged RPM dependency to Python 2 to support installation on RHEL 8.\n0.92.1 August 16, 2019Fixed IssuesSysdig Monitor Fixed issue with cluster name in Monitor UI\nCluster name was being populated incorrectly for Kubernetes event scopes.\nFixed Kubernetes events issue\nFixed Kubernetes event collection issue that occurred when using the go_k8s_user_events option. This option was introduced in agent version 0.91.\nSysdig Platform RHEL 7.7 and 8.0+ support The kernel module now builds for RHEL 7.7 and 8.0+\nFixed issue with StatsD metrics collection limits Some versions of the Sysdig agent allowed fewer than the configured number of StatsD metrics because Sysdig Secure-related StatsD metrics were counted towards the configured limit.\nThis change corrects that behavior so that the configured limit applies only to StatsD metrics that do not originate from Sysdig components.\nSysdig Secure Fixed a profiling-related issue that impacts Sysdig Secure 2.4\nSysdig Secure 2.4 will include a new Profiling feature, and 0.92.1 fixes a bug where profiling could remain disabled after periods of high load. In order to use Profiling, it is required to upgrade to agent 0.92.1 or higher.\n0.92 August 7, 2019New FeaturesPreparatory enhancements for upcoming Sysdig Secure Policy Editor Although the feature UI will not be released until version 2.4.0, Sysdig encourages all users of Sysdig Secure to upgrade to agent 0.92 in preparation for the new Policy Editor feature. Agent 0.92 will accept policies messages from both the current backend as well as a backend that supports the new policy editor.\nAbility to compress metrics data for internal transfer\nWith app checks integrations, when the volume of metrics data collected was too large to send over the agent\u0026rsquo;s internal queue, app checks could fail. This problem is solved by introducing an option to compress app checks metrics data, which reduces the internal load. See Compress Metrics Data for details on how to enable this option.\nFixed IssuesSysdig MonitorFix for occasionally dropped metrics In earlier releases of Sysdig Monitor, the agent sometimes failed to parse metrics containing negative values for some fields.\nThis change updates the behavior to drop fields that have unsupported negative values, and to generate a log message when such fields are encountered.\nSysdig Platform Fix for MySQL versions 8.0.14+\nFixed a bug that caused the MySQL app check to fail with an error.\nFixed agent crash issue exposed by recent Linux kernels\nAffected kernels include the 5.2.x line, 5.1.8+, and 4.19.49+.\nFixed a bug in HTTP parserIn the (uncommon) situation where absoluteURI is used in the Request-URI, fixed a bug that was causing a faulty URL.\n0.91 July 17, 2019New FeaturesImproved securityRemoved obsolete and vulnerable Python 2.6-compatible libraries from Docker images.\nMore efficient Kubernetes event handling.\nThe agent has added functionality to allow more efficient processing of Kubernetes user events.\nSee Process Kubernetes Events to enable.\nReduced CPU usage on Kubernetes clusters Extended performance optimizations for processing Kubernetes Services, which will reduce agent CPU usage in large clusters.\nContainer filtering enhanced. Smart filters and aggregated filtering options are now available. See Prioritize/Include/Exclude Designated Containers.\nFixed IssuesMonitor Fixed issue with Prometheus metrics gathering intervals\nThe agent will now respect the configured interval for scraping Prometheus metrics from remote endpoints, as opposed to doing it every second.\nFixed limit/requests calculations for init containers\nFixed memory calculations for Kubernetes init container limits and requests\nImproved Healthcheck monitoringAgent has improved ability to detect commands identified as a part of Kubernetes Liveness/Readiness Probes, in addition to Docker Health Checks.\nImproved error messaging\nWarning messages for container group inconsistencies were demoted to debug level, as they are harmless and do not need to clutter the error reporting stream.\nFixed issue with container \u0026ldquo;incomplete\u0026rdquo; reporting status\nStarting with version 0.90.0, the agent would report containers for which it had not yet fetched metadata as \u0026ldquo;incomplete.\u0026rdquo; This would then propagate to the Monitor UI. This restores the behavior where the agent leaves the unknown fields unset.\nResolved REST server issue\nFixed problem where an enabled port would respond to HTTP requests when not desired.\nFixed issue with StatsD metrics collection\nPrevious versions of the Sysdig agent, when configured to use the StatsD fowarder ({{statsd.use_forwarder: true}}) truncated messages that it received from containers to 2048 bytes, resulting in the potential for dropped and corrupted metrics. This change resolves that problem. See details under StatsD Integration.\nIt is recommended to follow upgrade best practices:\nKeep upgrades current\nTest upgrades in a non-mission-critical or staging environment before rolling into production.\n","url":"https://docs.sysdig.com/en/release-notes/linux-agent-release-notes/2019-archive/"},{"id":153,"title":"Advanced Network Exposure","content":"Supported Cloud ProvidersAdvanced Network Exposure provides comprehensive coverage across major cloud platforms:\nAWS Azure GCP IBM Cloud Exposure ValidationAdvanced Network Exposure performs a configuration evaluation of your cloud resources. This evaluation assesses the resources and their configurations, which can expose them to the internet. After finding an exposure path that exposes a resource, a port scan is triggered to determine whether the endpoint is truly exposed.\nConfiguration-Based Analysis: Evaluates the complete network path by analyzing resource configurations, security groups, network ACLs, routing tables, internet gateways, load balancers and other network components to determine theoretical accessibility from the internet.\nPort Scanning Validation: Performs network port scans to verify internet-exposed resources, validating the configuration analysis with real-world reachability tests. This ensures findings represent genuine exposure, not just permissive configurations that may be blocked by other network controls.\nService Fingerprinting: When scanned ports are discovered to be open, Advanced Network Exposure performs service fingerprinting to detect and identify the services running on those ports. This includes analyzing response headers, banners and service-specific protocol responses to determine the type of service (e.g., HTTP, HTTPS, SSH, databases), version information and other parts of your technology stack. This additional context helps assess the security implications of the exposed service.\nNote: Port scanning validation and service fingerprinting require additional setup steps and must be explicitly enabled. Please contact Sysdig Support to activate these features. For detailed information about the prerequisites and activation process, see Enable Advanced Network Exposure.\nViewing Exposure Information in InventoryAdvanced Network Exposure provides intuitive visualization of exposure information directly within the Sysdig Secure Inventory, making it easy to identify exposed resources and understand their exposure paths.\nExposure Status IconsWhen viewing resources in your Inventory, resources that can be analyzed for network exposure display an exposure status indicator on the right side of the resource listing:\nNot Exposed: Indicates that the resource is not accessible from the internet based on current network configurations and analyzed port scanning Exposed: Indicates that the resource has been identified as exposed to the internet through one or more network paths (Not validated with port scanning) Publicly Exposed: Indicates that the resource has been identified as exposed to the internet through one or more network paths (Validated with port scanning) This visual indicator allows you to quickly identify which resources in your inventory are exposed without having to drill into each resource.\nAccessing the Exposure SectionTo view detailed exposure information for a specific resource:\nNavigate to Inventory in Sysdig Secure Select the resource you want to investigate In the resource detail panel, click on the Exposure section in the left sidebar The Exposure section provides comprehensive information about the resource\u0026rsquo;s exposure status, including:\nExposure Path Visualization: An interactive network diagram showing paths from the internet to your resource. Exposure Findings: List of specific paths through which the resource is exposed. Contributing Resources: Resources involved in the exposure path and the path to which they belong. Exposure FindingsThe Exposure Findings tab in the UI provides detailed information about why a resource is exposed and all the network components involved in the exposure paths.\nExposed PathsThis section displays all the paths that make the resource exposed to the internet. Each path shows the complete sequence of network components from the internet to your resource. Multiple paths may exist for a single resource, and all are listed to give you complete visibility into how the resource can be reached from the internet.\nAll Affected ResourcesThe \u0026ldquo;All Affected Resources\u0026rdquo; section provides details about every network component involved in the exposure paths. For each resource, you can view:\nPlatform: The cloud provider (AWS, Azure, GCP, IBM Cloud) Resource Name: The resource\u0026rsquo;s identifier Category: The type of network component (Networking, Compute, etc.) Organization: The organization to which the resource belongs Account: The specific cloud account containing the resource Resource Type: The technical type of the resource Region: The geographical region where the resource is deployed Last Seen: When the resource was last scanned and analyzed Zones: The availability zones where the resource is located This information helps you understand the complete context of your exposure and identify which accounts, regions and network components need attention.\nValidated Exposure InformationWhen validated network exposure is activated, and a resource has been validated through port scanning and service fingerprinting, additional detailed information is included in the findings JSON data. This validated data provides concrete evidence of exposure and helps you understand exposed resources, exactly which services are accessible and what information they reveal about your infrastructure.\nExample Validated Exposure JSONBelow is an example of the JSON data generated when validated network exposure detects and fingerprints an open port:\n[ { \u0026#34;scanDate\u0026#34;: \u0026#34;2026-01-21T02:00:12.560Z\u0026#34;, \u0026#34;protocol\u0026#34;: \u0026#34;TCP\u0026#34;, \u0026#34;ip\u0026#34;: \u0026#34;\u0026lt;ip\u0026gt;\u0026#34;, \u0026#34;port\u0026#34;: 22, \u0026#34;domain\u0026#34;: null, \u0026#34;authenticationStatus\u0026#34;: 0, \u0026#34;authenticationConfidence\u0026#34;: 2, \u0026#34;probeCommand\u0026#34;: \u0026#34;\u0026lt;command to reach endpoints\u0026gt;\u0026#34;, \u0026#34;applicationName\u0026#34;: \u0026#34;OpenSSH\u0026#34;, \u0026#34;applicationVersion\u0026#34;: \u0026#34;8.9p1\u0026#34;, \u0026#34;applicationConfidence\u0026#34;: 2 } ] Understanding the Validated Exposure Data:\nscanDate: Timestamp indicating when the port scan and service fingerprinting were performed.\nprotocol: Network protocol used for the scan (e.g., TCP, UDP), showing how the service communicates.\nip: The public IP address that was scanned and found to have an open port, confirming the resource is reachable from the internet.\nport: The specific port number discovered to be open and accessible.\ndomain: Domain name associated with the IP address, if applicable. Null indicates no domain mapping was found.\nauthenticationStatus:\n0: authenticated\n1: unauthenticated\n2: unknown\nauthenticationConfidence:\n0: low\n1: mid\n2: high\nprobeCommand: The command used by the scanning infrastructure to probe and fingerprint the service. This shows the technical details of how the service was identified.\napplicationName: The identified application or service running on the open port (e.g., \u0026ldquo;OpenSSH\u0026rdquo;, \u0026ldquo;nginx\u0026rdquo;, \u0026ldquo;Apache\u0026rdquo;, \u0026ldquo;MySQL\u0026rdquo;). This tells you which application is exposed.\napplicationVersion: The specific version of the detected application.\napplicationConfidence:\n0: low\n1: mid\n2: high\nQuerying Exposure Results with Inventory SearchBeyond viewing exposure information for individual resources, you can use Inventory Search to query and analyze exposure validation results across your entire infrastructure. This search capability allows you to identify all publicly exposed endpoints and examine their port-scanning and service-fingerprinting data in a centralized view.\nAccessing Inventory SearchTo access the Inventory Search feature:\nNavigate to Inventory in Sysdig Secure Click on the Search option in the top menu Searching for Publicly Exposed ResourcesInventory Search uses SYSQL (Sysdig Query Language) to query and retrieve information about exposed resources. SYSQL is a graph-based query language that allows you to explore relationships between resources in your infrastructure.\nFor more information about SYSQL syntax and capabilities, see the SysQL Reference Library.\nUse the following query to retrieve all public endpoints validated through port-scanning and service-fingerprinting:\nMatch Host PUBLICLY_EXPOSED_BY PublicEndpoint as pe Return pe; This query uses the graph relationship PUBLICLY_EXPOSED_BY to find all resources that have validated exposure through port scanning. The results will show detailed information about each exposed endpoint.\nUnderstanding Search ResultsThe search results table displays comprehensive information about each publicly exposed endpoint, including:\nScan Date: When the port scan and service fingerprinting were last performed Protocol: The network protocol (TCP, UDP) used for the connection IP Address: The public IP address that was scanned and confirmed to be accessible Port: The specific port number found to be open Application Name: The identified service or application running on the port (e.g., OpenSSH, nginx, Apache) Application Version: The specific version of the detected service Authentication Status: Information about whether the endpoint had authentication enabled Confidence Levels: Metrics indicating the reliability of the service identification ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/advanced-network-exposure/"},{"id":154,"title":"AppSec Integrations","content":"Integrate with External PlatformsThere are two integration models: in-cluster (for Snyk) and API-based (all others). The installation instructions for each are different.\nFor Snyk: See the Snyk integration page.\nFor all others: Use the following steps:\nGenerate a Token for the Integration From the left navigation bar, select Integrations \u0026gt; Third Party | Risk Spotlight Integration.\nThe Spotlight Integration page appears, with a list of existing tokens and their expiry dates.\nClick +Add Token.\nFill in the attributes and click Create Token.\nName: Choose a name that indicates the integration with which the token is associated. Expiration: Select an expiration date (1/3/6 months; 1 year). Copy the new token as it is displayed in the list.\nStore the token in a safe place; it will not be visible or recoverable again.\nTo Renew a token at any time, click the Renew button, reset the expiry, and confirm.\nTo Delete a token, click the X beside the token name and confirm. This action will sever the integration between Sysdig and the 3rd-party tool.\nFollow the Platform-Specific Integration StepsCurrent integrations include:\nDocker Scout\nCheck the prerequisites. Follow the third-party integration guide provided, adding the Sysdig token as prompted. Verify the integration in the third-party UI. ","url":"https://docs.sysdig.com/en/sysdig-secure/appsec-integrations/"},{"id":155,"title":"Authenticate Azure for Cluster Shield","content":"Cluster Shield must authenticate with Azure Container Registry (ACR) for vulnerability management in Kubernetes workloads. Supported methods include:\nWorkload Identity Federation (WIF)\nWIF is recommended for security and minimal credential management.\nManaged Identity attached to AKS node pools (VMSS)\nKubernetes Secrets (dockerconfigjson)\nWorkload Identity FederationPrerequisitesEnsure that your AKS cluster has Workload Identity Federation and OpenID Connect issuer enabled. For more information, see Enable Workload Identity.\nConfigure WIF Create Managed Identity:\naz identity create --resource-group ${RESOURCE_GROUP} --name ${IDENTITY_NAME} Create Federated Identity Credential:\naz identity federated-credential create \\ --name ${FEDERATED_CREDENTIAL_NAME} \\ --identity-name ${IDENTITY_NAME} \\ --resource-group ${RESOURCE_GROUP} \\ --issuer ${OIDC_ISSUER_URL} \\ --subject system:serviceaccount:${NAMESPACE}:${SERVICE_ACCOUNT} Assign AcrPull Role to the Managed Identity:\naz role assignment create \\ --assignee $(az identity show --resource-group ${RESOURCE_GROUP} --name ${IDENTITY_NAME} --query \u0026#39;clientId\u0026#39; --output tsv) \\ --role AcrPull \\ --scope /subscriptions/${SUBSCRIPTION_ID}/resourceGroups/${ACR_RESOURCE_GROUP}/providers/Microsoft.ContainerRegistry/registries/${ACR_NAME} Annotate Kubernetes Service Account:\nkubectl annotate serviceaccount ${SERVICE_ACCOUNT} -n ${NAMESPACE} \\ azure.workload.identity/client-id=$(az identity show --resource-group ${RESOURCE_GROUP} --name ${IDENTITY_NAME} --query \u0026#39;clientId\u0026#39; -o tsv) Label the Cluster Shield Pod:\nmetadata: labels: azure.workload.identity/use: \u0026#34;true\u0026#34; ​\tCluster Shield automatically uses this configuration.\nManaged Identity ConfigurationPrerequisites AKS cluster node pools must have the Managed Identity attached. See Azure documentation for more information. No extra Cluster Shield-specific configuration is necessary. Ensure Cluster Shield Pods have unrestricted access to Azure Instance Metadata Service (IMDS). Kubernetes SecretsConfigure Kubernetes Secrets (dockerconfigjson) as given in the Kubernetes documentation.\nCluster Shield automatically uses these secrets if available.\nAdvanced TroubleshootingVerify Managed Identity Launch debug pod:\nkubectl run krane-utils --image=gcr.io/go-containerregistry/krane:debug -n ${NAMESPACE} --stdin --tty -- /busybox/sh Retrieve Azure IMDS token:\nwget -Y off --header \u0026#34;Metadata: true\u0026#34; -q -O - \u0026#34;http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01\u0026amp;resource=https://management.azure.com/\u0026#34; Verify Workload Identity Federation Check Kubernetes annotations and labels:\nkubectl get serviceaccount ${SERVICE_ACCOUNT} -n ${NAMESPACE} -o yaml kubectl get pods -n ${NAMESPACE} --show-labels Validate Environment Variables:\nenv | grep AZURE ​\tExpected variables:\n- `AZURE_CLIENT_ID` - `AZURE_FEDERATED_TOKEN_FILE` - `AZURE_TENANT_ID` - `AZURE_AUTHORITY_HOST` Verify token retrieval with krane:\nkrane auth token -v ${ACR_NAME} Verify Role AssignmentsEnsure the Managed Identity has the AcrPull role:\naz role assignment list --assignee $(az identity show --resource-group ${RESOURCE_GROUP} --name ${IDENTITY_NAME} --query \u0026#39;clientId\u0026#39; --output tsv) Troubleshoot Kubernetes SecretsSet log level to DEBUG in Cluster Shield deployment and verify secrets retrieval in logs.\nLearn More Azure Workload Identity Federation for AKS Azure Managed Identity Azure Instance Metadata Service Kubernetes Private Registry Secrets Azure Container Registry Roles ","url":"https://docs.sysdig.com/en/cluster-shield-troubleshooting-azure/"},{"id":156,"title":"Authenticate GCP for Cluster Shield","content":"Cluster Shield supports two primary authentication methods:\nDocker Credential Helper: The authentication method recommended by GCP. It uses Google Application Default Credentials (ADC). This automatically finds credentials based on the application environment. See Authenticate using Docker Credential Helper. Service Account Key: This authentication method relies on a user-managed key pair, and is the least secure method. See Authentication using Service Account Key. Authenticate Using Docker Credential HelperDocker Credential Helper utilizes Google Application Default Credentials (ADC). ADC is Google’s recommended strategy by which authentication libraries can automatically find credentials based on the application environment. These credentials are used by Cluster Shield to authenticate to the remote registry.\nGoogle Cloud Attached Service Account GKE Autopilot clusters automatically attach service accounts; no manual configuration is required.\nCreate Minimally Privileged Service Account:\ngcloud iam service-accounts create SA_NAME \\ --display-name=\u0026#34;DISPLAY_NAME\u0026#34; \\ --project=PROJECT_ID # Grant permissions gcloud projects add-iam-policy-binding PROJECT_ID \\ --member serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \\ --role roles/container.defaultNodeServiceAccount PROJECT_ID is the project ID where cluster-shield is running Grant Artifact Registry Reader role to the Service Account:\ngcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \\ --project=\u0026#34;REGISTRY_PROJECT_ID\u0026#34; \\ --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \\ --role=roles/artifactregistry.reader Create the Node Pool:\ngcloud container node-pools create NODE_POOL_NAME \\ --service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \\ --cluster=CLUSTER_NAME ​\tCluster Shield automatically uses the attached service account.\nWorkload Identity FederationWorkload Identity Federation (WIF) provides secure, fine-grained authentication without direct service account keys.\nWorkload Identity Federation is enabled by default in GKE Autopilot clusters; no configuration required.\nEnable WIF:\nApplicable to standard clusters only.\ngcloud container clusters update CLUSTER_NAME \\ --location=LOCATION \\ --workload-pool=PROJECT_ID.svc.id.goog Configure the Node Pool:\ngcloud container node-pools create NODEPOOL_NAME \\ --cluster=CLUSTER_NAME \\ --region=COMPUTE_REGION \\ --workload-metadata=GKE_METADATA Impersonate an IAM Service Account Using a Kubernetes Service AccountTo impersonate an Identity and Access Management (IAM) Service Account Using a Kubernetes Service Account:\nCreate a Kubernetes namespace:\nkubectl create namespace NAMESPACE Deploy Cluster Shield with Helm.\nIdentify the Kubernetes Service Account:\nkubectl get deployment -n NAMESPACE CLUSTER-SHIELD-DEPLOYMENT \\ -o=jsonpath=\u0026#34;{.spec.template.spec.serviceAccountName}\u0026#34; Bind Kubernetes Service Account to IAM Service Account:\ngcloud iam service-accounts add-iam-policy-binding IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com \\ --project \\ --role roles/iam.workloadIdentityUser \\ --member \u0026#34;serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]\u0026#34; PROJECT_ID is the project ID where cluster-shield is running NAMESPACE is the kubernetes namespace where cluster-shield is running KSA_NAME is the Kubernetes Service Account (KSA) name used by cluster-shield and retrieved at previous step. Annotate Kubernetes Service Account.\nkubectl annotate serviceaccount KSA_NAME \\ --namespace NAMESPACE \\ iam.gke.io/gcp-service-account=IAM_SA_NAME@IAM_SA_PROJECT_ID.iam.gserviceaccount.com ​\tCluster Shield automatically starts using these credentials.\nAuthenticate Using Service Account KeyThis authentication method relies on a user-managed key pair that can be used as a credential for a service account. Given that the credential is long-lived, it is the least secure option and we recommend you rely on the Docker Credential Helper instead.\nTo let Cluster Shield pull images by leveraging a Service Account Key:\nUse an existing service account, or create a new service account.:\ngcloud iam service-accounts create SERVICE_ACCOUNT_NAME \\ --description=\u0026#34;DESCRIPTION\u0026#34; \\ --display-name=\u0026#34;DISPLAY_NAME\u0026#34; If necessary, grant the specific role to the service account. For instance, for a private GAR, grant the Artifact Registry Reader role to all the necessary repositories. See Granting repository-specific roles.\nTo grant a role to a single principal, run the following command:\ngcloud artifacts repositories add-iam-policy-binding REPOSITORY \\ --location=LOCATION \\ --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \\ --role=roles/artifactregistry.reader REPOSITORY is the ID of the repository. PRINCIPAL is the principal to add the binding for. Use the form user|group|serviceAccount:email or domain:domain. Examples: user:test-user@gmail.com, group:admins@example.com, serviceAccount:test123@example.domain.com, or domain:example.domain.com. ROLE is the role you want to grant. LOCATION is the regional or multi-regional location of the repository. For GCR, see Grant IAM permissions.\nCreate or retrieve the Service Account Key, following Create a service account key:\nExecute this command to create service account keys:\ngcloud iam service-accounts keys create KEY_FILE \\ --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com KEY_FILE: The path to a new output file for the private key, for example, ~/sa-private-key.json. SA_NAME: The name of the service account to create a key for. PROJECT_ID: Your Google Cloud project ID. Create a dockerconfigjson Secret in Kubernetes with the service account key. For GAR, follow Configuring an imagePullSecret.\nkubectl create secret docker-registry SECRET_NAME \\ --namespace=NAMESPACE \\ --docker-server=https://LOCATION-docker.pkg.dev \\ --docker-email=SERVICE-ACCOUNT-EMAIL \\ --docker-username=_json_key \\ --docker-password=\u0026#34;$(cat KEY_FILE)\u0026#34; LOCATION is the regional or multi-regional location of the repository. SERVICE-ACCOUNT-EMAIL is the email address of the Compute Engine service account. KEY-FILE is the name of your service account key file. For example key.json. For Google Container Registry, provide the correct value for --docker-server option as documented in JSON key file.\n​5. Run Cluster Shield. Cluster Shield retrieves all dockerconfigjson (and legacy dockercfg) Secrets from all namespaces and uses them to authenticate to remote registries.\nAdvanced Troubleshooting Check the Application Default Credentials (ADC) Token:\ngcloud auth application-default print-access-token Check Node Pool Configuration:\ngcloud container node-pools describe NODE_POOL_NAME --cluster=CLUSTER_NAME Validate Kubernetes Service Account Annotations:\nkubectl get serviceaccount KSA_NAME -n NAMESPACE -o yaml Verify IAM Permissions:\ngcloud projects get-iam-policy PROJECT_ID \\ --flatten=\u0026#34;bindings[].members\u0026#34; \\ --format=\u0026#39;table(bindings.role)\u0026#39; \\ --filter=\u0026#34;bindings.members:serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com\u0026#34; Learn More Google Container Registry Authentication Google Artifact Registry Authentication Workload Identity Federation for GKE Application Default Credentials ","url":"https://docs.sysdig.com/en/cluster-shield-troubleshooting-gcp/"},{"id":157,"title":"Compliance","content":"Access Compliance from the left navigation menu.\nCompliance is not available for Managed Falco (Secure light).\nOverviewSysdig Secure\u0026rsquo;s Compliance module provides:\nActionable compliance:\nCompliance lets you manage your risks if you have the required permissions. Take action to: Remediate\nAccept the risk\nOpen a Pull Request in your code repository.\nApplicable only of if Git Infrastructure as Code (IaC) integration is enabled\nCollected Violations:\nThe resources defined by your Zones are evaluated against compliance policies.\nViolations are collected into tiles and shown on the Compliance page.\nEvery day, resources are sent to the backend, where Sysdig performs relevant analysis of policies.\nYou can create custom policies or use Sysdig out-of-the-box policies.\nIntuitive user interface (UI): Click the resource itself, rather than navigate a list of violations.\nDownload reports, supported by APIs.\nUse CasesCompliance and Security Team MembersCompliance and Security Team Members might want to:\nCheck the current compliance status of their business zones against predefined policies Demonstrate to an auditor the compliance status of their business zone in a specific point in time (the audit) Create a report of the compliance status of their business zone, and share it with their auditors and the management team Understand the magnitude of the compliance gap DevOps Team MembersDevOps Team Members might want to:\nIdentify the compliance violations of a predefined policy applied on their business zones Manage the violations according to their severity Easily fix the violation Document exceptions and accept risk according to the risk management policy of their organization PrerequisitesTo populate the Compliance module with data, ensure that you have prepared your environment to connect to Sysdig Secure:\nConnect Cloud Accounts Install Sysdig Agent in your Kubernetes environment Include --set global.kspm.deploy=true \\ while installing Sysdig Agent. If you are running Kubernetes and want to identify which version you have, see KSPM. Understand the Compliance UIOn the Compliance | Overview page, you can review the compliance posture for each of your zones. Each row shows the compliance findings of a policy that is applied to your zone.\nFilter the list with the Select Zones and Select Policies dropdowns.\nThe Compliance table is made up of the following columns:\nZone / Policy: This is the lens to evaluate your compliance results through your zones and the policies you applied to them.\nPassing Score: The number of requirements passing for this policy view, expressed as a percentage. The percentage of resources passing (or accepted) out of all resources is evaluated. Resources are the most granular of your results. The higher the percentage, the fewer individual resources failing, the better. The higher the better.\nRequirements Failing: The number of requirements remaining to fix to get to 100% for a view, listed as a bar chart of the past 7 days\u0026rsquo; results. The smaller the number, the better. Requirements are made up of one or more controls, so requirements will be the smaller number.\nControls to Fix: The number of controls to fix to achieve a perfect score. The smaller the better. (Multiple controls make up a single requirement, so the control count will be larger than the requirement count).\nResource Violations by Severity: The number of resources failing, organized by severity. The severity can be High, Medium, or Low. One resource can be counted multiple times if it’s failing multiple controls. The fewer, the better.\nAccepted Risks: The number of violations you have chosen to accept the risk for. Risks can be accepted at the level of an individual resource, or globally on a control for all resources that match a given zone.\nFor more information, see Accepted Risk.\nPolicy Compliance ReportYou can generate and manage a Policy Compliance Report from each compliance policy and zone listing on the Compliance Overview page.\nSelect the icon under the Report column beside a listing to download or schedule a Policy Compliance Report.\nYou can generate a PDF of the Policy Compliance Report, providing an overview of the current state of a compliance policy within a specific zone. The report highlights the status of passing requirements and controls, along with the count of passing and failing resources for each control.\nDownload a PDF of the Policy Compliance Report to get an overview of specific compliance policies within a defined zone. The report highlights the status of passing requirements and controls, along with the count of passing and failing resources for each control.\nAdditionally, you can schedule reports to automatically generate and send to an email or Slack channel as needed.\nWhen you generate a PDF, it is processed in the background and stored for up to 14 days for download. See Sysdig Secure Retention Limits.\nDownload PDFYou can generate an ad-hoc PDF that might take several minutes to process. Once generated, a toast notification will appear with a link to download the report. If the toast notification is missed, open the Policy Compliance Report under the Report menu and click Downloads. You can view the Download History and download the report.\nFor more information, see Download a Report.\nSchedule ReportsYou can create a schedule directly from the Compliance Overview page using the Policy Compliance Report menu. Clicking Schedule redirects you to the schedule configuration page with predefined fields.\nAlternatively:\nOpen Reporting \u0026gt; Scheduled Reports Click New Schedule. Select Policy Compliance Report as the report type. For this report type, the zones and policy fields are required when creating a schedule.\nDownloadsTo access generated reports, open Reporting \u0026gt; Reports Manager. Hover over the item you want and click the Downloads icon. Both ad-hoc and scheduled reports are available for download.\nExisting SchedulesYou can view all scheduled Policy Compliance Report. To do so, open Reporting \u0026gt; Scheduled Reports\nCurrently, filtering reports by a specific policy and zone combination is not supported.\nDetect and Remediate VulnerabilitiesTo detect prioritized vulnerabilities, analyze them, and remediate them in Compliance, follow these steps:\nOn the Attack Surface \u0026gt; Compliance Findings page, review high-level posture performance indicators on each of the policies applied on your zones.\nSelect a Policy to see its Findings and select a failing requirement to see the Controls and failing resources that comprise it.\nSelect View Remediation to open the Remediation panel.\nOn the Remediation panel, you can Review Issues where possible, and consult Remediation Guidelines for possible fixes. You can remediate:\nManually: Copy the code and apply it in production.\nOpen a Pull Request: If you have a Git Integration, choose the relevant Git source and Compliance will create a pull request integrating the fix (as well as checking for code formatting cleanup). You can review all the changes in the PR before you merge.\nOptionally, Add Exception and remove the violation from the failed controls. When accepting the risk you can leave a note as to the reason, and choose an expiration period for the acceptance. Risk can be accepted at the level of an individual resource, or globally on a control for all resources that match a given zone.\nOptionally, select Download Report for a .CSV spreadsheet of your compliance results for development teams, executives, or auditors.\nCSPM Zones ManagementOn the Compliance page, a default Entire Infrastructure zone is automatically created. Center for Internet Security (CIS) policies and the Sysdig Kubernetes policy are automatically added to the Entire Infrastructure zone.\nTo see results from any of the dozens of out-of-the-box policies provided with the Compliance module, or for any custom policies, you must apply them to a zone.\nSelect Policies \u0026gt; Posture Policies* to create, edit, and apply zones to policies.\nUse the CSPM APIWhen your organization uses a third-party system to receive remediation reports and create tasks, consider using the CSPM APIs.\nThese are documented online along with the rest of the Sysdig Secure APIs.\nFor API doc links for additional regions or steps to access them from within the Sysdig Secure UI, see the Developer Tools overview.\nCompliance Results API Call Requirements Please specify a zone in the request. If a zone is not specified in the request, results will be returned for policies applied on the default “Entire Infrastructure” zone. If no policy is applied on the default “Entire Infrastructure” zone, you will receive empty results. Note that URL Links to every Control Resource List API call are contained in the Compliance Results Response. Tenant-Aware Hierarchical Posture ScanningSysdig Tenant-Aware Hierarchical Posture Scanning enables organizations to centrally manage and evaluate security posture across both parent and child tenants in a multi-tenant environment. This feature ensures that posture assessments performed at the child tenant level are integrated into the parent tenant’s reporting and evaluation workflows, providing a unified compliance view.\nThis feature applies only to Kubernetes scan results (KSPM).\nKey Capabilities Hierarchical Posture Reporting: Child tenant scan results are aggregated under the parent tenant for a consolidated security posture. Centralized Compliance Evaluation: All policy evaluations occur in the parent tenant, ensuring uniform application of security policies. No Cross-Region Data Transfers: This feature assumes parent and child tenants are within the same region to avoid data transfer complexities. Independent Child Tenants: Child tenants operate independently but forward posture data to the parent for evaluation. Prerequisites Same-Region Deployment: Parent and child tenants must be deployed within the same cloud region. Parent-Child Relationship Definition: A mapping of child customer IDs to a parent customer ID must be configured. Guidelines Kubernetes Compliance Data Only: Parent centralization applies only to compliance-related data for Kubernetes scan results (KSPM). Zones and Risk Acceptance: These configurations are not automatically replicated from parent to child tenants. Child Tenant Autonomy: Each child tenant remains an independent entity with its own resources and configurations. Non-KSPM Functionality: This solution currently focuses on KSPM. Other CNAPP functionalities remain unchanged. Activate Tenant-Aware Hierarchical Posture ScanningTo activate the Tenant-Aware Hierarchical Posture Scanning feature, customers must contact Sysdig Support or their account representative. Our team will assist with enabling the feature and guiding you through the setup process to ensure smooth integration into your environment.\nConfigure Tenant-Aware Hierarchical Posture Scanning Enable Hierarchical Posture Scanning.\nTo do so, set up the parent-child customer ID mapping in system settings.\nDefine Zones and Policies in the parent tenant environment:\nEnsure all child resources are available in the parent inventory. Define security zones within the parent UI. Assign policies to zones for posture evaluation. Activate Policy Evaluation in the parent tenant environment:\nEnsure that Policy evaluation occurs exclusively at the parent level. Ensure that a re-evaluation task is triggered on the parent tenant to assess compliance based on the aggregated data. Troubleshooting Tenant-Aware Hierarchical Posture ScanningChild scan results are not appearing in the parent tenantPossible Causes and Solution Parent-Child Relationship Not Defined: Verify that the customer ID mappings are correctly set. Delayed Syncing: Ensure that the system has completed its data ingestion cycle. Policy evaluation not occurring at the parent levelPossible Causes and Solutions Zones Not Defined in Parent: Ensure that zones are correctly configured in the parent tenant. Re-Evaluation Task Not Triggered: Confirm that the parent tenant is set to re-evaluate child scan results. Frequently Asked QuestionsCan policies be defined at the child tenant level?No. Policies are only defined at the parent level and applied across all child tenants.\nDoes this feature work across multiple regions?No. The feature is designed for same-region deployments to avoid cross-region data transfer complexities.\nHow often does data sync between child and parent tenants?Syncing occurs after each scan is completed in a child tenant, followed by ingestion and evaluation at the parent tenant.\nWhat happens if a child tenant is deleted?The parent tenant retains previously ingested compliance data, but no new scans will be processed from the deleted child.\nCan I turn off hierarchical posture scanning after enabling it?A: Yes. However, once turned off, child scan results will no longer be forwarded to the parent, and compliance evaluations will only happen at the child level.\nTerminology and PoliciesTerminology Changes Previous Term New Term Framework, Benchmark Policy\nThe policy is a group of business/security/compliance/operations requirements that can represent a compliance standard (for example, PCI 3.2.1), a benchmark (for example, CIS Kubernetes 1.5.1), or a business policy (for example, ACME corp policy v1). You can review the available policies and create custom CSPM/Posture policies under Policies Scopes Zone\nA business group of resources for a specific customer, defined by a collection of Scopes of various resource types, calculated by “OR” operators Control Requirement (or Policy Requirement)\nA requirement exists in a single policy and is an integral part of the policy. The requirement represents a section in a policy with which compliance officers \u0026amp; auditors are familiar. Family Requirements Group\nGroup of requirements in a policy Rule Control\nA control defines the way we identify the issue (check) and the playbook to remediate the violation detected. Vulnerability Exception Risk Acceptance\nYou can review a violation or vulnerability, but not remediate it, and acknowledge it without making it fail the policy. Posture PoliciesThe following posture policies are included out of the box:\nNational Institute of Standards and Technology (NIST)\nNIST Cybersecurity Framework (CSF) v2.0 NIST Privacy Framework v1.0 NIST SP 800-53 Rev 5 NIST SP 800-53 Rev 5 Privacy Baseline NIST SP 800-53 Rev 5 Low Baseline NIST SP 800-53 Rev 5 Moderate Baseline NIST SP 800-53 Rev 5 High Baseline NIST SP 800-82 Rev 2 NIST SP 800-82 Rev 2 Low Baseline NIST SP 800-82 Rev 2 Moderate Baseline NIST SP 800-82 Rev 2 High Baseline NIST SP 800-171 Rev 2 NIST SP 800-190 2017 NIST SP 800-218 v1.1 Federal Risk and Authorization Management Program (FedRAMP)\nFedRAMP Rev 4 LI-SaaS Baseline FedRAMP Rev 4 Low Baseline FedRAMP Rev 4 Moderate Baseline FedRAMP Rev 4 High Baseline Defense Information Systems Administration (DISA) Security Technical Implementation Guide (STIG)\nDISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) v2 Category I (High) DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) v2 Category II (Medium) DISA Docker Enterprise 2.x Linux/UNIX Security Technical Implementation Guide (STIG) v2 Category III (Low) DISA Kubernetes Security Technical Implementation Guide (STIG) Ver 1 Rel 6 DISA Kubernetes Security Technical Implementation Guide (STIG) Ver 1 Rel 6 Category I (High) DISA Kubernetes Security Technical Implementation Guide (STIG) Ver 1 Rel 6 Category II (Medium) Center for Internet Security (CIS) Benchmarks\nCIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.7.0 CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.6.0 CIS Amazon Elastic Kubernetes Service (EKS) Benchmark v1.5.0 CIS Amazon Linux 2 Benchmark v3.0.0 CIS Amazon Web Services Foundations Benchmark v5.0.0 CIS Amazon Web Services Foundations Benchmark v4.0.1 CIS Amazon Web Services Foundations Benchmark v4.0.0 CIS Amazon Web Services Foundations Benchmark v3.0.0 CIS Apache HTTP Server 2.4 Benchmark v2.2.0 CIS Azure Kubernetes Service (AKS) Benchmark v1.7.0 CIS Azure Kubernetes Service (AKS) Benchmark v1.6.0 CIS Azure Kubernetes Service (AKS) Benchmark v1.5.0 CIS Azure Kubernetes Service (AKS) Benchmark v1.4.0 CIS Azure Kubernetes Service (AKS) Benchmark v1.3.0 CIS Bottlerocket Benchmark v1.0.0 CIS Critical Security Controls V8 CIS Debian Linux 12 Benchmark CIS Distribution Independent Linux Benchmark (Level 1 - Server) v2.0.0 CIS Distribution Independent Linux Benchmark (Level 2 - Server) v2.0.0 CIS Distribution Independent Linux Benchmark (Level 1 - Workstation) v2.0.0 CIS Distribution Independent Linux Benchmark (Level 1 - Workstation) v2.0.0 CIS Docker Benchmark v1.5.0 CIS Google Cloud Platform Foundations Benchmark v3.0.0 CIS Google Cloud Platform Foundations Benchmark v2.0.0 CIS Google Container-Optimized OS Benchmark v1.2.0 CIS Google Kubernetes Engine (GKE) Autopilot Benchmark v1.1.0 CIS Google Kubernetes Engine (GKE) Benchmark v1.7.0 CIS Google Kubernetes Engine (GKE) Benchmark v1.6.0 CIS Google Kubernetes Engine (GKE) Benchmark v1.5.0 CIS Google Kubernetes Engine (GKE) Benchmark v1.4.0 CIS Kubernetes Benchmark - v1.11.0 CIS Kubernetes V1.28 Benchmark v1.10.0 CIS Kubernetes V1.27 Benchmark v1.9.0 CIS Kubernetes V1.26 Benchmark v1.8.0 CIS Kubernetes V1.25 Benchmark v1.7.1 CIS Kubernetes V1.24 Benchmark v1.0.0 CIS Kubernetes V1.23 Benchmark v1.0.0 CIS Kubernetes V1.20 Benchmark v1.0.0 CIS Kubernetes V1.18 Benchmark v1.6.0 CIS Kubernetes V1.15 Benchmark v1.5.1 CIS Microsoft Azure Foundations Benchmark v4.0.0 CIS Microsoft Azure Foundations Benchmark v3.0.0 CIS Microsoft Azure Foundations Benchmark v2.1.0 CIS Microsoft Azure Foundations Benchmark v2.0.0 CIS Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) v1.6.0 CIS Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) v1.5.0 CIS Oracle Cloud Infrastructure Foundations Benchmark v2.0.0 CIS Red Hat Enterprise Linux 9 Benchmark v2.0.0 CIS Red Hat Enterprise Linux 8 Benchmark v3.0.0 CIS Red Hat OpenShift Container Platform Benchmark v1.8.0 CIS Red Hat OpenShift Container Platform Benchmark v1.7.0 CIS Red Hat OpenShift Container Platform Benchmark v1.6.0 CIS Red Hat OpenShift Container Platform Benchmark v1.5.0 CIS Rocky Linux 9 Benchmark v2.0.0 CIS SUSE Linux Enterprise 12 Benchmark v3.1.0 CIS Talos Linux Benchmark v1.0.0 CIS Ubuntu Linux 24.04 LTS Benchmark v1.0.0 CIS Ubuntu Linux 22.04 LTS Benchmark v2.0.0 CIS Ubuntu Linux 20.04 LTS Benchmark v2.0.1 CIS Windows Server 2022 Benchmark v3.0.0 CIS Windows Server 2019 Benchmark v3.0.1 Amazon Web Services (AWS) Best Practices\nAWS Foundational Security Best Practices AWS Well Architected Framework Microsoft Azure Best Practices\nMicrosoft Cloud Security Benchmark Regulatory Compliance Standards\nAustralian Government Information Security Manual (ISM) 2022 BSI-Standard 200-1: Information Security Management v1.0 C5:2020 (Cloud Computing Compliance Criteria Catalog) CCPA (California Consumer Privacy Act) Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM) Ver 4 Digital Operational Resilience Act (DORA) - Regulation (EU) 2022/2554 DPDP (Digital Personal Data Protection) Act Esquema Nacional de Seguridad (ENS) High Family Educational Rights and Privacy Act (FERPA) Federal Information Security Modernization Act (FISMA) General Data Protection Regulation (GDPR) Gramm-Leach-Bliley Act (GLBA) HIPAA (Health Insurance Portability and Accountability Act) Security Rule 2013 HITRUST CSF (Health Information Trust Common Security Framework) v9.6.0 Information Technology Security Guidance (ITSG-33) ISO/IEC 27001:2022 v3 ISO/IEC 27001:2013 v2 Multi-Level Protection Scheme (MLPS) NERC Critical Infrastructure Protection (CIP) NIS2 Directive (Directive on measures for a high common level of cybersecurity across de Union) 2022/2555 NSA/CISA Kubernetes Hardening Guide 2022 NCSC Cyber Assessment Framework (CAF) PCI DSS (Payment Card Industry Data Security Standard) v4.0 PCI DSS (Payment Card Industry Data Security Standard) v3.2.1 Reserve Bank of India (RBI) Framework Sarbanes-Oxley (SOX) Act SEBI (Securities and Exchange Board of India) Act SOSC 2 (System and Organization Controls) 2010 Risk Frameworks\nAll Posture Findings MITRE ATT\u0026amp;CK for Enterprise v13.1 MITRE D3FEND v0.11.0-BETA-1 SCF Framework 2024.2 Sysdig Best Practices\nSysdig CoreOS (Fedora CoreOS \u0026amp; RHCOS) Benchmark Sysdig Google Cloud Benchmark v1.0.0 Sysdig IBM Cloud Kubernetes Service (IKS) Benchmark Sysdig Kubernetes Sysdig Mirantis Kubernetes Engine (MKE) Benchmark Sysdig Mirantis Openstack for Kubernetes (MOSK) Sysdig Rancher Kubernetes Engine (RKE2) Benchmark Other Policies\nLockheed Martin Cyber Kill Chain OWASP Kubernetes Top Ten v1.0.0 Cloud CoverageThe following cloud services are covered:\nAmazon Web Services (AWS) Amazon Appflow Amazon Athena Amazon Bedrock Amazon CloudFront Amazon CloudWatch Amazon DynamoDB Amazon Elastic Block Store (EBS) Amazon Elastic Compute Cloud (EC2) Amazon Elastic Compute Cloud (EC2) Auto Scaling Amazon Elastic Container Registry (ECR) Amazon Elastic Container Service (ECS) Amazon Elastic File System (EFS) Amazon Elastic Kubernetes Service (EKS) Amazon ElastiCache Amazon Elasticsearch Service Amazon Firehose Amazon GuardDuty Amazon Inspector Classic Amazon Inspector v2 Amazon Kinesis Amazon Managed Streaming for Apache Kafka Amazon MQ Amazon OpenSearch Service Amazon RDS Amazon Redshift Amazon Relational Database Service (RDS) Amazon SageMaker Amazon Simple Notification Service (SNS) Amazon Simple Queue Service (SQS) Amazon Simple Storage Service (S3) Amazon VPC API Gateway API Gateway v2 AWS Account AWS AppSync AWS Auto Scaling AWS Certificate Manager AWS CloudFormation AWS CloudTrail AWS CodeBuild AWS Comprehend AWS Compute Optimizer AWS Config AWS Cost Explorer AWS Database Migration Service AWS Elastic Beanstalk AWS Glue AWS Identity and Access Management (IAM) AWS Key Management Service (KMS) AWS Lambda AWS Macie AWS Network Firewall AWS Secrets Manager AWS SecurityHub AWS Storage Gateway AWS Systems Manager AWS Web Application Firewall (WAF) AWS Web Application Firewall (WAF) v2 AWS Region AWS Secrets Manager AWS VPN Elastic Load Balancing (ELB) Route53 Google Cloud Platform (GCP) Anthos Service Mesh API Gateway App Engine Artifact Registry Assured Workloads Backup for GKE BeyondCorp Enterprise BigQuery Certificate Authority Service Cloud Bigtable Cloud Composer Cloud Data Fusion Cloud Data Loss Prevention Cloud Dataflow Cloud Deploy Cloud Dialogflow API Cloud DNS Cloud Document AI API Cloud Domains Cloud Filestore Cloud Functions Cloud Healthcare Cloud Intrusion Detection System (IDS) Cloud Key Management Service (KMS) Cloud Logging Cloud Memorystore for Memcached Cloud Memorystore for Redis Cloud Monitoring Cloud Pub Sub Cloud Resource Manager Cloud Run Cloud Spanner Cloud Speech API Cloud SQL Cloud Storage Cloud TPU Compute Engine Container Engine Container Registry Container Registry Vulnerability Scanning Database Migration Service Dataflow Dataplex Dataproc Dataproc Metastore Datastream Deployment Manager Dialogflow Document AI Eventarc Filestore Firestore Game Services API Google Cloud Billing API Google Cloud Virtual Network Google Kubernetes Engine (GKE) Identity and Access Management (IAM) Integration Connectors Google Kubernetes Engine (GKE) Managed Service for Microsoft Active Directory (Managed Microsoft AD) Memorystore Network Connectivity Network Management Network Services Organization Policy API Recommendation AI Secret Manager Service Directory Service Management API Speech-to-Text Transcoder API Vertex AI Virtual Private Cloud (VPC) Workflows Microsoft Azure AKS AppService Authorization Classic Network Compute Event Hub Key Vault Logging Managed Identity Microsoft Container Service Microsoft Locations Microsoft Resources Microsoft Service Principal Microsoft User Monitor MySQL Network Operational Insights Operations Management PostgreSQL Security Service Bus SQL Storage Subscription Web Oracle Cloud Infrastructure (OCI) Analytics Cloud Autonomous Database Block Storage Compute Events File Storage Global Infrastructure Identity and Access Management (IAM) Integration Cloud Key Management Logging Networking Notifications Object Storage Legacy Compliance VersionsNote that you may have a legacy version of Compliance installed.\nIf you are running older versions of Sysdig Secure, you may encounter different Compliance UI and features.\nCompliance and legacy Unified Compliance can be run in parallel. When benchmarks reach End of Life (EOL), data collection will only be available through Compliance, while the Legacy Reports will remain accessible on the interface for one year from their creation date.\nData cannot be transferred between Compliance versions.\nMigration GuideFor users migrating to the Compliance module, released January 2023:\nSaaS users that connect new data sources for Sysdig cloud accounts or Sysdig agents will automatically have the new Compliance module (previously known as “Actionable Compliance”) enabled.\nResources of the connected data sources will be evaluated according to CSPM/Risk and Compliance policies that are applied to zones. Results are displayed about 5-10 minutes after connection, varying by the scale of the resources.\nIf you were using Unified Compliance:\nOn existing Kubernetes clusters, ensure the applied helm charts are updated according to the KSPM Components guide. For Existing GCP cloud accounts, enable the Cloud Asset API. The new Compliance module will be automatically enabled on your existing Cloud accounts by January 26th. ","url":"https://docs.sysdig.com/en/sysdig-secure/compliance/"},{"id":158,"title":"Group Mappings","content":"Group mapping is beneficial to:\nManage permissions for and access to Sysdig resources from your organization\u0026rsquo;s IdP itself.\nFor example, to allow your Analytics team to access a set of Dashboards, you can create a group named Analytics and grant group members access only to the dashboards they need access to.\nUpdate or completely remove user access to Sysdig resources as soon as it’s updated in the IdP.\nAs an administrator, you can:\nEnter one or more IdP groups and assign a custom role and map teams. Map a group to one or more teams or all the teams. Select a user role for each group individually. Prerequisites A group mapping can only be used if a compatible Single Sign On (SSO) authentication is enabled in Sysdig. Group mapping is currently supported when using SAML 2.0 or OpenID SSO.\nSysdig On-Premises customers must enable the admin group mapping feature. To receive assistance, contact support.\nGroup Mapping BehaviorUpon receiving the group information from the IdP, Sysdig will process it and map the user to an appropriate team or role. Following are the main group mapping scenarios:\nNo group mapping information received from the IdP (empty groups). Group information received, but the user is not a member of any mapped group. Conflicting group mapping information received. Mapping information received, no conflicts exist. No Group Mapping Information Received from the IdPThis might be an indication of an issue on the IdP side. Verify the IdP configuration and confirm that the group information is sent as part of the login flow.\nGroup Information Received, but the User Is Not a Member of Any Mapped GroupThis is a valid situation and you can use it to control the access to Sysdig. If this was not intended for controlling access, verify the user group membership on the IdP as well as group mapping within Sysdig.\nConflicting Group Mapping Information ReceivedIf a user is a member of several groups that place the user in the same team with different roles, the system does not know where to place the user.\nMapping Information Received with No ConflictsThis is the expected behavior and in this situation, the user is assigned to teams/roles according to the available group mapping information.\nGroup Mapping SettingsFor certain situations, the system behavior can be configured. These options can be configured only using the Group Mapping Settings API.\nIn case of No group mapping information received from the IdP or Group information received, but the user is not a member of any mapped group, the behavior can be configured as:\n401 - Access denied (Default): Users are prevented from accessing the system. DefaultTeam/DefaultRole: Place a user in a default team with a default role. 302 - Redirect: Users are prevented from accessing the system and are redirected to a URL defined in noMappingsErrorRedirectURL. In case of Conflicting group mapping information received, the behavior can be configured as:\n401 - Access denied (Default): Users are prevented from accessing the system. First match: Place the user in the first found group. Group priority is controlled with the group ID. The lower the ID, the higher the priority. Weight based: Additional weight field is introduced to help with conflict resolution. This field can only be configured using the API. The lower the weight, the higher the priority. Weight by team based: Further enhancement of weight-based conflict resolution. Identifies conflict per team and resolves each conflict individually. This field can only be configured using the API. The lower the weight, the higher the priority. Enable Group MappingYou can enable group mapping in Sysdig Secure or Sysdig Monitor when using SAML 2.0 or OpenID.\nOIDCPrerequisitesConfigure group mapping on your Identity Provider (IdP) side. For instructions on configuring IdP, see the relevant documentation:\nOkta Configure Group Mappings for OIDC Navigate to Settings \u0026gt; Authentication (SSO).\nClick New Configuration\nSelect OpenID.\nEnable Group Mapping. Specify the Group Claims Name. It is the configurable metadata display name of an identity provider (IdP) group attribute. This value must match the group attribute display name configured on the IdP side. Group Claims Name is processed on every login attempt to read the groups that the user belongs to.\nClick Save Settings.\nSAMLPrerequisitesConfigure group mapping on your Identity Provider (IdP) side. For instructions on configuring your IdP, see the relevant documentation:\nMicrosoft Azure Okta Group Mappings for OIDC Configure Group Mappings for SAML Log in to Sysdig as an administrator.\nOpen Settings \u0026gt; Authentication (SSO).\nClick New Configuration.\nSelect SAML.\nEnable Group Mapping. Specify the Group Attribute Name.\nUse the configurable metadata display name of an identity provider (IdP) group attribute. This value must match the group attribute display name configured on the IdP side. Group Attribute Name is processed on every login attempt to read the groups that the user belongs to. Click Save Settings.\nAdd a MappingYou can map a group to one role and one or more teams.\nMake sure to configure at least one Admin group mapping.\nNavigate to Settings \u0026gt; Group Mappings (SSO). Enter the Group ID.\nThis is the unique name assigned to the group on the IdP side. This attribute value needs to match what’s included in the IdP response.\nIf the group information is coming from an Entra setup, and Entra is configured to send the Object ID as the attribute value for the group, you may need to use the Object ID instead of the Unique Name.\nIf the group members should assume the Sysdig administrator role, select the checkbox in the Admin column.\nSelect a role from the Role drop-down.\nYou can select only one role for a group mapping. Ensure that the roles aren’t conflicting with each other because the mapping will not work if conflicting roles exist for a user.\nSelect one or more teams from the Teams drop-down.\nOptionally, add additional mapping by clicking Add Group and repeating the same steps.\nClick Save.\n","url":"https://docs.sysdig.com/en/administration/group-mappings/"},{"id":159,"title":"Reports Manager","content":"From the Reports Manager, you can:\nDownload a report. Copy a report. Schedule the creation of a reports. View schedules associated with a report. View the history of previously generated reports. Modify reports and their filters. Access Reports ManagerTo access the Reports Manager:\nLog in to Sysdig Secure.\nSelect Reporting \u0026gt; Reports Manager from the left navigation bar.\nThe Reports Manager page appears.\nCreate a ReportYou can create reports from report templates, existing reports or from elsewhere in the UI.\nFrom Report Templates Log in to Sysdig Secure.\nSelect Reporting \u0026gt; Reports Manager.\nSelect New Report from the top of the page.\nChoose from a template.\nTo narrow down the report templates, you can select the category from the left pane.\nSave the report, and you can edit the panels within the report.\nFrom Existing ReportFrom the Reports manager you can either:\nOpen the menu for a selected report and select Duplicate. Open the report, on the top right menu and select Duplicate. From Elsewhere in the UIDepending on where you are in the Sysdig Secure UI, you may find either a reporting column with a report icon:\nOn the Attack Surface \u0026gt; Compliance Findings page, you can see the select the Report button in the top right corner to download one of the following reports: On the Attack Surface \u0026gt; Compliance Findings page, you can see the select the Report button in the top right corner to download one of the following reports:\nResource Posture Report Policy Compliance Report Policy Posture Report Alternatively, you can click the report icon to on the right side of a Compliance policy listing.\nModify a ReportYou can modify reports using either:\nReport Filters Panel filters Report FiltersCurrently only zones are supported within report filters, these will affect all panels within the report. When a zone is changed, you can save the filter, which will affect any schedule that uses that report. Optionally, you can save the filter as a new report, which will create a new report, and not affect any schedules.\nPanel FiltersOn the Report Detail page, you can view panels of the reported data. Each panel contains predefined queries relevant to the data listed, which determine the columns displayed and the conditions available for that query. Editing the panel\u0026rsquo;s filters will only affect the panel you are editing and will not impact any other panels within the report.\nSet a ScheduleReport schedules let you determine when a pre-existing, defined report should be undertaken again.\nTo set a report schedule:\nLog in to Sysdig Secure and select Reporting \u0026gt; Scheduled Reports.\nSelect a report.\n​ The Report Detail page appears.\n​ Edit the Frequency \u0026amp; Timeframe and click Update Schedule\nTo create a new scheduled report, click the New Schedule calendar icon.\nThe New Schedule page opens.\nFill out the schedule details:\nUnder Report Details, select Existing report or New report\nSelect All resources or a Specific Zones to choose a scope. If you select Specific Zones, be careful not to share a report of a zone with a team that is not authorized to view that zone.\nName: Choose a descriptive name.\nDescription: Enter a description of the report. Optionally, specify the password if you choose to set a password for the report.\nSet the Frequency \u0026amp; Timeframe. For example, you could cover a whole month by setting the Frequency to Monthly at 03.30 PM local time.\nSelect a Compression Format (GZIP or ZIP)\nNotification Channel: Select where your completed reports should be sent. To set up a Notification Channel, see Set Up Notification Channels. The available channels are:\nEmail Slack Format: Select the format in which the report should be sent; CSV, JSON, or PDF. PDF is limited to 7 columns and 250 rows. Therefore, use CSV or JSON for larger reports.\nPassword Protection: Enable this option to secure the report with a password. Make sure to remember your password or save it in a password manager, as it cannot be recovered if forgotten.\nNavigate the Report Detail PageAccess The Report Detail page by selecting a report from the Reports Manager page.\nSysdig reevaluates reports multiple times per day, as well as when you update a workload\u0026rsquo;s image.\nFilter by Zone (Scope)Use the Zones field to include specific Zones in the report you have open. By default, all zones are selected.\nEnter a zone or zones to affect all the panels inside the report.\nThe zone selection is not permanent and will not affect any scheduled reports. The zone is stored in the URL, so you can save the URL to go back to it later.\nExport Reports and TablesIn Reporting, you can download entire reports, or download individual tables from a report as in CSV or JSON format. You can also view when reports were previously downloaded.\nYou can also use the three-dot menu to quickly access the following:\nDownload a report in PDF View download history View existing schedules Download a ReportTo download a report:\nLog in to Sysdig Secure and select Reporting \u0026gt; Reports Manager.\nSelect a report.\nThe Report Detail page appears.\nClick Download.\nChoose the File Name and Format.\nCSV and JSON formats are only available when the report only has one table or panel. Otherwise, reports are available to download in PDF.\nClick Download to download the report.\nReports can be downloaded as a .zip or .gz file.\nDownload a TableTo download a single table:\nLog in to Sysdig Secure and select Reporting \u0026gt; Reports Manager.\nSelect a report.\nThe Report Detail page will open.\nHover over the top right corner of the desired table to reveal the scheduled, download and settings icons.\nSelect the download icon.\nThe Download window appears.\nSelect the desired File Name and Format.\nThe available formats are CSV, JSON and PDF.\nView DownloadsTo view previous downloads of Reports:\nLog in to Sysdig Secure and select Reporting \u0026gt; Reports Manager.\nSelect a report.\nThe Report Detail page will open.\nClick the three-dot menu in the top right corner and select Download History.\n","url":"https://docs.sysdig.com/en/sysdig-secure/reports-manager/"},{"id":160,"title":"On-Prem Release Notes 2021","content":"Release 5.0.2 Hotfix December 2021Upgrade ProcessSupported Upgrades From: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5, 5.0.0, 5.0.1\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Install instructions.\nDefect Fixes Fixed a version-comparison bug in RedHat rpm packages. Enabled a retention manager for Secure-only on-prem installations to handle data retention. Release 5.0.1 Hotfix November 2021Upgrade ProcessSupported Upgrades From: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5, 5.0.0\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Install instructions.\nDefect Fixes Fixed missing field \u0026ldquo;Last Evaluation Date\u0026rdquo; in the scanning policy evaluation results and Scheduled Reports Kubernetes environment / labels are no longer mandatory to generate a scanning Scheduled Report Fixed CVSS filters in scanning Scheduled Reports Fixed an issue in scanning Scheduled Reports when scanning Red Hat images that caused related Red-Hat advisories (RHSA) to not be displayed Fixed priority sorting for \u0026lsquo;Unknown\u0026rsquo; severity vulnerabilities that are now considered less severe than \u0026lsquo;Negligible\u0026rsquo; in scanning Scheduled Reports Release 4.0.5 Hotfix October 28, 2021Upgrade ProcessSupported Upgrades From: 3.6.2, 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Install instructions.\nDefect Fixes Fixed Scheduled Reports not displaying last evaluation date field Fixed an issue in 4.0.x Scheduled Reports when scanning Red Hat images, causing vulnerabilities missing related Red-Hat advisory (RHSA) to not be displayed Release 4.0.4 Hotfix September 29, 2021Upgrade ProcessSupported Upgrades From: 3.6.2, 4.0.0, 4.0.1, 4.0.2, 4.0.3\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Install instructions.\nDefect Fixes Fixed a timeout issue for policy advisor and scanning database init containers occuring in some environments Fixed a certificate handling issue at network security component Release 5.0 September 7, 2021 Known limitations\nThe Network Security Policy tool is not supported in OpenShift 3.11 with this release. Version 5.0.0 does not yet support Kubernetes 1.22. Upgrade Process**Supported Upgrades From:**4.0.x\nFor the full supportability matrix, see the Release Notes on GitHub. There you will also find important Install and Upgrade instructions.\nSysdig PlatformDefine S3 Bucket Path for Storing CapturesSysdig Platform users can now define a custom path in the S3 bucket they are using for storing captures. This is useful to those who want to reuse a certain bucket used for other purposes or send captures from different installations to the same S3 bucket. For more information, see (On-Prem) Configure Custom S3 Endpoint.(On-Prem) Configure Custom S3 Endpoint\nWebhook Channel EnhancementsSysdig supports the following on a Webhook channel integration:\nInsecure connections: You now have the ability to skip the TLS verification.\nCustom headers: If your Webhook integrations require additional headers or data you can append to the alert format by using a custom header on the UI. This option is in addition to the existing API facility to add custom headers programmatically.\nS3-Compatible Storage for Capture FilesConfiguring S3-compatible storage, such as Minio or IBM Cloud Object Storage, for your Sysdig captures is now supported on Sysdig Monitor. The capability can be turned on by configuring the system appropriately, as given in (SaaS) Configure Custom S3 Storage Endpoint.\nMicrosoft Team ChannelYou can now use Microsoft Team s as a notification channel in Sysdig Monitor. See Configure a Microsoft Teams Channel for more details.\nDark ModeThe dark appearance, known as Dark Mode, is available in Sysdig applications.\nSysdig can now automatically match your OS preferences. Available in Sysdig platform on-premises, or in SaaS in the US East and rolling out globally. For more information, see Configure Theme Preference.\nCustomized Session ExpirationSession expiration is the amount of time a user can remain idle before the session is automatically ended or expired. After the session expires, the user must log in to the Sysdig application again.\nSysdig now gives you the ability to make a shorter or longer idle session expiration for Sysdig applications. When a user browser is idle for a certain period of time, they will get automatically logged out. For more information, see Configure Customized Session Expiration.\nSysdig MonitorWorkload LabelSysdig Monitor now supports two new labels, kubernetes.workload.name and kubernetes.workload.type which can be used for scoping Dashboards and configuring Gropings.\nEarlier, each type of object (deployment, replicaset, statefulset, etc.) was unique, and in turn, you needed to use different types of Kubernetes Dashboards and a different Grouping resulting in n/a , where distinct types of Kubernetes objects are listed.\nFor more information, see Unified Workload Labels.\nSilencing Alert NotificationsSysdig Monitor allows you to silence alert notifications for a given scope for a predefined amount of time, and schedule silence in advance. When silenced, the alert will still be triggered and posted on the Events feed and in the graph overlays but will indicate it has been silenced. The types of notification channels you can use are Email, Slack, and Amazon SNS.\nYou will be notified 30 minutes before the start time and 30 minutes before the end time of a silence window. You will also be able to easily extend or end an active silence. To access the feature, navigate to Alerts \u0026gt; Silence on the Monitor UI.\nFor more information, see Silence Alert Notifications.\nSysdig SecureSysdig Secure for cloudSysdig Secure for cloudis available with Cloud Risk Insights for AWS, Cloud Security Posture Management based on Cloud Custodian for AWS and multi-cloud threat detection for AWS using Falco.\nWhat\u0026rsquo;s Included in this release:\nInsights: a powerful new visualization tool for threat detection, investigation, and risk prioritization, to help identify compliance anomalies and ongoing threats to your environment. With Insights, all findings generated by Sysdig across both workload and cloud environments are aggregated into a visual platform that streamlines threat detection and forensic analysis.\nThreat Detection based on AWS CloudTrail: To detect threats, anomalies and suspicious activities with the flexible Falco engine. See also: Sept 29, 2020.\nCloud Security Posture Management with AWS Benchmarks: The AWS CIS Benchmarks assessment evaluates your AWS services against the benchmark requirements and returns the results and remediation activities you need to fix misconfigurations in your cloud environment.\nWe\u0026rsquo;ve included several UI improvements to provide additional details such as: control descriptions, affected resources, failing assets, and guided remediation steps, both manual and CLI-based.\nImage Scanning for ECR and Fargate: one-click deployment\u0026ndash; see also ECR April 13, 2020 and Fargate Sept. 28, 2020.\nFalco Policy TunerSysdig is now releasing a managed version of the standalone Falco Tuner.\nPreviously, you had to run the tuner in your local environment, print suggestions, and manually update a rule with those suggestions. The new feature runs in the background and automatically tunes noisy rules and false positives. To streamline the creation of these exceptions, we\u0026rsquo;ve created a new object within Falco called exceptions.\nNote: To enable the tuner, Admin access rights to Sysdig Secure are required.\nFeature Enhancement: Falco ExceptionsPreviously, exceptions were created using and not conditions inside a Falco rule, e.g.\n- rule: Write below binary dir ... condition: \u0026gt; bin_dir and evt.dir = \u0026lt; and open_write and not package_mgmt_procs and not exe_running_docker_save and not python_running_get_pip and not python_running_ms_oms and not user_known_write_below_binary_dir_activities .... However, this process can be unwieldy and can result in unintended behavior. The new format, using exceptions, looks like this:\n- rule: Write below binary dir ... condition: bin_dir and evt.dir = \u0026lt; and open_write .... exceptions: - name: package_mgmt_procs fields: proc.name comps: in values: package_mgmt_binaries # list of known binaries ... See the full documentation here.\nTunable Exclusions Available in Insights DetailsWe\u0026rsquo;ve added the ability to identify and add exceptions using the Policy Tuner in the Insights module. Now you can receive policy tuning recommendations directly within the Insights view, enhancing usability, ease, and refinement of results.\nSee also: Insights and Runtime Policy Tuning.\nNew Scan Results Page LayoutWe have reorganized the visual layout of the Scan Results summaries to clearly distinguish policy evaluation from vulnerability matching and to better summarize the information.\nImprovements include:\nVulnerabilities and Policies are now two different sections in the UI\nVulnerability match update time is displayed to further distinguish from the Policy Evaluation time\nPolicy breakdown is collapsed by default to reduce cognitive load\nRe-evaluate policies button is now located in the impacted section only, as opposed to whole page\nApart from the vulnerability update time, the data remains unchanged from previous versions\nSee also: Review Scan Results.\nNew and Improved Host OS and Container Scanning ToolsWe at Sysdig are working hard to improve your security posture and compliance experience. As part of this commitment we are implementing a new framework to generate host benchmark results, introducing host scanning, and making backend improvements to the image scanning mechanism.\nInstallation StepsThe new features require a new component to be installed called the Node Analyzer. We\u0026rsquo;ve provided an installation script to automate the installation or to upgrade an existing Node Image Analyzer daemonset, if applicable.\nOnce you\u0026rsquo;ve installed or updated the components, the UI will automatically show Host Scanning and new Benchmarks functionality can still be accessed.)\nHost Scanning: NewIn addition to Sysdig Secure\u0026rsquo;s rich array of tools for scanning container images, you can now scan the hosts as well.\nScan hosts for vulnerabilities, and detailed Software Bill of Materials (SBoM)\nSupport for OS (e.g. rpm) and non-OS (e.g. Java, Ruby, Python) packages\nCompare and diff scan results\nHost Benchmarks: Updated More checks\nBetter results\nClustered aggregations - understand the posture of your environments, not just a single entity\nImage Scanning: Updated Automatically scan images if they have not been scanned Kubernetes Network Security: New Configuration and Improved User ExperienceSysdig\u0026rsquo;s Kubernetes Network Policy tool has been updated to include additional fine-tuning configurations and an improved user experience.\nAdditional Configuration Panel Workload Labels: Depending on your workload labelling policy, some labels may not be relevant for generating a KNP policy. Use the additional config to include/exclude a particular set of labels per cluster/namespace to declutter your UI and the resulting policy.\nUnresolved IP Configuration: Now it is possible to label raw IPs that are not mapping to your Kubernetes/OpenShift entities, i.e. external cloud provider services, so these labels will be automatically applied to the topology and ingress / egress tables.\nCluster CIDR configuration: If the CIDR configuration is not automatically detected by the agent, you can now directly configure internal subnets per cluster using the Sysdig interface.\nImproved UX Topology map: Additional information pop-up when hovering over a network connection or a network node, such as server process, source, destination, and more.\nUnresolved IP filtering: In the ingress and egress tables, by type or using free text search.\nAdditionally, Network is now presented as a top-level item in the Sysdig Secure navigation.\nActivity Audit ImprovedThe Activity Audit user interface was enhanced as follows:\nActivity Audit entry point moved under the Investigate menu\nTrace feature, used for kube exec, is now also available for parent commands\nThe filter selector is also available in-line, with no need to open the detail view\nLateral Tree view removed and replaced with the Scope menu above, in alignment with the Event panel\nAlert Notification Channel for Microsoft TeamsMicrosoft Teams is now available as an Alert Notification Channel in Sysdig Secure for Runtime Policies. See also: Manage Policies\nInternal Scanning Date ImprovementsScanning policies have improved the reliability of the Max days since creation and Max days since fix rule gate parameters. The information is now included in the inline-scan JSON report and available in the Jenkins plugin.\nReporting Improved with Multi-Select OptionAdded the option to select multiple policies and multiple package types as part of a scheduled scanning report.\nRelease 4.0.3 August 27, 2021This release is a hot-fix only release.\nUpgrade ProcessSupported Upgrades from: 3.6.2, 4.0.0, 4.0.1, 4.0.2\nFor Install/Upgrade instructions and the full supportability matrix, see the GitHub documentation.\nInstallation InstructionsFull installation instructions for Kubernetes environments: here.\nDefect FixesInline Scanning Fix for Sysdig SecureFixed an issue when scanning long Java manifest files that caused the scan to fail.\nLDAP Improvements for Sysdig PlatformFixed an issue with the LDAP sync Job running out of shared memory. The LDAP sync will no longer stop if it encounters an intermittent issue or error, but will allow the sync to complete.\n4.0.2 June 29, 2021This release is a hot-fix only release for Sysdig Secure features.\nUpgrade ProcessSupported Upgrades From: 3.6.2, 4.0.0, 4.0.1.\nFor Install/Upgrade instructions and the full supportability matrix, see the GitHub documentation.\nImprovementsCSV Runtime Reports The runtime labels that were described in a single CSV column (JSON encoded) will now be represented using one column per label.\nIf the same vulnerability, same package, same image is found in several runtime contexts, the CSV will separate each runtime context in a separate row, instead of building a JSON array with several objects nested.\nSee also: Scheduled Reports.\nDefect FixesFixed Incorrect Fingerprinting Causing False Positives in ScanningFixed incorrect version detection for Apache Struts 2 packages leading to false positives.\nFixed Metadata Retrieval Issue in ScanningFixed incorrect metadata retrieval for corner cases when imageIDs are associated with several digests.\nImproved Memory UsageReduced Redis memory consumed by scanning by optimizing the usage of the scanning API cache.\nFixed Subscription Alert EntriesFixed scanning alerts triggers for images discovered via the Node Image Analyzer or Inline Scan container.\nReadable Filenames for Scanning ReportsThe scheduled scanning reports now generate report files named after the report name i.e. my-daily-critical-vulns-2021-05-04.zip\nRelease 4.0.1 May 05, 2021This release is a hotfix-only release for Sysdig Secure features.\nUpgrade ProcessSupported Upgrades From: 3.6.2\nFor Install/Upgrade instructions and the full supportability matrix, see the GitHub documentation.\nImprovementsImproved RHEL Vulnerability MatchingThe RedHat OVAL source feed interpretation and the matching algorithm have been improved to handle special RedHat packages versioning rules. This should effectively translate into fewer false positives and more accurate fix versions for RH-based packages.\nDefect FixesSecurity FixA SQL injection vulnerability discovered in 4.0.0 has been fixed in 4.0.1.\nScan ResultsThe vulnerability list on the UI shows a different number of vulnerabilities as compared to the summary PDF report for the same image. This issue has been fixed as part of Improved RHEL Vulnerability Matching.\nSecure Audit Reporting ErrorsSecure Audit Reporting displayed intermittent errors for custom agent versions. Fixed the agent version parsing to correctly assess feature support.\nRelease 4.0.0 April 06, 2021Upgrade ProcessSupported Upgrades From: 3.6.2\nFor Install/Upgrade instructions and the full supportability matrix, see the GitHub documentation.\nMigrating MySQL to PostgreSQLFor consolidation and to meet higher performance requirements, upgrading to v4.0.0 from v3.x.x involves migrating MySQL to the PostgreSQL database. The migration process is seamless and no user intervention is expected. For more information, see Migration Documentation on GitHub.\nRelated Documents Installation Additional Docs Kubernetes README Review the Upgrade and other files within the version-specific GitHub folder for additional information. Replicated Not supported on 4.0.0 DeprecationsDeprecating \u0026ldquo;Scan Image\u0026rdquo; Reaction in AlertsWhen setting up runtime alerts in previous versions, there was an option to trigger \u0026ldquo;scan image\u0026rdquo; when an unscanned image was detected. This has been deprecated in the UI in favor of the Node Image Analyzer, which is bundled by default with the Sysdig agent as an additional container per node.\nSee also: Manage Scanning Alerts.\nDefect FixesLarge SAML MetadataAn issue was detected in an earlier version where large SAML metadata could not be saved due to limits in the database field size. This issue is now fixed and Sysdig now supports large SAML metadata.\nSingle Sign-On for Monitor and SecureWhen a user logs in to Sysdig products successively, a confusing error message related to SAML was displayed if:\nIf both Secure and Monitor have been configured with SSO.\nThe Create User on login feature has been turned on for both products.\nThis issue is fixed with this release.\nWhen a user created in one product logs in to another, and if the Create user on login feature is turned on, no error message is thrown. The user is added to the appropriate team in the product and can log in to the other.\nSysdig PlatformMonitor UI Displays On-Premises License InformationThe on-prem license information is now displayed on the Monitor UI. Additionally, users will be warned of imminent license expiration on the UI.\nChanges to Auditing Sysdig Platform ActivitiesDue to the changes in the underlying database (PostgreSQL instead of MySQL), the existing Sysdig auditing data will be dropped when performing the upgrade from 3.x to 4.0 on-premises version. The audit data is not migrated due to the potentially large size of the table, which could prolong the upgrade process. The data remains available in the MySQL database. If you require the data, do the following:\nBefore upgrading, dump the audit_events table from MySQL.\nWhen the upgrade is completed, import the data back to the new database if you desire.\nContact your Sysdig contact for details on how to perform this operation.\nSysdig MonitorImproved AlertsThe Alert interface has been improved to allow faster browsing and easier management. For more information, see Alerts.\nExplore Workflow EnhancementsThe Explore interface has been improved to allow faster troubleshooting.\nYou are now launched directly into the drill-down view when you navigate to Explore. You will still be able to group and navigate your infrastructure by using the hierarchical scope tree.\nThe new Grouping editor helps you create and manage your infrastructure groupings.\nFor more information, see Explore.\nVisualizing Missing Data on DashboardsDashboards now show null or missing data values as gaps instead of zero. Optionally, missing data can be displayed as a dotted or solid line in both Form-based and PromQL panels. StatsD metrics will continue to show null values as zero unless overridden by the settings.\nHost OverviewTo complement Sysdig Kubernetes Overviews, Hosts Overview has been released. Host Overview provides a unified view of the performance and health of physical hosts in your infrastructure.\nSysdig SecureServerless Agent Preview FeatureThe 1.0.x serverless agent is supported as a preview feature with Sysdig Platform 4.0. Note that there is no guarantee of forward or backwards compatibility with this preview release.\nSysdig Serverless Agent 1.0.0 for Fargate ECSThe \u0026ldquo;container-as-a-service\u0026rdquo; serverless environment calls for new agent models, and Sysdig provides them. Whereas in ECS, users still manage the underlying instances, with AWS Fargate the host is never visible and users simply run their workloads. And while this model is convenient, it can introduce risk as many people leave the containers unattended, without monitoring security events within that can exfiltrate secrets, compromise business data, impact performance, and increase their AWS costs. In addition, it is not possible to install a standard agent in an environment where you do not have access to a host.\nFor these reasons, Sysdig has introduced a new \u0026ldquo;serverless agent\u0026rdquo; model that can be deployed in these container-based cloud environments. The first implementation is for Fargate (ECS).\nSysdig will be rolling out security features on the serverless agent over time. In v1.0.0, users will see:\nRuntime Policies and Rules\nSecure Events\nTo obtain secure event information and the associated Falco policies and rules in the Sysdig Secure UI from a Fargate environment, users install the serverless agent using a CloudFormation Template. Then log in to Sysdig Secure and review the events in the UI.\nSee also: AWS Fargate Serverless Agents and Serverless Agent Release Notes (for future updates).\nKubernetes-Native Network Security with Sysdig Secure (Beta)A new feature has been added to Sysdig Secure for authoring and refining Kubernetes network policies (KNPs) that:\nAutomatically extracts the connection information, by observing the cluster networks and microservices communications\nOffers a visual flow to fine-tune the Kubernetes network policies, incorporating the user\u0026rsquo;s adjustments\nAutomatically generates the KNP YAML to be applied, without requiring previous Kubernetes policy knowledge from the user.\nAs soon as the feature is enabled, the Sysdig agent starts collecting and processing application communications, which are then enriched using Kubernetes metadata and presented in two different ways:\nTopology maps: a visual representation of the network flow between the Kubernetes entities (Services, Deployments, StatefulSets, DaemonSets, Jobs)\nIngress / Egress tables: for additional detail on each inbound/outbound communication and policy tuning.\nOnce the user has finished editing the desired policy, Sysdig will automatically compute the associated KNP YAML:\nEnforcement is delegated to the Kubernetes control plane, favoring policy-as-code and avoiding direct tampering with cluster communications\nAllow-only approach ensures that any communication which is not explicitly allowed by the policy will be forbidden\nPrerequisitesSysdig agent version 10.7+\nSupported Orchestrator Distributions and CNI Plugins:\nVanilla Kubernetes (kops, kube-admin) using Calico\nOpenShift 4.x using OVS\nGoogle GKE using Calico\nAmazon EKS using Calico\nRancher Kubernetes using Calico\nPlease contact us to enable this feature for your Sysdig Secure accounts.\nSee also: Network Security Policy Tool.\nNetwork Micro-Segmentation: Support for CronJobs, Weave, \u0026amp; Cilium CNIsThe Sysdig Network Security Policy Tool has been upgraded to add support for CronJob pod Owners.\nWith the addition of CronJob support, communication is aggregated to the CronJob (scheduler) level, rather than the Job. Therefore, when administrators review the activity in the Network Security Policy menu, they will see the higher-level CronJobs listed, and not an excess number of individual Job entries.\nThis update also adds support for Weave and Cilium CNIs on top of Calico support.\nNew Product: Rapid ResponseRapid Response is an Endpoint Detection and Response (EDR) solution built for cloud-native workloads, which gives security engineers the ability to respond to incidents directly via a remote shell. The shell uses the underlying host tooling already installed, such as kubectl, Docker commands, cloud CLIs, etc. Users can also mount their own scripts to use any familiar tooling.\nRapid Response requires a component installed on the host machine. This component provides end-to-end encrypted communication using a passphrase only your team knows. The Rapid Response feature is disabled by default and can only be accessed to teams that have the feature enabled. Admins can see all user activity, including access to audit logs, and can initiate a rapid response session. Advanced users can view only their own user activity, including their audit logs, and can initiate a rapid response session.\nSee also: Rapid Response: Installation and Rapid Response\nImage Scanning Reports v3 [BETA]The Image Scanning Reports feature has been thoroughly updated and has moved from a synchronous model to an asynchronous mode, in which you schedule the reports you need and then receive them through your normal notification channels (email, Slack, webhook.). The new version also includes:\nA preview function to check report structure in the UI\nA more advanced query builder\nExtended set of data columns (i.e. CVSS base score and vector) and extended set of available filters (i.e. package type)\nReporting v3 supports two different types or reports:\nVulnerability report: Containing vulnerability, package and image data\nI.e. Vulnerabilities in my runtime with Severity ≥ High, a Fix available and not included in a vuln exception list.\nPolicy report: Containing scanning policies and evaluated images data\nI.e. Images in my internal registry failing the \u0026ldquo;NIST\u0026rdquo; scanning policy.\nYou need to enable this feature from the Sysdig Labs setting on the User Profile page.\nSee Scheduled Reports for more detail.\nUI-Based Admission Controller ReleasedKubernetes\u0026rsquo; admission controllers help you define and customize which requests are allowed on your cluster. An admission controller intercepts and processes requests to the Kubernetes API prior to persistence of the object, but after the request is authenticated and authorized.\nSysdig\u0026rsquo;s Admission Controller (UI-based) builds upon Kubernetes and enhances the capacity of the image scanner to check images for Common Vulnerabilities and Exposures (CVEs), misconfigurations, outdated images, etc., elevating the scan policies from detection to actual prevention. Container images that do not fulfill the configured admission policies will be rejected from the cluster before being assigned to a node and allowed to run.\nSee also: Admission Controller.\nMain Features Granular admission policies: Defining a global policy per cluster, but also at the level of particular namespaces or image paths (i.e. registries) Registry and repository whitelist\nOnly allow images that pass the scanning evaluation criteria\nOnly allow images that have been evaluated recently\nOnly allow images that have been scanned before creation is requested to Kubernetes\nRegistry and repository whitelist\nScan unscanned requested images immediately (optional)\nCIS AWS Cloud Benchmark ReleasedA new cloud compliance standard has been added to the Sysdig compliance feature - CIS AWS Benchmark. This assessment is based on an open-source engine - Cloud Custodian - and is an initial release of Sysdig Cloud Security Posture Management (CSPM) engine. This first Sysdig cloud compliance standard will be followed by additional security compliance and regulatory standards for GCP, IBM Cloud and Azure.\nThe CIS AWS Benchmarks assessment evaluates your AWS services against the benchmark requirements and returns the results and remediation activities you need to fix misconfigurations in your cloud environment. We\u0026rsquo;ve also included several UI improvements to provide additional details such as: control descriptions, affected resources, failing assets, and guided remediation steps, both manual and CLI-based when available.\nNew Runtime Policy Events JSON FormatThe JSON format for the runtime policy events has been upgraded to include full scope information, rule labels, and a single-line representation for the event field\u0026rsquo;s keys and values.\nTo preserve backwards compatibility with existing integrations, the former JSON format is still available (and used by default on migration).\nFrom the Event Forwarder page, under \u0026ldquo;Data to Send,\u0026rdquo; the old JSON format is labeled \u0026ldquo;Policy Events (Legacy)\u0026rdquo; and the new one as \u0026ldquo;Runtime Policy Events.\u0026rdquo;\nSee also: Event Forwarding.\nScan Results List UpdatedThe UI for the list of scanned images has been updated to include several functionality and design improvements:\nStatus column (Passed or Failed) is now filterable\nImage Origin (Inline Scanner, Node image analyzer, etc.) is now visible, filterable, and has multi-select option\nImage registry is now visible on the table\nAbility to sort by date-added (default) or image name\nFlexible free-text search: filter by registry/repo:tag, repo:tag, repo, etc.\nSee also: Review Scan Results.\nImproved UI for New UsersWe have added introductory splash screens throughout the product to help you get started when using a feature for the first time.\nUI Improvement on Rules Library and Rule DetailsUsability improvement so you can see in which policies a rule is used, from both the Rules Library list and the Rule Detail view. See Manage Rules for details.\nDeprecation Notice: Legacy Commands Audit \u0026amp; Legacy Policy events The \u0026ldquo;Commands Audit\u0026rdquo; feature was deprecated in favor of Activity Audit in November 2019. This feature will be completely removed from the On-prem distribution in version 4.1.\nSysdig agent version 9.5.0+, released in January 2020, is required by the Activity Audit feature.\nThe \u0026ldquo;Policy Events\u0026rdquo; feature was deprecated in favor of the new Events feed in June 2020. This feature will be completely removed from the On-prem distribution in version 4.1.\nSysdig agent version 10.3.0+ is recommended.\nWindows Scanning ReleasedA beta version of the Windows Scanning Inspector has been released. This is a new feature from Sysdig for scanning Windows containers.\nThis is a standalone scanning engine. There is no centralized UI, management, or historical data. These features are planned for a future release.\nSee also: Windows Container Image Scanning [BETA].\nFeatures Identify Windows container image vulnerabilities from:\nWindows OS CVEs Windows or Linux hosts\nReports in JSON and PDF\nPolicy support\nSeverity\nFix available\nDays since fixed\nMalware Detection during Inline Image AnalysisAs part of the inline scanner version 2.3.1 release, malware scanning was added as a configurable detection that can be performed during inline analysis.\nThe default behavior if this feature is enabled and malware is found is to consider the scanning failed, report malware details, and abort analysis:\nSee Perform Inline Malware Scanning for recommended parameters and output options.\n","url":"https://docs.sysdig.com/en/release-notes/sysdig-on-premises-release-notes/2021-archive/"},{"id":161,"title":"Identity","content":"PrerequisitesAWSWhen your AWS accounts are successfully connected to Sysdig Secure with Advanced CIEM, Sysdig detects and analyzes the policies, roles, users, and groups you\u0026rsquo;ve configured in AWS for identity and access weak points and proposes remediation steps.\nConnect a Cloud Account for AWS Installed with Terraform or CloudFormation Template\nThese enable Threat Detection for Cloudtrail, which is required for Advanced CIEM to work with AWS Either installation automatically creates a required Identity Access Management (IAM) role, which gives Sysdig read-only access to your AWS resources.\nTerraform role name: sfc-cloudbench CFT role name: SysdigComplianceAgentlessRole Adequate AWS permissions to read policies related to users, roles, and access. GCPWhen your GCP accounts are successfully connected to Sysdig Secure with Advanced CIEM, the policies, roles, users, groups, and service accounts you\u0026rsquo;ve configured in GCP are detected and analyzed for identity and access weak points, and Sysdig proposes remediation steps.\nSee Connect a Cloud Account for GCP.\nAzureWhen your Azure accounts are successfully connected to Sysdig Secure with Advanced CIEM, the users, roles, policies, groups, and service accounts you\u0026rsquo;ve configured in Azure are detected and analyzed for identity and access weak points, and Sysdig proposes remediation steps.\nSee Connect a Cloud Account for Azure.\nUnderstand IdentityIn Sysdig Secure, Identity works together with Compliance to highlight user-focused and resource-focused risks.\nThe interfaces highlight risk from different focal points:\nIAM Policies: (AWS only) This page highlights critical risks organized by IAM policies. The detail drawers recommend policy optimizations to remove those risks. Optimization affects the entire policy. Users: This page highlights critical risks organized by individual users, focusing on unused permissions and inactive users. The detail drawers suggest remediation strategies, such as removing an inactive user, and present policy optimization changes. Optimization affects only the targeted user. Roles: This page highlights critical risks organized by role, focusing on unused permissions and unused roles. The detail drawers suggest remediation strategies for inactive or over-privileged roles, and present policy optimization changes. Optimization affects only the targeted role. Groups: This page highlights critical risks organized by group, focusing on unused permissions and unused groups. The detail drawers suggest remediation strategies, such as removal, for inactive groups and present policy optimization changes. Optimization only affects the targeted group. Service Identities This page highlights the risks associated with your GCP service accounts and Azure service principals. The detail drawers offer remediation strategies and show connected IAM resources. Use the Details DrawerIn any of the Identity pages, select an entity to open the details drawer on the right. Here, you will find key information about the entity. To learn more, navigate the available tabs:\nSummary: Key information about the entity, such as the associated account ID, and an overview of its permission criticality. You can also view risky permissions, identified on the basis of their potential for misuse if an identity is compromised. Remediation Strategies: View and apply suggestions to reduce the permission criticality of an entity. Possible actions might be to reduce the number of permissions granted to an inactive user or group. Connected IAM Resources: View other IAM Resources, such as users, groups and roles, that are connected to the entity you are examining. Configuration: (Only available in the IAM Policies page) View, copy or download the policy configuration in JSON. Understanding Permission Criticality ScoringPermissions are the primary determinant of Permission Criticality in IAM. If no permissions are tracked, the value for Unused Permission Criticality is n/a. Permission Criticality Scores range in the following order of severity: Critical, High, Medium, Low.\nPermission Criticality ScoresPermission Criticality Scores for Permission Criticality are determined by the most critical permissions given by a policy. For example, a policy with at least one permission allowing a Critical action is given a Critical Permission Criticality Score.\nUnused Permission CriticalityUnused Permission Criticality focuses on unused permissions, while Permission Criticality looks at all permissions. Unused Permission Criticality is designed to help you achieve the least permissive access.\nNote: The Unused Permission Criticality and Permission Criticality scores can differ if there are Used permissions with higher scores than Unused.\nUnderstand the Suggested Policy ChangesThe Sysdig CIEM may prompt you to optimize policies in different ways.\nOptimize an AWS Policy Globally: You can create an optimized policy to replace an existing policy. This \u0026ldquo;global\u0026rdquo; change affects all associated IAM entities (users, roles, groups).\nUse the Optimize IAM Policy button on an IAM Policy tab or page. See example.\nCreate Entity-Specific Optimized Policy: You can create a new, entity-specific policy that applies only to a user, role, or group. This \u0026ldquo;local\u0026rdquo; change affects the policies the IAM entity is associated with but does not replace the original policy.\nUse the Optimize IAM Policy button on a User, Role, or Group Detail Overview. See an example.\nDelete: Sysdig may detect a policy that has not been used by any IAM entity. It will recommend removing this policy from your AWS environment.\nUnderstand Highest AccessHighest Access offers a quick way to filter by Access Category. It shows this identity entity\u0026rsquo;s highest level of access according to all of its permissions. The categories are:\nAdmin: Actions that match certain patterns related to permissions or administrative controls, such as account/organization management, are categorized as Admin. Write: Actions that modify data are categorized as Write. This includes subcategories like Write/Delete,Write/Create. Read: Actions that allow one to view data are categorized as Read. This includes subcategories like List, Read, Action, Tagging. Empty Access: Either no policies are attached, or a policy is attached with zero permissions. Understand Risky PermissionsThe Identity detail drawer highlights permissions flagged as risky by the Sysdig Threat Research team. Risky permissions are identified based on their potential for misuse if an identity is compromised.\nEach flagged permission is accompanied by usage insights and links to relevant sources, such as associated Policies or Roles, making it easier to investigate and act. Open the detail drawer, hover over the Source column, and click Owner to examine the specific role in question. In the new Owner detail drawer that opens, you will see options for remediation actions. To proceed, click the Remediation Strategies tab in the Owner detail drawer.\u0026quot;\nUnderstand Remediation StrategiesThe Sysdig CIEM offers the following remediation strategies:\nDetach the role: All the roles that are totally unused by the selected identity will get this recommendation. If there are multiple unused roles, they are sorted by greatest reduction in unused permissions. Consolidate and Reduce Permissions: This recommendation is aimed at consolidating and reducing permissions associated with an identity. Sysdig evaluates all actions taken by the identity across their roles and consolidates them into a single, group-specific custom role. Only one custom role suggestion is provided per identity. Reduce Permissions with Existing Roles: You will receive recommendations corresponding to the number of attached roles. If an existing role encompasses all the permissions of the current role but has fewer total permissions, the user will be advised to replace it. If the users haven\u0026rsquo;t utilized any permissions, they will only receive a recommendation to detach the role. In cases where multiple replacement recommendations exist, they will be sorted by the greatest reduction in unused permissions. ","url":"https://docs.sysdig.com/en/sysdig-secure/identity/"},{"id":162,"title":"Identity Overview","content":"Access the OverviewTo access the Identity Findings dashboard, log in to Sysdig Secure and navigate to Attack Surface \u0026gt; Identity Findings from the left navigation bar.\nThis documentation reflects the Identity Findings page as it appears with Advanced CIEM enabled. If you’re using Basic CIEM, panels based on observed entitlement usage will not be available.\nHighlightsThe Identity Findings dashboard is designed for rapid identification of:\nThe overall scope of severe identity risks in your environment. Your adherence to least privilege principles through unused permissions. Trends in identity hygiene issues and the effectiveness of your remediation efforts. The most critical misconfigurations and risky access patterns across various identity types. It provides quick insights into your worst identity problems, enabling you to streamline remediation and enhance your cloud security posture.\nInteractive Behavior and Filtering Clicking on panels or rows within tables (for example, a specific finding type in Top Critical \u0026amp; High Severity Findings or a user in Users with Most Unused Permissions) will navigate you to the Identity Findings page with filters automatically applied to match your selection. This allows for immediate drill-down into the details relevant to your area of interest. The dashboard can be filtered globally using the options in the upper-left corner: Zone: Filter data by one or more Zones, which are logical groupings of resources such as accounts, clusters, or applications. Platform: Filter by specific cloud platforms (for example, AWS, Azure, GCP). Observed \u0026gt; 90 Days: This filter helps you focus on identities that have been observed by Sysdig Secure for a minimum of 90 days. Filtering for observed identities helps ensure that the least privilege recommendations are based on a sufficient period of activity profiling, providing higher confidence in the insights. Dashboard PanelsThe Identity Findings dashboard is organized into several sections, each providing insights into different aspects of your identity security posture.\nOverall Posture MetricsThese panels provide a high-level summary of your most critical identity findings and unused permissions across the environment.\nPanel Description Critical \u0026amp; High Severity Findings Critical \u0026amp; High Severity Findings is the total number of urgent Identity hygiene issues. Use this to assess the overall scope of severe identity risks. Note: This data point is the most current count from your latest scan. This number will update as scans complete. Average Unused Permissions Average Unused Permissions is the average percentage of excessive permissions across all identities. Use this to evaluate overall adherence to least privilege principles. Average Unused Permissions (Last 30 Days) Average Unused Permissions (Last 30 Days) shows the trend of excessive permissions over time. Use this to monitor progress in reducing over-permissioned identities. Critical \u0026amp; High Severity Findings (Last 30 Days) Critical \u0026amp; High Severity Findings (Last 30 Days) shows the trend of severe identity hygiene issues over time. Use this to track changes in severe findings and evaluate remediation efforts. Top Critical \u0026amp; High Severity Findings Top Critical \u0026amp; High Severity Findings shows the most common urgent identity hygiene issues. Use this to identify and prioritize the most critical misconfiguration. Columns: Finding type, Severity, # findings. Unused PermissionsThese tables highlight identities with excessive permissions, helping you prioritize least privilege refinement efforts.\nUnused Permissions Description Columns Users with Most Unused Permissions Lists IAM users with the highest percentages of unused permissions. Use this to identify users for access rights cleanup. User nameZonesContextUnused Permission Criticality (sortable)% of Unused Permissions (sortable) Roles with Most Unused Permissions Lists IAM roles with the highest percentages of unused permissions. Use this to refine over-permissioned roles. Role nameZonesContextUnused Permission Criticality (sortable)% of Unused Permissions (sortable) Groups with Most Unused Permissions Lists IAM groups with the highest percentages of unused permissions. Use this to refine group-level access and reduce excessive permissions. Group nameZonesContextUnused Permission Criticality (sortable)% of Unused Permissions (sortable)Membership Service Identities with Most Unused Permissions Lists service identities with the highest percentages of unused permissions. Use this to refine automated account access and enforce least privilege. Service Identity nameZonesContextUnused Permission Criticality (sortable)% of Unused Permissions (sortable) IAM Policies with Most Unused Permissions Lists policies with the highest percentages of excessive permissions. Use this to target policies for least privilege refinement. Policy nameZonesContextUnused Permission Criticality (sortable)% of Unused Permissions (sortable)Policy TypeShared Identity Hygiene SectionThese panels help you identify and manage various identity hygiene issues, reducing the attack surface.\nPanel Description Columns Longest Inactive Users Longest Inactive Users lists users with the longest periods of inactivity. Use this to identify stale accounts and reduce exposure to compromise. Cloud IAM UserPlatformDays inactive (sortable) Inactive Identities by Resource Family Inactive Identities by Resource Family shows a breakdown of inactive identities by resource family. Use this to identify dormant accounts and improve lifecycle hygiene. Visualization: Donut chart of Inactive Identities (split by Groups/Roles/Users/Service Accounts), showing count by identity type. Key Management Findings Key Management Findings summarizes issues related to access key misconfiguration. Use this to mitigate risks from exposed or improperly managed access keys. Finding TypeSeverity ","url":"https://docs.sysdig.com/en/sysdig-secure/identity/overview/"},{"id":163,"title":"IP Allowlist","content":"On IP Allowlist page, you can:\nEnable/disable the IP Allowlist feature globally Add new IP addresses or IP ranges View the list of already configured IP addresses and IP ranges Modify or delete existing IP address or IP range Enable/disable the individual IP address or IP range If misconfigured, this feature will cause you to lose access to Sysdig! Review this page carefully before you configure the feature.\nIf, however, you do run into issues and find yourself unable to access Sysdig as a result of using this feature, Contact Sysdig Support.\nPrerequisitesPermission to access IP Allowlist is only available to Admin users by default.\nYou can also add permission manually to a custom role. See Manage Custom Roles.\nAccess IP AllowlistTo access IP Allowlist:\nSign in to Sysdig Secure or Sysdig Monitor with the required permissions. See Prerequisites\nSelect Settings \u0026gt; IP Allowlist via the user menu.\nThe IP Allowlist page opens.\nAdd an IP Address or IP RangeTo add a new IP address or IP range:\nAccess the IP Allowlist page.\nSelect the option Add IP from the top right of the screen.\nThe IP Configuration page appears.\nSee Configure an IP.\nModify an IP Address or IP RangeTo modify an existing IP Address or IP range:\nAccess the IP Allowlist page.\nOn the IP Allowlist page, hover over an IP address or IP range listing.\nOn the rightmost side of the row with the IP address or IP range you want to modify, select the three-dot menu icon.\nSelect Edit.\nThe IP Configuration page appears.\nSee Configure an IP.\nConfigure an IPThe screen for adding and modifying the IP address or IP range is the same, but is accessed differently depending on the action you want to perform:\nOnce you add an IP, or select Edit on an existing IP, the IP configuration page appears.\nYou can configure the following parameters:\nEnabled: Use the toggle to select if the IP address or IP range be enabled. You can\u0026rsquo;t disable the IP address or IP range when creating a new one. IP address or range: Enter an IP address or IP range in CIDR notation. Notes: Add an optional note to help you identify the IP address or IP range. Once you configured the IP address or IP range, select the Save option from the top right of the page to save the changes.\nIf there are any errors, the page will inform you and allow you to rectify them.\nEnable and Disable IP Allowlist GloballyOnce you have added the list of IP addresses or IP ranges from which you want to allow access to Sysdig, you can enable the feature.\nEnsure that the IP range from which you are accessing the system is included. Once the feature is enabled, it will block access from any IP ranges that are not listed.\nTo assist you, the Your IP section on the IP Allowlist page includes the IP address currently being used to access Sysdig.\nTo enable the feature globally, select the option Enable IP Allowlist at the top of the IP Allowlist page.\nTo disable the feature globally, select the same button, which reads Disable IP Allowlist when enabled globally.\n","url":"https://docs.sysdig.com/en/administration/ip_allow_list/"},{"id":164,"title":"Jira Ticketing","content":"This integration works for both Jira Cloud (SaaS) and Jira Data Center (On-Prem).\nConfigure Jira Ticketing IntegrationPrerequisites Admin access to Sysdig Secure.\nA Jira Cloud or Data Center account with the appropriate permissions.\nThe latest Jira Data Center supported version is 10. A Jira API Token.\nLog in to your Jira account and generate the API token from Atlassian.\nThe API token must be created by the same User you input when creating a new Jira Ticketing Integration. The best practice is to set up the integration with a service account email rather than an individual\u0026rsquo;s email. Required PermissionsThe Administrator with the Jira API token who is setting up the integration must have the following:\nPermission to access Jira. Administrator Jira global permissions, or at least: Permissions to create issues in the Jira project associated with Sysdig. Permissions to create attachments in the Jira project associated with issues coming from Sysdig. If a Jira administrator sets ups the integration, the Sysdig Secure UI will reflect Jira status updates in real time.\nIf a non-administrator Jira user sets up the integration, changes in Jira may take up to an hour to be reflected in the Secure UI.\nThe Sysdig user who will create tickets in the UI must have one of the following:\nAdminister Jira global permission Browse Projects permission for the Jira project associated with Sysdig Administer Projects permission for the Jira project associated with Sysdig Set Up Jira IntegrationTo set up a ticketing integration with Jira:\nLog in to Sysdig Secure as an administrator.\nNavigate to Integrations \u0026gt; Ticketing.\nSelect New Integration.\nThe Connect Jira Account window appears.\nSpecify the following:\nIntegration Name: Choose any name for the integration. Atlassian URL: Your Jira account URL, in the format https://myaccount.atlassian.net. For example, https://sysdig.atlassian.net. Email: The email address of the API token holder, which matches the email used in the Jira Cloud or Data Center account. API Token: The Jira token you have generated. Follow the links in the wizard if you do not have a token. Certificate: Optionally, select a client certificate to enable mTLS between Sysdig and your Jira Data Center instance. Not applicable to Jira Cloud. Click Next and in Customize Project Settings tab specify the following:\nProject: Select your project from the dropdown. Issue Types: Select at least one issue type to use for this integration. Teams: Choose between two options. Select Teams: Apply this integration to particular teams, chosen from the drop-down. All Teams: Apply this integration to all teams on your account. Jira Assignee: Optionally, select the default assignee(s). Labels: Optionally, select labels for the tickets. Click Next.\nOptionally, assign custom field to the appropriate issue type in the Select Custom Fields tab.\nClick Next to save your configuration.\nThe Jira integration will be listed on the Ticketing Integration page with an Active status.\nIf you completed setup as a Jira administrator, a webhook named sysdig-jira-integration-webhook is created in your Jira server. This webhook updates Sysdig whenever a change is made to a ticket in the project you integrated.\nDo not delete this webhook, as this may lead to slower refresh rates.\nTest the IntegrationTo use the integration, open the Sysdig Secure Home page and check the Vulnerability Management (VM) Remediation recommendations, as described in Remediate with Jira.\nJira Platform TicketingTicket Types and TemplatesThe type of ticket created depends on where in the application you trigger the action and the filters or groupings you have selected.\nIn the Vulnerability Program Owner Flows view:\nwith no grouping selected, each row represents a single finding. Creating a ticket from this view generates an individual finding ticket, which also includes details about the affected resource. with Runtime Resource grouping selected, each row represents a resource with all of its findings (based on the applied filters). Creating a ticket from this view generates a resource ticket that aggregates all findings for that resource. Finding TicketsA finding is a single issue (for example, a vulnerability or control failure) on a single resource. When you create a finding ticket, additional information is added in the Jira issue, including:\nCVE description Links to related resources Remediation guidance Example of a finding ticket in Jira: Resource TicketsA resource is a unique running asset that may have one or more findings. When you create a resource ticket, additional details about the resource are included, such as:\nResource type and name Labels Associated findings Sysdig also attaches a CSV and/or PDF to the Jira issue with a full findings report.\nExample of a resource ticket in Jira: Ticket WorkflowTicket CreationTickets are created with the information available at the time of creation. Updates to resources (such as new labels, new findings, or resolved findings) are not automatically synced.\nFrom Program Finding Pages Select one or more rows to create tickets. With no grouping selected, each ticket is a finding ticket. With grouping selected, each ticket is a resource ticket, with findings included based on the current filters. From a Resource or Finding Drawer From the Resource drawer, you can create a ticket with all findings for that resource. From the Findings drawer, you can create a ticket scoped to that finding. From a Risk ViewCreate a Finding Ticket from a RiskWhen you create a ticket from a Risk view, Sysdig creates a Finding Ticket.\nA finding ticket represents one security finding on one resource and can be tracked individually across the UI.\nAccess and scope Navigate to Risk. Select a Risk Definition, then select a Risk Finding. For each unique combination of a finding and its anchor resource, Sysdig creates one ticket. Create a finding ticket From the selected Risk Finding, click Create Ticket. The Create Finding Ticket window appears. Review the ticket summary: 1 Finding Ticket will be created. Ticket Content includes 1 resource and 1 risk finding. Complete the required fields: Project: Select the destination project. Issue Type: Select the issue type (for example, Task, Epic, or Subtask). Labels: Select one or more labels. Assignee: Assign the ticket to a user. Reporter: Select the reporter. Due Date: Select the target completion date. Click Create. The ticket is created in the selected project and linked to the corresponding risk finding.\nTicket UpdatesSysdig does not update tickets automatically. However, if a ticket is closed in Jira, the updated status is reflected in Sysdig.\nTicket IndicatorsTicket indicators help you track issues directly in Sysdig:\nFinding indicator → shown on the finding if a ticket exists. Resource indicator → shown on the resource and all findings included in the ticket. Hover over the ticket icon to view the Jira issue and its current status.\n","url":"https://docs.sysdig.com/en/sysdig-secure/integrations-jira-ticketing/"},{"id":165,"title":"Use Labels","content":"Labels can be used in different ways:\nTo group infrastructure objects into logical hierarchies displayed in Explore (called groupings).\nFor more information, see Groupings.\nTo split aggregated data into segments.\nFor more information, see Segments.\nThere are two types of labels:\nInfrastructure labels\nMetric descriptor labels\nInfrastructure LabelsInfrastructure labels are used to identify objects or entities within the infrastructure that a metric is associated with, including hosts, containers, and processes. An example label is shown below:\nSysdig Notationkubernetes.pod.name Prometheus Notationkubernetes_pod_name The table below outlines what each part of the label represents:\nExample Label Component Description kubernetes The infrastructure type. pod The object. name The label key. Infrastructure labels are obtained from the infrastructure (including from orchestrators, platforms, and the runtime processes), and Sysdig automatically builds a relationship model using the labels. This allows users to create logical hierarchical groupings to better aggregate the infrastructure objects in the Explore module.\nFor more information on groupings, refer to the Groupings.\nMetric Descriptor LabelsMetric descriptor labels are custom descriptors or key-value pairs applied directly to metrics, obtained from integrations like StatsD, Prometheus, and JMX. Sysdig automatically collects custom metrics from these integrations and parses the labels from them. Unlike infrastructure labels, these labels can be arbitrary and do not necessarily map to any entity or object.\nMetric descriptor labels can only be used for segmenting, not grouping or scoping.\nAn example metric descriptor label is shown below:\nwebsite_failedRequests:20|region=\u0026#39;Asia\u0026#39;, customer_ID=\u0026#39;abc\u0026#39; The table below outlines what each part of the label represents:\nExample Label Component Description website_failedRequests The metric name. 20 The metric value. region=\u0026lsquo;Asia\u0026rsquo;, customer_ID=\u0026lsquo;abc\u0026rsquo; The metric descriptor labels. Multiple key-value pairs can be assigned using a comma-separated list. Sysdig recommends not using labels to store dimensions with high cardinalities (numerous different label values), such as user IDs, email addresses, URLs, or other unbounded sets of values. Each unique key-value label pair represents a new time series, which can dramatically increase the amount of data stored.\nGroupingsGroupings are hierarchical organizations of labels, allowing you to organize your infrastructure views in Explore in a logical order.\nTo access Groupings from Explore:\nSelect the name of the current grouping in the top left corner.\nThe Grouping drop-down will open.\nClick + beside My Groupings.\nThe Groupings Panel will open.\nHere, you can add a new grouping, create custom groupings, and see a preview.\nThe example above groups the infrastructure into four levels. This results in a tree view in the Explore module with four levels, with rows for each infrastructure object applicable to each level.\nAs each label is selected, Sysdig Monitor automatically filters out labels for the next selection that no longer fit the hierarchy, to ensure that only logical groupings are created.\nThe example below shows the logical hierarchy structure for Kubernetes:\nClusters: Cluster \u0026gt; Namespace \u0026gt; Replicaset \u0026gt; Pod\nNamespace: Cluster \u0026gt; Namespace \u0026gt; HorizontalPodAutoscaler \u0026gt; Deployment \u0026gt; Pod\nDaemonsets : Cluster \u0026gt; Namespace \u0026gt; Daemonsets \u0026gt; Pod\nServices: Cluster \u0026gt; Namespace \u0026gt; Service \u0026gt; StatefulSet \u0026gt; Pod\nJob: Cluster \u0026gt; Namespace \u0026gt; Job \u0026gt; Pod\nReplicationController: Cluster \u0026gt; Namespace \u0026gt; ReplicationController \u0026gt; Pod\nThe default groupings are immutable: They cannot be modified or deleted. However, you can make a copy of them that you can modify.\nUnified Workload LabelsSysdig provides the following labels to help improve your infrastructure organization and troubleshooting easier.\nkubernetes_workload_name: Displays all the Kubernetes workloads and indicates what type and name of workload resource (deployment, daemonSet, replicaSet, and so on) it is.\nkubernetes_workload_type: Indicates what type of workload resource (deployment, daemonSet, replicaSet, and so on) it is.\nThe availability of these labels also simplifies Groupings. You do not need different groupings for each type of deployment, instead, you have a single grouping for workloads.\nThe labels allow you to segment metrics, such as sysdig_host_cpu_cores_used_percent , by kubernetes_workload_name to see CPU cores usage for all the workloads, instead of having a separate query for segmenting by kubernetes_deployment_name, kubernetes_replicaSet_name , and so on.\nScopesA scope is a collection of labels that are used to filter out or define the boundaries of a group of data points when creating dashboards, dashboard panels, alerts, and teams. An example scope is shown below:\nIn the example above, the scope is defined by two labels with operators and values defined. The table below defines each of the available operators.\nOperator Description is The value matches the defined label value exactly. is not The value does not match the defined label value exactly. in The value is among the comma-separated values entered. not in The value is not among the comma-separated values entered. contains The label value contains the defined value. does not contain The label value does not contain the defined value. starts with The label value starts with the defined value. The scope editor provides dynamic filtering capabilities. It restricts the scope of the selection for subsequent filters by rendering valid values that are specific to the previously selected label. Expand the list to view unfiltered suggestions. At run time, users can also supply custom values to achieve more granular filtering. The custom values are preserved. Note that changing a label higher up in the hierarchy might render the subsequent labels incompatible. For example, changing the kubernetes_namespace_name \u0026gt; kubernetes_deployment_name hierarchy to swarm_service_name \u0026gt; kubernetes_deployment_name is invalid as these entities belong to different orchestrators and cannot be logically grouped.\nDashboards and PanelsDashboard scopes define the criteria for what metric data will be included in the dashboard\u0026rsquo;s panels. To see a dashboard\u0026rsquo;s scope, select it from the Dashboards module. The current dashboard\u0026rsquo;s scope can be seen at the top of the dashboard:\nIn this example, the scope is Team Scope.\nBy default, all dashboard panels abide by the scope of the overall dashboard. However, an individual panel scope can be configured for a different scope than the rest of the dashboard.\nAlertsYou can define an alert scope when you create an alert, or you can edit the scope of an exiting alert.\nBy default, the scope will conform to your Team Scope. Select Team Scope to specify the scope further by adding more labels.\nTeamsA team\u0026rsquo;s scope determines the highest level of data that team members have visibility for:\nIf a team\u0026rsquo;s scope is set to Host, team members can see all host-level and container-level information.\nIf a team\u0026rsquo;s scope is set to Container, team members can only see container-level information.\nA team’s scope only applies to that team. Users that are members of multiple teams may have different visibility depending on which team is active.\nFor more information on teams and configuring team scope, refer to the Manage Teams and Roles documentation.\nSegmentsAggregated data can be split into smaller sections by segmenting the data with labels. This allows for the creation of multi-series comparisons and multiple alerts. In the first image, the metric is not segmented:\nIn the second image, the same metric has been segmented by container_id:\nLine and Area panels can display any number of segments for any given metric. The example image below displays the sysdig_connection_net_in_bytes metric segmented by both container_id and host_hostname:\nFor more information regarding segmentation in dashboard panels, refer to the Configure Panels documentation. For more information regarding configuring alerts, refer to the Alerts documentation.\nCardinalityCardinality refers to the number of unique time series associated with a given metric. As each combination of labels and label values yields a single time series, all such combinations are counted for a metric, and the number is represented on the Metrics Usage UI.\nConsider calculating the total number of time series for the container_spec_cpu_period metric, which is represented in PromQL as follows:\ncount(container_spec_cpu_period{}) This query counts all the combinations for labels and label values associated with container_spec_cpu_period. For example:\nTime series 1: container_spec_cpu_period {_sysdig_datasource=\u0026quot;agent\u0026quot;,job=\u0026quot;k8s-cadvisor-default\u0026quot;} Time series 2: container_spec_cpu_period {_sysdig_datasource=\u0026quot;agent\u0026quot;,job=\u0026quot;kubernetes-nodes-cadvisor\u0026quot;} Time series 3: container_spec_cpu_period {_sysdig_datasource=\u0026quot;remote write\u0026quot;,job=\u0026quot;kubernetes-nodes-cadvisor\u0026quot;} Time series 4: container_spec_cpu_period {_sysdig_datasource=\u0026quot;remote write\u0026quot;,job=\u0026quot;custom-prom-job\u0026quot;} The Meaning of n/aThe term n/a can appear anywhere on the UI where some form of data is displayed. The term n/a indicates data that is not available or that it does not apply to a particular instance. In Sysdig parlance, the term signifies one or more entities defined by a particular label, such as hostname or Kubernetes service, for which the label is invalid. In other words, n/a collectively represents entities whose metadata is not relevant to aggregation and filtering techniques—Grouping, Scoping, and Segmenting. For instance, a list of Kubernetes services might display the list of all the services as well as n/a that includes all the containers without the metadata describing a Kubernetes service.\nYou might encounter n/a sporadically in Explore UI as well as in drill-down panels or dashboards, events, and likely elsewhere on the Sysdig Monitor UI when no relevant metadata is available for that particular display. How n/a should be treated depends on the nature of your deployment. The deployment will not be affected by the entities marked n/a.\nThe following are some of the cases that yield n/a on the UI:\nLabels are partially available or not available. For example, a host has entities that are not associated with a monitored Kubernetes deployment, or a monitored host has an unmonitored Kubernetes deployment running.\nLabels that do not apply to the grouping criteria or at the hierarchy level. For example:\nContainers that are not managed by Kubernetes. The containers managed by Kubernetes are identified with their container_name labels.\nIn certain groupings by DaemonSet, Deployments render N/A and vice versa. Not all containers belong to both DaemonSet and Deployment objects concurrently. Likewise, a Kubernetes ReplicaSet grouping with the kubernetes_replicaset_name label will not show StatefulSets.\nIn a kubernetes_cluster_name \u0026gt; kubernetes_namespace_name \u0026gt; kubernetes_deployment_name grouping, the entities without the kubernetes_cluster_name label yield n/a.\nEntities are incorrectly labeled in the infrastructure.\nKubernetes features that are yet to be in sync with Sysdig Monitoring.\nThe format is not applicable to a particular record in the database.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/use-labels/"},{"id":166,"title":"Install Sysdig CLI Scanner for Pipeline Scanning","content":"DeploymentThe sysdig-cli-scanner is a binary you can download and execute locally on your computer or environment.\nDownload latest version of sysdig-cli-scanner with: Linux:\nIntel Processor (AMD64)\ncurl -LO \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/linux/amd64/sysdig-cli-scanner\u0026#34; ARM Processor (ARM64)\ncurl -LO \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/linux/arm64/sysdig-cli-scanner\u0026#34; MacOS:\nIntel Processor (AMD64)\ncurl -LO \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/darwin/amd64/sysdig-cli-scanner\u0026#34; Apple Silicon (M1, M2) Processor (ARM64)\ncurl -LO \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/darwin/arm64/sysdig-cli-scanner\u0026#34; Optionally, you can check the sha256sum as:\nLinux:\nIntel Processor (AMD64)\nsha256sum -c \u0026lt;(curl -sL \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/linux/amd64/sysdig-cli-scanner.sha256\u0026#34;) ARM Processor (ARM64)\nsha256sum -c \u0026lt;(curl -sL \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/linux/arm64/sysdig-cli-scanner.sha256\u0026#34;) MacOS:\nIntel Processor (AMD64)\nshasum -a 256 -c \u0026lt;(curl -sL \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/darwin/amd64/sysdig-cli-scanner.sha256\u0026#34;) Apple Silicon (M1, M2) Processor (ARM64)\nshasum -a 256 -c \u0026lt;(curl -sL \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-cli-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-cli-scanner/latest_version.txt)/darwin/arm64/sysdig-cli-scanner.sha256\u0026#34;) Set the executable flag on the file:\nchmod +x ./sysdig-cli-scanner You only need to download and set executable once. Then:\nYou can scan images or IaC resources by running the sysdig-cli-scanner command:\nFor VM mode:\nSECURE_API_TOKEN=\u0026lt;your-api-token\u0026gt; ./sysdig-cli-scanner --apiurl \u0026lt;sysdig-api-url\u0026gt; \u0026lt;image-name\u0026gt; For IaC mode:\nSECURE_API_TOKEN=\u0026lt;your-api-token\u0026gt; ./sysdig-cli-scanner --iac --apiurl \u0026lt;sysdig-api-url\u0026gt; \u0026lt;PathsToScan\u0026gt; Next StepsContinue with one of the following:\nRun sysdig-cli-scanner in VM mode.\nRun sysdig-cli-scanner in IaC mode.\nBuild and run sysdig-cli-scanner with a Custom Container Image\n","url":"https://docs.sysdig.com/en/sysdig-secure/install-vulnerability-cli-scanner/"},{"id":167,"title":"Scheduled Reports","content":"The Schedules page lets you review, create, edit, enable and disable report schedules.\nAccess SchedulesTo access Schedules:\nLog in to Sysdig Secure.\nSelect Reporting \u0026gt; Scheduled Reports.\nThe Schedules page appears.\nReview SchedulesOn the Schedules page, you can see a list of schedules associated with your account.\nYou can find specific reports with the search bar and the drop-down list.\nFor each report schedule listed, you can see:\nA toggle to enable or disable the schedule. Name: The name of the schedule. Reports included: Which report the schedule creates. Frequency: How often the report is generated. Last Completed: When this report schedule last created a report. Click the three-dot icon beside any report schedule to View History for the report.\nSelect any schedule listing to edit the schedule. See Configure a Schedule.\nCreate a ScheduleTo create a schedule:\nLog in to Sysdig Secure.\nSelect Reporting \u0026gt; Scheduled Reports.\nSelect Reporting \u0026gt; Scheduled Reports.\nThe Schedules page appears.\nSelect New Schedule from the top right corner. The New Schedule page appears.\nFill out the configuration details. See Configure a Schedule. Configure a ScheduleYou can access the Schedule configuration page when you create a new schedule, or you edit an existing schedule. Here, you can configure the following:\nReport: Choose an existing report or create a new one. If existing, use the drop-down menu to choose. If creating a new report, choose from among: Kubernetes Workload Vulnerability Findings ECS Workload Vulnerability Scans Kubernetes Vulnerability Dashboard Policy Compliance Report ECS Workload Vulnerability Findings Registry Vulnerability Findings Host Vulnerability Findings Container Pipeline Vulnerability Scans Container Vulnerability Findings Resource Post Report (Legacy) Container Pipeline Vulnerability Findings Resource Posture Report Runtime Host Vulnerability Scanning Zones: Select all or one or more specific zones. If you choose to change the zone scope, you can update it the report, which will affect all associated schedules. Or create a new report without affecting any associated schedules. Report: Choose an existing report or create a new one. If existing, use the drop-down menu to choose. If creating a new report, choose from among: Kubernetes Workload Vulnerability Findings ECS Workload Vulnerability Scans Kubernetes Vulnerability Dashboard Policy Compliance Report ECS Workload Vulnerability Findings Registry Vulnerability Findings Host Vulnerability Findings Container Pipeline Vulnerability Scans Container Vulnerability Findings Resource Post Report (Legacy) Container Pipeline Vulnerability Findings Resource Posture Report Runtime Host Vulnerability Scanning Zones: Select all or one or more specific zones. If you choose to change the zone scope, you can update it the report, which will affect all associated schedules. Or create a new report without affecting any associated schedules. Name: The name of the schedule. Description: Enter any descriptive text for the schedule. Frequency \u0026amp; Timeframe: Select how often a schedule should run: daily, weekly or monthly. Daily: Select which time of day the report should run (for example, 12:00 AM, 1:30 PM). Weekly: Select which day of the week and time the report should run. Monthly: The the day (1st, 15th, Last Day) and time Data: Select whether the report uses your local timezone or UTC. The time range of the data included depends on the frequency: Daily: The report includes data from the previous 24 hours leading up to the scheduled run time. Example 1: A report scheduled for 12:00 AM (midnight) will generate data from the entire previous calendar day (12:00 AM to 11:59 PM). Example 2: A report scheduled for 1:00 PM will generate data from the previous day at 1:00 PM until the current day at 12:59 PM. Weekly: The report includes data from the previous 7 days leading up to the 12:00 AM (midnight) run time. Example: A report scheduled for Sunday (which runs at 12:00 AM Sunday) will include data from the previous Sunday at 12:00 AM until Saturday at 11:59 PM. For Policy Compliance Reports, the report only includes live data at the time of the report being generated, not the full 7 days. Monthly: The report includes data from the entire previous calendar month. Example: The report runs at 12:00 AM on March 1st and includes all data from February 1st at 12:00 AM until February 28th (or 29th) at 11:59 PM. For Policy Compliance Reports, the report only includes live data at the time of the report being generated, not the full previous month. Notifications: Optional: Select a notification channel if you wish to be notified when a report is created by a schedule, and ready to be downloaded. The available channels are Email and Slack. To create a notification channel, see Set Up Notification Channels. Format: Select the format for you report. PDF is the default. JSON and CSV are only available when the report is a single table. Compression Format: Select the format compression for your report. Gzip (.gz) and Zip (.zip) are supported. Password Protection: Optionally, toggle this on to set a password on the report PDF that is created. Be sure to remember your password, as it cannot be reset once the report is created. This is supported for zip files, but is not supported for Gzip files. Delete a ScheduleTo delete a schedule:\nLog in to Sysdig Secure.\nSelect Reporting \u0026gt; Scheduled Reports.\nThe Schedules page appears.\nSelect the three-dot icon of the schedule you wish to delete.\nSelect Delete.\n","url":"https://docs.sysdig.com/en/sysdig-secure/reporting/scheduled-reports/"},{"id":168,"title":"(Legacy) Working with Prometheus Metrics","content":"Latest Prometheus FeaturesSysdig agents v12.0 or above is required for the following capabilities:\nMonitoring Integrations Sysdig agents v10.0 or above is required for the following capabilities:\nNew capabilities of using Prometheus data:\nAbility to visualize data using PromQL queries. See Using PromQL.\nCreate alerts from PromQL-based Dashboards. See Create Panel Alerts.\nBackward compatibility for dashboards v2 and alerts.\nThe new PromQL data cannot be visualized by using the Dashboard v2 Histogram. Use time-series based visualization for the histogram metrics.\nNew metrics limit per agent\n10-second data granularity\nHigher retention rate on the new metric store.\nPrerequisites and Guidelines Sysdig agent v 10.0.0 and above is required for the latest Prometheus features.\nPrometheus feature is enabled in the dragent.yaml file.\nprometheus: enabled: true See Setting up the Environment for more information.\nThe endpoints of the target should be available on a TCP connection to the agent. The agent scrapes a target, remote or local, specified by the IP: Port or the URL in dragent.yaml.\nService DiscoveryTo use native Prometheus service discovery, enable Promscrape V2 as described in Enable Prometheus Native Service Discovery. This section covers the Sysdig way of service discovery that involves configuring process filters in the Sysdig agent.\nThe way service discovery works in the Sysdig agent differs from that of the Prometheus server. While the Prometheus server has built-in integration with several service discovery mechanisms and the prometheus.yml file to read the configuration settings from, the Sysdig agent auto-discovers any process (exporter or instrumented) that matches the specifications in the dragent.yaml, file and instructs the embedded lightweight Prometheus server to retrieve the metrics from it.\nThe lightweight Prometheus server in the agent is named promscrape and is controlled by the flag of the same name in the dragent.yaml file. See Configuring Sysdig Agent for more information.\nUnlike the Prometheus server that can scrape processes running on all the machines in a cluster, the agent can scrape only those processes that are running on the host that it is installed on.\nWithin the set of eligible processes/ports/endpoints, the agent scrapes only the ports that are exporting Prometheus metrics and will stop attempting to scrape or retry on ports based on how they respond to attempts to connect and scrape them. It is therefore strongly recommended that you create a configuration that restricts the process and ports for attempted scraping to the minimum expected range for your exporters. This minimizes the potential for unintended side-effects in both the Agent and your applications due to repeated failed connection attempts.\nThe end to end metric collection can be summarized as follows:\nA process is determined to be eligible for possible scraping if it positively matches against a series of Process Filter include/exclude rules. See Process Filter for more information.\nThe Agent will then attempt to scrape an eligible process at a /metrics endpoint on all of its listening TCP ports unless the additional configuration is present to restrict scraping to a subset of ports and/or another endpoint name.\nUpon receiving the metrics, the agent applies the following rules before sending them to the Sysdig collector.\nApplies the global metrics_filter rules.\nSee Include/Exclude Custom Metrics.\nImposes the configured max_metrics to limit the number of metrics.\nThe metrics ultimately appear in the Sysdig Monitor Explore interface in the Prometheus section.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycollect-prometheus-metrics/working-with-prometheus-metrics/"},{"id":169,"title":"On-Prem Release Notes 2020","content":"Release 3.6.2 December 14, 2020This release contains bug fixes and minor improvements.\nUpgrade ProcessSupported Upgrade From: 3.2.2, 3.5.1, (3.6.0 or 3.6.1 if it was installed)\nSee the GitHub documentation for the full supportability matrix and install/upgrade.\nBug Fixes Fixed email notifications error\nIn some cases, including alerts with very large scopes and some others, email notifications were not sent due to a bug in the email renderer. This issue has been fixed.\nFixed Kubernetes metadata display delay\nIn 3.6.0 and 3.6.1 releases, upon connecting an agent, it would take 1h for Kubernetes metadata to appear. With this bug fixed, the metadata is displayed a couple of minutes after connecting the agent.\nFixed dashboard display error when switching teams\nWhen the user switched teams, the dashboard menu was not displayed and required the user to reload the application. This has been fixed.\nImprovements to the security setup of our Intercom integrations\nWe have improved the security of the Sysdig Intercom integration, as in some cases, the conversations could leak between different users.\nFix to Activity Audit Janitor\nFixed an Activity Audit Janitor error that stopped the AA clean-up process when a particular set of Sysdig Secure features were not enabled.\nImprovementsIncreased Decimal Precision from 4 to 6With this release, we increased the decimal precision from 4 to 6 decimal places. This feature is mostly useful for customers using Prometheus metrics, as by convention, the metrics for time are given in seconds in Prometheus exporters, which does not work well for low numbers (for example - latencies in microseconds).\nNew Runtime Policy Events JSON FormatThe JSON format for the runtime policy events has been upgraded to include full scope information, rule labels, and a single-line representation for the event field\u0026rsquo;s keys and values.\nTo preserve backwards compatibility with existing integrations, the former JSON format is still available (and used by default on migration).\nFrom the Event Forwarder page, under \u0026ldquo;Data to Send,\u0026rdquo; the old JSON format is labeled \u0026ldquo;Policy Events (Legacy)\u0026rdquo; and the new one as \u0026ldquo;Runtime Policy Events.\u0026rdquo;\nSee also: Event Forwarding.\nRelease 3.5.3 December 14, 2020 (Replicated Only)This release is a bug fix only release.\nUpgrade ProcessSysdig Platform v 3.5.3 has been tested and qualified against the same components as in v. 3.5.1.\nSupported Upgrade from: 3.5.1, 3.2.x, 3.0\nBug FixesSysdig Platform\nFixed email notifications error\nIn some cases, including alerts with very large scopes and some others, email notifications were not sent due to a bug in the email renderer. This issue has been fixed.\nImprovements to the security setup of our Intercom integrations\nWe have improved the security of the Sysdig Intercom integration, as in some cases, the conversations could leak between different users.\nSysdig Secure\nEvents Forwarder improvement\nFixed a crash condition in the Events Forwarder service stemming from a microservices connectivity issue.\nRelease 3.6.1 November 23, 2020Oversight Services Now Offered for All Installs and Upgrades As part of our continued focus on our customers, we are now offering oversight services for all on-premises installs and upgrades. Your Technical Account Manager (TAM), in conjunction with our support organization and Professional Services [where applicable], will work with you to:\nAssess your environment to ensure it is configured correctly\nReview your infrastructure to validate the appropriate storage capacities are available\nReview and provide recommendations for backing up your Sysdig data\nWork with you to ensure our teams are ready to assist you during the install and upgrade process\nProvide the software for the install\nBe available during the process to ensure a successful deployment\nYou can always review the process in the documentation on GitHub (v. 3.6.0+) or the standard docs site (for older versions).\nIf you are a new customer looking to explore Sysdig, please head over here to sign up for a trial on our SaaS Platform. Alternatively, you can contact us here.\nUpgrade ProcessSupportability MatrixSysdig Platform has been tested and qualified against the following Upgrade matrix.\n* Note that as of this release, there are no upgrades for Replicated installations.\nRelated Documents Installation Additional Docs Kubernetes README Review the Upgrade and other files within the version-specific GitHub folder for additional information. Replicated No Replicated release from 3.6.0 forward. Sysdig SecureThe following improvements were introduced in release 3.6.1:\nNode Image Analyzer: Scan \u0026ldquo;Repo-less\u0026rdquo; ImagesAdded support to scan images that lack a Repo tag, such as OpenShift 4.x distribution images.\nAudit Tap Forwarding: Fixed Splunk Event Timestamp MetadataThe format of the \u0026ldquo;time\u0026rdquo; field included in the Splunk event metadata for forwarded Audit Tap events is now increased to millisecond granularity.\nFixed False Positives on Java Libraries Related to log4jFixed an issue that resulted in log4j-jboss-logmanagerand log4j-1.2-apibeing incorrectly detected as log4j, possibly generating vulnerability false positives.\nNOTE: Inline Scanner v2.1 Inline Scanner v2.1 has been released.\nThis component is independent of the Sysdig Platform version you are running\u0026ndash;it can be used with Sysdig On-Prem version 3.6.1 and with earlier versions.\nInline Scanner 2.1 includes the following enhancements:\nNEW\nAdded ability to analyze scratch-based images\nFIXES\nFixed a bug retrieving the PDF output for previously- scanned images\nAddressed several vulnerabilities found in the inline scanner container\nSee also: Integrate with CI/CD Tools.\nRelease 3.6.0 November 10, 2020Oversight Services Now Offered for All Installs and Upgrades As part of our continued focus on our customers, we are now offering oversight services for all on-premises installs and upgrades. Your Technical Account Manager (TAM), in conjunction with our support organization and Professional Services [where applicable], will work with you to:\nAssess your environment to ensure it is configured correctly\nReview your infrastructure to validate the appropriate storage capacities are available\nReview and provide recommendations for backing up your Sysdig data\nWork with you to ensure our teams are ready to assist you during the install and upgrade process\nProvide the software for the install\nBe available during the process to ensure a successful deployment\nYou can always review the process in the documentation on GitHub (v. 3.6.0+) or the standard docs site (for older versions).\nIf you are a new customer looking to explore Sysdig, please head over here to sign up for a trial on our SaaS Platform. Alternatively, you can contact us here.\nUpgrade ProcessSupportability MatrixSysdig Platform has been tested and qualified against the following Upgrade matrix.\n* Note that as of this release, there are no upgrades for Replicated installations.\nRelated Documents Installation Additional Docs Kubernetes README Upgrade notes, parameters, and more Replicated No Replicated release of 3.6.0 Sysdig PlatformInteractive Session Expiration Installation-WideWith this release, you can define a period of interactive-session expiration, so that when a user is idle for a defined period of time, the session terminates. This helps enterprises with strict security and compliance requirements comply with relevant security controls, such as NIST or PCI-DSS 8.1.8 .\nCurrently, this feature is available for on-premises only and is configured per installation.\nSee also: Configure Interactive Session Expiration.\nMinor Enhancements and Fixes around Users and Teams Team Search Available when Switching Teams\nYou can now search for Teams on the Team Switcher. This feature is especially handy for Admins who are members of many teams.\nSee also: Switching Teams in the UI.\nUser search now supports many more users\nWith this release, we have enhanced the performance for listing and search for users on bothSettings\u0026gt;Users and Settings\u0026gt;Teams pages. We now support tens of thousands of users comfortably.\nLDAP: Search for users by both username and email address\nFor enterprises using LDAP, this release enables search on both username and user email address in the Settings \u0026gt; Users and Settings \u0026gt; Teams pages. Users are listed by name but can be searched by email as well.\nLDAP: Default team role respected\nThis fix ensures that when LDAP users are created upon login, the default user role for the team is respected.\nInline Scanner 2.0A new version of the Sysdig inline scanner script has been released.\nMajor improvements:\nThe inline analysis container doesn\u0026rsquo;t need to spawn any additional containers\nThis removes the requirement for the Docker client, docker-in-docker, etc.\nThis enables usage in environments where docker-in-docker is not feasible or hard to instrument (e.g., Tekton).\nAdditional analysis workflows and formats:\nAdded support to analyze a docker archive\nA .tar.gz file containing the image, i.e. the output from a \u0026ldquo;docker save\u0026rdquo;\nExample execution\nAdded support to analyze OCI images (both and directory and archive)\nUncompressed or compressed OCI image format\nAdded support to retrieve an image from the container storage (CRI-O and others)\nExample execution Additional improvements:\nFaster image ingestion\nMore verbose logs available for troubleshooting and diagnosis\nMachine-readable JSON output via --format JSON command\nTo upgrade an earlier Sysdig Inline Scanning version to 2.0, you need to take into account the new invocation parameters, which are not backward compatible.\nSysdig Inline scanner can be used stand-alone or as a step inside a CI/CD pipeline (Jenkins, Tekton, CircleCI, etc). In the upcoming weeks, we will update the different integrations to provide out-of-the-box support for the 2.0 version.\nSysdig SecureRegulatory Compliance Control Validation \u0026amp; PCI ChecksA new feature has been added to Sysdig Secure for checking controls from various compliance standards. For the first release, we provide checks against specific controls in PCI 3.2. Future releases will include SOC2, NIST-800-53, and more.\nCompliance Validator and ReportsThe validator checks many Sysdig Secure features, including: image scanning policies, Falco runtime policies and rules, scheduled benchmark testing, Admission Controller, Network Security Policies, Node Image Analyzer, and more. Over time we will add new compliance coverage.\nDisclaimer: Sysdig cannot check all controls within a framework, such as those related to physical security.\nThis feature is a beta release. A Sysdig Secure admin must enable it from the Sysdig Labs interface under Settings.\nPCI Control DetailsThe PCI Quick Reference describes the full range of controls required to pass a PCI 3.2 audit. In this release, Sysdig Secure will check the following subset:\nControls 1.1.2, 1.1.3, 1.1.6.b, 2.2, 2.2.1, 2.2.2, 2.2.a, 2.4, 2.6, 4.1, 6.1, 6.2, 6.4.2, 6.5.1, 6.5.6, 6.5.8, 7.1.2, 7.2.3, 10.1, 10.2, 10.2.1, 10.2.2, 10.2.3, 10.2.6, 10.2.7, 10.3, 10.5.5, 10.6.1, 11.4, 11.5.a, 11.5.b.\nReplacing RHSA Advisories with CVE AdvisoriesIn new images scanned, RHSA advisories will be replaced with CVE advisories.\nBenchmarks support for Kubernetes Benchmark 1.6 Kubernetes Bench upgraded to version 1.6\nUsing the Kubernetes benchmark, we now provide customer-selected benchmark checks for GKE and EKS (rather than just the Kubernetes default).\nVulnerability Exceptions Handling EnhancedThe Vulnerability Exceptions feature in Sysdig Secure has been redesigned and enhanced.\nIt now offers:\nAdditional vulnerability and feed context\nPrecise mapping between images and their associated exceptions\nA better exception management lifecycle\nMultiple vulnerability lists, which can be flexibly assigned to different image sets (or just a particular image), using the scanning policy assignments\nAdditional information displayed to improve team awareness and security context\nVulnerability description\nUser-defined notes\nVulnerability feed info, with severities and links as provided per feed\nConfigurable expiration dates:\nAn exception is automatically disabled when the expiration date is met\nDay resolution, all times relative to 0:00 UTC\nEnhanced workflow integration with the \u0026ldquo;Scan results\u0026rdquo; page for an individual image, with the ability to quickly append a flagged vulnerability to a list.\nMigration: The exception and evaluation behavior in the current environment will be maintained after the feature upgrade. In particular:\nPre-existing vulnerability exceptions will be migrated to the \u0026ldquo;Default exceptions list\u0026rdquo;\nThe \u0026ldquo;Default exceptions list\u0026rdquo; will be assigned to every pre-existing policy assignment\nAll the pre-existing vulnerability exceptions expiration date will be set to \u0026ldquo;Never.\u0026rdquo;\nSee also: Manage Vulnerability Exceptions and Global Lists.\nEvent Forwarding: Kafka and Webhook AddedTwo new supported integrations have been added to the Sysdig Secure Event Forwarder:\nKafka topic\nGeneric webhook\nThe Kafka topic integration includes support for:\nMultiple Kafka brokers\nPartitioner/Balancer algorithms: Murmur2, Round robin, Least bytes, Hash, CRC32\nCompression algorithms: LZ4, Snappy, Gzip, Zstandard\nThe Webhook integration includes support for:\nAuthentication methods: Basic authentication, Bearer Token, and Signature Header\nCustom headers defined by the user to accommodate any additional parameter required on the receiving end\nImage Exclusion on Policy EventsUsers often want to tune policy events. We\u0026rsquo;ve added a button on the event detail that will add an exclusion to a specific container.image.repo for the policy that triggered the event. Once that exclusion is applied to the scope, policies will no longer fire for that container.image.repo.\nCaptures Filter on the Policies PagePolicies can now be filtered to display if a capture is associated with an active or inactive policy.\nQuick Menu to Captures from Runtime EventsFor runtime policy events that have an associated capture, we now offer a contextual menu for performing quick actions over the event capture, rather than a simple link to the Captures interface. You can:\nView the capture directly in Sysdig Inspect\nDirectly download or delete the capture\nAdditionally, if the event is scoped to a particular container, Sysdig Inspect will automatically filter the displayed information to the scope of that Container ID.\nImage Scan Results Page Redesigned to Improve Load Times \u0026amp; User Experience The user interface is cleaned up, reorganized, and provides the following functional improvements:\nLoad times are significantly decreased because the last known evaluation for the image is automatically fetched\nView the latest evaluation time directly in the scan summary Evaluated at\nUse the new Re-evaluate button to fetch current data if desired\nView the image origin/reporting mechanism in the new \u0026ldquo;Added By\u0026rdquo; field.\nPossible values are: Sysdig Secure UI, Node Image Analyzer, API, Sysdig Inline Scanner, or Scanning alert.\nCopy the Image Digest and Image ID to the clipboard using a quick pop-up panel.\nForwarding the Activity Audit InformationThe Sysdig Secure Event Forwarder has added support to forward Activity Audit data to external platforms.\nSysdig MonitorTime Navigation in Events FeedYou can now browse and find historic events easily by using time navigation.\nZooming Out DashboardsYou now have the ability to zoom out Dashboards. This feature doubles the selected timeframe for a better context surrounding a problem when troubleshooting an incident.\nRelease 3.5.1 August 24, 2020NOTE: Version 3.5.1 includes a fix for vulnerabilities that were detected in version 3.5.0. It is recommended to skip version 3.5.0 and install version 3.5.1 instead. As of this release, all on-premises installs and upgrades include oversight services from Sysdig support.\nOversight Services Now Offered for All Installs and Upgrades As part of our continued focus on our customers, we are now offering oversight services for all on-premises installs and upgrades. Your Technical Account Manager (TAM), in conjunction with our support organization and Professional Services [where applicable], will work with you to:\nAssess your environment to ensure it is configured correctly\nReview your infrastructure to validate the appropriate storage capacities are available\nReview and provide recommendations for backing up your Sysdig data\nWork with you to ensure our teams are ready to assist you during the install and upgrade process\nProvide the software for the install\nBe available during the process to ensure a successful deployment\nYou can always review the process in the documentation on GitHub (v. 3.6.0+) or the standard docs site (for older versions).\nIf you are a new customer looking to explore Sysdig, please head over here to sign up for a trial on our SaaS Platform. Alternatively, you can contact us here.\nUpgrade ProcessSysdig Platform has been tested and qualified against the following:\nSupported Upgrade From 3.5.0, 3.2.x, 3.0 Platform Version Vanilla Kubernetes 1.13.4, 14.10, 1.15.12, 1.16.13, 1.17.9, 1.18.6 OpenShift 4.4 \u0026ndash;\u0026gt; 1.17.1+1aa1c48 GKE 1.14.10-gke.36 EKS v1.17.7-eks-bffbac Rancher v2.3.3 IBM Unqualified PKS Unqualified Agent Version sysdig/agent 10.2.0 Components\nReplicated TBD\nKubernetes with Statefulsets\nRedis\nn/a\n4.0.12\nMySQL\nn/a\n5.6.44\nMySQL HA*\nn/a\n8.0.16 (see note)\nElasticSearch\nn/a\n5.6.16\nCassandra\nn/a\nrelease_version: 2.1.21\ncql_version: 3.2.1\nRDS\nn/a\n8.0.16\nPostgres (image scanning)*\nn/a\n12.3 (see note)\nAnchore (image scanning)\nn/a\n0.6.1\nNATS Exporter\nn/a\n0.6.0.1\nNATS Streaming\nn/a\n0.17.0.1\nHA-Proxy\nn/a\n1.9.15\nMySQL8: You can use MySQL8 for non-HA setups using the flag useMySQL8: true Postgres: Upgrading to 3.5.0 will also involve an automatic Postgres version upgrade from 10.6.x to 12.x. Depending on your database size, the upgrade could take some time. Related Documents Installation Upgrade Kubernetes Installer (Kubernetes | OpenShift) Installer Upgrade 3.5.0-3.5.1 Replicated Not supported Not supported Sysdig PlatformEndpoint for Feeds Update Has ChangedWe no longer point to ancho.re for feeds update but tohttps://api.sysdigcloud.com/api/scanning-feeds/v1/feeds. This could require a change to your firewall rules, as an exception to your proxy for ancho.re would impact the feeds update.\nSysdig Secure Note that the Secure Overview is not available with Replicated installations.\nNew Sysdig Secure Overview PageThe Sysdig Secure Overview provides an at-a-glance view of the critical areas of your security posture.\nScopingPanels can be scoped by Cluster or Namespace. The scope will update all panels that are displaying run-time data and the corresponding drill-down views.\nPanels Build Time - Images Scanned: Image scan results for all static image scans\nDrill-down - To Image Scanning Reports page.\nBuild Time - CVEs Found by Severity: The total number of CVEs present in each image scanned.\nDrill-down - Available in a future release\nRun-time - Images Scanned: The pass/fail status of images running now and their trend over time.\nDrill-down - To Runtime Scanning Image page.\nRun-time - CVEs by Severity: The total number of CVEs present in each running image\nDrill-down - Available in a future release\nRun-time - Policy Events by Severity: The total number of policy events by severity.\nDrill-down - Secure Events page.\nBenchmarks Tests Failing: The total number of benchmark tests that have failed.\nNew Get Started PageThe Get Started page provides the key steps to ensure users are getting the most value out of Sysdig Secure. We\u0026rsquo;ll update this page with new steps as we add new features to Sysdig Secure.\nThe Get Started page also serves as a linking page for:\nDocumentation\nRelease Notes\nThe Sysdig Blog\nSelf-Paced Training\nSupport\nUsers can access the page at any time by clicking the rocketship in the side menu.\nFeeds Status Page AddedIt\u0026rsquo;s useful to understand the last time the feeds were updated, especially in self-hosted environments. The Feeds Status page shows the different vulnerability feeds we integrate with, their feed group (often the distro version), the time of the last sync, and how many CVE records are present in the feed group.\nSee also: Feeds Status.\nSecure Events Feed OverhaulThe Events feed in Sysdig Secure (formerly called Policy Events) has been redesigned, both visually and functionally.\nApart from the styling and user experience improvements, these are the major new features and use cases\nAdvanced FilteringWe are deprecating the grouping/clustering of events present in the old version in favor of a much more powerful set of filtering capabilities:\nSeverity filters: Presented as quick buttons at the top, supporting multi-select\nAttribute filters: Provide a simplified syntax to filter events by the attributes they contain. For example ruleType=\u0026quot;Falco - Syscall\u0026quot; or image.repo!=\u0026quot;sysdig/agent\u0026quot;\nOpen the event details side panel to find quick filtering widgets to include or exclude the attribute values associated with the displayed event Event type selector: Supports runtime scanning alerts on top of policy runtime events (see section below), with an easy multi-selector in the UI.\nFree text search: Allows you to search the event titles and scope label values. I.e. Terminal shell inor my-k8s-cluster.\nNew scope selector: Allows for additional selector logic (in, not in, contains, startswith, etc), improving the scoping flexibility over earlier versions. This scope selector also provides scope variables, allowing you to quickly switch between, for example, Kubernetes namespaces without having to edit the panel scope.\nAll these filters can be combined additively to further refine your search.\nMultiple Event TypesThe new event feed displays not only the policy runtime events, but also runtime image scanning alerts.\nThe backend architecture, filtering, and UX have been designed to accommodate additional types of security events that will be pushed to the Event Feed in the future, upgrading the interface from a policy-runtime-centric experience to a full security center control panel.\nAdditional Event DetailsPolicy runtime events: These now display the rule that was fired together with the rule labels. You can use the quick filters mentioned above to further refine the search.\nRicher scope: Every security event now displays all the scope labels retrieved for the event, not just those configured in the scope selector.\nSee also: Secure Events.\nAdditional Considerations/LimitationsEvents in the old and new format will be stored separately:\nNo event or event data will be lost during the transition\nEvents that were registered before the new feed is deployed can be browsed using the old feed interface, which is available from the burger menu in the top-right corner\nEvents that happen after the new feed is deployed will appear in the new event feed\nEventually, all events within the retention period will be present in the new interface, at which point the version switcher will disappear\nTeam, Role, and Channel UpdatesA variety of enhancements have been added to the team, role, and notification channel options.\nService Manager Role Added to Sysdig SecureRBAC capability was previously added to Sysdig Secure. (See also January 27, 2020 and User and Team Administration.)\nNow a new role, Service Manager, is also available in Secure. It has the same permissions as the Standard User, plus the ability to invite existing users to the team and manage the notifications channels assigned to the team. See Team-Based Roles and Privileges\nConfigurable Default Team RoleYou can now define the default user role to apply when a new member is added to the team. The Admin can change this default on a per-team basis. See also: Create a Team.\nRBAC and Team Assignment for Notification ChannelsPreviously, notification channels in Sysdig Secure and Monitor were treated as global entities, visible and editable for most users of the platform regardless of team configurations.\nWe are enhancing the management and RBAC controls in the following ways:\nNotification channels can now be \u0026ldquo;global\u0026rdquo; or limited to a particular team\nGlobal channels can be managed by admins and can be viewed/used by other roles, while team-limited channels are available only to team members\nTeam Manager , Advanced User, and Service Manager (Secure) roles can create/update/delete team-scoped notification channels, they can also read and use the global ones\nStandard and View Only roles can read team-limited and global notification channels\nAdmins will be able to create global notification channels and migrate channels from \u0026ldquo;global\u0026rdquo; to \u0026ldquo;team-limited\u0026rdquo;, and also from one team to another.\nSee also: Set Up Notification Channels and the Share With field in each individual channel setting page.\nOptimized Runtime PageWe\u0026rsquo;ve released a new Runtime page for the Image Scanning module within Sysdig Secure. Improvements include:\nFiltering based on pass/fail/unscanned\nThe ability to search results for a specific image\nOptimized queries to improve response times\nFor more information, see Review Scan Results.\nMenu UpdateThe ordering of the side menu has been changed.\nImage Scanning UpdatesThe image scanning navigation bar has changed.\nThe side menu is reorganized into Analyze and Configure sections\nAnalyze: Different areas of scanning that allow users to view scan results\nConfigure: The areas of scanning that involve the setup of the application\nWhitelist terminology with CVEs has been removed.\n\u0026ldquo;CVE whitelist\u0026rdquo; is now CVE Exceptions.\nCLI-Based Admission Controller for Image ScanningAn additional tool for evaluating and admitting images is now available.\nSysdig Admission ControllerSysdig\u0026rsquo;s Admission Controller (UI-based) combines the Sysdig Secure image scanner with a policy language to evaluate scan results and the admission context, providing great flexibility in the admission decision. It also provides the first line of defense against image-based security threats.\nBy using Kubernetes API extensions to perform image scanning and other security checks on admission, we cover a major threat-prevention and hardening use case: \u0026ldquo;Only the images that are explicitly approved will be allowed to run on my cluster\u0026rdquo;.\nThe admission decision relies not only on the image name and tag but also on additional context from the admission review, including namespace, pod metadata, etc.\nFeatures\nRegistry and repository whitelist / blacklist\nGlobal and per-namespace admission configuration\nConfigurable pre-scan and post-scan behavior, i.e.:\nAccept only the images that pass the scan (default)\nDirectly reject non-whitelisted registries / repos, without scanning\nAccept the image even if it doesn\u0026rsquo;t pass the scan\nDo not accept any image that hasn\u0026rsquo;t been scanned already\nPod mutation: image tag is replaced by digest to prevent TOCTOU (Time of Check, Time of Use) issue if the tag is updated between the scan and the pod scheduling\nRequirements\nHelm 3\nKubernetes 1.15 or higher\nFor more information, see Admission Controller .\nAdded Automatic Image Scanning using Node AnalyzerThe (node) image analyzer (NIA) provides the capability to scan images as soon as they start running on hosts where the analyzer is installed. It is typically installed alongside the Sysdig agentcontainer.\nThis component was introduced to reduce dependencies on analyzing images within the Sysdig backend (SaaS or On-prem). Some advantages include:\nSharing credentials with the Sysdig backend in order to pull images is not required\nSharing the image content and potentially code with the Sysdig backend is not required; only metadata will be sent out\nOpening a network route to allow the Sysdig backend to reach the user\u0026rsquo;s registries is not required\nIf you have run the single line agent install with the --image-analyzer flag, then this component is already running in your infrastructure.\nThe feature is available for Kubernetes environments.\nFor more information, see Scan Running Images.\nAdded Image Scanning Integration OptionsTwo new scanning integrations are available for CI/CD pipelines. Sysdig provides:\nA reference implementation with Tekton Pipelines (prototype)\nA fully supported integration with Amazon Elastic Container Registry (ECR) for triggering auto-scans from the registry\nIntegrating Secure Image Scanning with Tekton PipelinesTekton Pipelines allow you to implement CI/CD workflows using a highly modular, cloud-native approach that:\nUses containers as the building blocks for individual tasks\nRuns directly on Kubernetes/OpenShift without requiring a dedicated infrastructure\nUses tasks that are purely declarative and described using their own CRD, making them easily composable and reusable\nSysdig\u0026rsquo;s reference implementation details the prototype task to invoke Sysdig Secure image scanning as a pluggable step in your CI/CD pipeline with just a YAML file:\nLeveraging Tekton integration with the orchestration layer, you can retrieve the image scanning policy evaluation and state (pass/fail) directly from the logs of the task pod.\nRead the \u0026ldquo;Securing Tekton pipelines in OpenShift with Sysdig\u0026rdquo; blog post for additional details\nIntegrating Secure Image Scanning with Amazon ECRAutomatically scan images pushed to your Amazon Elastic Container Registry (ECR) using AWS-native technologies and Sysdig Secure.\nSysdig image scanner integration is deployed as a CloudFormation template that listens to ECR registry events and uses AWS resources to streamline the image scanning process.\nECR itself will trigger the scan, no need for your CI/CD pipelines to actively pull from the registry\nDeployed in a few clicks, you just provide basic configuration parameters such as the Sysdig API token or the Sysdig backend URL\nNo need to configure registry scanning credentials on the Sysdig Secure side\nThis integration offers two different operation modes\nInline scanning:\nScanning will be performed inside an AWS CodeBuild pipeline allocating ephemeral resources\nNo need to configure any registry credentials for Sysdig Secure\nNo need to expose your ECR registry to the Sysdig Secure backend\nSysdig Secure will not retrieve the image contents, only the metadata that is required to perform the policy evaluation\nBackend scanning:\nSysdig Secure will retrieve the full image contents in order to perform the scan\nYour ECR registry must be reachable by the Sysdig Secure backend\nRegistry credentials are required, but they are pushed automatically by a lambda function, no need for manual configuration\nUpdated Inline Scan Script Added header values for import API for better supportability.\nUpgraded to Anchore engine v0.6.1.\nUse docker:dindinstead of ubuntu for the base image. This reduces the image size and speeds up downloading.\nThe latest version of the inline script will always be available at https://download.sysdig.com/stable/inline_scan.sh\nLink to repo for script source code: https://github.com/sysdiglabs/secure-inline-scan\nInline Scanning Reporting Improvements and DocumentationThis script from SysdigLabs is useful for performing image analysis on locally built container images and posts. The only dependency for this script is access to docker-engine, Sysdig Secure endpoint (with the API token) and network connectivity to post image analysis results.\nHere are examples of using the inline scanner in different pipelines:\nGitLab\nGitHub Actions\nAWS Codepipeline\nAzure Pipelines\nCircleCI\nPDF Reports from the Inline ScannerA new option\n-R [optional] Download scan result pdf report will generate a PDF artifact that is available for developers to consume in the pipeline.\nUpdates to Default Rules and PoliciesThe following changes have been made to default Policies in Sysdig Secure, and to default Falco rules:\nNew rule tags added that map Falco rules to PCI and NIST controls\nNew default policies added specifically for PIC/NIST compliance\nTuning modifications for:\nWrite below etc\nWrite below root\nChange thread namespace\nRun shell untrusted\nDetect outbound connections to common miner pool ports\nFor more information, see also Falco Rules Changelog.\nNew Vulnerability Feed Available: VulnDBWe\u0026rsquo;ve added VulnDB as an additional 3rd-party vulnerability source to improve Sysdig\u0026rsquo;s coverage in non-OS package vulnerabilities.\nIn addition, a new page is available for each VULNDB-linked advisory. It lists the CVEs and details about the Common Vulnerability Scoring System (CVSS) scores and external references.\nSee also: Vulnerability Databases Used.\nLinux CIS Benchmark Test AddedSysdig Agents can run the Independent Linux benchmark against the underlying host where the agent is installed. The Linux benchmark can be scheduled to run at a chosen interval in your environment and emits results and metrics about the status of the tests.\nOpenShift Hardening GuideThe OpenShift hardening guide implements configuration checks run by the agent against OpenShift environments.\nSee https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html/container_security_guide/index\nNote: This is supported for 3.x versions of OpenShift. When OpenShift releases a hardening guide for 4.x versions, we will update the configuration checks.\nCaptures can be Routed to Specific Storage LocationsAs a user, you may have different S3 buckets where you\u0026rsquo;d like to store Sysdig captures, based on the environment where the policy event was triggered. New options are available for deciding what storage option you\u0026rsquo;d like to use for each policy event.\nSysdig MonitorNew Dashboards is GASysdig Monitor offers a new version of dashboards. Its improved editing experience provides you with more flexibility and the new set of functionalities offers additional ways to visualize and consume your Sysdig data.\nFeatures and EnhancementsImproved User ExperienceThe New Dashboard offers a more fluid, natural dashboard building experience.\nDashboard SharingYou can now share your dashboard with members within your Sysdig team or share it across teams with fine-grained access controls. Define who should be able to see the dashboards and what level of access they should be granted: view only or collaborator with edit privileges.\nTime Series Name TemplatingCustomize the time series names on the legend on the panel editor by using the labels associated with Prometheus metrics and segments to gain context faster.\nMulti-Metric, Multi-Segmentation OptionsConfigure multiple queries within a single panel, and configure each query with multiple segmentation and scoping options. Individual queries can be customized to render as a line or stacked area. .\nEvent OverlayContextualize metrics and understand the \u0026ldquo;why\u0026rdquo; faster with a unified view of both metrics and events. Configure event overlay to display events from Kubernetes environments as well as alert events, and any other events ingested using Sysdig\u0026rsquo;s open REST API.\nDashboard LibraryFormerly, Dashboard Templates.\nYou can quickly view your infrastructure through the lens of one of Sysdig\u0026rsquo;s curated dashboards, or use it as a base to start building your own. You can find dashboards in the Library for managing Kubernetes capacity and health, hosts and server performance, applications and services telemetry, and the security posture of your infrastructure with data fed from Sysdig Secure. See Dashboard Library to learn more.\nMapping Values to TextInstantly understand what\u0026rsquo;s going on by mapping number panel values to text. If you have a metric that returns 1 for up, and 0 for down, map those values to \u0026ldquo;UP\u0026rdquo; and \u0026ldquo;DOWN\u0026rdquo; respectively. By defining thresholds and mapping to text, you don\u0026rsquo;t need to be concerned about the values. This is critically valuable when dashboards are shared between team members. For more information, see Text.\nGranular Axes and Legend ControlsYou have more flexibility when customizing the axes, as well as better support for time series with long names. You can now configure the legend by toggling its visibility and moving it to the bottom of the panel.\nMajor ChangesSignificant changes have been introduced to enhance the usability of the existing functionalities. Review the changes before you explore the functionalities.\nTopology MapsTopology maps are no longer available in Dashboard. Access Topology maps through Explore, as you explore your microservices and Kubernetes applications.\nDashboard WizardMy Dashboards are no longer accessible in Explore. Additionally, Dashboard Wizard has been removed. Instead, the concept of Templates has been introduced in Dashboards to help you get started with a library of templates addressing key use cases.\nHistogram and Summary Metric TypeHistogram and summary metrics are no longer supported in the Histogram panel type. You can continue to use them within Explore.\nAPIs and IntegrationsAPI endpoints for the legacy dashboards (v2) will soon be deprecated. If you are directly integrating into the API, please contact Sysdig for guidance. Additionally, our Python SDK and CLI have been updated to support the new dashboards APIs.\nSysdig Monitor RebrandingThe Monitor app has been refreshed with new logos and icons. The navigation pane has been re-organized. The Explore tab is moved below Dashboards.\nThe New Get Started PageThe Get Started page provides the key steps to ensure that you are getting the most value out of Sysdig Monitor. We\u0026rsquo;ll update this page with new steps as we add new features to Sysdig Monitor.\nThe Get Started page also serves as a linking page for:\nDocumentation\nRelease Notes\nThe Sysdig Blog\nSelf-Paced Training\nSupport\nYou can access the page at any time by clicking the rocketship icon in the left navigation bar. See Getting Started with Sysdig Monitor.Getting Started with Sysdig Monitor\nRBAC and Team Assignment for Notification ChannelsPreviously, notification channels in Sysdig Secure and Monitor were treated as global entities, visible and editable for most users of the platform regardless of team configurations.\nWe are enhancing the management and RBAC controls in the following ways:\nNotification channels can now be \u0026ldquo;global\u0026rdquo; or limited to a particular team\nGlobal channels can be managed by admins and can be viewed/used by other roles, while team-limited channels are available only to team members\nTeam Manager , Advanced User, and Service Manager (Secure) roles can create/update/delete team-scoped notification channels, they can also read and use the global ones\nStandard and View Only roles can read team-limited and global notification channels\nAdmins will be able to create global notification channels and migrate channels from \u0026ldquo;global\u0026rdquo; to \u0026ldquo;team-limited\u0026rdquo;, and also from one team to another.\nSee also: Set Up Notification Channels and the Share With field in each individual channel setting page.\nAWS Role DelegationSysdig Monitor can now utilize the Amazon Web Service (AWS) AssumeRole functionality and discover cloud assets, grab CloudWatch metrics from your AWS account, and use custom S3 bucket for storing captures. Upon integrating with an AWS role, you can delegate access to AWS resources that are not associated with your Sysdig AWS account.\nRole delegation is an alternative to the existing integration method using the access keys. This method is considered secure as sharing developer access keys with third-parties is not recommended by Amazon.\nFor more information, see Integrate with AWS Role Delegation.\nConfigurable Default Team RoleYou can now define the default user role to apply when a new member is added to the team. The Admin can change this default on a per-team basis. See also: Create a Team.\nDefault Dashboards for Istio 1.5Default dashboards (Overview and Services dashboards) are now available for Istio v1.5 in addition to the existing ones for Istio v1.0.\nRelease 3.2.2, June 11, 2020This is a hotfix release for Benchmarks. See Defect Fixes for details.\nUpgrade ProcessSysdig Platform has been tested and qualified against the following:\nSupported Upgrade From 2.5.0, 3.0 Platform Version Vanilla Kubernetes 1.13.4, 1.15.3 and 1.16.0 OpenShift 3.11, 4.2 and 4.3 GKE v1.14.6-gke.13 EKS EKS .7, Kubernetes 1.14 Rancher v2.3.3 IBM Unqualified PKS Unqualified Agent Version sysdig/agent 10.1.1 Components Replicated Kubernetes with Statefulsets Redis 4.0.12.7 4.0.12.7 MySQL 5.6.44.0 8.0.16.2 ElasticSearch 5.6.16.15 5.6.16.15 Cassandra 2.1.21.16 2.1.21.16 RDS n/a 8.0.16 Postgres (image scanning) n/a 10.6.11 Anchore (image scanning) n/a 0.5.1.2 NATS Exporter n/a 0.6.0.1 NATS Streaming n/a 0.16.2.1 Related Documents Installation\nKubernetes\nInstaller-based:\nInstaller (Kubernetes | OpenShift) 2.5.0-3.2.2\nManual:\nManual Install 3.0.0+ (Kubernetes)\nSysdig SecureDefect FixesProblem: On a cluster running Kubernetes v1.12 or later versions with Sysdig agent v9.7.0 or later versions, the CIS Kubernetes benchmark result could not be interpreted, resulting in an infinite spinner displayed in the UI.\nResolution: Sysdig agents v9.7.0 or later versions can now be used with Kubernetes v1.12 or later versions. The CIS Kubernetes versions included are 1.3, 1.4, and 1.5.\nSysdig MonitorThis release contains no new features or defect fixes.\nSysdig PlatformThis release contains no new features or defect fixes.\nRelease 3.2.1-Onprem (Replicated Only), March 23, 2020This is a hotfix release that enforces a minimum Replicated Console version to include a necessary security patch. This release contains no new Sysdig functionality and is not a required upgrade.\nUse of release 3.2.1-onprem requires first upgrading your Replicated Console to version 2.42.4 or newer.\nRelease 3.2.0, March 04, 2020Upgrade ProcessSysdig Platform has been tested and qualified against the following:\nSupported Upgrade From 2.5.0, 3.0 Platform Version Vanilla Kubernetes 1.13.4, 1.15.3 and 1.16.0 OpenShift 3.11, 4.2 and 4.3 GKE v1.14.6-gke.13 EKS EKS .7, Kubernetes 1.14 Rancher v2.3.3 IBM Unqualified PKS Unqualified Agent Version sysdig/agent 9.6.1 Components Replicated Kubernetes with Statefulsets Redis 4.0.12.7 4.0.12.7 MySQL 5.6.44.0 8.0.16.2 ElasticSearch 5.6.16.15 5.6.16.15 Cassandra 2.1.21.16 2.1.21.16 RDS n/a 8.0.16 Postgres (image scanning) n/a 10.6.11 Anchore (image scanning) n/a 0.5.1.2 NATS Exporter n/a 0.6.0.1 NATS Streaming n/a 0.16.2.1 Related Documents Installation\nKubernetes\nInstaller-based:\nInstaller (Kubernetes | OpenShift)\nManual:\nManual Install 3.0.0+ (Kubernetes)\nSysdig SecureData Retention Limits for Scan ResultsUse this feature to set limits on how long image scan metadata is stored, either by tags or days. This removes stale data and helps keep scan results easy to read.\nSee Data Retention for details.Data Retention\nRBAC Capability Available in Sysdig SecureThe new role-based access control (RBAC) model available in Sysdig Secure allows you to define the access privileges granted to each user in a Sysdig Secure team.\nBesides the Admin role, which has full access and belongs to every team, there are four roles that can be assigned when adding a user to a team. (Note that the role names are the same in Monitor and Secure, but the privileges differ slightly. Users must be assigned Monitor team roles and Secure team roles separately.)\nView Only: Read access to every Secure feature within the team scope. A View Only user cannot modify runtime policies, image scanning policies, or any other content.\nStandard User: Can push container images to the scanning queue and view the image scanning reports. Standard Users can also display the runtime security events within the team scope. They cannot access the Benchmarks, Activity Audit. or Policy definition sections of the product.\nAdvanced User: Can access every Sysdig Secure feature within the team scope in read and write mode. Advanced Users can create, delete, or update runtime policies, image scanning policies or any other content. The Advanced User cannot manage other users.\nTeam Manager: Same permissions as the Advanced User + ability to add/delete team members or change team member permissions.\nTeam Managers only have user administration rights within the specific team(s) for which they are designated Managers.\nSee User and Team Administration for details.\nVulnerability Scan Results ComparisonIn image scanning reports, the vulnerability comparison feature allows users to compare two different tags within the same repo to see which vulnerabilities are new or have been fixed in version X compared to version Y.\nThis allows developers easily to compare the latest image to a previous version to easily report on which vulnerabilities have been addressed and which are new.\nSee Review Vulnerability Summaries for details.Review Vulnerability Summaries\nRedesigned Captures PageThe Captures function in Sysdig Secure has a new look and the following usability improvements:\nBulk deletion of capture files\nAbility to see whether a capture was triggered manually or by a policy\nSearch across all capture files\nFile Data Source Support for Activity AuditSysdig Secure\u0026rsquo;s Activity Audit now supports a new data source element: File activity.\nSysdig agent version 9.5.0+ is required to enable this new data source.\nYou can now filter the activity by file type or specific file attributes:\nFile name\nDirectory\nCommand (used to access the file)\nAccess mode\nFile activity is also visible in the time-series graph at the top (pink color):\nActivity Audit will capture non-read file operations executed by interactive commands\nSysdig MonitorThis release contains various bug fixes and improvements. There are no new features in v3.2.0.\nSysdig PlatformS3-Compatible Storage for Capture FilesConfiguring S3-compatible storage (such as Minio or IBM Cloud Object Storage) for your Sysdig captures is now supported on Sysdig Platform on-prem deployments. The capability can be turned on by configuring the system appropriately, as given in (On-Prem) Configure Custom S3 Endpoint.\n","url":"https://docs.sysdig.com/en/release-notes/sysdig-on-premises-release-notes/2020-archive/"},{"id":170,"title":"Monitor SaaS Release Notes 2021","content":"December 17, 2021Update on Log4j Vulnerability (CVE-2021-44228)Sysdig confirms that all services that compose Sysdig\u0026rsquo;s Cloud Platform running Apache\u0026rsquo;s vulnerable Log4j library have been patched to 2.16. We have not detected any successful attempts at exploitation of this attack vector during that time window.\nDecember 15, 2021Update on Log4j Vulnerability (CVE-2021-44228)The sysdig agent does not include the Log4j library\nSysdig is using an alternative framework for logging, called Logback. The logback framework isn\u0026rsquo;t vulnerable to this issue.\nSysdig components include a log4j library in our standard distribution that was vulnerable. This library is included for compatibility reasons only, is not used for primary logging, and our security team has determined we are not vulnerable based on our application architecture and existing mitigating controls.\nSysdig can confirm that all services that compose Sysdig\u0026rsquo;s Cloud Platform running Apache\u0026rsquo;s vulnerable Log4j library have been patched to the latest version or adds additional mitigating controls suggested by vendors. We have not detected any successful attempts at exploitation of this attack vector during that time window.\nDetails regarding upgrades\nWe:\nexplicitly set commonsLog4jVersion = 2.15.0 update all of log4j-to-slf4j, log4j-api, and log4j-core to version 2.15.0 December 12, 2021A Statement on Log4j Vulnerability (CVE-2021-44228)Security researchers recently disclosed the vulnerability CVE-2021-44228 in Apache\u0026rsquo;s log4j, which is a common Java-based library used for logging purposes\nSysdig is using an alternative framework for logging called Logback. The logback framework isn\u0026rsquo;t vulnerable to this issue.\nSysdig components include a log4j library in our standard distribution that appears to be vulnerable. It has been confirmed that this library is included for compatibility reasons only and is not used for primary logging. As a result this should not pose any risks.\nPatches will be provided to upgrade the log4j libraries that are included for compatibility reasons.\nIf you have any questions or concerns, please reach out to your Sysdig contact.\nOctober 12, 2021Expose Custom Data on Webhook NotificationSysdig gives you the ability to specify custom data and attach it to the alert notification. For more information, see Configure a Webhook Channel.\nPrometheus Recording RulesSysdig now supports Prometheus recording rules for metric aggregation and querying. To enable this feature in your environment, contact Sysdig Support.\nTeam Scope for Prometheus Remote WriteSysdig gives you the ability to determine the granularity of data collected by Prometheus Remote Write to which team members will have the visibility. You can specify what data team members can see by specifying tag/value expressions for the metrics. The drop-down defaults to \u0026ldquo;is\u0026rdquo;, but can be changed to \u0026ldquo;is not\u0026rdquo;, \u0026ldquo;in\u0026rdquo;, \u0026ldquo;contains\u0026rdquo;, and so on. Complex policies can be created by clicking drop-down to create AND chains of several expressions. You can view the saved team scope by hovering on the corresponding team from the User menu.\nEnhanced User Experience for Monitor IntegrationsThe UI for Monitoring Integrations has been enhanced to include guided configuration for exporters.\nFor each integration, you can use the wizard to specify the required information and you will be provided with a single-line command to install the exporter in your cluster. You no longer have to see the documentation or the given exporter source code to guess the name of the variable to configure the credentials of your database or the SSL certificate in the connection string.\nIf you want to deploy it through your CI/CD pipeline and you cannot run commands directly in production, you also have the option to generate the manifests to upload to your repository. If you prefer a package management approach, you also have the option to use Helm charts for the Monitoring Integrations.\nAfter deploying an exporter, you can see whether it is working on the wizard. Sysdig Monitor automatically detects the metrics arriving in your account and associates them to the workload. This way, it is easy to visually detect the applications that are correctly reporting metrics and those that need some attention.\nFor more information, see Monitoring Integrations.\nDashboard Enhancements Ability to edit dashboard and panel name inline in the Panel Editor. Ability to add dashboard template to favorites. Moved the legacy dashboard templates to Deprecated section Supports RabbitMQ Integration. Configure it using the Monitoring Integrations. Added new dashboard templates for the following: Fargate Usage Go applications Sysdig Admission Controller RabbitMQ Integrations Kubernetes Controller Manager Kubernetes Scheduler CoreDNS Alert Enhancements Added new alerts for RabbitMQ and CoreDNS integrations and for Go applications. August 10, 2021Monitoring IntegrationsSysdig discovers the services running in your environment and gives you visibility into deeper application performance and health telemetry by configuring a managed Monitoring Integration through PromCat. You can easily view which services you can configure an integration for, check the status of existing integrations, and leverage curated content in the alerts library and out-of-the-box dashboards.\nSee (Limited Availability) Configure Monitoring Integrations for more details.\nAlerts LibraryThe Alerts Library in Sysdig Monitor gives you a recommended list of alerts to configure based on the services running in your infrastructure. The curated content from the Sysdig removes the need for guessing which alerts to configure and takes you from zero to full monitoring coverage faster.\nFor more information, see Alerts Library.\nAlert EnhancementsThe usability of the Alert page has been enhanced to include:\nAbility to create and edit alert groups based on the service that they are representing. The alerts created from alert templates will have groups automatically assigned to them.\nEfficient visual cues to see alert activities and identity the alerts that are not resolved. A bell icon next to an alert indicates that it has not been resolved. Alerts that are active over the past two weeks will have an event chart under the Activities Over Last Two Weeks column and an event feed on the alert details slider.\nFor more information, see Manage Alerts.\nEnhanced Kubernetes DashboardsWe have introduced several improvements to the out-of-the-box Kubernetes dashboards:\nWorkload dashboards are refreshed with relevant status and golden signals.\nImproved UX with panel location and color code.\nSome workflows are simplified to make it easier for beginners in Kubernetes\nImproved capacity planning capabilities.\nText boxes are easier to read and locate near the relevant panels.\nJuly 19, 2021Customized Session ExpirationSession expiration is the amount of time a user can remain idle before the session is automatically ended or expired. After the session expires, the user must log in to the Sysdig application again.\nSysdig now gives you the ability to make a shorter or longer idle session expiration for Sysdig applications. When a user browser is idle for a certain period of time, they will get automatically logged out. For more information, see Configure Customized Session Expiration.\nEnhanced Session LogoutTo offer superior user security, the logout procedure has been enhanced. When the users log out of a Sysdig application, they will be automatically be logged out of both Monitor and Secure applications.\nJune 01, 2021PromQL LibraryWe have compiled a list of PromQL queries to give you one-click insights into the health and performance of your infrastructure. The library also includes a PromQL 101 category to give you hands-on exposure to PromQL. For more information, see PromQL Library.\nPrometheus Remote WriteSysdig supports ingesting metrics from Prometheus servers by using remote_write capabilities. In Sysdig terminology, the remote endpoints that can read Prometheus metrics are known as Prometheus Remote Write. Prometheus Remote Write does not require the Sysdig agent to be installed in the Prometheus environment. This facility expands Sysdig monitoring capability beyond Kubernetes and regular Linux kernels to environments where the Sysdig agent cannot be installed.\nFor more information, see Prometheus Remote Write.\nDark ModeThe dark appearance, known as Dark Mode, is available in Sysdig applications.\nSysdig can now automatically match your OS preferences. Available in Sysdig platform on-premises, or in SaaS in the US East and rolling out globally. For more information, see Configure Theme Preference.\nImproved Dashboard TemplatesThe following Dashboard templates have been enhanced to display the data better, return improved results, and add golden signals.\nKubernetes\nApplication\nNgnix\nCeph\nNgnix Ingress\nElasticSearch\nRedis\nMay 10, 2021Silencing Alert NotificationsSysdig Monitor allows you to silence alert notifications for a given scope for a predefined amount of time, and schedule silence in advance. When silenced, the alert will still be triggered and posted on the Events feed and in the graph overlays but will indicate it has been silenced. The types of notification channels you can use are Email, Slack, and Amazon SNS.\nYou will be notified 30 minutes before the start time and 30 minutes before the end time of a silence window. You will also be able to easily extend or end an active silence. To access the feature, navigate to Alerts \u0026gt; Silence on the Monitor UI.\nFor more information, see Silence Alert Notifications.\nWorkload LabelSysdig Monitor now supports two new labels, kubernetes.workload.name and kubernetes.workload.type which can be used for scoping Dashboards and configuring Gropings.\nEarlier, each type of object (deployment, replicaset, statefulset, etc.) was unique, and in turn, you needed to use different types of Kubernetes Dashboards and a different Grouping resulting in n/a, where distinct types of Kubernetes objects are listed.\nFor more information, see Unified Workload Labels.\nNew Kubernetes Dashboards Available Resources Calculator\nEnsure there is sufficient capacity in a cluster to deploy a new application.\nApplication Status\u0026amp;Overview\nUnderstand the status of applications (workloads) running in a cluster by monitoring performance, pod health, and resource usage\nCluster Capacity Planning\nMonitor the capacity of Kubernetes clusters ensuring they\u0026rsquo;re correctly sized to support new applications when they\u0026rsquo;re deployed.\nContainer Resource Usage\u0026amp;Troubleshooting\nUnderstand the performance of the different containers running in pods across your infrastructure and identify any that are behaving anomalously.\nNode Status\u0026amp;Overview\nMonitor the health, resource usage, and network statistics for nodes running in clusters\nPod Rightsizing\u0026amp;Capacity Optimization\nOptimize your infrastructure and better control cluster spend by ensuring pods are sized correctly. Understand if you can free up resources by reducing memory and/or CPU requests.\nPod Scheduling Troubleshooting\nIf a pod cannot be scheduled due to insufficient resources, use this dashboard to identify where the resource bottleneck is.\nPod Status\u0026amp;Overview\nMonitor the health, resource usage, and network statistics for pods running as part of workloads.\nApril 26, 2021Extended Label SetRunning PromQL queries is now smoother and faster with the extended label set. The extended label set is created by augmenting the incoming data with the rich metadata associated with your infrastructure and making it available in PromQL. You now no longer have to write complex queries in order to troubleshooting infrastructure issues or building dashboards and alerts. For more information, see Run PromQL Queries Faster with Extended Label Set.\nMicrosoft Team ChannelYou can now use Microsoft Team s as a notification channel in Sysdig Monitor. See Configure a Microsoft Teams Channel for more details.\nS3-Compatible Storage for Capture FilesConfiguring S3-compatible storage, such as Minio or IBM Cloud Object Storage, for your Sysdig captures is now supported on Sysdig Monitor. The capability can be turned on by configuring the system appropriately, as given in (SaaS) Configure Custom S3 Storage Endpoint.\nWebhook Channel EnhancementsSysdig supports the following on a Webhook channel integration:\nInsecure connections: You now have the ability to skip the TLS verification.\nCustom headers: If your Webhook integrations require additional headers or data you can append to the alert format by using a custom header on the UI. This option is in addition to the existing API facility to add custom headers programmatically.\nView LogDNA Alerts as Sysdig EventsIf your environment has both LogDNA and Sysdig, you can view relevant LogDNA Alerts as Events in Sysdig. These Sysdig Events behave like any other type of Events in Sysdig They will be overlaid on Sysdig graphs, listed in the Event Feed, and can be used to create an Alert in the Sysdig Platform. The link provided in the Event Details redirects you to the LogDNA Platform, in case further investigation is needed. For more information, see LogDNA Events.\nMarch 03, 2021PromQL Query ExplorerPromQL Query Explorer helps you understand metrics and their labels and values, and create queries faster before using them in Dashboards and Alerts.\nPromQL can be used not only with metrics collected from Prometheus endpoints but also with Sysdig native metrics collected by the agent. For more information, see PromQL Query Explorer.\nIBM Cloud FunctionsYou can now use IBM Cloud Functions as a notification channel in Sysdig Monitor. See Configure IBM Cloud Functions Channel for more details.\nSAML Single LogoutSysdig supports SAML Single Logout. This feature enables you to configure automatic logout from the Identity Provider when users log out of Sysdig. This feature is currently available for SaaS regions US-West and EU-Central. For more information, see Configure SAML Single Logout.\nEnhanced Dashboard Scope SessionWhen returning to a previously visited Dashboard the UI retains your last used scope.\nFebruary 05, 2021Import Prometheus Alert RulesYou have now the ability to import Prometheus alert rules into Sysdig Monitor. The ease of YAML import makes it significantly convenient to tap into Prometheus ecosystem resources, such as promcat.io.\nFor more information, see Import Prometheus Alert Rules.\nUX ImprovementsSysdig Monitor interface has been enhanced to provide the following capabilities:\nEdit dashboard scopes in a panel editor.\nSet a dashboard template as the team entry point.\nJanuary 05, 2021Improved AlertsThe Alert interface has been improved to allow faster browsing and easier management. For more information, see Alerts.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-monitor-release-notes/2021-archive/"},{"id":171,"title":"Cluster Shield Release Notes 2024","content":"1.6.0 Dec 11, 2024 The new Admission Control feature for Vulnerability Management (VM) and Kubernetes Security Posture Management (KSPM) in Cluster Shield is in active development. If you are interested in using this feature, contact your Sysdig representative.\nBreaking Changes Renamed the deny_on_error parameter into failure_policy under the admission_control configuration. The failure_policy parameter will now be a string accepting Ignore (default) and Fail as a value. Feature Enhancements The helm chart now triggers a new deployment when TLS Certificates changes. Added additional DEBUG-level logs and prometheus metrics to expose the total memory visible from the application and the limits assigned to each component. Defect Fixes Fixed an issue that caused the application to use the wrong API endpoint when you select \u0026ldquo;in1\u0026rdquo; region. Fixed an issue with the Kubernetes Metadata feature to ensure that it correctly tracks terminated containers. Fixed an issue that prevented the Container Vulnerability Management feature from performing scans correctly using Admission Control . Fixed some issues that prevented the Admission Control feature from correctly rejecting pods and comunicate with the backend. 1.5.1 Nov 15, 2024Defect Fixes Fixed an issue where the Kubernetes Metadata feature was not sending init container IDs to the Sysdig backend. This resulted in missing Kubernetes metadata for events associated with those containers. 1.5.0 Nov 05, 2024Feature Enhancements The audit parameter now lets you set webhook_rules.\nThe webhook_rules parameter lets you specify a list of rules used to determine if a request should be audited.\nThe Container Vulnerability Management feature now emits a WARN-level log when a Runtime Scanner is running on the same cluster.\nDefect Fixes Fixed a defect that caused the Kubernetes Metadata feature to correctly use the specified annotations_allowlist. Fixed a defect that caused the Kubernetes Metadata feature to correctly live-reload the configuration upon changes. Fixed a defect that caused the cluster_config.tags validation to throw an error when keys did contain the . character. Fixed a defect that caused the Container Vulnerability Management feature through Admission Control to not correctly propagate errors. 1.4.0 Oct 02, 2024Feature Enhancements The admission_control parameter now allows to set excluded_namespaces.\nThe excluded_namespaces parameter lets you specify a list namespaces that will be exempted from the admission validation.\nThe audit parameter now allows to set excluded_namespaces.\nThe excluded_namespaces parameter lets you specify a list namespaces that will be exempted from events watching.\nThe cluster_config parameter now allows to set tags.\nThe tags parameter lets you specify an additional set of tags that will be applied to the metadata sent to the backend.\nAdded support for replicationcontrollers events in Container Vulnerability Management feature.\nDefect Fixes Fixed a defect that caused the Container Vulnerability Management feature to wrongly identify Bouncy Castle crypto java package. 1.3.1 Sep 10, 2024Defect Fixes Fixed a defect where the Container Vulnerability Management feature used incorrect credentials to pull an image from a registry. This occurred when the image pull string resolved by the container runtime differed from the one set in the Kubernetes workload manifest. 1.3.0 Sep 03, 2024Breaking Changes Renamed internal component names to complete the transition to features. Now log groups and metric contain the feature names instead. Feature Enhancements The helm chart now supports to set an existing secret for TLS Certificates used by the application.\nAdded a new prometheus metric that expose the enablement status of each feature.\nThe Container Vulnerability Management feature now detects GO runtime vulnerabilities.\nThe kubernetes_metadata parameter now allows to set annotations_allowlist.\nThe annotations_allowlist parameter lets you specify a list of annotations to be included for each resource. This configuration is particularly useful for generating KSM annotation metrics.\nDefect Fixes Fixed a defect that causes existing secret credentials to be injected as environment variables Fixed a defect that caused the Admission Control feature to use IPs instead of FQDN when a proxy is configured 1.2.0 Aug 05, 2024Breaking Changes The helm chart value image.repository has been split into two different values: image.registry and image.repository. These two values are then concatenated to create the image pull string. If global.imageRegistry is provided, it will override image.registry. If you currently have the setting image.repository should update your values to this new structure. Feature Enhancements Added support for in1 SaaS region. Added support for pods events in Admission Control feature parameter. Allow to tune up the configuration for Container Vulnerability Management feature to properly manage the file size for processed files. Improve manifests parsing on Java packages detection. Fixed Vulnerabilities CVE-2024-41110 Defect Fixes Fixed a defect that could cause truncated log lines. Fixed a defect that could cause the helm chart generated Configmap to not be properly formatted. Fixed a defect that could cause the helm chart to generate an uneeded empty ValidatingWebhookConfiguration. Fixed a defect that could cause the Admission Control and the Posture features to ignore the ssl.verify configuration. Fixed a defect that could cause the Admission Control and the Posture features to not properly use a proxy connection. Fixed a defect that could cause the Container Vulnerability Management feature to incorrectly handle responses from older versions of Sysdig On-premises Backend. Fixed a defect that could cause the helm chart to not use CA Certificates when defined in the global section. Fixed a defect that could cause the helm chart installation to fail if the kubernetes_metadata parameter is enabled and the global.sysdig.region is defined. Fixed a defect that could cause communication issues with the Audit and the Admission Control features on clusters using custom CNI. Fixed a defect that define namespace in ValidatingWebhookConfiguration resource created by the helm chart 1.1.2 Jul 18, 2024Defect Fixes Fixed a defect that could cause the Container Vulnerability Management feature to scan images using the x86_64 architecture in arm64 clusters. 1.1.1 July 09, 2024Defect Fixes Fixed a defect that prevented the Container Vulnerability Management feature to properly manage the file size for processed files. 1.1.0 July 03, 2024Feature Enhancements Ability to run on GKE when the cluster is configured to run with the Autopilot functionality. To enable this feature, add the flag --set global.gke.autopilot=true to the configuration while installation.\nAdded support for Windows worker nodes. Once installed with the kubernetes Metadata feature enabled, it pair with the Windows Agent to include kubernetes information in the events reported by the Sysdig backend.\n1.0.1 June 17, 2024Feature EnhancementsAdded the ability to configure ports used by Admission Control and Audit\n1.0.0 June 12, 2024Fixed Vulnerabilities CVE-2024-24789 CVE-2024-24790 0.11.0 June 5, 2024Feature Enhancements Ability to configure external distributed cache Introduced Container Vulnerability Management feature through Admission Control Secure API token is no longer required to configure Cluster Shield for Sysdig SaaS Posture feature now collects information about secrets for Inventory Fixed Vulnerabilities CVE-2024-2961 CVE-2024-33599 CVE-2024-32473 CVE-2024-33600 CVE-2024-33601 CVE-2024-33602 Defect Fixes Fixed a defect that was preventing already existing credential secrets to be correctly loaded Fixed a defect causing some components to panics due to a missing message keys in their logs Set exit code correctly when the application ends with an error Fixed a memory leak when the Kubernetes Metadata feature was enabled Fixed a memory leak issue when the Container Vulnerability Management feature was enabled Fixed a defect that was blocking the application while starting Admission Control Fixed a defect preventing to display DEBUG-level logs Fixed a defect which could cause long-running workloads to disappear from the UI for Container Vulnerability Management 0.10.1 May 3, 2024Fixed an issue preventing Cluster Shield to read access_key and secure_api_token from already existing secrets.\n0.10.0 May 2, 2024Feature Enhancements Improved communication with the Sysdig backend by reducing the network footprint for Container Vulnerability Management feature Improved pull secrets retrieval, reducing the memory footprint by filtering supported secret types and adding support for pagination for Container Vulnerability Management feature Decreased the time required to see preliminary container vulnerability results in the UI Ability to configure sysdig_endpoint using region Introduced liveness and readiness probes in the helm chart Fixed Vulnerabilities CVE-2023-45288 CVE-2024-29018 Defect Fixes Fixed a defect that could cause Container Vulnerability Management feature to ignore the image digest, running the risk of analyzing an incorrect image Set correct exit code for sub-processes when running in multi-process mode Fixed TLS certificate generation that was causing issues on AKS clusters 0.9.0 April 15, 2024Enhancements Supports sending the k8s_metadata message. The agent retrieves the tags used for the Cost Advisor feature from k8s_metadata. 0.8.0 April 4, 2024Enhancements You can now use an already existing secret (managed from outside the cluster-shield helm chart) to deploy information like Secure API Token and Access Key. Internal communication use TLS by default. The Kubernetes Metadata feature now support monitor events The Kubernetes Metadata feature now support short lived resources 0.7.0 March 19, 2024Enhancements Added the Kubernetes Metadata feature lets you collect cluster metadata replacing the Delegated Agent functionality. The Cluster Shield can now be executed as single process. Added onPremCompatibilityVersion in the helm chart that can be used to specify the on-prem version used. Breaking changes Configuration for the container_vulnerability_management parameter: offline_analyzer is not longer available, if you set it please remove it from the configuration. platform_services_enabled is now enabled by default registry_verify_certificate is now replaced by registry_ssl March 07, 2024Sysdig Cluster Shield Released as Controlled AvailabilitySysdig is delighted to announce the controlled availability of Sysdig Cluster Shield. This solution consolidates multiple agent deployments into a single containerized component, marking a significant advancement in simplifying the deployment, management, and configuration of the Sysdig suite of security and compliance tools at the cluster level. By streamlining operations for Kubernetes environments, Cluster Shield makes it easier than ever to maintain your security and compliance posture.\nFor more information, see Sysdig Cluster Shield.\n","url":"https://docs.sysdig.com/en/release-notes/sysdig-cluster-shield-release-notes/2024-archive/"},{"id":172,"title":"Cloud Shield Release Notes 2025 Archive","content":"0.8.3 December 15, 2025Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-59375 CVE-2025-61727 CVE-2025-61729 CVE-2025-9714 CVE-2025-4598 0.8.2 November 24, 2025Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2024-25621 CVE-2025-64329 CVE-2025-6965 CVE-2024-56433 0.8.1 October 27, 2025Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-32988 CVE-2025-32989 CVE-2025-32990 CVE-2025-6395 0.8.0 September 29, 2025Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-5914 CVE-2025-6020 CVE-2025-8941 CVE-2025-32414 CVE-2025-32415 CVE-2025-8194 0.7.1 August 13, 2025Defect Fixes Resolved an issue affecting the scanning of Amazon Linux instances. Vulnerability FixesThis release addresses the following security vulnerability:\nCVE-2025-7425 0.7.0 August 1, 2025What\u0026rsquo;s NewSysdig Cloud Shield provides agentless scanning capabilities while giving customers full control over where and how their data is processed. Designed to meet the highest standards for data sovereignty, privacy, and regulatory compliance, Cloud Shield ensures that all sensitive workload data remains entirely within your cloud environment, with only redacted metadata sent to Sysdig for analysis and visualization.\n","url":"https://docs.sysdig.com/en/release-notes/cloud-shield-release-notes/2025-archive/"},{"id":173,"title":"Host Shield for Linux Release Notes (2025)","content":"14.3.1 December 18, 2025 Supported sysdig-deploy version: 1.99.5 Supported Falco Engine version: 1000.51 Supported shield chart version: 1.25.3 Defect Fixes Fixed an issue that could cause crashes when a specific combination of features was enabled simultaneously. Resolved Sysdig Shield restarts caused by custom Falco rules using container timestamp and probe fields. Existing rules using these fields will function as expected. For more details, see Known Issues. Removed the extra configuration requirement for File Integrity Monitoring (FIM). Previously, FIM required setting an additional flag (security.enabled: true) for the feature to work correctly. This dependency has now been removed. FIM operates as expected without any extra configuration. Vulnerability Fixes CVE-2025-61727 CVE-2025-61729 CVE-2025-66418 CVE-2025-66471 CVE-2025-4598 CVE-2025-9714 14.3.0 December 04, 2025 Supported sysdig-deploy version: 1.99.0 Supported Falco Engine version: 1000.51 Supported shield chart version: 1.25.0 EnhancementsImproved Container Metadata RetrievalContainer metadata retrieval is redesigned to use container-runtime listen APIs. Previously, Host Shield retrieved container information asynchronously on the first process event (clone, execve, fork) inside the container, which could result in missing container metadata for the earliest syscall events.\nWith the new design, Host Shield now receives container metadata at container creation time, before the container is scheduled for execution, typically thousands of events or up to 100 ms earlier. This ensures container details are available from the very first event.\nSupported Container Engines:\nDocker Podman v4.0.0 onwards containerd CRI (containerd, CRI-O, k3s) LXC BPM Multiple CRI Sockets SupportHost Shield can now connect to multiple CRI endpoints simultaneously. This is useful in environments where multiple container runtimes are available, such as clusters running both containerd and CRI-O.\nNew Container Runtime ConfigurationContainer engine settings have moved to a new container_runtime configuration section. This updated structure provides clearer organization and allows you to define custom socket paths for each engine:\ncontainer_runtime: docker: enabled: true sockets: [\u0026#34;/var/run/docker.sock\u0026#34;] podman: enabled: true sockets: [\u0026#34;/run/podman/podman.sock\u0026#34;] cri: enabled: true sockets: [\u0026#34;/run/containerd/containerd.sock\u0026#34;, \u0026#34;/run/crio/crio.sock\u0026#34;] The previous container_engines configuration keys will continue to be supported for 12 months, until November 2026, to ensure backward compatibility.\nFIM DetectionsA new Sysdig Secure Runtime detection type, File Integrity Monitoring (FIM) is now available. Refer to the FIM configuration page to learn how to enable and configure it.\nMalware Detections: Extended YARA SupportThis Host Shield version introduces expanded support for the YARA language, including rules that use wildcards. This enhancement enables the Threat Research Team to deliver additional YARA rules that are fully compatible with this and future Shield versions. See malware policy for more details.\nImproved Host Scanner Container Runtime Socket Path HandlingThe container runtime socket path configuration is now simplified to remove ambiguity. The previously supported configuration options:\nhost_scanner.docker_socket_paths host_scanner.podman_socket_paths have been deprecated in favor of the new fields:\nhost_scanner.docker_socket_path host_scanner.podman_socket_path Only one socket path per container runtime is now supported. Deprecated options continue to work for backward compatibility, but only the first value in the socket path list is used.\nTunable Probe Buffer Size and CPU SharingNew configuration options are now available to finetune in-probe event processing:\nsinsp: buffer_size_mb: 8 # default; allowed values: 1–512 (powers of two) universal_ebpf_cpu_per_buffer: 2 # default sinsp.buffer_size_mb: Defines the size (in MB) of the event processing buffer inside the probe. Allowed values are: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512. This setting applies to all probe types.\nsinsp.universal_ebpf_cpu_per_buffer: Controls how internal buffers are shared across CPUs for the Universal eBPF probe. For example, on an 8-core node, setting this value to 2 creates 4 internal buffers, each shared by two CPUs.\nThese options provide greater control over probe behavior during syscall event spikes.\nChanging these settings without consulting Sysdig Support may cause memory issues. Memory allocated in eBPF probes counts toward process limits, and increasing buffer sizes may trigger Kubernetes memory limits or the Agent’s internal watchdog.\nDefect Fixes Fixed an issue that prevented certain HTTP network metrics from being emitted. Known Issues The File Integrity Monitoring (FIM) feature functions as expected. However, it currently requires an additional configuration flag to be enabled:\nsecurity: enabled: true Sysdig is aware of this dependency and will remove the need for this flag in an upcoming release.\nCustom Falco rules that use any of the following fields in their condition or output may cause Sysdig Shield to restart:\ncontainer.start_ts\ncontainer.duration\nproc.is_container_healthcheck\nproc.is_container_liveness_probe\nproc.is_container_readiness_probe As a workaround, update the rule condition to exclude container events or restrict it to specific event types, for example:\nevt.type != container or\nevt.type = \u0026lt;specific type\u0026gt; Sysdig is aware of this and is working on a fix in an upcoming release.\nVulnerability Fixes CVE-2025-47914 CVE-2025-58181 CVE-2025-59375 CVE-2025-9230 14.2.5 November 26, 2025 Supported sysdig-deploy version: 1.96.5 Supported Falco Engine version: 1000.49.0 Supported shield chart version: 1.23.4 Defect FixesThis release is required only for customers who are contacted directly by a Sysdig representative. No upgrade is needed otherwise.\n14.2.4 November 19, 2025 Supported sysdig-deploy version: 1.96.4 Supported Falco Engine version: 1000.49.0 Supported shield chart version: 1.23.2 Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2024-25621 CVE-2025-47913 CVE-2025-52881 CVE-2025-58187 CVE-2025-6965 CVE-2025-53905 CVE-2025-53906 CVE-2025-64329 CVE-2024-56433 14.2.3 October 30, 2025 Supported sysdig-deploy version: 1.96.0 Supported Falco Engine version: 1000.49.0 Supported shield chart version: 1.22.0 Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-58183 CVE-2025-58185 CVE-2025-58186 CVE-2025-58188 CVE-2025-61723 CVE-2025-61724 CVE-2025-61725 CVE-2025-47912 CVE-2025-50181 CVE-2025-50182 CVE-2025-53057 CVE-2025-53066 CVE-2025-54388 CVE-2025-54410 CVE-2025-58189 14.2.2 October 08, 2025 Supported sysdig-deploy version: 1.95.3 Supported Falco Engine version: 1000.49.0 Supported shield chart version: 1.21.1 UpdatesHost PostureUpdated KSPM Analyzer component in Host Posture for improved resiliency. See KSPM Analyzer release notes for more details.\nDefect Fixes Fixed an issue causing app checks to progressively consume more memory unexpectedly. Fixed an issue preventing Shield from starting in legacy eBPF mode on most recent kernels (6.16.1, 6.15.10, 6.12.42, 6.6.102, 6.1.148 and later). Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-47906 CVE-2023-52323 CVE-2025-32988 CVE-2025-32989 CVE-2025-32990 CVE-2025-47907 CVE-2025-6395 14.2.1 September 9, 2025 Supported sysdig-deploy version: 1.93.2 Supported Falco Engine version: 1000.49.0 Supported shield chart version: 1.19.1 EnhancementsPre-filled DNS Cache for IBM Cloud Metadata ServiceThe DNS cache is now automatically pre-filled to avoid resolving the IBM Cloud metadata service HTTPS endpoint, improving reliability.\nDefect Fixes Fixed the legacy AppChecks for MongoDB. For X.509 authentication, ssl_keyfile is no longer supported. Instead, provide both the certificate and key in a single file specified with ssl_certfile. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-8194 CVE-2025-6020 CVE-2025-8941 14.2.0 August 28, 2025 Supported sysdig-deploy version: 1.93.0 Supported Falco Engine version: 1000.49.0 Supported shield chart version: 1.18.0 EnhancementsIPv4 and IPv6 Enrichment for Secure Threat EventsHost Shield can now enrich Sysdig Secure threat events with the IPv4 and IPv6 addresses of related instances. See configuration for more details.\nNew Metric for Container FilesystemAdded a metric sysdig_container_fs_rw_used_bytes to monitor read/write usage on container filesystems.\nAdded Oracle Cloud (OCI) and IBM Cloud Metadata in EventsEvents now include metadata from Oracle Cloud (OCI) and IBM Cloud for improved visibility and context. To disable OCI and IBM metadata, add the following settings to your Shield chart configuration.\nhost: additional_settings: collect_ibm_metadata: false # To disable IBM metadata collection collect_oci_metadata: false # To disable OCI metadata collection Selective enablement of Response ActionsResponse actions can be now enabled/disabled individually, to manage the permissions granularly, based on the actions that you want to employ in your environment. For more details, see Response Actions.\nDefect Fixes Resolved AppChecks compatibility issues with specific Python versions. Resolved a bug that prevented Host Shield from correctly detecting Windows vulnerabilities. skip_events_by_process now skips child processes spawned both before and after the Agent starts. Known Issues AppChecks for MongoDB metrics are not functional in this release. A fix will be available in an upcoming release. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-5914 CVE-2025-7425 CVE-2025-32414 CVE-2025-32415 CVE-2025-54388 CVE-2025-8058 CVE-2022-29458 14.1.1 August 5, 2025 Supported sysdig-deploy version: 1.91.1 Supported Falco Engine version: 1000.47.0 Supported shield chart version: 1.15.2 Defect Fixes Fixed an issue that prevented CPU profiles from being generated. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-30749 CVE-2025-50106 CVE-2025-6965 CVE-2024-23337 CVE-2024-52533 CVE-2025-30754 CVE-2025-30761 CVE-2025-4373 CVE-2025-48060 14.1.0 July 28, 2025 Supported sysdig-deploy version: 1.90.0 Supported Falco Engine version: 1000.47.0 Supported shield chart version: 1.13.0 EnhancementsMetadata Retrieval Timeout Configuration Introduced a new flag custom_container.metadata_deadline_secs to configure the time window during which metadata can be retrieved. Timestamped CPU Profile Storage The runtime agent now stores CPU profiles with date and time in the file names. Defect Fixes Fixed an issue where the probe download script incorrectly reported the eBPF probe download as successful, even in case of failure. Added support for detecting libpod containers running with the cgroups mode set to split. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2024-12718 CVE-2025-4138 CVE-2025-4517 CVE-2025-4673 CVE-2025-49794 CVE-2025-49796 CVE-2025-6020 CVE-2025-0913 CVE-2025-22874 CVE-2025-25724 CVE-2025-3576 CVE-2025-4330 CVE-2025-4435 CVE-2025-5702 CVE-2025-6021 14.0.1 June 25, 2025 Supported sysdig-deploy version: 1.87.1 Supported Falco Engine version: 1000.45.0 Supported shield chart version: 1.11.1 Defect Fixes Fixed build failures of the legacy eBPF probe on the most recent 6.15 kernels. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-4673 CVE-2025-0913 14.0.0 June 17, 2025 Supported sysdig-deploy version: 1.86.0 Supported Falco Engine version: 1000.45.0 Supported shield chart version: 1.9.0 This release introduces major changes, including performance improvements, new defaults, and component deprecations. Review carefully, as some updates may require action.\nEnhancementsDynamic Syscall FilteringHost Shield introduces a new capability, Dynamic Syscall Filtering, to improve performance and resilience while reducing the resource requirements. This feature is enabled by default. It monitors the system calls required for active features, plugins, and policies, significantly reducing system call volume and system overhead. This dynamic filtering improves performance and resilience, especially in lightweight Host Shield modes and high-load environments, by lowering CPU and memory usage. For more details, see Dynamic Syscall Filtering.\nSecure Light Default ModeThe shield and sysdig-deploy helm charts now switch to secure_light mode by default when monitor features are not enabled, delivering significantly improved performance and reliability out of the box.\nImproved Posture Connectivity ResiliencyChanged the default transport protocol for the Posture feature from nats to https to improve resilience against transient network failures and round-trip communication issues.\nNew Option to Skip Failed DNS RequestPreviously, the dns_detection feature did not raise events for failed DNS requests. Now, dns_detection processes all DNS requests, including failed ones, and consequently applies policies on the raised events. You can enable the new dns_detection.skip_failed_requests option (disabled by default) in the shield chart to restore the previous behavior of skipping failed DNS requests and prevent related events from being raised. This helps reduce noise if these types of errors are not relevant to your environment.\nFlatcar OS supportedFlatcar OS is now supported on Sysdig Shield.\nDeprecationsCustom App Checks SunsetCustom App Checks are no longer supported.\nAppChecks Python 2.7App Checks using Python 2.7 is no longer supported.\nMinimum Kernel Version Set to 3.10Linux kernel versions older than 3.10 are no longer supported.\nDefect FixesFixed Kernel Header Install on Debian Fixed an issue where the install script on Debian-based systems was unexpectedly installing Kernel headers even when universal eBPF was selected. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-30698 CVE-2025-30691 CVE-2025-24528 CVE-2025-22872 CVE-2025-22871 CVE-2025-21587 CVE-2025-4802 CVE-2023-4752 CVE-2025-0938 CVE-2025-0395 CVE-2024-12243 CVE-2024-12133 CVE-2024-8176 13.9.2 May 22, 2025 Supported sysdig-deploy version: 1.84.2 Supported Falco Engine version: 1000.42.0 Supported shield chart version: 1.6.3 Defect Fixes The install script now skips unnecessary kernel header installation on Debian systems when universal eBPF is selected, enabling faster, cleaner installs with reduced dependencies. Vulnerability FixesThis release addresses the following security vulnerability:\nCVE-2025-46569 13.9.1 May 09, 2025 Supported in chart sysdig-deploy version: 1.83.0 Supported Falco Engine version: 1000.42.0 Supported in chart shield version: 1.6.0 Defect FixesFixed an issue in the Universal eBPF driver that introduced increased latency for the sendmmsg and recvmmsg syscalls.\n13.9.0 May 1, 2025 Supported in chart sysdig-deploy version: 1.81.0 Supported Falco Engine version: 1000.42.0 Supported in chart shield version: 1.4.0 Known IssueIf you\u0026rsquo;re using Agent version 13.9.0 with the universal_ebpf probe, you may experience high CPU usage and reduced system performance. This issue is related to how the agent handles the sendmmsg and recvmmsg syscalls.\nTo reduce the impact, update your agent configuration to skip these events.\nskip_events_by_type: - recvmmsg - sendmmsg EnhancementsNetwork Security on Secure Light modeNetwork Security (NetSec) is now supported in Secure Light mode, providing feature parity with Secure mode, significantly reducing resource consumption while preserving key security functionalities.\nActivity Audit container interactive processes trackingActivity Audit now focuses on interactive processes inside containers by default, making collected data more relevant and reducing noise. By default only interactive commands (i.e: Actions with a bound TTY) will generate Activity Audit events.\nFor example:\nkubectl -it exec POD -- COMMAND : Event is reported (interactive). kubectl exec POD -- COMMAND : Event is not reported (non-interactive). If you prefer to also include non-interactive executions, you can revert to the previous behavior by enabling this option in your dragent.yaml\nsecure_audit_streams: container_processes_include_non_interactive_exec: true Response ActionsThe fresh new Response Actions feature has been added, allowing you to execute actions on your workloads from Sysdig, to respond to ongoing threats and incidents. The actions included in this release are:\nContainer kill/stop/pause Process kill File quarantine File acquire They are also complemented with the possibility to be reverted, when applicable.\nFor additional information, see Response Actions\nEnhanced overhead of JMX instrumentationJava process metrics can be scraped only if a corresponding hsperfdata file exists. Processes without the hsperfdata file will be skipped. New configuration option allows you to specify a minimum age for hsperfdata files. If an hsperfdata file is younger than this configured threshold, the corresponding Java process will not be scraped.\njmx: enforce_hsperfdata_exists: true jmx_scrape_delay_seconds: 120 Defect Fixes Ensured adherence to agent HTTP health status_port configuration option. Optimized performance in processing data received from the recvmsg syscall. Improved PostgreSQL protocol parsing in Monitor mode to correctly handle potentially malformed packets. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-30204 CVE-2024-40635 CVE-2024-8176 CVE-2024-7592 CVE-2025-29923 ","url":"https://docs.sysdig.com/en/release-notes/linux-host-shield-release-notes/2025-archive/"},{"id":174,"title":"Activity Audit","content":"Activity Audit can provide data about your infrastructure to help prove to auditors that proper data visibility and security measures are in place.\nActivity Audit is a critical requirement for many compliance standards, such as SOC2, PCI, HIPAA and NIST 800-53.\nData SourcesThe available data sources in Activity Audit are:\nCmd (command): Processes executed in an interactive (tty != 0) shell, meaning commands executed by a user logging into the console or through SSH.\nNet (connection): TCP Network connections made to and from user commands, sshd and telnet.\nKubernetes (kubernetes): Kubernetes exec and attach commands extracted from the Kubernetes/OpenShift audit log.\nFile (fileaccess): File activities or modifications related to user commands via Kube or Docker.\nUse the legend at the right side of the Activity Audit graph to filter information from one particular data set.\nPrerequisites To track kubectl exec and other Kubernetes commands, Install Kubernetes audit logging.\nIf you are running on a GKE cluster, review GKE Limitations.\nAccess Activity AuditTo access Activity Audit:\nLog in to Sysdig Secure.\nSelect Threats \u0026gt; Forensics | Activity Audit.\nInvestigate EventsYou can also open Activity Audit from the Events feed:\nLog in to Sysdig Secure.\nSelect Threats \u0026gt; Activity | Events.\nThe Events feed appears.\nFind a policy event.\nYou can group events by policy to filter non-policy events from the feed.\nSelect a policy event.\nThe event details panel appears.\nSelect Investigate \u0026gt; View Activity Audit to investigate details.\nThe Activity Audit page opens in a new tab, filtered to the event you were viewing.\nActivity Audit can correlate interactive requests from a Kubernetes user with the commands and network connections performed inside the container. This lets you trace commands and connections back to users, trace an event\u0026rsquo;s impact, and resolve the issue.\nNavigate the Audit InterfaceActivity Audit displays a continuously updated list of activities. Use the UI features to find and filter the information you need.\nFilter ActivitiesYou can use filters to search, sort, parse, and surface meaningful data and connections in Activity Audit:\nScope: Reduce the scope of your investigation by focusing on a more specific area of your infrastructure. By default, your scope will be set to Everywhere, unless a team scope is defined for your currently selected team.\nData Source: Choose a data source from the right side of the graph. Available data sources are: network activity, commands, kubectl exec, or file. You can select more than one source.\nAttribute (=/!=): Choose = or -!= next to an attribute, either from the list or from the detail view, to include/exclude that attribute from the filter\nAttribute (manual): If you know the attribute, you can type it into the filter box manually, with the following syntax:\nInclude an attribute\nattribute_name=\u0026quot;attribute_value\u0026quot; e.g. comm=\u0026quot;grep\u0026quot;\nExclude an attribute\nattribute_name!=\u0026quot;attribute_value\u0026quot; e.g. comm!=\u0026quot;grep\u0026quot;\nTrace Trace entries to see all relevant activity in a session from a specific user. See the Trace Button paragraph for details.\nFrequency graph: Select a section of the graph to zoom in on a time frame and see detailed activity. For details, see Frequency Graph paragraph.\nCombine: You can combine these methods as needed.\nFor example, the following filter surfaces activity on a particular pod, while excluding activity from one IP address that is known to be normal.\nresource=\u0026quot;pods\u0026quot; name=\u0026quot;woocommerce-6877958\u0026quot; sourceaddresses!=\u0026quot;172.20.41.2\nFrequency GraphThe graph shows the activity frequency for each data source, letting you easily zero-in on anomalies.\nThe image above shows a spike in network activity (purple line) between 12:00 - 3:00 pm.\nDrag the mouse over the peak to auto-zoom on the time frame and see more detail.\nTime Navigation ButtonsUse the time window navigation bar to show only activities run within that window.\nActivity Row and DetailsSelect an activity row to see its details on the right panel, including all the collected attributes. You can add filters:\nTo include a value, select =. To exclude a value, select !=. See Review Activity Details for the attributes of each data source.\nYou can also perform quick filtering by selecting attribute and filter type directly from the activity row. Trace Button for kube exec and Shell ActivitiesBeside each activity originating a trace there is a Trace button . The Trace button is only available for the following events:\nkube exec kube attach ssh dropbear shells (*sh) The Trace button lets you correlate activities from the originator to each single performed operation. See Follow a kubectl exec Trace use case to see it in action.\nThis button does not appear if you are running on a GKE cluster.\nkubectl runThe Kubernetes event in the activity audit list labeled kube run is received from the AC in the following cases:\nA kubectl run is performed A kubectl attach is performed Review Activity DetailsCommand Details\nName\nDescription\nTime\nThe date and time the command was executed.\nCommand\nThe command executed.\nFull Command Line\nThe complete command, including all variables/options.\nWorking Directory\nThe directory the command was executed in.\nScope\nThe entities within the infrastructure impacted by the command, including\nKubernetes namespace name\nKubernetes deployment name\nKubernetes cluster name\nKubernetes pod name\nHost\nThe hostname and MAC address of the host the command was executed on. The hostname value is expected to match /proc/sys/kernel/hostname contents of the host or container. Additional Details\nDetailed user/host information:\nThe Process ID (PID) of the command.\nThe Parent Process ID (PPID) of the command.\nThe user ID of the user that executed the command.\nThe Shell ID.\nNetwork Connection Details\nOnly TCP connections are captured in activity audit.\nName\nDescription\nTime\nThe date and time of the network connection\nConnection Direction\nIncoming or outgoing connection\nConnection Details\nIncluding:\nTransport-level protocol (lp4)\nClient address, server address (lp4)\nClient port, server port\nScope\nThe entities impacted by the network connection, including\nKubernetes namespace name\nKubernetes cluster name\nKubernetes pod name\nHost\nThe host name and MAC address of the host where the connection was made\nAdditional Details\nThe process name and ID (Parent Process ID/PID) that launched or received the network connection\nKubectl Exec Details\nName\nDescription\nTime\nThe date and time of the kubectl command\nKubernetes resource\nIncluding:\nresource: The kind of Kubernetes resource affected (only pods)\nname: name of the resource (pod name)\nsubresource: exec\ncommand: the command executed\ncontainer: the high-level name in the Kubernetes definition\nKubernetes user and group\nIncluding:\nuser: user name performing the kubectl command. Can be either a service account or a human user.\ngroups: groups the user belongs to\nuserAgent: client userAgent\nSources addresses\nExternal IP address that initiated the connection\nScope\nIncluding\nKubernetes namespace name\nKubernetes deployment name\nKubernetes cluster name\nKubernetes pod name\nHost\nHost name and MAC address of the host where the kubectl exec was made\nFile Activity Details\nName\nDescription\nTime\nDate and time the file was modified\nFile access details\n- File name\n- File directory\n- Command used to access the file\n- Access mode\nScope\nEntities impacted by the file activity, including\nKubernetes namespace name\nKubernetes deployment name\nKubernetes cluster name\nKubernetes pod name\nHost\nThe host name and MAC address of the host where the file activity occurred\nUse CasesLook for Suspicious CommandsDuring an investigation you usually need to find suspicious activities among the most normal and recurring ones.\nIn this example, a ps command is executed very frequently. This creates noise and makes investigations harder.\nYou can use filters to reduce noise and make the investigation easier. Select != beside comm ps exclude the ps command. Once excluded, other, more interesting commands emerge instantly.\nFiltering for Incident ResponseA Policy Event reports a dangerous peak in network connections coming from a specific pod. This example describes one way to search for the root cause.\nWhat user and what activity triggered this issue?\nUse the Respond button next to the policy event to jump directly to the relevant data.\nHere you can determine:\nThe pod/namespace on which the heightened activity is occurring.\nThe process related to the activity (in this case, ab, or the Apache Benchmark tool).\nRelated activities in the graph (cmd and kube exec lines).\nRepetitive entries that can be screened out.\nRefine the view through filtering:\nSwitch from network data source to cmd and kube exe.\nFilter out noisy, repetitive entries (such as comm!=\u0026quot;bash\u0026quot;)\nInvestigate details of a kube exec item for user information.\nAfter filtering, you have a focused incident report detailing:\nThe Kubernetes user \u0026ldquo;johndoe\u0026rdquo;\nThe external IP he used to connect\nThe set of commands he used to install and launch the Apache Benchmark stress-testing tool.\nFollow a kubectl exec TraceIn a production environment, kubectl exec commands are typically suspicious. Because such commands are interactive sessions, it can be difficult to pinpoint which individual has issued the commands and what other activities the individual performed. You can use Sysdig\u0026rsquo;s Trace functionality to correlate kubectl exec commands with a specific user and the network and command activities performed in that user\u0026rsquo;s session.\nIn this example, suspicious activity has been detected and you want to determine whether someone has downloaded and executed a Trojan horse.\nUse the Groups to display your Kubernetes hierarchy by namespace and deployment. Focus on the pod displaying unexpected high levels of activity (based on the number in parentheses).\nCheck the corresponding activity graph and zero in on a time frame and see kube exec activity among the hundreds of commands and network events.\nSelect the kube exec item and click the Trace button on left.\nThis session trace displays a formatted report of any container activity (network, commands) that the user performed inside the container.\nThis button does not appear if you are running on a GKE cluster.\nStore Activity Audit DataActivity audit data retention limits are defined in the dedicated documentation page.\nIf you need to retain events for longer periods, you can use SIEM and Data Platforms to send logs to a storage solution of your choice. Additionally, Captures let you take snapshots of all the activity happening on the host when an event occurs, supporting you in triage and investigation.\n","url":"https://docs.sysdig.com/en/sysdig-secure/activity-audit/"},{"id":175,"title":"Add Agent Files","content":"After generating the files, add them to the Support ticket you created.\nDebug the Agent Start Command or Manifest FileMany agent connection problems are due to transcription errors in the agent start command or manifest files.\nThis is especially true with truncated access keys and when using the ADDITIONAL_CONF parameter in a container agent installation. Always cut and paste, and then modify, the Sysdig example commands or manifest files.\nThe Helm values, docker start, and native agent run commands are available in the Secure UI. To find them:\nLog in to Sysdig Secure.\nNavigate to Integrations \u0026gt; Sysdig Agents page.\nSelect Add Agent in the top right corner.\nIf you are not an Admin level user you will not see the installation tab, in this case, please request the instructions from the admin.\nSelect the platform (Kubernetes, Docker, Linux or Fargate).\nCopy the host-shield-compose.yml content and follow the instructions for running it.\nTry running the agent from the command line using the command: docker compose -f host-shield-compose.yml up -d\nEnsure that you have the agent container ID.\ndocker ps -a Stop the container.\ndocker stop \u0026lt;container_id\u0026gt; Debug the container. To do so, create a directory and copy log files to that directory.\nmkdir test_log docker cp sysdig-agent:/opt/draios/logs ./test_log/ Once debugging is complete, start the agent container.\ndocker start \u0026lt;container_id\u0026gt; Send in the command used and initial agent output.\nTip: if using docker start to debug the agent live, remove the \u0026lsquo;-d' option so the output will display on the console.\nSysdig Agent Configuration File and LogsWhen troubleshooting issues such as metrics not reporting, agent connection failures, or abnormal behavior, it is essential to collect the Sysdig Agent configuration and log files. Provide the Sysdig Support team with context-specific diagnostic data to ensure faster and more effective assistance. The method for gathering these files depends on your deployment type, such as Kubernetes, Docker, or native Linux.\nGeneral Guidance Restart the agent before collecting logs to capture critical startup information.\nThe method for restarting the agent depends on your deployment:\nKubernetes:\nDelete the relevant agent Pod to restart it. Kubernetes will automatically create a new Pod:\nkubectl -n NAMESPACE delete pod sysdig-agent-AGENT_ID Docker:\ndocker restart sysdig-agent Linux service-based agents:\nservice dragent restart File locations differ by deployment type:\nIn Kubernetes, configuration is typically sourced from a ConfigMap and logs reside in the agent pod’s filesystem. In Docker deployments, configuration and logs are within the running container. In native Linux installations, files are found directly on the host system. Typical file paths (depending on deployment):\nMain configuration file: /opt/draios/etc/dragent.yaml Log directory: /opt/draios/logs/ Primary log file: /opt/draios/logs/draios.log The agent rotates the log file when it reaches 10MB, retaining the 10 most recent log files, each with a timestamp.\nAlways provide the host name, pod name, or relevant VM/instance where the files were collected.\nCollecting Files by DeploymentKubernetes Deployments Obtain the agent configuration (from the ConfigMap):\nkubectl -n NAMESPACE get configmap sysdig-agent -o yaml \u0026gt; sysdig-agent-configmap.yaml Collect all agent logs:\nkubectl -n NAMESPACE cp sysdig-agent-AGENT_ID:/opt/draios/logs/. . The above command will grab ALL the log files (including the rollovers) and place them in the directory where the command was run.\nFor agent Pods not in Running/Ready state, attach the output of:\nkubectl -n NAMESPACE describe pod sysdig-agent-AGENT_ID \u0026gt; describe-pod.txt Optionally, export the DaemonSet configuration for cluster-level troubleshooting:\nkubectl -n NAMESPACE get daemonset sysdig-agent -o yaml \u0026gt; sysdig-agent-daemonset.yaml Docker Deployments Copy the configuration file and all log files from the running Sysdig agent container:\ndocker cp sysdig-agent:/opt/draios/etc/dragent.yaml ./dragent.yaml docker cp sysdig-agent:/opt/draios/logs/. ./logs/ Linux Agents (.rpm/.deb Packages) Copy the configuration and log files from the host to your workstation:\ncp /opt/draios/etc/dragent.yaml ./dragent.yaml cp -r /opt/draios/logs ./logs/ What to Attach to Your Support Case The agent configuration file, dragent.yaml, as applicable All files from /opt/draios/logs/ or container/pod equivalents For Kubernetes:\nAgent logs sysdig-agent-configmap.yaml sysdig-agent-daemonset.yaml describe-pod.txt for non-running pods Helm values.yaml file used to deploy the agent If OOMKill is occurring, collect logs from the previous container using --previous Also include:\nAny other logs or files relevant to the issue The hostname, pod name, or instance name where the files were collected Compress the files into a .zip or .tar.gz archive and attach them to your support case.\nDebug Log LevelIf requested by Support, enable debug logging in the agent configuration before collecting new logs. For more information, see Debug log level available.\nKubernetes: Check for Delegated AgentsWith agents deployed in a Kubernetes environment, it can be useful to know which agents are \u0026ldquo;delegated\u0026rdquo; to poll the Kubernetes API server.\nTo do this, you must generate agent log files (see above) and search for \u0026lsquo;delegated\u0026rsquo;.\nLogs are stored in /opt/draios/logs/draios.log.\nFor agent versions 0.77.0 or later: you will see log entries stating whether your agent is/is not the delegated node and the exact address of the delegated node.\nSearch for the string \u0026ldquo;Delegated\u0026rsquo;.\nFor agents before version 0.77.0: issue the command:\nkubectl get nodes By default, the top two addresses automatically became delegated polling agents.\nAlternatively, enabling debug mode in agent versions 0.64.0 and beyond will show the node list in any agent logs as well.\nDocker Swarm: Find the Docker Swarm MasterWhen using a Sysdig agent inside a Docker Swarm, metadata (information about inventory, labels, ext..) is collected from the Docker Swarm masters.\nEffort should be made to collect the logs from the masters, and more specifically the \u0026ldquo;leader\u0026rdquo; when a problem with Docker Swarm inventory is suspected.\nTo determine which Docker Swarm nodes are masters and leaders:\nRun the command:\ndocker node ls Example:\n$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS 789sgbfdbtcdtn9npbnkuz worker1 Ready Active 76avknaakzbvmwlnh5jr3g * manager1 Ready Active Leader Under the Manager Status column, you can note which node is the \u0026ldquo;Leader\u0026rdquo;.\n","url":"https://docs.sysdig.com/en/docs/support/submit-a-support-ticket/add-agent-files/"},{"id":176,"title":"Amazon SNS Notifications","content":"SupportAmazon SNS Topic Notifications are supported for the following areas:\nProduct Supported Area Secure Runtime Policies Monitor Alerts AWS ConfigurationTo configure your AWS to integrate with Sysdig:\nSign into the Amazon SNS Console.\nIn the left navigation pane, select Topics.\nThe Topics page appears.\nSelect Create topic or choose an existing topic from the dropdown list.\nThe topic configuration page appears.\nIn the Details section, The topic\u0026rsquo;s name, Amazon Resource Name (optional), display name, and the topic owner\u0026rsquo;s AWS account ID are displayed.\nIn the Details section, enter a name for the topic or select the topic from the list.\nUnder Type, select Standard.\nUnder Access policy - optional, select Basic.\nUnder Publishers - Specify who can publish messages to the topic, select Only the specified AWS accounts and enter the appropriate account ID for your Sysdig SaaS region. To find the correct ID, see AWS Account IDs.\nWhen you have completed configuration, select Create topic.\nEnsure you subscribe to the created topic.\nIn the left navigation pane, choose Subscriptions.\nOn the Create subscription page, enter the Amazon Resource Name (ARN) of the topic you created earlier.\nSpecify other details and click Create subscription.\nFor further information about AWS SNS, refer to the AWS documentation.\nSysdig Configuration Log in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nClick Add Notification Channel +, and select Amazon SNS Topic.\nEnter the Topic created on the AWS side, along with a Channel Name.\nToggle the Enablement, and Notification sliders as appropriate.\nFrom Shared With, choose whether to share this notification channel globally (all teams) or to limit visibility to the team you are currently logged in as.\nClick Save.\n","url":"https://docs.sysdig.com/en/administration/amazon-sns-notifications/"},{"id":177,"title":"Apache","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nApache SetupInstall mod_status on your Apache servers and enable ExtendedStatus. The following configuration is required. If it is already present, then un-comment the lines, otherwise add the configuration.\nLoadModule status_module modules/mod_status.so ... \u0026lt;Location /server-status\u0026gt; SetHandler server-status Order Deny,Allow Deny from all Allow from localhost \u0026lt;/Location\u0026gt; ... ExtendedStatus On Sysdig Agent ConfigurationReview how to edit dragent.yaml to Integrate or Modify Application Checks.\nApache has a common default for exposing metrics. The process command name can be either apache2 or httpd. By default, the Sysdig agent will look for the process apache2. If named differently in your environment (e.g. httpd), edit the configuration file to match the process name as shown in Example 1.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with Apache and collect all metrics.\napp_checks: - name: apache check_module: apache pattern: comm: apache2 conf: apache_status_url: \u0026#34;http://localhost:{port}/server-status?auto\u0026#34; log_errors: false ExampleIf it is necessary to edit dragent.yaml to change the process name, use the following example and update the comm with the value httpd.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\napp_checks: - name: apache check_module: apache pattern: comm: httpd conf: apache_status_url: \u0026#34;http://localhost/server-status?auto\u0026#34; log_errors: false Metrics AvailableThe Apache metrics are listed in the metrics dictionary here: Apache Metrics.\nUI Examples ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/apache/"},{"id":178,"title":"Apache Kafka Consumer Metrics","content":"See Application Integrations for more information.\nkafka.broker_offsetThe current message offset value on the broker.\nkafka.consumer_lagThe lag in messages between the consumer and the broker.\nkafka.consumer_offsetThe current message offset value on the consumer.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/apache-kafka-consumer-metrics/"},{"id":179,"title":"Apache Metrics","content":"See Application Integrations for more information.\napache.conns_async_closingThe number of asynchronous closing connections.\napache.conns_async_keep_aliveThe number of asynchronous keep-alive connections.\napache.conns_async_writingThe number of asynchronous write connections.\napache.conns_totalThe total number of connections handled.\napache.net.bytesThe total number of bytes served.\napache.net.bytes_per_sThe number of bytes served per second.\napache.net.hitsThe total number of requests performed.\napache.net.request_per_sThe number of requests performed per second.\napache.performance.busy_workersThe number of workers currently serving requests.\napache.performance.cpu_loadThe percentage of CPU used.\napache.performance.idle_workersThe number of idle workers in the instance.\napache.performance.uptimeThe amount of time the server has been running in seconds.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/apache-metrics/"},{"id":180,"title":"Architecture","content":" Sysdig AgentSysdig collects monitoring and security information from target entities. To achieve this, one Sysdig agent should be deployed in each host. These hosts can be:\nThe nodes that make up a Kubernetes or OpenShift cluster.\nVirtual machines or bare metal on your physical premises.\nLiving in a cloud environment, for example, Amazon Web Service (AWS), Google Cloud, IBM Cloud, and Azure.\nThe Sysdig agent can be installed as a container using a Helm chart, Kubernetes operator, and so on.\nOnce the agent is installed in the host, it starts collecting information from a variety of sources, such as:\nRunning containers Container runtime The orchestration API, such as Kubernetes, OpenShift, and so on Metrics from defined Prometheus endpoints, Auto-detected JMX sources, StatsD, and integrations The host itself The Sysdig agent maintains a permanent communication channel with the Sysdig backend, and sends messages containing the monitoring metrics, infrastructure metadata, and security events. The channel is secured with standard TLS encryption and transports data as binary messages. The agent uses this channel to transmit data, and to receive additional configuration from the backend, such as security runtime policies or benchmarks.\nSysdig BackendFor the Sysdig backend, you have a choice between:\nUsing the SaaS version, managed transparently by Sysdig, Installing it directly on your premises. Neither choice affects the operations described below. Once the agent messages are received in the backend, they are processed and extracted into data available to the platform, for example, as time series, infrastructure and security events, and infrastructure metadata.\nThe main components of the backend/platform include:\nExtraction and post-processing of the metric data from the agent, so that full time-series, with all the necessary infrastructure metadata, are available to you\nMaintenance of the infrastructure metadata (most notably Kubernetes state), so that all events and time series can be enriched and correctly grouped\nStorage of time-series and event data\nProcessing of time-series data to calculate alert triggers\nQueuing the security events triggered by the agents to be shown on the event feed, notifying through the configured notification channels and alerts and forwarding via the Event Forwarder to external platforms like Splunk, Syslog or IBM Multicloud Manager (MCM) / Qradar\nAggregating and post-processing other security, data such as container fingerprints that are used to generate container profiles, or security benchmark results\nThe Sysdig platform stores this post-processed data in a set of internal databases. The API service combines these to create the data views, such as dashboards, event feeds, vulnerability reports, and security benchmarks.\nSysdig APIsThe Sysdig platform provides several ways to consume and present its internal data. All APIs are RESTful, HTTP JSON-based, and secured using TLS. The same APIs are used to power the Sysdig front end, as well as any API clients (such as sdc-cli).\nMonitor API\nUser and Team management API\nDashboard API\nEvents API\nAlerts API\nData API (proprietary Sysdig API for querying time-series data)\nSecure API\nImage Scanning API\nSecurity Events API\nActivity Audit API\nSecure Overview API\nPromQL API: Prometheus compatible HTTP API for querying time -series data\nThese enable different use cases:\nAccess to the platform via the Sysdig user interface (UI)\nProgrammatic input and extraction of data, i.e.\nAutomatic user creation\nTerraform scripts to save or recover configuration state\nInline scanning to push scanning results from the CI/CD pipeline\nInstrumentation using thesdc-cli.\nPromQL API interface that can be used to connect any PromQL-compatible solutions, such as Grafana.\n","url":"https://docs.sysdig.com/en/administration/on-prem-architecture/"},{"id":181,"title":"AWS","content":"Review AWS Roles and PermissionsThere are two identities involved in the onboarding process:\nInstaller: Either a User or Role that will be used to perform the onboarding. Sysdig does not have access to this identity. Sysdig: A set of IAM Roles created during onboarding with specific, less permissive permissions attached. Sysdig will be given access to these Roles. Prerequisites Sysdig Secure SaaS with Admin permissions. Terraform v1.5.0+ installed or access to CloudFormation. Access to a User or Role with the permissions required to install. Permissions Required to InstallThe Installer must have at least the following roles assigned:\nFor Single Account installations: IAMFullAccess: This policy is required to create IAM Roles and associated permissions. For Organization installations: IAMFullAccess: This policy is required to create IAM Roles and associated permissions. AWSOrganizationsReadOnlyAccess: This policy is required to list Accounts and OUIDs in your Organization. AWSCloudFormationFullAccess: This policy is required to create a CloudFormation StackSet that creates IAM roles in each Account in your Organization. Permissions Granted to SysdigThe installation creates two IAM Roles that Sysdig can access. These Roles have the following permissions attached:\nA Role named sysdig-secure-onboarding-XXXX used to manage the base integration with Sysdig AWSAccountManagementReadOnlyAccess (Organizational install) AWSOrganizationsReadOnlyAccess A role named sysdig-secure-posture-XXXX used to collect an Inventory of cloud resources, and perform CSPM SecurityAudit A Custom IAM Policy containing the following permissions: account:GetContactInformation elasticfilesystem:DescribeAccessPoints lambda:GetFunction lambda:GetRuntimeManagementConfig macie2:ListClassificationJobs waf-regional:ListRuleGroups waf-regional:ListRules bedrock:ListAgents bedrock:GetAgent bedrock:ListKnowledgeBases bedrock:GetKnowledgeBase bedrock:ListGuardrails bedrock:GetGuardrail bedrock:GetModelInvocationLoggingConfiguration Supported AWS RegionsSysdig supports agentless scanning in the following AWS regions:\nRegion Display Name af-south-1 Africa (Cape Town) ap-east-1 Asia Pacific (Hong Kong) ap-northeast-1 Asia Pacific (Tokyo) ap-northeast-2 Asia Pacific (Seoul) ap-northeast-3 Asia Pacific (Osaka) ap-south-1 Asia Pacific (Mumbai) ap-south-2 Asia Pacific (Hyderabad) ap-southeast-1 Asia Pacific (Singapore) ap-southeast-2 Asia Pacific (Sydney) ap-southeast-3 Asia Pacific (Jakarta) ap-southeast-4 Asia Pacific (Melbourne) ca-central-1 Canada (Central) eu-central-1 Europe (Frankfurt) eu-central-2 Europe (Zurich) eu-north-1 Europe (Stockholm) eu-south-1 Europe (Milan) eu-south-2 Europe (Spain) eu-west-1 Europe (Ireland) eu-west-2 Europe (London) eu-west-3 Europe (Paris) me-central-1 Middle East (UAE) me-south-1 Middle East (Bahrain) sa-east-1 South America (São Paulo) us-east-1 US East (N. Virginia) us-east-2 US East (Ohio) us-west-1 US West (N. California) us-west-2 US West (Oregon) Need support for a region not listed? Contact your Sysdig representative to request additional region coverage.\nPrepare Your Environment1. Configure Installation PermissionsEnsure the User or Role you log in to AWS with has the necessary permissions to install. You can:\nUse an existing User or Role who meets the permissions requirements. Create a new User or Role and set up permissions. Add permissions to an existing User or Role. Log into AWS and navigate to IAM\u0026gt;Users or IAM\u0026gt;Roles as applicable Open the details of the User or Role that will be used to onboard, and select Permissions Under Permissions policies, verify and add necessary policies. 2. Authenticate and Configure TerraformIf you are installing using CloudFormation, skip to step 3.\nConfigure Terraform to use AWS Credentials for the User or Role from step 1. A simple way is to use the following environment variables:\nAWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_REGION For alternative ways to authenticate Terraform, see the AWS Terraform Provider documentation.\n3. Collect your Account DetailsAccount ID Sign in to the AWS Console. For an Organizational install, ensure you sign in to the Management account of your Organization. Expand the dropdown in the top right corner of your screen and copy your Account ID. (Organizational install) Organization Unit IDsBy default, your entire AWS Organization will be onboarded. If you would like to restrict the onboarding to a subset of your Organization, you can target specific OUIDs.\nSign in to the AWS Console. Expand the dropdown in the top right corner of your screen and select Organization. Note down the list of OUIDs that you would like to onboard. Note: accounts are added recursively below selected OUs, even if there are child OUs within them. Connect AWS using the Wizard Log into Sysdig Secure. Select Integrations \u0026gt; Environments \u0026gt; AWS, and select Add AWS Account in the top right corner. Choose whether to connect your AWS Organization or Single Account. This enables CSPM and lets you onboard Vulnerability Management, CIEM and Threat Detection after completing.\nTerraformOrganization Enter your: Management Account ID: The Account ID of your Organization\u0026rsquo;s Management Account. Primary Region: The region in which to create regional resources such as StackSets OUIDs: Choose how to onboard accounts in your organization: All: Onboard all accounts in the organization. Optionally, specify OUIDs to exclude. Include OUIDs: Onboard only the specified OUIDs. Exclude OUIDs: Onboard all accounts except the specified OUIDs. Enter the OUIDs as a comma-separated list, based on the selected account option. For more details on selective cloud account onboarding, see Selective Cloud Account Onboarding. Generate and apply the Terraform code: Create a main.tf file. Copy the snippet provided into the file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. Ensure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; AWS. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/aws//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;5.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/aws//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;5.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } After deployment, your Accounts will appear on the Cloud Accounts page.\nSingle Account Enter your: Account ID: The Account ID of account you wish to onboard. Generate and apply the Terraform code: Create a main.tf file. Copy the snippet provided into the file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. After deployment, your Account will appear on the Cloud Accounts page.\nCloudFormation Templates Log in to the AWS Account where you want to deploy. For Organizational installs, log into your Organization\u0026rsquo;s Management Account.\nEnter your:\nAccount ID: The Account ID of account you wish to onboard. For Organizational installs, the Account ID of your Organization\u0026rsquo;s Management Account. (For Organizational)OUIDs: Choose how to onboard accounts in your organization: All: Onboard all accounts in the organization. Optionally, specify OUIDs to exclude. Include OUIDs: Onboard only the specified OUIDs. Exclude OUIDs: Onboard all accounts except the specified OUIDs. Enter the OUIDs as a comma-separated list, based on the selected account option. For more details on selective cloud account onboarding, see Selective Cloud Account Onboarding. Click Launch Stack.\nYou are redirected to the AWS Console. Follow the prompts to create the CloudFormation Stack.\nBe sure to check the Acknowledgements in the AWS Capabilities section in the AWS Console.\nWhen complete, return to the Sysdig Wizard and click Complete. Accounts will not appear in the Cloud Accounts page until this button is clicked.\nCheck the Connection StatusTo validate the successful connection of your AWS environment:\nIn Sysdig Secure, select Integrations \u0026gt; Environments \u0026gt; AWS.\nThe Status column shows the overall connection status:\nConnected Error Unknown Select the desired account to review the individual services in the detail drawer.\nYou can view the status of each feature you have enabled.\nFor example, the health status for CSPM onboarding is given below:\nCSPM Status Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Error ❌ Authentication errors. For example: Invalid account IDInvalid client secretInvalid access credentialsAccess token errors Deny policy created by the user is preventing Sysdig from collecting resourcesThe scan takes too long and eventually times out.Unknown error Learn More AWS Cloud Accounts Add New Features ","url":"https://docs.sysdig.com/en/sysdig-secure/connect-aws/"},{"id":182,"title":"AWS CloudTrail CloudConnector Policy","content":" Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nCreate an AWS CloudTrail - CloudConnector PolicyTo create an AWS CloudTrail - CloudConnector policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select AWS CloudTrail - CloudConnector.\nConfigure an AWS CloudTrail - CloudConnector PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate personnel.\nSee also: Set Up Notification Channels.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and AWS CloudTrail - CloudConnector.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy and choose the AWS CloudTrail - CloudConnector to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/aws-cloudtrail-connector-policy/"},{"id":183,"title":"Certificates Management","content":"Specifically, it:\nOptimizes the secure handling of certificates Supports .csr flows Provides a UI for certificate management Adds support for client-side certificates in the events forwarder At this time, the feature is for Sysdig Secure SaaS only, and is integrated with the appropriate event forwarding options:\nSplunk Syslog Webhook Kafka authentication is handled through a different mechanism.\nAccess the Certificates Management Page Log in to Sysdig Secure as admin and navigate to Settings from the user profile.\nSelect Certificates Management.\nContinue with creating a certificate.\nCreate a CertificateFollow the steps below to generate a certificate.\nOnce you\u0026rsquo;ve created a certificate, you can assign the certificate to the event forwarding integrations.\nGenerate a CA-Signed Key and CertYou must have a signed key and certificate from a Certificate Authority (CA), a step that your organization may already have done. If not, follow these steps:\nGenerate the CA key:\nopenssl genrsa -out ca.key 4096 Generate the CA certificate, setting the expiration to 10 years from now:\nopenssl req -x509 -new -nodes -key ca.key -sha256 -days 1825 -out ca.pem You will be prompted to provide details to populate the certificate information. Be as thorough as possible. Save the resulting ca.pem file.\nObtain the Certificate Signing Request (CSR)The Certificates Management UI streamlines the process of obtaining a certificate-signing request (CSR).\nLog in to Sysdig Secure as Admin and select Settings \u0026gt; Certificates.\nClick Upload Certificate or click the three-dot menu and select New CSR.\nUpload the .pem in the Sysdig UI Return to Settings \u0026gt; Certificates and select Upload Certificate.\nAssign the certificate a meaningful name.\nClick Upload and Create.\nThe certificate will appear in the certificates list and can be applied as needed.\nApply Certificate to Event Forwarding Log in to Sysdig Secure as an administrator and select Integrations \u0026gt; Notification Channels.\nChoose an existing or new integration for Splunk, Syslog, or Webhook.\nSelect the correct uploaded certificate from the Certificate field and Save.\nManage CertificatesCheck Where Certs Are UsedEach certificate shows in how many places it is used. Click that number to go to each integration using that certificate.\nRemove a CertificateTo remove a certificate, first make it unused. Open each integration using the certificate and either remove it from the integration or remove the whole integration itself.\nWhen the certificate is no longer used, you can remove it.\nUpdate a CertificateTo update a certificate, add a completely new certificate and update the integrations to use it instead of the old one. Then you can remove the old one.\n","url":"https://docs.sysdig.com/en/administration/certificate_management/"},{"id":184,"title":"Change Agent Log Level Globally","content":"In order of increasing detail, the log levels available are:\nnone fatal critical error warning notice info debug trace The default level (info) creates an entry for each aggregated metrics transmission to the backend servers, once per second, in addition to entries for any warnings and errors.\nSetting the value lower than info may prohibit troubleshooting agent-related issues.\nThe type and amount of logging can be changed by adding parameters and log level arguments shown below to the agent\u0026rsquo;s user settings configuration file here:\n/opt/draios/etc/dragent.yaml\nAfter editing the dragent.yaml file, restart the agent at the shell with: service dragent restart to affect changes.\nNote that dragent.yaml code can be written in both YAML and JSON. The examples below use YAML.\nFile Log LevelWhen troubleshooting agent behavior, increase the logging to debug for full detail:\nlog: file_priority: debug If you wish to reduce log messages going to the /opt/draios/logs/draios.log file, add the log: parameter with one of the following arguments under it and indented two spaces: [ none | fatal | critical | error | warning | notice | info | debug | trace ]\nlog: file_priority: error Container Console LoggingIf you are running the containerized agent, you can also reduce container console output by adding the additional parameter console_priority: with the same arguments [ none | fatal | critical | error | warning | notice | info | debug | trace ]\nlog: console_priority: warning Note that troubleshooting a host with less than the default \u0026lsquo;info\u0026rsquo; level will be more difficult or not possible. You should revert to \u0026lsquo;info\u0026rsquo; when you are done troubleshooting the agent.\nA level of \u0026lsquo;fatal\u0026rsquo; will generate the fewest log entries (use \u0026rsquo;none\u0026rsquo; to disable logging entirely), a level of \u0026rsquo;trace\u0026rsquo; will give the most, \u0026lsquo;info\u0026rsquo; is the default if no entry exists.\nExamples When using Helm charts and passing arguments either using the “–set” flags or the values files, the logPriority parameter allows to directly set both Agent console and file logging priorities. The possible values are “info” and “debug”. This parameter is mutually exclusive with sysdig.settings.log, therefore they should not be used together.\nUsing HELMhelm install ... \\ --set agent.sysdig.settings.log.file_priority=debug \\ --set agent.sysdig.settings.log.console_priority=debug \\ sysdig/sysdig-deploy OR\nhelm install ... \\ --set agent.logPriority=debug \\ sysdig/sysdig-deploy Using values.yamlagent: sysdig: settings: log: file_priority: debug console_priority: debug OR\nagent: logPriority: debug Using dragent.yamlcustomerid: 831f3-Your-Access-Key-9401 tags: local:sf,acct:eng,svc:websvr log: file_priority: warning console_priority: info OR\ncustomerid: 831f3-Your-Access-Key-9401 tags: local:sf,acct:eng,svc:websvr log: { file_priority: debug, console_priority: debug } Using Docker Run CommandIf you are using the \u0026ldquo;ADDITIONAL_CONF\u0026rdquo; parameter to start a Docker containerized agent, you would specify this entry in the Docker run command:\n-e ADDITIONAL_CONF=\u0026#34;log: { file_priority: error, console_priority: none }\u0026#34; -e ADDITIONAL_CONF=\u0026#34;log:\\n file_priority: error\\n console_priority: none\u0026#34; Using daemonset.yaml in Kubernetes InfrastructureWhen running in a Kubernetes infrastructure installed using the v1 method, comment in the \u0026ldquo;ADDITIONAL_CONF\u0026rdquo; line in the agent sysdig-daemonset.yaml manifest file, and modify as needed:\n- name: ADDITIONAL_CONF #OPTIONAL pass additional parameters to the agent value: \u0026#34;log:\\n file_priority: debug\\n console_priority: error\u0026#34; ","url":"https://docs.sysdig.com/en/sysdig-secure/change-agent-log-level-globally/"},{"id":185,"title":"Cloud Shield Release Notes","content":"0.8.8 May 26, 2026Vulnerability FixesThis release addresses the following vulnerabilities:\nCVE-2026-33811 CVE-2026-33814 CVE-2026-39820 CVE-2026-39836 CVE-2026-42151 CVE-2026-42154 CVE-2026-4424 CVE-2026-39823 CVE-2026-39825 CVE-2026-39826 CVE-2026-40179 CVE-2026-42499 CVE-2026-44903 CVE-2026-5121 0.8.7 April 27, 2026Vulnerability FixesThis release addresses the following vulnerabilities:\nCVE-2026-27135 CVE-2026-32280 CVE-2026-32281 CVE-2026-32282 CVE-2026-32283 CVE-2026-32288 CVE-2026-32289 CVE-2026-4111 CVE-2026-4519 0.8.6 March 30, 2026Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-14831 CVE-2025-15366 CVE-2025-15367 CVE-2026-0865 CVE-2026-0915 CVE-2026-1299 CVE-2026-25679 CVE-2026-27142 CVE-2025-15281 CVE-2025-9820 CVE-2026-0861 CVE-2026-27139 0.8.5 February 23, 2026Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-68121 CVE-2025-15467 CVE-2025-47911 CVE-2025-58190 CVE-2025-11187 CVE-2025-12084 CVE-2025-13601 CVE-2025-14104 CVE-2025-69419 CVE-2025-9086 CVE-2025-15468 CVE-2025-15469 CVE-2025-66199 CVE-2025-68160 CVE-2025-69418 CVE-2025-69420 CVE-2025-69421 CVE-2026-22795 CVE-2026-22796 0.8.4 January 26, 2026Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-68973 CVE-2025-6069 CVE-2025-8291 CVE-2024-5642 CVE-2025-6075 ","url":"https://docs.sysdig.com/en/release-notes/cloud-shield-release-notes/"},{"id":186,"title":"CloudWatch Monitoring","content":"Compare AWS Metric Streams and CloudWatch APIsForwarding CloudWatch Metric Streams to Sysdig Monitor offers more granular data, lower latency, and better scalability, though it requires additional AWS resources that incur AWS charges. On the other hand, using the CloudWatch API is easier to set up but delivers less granular data with higher latency, which may not be ideal for troubleshooting.\nMetric Streams CloudWatch APIs Monitors all the AWS services including custom namespaces Monitors a limited set of AWS services (ELB, ALB, RedshiftCluster, EBS, DynamoDB, EC2, ElastiCache, EMR, RDS, and SQS) 1-minute metric granularity 5-minute metric granularity No API polling is needed, eliminating the potential for API throttling AWS CloudWatch API must be polled for metrics, leading to potential API throttling Connect Sysdig Monitor to AWS CloudWatch Metric StreamsCloudWatch Metric Streams can be provisioned with Terraform or Cloudformation. In both cases, the following resources are created in your AWS environment:\naws_cloudwatch_log_group.sysdig_stream_logs aws_cloudwatch_log_stream.http_log_stream aws_cloudwatch_log_stream.s3_backup aws_cloudwatch_metric_stream.sysdig_metric_stream_all_namespaces aws_iam_role.service_role aws_iam_role.sysdig_cloudwatch_integration_monitoring_role aws_iam_role.sysdig_cloudwatch_metric_stream_role aws_iam_role_policy.cloud_monitoring_policy aws_kinesis_firehose_delivery_stream.sysdig_metric_kinesis_firehose aws_s3_bucket.sysdig_stream_backup_bucket Provision AWS CloudWatch Metric Streams with TerraformFor details on provisioning AWS CloudWatch Metric Streams, see the Sysdig Monitor Terraform Repository.\nProvision AWS CloudWatch Metric Streams with Cloudformation Log in to Sysdig Monitor as an Admin.\nIn the left sidebar, select Integration \u0026gt; Cloud Accounts.\nThe Cloud Accounts page appears.\nSelect Add Account \u0026gt; AWS \u0026gt; CloudWatch Monitoring \u0026gt; CloudWatch Metric Streams.\nOpen Use Cloudformation Template to load a Cloudformation stack that provisions CloudWatch Metric Streams.\nConnect Sysdig Monitor to the AWS CloudWatch APISysdig Monitor recommends using role delegation to poll the CloudWatch API in your AWS account. To enable this, Sysdig Monitor must be allowed to assume an IAM role in your AWS account with the necessary permissions. For instructions to set up cross-account IAM role delegation, see Enable AWS Role Delegation with API.\nAlternatively, you can provide an IAM access key and secret key with the same permissions.\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Action\u0026#34;: [ \u0026#34;autoscaling:Describe*\u0026#34;, \u0026#34;cloudwatch:Describe*\u0026#34;, \u0026#34;cloudwatch:Get*\u0026#34;, \u0026#34;cloudwatch:List*\u0026#34;, \u0026#34;dynamodb:ListTables\u0026#34;, \u0026#34;dynamodb:Describe*\u0026#34;, \u0026#34;ec2:Describe*\u0026#34;, \u0026#34;ecs:Describe*\u0026#34;, \u0026#34;ecs:List*\u0026#34;, \u0026#34;elasticache:DescribeCacheClusters\u0026#34;, \u0026#34;elasticache:ListTagsForResource\u0026#34;, \u0026#34;elasticloadbalancing:Describe*\u0026#34;, \u0026#34;rds:Describe*\u0026#34;, \u0026#34;rds:ListTagsForResource\u0026#34;, \u0026#34;sqs:ListQueues\u0026#34;, \u0026#34;sqs:GetQueueAttributes\u0026#34;, \u0026#34;sqs:ReceiveMessage\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } ] } Enable CloudWatch Metric Streams in On-Prem DeploymentsSysdig on-prem versions 6.1.1 and above can collect various types of CloudWatch Metric Streams from your AWS environment. This page outlines the pre-requisites and steps to enable this service in your on-prem deployment.\nPrerequisites Public key certificate: AWS CloudWatch Metric Streams require a public signed-certificate to execute POST request to Sysdig endpoint over https and to validate the certificate. Self-signed certificates will not work. AWS access key and AWS secret key. Sysdig installation uses the credentials to assume the role when you add the AWS account with the credentials. Installation Determine your environment and follow the instructions as given in the On-Prem Installation documentation.\nDownload the installer image.\nWe recommend that you contact your Sysdig Technical Account Manager to help you with the installation that matches your distribution.\nEnsure that the directory with the certificates and the values.yaml are at the same directory level. For example:\n$ ls certs installer-darwin-amd65 values.yaml $ ls certs my.server.cert my.server.key In the values.yaml file, configure parameters as follows:\nsysdig: .... # this flag enables cloudwatch metric streams converter service cloudwatchMetricConverter: enabled: true # AWS secret key and access key that will be used by backend to assume role # if user adds account with role delegation secretKey: \u0026lt;AWS secret access key\u0026gt; accessKey: \u0026lt;AWS access key\u0026gt; # This is to avoid generating self-signed certificates and use custom certificates # path is relative to values.yaml file certificate: generate: false # In some cases this should be a full chain file # with certificate for particular URL plus intermediate certificate(s) # plus root certificate crt: certs/my.server.crt key: certs/my.server.key With the changes in the values.yaml file, the Installer will update the Sysdig backend to enable AWS Cloudwatch Metric Streams.\nStarting from on-premise version 7.4.0 the values.yaml schema has changed. See the release notes for more details.\nYAML Configuration (version 7.4.0 and later)cloudwatchMetricStreamsConverter: enabled: true global: accessKey: \u0026lt;AWS secret access key\u0026gt; secretKey: \u0026lt;AWS access key\u0026gt; certificate: generate: false crt: certs/my.server.crt key: certs/my.server.key Continue with the on-premise installation. ","url":"https://docs.sysdig.com/en/sysdig-monitor/cloud-accounts/connect-aws-account/cloudwatch-monitoring/"},{"id":187,"title":"Cluster Shield Release Notes","content":"1.23.0 May 28, 2026Supported shield chart version: 1.42.0\nEnhancements The audit feature can now poll Kubernetes audit events from CloudWatch Logs when running on EKS nodes. Enable it by setting features.audit.method to audit_backend. Authentication is handled automatically via IRSA if the cluster-shield ServiceAccount is annotated with the appropriate IAM role. Defect Fixes Fixed an issue which could cause Container Vulnerability Management feature to terminate unexpectedly. Vulnerability FixesThis release addresses the following vulnerabilities:\nCVE-2026-33811 CVE-2026-33814 CVE-2026-33997 CVE-2026-34040 CVE-2026-39820 CVE-2026-39836 CVE-2026-41567 CVE-2026-42151 CVE-2026-42154 CVE-2026-42306 CVE-2026-39823 CVE-2026-39825 CVE-2026-39826 CVE-2026-40179 CVE-2026-41568 CVE-2026-42499 CVE-2026-44903 1.22.0 April 24, 2026Supported shield chart version: 1.35.0\nDefect Fixes Fixed an issue causing Admission Controller to incorrectly handle Image Signature Verification due to incorrect evaluation of the certificate timestamp. Fixed an issue causing Admission Controller not to correctly evaluate Image Signature Validation policies when the scope was set to the whole infrastructure. Vulnerability FixesThis release addresses the following vulnerabilities:\nCVE-2026-27135 CVE-2026-32280 CVE-2026-32281 CVE-2026-32283 CVE-2026-33216 CVE-2026-33218 CVE-2026-34986 CVE-2026-39883 CVE-2026-4424 CVE-2026-4519 CVE-2026-32282 CVE-2026-32288 CVE-2026-32289 CVE-2026-33215 CVE-2026-33217 CVE-2026-33219 CVE-2026-33222 CVE-2026-33223 CVE-2026-33246 CVE-2026-33247 CVE-2026-33248 CVE-2026-33249 CVE-2026-5121 1.21.0 March 26, 2026Supported shield chart version: 1.31.0\nDefect Fixes Fixed a bug which could cause a fatal error: concurrent map writes error when analyzing Python uv.lock files. Fixed a bug where RHEL EUS distributions were incorrectly identified as standard RHEL. Resolved an issue where the Kubernetes Lease resource created using Helm was missing standard Kubernetes labels: app.kubernetes.io/name app.kubernetes.io/instance app.kubernetes.io/version Vulnerability FixesThis release addresses the following vulnerabilities:\nCVE-2026-33186 CVE-2026-27141 CVE-2026-4111 CVE-2025-14831 CVE-2025-15366 CVE-2025-15367 CVE-2026-0865 CVE-2026-1299 CVE-2026-25679 CVE-2026-27142 CVE-2025-9820 CVE-2026-27139 1.20.0 February 26, 2026Supported shield chart version: 1.30.0\nEnhancements Lease resources are no longer managed by the Helm chart and are now created directly by Cluster Shield with an ownerReference configured. Their lifecycle is delegated to Kubernetes garbage collection, ensuring automatic cleanup when the owning component is removed. This improves upgrade reliability, prevents orphaned resources, reduces operational complexity, and aligns resource management with native Kubernetes behavior for more predictable deployments. Defect FixesVulnerability FixesThis release addresses the following vulnerabilities:\nCVE-2025-68121 CVE-2025-15467 CVE-2026-24051 CVE-2025-11187 CVE-2025-12084 CVE-2025-14104 CVE-2025-69419 CVE-2025-9086 CVE-2026-0915 CVE-2026-23831 CVE-2026-24117 CVE-2026-24137 CVE-2026-24686 CVE-2025-15281 CVE-2025-15468 CVE-2025-15469 CVE-2025-66199 CVE-2025-68160 CVE-2025-69418 CVE-2025-69420 CVE-2025-69421 CVE-2026-0861 CVE-2026-22795 1.19.0 January 29, 2026Supported shield chart version: 1.27.0\nDefect Fixes Fixed an issue in Response Actions where the Volume Snapshot action failed for deployments with multiple pods sharing the same Persistent Volume Claim (PVC). The action now deduplicates shared PVCs, preventing the too many matching PVCs found error. Vulnerability FixesThis release addresses the following vulnerabilities:\nCVE-2024-5642 CVE-2025-6069 CVE-2025-6075 CVE-2025-8291 CVE-2025-13601 CVE-2025-61726 CVE-2025-61728 CVE-2025-61730 CVE-2025-66564 CVE-2025-68973 ","url":"https://docs.sysdig.com/en/release-notes/sysdig-cluster-shield-release-notes/"},{"id":188,"title":"Collect Prometheus Metrics","content":"Sysdig is compatible with Prometheus HTTP API, allowing you to query your monitoring data programmatically using PromQL, and extend Sysdig\u0026rsquo;s functionality to other platforms, such as Grafana.\nA lightweight Prometheus server is directly embedded into the Sysdig agent to facilitate metric collection. Use Prometheus syntax to filter and label targets, instances and jobs, and configure the agent to identify processes that expose Prometheus metric endpoints on its own host and send findings to the Sysdig collector for storing and further processing.\nPrerequisitesYou do not need to install Prometheus to collect Prometheus metrics.\nAgent CompatibilitySee the Sysdig agent versions and compatibility with Prometheus features:\nSysdig Agent v12.2.0 and AboveThe following features are enabled by default:\nScrape any Kubernetes pods with the following annotation set: prometheus.io/scrape=true Scrape applications supported by Default Integrations. For more information, see Set up the Environment.\nSysdig Agent Prior to v12.0.0Manually enable Prometheus in dragent.yaml file:\nprometheus: enabled: true For more information, see Enable Promscrape V2 on Older Versions of Sysdig Agent .\nSet Up the EnvironmentPrometheus metrics are collected with annotations. This page describes how to set up your environment to collect Prometheus metrics if you are not using Kubernetes Service Discovery.\nIf you are already leveraging Kubernetes Service Discovery, specifically the approach given in prometheus-kubernetes.yml, you might already have annotations attached to the pods that mark them as eligible for scraping. Such environments can quickly begin scraping the same metrics by using the Sysdig agent in a single step.\nIf you are not using Kubernetes Service Discovery, follow the instructions given below:\nAdd AnnotationsEnsure that the Kubernetes pods that contain your Prometheus exporters have been deployed with the following annotations to enable scraping, substituting the listening exporter-TCP-port:\nspec: template: metadata: annotations: prometheus.io/scrape: \u0026#34;true\u0026#34; prometheus.io/port: \u0026#34;exporter-TCP-port\u0026#34; The configuration above assumes your exporters use the typical endpoint called /metrics. If your exporter is using a different endpoint, specify by adding the following additional annotation, substituting the exporter-endpoint-name:\nprometheus.io/path: \u0026#34;/exporter-endpoint-name\u0026#34; Test the EnvironmentUse this Sample Exporter to test your environment:\nExpand apiVersion: apps/v1 kind: Deployment metadata: name: prometheus-java-app spec: replicas: 1 selector: matchLabels: app: prometheus-java-app template: metadata: labels: app: prometheus-java-app annotations: prometheus.io/scrape: \u0026#34;true\u0026#34; prometheus.io/path: \u0026#34;/prometheus\u0026#34; prometheus.io/port: \u0026#34;8080\u0026#34; spec: containers: - name: prometheus-java-app image: luca3m/prometheus-java-app imagePullPolicy: Always You will see auto-discovered Prometheus metrics being displayed on Sysdig Monitor. You can use this working example as a basis to similarly annotate your own exporters.\nDynamic SamplingDynamic sampling supports scraping a rotating set of Prometheus endpoints based on the total amount of time series scraped from each endpoint. Once enabled, it ensures consistent and up-to-date data from every Prometheus endpoints on a given node at dynamic intervals, while maintaining the data collection frequency and fidelity of Prometheus metrics via the Sysdig agent.\u0026quot;\nSysdig\u0026rsquo;s ability to collect and process the volumes of data scraped from different Prometheus endpoints depends on the number of time series scraped from each endpoint, the total Prometheus time series collected by the agent in each time window, and the frequency at which Sysdig agent collects and sends the data to the backend.\nWhen nodes have multiple Prometheus endpoints sending high volumes of time series, the Sysdig agent may skip some endpoints depending on the overall volume and scrape frequency.\nDynamic sampling addresses this by cycling through individual Prometheus endpoints and scraping the latest time series from each endpoint on a rotational basis, ensuring all time series from all Prometheus endpoints are processed at dynamic intervals. This results in more time series being scraped and processed overall at a lower frequency. For example, instead of receiving 50,000 time series every 10 seconds, you might receive 100,000 time series every 20 seconds.\nDynamic Sampling Considerations Any alerts that depend on dynamically-sampled metrics will have the same interval as the metric. Using the example here, the alerts related to either endpoint will be raised, at most, every 20 seconds.\nThe time series from all the endpoints are sent to the backend in order to prevent data integrity issues. Therefore, if total number of time series from a particular endpoint is greater than the maximum allowed limit by any agent, the time series from that endpoint will be dropped irrespective of whether dynamic sampling is turned on or not.\nSysdig agent always maximizes the allowed limit for every interval as long as all the time series of an endpoint fits in the allowed limit.\nEnable Dynamic SamplingTo configure dynamic sampling:\nOpen the dragent.yaml file.\nAdd the following line:\npromscrape_emit_all: true\nRestart the agent.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/custom-integrations/collect-prometheus-metrics/"},{"id":189,"title":"Configure Serverless Agent","content":"Configuration environment variables can be provided directly to the agent or applied through the platform-specific automatic installers listed below:\nCross-Platform Configuration Configuring ECS Fargate Serverless Agent ","url":"https://docs.sysdig.com/en/sysdig-secure/configure-serverless-agent/"},{"id":190,"title":"Configure Alerts","content":"Configure an AlertYou can open the Alert Editor to configure alerts from several places in the Sysdig Monitor UI:\nAlerts: Select New Alert or edit an existing alert. Metrics Explorer: Select Create Alert. An existing Dashboard: click the three-dot menu icon on a panel, and select Create Alert. An Event panel: Select Create Alert from Event. The Alerts Library: Select Enable Alert on a pre-defined template. Alert TypesWhen you open the Alert Editor, you can select from a number of alert types, suitable for different use cases:\nThreshold (Previously Metric): Monitor your infrastructure by comparing any metric against user-defined thresholds Prometheus (Previously PromQL): Monitor your infrastructure with PromQL queries, maintaining full compatibility with OSS Prometheus. Event: Monitor your infrastructure by tracking specific events, and alert if the total number of occurrences exceeds a user-defined threshold Group Outlier: Monitor unusual patterns by detecting deviations from expected group behavior. Percentage of Change: Compare the percentage of change of a metric over two specific timeframes, such as comparing the last 5 minutes to the previous hour. Downtime: Monitor any type of entity - host, container, process, service, etc - and alert when the entity goes down. The type of alert you choose will determine the sections and conditions you can configure in the Alert Editor.\nSettingsIn the Alerts Editor, configure the following parameters in the Settings section:\nAlert Severity: Select a priority. High, Medium, Low and Info. Alert Name: Specify a meaningful name that can uniquely represent the Alert you are creating. For example, Production Cluster Failed Scheduling pods. Description (optional): Add additional alert context Group (optional): Group alerts by assigning them to a specific group name. Alerts that have no group name will be added to the Default Group. Orphaned Alerts: Automatically deactivate orphaned alert occurrences and eliminate noise caused by outdated alerts triggered for entities that are no longer reporting data. Link to Dashboard: Select a dashboard that you might want to include in the alert notification. Link to Runbook: Specify the URL of a runbook. NotificationIn the Notifications section of the Alert Editor, you can configure alerts to forward to notification channels and configure the template that is sent.\nAlerts are supported for the following notification channels:\nAmazon SNS Custom Webhook Email Google Chat IBM Cloud Functions IBM Event Notifications (IBM Only) Microsoft Teams OpsGenie PagerDuty Prometheus Alert Manager Slack Sysdig Team Email VictorOps Webhook To configure an alert to forward to a notification channel, you must set up a notification channel first. To set up a notification channel, see Set up Notification Channels.\nNotification ChannelTo configure an alert to be sent to a notification channel:\nOpen the Alert Editor through one of the methods described in Configure an Alert and navigate to the Notifications section.\nSelect Add Channel.\nSelect a notification channel you have set up from the Notification Channel drop-down.\nAfter [setting up a Notification Channel], the channel will appear on the Notification Channel drop-down list.\nYou can configure alerts for forwarding to multiple notification channels when the alert condition is met.\n(Optional) Use the toggles and the time settings to get notified at a specific frequency when the notification is unresolved, and to receive a notification when it is resolved. For more details, see Resolution Notification.\nResolution NotificationNotification Channels that receive alert notifications can also receive resolution notifications when the alert condition is no longer met. Toggle Get Notified under When Resolved in order to forward resolution notifications so that incidents can be automatically closed in incident management channels such as Pagerduty or Opsgenie.\nThis setting allows an alert to override the notification channel\u0026rsquo;s default notification settings. If an override is not configured, the alert will inherit the default settings from the notification channel.\nCustomize NotificationsConfigure Notification Template Open the Alert Editor through one of the methods described in Configure an Alert\nIn the Notifications section, select Configure Notification Template.\nThe Configure Notification Template drawer opens.\nCustomize the notification template. You can use custom text, hyperlinks, and dynamic variables to customize the template.\nTitle: Customize the notification subject and event title.\nBody: Customize the text seen before (pre) and after (post) the body of the alert. The body is automatically generated by the alert.\nAdditional Notification Fields: Optionally, define additional notification fields to be sent along with the notification.\nField: Name of the field. It does not have to be the same as variable name used in value. Value: The field value. Supports custom text, hyperlinks, and dynamic variables. Additional Notification Fields example: Dynamic VariablesDynamic variables assign themselves the value of the variable, which can continually change as the operation is evaluated. Autocomplete is available when you type double curly braces ({{) followed by initial characters of the variable name.\nThe following variable types are supported:\nAlert Rule Variables: Represent attributes of the alert rule definition. Prefixed with alert.rule. Alert Occurrence Variables: Represent variables related to an alert event generated when a rule is triggered. Prefixed with alert.occurrence. Variable Basics\nVariables must correspond to the segmentation values defined for the alert. For example, if an alert is segmented by host_hostname and container_name, use {{ alert.occurrence.labels.host_hostname }} and {{ alert.occurrence.labels.container_name }}. Variables must be enclosed in double curly braces ({{ }}). To use literal double curly braces in a template, prefix them with an escape character. Example: \\{{Above 50% of CPU Usage}} Text enclosed in double curly braces that is not a valid variable is replaced with an empty string. Example: {{DPService1}} is {{Above 50% of CPU Usage}} renders as is {{Above 50% of CPU Usage}}. Variables are case-sensitive. Notification subjects will not show up on the Event feed. Using a variable that is not a part of the segment will trigger an error. When a variable is not resolved, the output will be \u0026ldquo;N/a\u0026rdquo;. No error will be reported. Supported variables Variable Description {{ alert.rule.id }} The auto-generated unique alert identifier. {{ alert.rule.name }} The configured alert name. {{ alert.rule.description }} The configured alert description. {{ alert.rule.scope }} The configured alert scope. {{ alert.rule.severity }} The configured alert severity label. HIGH, MEDIUM, LOW, INFO. {{ alert.rule.url }} The URL to the Sysdig Monitor page where the alert can be edited. {{ alert.rule.group_by }} A JSON String array with all the labels on which the alert has been grouped by. This applies only to metric and event alerts. {{ alert.rule.condition }} The configured alert main condition. This applies only to metric and event alerts. {{ alert.rule.warning_condition }} The configured alert warning condition. This does not apply to Prometheus alerts. {{ alert.rule.labels }} A JSON object mapping label names from the alert definition to their values. {{ alert.rule.timespan }} The configured alert timespan. {{ alert.rule.range }} The configured alert range. {{ alert.rule.duration }} The configured alert duration. {{ alert.rule.observation_window }} The configured alert observation window. {{ alert.rule.team_name }} The team owner of the alert. {{ alert.rule.type }} The configured alert type: MANUAL, EVENT, PROMETHEUS, FORM_BASED_PROMETHEUS, PERCENTAGE_OF_CHANGE, GROUP_OUTLIERS. {{ alert.rule.dashboard_links }} URLs to the Alert\u0026rsquo;s dashboards. {{ alert.rule.dashboard_template_links }} URLs to the Alert\u0026rsquo;s dashboard templates. {{ alert.rule.runbook_links }} URLs to the Alert\u0026rsquo;s runbook. {{ alert.rule.annotations }} Key-value pairs of Alert\u0026rsquo;s annotations. {{ alert.rule.group_outliers_algorithm }} The Algorithm used to compute outliers in case of Group Outliers Alert type. MAD (Median Absolute Deviation) or DBSCAN (Density-Based Spatial Clustering of Applications with Noise). {{ alert.rule.mad_threshold }} The configured Alert\u0026rsquo;s MAD threshold, in case of MAD algorithm. {{ alert.rule.mad_tolerance }} The configured Alert\u0026rsquo;s MAD tolerance, in case of MAD algorithm. {{ alert.rule.dbscan_tolerance }} The configured Alert\u0026rsquo;s DBSCAN tolerance, in case of DBSCAN algorithm. {{ alert.occurence.workflow_status }} The current workflow status of the alert occurrence: Triggered, Resolved, Acknowledged, Unacknowledged. {{ alert.occurence.state }} The current state of the alert occurrence event. Examples: ACTIVE: for triggered events and events under renotification; OK: for events in which the condition no longer occurs {{ alert.occurence.condition }} The condition that made the alert occurrence trigger or resolve. {{ alert.occurence.condition_value }} The value that made the alert condition trigger, modelled as a string. In case of a no data alert triggering, this field will be values with \u0026ldquo;No Data\u0026rdquo;. {{ alert.occurence.condition_value_raw }} The raw value that made the alert condition trigger. {{ alert.occurence.id }} Unique identifier associated with each alert occurrence. {{ alert.occurence.event_id }} Identifier associated with an alert occurrence event in the event feed. {{ alert.occurence.username }} The username of the user responsible for the triggering of the alert occurrence event, if applicable, such as in the cases of test notification triggering. {{ alert.occurence.active_since_minutes }} The number of minutes the alert occurrence has been active, used in case of re-notifications. {{ alert.occurence.metrics }} A JSON object with alert occurrence\u0026rsquo;s metrics. {{ alert.occurence.starts_at }} The timestamp when the alert occurrence started, formatted as yyyy-MM-dd\u0026rsquo;T\u0026rsquo;HH:mm:ss.SSS\u0026rsquo;Z'. {{ alert.occurence.ends_at }} The timestamp when the alert occurrence ended, formatted as yyyy-MM-dd\u0026rsquo;T\u0026rsquo;HH:mm:ss.SSS\u0026rsquo;Z\u0026rsquo;. Only available in case the alert occurrence has been resolved. {{ alert.occurence.url }} The url to the alert occurrence event details page within Sysdig Monitor. {{ alert.occurence.capture_url }} The url to the Alert occurrence capture. {{ alert.occurence.threshold }} Specifies whether the event is a MAIN or THRESHOLD, respectively if it trigger for a main or warning condition. {{ alert.occurence.entity }} The alert occurrence segment. {{ alert.occurence.trigger.timestamp }} The timestamp in which the alert occurrence event fired, as an epoch long number in microseconds. {{ alert.occurence.trigger.metadata }} JSON object, allowing the user to inspect the metric values that made the alert trigger or re-notify. {{ alert.occurence.resolved.timestamp }} The timestamp in which the alert occurrence event resolved, as an epoch long number in microseconds. {{ alert.occurence.metadata }} A JSON object allowing the user to inspect the metric values that made the alert resolve. {{ alert.occurence.labels.\u0026lt;label_name\u0026gt; }} \u0026lt;label_name\u0026gt; represents any available label that you can find on the corresponding Scope section of the matching Event in the Events feed. See screenshot below. Example labels from the scope in the screenshot: _sysdig_datasource = agent, agent_tag_cluster = demo-kube-aws, etc. The body of the notification message contains a Default Alert Template. It is the default alert notification generated by Sysdig Monitor. You may add free text, variables, or hyperlinks before and after the template.\nExampleThe following example shows a notification template created to alert you on Failing Prometheus Jobs. Adding the following to the subject line helps you identify the problem area at a glance without having to read the entire notification body:\n{{ alert.occurrence.labels.kube_cluster_name }}:{{ alert.occurrence.labels.job }} - {{ alert.rule.name }} is {{ alert.occurrence.workflow_status }} AutomationsYou can link an alert to one or more Alert Automations to run automated workflows whenever the alert fires. Automations let you apply conditional logic and route notifications across multiple channels in a single flow.\nTo link an alert to an automation:\nOpen the Alert Editor through one of the methods described in Configure an Alert and navigate to the Automations section.\nSelect Add Automation.\nSelect an automation from the Automation drop-down.\nYou can link multiple automations to a single alert. Each automation will run independently when the alert fires.\nSelect Save to apply the changes.\nIf you delete an automation, it is not automatically removed from the alerts it was linked to. The alert continues to reference the orphaned automation, and you cannot save further changes to the alert until you manually remove that reference from the Automations section in the Alert Editor.\nAutomate Deactivation or Resolution of Orphaned Alert OccurrencesSysdig Monitor can automatically deactivate or resolve alert occurrences triggered by entities like hosts or containers that are no longer reporting data. This curbs noise from potentially outdated alert occurrences, ensuring that your alert notifications remain relevant.\nBy automatically deactivating or resolving orphaned alert occurrences, you can eliminate false positives and ensure that only alert occurrences from existing entities are reported in the system.\nPrerequisitesAutomatic Alert Deactivation is available for the following alert types:\nThreshold Alerts Group Outlier Alerts Downtime Alerts Automatic Alert Resolution is available for the following alert types:\nThreshold Alerts Configure Response to Lack of DataTo configure a response to a lack of alert occurrence data:\nLog in to Sysdig Monitor.\nEither Create an Alert or edit an existing alert of the supported types.\nThe Alert configuration page appears.\nUnder Settings, review responses to Active Alert Occurrence Stopped Reporting Data:\nKeep Firing: The alert occurrence will continue, even if no data is reported. Resolve: When alert occurrences are resolved rather than deactivated, notification channels and alert configurations determine whether a resolution notification should be sent. Deactivate: Deactivated alert occurrences will not send any notifications but will be marked in the event feed as deactivated. Supported Aggregation FunctionsThe table below displays supported time aggregation functions, group aggregation functions, and relational operators:\nTime Aggregation Function Group Aggregation Function Relational Operator timeAvg() avg() = min() min() \u0026lt; max() max() \u0026gt; sum() sum() \u0026lt;= not applicable not applicable \u0026gt;= not applicable not applicable != CapturesOptionally, configure a Sysdig capture. Specify the following:\nCapture Enabled: Click the slider to enable Capture. Capture Duration: The period of time captured. The default time is 15 seconds. The capture time starts from the time the alert threshold was breached Capture Storage: The storage location for the capture files. Capture Name: The name of the capture file Capture Filter: Restricts the amount of trace information collected. Sysdig capture files are not available for Event Alerts and Prometheus Alerts. See Captures for more information.\nConsistent Alert Preview for Alert Rule EvaluationThreshold Alerts, Event Alerts, and Prometheus Alerts provide an alert preview that accurately reflects alert rule checks. This aligns the data points in the alert preview with the actual alert evaluation intervals, ensuring a realistic representation of alert behavior, since each point in the alert preview corresponds to an actual alert rule check.\nFor scenarios where you need to view data in a different format from the alert rule checks, such as data in 10s intervals or a week-long alert preview, switch to Explore Mode. This mode provides the flexibility to view data at different granularities or over extended periods, even if these do not correspond to the specific intervals of alert check. Explore Mode does not apply to Event Alerts.\nEvaluation Interval for Threshold Alerts and Prometheus AlertsBy default, alerts are evaluated every minute. However, if an alert has a range of 3 hours or more, it will be evaluated every 10 minutes instead. For instance, if you have configured a Threshold Alert to look at data \u0026ldquo;over the last 3 hours,\u0026rdquo; it will be evaluated every 10 minutes. The same applies to Prometheus Alerts like sum(rate(errors_total[3h])) \u0026gt; 100 which will also be evaluated every 10 minutes. Additionally, this means that re-notifications can only be as frequent as 10m for these alerts.\nPlease note that Threshold Alerts and Prometheus Alerts with ranges of 31 days or more are not supported.\nQuery Range Check Interval up to 3h 1m up to 1d 10m up to 7d 1h up to 31d 1d 31d Not Supported ","url":"https://docs.sysdig.com/en/sysdig-monitor/configure-alerts/"},{"id":191,"title":"Configure CDR and Advanced CIEM for Azure","content":"Setting up Log Ingestion relies on the following Azure features:\nDiagnostic Settings Event Hub Service Principals Sysdig released a new onboarding experience for Azure in August 2024. If you onboarded your Azure tenant and/or subscription before the 6th of August, 2024, and would like to add more features, contact your Sysdig representative.\nPrerequisites You must have an Azure Subscription or Tenant already connected to Sysdig. Access to a User with the permissions required to install. Set Up Log Ingestion Log in to Sysdig Secure, select Integrations \u0026gt; Environments \u0026gt; Azure.\nSelect an account that is part of the tenant you would like to add features to or the individual account you onboarded.\nOn the right panel, you will see a list of features.\nClick Setup beside a desired feature to open the wizard.\nEnsure you have the necessary permissions configured as described in the initial setup.\nVerify the details of your tenant and the subscription where the features will be added.\nSelect the region where the Event Hub will be deployed to forward logs to Sysdig (to set up log ingestion).\nWe recommend that you use your primary region.\nSelect which log types and sources you want to monitor. This will affect the Terrfaorm snippet generated at the end of the setup:\nDefault Setup: Includes all the logs required by Advanced CIEM and CDR.\nGuided Customization: Un-tick the boxes beside sources you wish to exclude from collection.\nSee Tune Log Volume Using the Onboarding UI for advanced options.\nGenerate and apply the Terraform code:\nCreate a log_ingestion.tf file in the folder that contains your main.tf. Copy the snippet provided into the log_ingestion.tf file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. Customize Log IngestionDisable FeaturesWhen you configure a Log Ingestion component, both Advanced CIEM and CDR are enabled by default.\nTo disable either of these features, follow the instructions below.\nRetrieve the log_ingestion.tf Terraform snippet as described above.\nBefore running terraform init \u0026amp;\u0026amp; terraform apply, comment out the relevant stanza from the snippet.\nWe recommend commenting out the stanza instead of removing it entirely, in case you want to enable the feature in the future.\nTo disable Advanced CIEM, comment out: resource \u0026#34;sysdig_secure_cloud_auth_account_feature\u0026#34; \u0026#34;identity_entitlement\u0026#34; { account_id = module.onboarding.sysdig_secure_account_id type = \u0026#34;FEATURE_SECURE_IDENTITY_ENTITLEMENT\u0026#34; enabled = true components = [module.event-hub.event_hub_component_id] depends_on = [module.event-hub, sysdig_secure_cloud_auth_account_feature.config_posture] } To disable CDR, comment out: resource \u0026#34;sysdig_secure_cloud_auth_account_feature\u0026#34; \u0026#34;threat_detection\u0026#34; { account_id = module.onboarding.sysdig_secure_account_id type = \u0026#34;FEATURE_SECURE_THREAT_DETECTION\u0026#34; enabled = true components = [module.event-hub.event_hub_component_id] depends_on = [module.event-hub] } Run terraform init \u0026amp;\u0026amp; terraform apply\nCustomize Log Ingestion after InstallationDisabling or re-enabling features after applying the Terraform is possible, simply comment or uncomment the feature stanza as described above, and re-run terraform apply.\nAdvanced CustomizationAdvanced customization is available via variables in the Terraform module. Modifying these values can cause installation and/or feature operation to fail, so contact your Sysdig representative before modifying these values.\nTune Log VolumeCloud Detection and Response (CDR) coverage of Azure includes multiple sources. By default, Activity Logs are always enabled, while Entra ID Logs are enabled only in Tenant setups.\nYou can customize this during the setup through the Sysdig Secure UI, or in the Terraform snippet. After setup, you can manually edit the Terraform snippet.\nTuning the configuration will change the logs that will be sent to Sysdig. This will affect Sysdig’s runtime visibility and threat detection capabilities.\nTune Log Volume Using the Onboarding UITo customize this through the UI, you can follow the instructions given in Set Up Log Ingestion.\nWhen you Select Sources (optional), choose the Guided Customization option.\nNow, you can choose which sources you would like to use under Choose log categories. The Terraform snippet you obtain at the end of the flow will be configured accordingly.\nTune Log volume via TerraformTo customize this directly in the Terraform, use the enabled_platform_logs and enabled_entra_logs parameters.\nConfigure Additional ResourcesOn top of subscription and tenant-wide resources, Sysdig provides CDR capabilities on additional resources, such as Key Vaults. To enable this, you must specify the resource you want to ingest logs for and the related Log Category that you want to send to Sysdig:\nPrerequisites: An Azure cloud account connected to Sysdig through modular onboarding.\nLog in to Sysdig Secure.\nSelect Integrations \u0026gt; Environments \u0026gt; Azure.\nSelect a connected Azure account from the list. Or select Connected \u0026gt; Open the drawer to see more on the listing.\nThe detail drawer will open.\nUnder Threat Detection, select Setup Threat Detection. The Account Overview page appears.\nUnder Cloud Detection and Response, select Go to Setup.\nProceed through the steps.\nOn step 5, Configure Additional Resources (optional), you will be prompted to gather your Resource IDs and related log types you need. You will need them later to configure the additional_resources Terraform module. This module creates diagnostic settings on the resources you specify. This lets you send those logs to Sysdig through the dedicated Event Hub. Read more on the Terraform module documentation.\nOn step 8, Deploy Terraform, you will be provided with a snippet at point 1. Follow the instructions to copy it in the log_ingestion.tf file. At the end of the file add the additional_resources module with the diagnostic_settings variable set to map each Resource ID to the Log Categories you want to send to Sysdig as described at the previous step.\nThis example enables AuditEvent on a Key Vault named Foo:\nmodule \u0026#34;additional-resources\u0026#34; { source = \u0026#34;sysdiglabs/secure/azurerm//modules/integrations/additional-resources\u0026#34; sysdig_authorization_id = module.event-hub.sysdig_authorization_id event_hub_name = module.event-hub.event_hub_name deployment_identifier = module.event-hub.unique_deployment_id diagnostic_settings = { \u0026#34;/subscriptions/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee/resourceGroups/my-resource-group/providers/Microsoft.KeyVault/vaults/Foo\u0026#34; = [\u0026#34;AuditEvent\u0026#34;] } } Find available log categories for each resource type in the Azure documentation.\nTune Event HubSysdig provides a default configuration for Event Hub that relies on a standard tier Event Hub with 4 partitions and throughput unit autoscaling enabled, starting from 1 throughput unit (TU) and capped at 20 maximum TUs.\nTo customize the number of partitions:\nLog in to Sysdig Secure.\nSelect Integrations \u0026gt; Environments \u0026gt; Azure.\nSelect a connected Azure account from the list. Or select Connected \u0026gt; Open the drawer to see more on the listing.\nThe detail drawer will open.\nUnder Cloud Detection and Response, select Setup Cloud Detection and Response. The Account Overview page appears.\nUnder Cloud Detection and Response, select Go to Setup.\nProceed through the steps.\nOn step 6, Customize Azure EventHub partitions (optional), select how many partitions you want. The available number ranges between 1 and 32. The default value is 16.\nIn general, for all the Event Hub parameters, you can adapt the arguments of the threat detection Terraform module (source = sysdiglabs/secure/azurerm//modules/services/event-hub-data-source). See module specifications and the Event Hub documentation.\nCheck the Connection StatusTo check the connection status:\nLog in to Sysdig Secure and select Integrations \u0026gt; Environments \u0026gt; Azure. Select your account. The Detail panel will open on the right. If the connection is successful, you will see the feature as Connected. This may take up to 5 minutes after deploying the Terraform.\nGiven below are the possible health statuses for Advanced CIEM:\nStatus Description Healthy ✅ The account has been successfully connected, and all the CIEM tasks are processed as expected. Error ❌ Error processing the CIEM analysis tasks. ","url":"https://docs.sysdig.com/en/sysdig-secure/azure-configure-cdr-and-ciem/"},{"id":192,"title":"Configure CDR and Advanced CIEM for GCP","content":" Pub Sub Service Account To configure CDR and Advanced CIEM, set up log ingestion.\nSysdig released a new onboarding experience for GCP in October 2024. If you onboarded your GCP organization and/or project before October, 2024, and would like to add more features, contact your Sysdig representative.\nPrerequisites You must have an GCP Project or Organization already connected to Sysdig. Access to a User with the permissions required to install. Set Up Log IngestionTo utilize CDR and Advanced CIEM, you must set up log ingestion:\nLog in to Sysdig Secure, select Integrations \u0026gt; Environments \u0026gt; GCP.\nSelect an account that is part of the organization you would like to add features to or the individual account you onboarded.\nOn the right panel, you will see a list of features.\nSelect either Set Up Advanced CIEM or Set Up Cloud Threat Detection.\nUnder Advanced CIEM or Threat Detection, and beside Log Ingestion, select Go to Setup.\nVerify that you have all the required permissions to perform the installation, the details of your organization/project where the features will be added.\nSelect to enable the required APIs manually or through Terraform\nManual: simpler, suitable for a limited number of projects or when the required APIs are already enabled Terraform: more complex, but overall easier when dealing with larger environments Select which log types and sources you want to monitor. This will affect the Terraform snippet generated at the end of the setup:\nDefault Setup: Includes all the logs required by Advanced CIEM and CDR.\nGuided Customization: Un-tick the boxes beside sources you wish to exclude from collection.\nAdvanced Customization: You can customize the Terraform snippet generated to define the audit events enabled for each service. For details, see Customize Log Ingestion.\nSee Tune Log Volume Using the Onboarding UI for advanced options.\nSelect the Sink Filter configuration. This will affect the Terraform snippet generated at the end of the setup:\nDefault Setup: Includes all the logs required by Advanced CIEM and CDR. Advanced Customization: You can customize the Terraform snippet generated to filter which event is to be sent to Sysdig. For details, see Customize Log Ingestion. Create a log_ingestion.tf file in the folder that contains your main.tf.\nCopy the snippet provided into the log_ingestion.tf file. Save a copy of it securely, because you will need it later if you wish to Customize Log Ingestion.\nRun the command: terraform init \u0026amp;\u0026amp; terraform apply.\nCustomize Log IngestionWhen you configure a Log Ingestion component, both Identity and Access Management and Cloud Detection and Response are enabled by default. You may wish to disable one or more of these features. There are two ways to customize log ingestion. You can either:\nUninstall the existing log ingestion, and then redo setup through the wizard. (Advanced) Edit the existing configuration with Terraform. Prerequisite: You need the terraform snippet generated during initial setup. If you do not have this snippet to hand, use the first method. To customize log ingestion through the UI:\nTo uninstall your current, undesired log ingestion setup, delete log_ingestion.tf or rename it log_ingestion.tf.disabled.\nRun terraform apply to save your change. Terraform will not find the log ingestion configuration file.\nLog in to Sysdig Secure.\nSelect Integrations \u0026gt; Environments \u0026gt; GCP.\nYou will be able to set up Log Ingestion afresh.\nFollow the instructions in Set Up Log Ingestion, and select the desired features to configure.\nTo customize an installed log ingestion with Terraform, comment out the undesired sections in the snippet:\nRetrieve the log_ingestion.tf Terraform snippet you generated in your initial setup from the place you saved it.\nTo disable Identity and Access Management, comment out:\nresource \u0026#34;sysdig_secure_cloud_auth_account_feature\u0026#34; \u0026#34;identity_entitlement\u0026#34; { account_id = module.onboarding.sysdig_secure_account_id type = \u0026#34;FEATURE_SECURE_IDENTITY_ENTITLEMENT\u0026#34; enabled = true components = [module.event-hub.event_hub_component_id] depends_on = [module.event-hub, sysdig_secure_cloud_auth_account_feature.config_posture] } To disable Cloud Detection and Response, comment out:\nresource \u0026#34;sysdig_secure_cloud_auth_account_feature\u0026#34; \u0026#34;threat_detection\u0026#34; { account_id = module.onboarding.sysdig_secure_account_id type = \u0026#34;FEATURE_SECURE_THREAT_DETECTION\u0026#34; enabled = true components = [module.event-hub.event_hub_component_id] depends_on = [module.event-hub] } Run terraform init \u0026amp;\u0026amp; terraform apply.\nYour log ingestion setup will be customized.\nWe recommend commenting out the stanza instead of removing it entirely, as it makes it easier to re-enable the feature later.\nAdvanced CustomizationAdvanced customization is available via variables in the Terraform module. Modifying these values can cause installation and/or feature operation to fail, so contact your Sysdig representative before modifying these values.\nTune the Cloud Logs VolumeWhen you set up CDR, Sysdig creates a log sink to access logs through Pub/Sub. As a high volume of logs are costly to process, you may wish to tune the number of audit logs that are generated, or the logs that sent to Sysdig.\nTuning the configuration will change the logs that will be sent to Sysdig. This will affect Sysdig’s runtime visibility and threat detection capabilities.\nTune Log Volume Using the Onboarding UITo customize this through the UI, you can follow the instructions given in Set Up Log Ingestion.\nUsing the Select Sources (optional) option, you can tune which logs are generated:\nGuided customization: Use this option to simply select audit logs that all services should generate. The Terraform snippet parameters you obtain at the end of the flow will be configured accordingly. Advanced customization: Use this option to define different configurations for different services inside your Terraform snippet. Additional guidance on this is available in the next paragraph. Using the Sink Filter Configuration (optional) option, you can configure which logs are forwarded to Sysdig by selecting the Advanced Customization option.\nNow, you can customize the Terraform snippet generated to filter which event is to be sent to Sysdig. For details, see Customize Log Ingestion.\nTune Log volume via Terraform To tune which logs are generated, see Tune Log Generation.\nTo set up inclusion or exclusion filters, see Tune the Log Sink Filter.\nTune Audit Log GenerationCDR enables Data Access audit logs for every service on every connected project by default:\n[ { service = \u0026#34;allServices\u0026#34; log_config = [ { log_type = \u0026#34;ADMIN_READ\u0026#34; }, { log_type = \u0026#34;DATA_READ\u0026#34; }, { log_type = \u0026#34;DATA_WRITE\u0026#34; } ] } ] You can customize this to change the enabled log types or specify the single services. For a the list of services providing audit logs, see the Google Cloud documentation.\nTo customize this, specify the audit_log_config variable for the pub-sub module:\nmodule \u0026#34;pub-sub\u0026#34; { ... audit_log_config = [ { service = \u0026#34;storage.googleapis.com\u0026#34; log_config = [ { log_type = \u0026#34;DATA_WRITE\u0026#34; } ] }, { service = \u0026#34;cloudsql.googleapis.com\u0026#34; log_config = [ { log_type = \u0026#34;ADMIN_READ\u0026#34; }, { log_type = \u0026#34;DATA_READ\u0026#34; }, { log_type = \u0026#34;DATA_WRITE\u0026#34; } ] } ] } While the Terraform is unique to Sysdig, the configuration affects the project and the logs it generates, which could impact on consumers of those logs. If you want to keep generating these logs, without sending them to Sysdig, you can tune the log filter.\nTune the Log Sink FilterBy default, the log sink filter is configured to only pick up Audit logs: protoPayload.@type = \\\u0026quot;type.googleapis.com/google.cloud.audit.AuditLog\\\u0026quot;. You can add exclusion filters to narrow the scope further.\nYou can customize the filter by specifying the ingestion_sink_filter in the pub-sub module.\nThis example snippet excludes get and list methods for Data Access audit logs:\nmodule \u0026#34;pub-sub\u0026#34; { ... ingestion_sink_filter = \u0026#34;protoPayload.@type = \\\u0026#34;type.googleapis.com/google.cloud.audit.AuditLog\\\u0026#34; (protoPayload.methodName !~ \\\u0026#34;\\\\.(get|list)$\\\u0026#34; OR logName !~ \\\u0026#34;%2Fdata_access$\\\u0026#34;)\u0026#34; } Alternatively you can specify exclude filters with the exclude_logs_filter variable in the same module.\nThis example excludes:\ngets and lists on kubernetes gets and lists on Google Cloud Storage (GCS) module \u0026#34;pub-sub\u0026#34; { ... exclude_logs_filter = [ { name = \u0026#34;k8s_get_list\u0026#34; description = \u0026#34;Exclude get and list methods on kubernetes\u0026#34; filter = \u0026#34;protoPayload.serviceName=\\\u0026#34;k8s.io\\\u0026#34; AND protoPayload.methodName =~ (\\\u0026#34;\\\\.get$\\\u0026#34; OR \\\u0026#34;\\\\.list$\\\u0026#34;)\u0026#34; }, { name = \u0026#34;storage_objects_get_list\u0026#34; description = \u0026#34;Exclude get and list methods on GCS objects\u0026#34; filter = \u0026#34;protoPayload.methodName = (\\\u0026#34;google.storage.objects.get\\\u0026#34; OR \\\u0026#34;google.storage.objects.list\\\u0026#34; OR \\\u0026#34;storage.objects.get\\\u0026#34; OR \\\u0026#34;storage.objects.list\\\u0026#34;)\u0026#34; } ] } The following example for the organization threat detection module excludes:\nspecific project logs specific folder logs module \u0026#34;pub-sub\u0026#34; { ... exclude_logs_filter = [ { name = \u0026#34;exclude_project_test\u0026#34; description = \u0026#34;Exclude GCP Test Project logs\u0026#34; filter = \u0026#34;source(projects/my-test-project-id)\u0026#34; }, { name = \u0026#34;exclude_folder_sandbox\u0026#34; description = \u0026#34;Exclude GCP Sandbox Folder logs\u0026#34; filter = \u0026#34;source(folders/my-sandbox-folder-id)\u0026#34; }, ] } For the full syntax of the filtering options, see Google Cloud Logging query language page.\nCheck the Connection StatusTo check the connection status:\nLog in to Sysdig Secure and select Integrations \u0026gt; Environments \u0026gt; GCP. Select your account. The Detail panel will open on the right. If the connection is successful, you will see the feature as Connected. This may take up to 5 minutes after deploying the Terraform.\nGiven below are the possible health statuses for Advanced CIEM:\nStatus Description Healthy ✅ The account has been successfully connected, and all the CIEM tasks are processed as expected. Error ❌ Error processing the CIEM analysis tasks. ","url":"https://docs.sysdig.com/en/sysdig-secure/gcp-configure-cdr-and-ciem/"},{"id":193,"title":"Configure Threat response for AWS","content":" Sysdig released a new onboarding experience for AWS in September 2024. If you onboarded your AWS Organization or Account before September 30, 2024, and would like to add more features, contact your Sysdig representative.\nPrerequisites An AWS Account or Organization connected to Sysdig. Access to a user with the permissions required to install. Set Up Cloud Response Actions Log in to Sysdig Secure, and select Integrations \u0026gt; AWS.\nSelect an onboarded account you would like to add features to.\nThe detail panel appears on the right. Here, you can see a list of features.\nSelect Setup Threat Response.\nThe Account Overview page appears. Here, you can review which features are enabled.\nUnder Threat Response, and beside Cloud Response Actions, select Go to Setup.\nSelect whether you wish to use Terraform or a CloudFormation Template.\nEnsure you have the necessary permissions configured as described in the first step.\nVerify the details of your Organization or Account where the features will be added.\nSelect which Response Actions you want to set up. By selecting an action, you\u0026rsquo;re provisioning one or more Lambda functions, along with Roles and the required Permissions to execute them. See Permissions and Resources for additional information.\nDeploy the configured setup.\nEnsure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; AWS. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/aws//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;5.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/aws//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;5.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } For Terraform, save the generated Terraform snippet as cloud_response_actions.tf, in the folder that contains your main.tf and then run terraform init \u0026amp;\u0026amp; terraform apply. For CloudFormation, follow the link in the setup to your AWS Console. Once completed, come back to the Sysdig UI and click \u0026ldquo;Complete\u0026rdquo;. Check Connection StatusTo check the connection status:\nLog in to Sysdig Secure.\nSelect Integrations \u0026gt; AWS.\nSelect your account.\nThe detail panel appears on the right.\nIf the connection is successful, you will see the feature as Connected. This may take up to 5 minutes after deploying with Terraform.\n","url":"https://docs.sysdig.com/en/sysdig-secure/aws/configure-threat-response/"},{"id":194,"title":"Configure PVC Metrics","content":"PrerequisitesPVC objects are monitored automatically with Sysdig Agent v12.2.0 and above.\nTo learn about agent configuration, see Configure the Agent\nApply RulesIf you are upgrading the Sysdig agent, either download sysdig-agent-clusterrole.yaml or apply the following rule to the ClusterRole associated with your Sysdig agent.\nrules: - apiGroups: - \u0026#34;\u0026#34; resources: - nodes/metrics - nodes/proxy - nonResourceURLs: - /metrics verbs: - get The rules are required to scrape the kubelet containers. With this rule enabled, you will also have the kubelet metrics and can access kubelet templates for both dashboards and alerts.\nThis configuration change is only required for agent upgrades because the sysdig-agent-clusterrole.yaml associated with fresh installations will already have this configuration. See Steps for Kubernetes (Vanilla) for information on Sysdig agent installation.\nSysdig Agent v12.3.x and AboveThe following kube-state-metrics (KSMs) are enabled by default for Sysdig agent v12.3.0 and above. The configuration for collecting the resource metrics looks similar to:\nk8s_extra_resources: include: - services - resourcequotas - persistentvolumes - persistentvolumeclaims - storageclasses Disable Collecting PVC MetricsTo disable collecting PVC metrics, add the following to the dragent.yaml file:\nk8s_extra_resources: include: - services - resourcequotas For details on how to configure dragent.yaml, see Configure the Agent\nHere, you remove the entries corresponding to the persistentvolumes and persistentvolumeclaims resources from the k8s_extra_resources.\nCollect Additional Resource MetricsTo enable collecting other resource metrics, such as horizontalpodautoscalers, add the entries corresponding to the resources to the dragent.yaml file:\nk8s_extra_resources: include: - services - resourcequotas - persistentvolumes - persistentvolumeclaims - storageclasses - horizontalpodautoscalers - ingresses - certificatesigningrequests For more information, see Enable Kube State Metrics.\nSysdig Agent Prior to v12.3.0 Contact your Sysdig representative or Sysdig Support for technical assistance with enabling PVC metrics in your environment.\nUpgrade Sysdig agent to v12.2.0 or above\nIf you are an existing Sysdig user, include the following configuration in the dragent.yaml file:\nk8s_extra_resources: include: - persistentvolumes - persistentvolumeclaims - storageclasses Access PVC Dashboard from the Library Log in to Sysdig Monitor and click Dashboards.\nOn the Dashboards slider, scroll down to locate Dashboard Library (formerly: Dashboard Templates).\nClick Kubernetes to expand the Kubernetes section.\nSelect the PVC and Storage dashboard.\nAccess PVC Alert Template Log in to Sysdig Monitor and click Alerts.\nOn the Alerts page, click Library.\nOn the Library page, click All Templates.\nSelect the Kubernetes PVC alert templates.\nPVC Metrics Metrics Metric Type Labels Metric Source kube_persistentvolume_status_phase Gauge persistentvolume, phase Kubernetes API kube_persistentvolume_claim_ref Gauge persistentvolume, name Kubernetes API kube_storageclass_created Gauge storageclass Kubernetes API kube_storageclass_info Gauge storageclass, provisioner, reclaim_policy, volume_binding_mode Kubernetes API kube_storageclass_labels Gauge storageclass Kubernetes API kube_pod_spec_volumes_persistentvolumeclaims_info Gauge namespace, pod, uid, volume, persistentvolumeclaim Kubernetes API kube_pod_spec_volumes_persistentvolumeclaims_readonly Gauge namespace, pod, uid, volume, persistentvolumeclaim Kubernetes API kube_persistentvolumeclaim_status_condition Gauge namespace, persistentvolumeclaim, type, status Kubernetes API kube_persistentvolumeclaim_status_phase Gauge namespace, persistentvolumeclaim, phase Kubernetes API kube_persistentvolumeclaim_access_mode Gauge namespace, persistentvolumeclaim, access_mode Kubernetes API kubelet_volume_stats_inodes Gauge namespace, persistentvolumeclaim Kubelet kubelet_volume_stats_inodes_free Gauge namespace, persistentvolumeclaim Kubelet kubelet_volume_stats_inodes_used Gauge namespace, persistentvolumeclaim Kubelet kubelet_volume_stats_used_bytes Gauge namespace, persistentvolumeclaim Kubelet kubelet_volume_stats_available_bytes Gauge namespace, persistentvolumeclaim Kubelet kubelet_volume_stats_capacity_bytes Gauge namespace, persistentvolumeclaim Kubelet storage_operation_duration_seconds_bucket Gauge operation_name, volume_plugin,le Kubelet storage_operation_duration_seconds_sum Gauge operation_name, volume_plugin Kubelet storage_operation_duration_seconds_count Gauge operation_name, volume_plugin Kubelet storage_operation_errors_total Gauge operation_name, volume_plugin Kubelet storage_operation_status_count Gauge operation_name, status, volume_plugin Kubelet ","url":"https://docs.sysdig.com/en/sysdig-monitor/configure-pvc/"},{"id":195,"title":"Configure Threat detection and Advanced CIEM for AWS","content":" Sysdig released a new onboarding experience for AWS in September 2024. If you onboarded your AWS Organization or Account before September 30, 2024, and would like to add more features, contact your Sysdig representative.\nPrerequisites An AWS Account or Organization connected to Sysdig. Access to a user with the permissions required to install. At least one CloudTrail trail in the accounts to be monitored. Set Up Log IngestionTo configure Agentless Threat Detection and Advanced CIEM, you must set up log ingestion with either EventBridge or S3.\nEventBridge allows Sysdig to receive CloudTrail logs and AWS service events, such as object events and GuardDuty Findings, with minimal latency. EventBridge setups support log volume tuning of which logs you want Sysdig to receive based on Event pattern. S3 provides a cost-effective solution for streaming CloudTrail logs with a latency in the order of minutes. Log volume tuning is not available for S3 setups. EventBridge S3 Supported logs CloudTrail events, GuardDuty findings, Object events CloudTrail events Latency Sub-second Minutes Price (data transfer excluded) By event-type and for transferring data to Sysdig\u0026rsquo;s Event bus. SNS notifications delivered via HTTP and file transferring Log volume tuning Fine-grained, using Event pattern Up to accounts and regions EventBridge SetupTo set up Log Ingestion for EventBridge:\nLog in to Sysdig Secure, and select Integrations \u0026gt; Environments \u0026gt; AWS.\nSelect an onboarded account you would like to add features to.\nThe detail panel appears on the right. Here, you can see a list of features.\nSelect either Set Up Advanced CIEM or Set Up Threat Detection.\nThe Account Overview page appears. Here, you can review which features are enabled.\nUnder Advanced CIEM or Threat Detection, and beside Log Ingestion, select Go to Setup.\nSelect EventBridge.\nSelect whether you wish to set up Threat detection and Advanced CIEM with Terraform or a CloudFormation Template.\nThe wizard will guide you to review prerequisites and check your account details.\nSelect the regions you would like to collect logs from.\nEnsure you select at least us-east-1. Add any other AWS regions you use for your account. AWS logs global service events to us-east-1 region. Without this region in your AWS setup, you might miss key events, including IAM events.\nSelect which log types and sources you want to monitor. This will affect the Terraform snippet or the CloudFormation Stack generated at the end of the setup:\nDefault Setup: Includes all the logs required by Advanced CIEM and Threat detection.\nGuided Customization: You can customize the logs that EventBridge will forward to Sysdig. This doesn\u0026rsquo;t modify any CloudTrail configuration, as well as how other resources in other services are configured. Object events enable the collection of S3 Object notifications, described in the dedicated section.\nAdvanced Customization: You can customize the Terraform snippet or CloudFormation Stack parameters generated to define a custom Event pattern to use in the Event Bridge rules. For details, see Customize Log Ingestion.\nSee Tune Log Volume Using the Onboarding UI for advanced options.\nFor Terraform, save the generated Terraform file log_ingestion.tf, in the folder that contains your main.tf.\nFor CloudFormation, follow the link in the setup to your AWS Console. Copy the snippet provided into the log_ingestion.tf file.\nRun the command: terraform init \u0026amp;\u0026amp; terraform apply.\nGuardDuty findings are ingested if the service is enabled in the AWS Accounts.\nS3 Setup Wait for Inventory data to be fetched from the account you want to connect to be guided in the values to use. This can take up to several hours.\nIf you are in a hurry, you can continue anyways, adding the values manually.\nTo set up Log Ingestion for S3:\nLog in to Sysdig Secure, and select Integrations \u0026gt; Environments \u0026gt; AWS.\nSelect an onboarded account you would like to add features to.\nThe detail panel appears on the right. Here, you can see a list of features.\nSelect either Set Up Advanced CIEM or Set Up Threat Detection.\nThe Account Overview page appears. Here, you can review which features are enabled.\nUnder Advanced CIEM or Threat Detection, and beside Log Ingestion, select Go to Setup.\nSelect S3.\nSelect whether you wish to set up Threat detection and Advanced CIEM with Terraform or a CloudFormation Template.\nThe wizard will guide you to review prerequisites and check your account details.\nVerify or select your CloudTrail Trail:\nIf you have only one trail, reviews its details. If you have multiple trails, select which trail you want to access. If your trail data hasn\u0026rsquo;t been fetched, enter the trail data manually. In the single account setup, the Trail, the KMS key and the SNS topic it uses, as well as the S3 Bucket where logs are written must be in the same account.\nIf you have such a setup and need to monitor a single account, consider the connecting your organization or using EventBridge.\nBased on the selected trail, Sysdig will either:\nSubscribe to the SNS topic configured on the trail. In this case you should review the details. Create a SNS topic. You will need to attach it to the trail later. Define the region and name for the topic to be created. Select the regions you would like to collect logs from. By default, you must have at least us-east-1. Add any other AWS regions you use for your account.\nAWS logs global service events to us-east-1 region. Without this region in your AWS setup, you might miss key events, including IAM events.\nApply the setup in your organization or account\nFor Terraform, save the generated terraform file log_ingestion.tf, in the folder that contains your main.tf and run the command: terraform init \u0026amp;\u0026amp; terraform apply For CloudFormation, follow the link in the setup to your AWS Console. If your CloudTrail Trail encrypts data with a KMS Key, and the key is hosted in a different account than the S3 bucket\u0026rsquo;s, you need to edit the KMS Key policy to allow Sysdig reading CloudTrail files\nIf you didn\u0026rsquo;t have the SNS notification delivery configured on the trail, you\u0026rsquo;ll be guided to set it up. This can be accomplished through the AWS Management Console or via the AWS CLI tool.\nDisable FeaturesWhen you configure a Log Ingestion component, both Advanced CIEM and Threat detection are enabled by default. You can disable one of these features. This is available for both EventBridge and S3 Terraform setups. It is not available for CloudFormation Template setups. To disable either of these features, comment out the relevant stanza in the Terraform snippet:\nRetrieve the log_ingestion.tf Terraform snippet from the onboarding wizard as described in Set Up Log Ingestion.\nTo disable Advanced CIEM comment out the identity_entitlement resource. For example:\nresource \u0026#34;sysdig_secure_cloud_auth_account_feature\u0026#34; \u0026#34;identity_entitlement\u0026#34; { account_id = module.onboarding.sysdig_secure_account_id type = \u0026#34;FEATURE_SECURE_IDENTITY_ENTITLEMENT\u0026#34; enabled = true components = [module.event-bridge.event_bridge_component_id] depends_on = [module.event-bridge, sysdig_secure_cloud_auth_account_feature.config_posture] } To disable Threat detection, comment out the threat_detection resource. For example:\nresource \u0026#34;sysdig_secure_cloud_auth_account_feature\u0026#34; \u0026#34;threat_detection\u0026#34; { account_id = module.onboarding.sysdig_secure_account_id type = \u0026#34;FEATURE_SECURE_THREAT_DETECTION\u0026#34; enabled = true components = [module.event-bridge.event_bridge_component_id] depends_on = [module.event-bridge] } Run terraform init \u0026amp;\u0026amp; terraform apply.\nWe recommend you comment out the stanza instead of removing it entirely. Later, if you want to enable a disabled feature, you can un-comment the stanza.\nCheck Connection StatusTo check the connection status:\nLog in to Sysdig Secure.\nSelect Integrations \u0026gt; Environments \u0026gt; AWS.\nSelect your account.\nThe detail panel appears on the right.\nIf the connection is successful, you will see the feature as Connected. This may take up to 5 minutes after deploying the Terraform.\nAdvanced Customization for EventBridgeIn EventBridge log ingestion setups, you can perform advanced customization to tune log volumes and monitor S3 buckets.\nTuning and S3 bucket monitoring are not available for S3 log ingestion setups.\nTune Log VolumeWhen used with AWS EventBridge, the Log Ingestion component creates an EventBridge rule that sends events matching the conditions defined in an event pattern to Sysdig. You can tune the event pattern to your preference to change which events you collect. This can be accomplished during setup with the UI, Terraform, or CFT. After setup, you can manually edit the Terraform snippet or the CFT parameters.\nFor a starting point, see default Event pattern.\nTuning the pattern will change the logs that will be sent to Sysdig. This will affect Sysdig runtime visibility and threat detection capabilities. Contact your Sysdig representative for more information or assistance with this process.\nTune Log Volume Using the Onboarding UITo customize log volume through the UI, you can follow the instructions in Set Up Log Ingestion.\nWhen you Select Sources (optional), choose one of the following:\nGuided customization: Use this option to simply select the sources you want to use. The Terraform snippet/CloudFormation Template parameters you obtain at the end of the flow will be configured accordingly. Advanced customization: Use this option to define a custom Event pattern inside your Terraform snippet/CloudFormation Template parameters. Additional guidance on this is available in the next paragraph. Tune Log volume via Terraform/CFTOnce you have your desired Event pattern, you can customize the event_pattern parameter in the log_ingestion.tf Terraform snippet, located in the event-bridge module. Example:\nmodule \u0026#34;event_bridge\u0026#34; { ... event_pattern = \u0026lt;\u0026lt;EOF { \u0026#34;detail-type\u0026#34;: [ \u0026#34;AWS API Call via CloudTrail\u0026#34; ], \u0026#34;detail\u0026#34;: { \u0026#34;eventCategory\u0026#34;: [ \u0026#34;Management\u0026#34; ] } } EOF } To customize this in the CFT stack creation, edit the EventBridge Rule Event Pattern parameter, setting it to your desired value.\nRaise the API Destination Rate Limit This applies to setups after the June 5th, 2025 release/using Terraform event-bridge module v3 or above.\nBy default, API destinations limit the rate to 300 requests/second per account and region. You can raise this limit via:\nThe AWS Management Console Terraform with the following snippet: resource \u0026#34;aws_servicequotas_service_quota\u0026#34; \u0026#34;example\u0026#34; { quota_code = \u0026#34;L-755FD01C\u0026#34; service_code = \u0026#34;events\u0026#34; value = 1500 //new quota value } This also allows other API destinations to set higher rate limits.\nOnce you have raised the limit, use Terraform or CloudFormation Templates (CFT) to apply the new rate limit to the API destination.\nRaise Rate Limit in TerraformTo apply the new rate the limit to Sysdig\u0026rsquo;s API Destination in Terraform:\nEdit the log_ingestion.yaml file. Add the api_dest_rate_limit parameter, setting it to the desired value: module \u0026#34;event_bridge\u0026#34; { ... api_dest_rate_limit = 1500 } Run terraform apply Raise Rate Limit in CFTTo apply the new rate limit to Sysdig\u0026rsquo;s API Destination in CloudFormation Templates (CFT):\nOpen the Stack Click Update. Use the existing template. Customize Rate Limit with the desired limit. Submit the update. Monitor Buckets with NotificationsCloudTrail allows you to monitor operations on S3 buckets as part of Data events. If you enabled them, those logs will be forwarded to Sysdig with either of the setups. Instead, if they\u0026rsquo;re not enabled, you\u0026rsquo;re using EventBridge and you\u0026rsquo;re looking for an alternative to monitor operations performed on objects stored in AWS Simple Storage Service (S3) buckets, or avoid forwarding all the data logs to Sysdig, you can leverage S3 Event Notifications.\nTo learn about supported event types, see AWS\u0026rsquo;s documentation on EventBridge. To enable this function, see Enabling Amazon EventBridge. Once enabled, you can configure the Event Notifications on the buckets of your interest and EventBridge will forward the events from those buckets to Sysdig and processed using the configured policies and rules.\nCheck the Connection StatusTo check the connection status:\nLog in to Sysdig Secure and select Integrations \u0026gt; Environments \u0026gt; AWS.\nSelect the desired account to review the status in the detail drawer.\nIf the connection is successful, you will see the feature as Connected.\nGiven below are the possible health statuses for Advanced CIEM:\nStatus Description Healthy ✅ The account has been successfully connected, and all the CIEM tasks are processed as expected. Error ❌ Error processing the CIEM analysis tasks. ","url":"https://docs.sysdig.com/en/sysdig-secure/aws/configure-threat-detection-ciem/"},{"id":196,"title":"Configure Vulnerability Management for AWS","content":" Sysdig released a new onboarding experience for AWS in September 2024. If you onboarded your AWS Organization or Account before September 30, 2024, and would like to add more features, contact your Sysdig representative.\nPrerequisites An AWS Account or Organization already connected to Sysdig. Access to a User with the permissions required to install. Set Up Volume Access Log in to Sysdig Secure, select Integrations \u0026gt; Environments \u0026gt; AWS.\nSelect an Account that is part of the Organization you would like to add features to, or the individual Account you onboarded.\nThe detail panel appears on the right. It displays a list of features.\nClick Setup beside a desired feature to open the wizard.\nEnsure you have the necessary permissions configured as described in the initial setup.\nExclude or Include Resources from Vulnerability Scanning:\nYou can exclude VPCs or Hosts from scans using tags. For more information, see Exclude/Include Resources From Vulnerability Scanning. Verify the details of your Organization or Account where the features will be added.\nGenerate and apply the Terraform code:\nCreate a volume_access.tf file in the folder that contains your main.tf.\nCopy the snippet provided into the volume_access.tf file.\nRun the command: terraform init \u0026amp;\u0026amp; terraform apply.\nEnsure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; AWS. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/aws//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;5.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/aws//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;5.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } Exclude/Include Resources from Vulnerability ScanningWhen you connect your AWS account with Vulnerability Host Scanning, by default all Virtual Private Cloud (VPC) and Elastic Compute Cloud (EC2) Instances with root volumes in the account are included in the scan.\nYou can use tags to exclude specific VPCs or EC2 Instances from being scanned.\nHow to exclude VPCs or Hosts: To exclude certain VPCs or EC2 instances from being scanned, assign specific tags to them in the AWS Console or using AWS APIs.\nWe recommend you set these tags before initiating the scanning process. You can add tags after onboarding, but the exclusion will only take effect in subsequent scans.\nHow to include Data Volumes in Scans: By default, only root volumes of EC2 Instances are scanned.\nTo also include data volumes in scans, use specific tags as follows:\nTagging SemanticsYou can use the following tags at volume, EC2, or VPC level. You can add tagging at any time, for example, if you want to exclude/include something that was or was not scanned.\nKeys: sysdig:secure:scan, sysdig:secure:data-volumes:scan.\nValues: true, false\nUsage Examples\n“sysdig:secure:scan” : “false” on a VPC excludes all resources in the VPC from scanning. “sysdig:secure:scan” : “false” on an EC2 Instance excludes the instance and all its volumes from scanning “sysdig:secure:scan” : “true” on a data-volume of an EC2 Instance includes such volume for scanning “sysdig:secure:data-volumes:scan” : “true” on a VPC has the same effect as applying the “sysdig:secure:scan” : “true” tag to all the data-volumes of all the EC2 instances in it “sysdig:secure:data-volumes:scan” : “true” on an EC2 Instance has the same effect as applying the “sysdig:secure:scan” : “true” tag to all its data-volumes “sysdig:secure:data-volumes:scan” : “true” on a VPC, while “sysdig:secure:data-volumes:scan” : “false” on an EC2 Instance of the same VPC, has the same effect as applying the “sysdig:secure:scan” : “true” tag to all data-volumes of all the EC2 instances within the VPC except the one explicitly excluded via the tag. The following tags are redundant; using them will have the same effect as not having them. This is either because Sysdig scans them by default or because the values have been overridden by a tag at a higher level, such as a VPC or an EC2 Instance.\n“sysdig:secure:scan” : “true” on a VPC “sysdig:secure:scan” : “true” on an EC2 Instance “sysdig:secure:scan” : “true” on the root volume of an EC2 Instance “sysdig:secure:scan” : “false” on any data-volumes of an EC2 Instance “sysdig:secure:scan” : “false” on the root volume of an EC2 Instance has no effect. The root volume is always scanned as part of the EC2 instance scan. “sysdig:secure:data-volumes:scan” : “false” on a VPC “sysdig:secure:data-volumes:scan” : “false” on an EC2 Instance “sysdig:secure:data-volumes:scan” : “false” on any data-volumes of an EC2 Instance Enable Malware ScanningMalware Scanning (preview) is available for connected AWS accounts with Host Scanning enabled. To enable Malware Scanning:\nLog in to Sysdig Secure.\nSelect Integrations \u0026gt; Environments \u0026gt; AWS.\nSelect your desired connected account.\nHost Scanning must be enabled. If it is not, Set Up Volume Access to enable it.\nUnder Host Scanning, toggle Malware Scanning on to enable it.\nMalware Scanning is now enabled.\nIn Search, you can View Malware Scanning Results.\nFor more details, see Malware Scanning.\nCheck Connection StatusTo check the connection status:\nLog in to Sysdig Secure and select Integrations \u0026gt; Environments \u0026gt; AWS.\nSelect the desired account to review the status in the detail drawer.\nIf the connection is successful, you will see the feature as Connected. This may take up to 5 minutes after deploying the Terraform.\nGiven below are the possible health statuses for Vulnerability Management Host Scanning and Workload Scanning:\nHost ScanningHealth status of Host scanning is checked every 8 hours.\nStatus Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Warning ⚠ Discovered no hosts Scanned hosts are unsupported Error ❌ Failed the scanning. Workload ScanningHealth status of Workload scanning is checked every 3 hours.\nStatus Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Warning ⚠ Discovered no workloads. Error ❌ Failed the scanning. ","url":"https://docs.sysdig.com/en/sysdig-secure/aws-configure-vm/"},{"id":197,"title":"Configure Vulnerability Management for Azure","content":" Sysdig released a new onboarding experience for Azure in August 2024. If you onboarded your Azure tenant and/or subscription before the 6th of August, 2024, and would like to add more features, contact your Sysdig representative.\nVulnerability Host Scanning relies on the following Azure features:\nAzure LightHouse: Manages the relationship between the Sysdig Service Principal and the target subscriptions. Snapshot: Shares disks with Sysdig. To configure VM, set up volume access.\nPrerequisites You must have an Azure Subscription or Tenant already connected to Sysdig.\nAccess to a User with the permissions required to install.\nEnable Microsoft Managed Services (Lighthouse) in each subscription using agentless scanning:\nfor sub in $(az account list --query \u0026#34;[].id\u0026#34; -o tsv); do echo \u0026#34;Registering MMS in $sub\u0026#34; az provider register --namespace Microsoft.ManagedServices --subscription \u0026#34;$sub\u0026#34; done For more details, see Missing Microsoft.ManagedServices Namespace Registration.\nSet Up Volume AccessUse the following instructions to set up volume access for Vulnerability Host Scanning for your Azure instances.\nLog in to Sysdig Secure, select Integrations \u0026gt; Environments \u0026gt; Azure. Select an account that is part of the tenant you would like to add features to or the individual account you onboarded. On the right panel, you will see a list of features. Click Setup beside a desired feature to open the wizard. Ensure you have the necessary permissions configured as described in the initial setup. Exclude or Include Resources from Vulnerability Scanning: You can exclude resource groups and virtual machines from scans using tags. For more information, see how to include/exclude resources. Verify the details of your tenant and the subscription where the features will be added. Generate and apply the Terraform code: Create a volume_access.tf file in the folder that contains your main.tf. Copy the snippet provided into the volume_access.tf file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. Ensure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; Azure. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/azurerm//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;3.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/azurerm//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;3.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } Exclude/Include Resources from Vulnerability ScanningBy default, all Resource Groups and Virtual Machines with root disks are included in scans. To manage exclusions and inclusions, use the following tags:\nKey Value Description sysdig:secure:scan true Include in scan false Exclude from scan sysdig:secure:data-volumes:scan true Include data volumes in scan false Exclude data volumes from scan Usage Examples Tag Level Effect sysdig:secure:scan: \u0026quot;false\u0026quot; Resource Group Excludes all resources within that group from scanning sysdig:secure:scan: \u0026quot;false\u0026quot; Virtual Machine Excludes the VM and all its disks from scanning sysdig:secure:scan: \u0026quot;true\u0026quot; Data Disk Includes the disk for scanning sysdig:secure:data-volumes:scan: \u0026quot;true\u0026quot; Resource Group Includes all data disks in that group for scanning sysdig:secure:data-volumes:scan: \u0026quot;true\u0026quot; Virtual Machine Includes all its data disks for scanning sysdig:secure:data-volumes:scan: \u0026quot;true\u0026quot; Resource Group and VM Excludes the VM\u0026rsquo;s data-disks but includes others in the group Redundant Tags Tag Description sysdig:secure:scan: \u0026quot;true\u0026quot; Sysdig scans by default, so these tags are redundant. sysdig:secure:data-volumes:scan: \u0026quot;false\u0026quot; Sysdig does not scan data volumes by default unless explicitly included. Enable Malware ScanningMalware Scanning (preview) is available for connected Azure accounts with Host Scanning enabled. To enable Malware Scanning:\nLog in to Sysdig Secure.\nSelect Integrations \u0026gt; Environments \u0026gt; Azure.\nSelect your desired connected account.\nHost Scanning must be enabled. If it is not, Set Up Volume Access to enable it.\nUnder Host Scanning, toggle Malware Scanning on to enable it.\nMalware Scanning is now enabled.\nIn Search, you can View Malware Scanning Results.\nFor more details, see Malware Scanning.\nCheck the Connection StatusYou can verify your Vulnerability Management configuration by checking your connection status:\nLog in to Sysdig Secure and select Integrations \u0026gt; Environments \u0026gt; Azure.\nSelect your account.\nThe detail drawer appears on the right.\nIf the connection is successful, you will see the feature as Connected. This may take up to 5 minutes after deploying the Terraform.\nGiven below are the possible health statuses for Vulnerability Management Host Scanning and Workload Scanning:\nHost ScanningHealth status of Host scanning is checked every 8 hours.\nStatus Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Warning ⚠ Discovered no hosts Scanned hosts are unsupported Error ❌ Failed the scanning. Workload ScanningHealth status of Workload scanning is checked every 3 hours.\nStatus Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Warning ⚠ Discovered no workloads. Error ❌ Failed the scanning. ","url":"https://docs.sysdig.com/en/sysdig-secure/azure-configure-vm/"},{"id":198,"title":"Configure Vulnerability Management for GCP","content":" Snapshot: Shares disks with Sysdig. Sysdig released a new onboarding experience for GCP in October 2024. If you onboarded your GCP organization and/or project before October, 2024, and would like to add more features, contact your Sysdig representative.\nTo configure Vulnerability Management, set up volume access.\nPrerequisites You must have an GCP Project or Organization already connected to Sysdig. Access to a User with the permissions required to install. Volume Access Installation StepsUse the following steps to set up volume access for Vulnerability Host Scanning for your GCP instances.\nLog in to Sysdig Secure, select Integrations \u0026gt; Environments \u0026gt; GCP. Select a project that is part of the organization you would like to add features to or the individual account you onboarded. On the right panel, you will see a list of features. Click Setup beside a desired feature to open the wizard. Ensure you have the necessary permissions configured as described in the initial setup. Exclude or Include Resources from Vulnerability Scanning: You can exclude resource groups and virtual machines from scans using labels. For more information, see how to include/exclude resources. Verify the details of your organization and the project where the features will be added. Generate and apply the Terraform code: Create a volume_access.tf file in the folder that contains your main.tf. Copy the snippet provided into the volume_access.tf file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. Ensure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; GCP. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/google//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;2.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/google//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;2.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } Exclude and Include Resources from Vulnerability ScanningWhen you connect a GCP project with Vulnerability Host Scanning, by default all Compute Instances with root volumes in the project are included in the scan.\nYou can exclude specific Compute Instances from being scanned using labels.\nExclude InstancesTo exclude certain Compute Instances from being scanned, you must assign specific labels to them in the GCP Console or using GCP APIs.\nSet these labels before initiating the scanning process. If you add labels after onboarding, the exclusion will only take effect in subsequent scans.\nInclude Data Volumes in ScansBy default, only root volumes of Compute Instances are scanned.\nTo also include data volumes in scans, you need to use the following specific labels.\nTagging SemanticsYou can use the following labels at Volume or Compute Instance level. Tagging can be added at any time, for example, if you want to exclude/include something that was or was not scanned.\nKey: sysdig-secure-scan, sysdig-secure-data-volumes-scan.\nValues: true, false\nUsage Examples\n“sysdig-secure-scan” : “false” on a Compute Instance excludes the instance and all its volumes from scanning “sysdig-secure-scan” : “true” on a data-volume of a Compute Instance includes such volume for scanning “sysdig-secure-data-volumes-scan” : “true” on a Compute Instance has the same effect as applying the “sysdig-secure-scan” : “true” tag to all its data-volumes. The following tags are redundant; using them will have the same effect as not having them. This is either because Sysdig scans them by default or because the values have been overridden by a tag at a higher level (such as a Compute Instance).\n“sysdig-secure-scan” : “true” on a Compute Instance “sysdig-secure-scan” : “true” on the root volume of a Compute Instance “sysdig-secure-scan” : “false” on any data-volumes of a Compute Instance “sysdig-secure-scan” : “false” on the root volume of a Compute Instance has no effect. The root volume is always scanned as part of the Compute Instance scan. “sysdig-secure-data-volumes-scan” : “false” on a Compute Instance “sysdig-secure-data-volumes-scan” : “false” on any data-volumes of a Compute Instance. Enable Malware ScanningMalware Scanning (preview) is available for connected GCP accounts with Host Scanning enabled. To enable Malware Scanning:\nLog in to Sysdig Secure.\nSelect Integrations \u0026gt; Environments \u0026gt; GCP.\nSelect your desired connected account.\nHost Scanning must be enabled. If it is not, Set Up Volume Access to enable it.\nUnder Host Scanning, toggle Malware Scanning on to enable it.\nMalware Scanning is now enabled.\nIn Search, you can View Malware Scanning Results.\nFor more details, see Malware Scanning.\nCheck the Connection StatusYou can verify your Vulnerability Management configuration by checking your connection status. It may take 10 minutes or so for events to be collected and displayed.\nLog in to Sysdig Secure and select Integrations \u0026gt; Environments \u0026gt; GCP.\nSelect your account.\nThe detail drawer appears on the right.\nIf the connection is successful, you will see the feature as Connected. This may take up to 5 minutes after deploying the Terraform.\nGiven below are the possible health statuses for Vulnerability Management Host Scanning and Workload Scanning:\nHost ScanningHealth status of Host scanning is checked every 8 hours.\nStatus Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Warning ⚠ Discovered no hosts Scanned hosts are unsupported Error ❌ Failed the scanning. Workload ScanningHealth status of Workload scanning is checked every 3 hours.\nStatus Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Warning ⚠ Discovered no workloads. Error ❌ Failed the scanning. ","url":"https://docs.sysdig.com/en/sysdig-secure/gcp-configure-vm/"},{"id":199,"title":"Connect to HTTP Proxy","content":"Connect to an HTTP ProxyYou can configure the Serverless Workload Agent to connect to an HTTP Proxy by using the SYSDIG_EXTRA_CONF environment variable. This variable accepts values in either YAML or JSON format. You must provide the options under the http_proxy heading.\nOption Default Description proxy_host The hostname of the proxy server. An empty string disables the proxy connection. proxy_port The port on the proxy server for the agent to connect to. Zero or empty string disables the proxy connection. proxy_user Specifies the username for HTTP authentication. An empty string indicates no authentication. proxy_password Specifies the password for HTTP authentication. Leave it blank if proxy_user is specified without it. ssl false If set to true, the connection between the agent and the proxy server is encrypted. ssl_verify_certificate true Determines whether the agent will verify the certificate presented by the proxy. ca_certificate The path to the CA certificate for the proxy server. If SSL verification is enabled, the certificate must be appropriately signed. For further details, see Enable HTTP proxy for agents.\nExampleThe following configuration, provided through the SYSDIG_EXTRA_CONF environment variable, shows how to set up the Workload Agent to connect to an HTTP proxy with:\nsquid.my.domain.com:6444 as the host and port; my-user as the username; my-proxy-password as the password. SYSDIG_EXTRA_CONF=\u0026#34;http_proxy:\\n proxy_host: squid.my.domain.com\\n proxy_port: 6443\\n proxy_user: my-user\\n proxy_password: my-proxy-password\u0026#34; Note that newlines and spaces are important when passing this configuration as YAML to the Workload Agent.\n","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-connect-http-proxy/"},{"id":200,"title":"Containers","content":" Sysdig Agent Vulnerability Host Scanner Posture Host Analyzer Rapid Response Next StepsInstall the Sysdig Agent as a container\nInstall the Vulnerability Host Scanner as a container\nInstall the Posture Host Analyzer as a container\nInstall the Rapid Response as a container\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-container-install/"},{"id":201,"title":"Install Host Shield as a Container","content":"Migrate to the Host ShieldThe Host Shield is nothing but the agent container. Starting from Sysdig Agent 13.6.1, you can enable additional features such as Host Scanning, Host Security Posture Management, and Rapid Response directly from the container configuration.\nPrerequisites Review System Requirements Understand Agent Drivers Collect the following: Sysdig Access Key Collector Address and Port for COLLECTOR and PORT Secure API Endpoint to use for SYSDIG_API_ENDPOINT System Requirements A supported distribution or Kubernetes platform\nPort 6443 open for outbound traffic\nThe Host Shield communicates with the collector on port 6443. If you\u0026rsquo;re using a firewall, make sure to open port 6443 for outbound traffic so that the Host Shield can communicate with the collector.\nAllow traffic on port 12000 to communicate within the cluster for Kubernetes Security Posture Management (KSPM).\nKubernetes PlatformsThe supported Kubernetes platforms are:\nKubernetes (Vanilla)\nAmazon Elastic Kubernetes Service (EKS)\nNote: AWS Fargate is not supported on EKS\nGoogle Kubernetes Engine (GKE)\nAzure Kubernetes Service (AKS)\nRedHat Openshift\nIBM Kubernetes Service (IKS)\nRKE Government (RKE2)\nLinux DistributionsThe supported Linux distributions are:\nDebian Ubuntu 18.04 and above Ubuntu (Amazon) CentOS 7 and above Alma Linux Rocky Linux Red Hat Enterprise Linux (RHEL) 7 and above SuSE Linux Enterprise Server* RHEL CoreOS (RHCOS) Fedora Fedora CoreOS Linux Mint Amazon Linux (Original) Amazon Linux 2 (AL2) Amazon Linux 2023 (AL2023) Amazon Bottlerocket Google Container Optimized OS (COS) Oracle Linux (UEH) Oracle Linux (RHCK) Azure Linux (CBL-Mariner) EulerOS ArchLinux Alpine Linux 3.20 and above We may support additional Linux distributions depending on the feature required. For more details, Contact Sysdig Support.\nCPU ArchitecturesThe supported CPU architectures are:\nX86 ARM Install the Host ShieldTo install the Host Shield as a container using Docker Compose, create a docker-compose.yml file with the following content:\nversion: \u0026#39;3.8\u0026#39; services: sysdig-agent: image: quay.io/sysdig/agent-slim:14.0.0 container_name: sysdig-host-shield restart: always privileged: true network_mode: host pid: host shm_size: 512M environment: ACCESS_KEY: \u0026lt;ACCESS_KEY\u0026gt; COLLECTOR: \u0026lt;COLLECTOR_URL\u0026gt; COLLECTOR_PORT: \u0026lt;COLLECTOR_PORT\u0026gt; SYSDIG_AGENT_DRIVER: universal_ebpf ADDITIONAL_CONF: | host_scanner: enabled: true host_fs_mount_path: /host scan_containers_enabled: true kspm_analyzer: enabled: true host_root: /host features: respond: response_actions: enabled: true detections: drift_control: enabled: true malware_control: enabled: true file_integrity_monitoring: enabled: true ml_policies: enabled: true sysdig_api_endpoint: \u0026lt;SECURE_API_ENDPOINT\u0026gt; volumes: - /:/host:ro - /sys/kernel/debug:/sys/kernel/debug:ro - /var/run/docker.sock:/host/var/run/docker.sock For additional configuration options, reach out to your account representative or support.\nParameter Breakdown: ACCESS_KEY: Your Sysdig Access Key. COLLECTOR: The Sysdig collector URL for your SaaS region. COLLECTOR_PORT: The port used by the Sysdig collector. sysdig_api_endpoint: Specifies the Sysdig API URL for your SaaS region. host_scanner: Enables host vulnerability scanning. kspm_analyzer: Enables Host Security Posture Management analysis. feaures.respond.response_actions: Enables and configures Response Actions. Read more in the dedicated page Deploy the Host Shield Save the docker-compose.yml file in your working directory. Replace the following with your actual Sysdig configuration values: \u0026lt;ACCESS_KEY\u0026gt; \u0026lt;COLLECTOR_URL\u0026gt; \u0026lt;COLLECTOR_PORT\u0026gt; \u0026lt;SECURE_API_ENDPOINT\u0026gt; Start the container: docker compose up -d Rapid ResponseTo enable Rapid Response, add the following configuration to the ADDITIONAL_CONF.\nADDITIONAL_CONF: | rapid_response: enabled: true password: \u0026lt;RR_PASSWORD\u0026gt; Later, you can use the password you define here to Start Rapid Response.\nSee Respond for more information.\nFurther customizations are available in the Configuration Library.\n","url":"https://docs.sysdig.com/en/sysdig-secure/install-container-host-shield/"},{"id":202,"title":"Create Custom Prometheus Jobs via API","content":"OverviewCustom Prometheus jobs created with the API behave exactly like regular Prometheus jobs defined traditionally through the prometheus.yaml. Using the API, you can define a job with all scrape_config parameters including metric_relabel_config. Once the job is created and enabled, job configuations are automatically pushed to relevant agents in your infrastructure without requiring manual configuration updates or agent redeployment. Custom Prometheus jobs support cluster-wide definitions and also allow for selective enablement or disablement on a per-cluster level.\nCustom Prometheus jobs must be created and then enabled for the job to start collecting metrics\nJob Priority when Names ConflictWhen multiple Prometheus jobs share the same name, Sysdig Monitor uses the following precedence rules to determine which job takes effect:\nPriority Source Description 1 (Highest) prometheus.yaml agent configuration Jobs defined directly in the agent’s prometheus.yaml override all others. 2 Metrics Disablement API Metrics disabled via the Metrics Disablement API will continue to be dropped, even if a custom job attempts to collect them. 3 Custom Prometheus Jobs (API) Jobs created via the custom Prometheus Job API will override Enabled-by-Defualt Integrations if they have the same job name. 4 (Lowest) Enabled-by-Default Integrations Jobs automatically created by Sysdig’s built-in integrations. This includes the default k8s-pods job that scrapes any pod with the prometheus.io/scrape=true annotation. Best Practices Validate your configuration before pushing: Use promtool check config to validate your job definition locally. This helps catch syntax errors that could cause the Prometheus scrape process to fail on the agent. The API does not perform strict validation. Use caution when deploying changes as metrics collection can fail when pushing invalid changes.\nUse unique and descriptive job names: Use clear naming conventions to avoid unintentional name collisions with existing Prometheus jobs, especially those from built-in integrations or local agent configs (prometheus.yaml).\nVerify deployment using the Agent Console: After creating or updating a job, use the Agent Console command prometheus scrape_jobs show to inspect the final scrape configuration applied to each agent. This helps confirm targeting and relabeling logic are working as expected.\nTest in a single cluster first: If possible, roll out and validate a new job in a single cluster before enabling it globally.\nAccess Next Gen API DocsFor further detail regarding API usage, review the Metrics Collection section in the Next Gen API docs.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/custom-integrations/custom-prometheus-job-api/"},{"id":203,"title":"Cross-Platform Configuration Library","content":"For more information, see:\nAdd Custom CA Certificates\nDriver Modes\nConfiguration\n","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-cross-platform-configuration-library/"},{"id":204,"title":"Docker/CIS Benchmarks","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\ncompliance.docker-bench.container-images-and-build-file.pass_pctThe percentage of successful Docker benchmark tests run on the container images and build files.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.container-images-and-build-file.tests_failThe number of failed Docker benchmark tests run against the container images and build file.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.container-images-and-build-file.tests_passThe number of successful Docker benchmark tests run against the container images and build file.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.container-images-and-build-file.tests_totalThe total number of tests run against the container images and build file.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.container-runtime.pass_pctThe percentage of successful container runtime Docker benchmark tests.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.container-runtime.tests_failThe number of failed container runtime benchmark tests.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.container-runtime.tests_passThe number of successful container runtime Docker benchmark tests.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.container-runtime.tests_totalThe total number of Docker benchmark tests run against container runtimes.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-caps-addedThe number of containers running without kernel restrictions in place.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-maxretry-not-setThe number of containers configured to not limit installation retries if the initial attempt fails.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-mount-prop-sharedThe number of containers that use mount propagation.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-networking-hostThe number of containers that share the host\u0026rsquo;s network namespace.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-no-apparmorThe number of containers running without an AppArmor profile.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-no-cpu-limitsThe number of containers running with no CPU limits configured.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-no-health-checkThe number of containers that have no HEALTHCHECK instruction configured.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-no-mem-limitsThe number of containers configured to run without memory limitations.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-no-pids-cgroup-limitThe number of containers that do not use a cgroup for PIDs.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-no-restricted-privsThe number of containers running that can have additional privileges configured.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-no-seccompThe number of containers that disable the default seccomp profile.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-no-securityoptsThe number of containers running without SELinux options configured.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-no-ulimit-overrideThe number of containers running that override the default ulimit.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-privileged-portsThe number of containers that have privileged ports mapped into them.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-root-mounted-rwThe number of containers that mount the host\u0026rsquo;s root filesystem with read/write privileges.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-running-privilegedThe number of containers running with the --privileged configuration option set.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-sensitive-dirsThe number of containers that have mounted a sensitive directory from the host.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-sharing-docker-sockThe number of containers that share the host\u0026rsquo;s docker socket.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-sharing-host-devsThe number of containers that share one or more host devices.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-sharing-host-ipc-nsThe number of containers that share the host\u0026rsquo;s IPC namespace.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-sharing-host-pid-nsThe number of containers that share the host\u0026rsquo;s PID namespace.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-sharing-host-user-nsThe number of containers that share the host\u0026rsquo;s user namespace.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-sharing-host-uts-nsThe number of containers that share the host\u0026rsquo;s UTS namespace.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-sshd-docker-exec-failuresThe number of containers running an SSH daemon.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-unexpected-cgroupThe number of containers running without a dedicated cgroup configured.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-using-docker0-netThe number of containers using the default docker bridge network docker0.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.c-wildcard-bound-portThe number of containers that do not bind incoming traffic to a specific interface.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-daemon-configuration.pass_pctThe percentage of successful Docker benchmark tests run against the Docker daemon configuration.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-daemon-configuration.tests_failThe number of benchmark tests run against the Docker daemon configuration that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-daemon-configuration.tests_passThe number of benchmark tests run against the Docker daemon configuration that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-daemon-configuration.tests_totalThe total number of benchmark tests run against the Docker daemon configuration.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-daemon-configuration-files.pass_pctThe percentage of successful Docker benchmark tests run against the Docker daemon configuration files.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-daemon-configuration-files.tests_failThe number of benchmark tests run against the Docker daemon configuration files that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-daemon-configuration-files.tests_passThe number of benchmark tests run against the Docker daemon configuration files that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-daemon-configuration-files.tests_totalThe total number of benchmark tests run against the Docker daemon configuration files.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-security-operations.pass_pctThe percentage of benchmark tests run against Docker security operations that were successful.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-security-operations.tests_failThe number of benchmark tests run against Docker security operations that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-security-operations.tests_passThe number of benchmark tests run against Docker security operations that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-security-operations.tests_totalThe total number of benchmark tests run against Docker security operations.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-swarm-configuration.pass_pctThe percentage of benchmark tests run against the Docker swarm configuration that were successful.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-swarm-configuration.tests_failThe number of benchmark tests run against the Docker swarm configuration that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Maxv compliance.docker-bench.docker-swarm-configuration.tests_passThe number of benchmark tests run against the Docker swarm configuration that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-swarm-configuration.tests_totalThe total number of benchmark tests run against the Docker swarm configuration.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.docker-usersThe number of user accounts with permission to access the Docker daemon socket.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.host-configuration.pass_pctThe percentage of benchmark tests run against the host configuration that were successful.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.host-configuration.tests_failThe number of benchmark tests run against the host configuration that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.host-configuration.tests_passThe number of benchmark tests run against the host configuration that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.host-configuration.tests_totalThe total number of benchmark tests run against the host configuration.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.img-images-using-addThe number of images that use the COPY function rather than the ADD function in Dockerfile.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.img-no-healthcheckThe number of images with no HEALTHCHECK instruction configured.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.img-running-rootThe number of images that use the root user.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.img-update-insts-foundThe number of images that run a package update step without a package installation step.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.pass_pctThe percentage of Docker benchmark tests run that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.scoreThe current pass/fail score for Docker benchmark tests run. The value of this metric is calculated by starting at zero, and incrementing once for every successful test, and decrementing once for every test that returns a WARN result or worse.\nMetadata Description Metric Type Counter Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.tests_failThe total number of Docker benchmark tests that have failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.tests_passThe total number of Docker benchmark tests that have passed\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.docker-bench.tests_totalThe total number of Docker benchmark tests that have been run.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/docker-cis-benchmarks/"},{"id":205,"title":"Elasticache","content":"aws.elasticache.CPUUtilizationThe percentage of CPU utilization.\nWhen reaching high utilization and your main workload is from read requests, scale your cache cluster out by adding read replicas. If the main workload is from write requests, scale up by using a larger cache instance type.\nFor more information, refer to the ElastiCache documentation.\nMetadata Description Metric Type Gauge Value Type % Segment By CloudProvider Default Time Aggregation Averave Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.elasticache.FreeableMemoryThe amount of memory considered free, or that could be made available, for use by the node.\nFor more information, refer to the ElastiCache documentation.\nMetadata Description Metric Type Gauge Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.elasticache.NetworkBytesInThe number of bytes the host has read from the network.\nFor more information, refer to the ElastiCache documentation.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elasticache.NetworkBytesOutThe number of bytes the host has written to the network.\nFor more information, refer to the ElastiCache documentation.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elasticache.SwapUsageThe amount of swap space used on the host.\nIf swap is being utilized, the node probably needs more memory than is available and cache performance may be negatively impacted. Consider adding more nodes or using larger ones to reduce or eliminate swapping.\nFor more information, refer to the ElastiCache documentation.\nMetadata Description Metric Type Gauge Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/sysdig-monitor/aws-metrics-legacy/elasticache/"},{"id":206,"title":"Enable Data Security Findings for AWS","content":"Sensitive data is analyzed in-place and remains within your AWS accounts during scanning.\nAWS services that are currently supported for scanning include:\nS3 Buckets RDS Databases Prerequisites An AWS Account or Organization already connected to Sysdig. A Sysdig Secure Risk Management or CNAPP subscription with the Data Security Findings add-on. Data Security Findings is currently available through a guided onboarding process. Contact your Sysdig account team or support representative to enable this feature.\nEnable Data Security Findings Contact your Sysdig account team or support representative to enable Data Security Findings for your AWS accounts. Once provisioned, log in to Sysdig Secure and navigate to Integrations \u0026gt; Environments \u0026gt; AWS. Select the AWS account you want to verify. Data Security Findings will appear in the features list once enabled. Check Enabled StatusYou can confirm whether Data Security Findings is active for your account:\nIn Sysdig Secure, go to Integrations \u0026gt; Environments \u0026gt; AWS.\nSelect the account.\nThe detail panel on the right will show the status of Data Security Findings.\nIf onboarding is complete, the feature status will show Enabled or Healthy.\n","url":"https://docs.sysdig.com/en/sysdig-secure/aws-data-security-findings/"},{"id":207,"title":"Enable Data Security Findings for Azure","content":"Sensitive data is analyzed in-place and remains within your Azure accounts during scanning.\nAzure services that are currently supported for scanning include:\nAzure Blob Storage Prerequisites An Azure Account or Organization already connected to Sysdig. A Sysdig Secure Risk Management or CNAPP subscription with the Data Security Findings add-on. Data Security Findings is currently available through a guided onboarding process. Contact your Sysdig account team or support representative to enable this feature.\nEnable Data Security Findings Contact your Sysdig account team or support representative to enable Data Security Findings for your Azure accounts. Once provisioned, log in to Sysdig Secure and navigate to Integrations \u0026gt; Environments \u0026gt; Azure. Select the Azure account you want to verify. Data Security Findings will appear in the features list once enabled. Check Enabled StatusYou can confirm whether Data Security Findings is active for your account:\nIn Sysdig Secure, go to Integrations \u0026gt; Environments \u0026gt; Azure.\nSelect the account.\nThe detail panel on the right will show the status of Data Security Findings.\nIf onboarding is complete, the feature status will show Enabled or Healthy.\n","url":"https://docs.sysdig.com/en/sysdig-secure/azure-data-security-findings/"},{"id":208,"title":"Enable Data Security Findings for GCP","content":"Sensitive data is analyzed in-place and remains within your GCP accounts during scanning.\nGCP services that are currently supported for scanning include:\nGoogle Cloud Storage (GCS) buckets Prerequisites A GCP Account or Organization already connected to Sysdig. A Sysdig Secure Risk Management or CNAPP subscription with the Data Security Findings add-on. Data Security Findings is currently available through a guided onboarding process. Contact your Sysdig account team or support representative to enable this feature.\nEnable Data Security Findings Contact your Sysdig account team or support representative to enable Data Security Findings for your GCP accounts. Once provisioned, log in to Sysdig Secure and navigate to Integrations \u0026gt; Environments \u0026gt; GCP. Select the GCP account you want to verify. Data Security Findings will appear in the features list once enabled. Check Enabled StatusYou can confirm whether Data Security Findings is active for your account:\nIn Sysdig Secure, go to Integrations \u0026gt; Environments \u0026gt; GCP.\nSelect the account.\nThe detail panel on the right will show the status of Data Security Findings.\nIf onboarding is complete, the feature status will show Enabled or Healthy.\n","url":"https://docs.sysdig.com/en/sysdig-secure/gcp-data-security-findings/"},{"id":209,"title":"Enable Kube State Metrics","content":"Supported Kubernetes ResourcesCluster Shield can collect the following Kubernetes resources:\ncertificatesigningrequest configmap cronjob daemonset deployment horizontalpodautoscaler ingress job namespace node persistentvolume persistentvolumeclaim pod poddisruptionbudget replicaset replicationcontroller resourcequota service statefulset storageclass Collect KSMsTo collect KSMs, configure Cluster Shield.\nThis replaces the legacy classic agent method. See Cluster Shield 1.11.0.\nCluster Shield 1.11.0 and AboveTo collect Kubernetes State Metrics (KSM) with Cluster Shield, add this configuration to values.yaml:\nfeatures: monitor: kube_state_metrics: enabled: true You can also apply it with a Helm command:\n--set clusterShield.cluster_shield.features.monitor.kube_state_metrics.enabled=true To enable KSM, Kubernetes metadata, Kubernetes events, and metadata messages carrying CostAdvisor data, use this command:\n--set clusterShield.cluster_shield.features.kubernetes_metadata.enabled: true \\ --set clusterShield.cluster_shield.features.monitor.kube_state_metrics.enabled=true \\ --set clusterShield.cluster_shield.features.monitor.kubernetes_events.enabled=true \\ Collect KSMs (Legacy)To collect KSM with the classic agent, enable the kubernetes_metadata feature. This configuration also enables the collection of Kubernetes events.\nRequired KSM FamiliesSome metric families are enabled by default, while others must be manually enabled.\nThe following KSM families cannot be disabled as they are required for certain parts of the Sysdig Platform to function:\ncronjobs daemonsets deployments jobs namespaces nodes pods replicasets replicationcontrollers statefulsets The following Kube State Metrics families are collected by default, but can be disabled if desired:\nservices resourcequotas persistentvolumes persistentvolumeclaims storageclasses configmaps Agent Versions 12.13.0 to 13.8.1Several metrics are available to be scraped but are not enabled by default. Set the following configuration in dragent.yaml to enable them. To apply configurations, see Configure the Agent.\nPod MetricsTo enable metrics such as kube_pod_status_ready_time and kube_pod_start_time metrics, add the following configuration:\nk8s_send_pod_times: true To collect the poddisruptionbudgets metric family, use the following configuration.\nk8s_extra_resources: include: - poddisruptionbudgets For example, use the following configuration to collect the default resources as well as poddisruptionbudgets metrics:\nk8s_extra_resources: include: - poddisruptionbudgets - services - resourcequotas - persistentvolumes - persistentvolumeclaims - storageclasses ConfigMap MetricsTo collect kube_configmap_info, use the following configuration:\nk8s_extra_resources: include: - configmaps Use sysdig-deploy chart v1.45.0 or above to collect thekube_configmap_info metrics.\nEnable Node AnnotationsBy default, Sysdig monitors Kubernetes nodes, so configuring k8s_extra_resources is unnecessary. However, to collect annotation metrics like kube_node_annotations, you must configure k8s_annotations_allowlist. Each annotation should be specified individually in the kubernetes.\u0026lt;resource-type\u0026gt;.annotation.\u0026lt;annotation-key\u0026gt; format.\nFor example, the following configuration collects the kubernetes.io/foo and kubernetes.io/bar annotations on nodes:\nk8s_annotations_allowlist: - \u0026#34;kubernetes.node.annotation.kubernetes.io/foo\u0026#34; - \u0026#34;kubernetes.node.annotation.kubernetes.io/bar\u0026#34; Example KSM Configurationk8s_extra_resources: include: - poddisruptionbudgets - services - resourcequotas - persistentvolumes - persistentvolumeclaims - storageclasses k8s_annotations_allowlist: - \u0026#34;kubernetes.node.annotation.kubernetes.io/foo\u0026#34; - \u0026#34;kubernetes.node.annotation.kubernetes.io/bar\u0026#34; Agent Versions 12.9.0 and AboveThe following metric families are available to be scraped by the Sysdig Agent but are not enabled by default.\ncertificatesigningrequests horizontalpodautoscalers ingresses To enable the agent to collect the above metric families, you must edit the agent configuration file, dragent.yaml, and include them along with the other resources you would like to collect. To apply configurations, see Configure the Agent.\nFor example, to collect all configurable resources including ingresses and certificatesigningrequests, add the following to dragent.yaml:\nk8s_extra_resources: include: - ingresses - certificatesigningrequests - services - resourcequotas - persistentvolumes - persistentvolumeclaims - storageclasses NOTE: When configuring k8s_extra_resources you must include all configurable Kube State Metrics families in order to collect metrics from those families. If you add ingresses but remove services, for example, the Sysdig agent will no longer collect services metrics. Adding only the ingresses or certificatesigningrequests configuration as follows will instruct the Sysdig agent to not collect the other configurable KSM services.\nk8s_extra_resources: include: - ingresses - certificatesigningrequests Therefore, ensure that you include the entire block of configuration corresponding to all the Kubernetes resources you wish to collect.\nAgent Versions 12.5.0 and Abovehorizontalpodautoscalers (HPA) kube state metrics are not collected by default. To enable the agent to collect HPA kube state metrics, you must edit the agent configuration file, dragent.yaml, and include it along with the other resources you would like to collect. To apply configurations, see Configure the Agent.\nFor example, to collect all supported resources including HPAs, add the following to dragent.yaml:\nk8s_extra_resources: include: - services - resourcequotas - persistentvolumes - persistentvolumeclaims - horizontalpodautoscalers NOTE: When configuring k8s_extra_resources you must include all configurable Kube State Metrics families in order to collect metrics from those families. If you add horizontalpodautoscalers but remove services, for example, the Sysdig agent will no longer collect services metrics. Adding only the horizontalpodautoscalers configuration as follows will instruct the Sysdig agent to not collect the other configurable KSM services.\nk8s_extra_resources: include: - horizontalpodautoscalers Therefore, ensure that you include the entire block of configuration corresponding to all the Kubernetes resources you wish to collect.\nAgent Versions 12.3.x and 12.4.xThe Sysdig agent collects HPA, PVS, PV, Resourcequota, and Services kube state metrics by default.\nTo disable some of them, you must edit the agent config file, dragent.yaml, as follows:\nk8s_extra_resources: include: - services - resourcequotas - persistentvolumes - persistentvolumeclaims - horizontalpodautoscalers The above list includes all the supported resources so you must remove the resources you are not interested in. For example, if you want to disable services, use the following:\nk8s_extra_resources: include: - resourcequotas - persistentvolumes - persistentvolumeclaims - horizontalpodautoscalers Learn More Time Series Billing. To collect Kubernetes events, see Process Kubernetes Events. ","url":"https://docs.sysdig.com/en/sysdig-monitor/enable-kube-state-metrics/"},{"id":210,"title":"Event Types","content":"Additionally, you can create Custom Events, as well as import events from LogDNA.\nAlert EventsAlert Events are triggered by user-configured alerts. Types of Alerts include Threshold Alerts, Prometheus Alerts, and Event Alerts. For more information on configuring alerts, see Alerts.\nSysdig EventsSysdig creates a Sysdig Event and publishes it in the Events feed whenever a notification channel fails. For more information, see Notification Failures.\nInfrastructure EventsEvents can be collected from supported services within the production environment. The Sysdig Agent automatically discovers these services and collects event data for a select group of events by default. Additional events can be added to the list by configuring the agent.\nFor more information, see Infrastructure Events\nCustom EventsAdditional events can be collected by the Sysdig agent and displayed in the Events module, but require more comprehensive configuration steps. These Custom Events can be integrated via:\nThe Sysdig Monitor Slackbot\nPython scripts (either pre-built by Sysdig or user-created)\nA CURL request\nFor brief sample scripts regarding configuring other custom events, see Custom Events. For more information, contact Sysdig Support.\nLogDNA EventsFor LogDNA users, Sysdig Monitor provides the ability to view LogDNA alerts as Sysdig events. These events will provide a link redirecting you to the LogDNA for further investigation.\nJust as with other types of Sysdig Events, you can create alerts based on the LogDNA events.\nThe log data provided by LogDNA carries additional details about system health. The ability to view relevant LogDNA events in Sysdig helps you debug and monitor the health of a system efficiently.\nFor example, if the number of logs generated during a deployment is higher than expected, you get notified with your Sysdig Events feed.\nThere is no configuration required on the Sysdig Monitor side. For information on configuring LogDNA to send alerts to Sysdig Monitor, see Sysdig Alert Integration.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/monitor-event-types/"},{"id":211,"title":"Filter Custom Metrics","content":" To exclude metrics, Sysdig recommends that you edit the prometheus.yaml file. If you use the metric_filter to exclude metrics, you must restart the agent before your changes take effect.\nTo filter custom metrics, you can:\nUse the configurable patterns.\nUse log and identify the custom metrics that are exceeding limits.\nAfter you identify the key custom metrics that must be received, use the new include and exclude filtering parameters to make sure you receive them before the metrics limit is hit.\nInclude and Exclude MetricsHere is an example configuration entry in the agent configuration file:\nmetrics_filter: - include: test.* - exclude: test.* - include: haproxy.backend.* - exclude: haproxy.* - exclude: redis.* - exclude: \u0026#39;*\u0026#39; For the above configuration entry, the action for these metrics is:\ntest.\\* : send\nhaproxy.backend.request: send\nhaproxy.frontend.bytes : drop\nredis.keys : drop\nIf no metric matches any of the above include filters, it will be dropped with the last - exclude: '*'\nWhen the agent reads the metrics, they are filtered according to the configured filters and the filtering rule order. The first rule that matches is applied. Therefore, in this example, the inclusion item for test.\\* will be applied, and the second exclude rule for the same exact metric entry will be ignored.\nThe combined limit for include and exclude filters is 100 entries.\nLog Accepted and Dropped MetricsLogging is disabled by default. To enable logging and see which metrics are accepted or dropped, add the following configuration entry into the dragent.yaml file:\nmetrics_excess_log: true Once enabled, logging occurs at INFO level every 30 seconds and lasts for 10 seconds. Logs are stored in /opt/draios/logs/draios.log and are formatted like this:\n+/-[type] [metric included/excluded]: metric.name (filter: +/-[metric.filter]) + indicates included and - indicates excluded.\nThe first + or -, followed by type provides an easy way to quickly scan the list of metrics and spot which are included or excluded .\nThe second entry specifies the metric type: statsd, app\\_check, service\\_check, or jmx.\nA third entry spells out whether included or excluded, followed by the metric name. Finally, the last entry, in parentheses, gives information about the filter applied and its effect.\nWith this example filter rule set:\nmetrics_filter: - include: mongo.statsd.net* - exclude: mongo.statsd.* You might see the following INFO level log entries (timestamps stripped):\n-[statsd] metric excluded: mongo.statsd.vsize (filter: -[mongo.statsd.*]) +[statsd] metric included: mongo.statsd.netIn (filter: +[mongo.statsd.net*]) Reduce Metrics ConsumptionThe Sysdig Agent collects metrics in your cloud environments and processes time series. Ingesting a large number of time series can exceed your Time Series Billing. This section explains how you can exclude and limit time series ingestion.\nExcluding Default Metrics and Prometheus Remote Write Metrics - LimitationsAfter it is installed, the Sysdig Agent collects thousands of metrics, such as sysdig_container_cpu_used_percent at no additional cost. These are known as default metrics and their collection cannot be disabled. Metrics that are not collected by default are called custom metrics. The collection of custom metrics counts towards your Time Series Billing while default metrics do not.\nTo stop custom metrics from being forwarded to Sysdig via Prometheus Remote Write, configuration changes must be made directly in the prometheus.yaml file. You cannot drop a metric once it has already been ingested.\nExcluding metrics from collection only applies to custom metrics that are collected by the Sysdig Agent.\nExclude Clusters from CollectionAdmins can exclude specific Kubernetes clusters from metrics collection for all supported monitoring integrations, except for the Prometheus Default Job (k8s-pods). To disable a cluster integration:\nLog in to Sysdig Monitor as an Admin, and navigate to Integrations \u0026gt; Monitoring Integrations from the left navigation bar.\nOn the Monitoring Integrations page, select an integration that is Reporting Metrics.\nClick Manage this Integration.\nUnder Exceptions, select the clusters you wish to exclude.\nClick Confirm, then Close the window.\nThis excludes all metrics associated with this integration for the specified cluster from being collected by the agent. The change may require a few minutes to take effect.\nExclude Workloads from CollectionThe Sysdig agent collects metrics from any workload labelled with the prometheus.io/scrape='true' annotation. To prevent these metrics from being collected, either remove the annotation prometheus.io/scrape='true' or apply the following annotation:\nspec: template: metadata: annotations: promcat.sysdig.com/omit: \u0026#39;true\u0026#39; You can apply this annotation across an entire namespace with the following kubectl command:\nkubectl get pods -n \u0026lt;namespace\u0026gt; -o name | xargs -I {} kubectl annotate {} promcat.sysdig.com/omit=\u0026#39;true\u0026#39; Exclude Metrics Collection Jobs with the Sysdig APIYou can use the Sysdig API to exclude specific metrics without turning off the integration or omitting all metrics at the workload level. This is useful for the Prometheus Default Job, where disabling the entire k8s-pods job may have unintended consequences for workloads that rely on the collection of metrics via kubernetes annotation.\nDisable Collection of a Single Metric for a Specified Prometheus JobSome metrics with high cardinality may not offer substantial value. Disable the collection of such metrics to reduce time series consumption.\nIn the following example, http_roundtrip_duration_seconds_bucket is a metric that is collected by the Prometheus Default k8s-pods job. To exclude the http_roundtrip_duration_seconds_bucket metric from being collected, use the following bash command:\ncurl --location --request POST \u0026#39;https://\u0026lt;regional-endpoint\u0026gt;/monitor/prometheus-jobs/v1/disabled-metrics\u0026#39; \\ --header \u0026#39;Authorization: Bearer \u0026lt;token\u0026gt;\u0026#39; \\ --header \u0026#39;content-type: application/json\u0026#39; \\ --header \u0026#39;X-sysdig-public-notation: true\u0026#39; \\ --data-raw \u0026#39;{ \u0026#34;data\u0026#34;: [ { \u0026#34;jobName\u0026#34;: \u0026#34;k8s-pods\u0026#34;, \u0026#34;metrics\u0026#34;: [ { \u0026#34;metricName\u0026#34;: \u0026#34;http_roundtrip_duration_seconds_bucket\u0026#34;, \u0026#34;isDisabled\u0026#34;: true } ] } ] }\u0026#39; Re-enable Metrics Collection for a Specified Prometheus JobTo re-enable a metric whose collection was previously disabled, you can use the same endpoint:\ncurl --location --request POST \u0026#39;https://\u0026lt;regional-endpoint\u0026gt;/monitor/prometheus-jobs/v1/disabled-metrics\u0026#39; \\ --header \u0026#39;Authorization: Bearer \u0026lt;token\u0026gt;\u0026#39; \\ --header \u0026#39;content-type: application/json\u0026#39; \\ --header \u0026#39;X-sysdig-public-notation: true\u0026#39; \\ --data-raw \u0026#39;{ \u0026#34;data\u0026#34;: [ { \u0026#34;jobName\u0026#34;: \u0026#34;k8s-pods\u0026#34;, \u0026#34;metrics\u0026#34;: [ { \u0026#34;metricName\u0026#34;: \u0026#34;http_roundtrip_duration_seconds_bucket\u0026#34;, \u0026#34;isDisabled\u0026#34;: false } ] } ] }\u0026#39; List All Disabled Metrics for a Specific Prometheus JobTo list all disabled metrics for a specific Prometheus job, use the following bash command:\ncurl --location --request GET \u0026#39;https://\u0026lt;regional-endpoint\u0026gt;/monitor/prometheus-jobs/v1/disabled-metrics\u0026#39; \\ --header \u0026#34;Authorization: Bearer \u0026lt;token\u0026gt;\u0026#34; For details regarding API usage, see Access Next Gen API docs.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/filter-custom-metrics/"},{"id":212,"title":"Vulnerability Findings","content":" Pipeline Registry Runtime Understand Image ScanningImage scanning enables you to examine container images for vulnerabilities, misconfigurations, and license violations. You can integrate image scanning into your development build process to verify images added to your container registry, as well as scan images used by active containers in your infrastructure.\nImage scanning provides registry insights into where your images are stored, initiates scans, and allows you to review the scan results.\nBehind the scenes:\nSBOM is analyzed\nSBOM is compared against multiple vulnerability databases\nSBOM is then evaluated against default or user-defined policies.\nResults are reported, both in Sysdig Secure and (if applicable) in a developer\u0026rsquo;s external CI tool.\nPlatform-Based ScanningSysdig Vulnerability Management module offers platform-based scanning by default. The scanning tools analyze images and host filesystems to extract the Software Bill of Materials (SBOM) and send them to the Sysdig backend for vulnerability matching and policy evaluation. You can retrieve the scanning result by using an API or the Sysdig Secure UI.\nPrerequisites VM Tools installed\nThe following version of VM tools support SBOM scanning:\nHost Scanner v0.7.0 and above for non-Kubernetes containers\nHost scanner for host filesystem is not currently supported\nCluster Scanner v1.23 and above\nCLI Scanner v1.8.0 and above\nRegistry Scanner v1.1.26 and above\nAgentless scanning\nFor on-prem environment, use v6.8.0\nRetrieve SBOM ResultsYou can retrieve SBOM results from the scanning process in CycloneDX JSON format via either the API or the Sysdig Secure UI. Having a downloaded version of the SBOM provides you with a detailed list of software components, enabling you to conduct thorough audits, manage risks effectively, and meet compliance standards.\nRetrieve SBOM Using the APITo retrieve the SBOM of your asset, issue a curl GET request against the Sysdig Secure endpoint:\ncurl -X GET -H \u0026#39;Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;\u0026#39; \u0026#39;https://\u0026lt;HOSTNAME\u0026gt;/secure/vulnerability/v1beta1/sboms?assetId=\u0026lt;sha256:xxxxxx\u0026gt;\u0026amp;assetType=container-image\u0026#39; Query Parameters assetId: The ID of the asset for which you want to retrieve the SBOM. It\u0026rsquo;s the imageId for container-image and the hostId for hosts. For example, assetId=sha256:xxxxxx. You can provide bomIdentifier or both assetId and assetType assetType: The type of the asset for which you want to retrieve the SBOM. For example, container-image. Provide this with the assetId if you are not providing bomIdentifier. bomIdentifier: The ID of a single SBOM. Either you can provide bomIdentifier or both assetId and assetType to retrieve the SBOM result. For example, bomIdentifier=urn:uuid:45667rrrr-b8f2-42345-b996-dkffllflp. Download SBOM Using the UITo download the SBOM of your scan results in CycloneDX JSON format from the Sysdig Secure UI:\nBased on your scanning type, open the Findings page in the Vulnerabilities menu.\nFor example, Attack Surface \u0026gt; Vuln Runtime Findings.\nFrom the all findings page, select a scanning result.\nThe scanning results page appears.\nSelect the Details tab on the scan results page and click Download SBOM.\nInstant Scanning with Scan NowYou can skip deploying CLI-based scanning tools such as Registry Scanner and directly scanning the images in your running environment using the Scan Now button. This initiates platform-based scanning, making it easier to get started with Vulnerability Management. You can effortlessly scan and view image results without needing to deploy any extra components. For more information, see Manual Image Scanning.\nLayered AnalysisContainer images are optimized for distribution by layer composition. Each instruction or change made during the image build process creates a new layer. Any filesystem change—whether it\u0026rsquo;s adding, deleting, or modifying files—generates a new layer on top of the previous image.\nLayered Analysis helps detect and display vulnerabilities and packages associated with each image layer and identify different remediation actions and ownership depending on the layer that introduces them. For example, vulnerabilities in the base OS layer are remediated by updating the base image version, typically performed by the platform operation team. In contrast, the ones belonging to the application or non-os layers are remediated by bumping the versions of libraries and dependencies in the corresponding application or service owned by the development teams.\nAdditionally, layered analysis can detect sibling images that are built on top of the same base image and enables routing remediation actions to the right layer and the right owner.\nPrerequisites and Guidelines On-Prem version 6.13.0 or higher\nCLI Scanner v1.12.0 or higher\nUse the --separate-by-layer and --separate-by-image options to change the output of the CLI scanner to show image hierarchy or layer information. For more information, see Display Image Layers.\nCluster Shield\nPlatform scanning is enabled by default\nRegistry Scanner v1.1.26 or higher\nPlatform scanning is enabled by default\nLegacy runtime-scanner is not supported\nUse Scan Results API JSON to view the new fields for layer information\nCaveats The FROM shown in the Image Hierarchy should not be confused with the FROM in the Dockerfile, as they might differ.\nA base image can have multiple tags. When Sysdig identifies a base image in your application, it displays the tags that were used to scan the base image, which may differ from the tags specified in your application\u0026rsquo;s Dockerfile.\nFor example, if the following is your Dockerfile of your application:\nFROM alpine:3.18 WORKDIR /usr/app COPY myapp-binary . ENTRYPOINT [ \u0026#34;/usr/app/myapp-binary\u0026#34; ] You should scan the base image, alpine:3.18, using the exact image name. If you scan it using alpine:latest, though the tag latest is referring to the same alpine:3.18, the image will be known to Sysdig as alpine:latest, and shown in the Image Hierarchy as FROM alpine:latest instead of the FROM alpine:3.18 matching the Dockerfile.\nYou can see the base image on the Image hierarchy as follows:\nTo effectively identify base images within the image hierarchy, Sysdig need to know the SBOM of the base images in advance. For pipeline scans, prioritize scanning base images before scanning the child images. When handling images in registries and runtime workloads, ensure that the base images are also scanned. This enables Sysdig to detect and correlate the layers accurately.\nUnder the Image Hierarchy:\nAll layers shows the total number of vulnerabilities in the final image composition, including vulnerabilities from both the application layers and base image layers. Commonly the total number displayed will be the sum of the base images and the application layers, but this is not always the case. If a vulnerability is fixed by upgrading or removing a package or library in one of the intermediate layers, the count in the All layers won\u0026rsquo;t include that vulnerability.\nThe base images (prefixed with FROM) display the vulnerabilities present in that base image, including those inherited from parent images. However, the Application layers counter includes vulnerabilities introduced in the application layers only. It doesn\u0026rsquo;t include the ones from base images.\nView Image LayersSee the Recommendations tab associated with an image or pipeline scan to view list of CVEs, fixable packages, and the commands to fix the issues.\nThe Vulnerabilities tab provides you with the hierarchy of the image, all the layers of the image, and the total number of CVEs. Select a layer to view the CVEs associated with that particular layer.\nSee the Packages tab to view the list of layers associated with the selected image and packages associated with each layer.\nReport Scanning ResultsThe analysis generates a detailed report of the image contents, including:\nOfficial OS packages\nUnofficial OS packages\nGolang, Rust, PHP, and .Net packages\nConfiguration files\nCredentials files\nImage layers\nLocalization modules and software-specific installers:\nJavaScript with NPM\nPython PiP\nRuby with GEM\nJava/JVM with .jar archives\nImage metadata and configuration attributes\nFor a full list, see Non-OS-Based Sources and Supported Package Types.\nPlanned change for 22 June 2026. Sysdig is making improvements to Alpine and Ubuntu vulnerability feeds and adding Python PDM support. After this release, customers may see more Alpine findings and severity changes on Ubuntu CVEs. See the SaaS Sysdig Secure Release Notes for details.\nRemediate with JiraSysdig has an API-enabled remediation workflow with Jira. After you integrate Jira, you can create a Jira ticket from the Vulnerabilities module:\nLog in to Sysdig Secure.\nNavigate any results page in Vulnerabilities.\nClick on a vulnerability\nThe details panel will open on right.\nClick Create a Jira ticket.\nFill in the details, such as Project, Ticket type, assignee, and customer labels.\nSubmit the ticket.\nOnce submitted, the CVE drawer will note a Jira ticket exists for that vulnerability.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/findings/"},{"id":213,"title":"Forwarding to Google SecOps (Formerly Google Chronicle)","content":"Event Forwarding to Google SecOps is authenticated with a Service Account. The legacy authentication method, involving an API Key, continues to be supported. However, we recommend that you use Service Accounts for authentication. See Service Accounts.\nPrerequisitesEvent forwards originate from region-specific IPs. For the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle event forwarding.\nConfigure Event ForwardingTo set up Event Forwarding to Google SecOps with a Service Account:\nLog in to Sysdig Secure as Admin.\nNavigate to Integrations \u0026gt; Add Integrations.\nSearch and choose Google SecOps.\nSpecify the following:\nIntegration Name: A unique name to help you identify the SecOps integration.\nCustomer ID: The Google Customer ID associated with your GCP account. In the Google SecOps UI, find this in Settings \u0026gt; Profile \u0026gt; IDP USER ID.\nNamespace: User-configured environment namespace to identify the data domain the logs originated from. Use namespace as a tag to identify the appropriate data domain for indexing and enrichment functionality.\nJSON Credentials: Upload your Google Chronicle JSON credentials. See Getting API Authentication Credentials.\nRegion: Select your region, such as US, Europe, or Asia.\nData to Send: From the drop-down, select which data to forward, such as activity audit, Sysdig platform audit, and runtime policy events. The available list depends on the Sysdig features and products you have enabled.\nTest the integration, then toggle Enabled to activate it.\nClick Save to finish.\nConfigure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description CHRONICLE credentialsOAuth2 yes string The Google Chronicle JSON credentials CHRONICLE region no string us, europe, asia-southeast1 us The target region CHRONICLE chronicleCustomerId yes string The Google Chronicle Customer ID CHRONICLE namespace yes string The namespace to identify the data domain ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forward-to-google-secops/"},{"id":214,"title":"Frequently Used Installer Configurations","content":"SMTP Configurations for Email NotificationsTo set up Email Notifications for On-Prem, you may need to configure your Single Mail Transfer Protocol (SMTP) parameters in your installation configmap:\nFind the parameters and appropriate values for SMTP in Configuration Parameters.\nEach field includes smtp in its name. For example:\nsysdig: ... smtpServer: smtp.sendgrid.net smtpServerPort: 587 #User,Password can be empty if the server does not require authentication smtpUser: apikey smtpPassword: XY.abcdefghijk... smtpProtocolTLS: true smtpProtocolSSL: false #Optional Email Header smtpFromAddress: sysdig@mycompany.com Starting from on-premise version 7.4.0 the values.yaml schema has changed. See the release notes for more details.\nUpdated Configuration (version 7.4.0 and later)global: smtpServer: smtp.sendgrid.net smtpServerPort: 587 #User,Password can be empty if the server does not require authentication smtpUser: apikey smtpPassword: XY.abcdefghijk... smtpProtocolTLS: true smtpProtocolSSL: false #Optional Email Header smtpFromAddress: sysdig@mycompany.com smtpFromName: \u0026#34;\u0026#34; Copy the parameters and appropriate values into your values.yaml. See Quickstart Installation. Configure AWS Credentials Using the InstallerThe available fields for AWS credentials are found in Configuration Parameters. They are:\nsysdig: accessKey: my_awesome_aws_access_key secretKey: my_super_secret_secret_key Starting from on-premise version 7.4.0 the values.yaml schema has changed. See the release notes for more details.\nUpdated Configuration (version 7.4.0 and later)global: accessKey: my_awesome_aws_access_key secretKey: my_super_secret_secret_key Use hostPath for Static Storage of Sysdig ComponentsThe Installer assumes the usage of a dynamic storage provider, such as Amazon Web Services (AWS) or Google Kubernetes Engine (GKE). If these are not used in your environment, add the entries below to values.yaml in order to configure static storage.\nBased on the size entered in the values.yaml file (small/medium/large), the Installer assumes a minimum number of replicas and nodes are provided.\nEnter the names of the nodes on which you will run the Cassandra, ElasticSearch, mySQL and PostgreSQL components of Sysdig in thevalues.yaml, as in the parameters and example below.\nParameters\nstorageClassProvisioner: hostPath.\nsysdig.cassandra.hostPathNodes: The number of nodes configured here needs to be at minimum 1 when configured size is small, 3 when configured size is medium, and 6 when configured size is large.\nelasticsearch.hostPathNodes: The number of nodes configured here needs to be at minimum 1 when configured size is small, 3 when configured size is medium, and 6 when configured size is large.\nsysdig.mysql.hostPathNodes: When sysdig.mysqlHA is configured to true, this must be at least 3 nodes. When sysdig.mysqlHA is not configured, it should be at least 1 node.\nsysdig.postgresql.hostPathNodes: This can be ignored if Sysdig Secure is not licensed or used in this environment. If Secure is used, then the parameter should be set to 1, regardless of the size setting. ExamplestorageClassProvisioner: hostPath elasticsearch: hostPathNodes: - my-cool-host1.com - my-cool-host2.com - my-cool-host3.com - my-cool-host4.com - my-cool-host5.com - my-cool-host6.com sysdig: cassandra: hostPathNodes: - my-cool-host1.com - my-cool-host2.com - my-cool-host3.com - my-cool-host4.com - my-cool-host5.com - my-cool-host6.com mysql: hostPathNodes: - my-cool-host1.com postgresql: hostPathNodes: - my-cool-host1.com Starting from on-premise version 7.4.0 the values.yaml schema has changed. See the release notes for more details.\nParameters (version 7.4.0 and later) .global.storageClassProvisioner: hostPath.\n.sysdigCommonConfig.hostPathConfigs.hostPathNodesMapping.cassandra.hostPathNodes: The minimum number of nodes required depends on the configured size:\nsmall: 1 node medium: 3 nodes large: 6 nodes .sysdigCommonConfig.hostPathConfigs.hostPathNodesMapping.elasticsearch.hostPathNodes: The minimum number of nodes required depends on the configured size:\nsmall: 1 node medium: 3 nodes large: 6 nodes Similar configuration applies to all other datastores.\nExample: hostPathNodes Configuration (version 7.4.0 and later)sysdigCommonConfig: hostPathConfigs: hostPathNodesMapping: elasticsearch: hostPathNodes: - my-cool-host1.com - my-cool-host2.com - my-cool-host3.com - my-cool-host4.com - my-cool-host5.com - my-cool-host6.com cassandra: hostPathNodes: - my-cool-host1.com - my-cool-host2.com - my-cool-host3.com - my-cool-host4.com - my-cool-host5.com - my-cool-host6.com ... Run Only Sysdig Pods on a Node Using Taints and TolerationsIf you have a large shared Kubernetes cluster and want to dedicate a few nodes for just the Sysdig backend component installation, you can use the Kubernetes concept of taints and tolerations.\nThe basic process is:\nAssign labels and taints to the relevant nodes.\nReview the sample node-labels-and-taints values.yaml in the Sysdig GitHub repository.\nCopy that section to your own values.yaml file and edit with labels and taints you assigned.\nExample from the sample file:\n# To make the \u0026#39;tolerations\u0026#39; code sample below functional, assign nodes the taint # dedicated=sysdig:NoSchedule. E.g: # kubectl taint my-awesome-node01 dedicated=sysdig:NoSchedule tolerations: - key: \u0026#34;dedicated\u0026#34; operator: \u0026#34;Equal\u0026#34; value: sysdig effect: \u0026#34;NoSchedule\u0026#34; # To make the Label code sample below functional, assign nodes the label # role=sysdig. # e.g: kubectl label nodes my-awesome-node01 role=sysdig nodeaffinityLabel: key: role value: sysdig Starting from on-premise version 7.4.0 the values.yaml schema has changed. See the release notes for more details.\n# To make the `tolerations` code sample below functional, assign nodes the taint # dedicated=sysdig:NoSchedule. E.g: # kubectl taint my-awesome-node01 dedicated=sysdig:NoSchedule global: tolerations: - key: \u0026#34;dedicated\u0026#34; operator: \u0026#34;Equal\u0026#34; value: sysdig effect: \u0026#34;NoSchedule\u0026#34; # To make the Label code sample below functional, assign nodes the label # role=sysdig. # e.g: kubectl label nodes my-awesome-node01 role=sysdig nodeaffinityLabel: key: role value: sysdig PatchingPatching can be used to customize or \u0026ldquo;tweak\u0026rdquo; the default behavior of the Installer to accommodate the unique requirements of a specific environment. Use patching to modify the parameters that are not exposed by thevalues.yaml. Refer to configuration_parameters.md for more detail about various parameters. The most common use case for patching is during upgrades. When generating the differences between an existing installation and the upgrade, you may see previously customized configurations that the upgrade would overwrite, but that you want to preserve.\nPatching ProcessIf you have run generate diff and found a configuration that you need to tweak (for example, the installer deletes something you want to keep, or you need to add something that isn\u0026rsquo;t there), then follow these general steps:\nCreate an overlays directory in the same location as the values.yaml. This directory, and the PATCH.yaml you create for it, must be kept. The installer will use it during future upgrades of Sysdig.\nCreate a .yaml file to be used for patching. You can name it whatever you want; we will call it PATCH.yaml for this example.\nPatch files must include, at a minimum:\napiVersion\nkind\nmetadata.name\nof the object to be patched.\nThen you add the specific configuration required for your needs. See one example below.\nYou will need this patch definition for every Kubernetes object you want to patch.\nRun generate diffagain and check the outcome satisfies your needs.\nWhen satisfied, complete the update by changing the scripts value to deploy and running the installer.\nTo add another patch, you can either add a separate .yamlfile or a new YAML document separated by ---.\nThe recommended practice is to use a single patch per Kubernetes object.\nExamplePresume you have the following generated configuration:\napiVersion: v1 kind: Service metadata: annotations: {} labels: app: sysdigcloud role: api name: sysdigcloud-api namespace: sysdigcloud spec: clusterIP: None ports: - name: api port: 8080 protocol: TCP targetPort: 8080 selector: app: sysdigcloud role: api sessionAffinity: None type: ClusterIP Add to the Generated ConfigurationSuppose you want to add an extra label my-awesome-label: my-awesome-value to the Service object. You would put the following in PATCH.yaml:\napiVersion: v1 kind: Service metadata: name: sysdigcloud-api labels: my-awesome-label: my-awesome-value Run the installer again, and the configuration would be as follows:\napiVersion: v1 kind: Service metadata: annotations: {} labels: app: sysdigcloud role: api my-awesome-label: my-awesome-value name: sysdigcloud-api namespace: sysdigcloud spec: clusterIP: None ports: - name: api port: 8080 protocol: TCP targetPort: 8080 selector: app: sysdigcloud role: api sessionAffinity: None type: ClusterIP Remove from the Generated ConfigurationSuppose you wanted to remove all the labels. You would put the following in PATCH.yaml:\napiVersion: v1 kind: Service metadata: name: sysdigcloud-api labels: Run the installer again, and the configuration would be as follows:\napiVersion: v1 kind: Service metadata: annotations: {} name: sysdigcloud-api namespace: sysdigcloud spec: clusterIP: None ports: - name: api port: 8080 protocol: TCP targetPort: 8080 selector: app: sysdigcloud role: api sessionAffinity: None type: ClusterIP ","url":"https://docs.sysdig.com/en/administration/onprem-installer-configuration/"},{"id":215,"title":"Configure Google Cloud Authentication for OIDC","content":"PrerequisitesReview OpenID Connect (SaaS).\nConfigure Google Cloud Log in to your organisation\u0026rsquo;s Google Cloud as a user with necessary privileges to configure Credentials.\nFrom the Navigation menu, select API \u0026amp; Services \u0026gt; Credentials.\nFrom the Create Credentials menu, select OAuth client ID and continue with the on-screen instructions.\nWhen creating OAuth client ID, select Web application as the application type. Enter the name of the web client of your choice.\nIn Authorized Redirect URIs enter the correct Redirect URLs from OpenID Connect (SaaS)\nSelect Create to create the application.\nWhen the OAuth client is created, note the Client ID and Client secret, then click OK.\nConfigure Sysdig Settings From the user menu, open Settings \u0026gt; Authentication (SSO), then click the OpenID row under SSO Configuration.\nSet the Client ID and Client secret to the values obtained from Google Cloud.\nSet Issuer URL to https://accounts.google.com.\nToggle to enable Metadata Discovery.\nClick Save Settings.\n","url":"https://docs.sysdig.com/en/administration/saas-google-cloud-auth-openid/"},{"id":216,"title":"Google OAuth (SaaS)","content":"Enable Google OAuthGoogle OAuth is pre-configured by Sysdig, so you can simply select it as the preferred authentication option.\nLog in to Sysdig Monitor or Sysdig Secure as an administrator, and open the user menu.\nSelect Settings \u0026gt; Authentication (SSO).\nFrom the SSO Integrations list, find the row with Google OAuth.\nToggle the configuration as Enabled to save your choice.\nRepeat for Sysdig Monitor or Sysdig Secure, if you want to enable it on both the applications.\nUser ExperienceThis section provides insight into the login experience of an end user.\nPrerequisitesNote the following requirements for successful Google OAuth login:\nThe user must already have logged in successfully at least once to your environment, having used an email-based invitation and set an initial password.\nThe username used in the Sysdig platform must precisely match the Google email address of the user. That is, it cannot be a shortened or an altered Google email alias.\nUser LoginFor a valid user to log in to Sysdig using Google OAuth:\nOpen the Sysdig application in a browser. Select Login with Google . If the user\u0026rsquo;s browser has not been already authenticated via Google, and has multiple Google profiles known by their browser, the user will be presented a Google page to select a profile and enter a password (if necessary) before being redirected back to your Sysdig environment.\nLearn More User and Team Administration Enable Google OAuth in On-Prem Environments ","url":"https://docs.sysdig.com/en/administration/google-oauth-saas/"},{"id":217,"title":"Google OAuth (On-Prem)","content":" These instructions are specific to On-Premises Deployments of the Sysdig platform. If you are using the cloud-based (SaaS) Sysdig platform, refer to Google OAuth (SaaS) instead.\nPrerequisitesThe Sysdig platform on-premises installation must have a DNS name associated with it. Google does not support applications that do not have an associated DNS name.\nDNS NameKubernetesFor Kubernetes-based installations, ensure the api.url ConfigMap element contains your hostname (older installations), or use the sysdig.dnsname (newer Installer-based).\nIn the following examples, DNS_NAME refers to the hostname you configured in your platform settings.\nIn Google Console: Obtain OAuth Client Credentials Log in to the Google API Console.\nCreate your project.\nSelect Credentials from the left-hand navigation, and choose the OAuth consent screen from the navigation bar.\nWhen prompted, select Internal or External User Type and click Create.\nChoosing Internal will limit the users to those with accounts belonging to the same domain as the email used to create the project, for example, mycompany.com. Note that if some of your users have a different domain, such as mycompany.uk, choose the External user type.\nOn the subsequent OAuth Consent screen, enter the required Email address and Product name, as well as other additional optional information, then click Save.\nFrom the Credentials tab, click the Create Credentials drop-down and select OAuth client ID.\nWhen prompted for Application type, select Web application, then enter the following parameters:\nName: Use a meaningful name, such as \u0026ldquo;Sysdig\u0026rdquo;.\nAuthorized JavaScript Origins: Enter https://DNS_NAME:API_PORT\nAuthorized Redirect URLs: Enter one or more of the following values:\nIf configuring Sysdig Monitor, enter: https://DNS_NAME:API_PORT/api/oauth/google/auth\nIf configuring Sysdig Secure, enter: https://DNS_NAME:API_PORT/api/oauth/google/secureAuth\nClick Create.\nA success message with client ID and client secret will be displayed. Copy these to a safe place, as you will need them in the next step.\nConfigure Settings in Sysdig PlatformYou can choose one of the following options to configure OAuth settings on the Sysdig side: a UI page, scripts, or entries in your Replicated or Kubernetes orchestrator.\n1. UI-Based: Configure Google OAuth in SettingsTo enable baseline Google OAuth functionality:\nEnter Google OAuth Basic Settings Log in to Sysdig Monitor or Sysdig Secure as \u0026ldquo;super\u0026rdquo; Admin and select Settings.\nSelect Authentication.\nSelect the Google OAuth tab.\nEnter the relevant parameters and click Save.\nApplication ID: the Client ID you were sent\nApplication Secret: the Client Secret you were sent\nURL Redirect:\nIf configuring Sysdig Monitor, enter: https://DNS_NAME:API_PORT/api/oauth/google/auth\nIf configuring Sysdig Secure, enter: https://DNS_NAME:API_PORT/api/oauth/google/secureAuth Allowed Domains: Comma-separated list of domains permitted to log in. For example, mycompany.com, myxompanyalias.com.\nSelect Google OAuth for SSO Select Google OAuthfrom the Enabled Single Sign-On dropdown\nClick Save Authentication.\nRepeat for Sysdig Monitor or Sysdig Secure, if you want to enable on both applications.\n2. Script-Based: Configure OAuth Using ScriptsThe configuration of the Google OAuth feature can be viewed, updated, and deleted by the \u0026ldquo;super\u0026rdquo; Admin. A google_oauth_config.sh helper script is available in the SSO folder at sysdig-cloud-scripts repository to assist in completing this configuration. Invoking the script with no options will display help text.\n# ./google_oauth_config.sh -h Usage: ./google_oauth_config.sh [OPTIONS] Affect Google OAuth login settings for your Sysdig software platform installation To use the helper script, modify env.sh to set the required values for API_TOKEN of the \u0026ldquo;super\u0026rdquo; Admin user and the URL for accessing the Sysdig platform API (which will be the same URL that your users access for the Sysdig Monitor application).\nDepending if the API_TOKEN has been obtained from the Sysdig Monitor or Sysdig Secure application UI, the settings will be applied to the consequent product.\nInitially, no Google OAuth settings are set. A initial run of the script would confirm that:\n# ./google_oauth_config.sh No google-oauth settings are set Run for further info: ./google_oauth_config.sh -h Add the -s option to set the Google OAuth configuration for a particular Sysdig application. When setting the config, you\u0026rsquo;ll use additional options to provide the config details you saved in the earlier Google OAuth step.\nConfig Detail Option Client ID -i Client Secret -e Allowed Domains -a Redirect URL -r If the configuration is successfully posted to the Sysdig platform, the new configuration will be echoed back.\nDepending if the API_TOKEN has been obtained from the Sysdig Monitor or Sysdig Secure application UI, the settings will be applied to the relevant product.\n# ./google_oauth_config.sh -s -i \u0026#34;t2em0alq7l13n1hevua48ehieenkb06q.apps.googleusercontent.com\u0026#34; -e \u0026#34;ucP_WY908-k\u0026#34; -r \u0026#34;https://sysdigtest.com:443/api/oauth/google/auth\u0026#34; -a \u0026#34;[\\\u0026#34;sysdig.com\\\u0026#34;]\u0026#34; { \u0026#34;authenticationSettings\u0026#34;: { \u0026#34;id\u0026#34;: 1, \u0026#34;version\u0026#34;: 1, \u0026#34;createdOn\u0026#34;: 1547709552000, \u0026#34;type\u0026#34;: \u0026#34;google-oauth\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;SYSTEM\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;clientId\u0026#34;: \u0026#34;t2em0alq7l13n1hevua48ehieenkb06q.apps.googleusercontent.com\u0026#34;, \u0026#34;clientSecret\u0026#34;: \u0026#34;ucP_WY908-k\u0026#34;, \u0026#34;redirectUrl\u0026#34;: \u0026#34;https://sysdigtest.com:443/api/oauth/google/auth\u0026#34;, \u0026#34;allowedDomains\u0026#34;: [ \u0026#34;sysdig.com\u0026#34; ] } } } Once you\u0026rsquo;ve completed this configuration, clicking the Google Login button at the login screen of the appropriate Sysdig application(s) should redirect to Google OAuth login page.\nIf you wish to delete your Google OAuth configuration, invoke the -d option. If successful, the disabled configuration will be printed.\n# ./google_oauth_config.sh -d { \u0026#34;authenticationSettings\u0026#34;: { \u0026#34;id\u0026#34;: 1, \u0026#34;version\u0026#34;: 1, \u0026#34;createdOn\u0026#34;: 1547709552000, \u0026#34;type\u0026#34;: \u0026#34;google-oauth\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;SYSTEM\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;clientId\u0026#34;: \u0026#34;t2em0alq7l13n1hevua48ehieenkb06q.apps.googleusercontent.com\u0026#34;, \u0026#34;clientSecret\u0026#34;: \u0026#34;ucP_WY908-k\u0026#34;, \u0026#34;redirectUrl\u0026#34;: \u0026#34;https://sysdigtest.com:443/api/oauth/google/auth\u0026#34;, \u0026#34;allowedDomains\u0026#34;: [ \u0026#34;sysdig.com\u0026#34; ] } } } 3. Orchestrator-Based: Enter Settings Using OrchestratorKubernetesEnter the OAuth allowed domains, Client ID, and Client Secret into the appropriate elements of the Kubernetes ConfigMap. Use appropriate Kubernetes methods to push the updated settings and restart the backend containers to apply the changes.\n# Optional: OAuth allowed domains (comma separated list of domains) sysdigcloud.oauth.allowed.domains.list: \u0026quot;\u0026quot; # Optional: Sysdig Cloud Google OAuth Client ID sysdigcloud.google.oauth.client.id: \u0026quot;\u0026quot; # Optional: Sysdig Cloud Google OAuth Client Secret sysdigcloud.google.oauth.client.secret: \u0026quot;\u0026quot; User ExperienceThe following are required for successful Google OAuth login:\nYou must have already logged in successfully at least once to your environment (such as via email-based Invitation and set an initial password).\nYour login username in the Sysdig platform must precisely match your Google email address (it cannot be a shortened/altered Google email alias).\nIf your setup meets the requirements, you can log in via Google OAuth by clicking the Log in with Google button.\nIf your browser has not already successfully authenticated via Google and/or has multiple Google profiles known by their browser, you will be presented a Google page to select a profile and enter a password (if necessary) before being redirected back to your Sysdig environment.\nSee also User and Team Administration for information on creating users.\n","url":"https://docs.sysdig.com/en/administration/onprem-google-oauth/"},{"id":218,"title":"Headless Cloud Security Release Notes","content":" Headless Cloud Security is available in Public Beta. Contact your Sysdig representative for more information.\n0.1.0 May 06, 2026Sysdig Headless Cloud Security (Public Beta)Sysdig Headless Cloud Security packages Sysdig cloud security workflows as reusable agent skills that run inside AI coding agents such as Claude Code. The integration enables users to onboard environments, investigate vulnerabilities and runtime threats, remediate risks, and manage posture workflows without leaving their AI environment.\nInstall in Claude Code /plugin marketplace add sysdig/skills /plugin install headless-cloud-security@sysdig-skills New Skillssysdig-onboardingAdded the sysdig-onboarding skill for onboarding cloud accounts and Kubernetes clusters into Sysdig Secure.\nThe skill can:\nGuide you through onboarding interactively or through an autonomous workflow Generate Terraform configurations for cloud account onboarding Generate Helm values for Kubernetes onboarding Validate prerequisites Deploy onboarding configurations Verify connectivity after deployment sysdig-investigateAdded the sysdig-investigate skill for identifying and prioritizing vulnerable container images in Sysdig-monitored environments.\nThe skill can:\nRank vulnerable images using configurable risk metrics Generate remediation plans Create tracking tickets in Jira, Linear, or GitHub Projects Recommend assignees using Sysdig risk and exposure signals Hand off remediation workflows to sysdig-remediate sysdig-remediateAdded the sysdig-remediate skill for remediating vulnerable container images.\nThe skill can:\nRetrieve Critical and High CVEs from Sysdig Identify safe fix versions through dependency chain analysis Generate minimal remediation patches Open pull requests or merge requests in GitHub or GitLab Generate .patch files for local repositories Persist image-to-repository mappings and reviewer history across sessions sysdig-postureAdded the sysdig-posture skill for authoring Sysdig Secure Posture custom controls and policies.\nThe skill supports:\nRego-based custom control authoring Custom policy creation Terraform generation using the Sysdig Terraform provider Rego validation Policy and control discovery workflows API access is read-only. All configuration changes are managed through Terraform.\nsysdig-runtime-investigateAdded the sysdig-runtime-investigate skill for investigating runtime threats detected by Sysdig.\nThe skill can:\nIdentify the highest-priority runtime threat Enumerate affected container images Correlate runtime activity with vulnerabilities Analyze network blast radius Perform VirusTotal lookups for suspicious binaries Escalate investigations to Jira or PagerDuty workflows Known Issues The sysdig-onboarding skill is currently optimized for AWS environments. Expanded Azure and GCP support is planned for upcoming releases. Claude Code is the primary supported AI coding agent, and the skills are optimized for its capabilities. Other MCP-compatible agents, including Cursor, OpenAI Codex, and OpenCode, can use the skills through the npx skills CLI command, but are not officially supported at this time. ","url":"https://docs.sysdig.com/en/release-notes/headless-cloud-security-release-notes/"},{"id":219,"title":"Host Shield for Linux Release Notes","content":" Deprecation Notice Support Ending\nStarting with version 14.3.0, Legacy eBPF is deprecated and it will be unsupported after December 4, 2026. Future releases will no longer introduce new features for Legacy eBPF. To ensure continued feature support and compatibility, we strongly recommend migrating to: Universal eBPF, or Kernel Module on environments running kernels older than version 5.8 For more information, see the full Drivers documentation. Secure Mode is now deprecated and will be permanently retired on December 4, 2026. To ensure continued support and benefit from improved performance, migrate to Secure_Light mode. This mode offers enhanced efficiency and is the long-term supported option moving forward. See the deprecation policy for more details. 14.6.0 May 19, 2026 Supported shield chart version: 1.38.0 Supported sysdig-deploy version: 1.111.0 Supported Falco Engine version: 1000.55.0 EnhancementsEnhanced Container Support Performance on Hosts with High Process Counts Improved performance of container support, especially on machines with large numbers of running processes. Expanded Rootless Podman Container Detection Extended container detection capabilities to dynamically surface rootless Podman containers. New Read only Filesystem Metrics Introduced the sysdig_host_filesystem_readonly metric to indicate whether the host filesystem is mounted as read-only Improved Agent Performance During Posture Scanning Reduced agent overhead by filtering syscall events from supervised subprocesses during posture scans and other intensive operations, resulting in lower CPU and memory usage. Added Kubernetes API request timeout configuration Introduced k8s_api_request.socket_timeout_sec setting to allow control over socket timeout behavior for Kubernetes API requests. Least Privileged Mode Support for Host Shield Added support for running Host Shield in unprivileged mode by setting host.privileged: false in the Helm chart, bringing parity with the Least Privileged Agent. For more information, see Manage Host Shield Privileges. Defect Fixes Fixed missing fields and incorrect behavior on DNS events: resolved two bugs in DNS detection that could cause DNS events to be silently dropped or have fields missing, leading to policy rules not firing as expected and incomplete data in DNS-related alerts. Customers relying on DNS-based detection rules should see more consistent and complete DNS event data after this fix.\nFixed a bug which could cause host-scanner to hang indefinitely at startup when attempting to ping the Docker daemon, if Non-Kubernetes Containers scanning is enabled.\nFixed a bug causing containers to report memory usage exceeding their configured limits.\nAddressed an issue where erroneous socket events could cause file descriptor tables to grow indefinitely, leading to potential unbounded memory consumption.\nFixed probe build failures on Fedora 42 and 43 distributions.\nResolved an occasional crash occurring when the system was running with observations enabled.\nVulnerability FixesAddressed the following vulnerabilities:\nCVE-2026-41676 CVE-2026-41677 CVE-2026-41678 CVE-2026-41681 CVE-2026-41898 CVE-2026-22016 CVE-2026-29181 CVE-2026-33811 CVE-2026-33814 CVE-2026-39820 CVE-2026-39836 CVE-2026-39979 CVE-2026-40164 CVE-2026-42151 CVE-2026-42154 CVE-2026-4424 CVE-2026-4878 CVE-2025-14087 CVE-2025-14512 CVE-2026-22013 CVE-2026-22021 CVE-2026-23865 CVE-2026-29111 CVE-2026-39823 CVE-2026-39825 CVE-2026-39826 CVE-2026-39882 CVE-2026-40179 CVE-2026-42499 CVE-2026-5121 CVE-2026-22007 CVE-2026-22018 CVE-2026-34268 14.5.2 April 22, 2026 Supported shield chart version: 1.34.6 Supported sysdig-deploy version: 1.109.7 Supported Falco Engine version: 1000.55.0 Defect Fixes Fixed a performance issue in container support on machines with large numbers of running processes. Fixed a bug that caused a container to report more memory than its configured limit. Vulnerability FixesAddressed the following vulnerabilities:\nCVE-2026-39892 CVE-2026-27135 CVE-2026-34982 CVE-2026-34986 CVE-2026-39883 CVE-2025-29768 CVE-2025-71176 CVE-2026-28418 CVE-2026-28419 CVE-2026-28420 CVE-2026-35177 CVE-2026-39881 CVE-2021-3927 CVE-2021-3928 CVE-2021-3968 CVE-2021-3973 CVE-2021-3974 CVE-2021-4136 CVE-2021-4166 CVE-2021-4173 CVE-2021-4187 CVE-2022-0213 CVE-2022-0351 CVE-2022-1616 CVE-2022-1619 CVE-2022-1620 CVE-2022-1674 CVE-2022-1720 CVE-2022-1725 CVE-2022-2042 CVE-2022-2124 CVE-2022-2125 CVE-2022-2126 CVE-2022-2129 CVE-2022-2175 CVE-2022-2182 CVE-2022-2183 CVE-2022-2206 CVE-2022-2207 CVE-2022-2208 CVE-2022-2210 CVE-2022-2257 CVE-2022-2284 CVE-2022-2285 CVE-2022-2286 CVE-2022-2287 CVE-2022-2304 CVE-2022-2343 CVE-2022-2344 CVE-2022-2345 CVE-2022-2522 CVE-2022-2817 CVE-2022-2819 CVE-2022-2845 CVE-2022-2849 CVE-2022-2862 CVE-2022-2874 CVE-2022-2889 CVE-2022-2923 CVE-2022-2946 CVE-2022-2980 CVE-2022-2982 CVE-2022-3016 CVE-2022-3037 CVE-2022-3099 CVE-2022-3134 CVE-2022-3153 CVE-2022-3234 CVE-2022-3235 CVE-2022-3256 CVE-2022-3278 CVE-2022-3296 CVE-2022-3297 CVE-2022-3324 CVE-2022-3352 CVE-2022-3705 CVE-2022-4141 CVE-2022-4292 CVE-2022-4293 CVE-2023-0049 CVE-2023-0051 CVE-2023-0054 CVE-2023-0288 CVE-2023-0433 CVE-2023-0512 CVE-2023-1127 CVE-2023-1170 CVE-2023-1175 CVE-2023-1264 CVE-2023-2609 CVE-2023-2610 CVE-2023-46246 CVE-2023-4734 CVE-2023-4735 CVE-2023-4738 CVE-2023-4751 CVE-2023-4781 CVE-2023-48231 CVE-2023-48232 CVE-2023-48233 CVE-2023-48234 CVE-2023-48235 CVE-2023-48236 CVE-2023-48237 CVE-2023-48706 CVE-2023-5344 CVE-2023-5441 CVE-2023-5535 CVE-2024-22667 CVE-2024-41957 CVE-2024-41965 CVE-2024-43374 CVE-2024-43802 CVE-2024-45306 CVE-2024-47814 CVE-2025-1215 CVE-2025-22134 CVE-2025-24014 CVE-2025-26603 CVE-2026-26269 CVE-2026-28422 14.5.1 April 15, 2026 Supported shield chart version: 2.7.2 Supported sysdig-deploy version: 1.109.6 Supported Falco Engine version: 1000.55.0 EnhancementsReduced File Descriptor Path Logging Verbosity Reduced log verbosity when resolving file descriptor paths. Defect Fixes Erroneous socket events caused file descriptor tables to grow, potentially leading to unbounded memory usage. Fixed an issue in Host Posture in which Linux host benchmark checks produced duplicate sysctl values, causing incorrect false-positive posture results. Fixed an issue in which Host Posture sent requests incompatible with on-premises installations earlier than version 7.7.0, preventing scans from being scheduled. Fixed an issue in which Host Posture sent duplicated results for the same host, preventing host posture evaluation from completing. Fixed an issue causing the agent to stop unexpectedly when running with observations enabled. Fixed an issue where the legacy_ebpf driver would not load on Oracle Linux version 8. Vulnerability Fixes CVE-2026-30922 CVE-2026-32280 CVE-2026-32283 CVE-2026-32288 CVE-2026-4519 CVE-2025-11468 CVE-2025-12781 CVE-2025-13837 CVE-2025-15282 CVE-2025-4516 CVE-2025-6069 CVE-2026-0672 CVE-2026-0865 CVE-2026-25645 CVE-2026-32282 CVE-2026-32289 CVE-2026-34073 CVE-2026-3644 CVE-2026-4224 CVE-2025-6075 CVE-2026-2297 CVE-2026-32281 CVE-2026-33810 CVE-2026-3479 14.5.0 March 31, 2026 Supported shield chart version: 1.33.0 Supported sysdig-deploy version: 1.108.0 Supported Falco Engine version: 1000.55.0 EnhancementsLocal Scanning for Kubernetes Container Workloads Sysdig now supports local scanning of vulnerabilities for Kubernetes container workloads by using Host Shield image scanning on each node. This improves coverage for more complex environments, without relying solely on registry or agentless scanning paths. For more information, see Local Scanning. Reduced Agent Log Noise Downgraded a recurring warning message in agent logs to Debug level. The message had no impact on functionality and required no action. Reduced Log Noise for Unresolvable Thread Entries Reduced the severity of a log message that could appear frequently in agent logs and cause unnecessary concern and log rotation. The message, which indicated a thread without a resolvable main process, required no action and has been moved to Debug level to avoid surfacing as a warning during normal operations. Improved Handling of Delayed Container Events Improved processing of delayed container events to ensure they are handled correctly when they arrive after their expected time. Defect Fixes Fixed Prometheus exporter logging to prevent INFO-level messages from being reported as errors. Fixed a bug where the baseliner does not respect the pause time after being stopped. Resolved an issue where the kmod driver could exit unexpectedly under high load on large machines (48+ cores). Fixed a pipe descriptor leak on shield restart when you enable Host Scanner or Rapid Response. Fixed a segmentation fault and subsequent agent restart that was triggered when initiating a capture with a filter containing a plugin field. Updated tests to include an additional subprocess required by the shield. Fixed a race condition during Secure Policies reload that could cause the Host Shield to stop unexpectedly. Resolved a bug causing backend exceptions and agent disconnections due to invalid protobuf payloads. Fixed an issue where the container_image_tag metric label displayed an incorrect value when the container image reference included a registry port. Fixed an issue where installing Host Shield using system packages failed on SUSE Linux Enterprise Server (SLES) 16 and Red Hat Enterprise Linux (RHEL) 10. Vulnerability FixesAddressed the following vulnerabilities:\nCVE-2026-27459 CVE-2026-33186 CVE-2026-4111 CVE-2025-14831 CVE-2025-15366 CVE-2025-15367 CVE-2026-1299 CVE-2026-25727 CVE-2026-26007 CVE-2026-27448 CVE-2025-9820 14.4.1 March 12, 2026 Supported sysdig-deploy version: 1.106.1 Supported Falco Engine version: 1000.52 Supported shield chart version: 1.30.2 EnhancementsImproved Handling of Delayed Container EventsImproved processing of delayed container events to ensure they are handled correctly when they arrive after their expected time.\nDefect Fixes Fixed an issue in Host Scanner Vulnerability Management where packages could fail to be detected on: Amazon Linux, EulerOS, Talos, and minimal or hardened Alpine variants. Vulnerability FixesAddressed the following vulnerabilities:\nCVE-2026-24051 CVE-2026-0915 CVE-2026-24137 CVE-2026-25679 CVE-2026-27142 CVE-2025-15281 CVE-2026-0861 14.4.0 February 17, 2026 Supported sysdig-deploy version: 1.103.0 Supported Falco Engine version: 1000.52 Supported shield chart version: 1.28.0 EnhancementsSysdig Host Shield Key Stored in Memory Host Shield can now load the access key from the SYSDIG_HOST_SHIELD_SYSDIG_ENDPOINT__ACCESS_KEY operating system environment variable. The access key will be stored in memory only and will not be written to disk. Reduced Collector Connection Log Verbosity Reduced error log verbosity when retrying connections to the Sysdig collector. Improved Docker Audits with Mirantis Container Runtime (MCR) Enhanced Docker audits to skip evaluation when Mirantis Container Runtime (MCR) is detected. Amazon Kinesis in Agent Local ForwardingStarting from this release, Amazon Kinesis is available as target integration in Agent Local Forwarding, supporting both Amazon Kinesis Firehose and Amazon Kinesis Data Streams as configurable targets. For more information, see:\nAmazon Kinesis Firehose Amazon Kinesis Data Streams Defect Fixes Fixed an issue where a malformed message shared may lead to backend disconnections. Fixed metadata retrieval for IBM standalone virtual server instances. Fixed an issue affecting the detection of incorrect container memory limits. Fixed a minor memory usage issue in StatsD connection handling. Fixed exceptions that occurred when the set of block devices present during aggregation changed. Added support for Kubernetes version 1.29 to 1.32, including updated compliance audit coverage. Fixed an issue that could cause Host Shield to run unnecessary Vulnerability Management scans after restarts. Fixed a pipe descriptor leak on Shield restart when Host Scanner or Rapid Response is enabled. Fixed the skip_events_by_process configuration to skip child processes spawned both before and after the Shield starts. This affects Host Shield version 14.3.x. Improved Shield support bundle generation. Support bundles are now created in the /tmp/ directory. Added a compression fallback chain (bzip2 → gzip → uncompressed tar) to ensure bundle collection succeeds when preferred compression tools are unavailable. Vulnerability FixesAddressed the following vulnerabilities:\nCVE-2025-68121 CVE-2025-15467 CVE-2025-61726 CVE-2025-64720 CVE-2025-65018 CVE-2026-21441 CVE-2026-21945 CVE-2025-11187 CVE-2025-12084 CVE-2025-13601 CVE-2025-13836 CVE-2025-14104 CVE-2025-61728 CVE-2025-69419 CVE-2025-9086 CVE-2026-21925 CVE-2026-21933 CVE-2026-22772 CVE-2025-15468 CVE-2025-15469 CVE-2025-61730 CVE-2025-66199 CVE-2025-68160 CVE-2025-69418 CVE-2025-69420 CVE-2025-69421 CVE-2026-22795 CVE-2026-22796 CVE-2025-66506 Known Issues FIM detection relies on BPF_LINK_CREATE, which is not available on kernel versions earlier than 5.7 or libbpf versions earlier than 0.0.8. When this capability is unavailable, FIM detection will fail to initialize. Sysdig plans to fix this in an upcoming release.\nWorkaroundUpgrade the host kernel to version 5.7 or later, upgrade libbpf to version 0.0.8 or later, or temporarily disable the FIM feature before upgrading Shield.\n14.3.2 January 15, 2026 Supported sysdig-deploy version: 1.99.7 Supported Falco Engine version: 1000.51 Supported shield chart version: 1.25.4 Defect Fixes Fixed metadata retrieval in IBM standalone virtual server instances. Fixed a bug that could cause the Shield to enter an infinite loop when handling the recvmsg and recvmmsg syscalls. Vulnerability FixesAddressed the following vulnerabilities:\nCVE-2025-66506 CVE-2025-11083 CVE-2025-45582 CVE-2025-8291 ","url":"https://docs.sysdig.com/en/release-notes/linux-host-shield-release-notes/"},{"id":220,"title":"Install Host Shield in On-Prem Deployments","content":"For more information, see the following:\nInstalling Shield for Sysdig Monitor : Sysdig Monitor provides monitoring and troubleshooting, cost-optimization, and alerting capabilities with process-level visibility into your dynamic, distributed production environments. Installing Shield for Sysdig Secure: Sysdig Secure provides runtime security, identity management, compliance, vulnerability management, and response. Runtime security includes workload and container drift monitoring, image profiling, activity auditing, and network security policy generation. Compliance enables you to check your workloads and cloud environments against compliance standards like CIS benchmarks. Vulnerability management includes runtime vulnerability scanning, build pipeline scanning, and registry scanning. Rapid Response allows designated advanced users to connect remotely to a host for forensic investigation. For on-prem installation of the backend components, use the On-Premises Deployments documentation with the assistance of your Sysdig representative.\nNext Steps Airgapped Agent installation ","url":"https://docs.sysdig.com/en/administration/onprem-agent-installation/"},{"id":221,"title":"IAM Policy Code to Use","content":"CloudWatch Metric StreamsSysdig requires additional permissions to collect metadata and display the correct status for the Amazon Web Service (AWS) CloudWatch Metric Stream integration. If you are setting up CloudWatch Metric Steams manually, and prefer to authenticate with the access keys, use the following policy:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Action\u0026#34;: [ \u0026#34;s3:ListBucket\u0026#34;, \u0026#34;s3:GetBucketTagging\u0026#34;, \u0026#34;s3:GetObject\u0026#34;, \u0026#34;s3:GetObjectAttributes\u0026#34;, \u0026#34;cloudwatch:GetMetricStream\u0026#34;, \u0026#34;cloudwatch:ListMetricStreams\u0026#34;, \u0026#34;cloudwatch:ListTagsForResource\u0026#34;, \u0026#34;firehose:DescribeDeliveryStream\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } ] } CloudWatch APICreating a Sysdig-specific IAM policy enables Sysdig to collect metadata and CloudWatch metrics from the following services, as applicable to your environment:\nDynamodb\nEC2 hosts\nECS\nElasticache\nRDS\nSQS\nIf you want to use your own AWS Simple Storage Service (S3) bucket to store Sysdig capture files, you can append those code snippets to this IAM Policy as well. See Storage: Configure AWS Capture File Storage (Optional) for details.\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Action\u0026#34;: [ \u0026#34;autoscaling:Describe*\u0026#34;, \u0026#34;cloudwatch:Describe*\u0026#34;, \u0026#34;cloudwatch:Get*\u0026#34;, \u0026#34;cloudwatch:List*\u0026#34;, \u0026#34;dynamodb:ListTables\u0026#34;, \u0026#34;dynamodb:Describe*\u0026#34;, \u0026#34;ec2:Describe*\u0026#34;, \u0026#34;ecs:Describe*\u0026#34;, \u0026#34;ecs:List*\u0026#34;, \u0026#34;elasticache:DescribeCacheClusters\u0026#34;, \u0026#34;elasticache:ListTagsForResource\u0026#34;, \u0026#34;elasticloadbalancing:Describe*\u0026#34;, \u0026#34;rds:Describe*\u0026#34;, \u0026#34;rds:ListTagsForResource\u0026#34;, \u0026#34;sqs:ListQueues\u0026#34;, \u0026#34;sqs:GetQueueAttributes\u0026#34;, \u0026#34;sqs:ReceiveMessage\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } ] } See Change the AWS Services that are Polled for more detail.\n","url":"https://docs.sysdig.com/en/administration/iam-policy-code-to-use/"},{"id":222,"title":"Identity Findings","content":" This documentation reflects the Identity Findings page as it appears with Advanced CIEM enabled. If you’re using Basic CIEM, columns that rely on observed entitlement usage will not be available.\nUnderstand Identity FindingsThe Attack Surface \u0026gt; Identity Findings page provides a detailed, table-based view of all identity-related issues detected across your cloud infrastructure. It is designed for security analysts and engineers to drill down into specific findings, understand their context, and take remediation actions.\nEach row in the table represents a unique identity finding. The columns displayed will vary depending on the selected grouping.\nFiltering FindingsUse the filters at the top of the page to narrow the results and focus on the most relevant issues. You can apply a range of identity-specific filters.\nDefault FiltersThese filters are available by default:\nSearch: Filter findings by resource name. Zone: Filter by one or more Zones, logical groupings such as accounts, clusters, or applications. Severity: Filter findings by severity: Critical, High, Medium, Low, or Informational. Observed \u0026gt; 90 Days: Focuses results on identities that have been observed for at least 90 days. This helps ensure that least privilege recommendations are based on a meaningful period of activity. Finding Name: Filter by specific checks, such as \u0026ldquo;Multiple Access Keys Active,\u0026rdquo; \u0026ldquo;Access Keys Not Rotated,\u0026rdquo; or \u0026ldquo;No MFA.\u0026rdquo; Additional FiltersClick + Add to apply more granular filters, or use filters automatically applied when drilling down from the Identity Overview dashboard:\nAccount: Cloud account, subscription, or project ID where the resource resides. Highest Access: Filter by the identity’s maximum level of access: Admin, Write, or Read. Platform: Filter by cloud provider (AWS, Azure, GCP). Resource Family: Filter by IAM resource type group: User, Group, Role, Access Policy, or Service Account. Resource Type: Further narrow by resource sub-type within the family. Unused Permission Criticality: Filter by the criticality of unused permissions (Critical, High, Medium, or Low). This is based on the most severe permission the identity is entitled to—even if unused. Grouping FindingsYou can group findings to change how data is presented:\nNone (Flat List): Displays individual findings line by line. Resource: Groups findings by affected resource or identity, aggregating all findings for that entity into a single row. Identity Check: Groups findings by the type of identity issue (for example, No MFA, Unused Permissions). This view is ideal for security teams prioritizing remediation for common issues across their environment. Findings Table ColumnsColumn definitions vary depending on how the data is grouped.\nWhen Grouping by \u0026ldquo;None\u0026rdquo; (Flat List) Column Description Finding Name Type of issue (for example, Multiple Access Keys Active, Access Keys Not Rotated, Inactive, Unused Permissions). Severity Severity of the finding. Resource Affected IAM entity (for example, sysdig-user-1 (User), DevTeam-Admins (Group)). Acct/Subs/Proj Cloud account, subscription, or project ID. Zones Relevant Sysdig Zones. Platform Cloud provider (AWS, Azure, GCP). Unused Permission Criticality Maximum impact of unused permissions associated with the identity. % Unused Permissions Percent of entitled permissions not observed in use. Highest Access The identity\u0026rsquo;s highest access level: Admin, Write, or Read. First Seen When the finding was first detected for the identity. When Grouping by \u0026ldquo;Resource\u0026rdquo; Column Description Resource Affected IAM entity. Platform Cloud provider (AWS, Azure, GCP). Zones Relevant Sysdig Zones. Acct/Subs/Proj Cloud account, subscription, or project ID. Findings Total number of findings affecting the identity. Days Inactive For inactive identities, the number of days since last observed activity. Unused Permission Criticality Highest unused permission criticality for this identity. % Unused Permissions Aggregate percentage of unused permissions. Highest Access Maximum access level assigned. Membership (Groups only) Number of members in the group. First Seen When the identity was first observed by Sysdig. When Grouping by \u0026ldquo;Identity Check\u0026rdquo; Column Description Finding Name The specific check (for example, No MFA, Unrotated Access Key(s), Inactive). Severity The defined severity for associated findings. Zones Relevant Sysdig Zones. Findings Total count of unique findings associated with this identity check. Reviewing Findings in DetailEach row is clickable and opens a contextual side panel, based on the current grouping:\nFlat List (No Grouping):\nOpens the Findings Detail panel, which includes:\nDetails about the affected identity. Finding specifics: description, severity, and impacted permissions. Remediation guidance. Grouped by Resource:\nOpens the Identity Resource panel, which includes:\nAll findings associated with the identity. Relationships (e.g., policies, groups, roles). Remediation options. Grouped by Identity Check: Opens the Identity Check panel, which provides:\nHighlights: Summary data, including total affected resources/identities and scope (accounts/zones impacted). Impacted Resources: A paginated table of all affected resources and their details. Remediate: General remediation guidance. For more detailed guidance, see the remediation provided with individual findings. These detailed views provide full context for prioritizing and resolving issues, supporting effective enforcement of least privilege across your cloud environment.\n","url":"https://docs.sysdig.com/en/sysdig-secure/identity/findings/"},{"id":223,"title":"Infrastructure Events","content":" Docker\nContainerD\nKubernetes\nEvents marked with * are enabled by default. To configure additional infrastructure events, see Collect Event Data and Understand the Agent Configuration.\nDocker EventsThe following Docker events are supported.\ndocker: container: - attach # Container Attached (information) - commit # Container Committed (information) - copy # Container Copied (information) - create # Container Created (information) - destroy # Container Destroyed (warning) - die # Container Died (warning) - exec_create # Container Exec Created (information) - exec_start # Container Exec Started (information) - export # Container Exported (information) - kill # Container Killed (warning) - oom # Container Out of Memory (warning) - pause # Container Paused (information) - rename # Container Renamed (information) - resize # Container Resized (information) - restart # Container Restarted (warning) - start # Container Started (information) - stop # Container Stopped (information) - top # Container Top (information) - unpause # Container Unpaused (information) - update # Container Updated (information) image: - delete # Image Deleted (information) - import # Image Imported (information) - pull # Image Pulled (information) - push # Image Pushed (information) - tag # Image Tagged (information) - untag # Image Untaged (information) volume: - create # Volume Created (information) - mount # Volume Mounted (information) - unmount # Volume Unmounted (information) - destroy # Volume Destroyed (information) network: - create # Network Created (information) - connect # Network Connected (information) - disconnect # Network Disconnected (information) - destroy # Network Destroyed (information) ContainerD EventsThe following ContainerD events are supported.\ncontainerd: container: - create # Container created (information) - exit # Container exited (information) - die # Container exited with an error (warning)* - oom # Container out of memory (warning)* image: - create # Image created (information) - update # Image updated (information) - delete # Image deleted (information) Kubernetes EventsThe following Kubernetes events are supported.\nkubernetes: node: - TerminatedAllPods # Terminated All Pods (information) - RegisteredNode # Node Registered (information)* - RemovingNode # Removing Node (information)* - DeletingNode # Deleting Node (information)* - DeletingAllPods # Deleting All Pods (information) - TerminatingEvictedPod # Terminating Evicted Pod (information)* - NodeReady # Node Ready (information)* - NodeNotReady # Node not Ready (information)* - NodeSchedulable # Node is Schedulable (information)* - NodeNotSchedulable # Node is not Schedulable (information)* - CIDRNotAvailable # CIDR not Available (information)* - CIDRAssignmentFailed # CIDR Assignment Failed (information)* - Starting # Starting Kubelet (information)* - KubeletSetupFailed # Kubelet Setup Failed (warning)* - FailedMount # Volume Mount Failed (warning)* - NodeSelectorMismatching # Node Selector Mismatch (warning)* - InsufficientFreeCPU # Insufficient Free CPU (warning)* - InsufficientFreeMemory # Insufficient Free Mem (warning)* - OutOfDisk # Out of Disk (information)* - HostNetworkNotSupported # Host Ntw not Supported (warning)* - NilShaper # Undefined Shaper (warning)* - Rebooted # Node Rebooted (warning)* - NodeHasSufficientDisk # Node Has Sufficient Disk (information)* - NodeOutOfDisk # Node Out of Disk Space (information)* - InvalidDiskCapacity # Invalid Disk Capacity (warning)* - FreeDiskSpaceFailed # Free Disk Space Failed (warning)* - Infra Connectivity # Connection Failure Between Agent and API Server (warning)* pod: - Pulling # Pulling Container Image (information) - Pulled # Ctr Img Pulled (information) - Failed # Ctr Img Pull/Create/Start Fail (warning)* - InspectFailed # Ctr Img Inspect Failed (warning)* - ErrImageNeverPull # Ctr Img NeverPull Policy Violate (warning)* - BackOff # Back Off Ctr Start, Image Pull (warning) - Created # Container Created (information) - Started # Container Started (information) - Killing # Killing Container (information)* - Unhealthy # Container Unhealthy (warning) - FailedSync # Pod Sync Failed (warning) - FailedValidation # Failed Pod Config Validation (warning) - FailedScheduling # FailedScheduling (warning)* - OutOfDisk # Out of Disk (information)* - HostPortConflict # Host/Port Conflict (warning)* replicationController: - SuccessfulCreate # Pod Created (information)* - FailedCreate # Pod Create Failed (warning)* - SuccessfulDelete # Pod Deleted (information)* - FailedDelete # Pod Delete Failed (warning)* replicaSet: - SuccessfulCreate # Pod Created (information)* - FailedCreate # Pod Create Failed (warning)* - SuccessfulDelete # Pod Deleted (information)* - FailedDelete # Pod Delete Failed (warning)* deployment: - SelectingAll # Selecting All Pods (warning)* - ScalingReplicaSet # Scaling Replica Set (information)* - DeploymentRollbackRevisionNotFound # No revision to roll back (warning)* - DeploymentRollbackTemplateUnchanged # Skipping Rollback (warning)* - DeploymentRollback # Rollback Done (information)* daemonSet: - SelectingAll # Selecting All Pods (warning)* statefulSet: - SuccessfulCreate # Pod Created (information)* - FailedCreate # Pod Create Failed (warning)* - SuccessfulDelete # Pod Deleted (information)* - FailedDelete # Pod Delete Failed (warning)* - RecreatingFailedPod # Recreate fail pod (warning)* service: - CreatingLoadBalancerFailed # Load Balancer Create Failed (warning)* - CleanupLoadBalancerFailed # Load Balancer Cleanup Failed (warning)* - DeletingLoadBalancer # Load Balancer Delete Start (information) - DeletingLoadBalancerFailed # Load Balancer Delete Failed (warning)* - DeletedLoadBalancer # Load Balancer Delete End (information) - UnAvailableLoadBalancer # Unavailable Load Balancer (warning)* - UpdatedLoadBalancer # Updated Load Balancer (information)* - UpdateLoadBalancerFailed # Load Balancer Update Failed (warning)* - SyncLoadBalancerFailed # Load Balancer Sync Failed (warning)* horizontalPodAutoscalar: - SelectorRequired # Selector Required (warning)* - InvalidSelector # Selector Not Valid (warning)* - FailedConvertHPA # Failed to Convert HPA (warning)* - FailedGetScale # Failed to get Scale (warning)* - FailedComputeMetricsReplicas # Failed to Compute Replicas (warning)* - FailedRescale # Failed to rescale (warning)* - FailedUpdateStatus # Failed to update status (warning)* ","url":"https://docs.sysdig.com/en/sysdig-monitor/infrastructure-events/"},{"id":224,"title":"Install Rapid Response","content":" Rapid Response team members have access to a full shell from within the Sysdig Secure UI. Responsibility for the security of this powerful feature rests with you, your enterprise, and your designated employees.\nSee also: Rapid Response.\nThe Rapid Response agent can be installed via Helm on Kubernetes.\nNote: You can also install Rapid Response on a host as a container.\nInstall Using Using HelmPrerequisites Installed Sysdig Components on Kubernetes using Helm Helm v3.8 or above Deployment Steps Recommended: Replace helm install with helm upgrade --install.\nTo enable the Rapid Response component in your existing Sysdig Secure Helm install command, add the following:\n--set rapidResponse.enabled=true \\ --set rapidResponse.rapidResponse.passphrase=YOUR_SECRET_PASSPHRASE \\ For passphrase, enter any phrase you want to use.\nRun the modified command to deploy Sysdig Secure with the Rapid Response component enabled. Designated Advanced Users will now be able to remote connect into a host directly from the Event stream in Sysdig Secure.\nConfigure Log StorageIn order to save session logs, Rapid Response requires custom storage to be configured.\nIf you are using the default storage for Capture files, you will need to configure an AWS or custom S3 bucket to store Rapid Response log files after a session. If you have already configured an S3 bucket for Captures, then Rapid Response logs will be routed there automatically, into their own folder.\nFor SaaS Users with Sysdig Secure Only\nContact Sysdig Support for assistance creating a custom S3 bucket for rapid response logs.\nPost-InstallationAfter Rapid Response is installed, team(s) must be configured to use it.\nTroubleshootingValidate the Rapid Response installation:\nEnsure the host component can reach the Sysdig collector. Its address and port are defined here for SaaS users or provided during the installation for on-prem users. Ensure there are no intermediate proxies that could enforce maximum time to live (since sessions could potentially have long durations) Ensure that the host component can reach the object storage (S3 bucket) when configured. ","url":"https://docs.sysdig.com/en/sysdig-secure/install-rapid-response-classic/"},{"id":225,"title":"Install Sysdig Agent","content":"Installation RequirementsBefore installing the Sysdig Agent:\nEnsure that your system meets the following requirements:\nA supported distribution or a container platform.\nPort 6443 is open for outbound traffic.\nThe Sysdig Agent requires egress permissions on port 6443 to reach the Sysdig Collector, which receives data from the agent. See IP ranges for more information.\nDetermine the Agent Mode.\nLinux Kernel 3.10 or later\nCollect the following:\nACCESS_KEY: The Sysdig agent access key.\nYou can retrieve the key from the Sysdig Monitor UI using one of the following:\nSettings \u0026gt; Agent Installation menu. Get Started \u0026gt; Install the Agent tab. The installation wizard automatically populates the agent access key. COLLECTOR: Use the collector address associated with your region.\nTAGS: The list of tags for the host where the agent is installed. For example: role:webserver, location:europe.\nFor more information on agent configuration, see Configure Sysdig Agent.\nIf you need any assistance, contact Sysdig Support for help.\nContainer Platforms Kubernetes v1.11 and above\nGoogle Kubernetes Engine (GKE) Amazon Elastic Kubernetes Service (EKS) Note: AWS Fargate is not supported on EKS\nAzure Kubernetes Service (AKS) IBM Cloud Kubernetes Service (IKS) RedHat OpenShift Kubernetes Service (ROKS) 4 and above\nAmazon ECS on EC2\nLinux Distributions Debian v10 and above Ubuntu v18 and above Ubuntu (Amazon) v18 and above CentOS v7 and above Red Hat Enterprise Linux (RHEL) v7 and above SuSE Linux Enterprise Server v15 SP4 and above (running as a container)* RHEL CoreOS (RHCOS) Fedora v36 and above Fedora CoreOS Linux Mint Amazon Linux Amazon Linux v2 Amazon Linux v3 Amazon Bottlerocket Google Container Optimized OS (COS) Oracle Linux (UEH) Oracle Linux (RHCK) EulerOS * Linux service install is not supported on SuSE Linux Enterprise Server.\nContainer Runtimes Docker LXC CRI-O containerd Podman Mesos CPU Architectures X86 ARM s390x (zLinux)** ** Prebuilt probes, Captures and agent installation using the agent container are not supported.\n** Supports only RHEL and OpenShift.\nNext Steps Install on ECS Install on Kubernetes Install on Linux Hosts ","url":"https://docs.sysdig.com/en/sysdig-monitor/install-classicagent/"},{"id":226,"title":"Installer (Kubernetes | OpenShift)","content":"For the latest Sysdig on-prem installation documentation, see the onprem-install-docs repository.\nAll on-premises installations and upgrades are scheduled with and guided by Sysdig technical account managers and the professional services division. See Oversight Services for more information.\nThe instructions in this section are for review purposes only.\nInstallation OverviewTo install, you must:\nDownload the Installer binary and fill out the values.yaml file for the version you\u0026rsquo;d like to install. Provide a few basic parameters. Launch the Installer. In a normal installation, the rest is automatically configured and deployed.\nYou can perform a quick install if your environment has access to the internet, or a partial or full airgapped installation, as needed. Each is described below.\nSee Frequently Used Installer Configurations to:\nCustomize or override settings\nUse hostPath for static storage of Sysdig components\nUse Kubernetes node labels and taints to run only Sysdig pods on selected nodes in a cluster\nGuidelines for Installation and UpgradeCurrent on-premises users who are upgrading their backend can run an installer diff to discover the differences between the old and new versions and then installer deploy for the new version.\nIf you are installing the Sysdig Platform for the first time, ignore the For Upgrade Only instructions in the process.\nPrerequisitesThe Installer must be run from a machine with kubectl or oc configured and with access to the target cluster where the Sysdig platform will be installed. Note that this cluster may be different than where the Sysdig agent is deployed.\nRequirements for Installation Machine with Internet Access\nNetwork access to Kubernetes cluster\nNetwork access to quay.io\nA domain name you are in control of.\nAdditional Requirements for Airgapped Environments\nEdited values.yaml with air gap registry details updated\nNetwork and authenticated access to the private registry\nAccess Requirements\nSysdig license key (Monitor and/or Secure)\nQuay pull secret\nStorage RequirementsYou may use dynamic or static storage on a variety of platforms to store the Sysdig platform components (StatefulSets). Different configuration parameters and values are used during the installation, depending on which scenario you have.\nUse Case 1: Default, Undefined (AWS/GKE)If you are using dynamic storage on Amazon Web Services (AWS) or Google Kubernetes Engine (GKE) and haven\u0026rsquo;t configured any storage class there yet, then the Quick Install streamlines the process for you.\nstorageclassProvisioner: Enter aws or gke. The installer will create the appropriate storage class and then use it for all the Sysdig platform stateful sets.\nstorageclassName: Leave empty.\nUse Case 2: Dynamic, predefinedYou might be using dynamic storage but have already created storage classes in it. This dynamic storage could be AWS, GKE, or any other functioning dynamic storage you use. In this case, you would enter:\nstorageclassProvisioner: Leave empty; anything specified for this option will be ignored.\nstorageclassName: Provide the name of the pre-configured storage class you want to use. The installer will use this storage class for all the Sysdig platform StatefulSets.\nUse Case 3: Static StorageIf dynamic storage is not available, you can use static storage for the Sysdig StatefulSets. In this case, you can use:\nstorageclassProvisioner: Enter hostpath, then define the nodes for the four main Sysdig components: ElasticSearch, Cassandra, MySQL, and Postgres.storageclassProvisioner.\nSee Frequently Used Installer Configurations for details.\nQuickstart InstallationThis install assumes the Kubernetes cluster has network access to pull images from quay.io.\nHave your Sysdig Technical Account Manager download the installer binary that matches your OS from the sysdigcloud-kubernetes releases page.\nFor Upgrades Only: Copy the current version of values.yaml to your working directory.\n./installer-image import -n sysdig --certs-directory certs -o values.yaml If you are editing the values.yaml file for an OpenShift installation and want to review a sample, see openshift-with-hostpath.\nEdit the following values:\nsize: Specifies the size of the cluster. Size defines CPU, Memory, Disk, and Replicas. Valid options are: small, medium, and large.\nquaypullsecret: The quay.io pull secret provided with your Sysdig purchase confirmation mail.\nstorageClassProvisioner: Review Storage Requirements, above.\nIf you have the default use case, enter aws or gke in the storageClassProvisioner field. Otherwise, see Use Case 2 or 3.\nsysdig.license: Sysdig license key provided with your Sysdig purchase confirmation mail.\nsysdig.dnsname: The domain name the Sysdig APIs will be served on. Note that the master node may not be used as the DNS name when using hostNetwork mode.\nsysdig.collector.dnsName: (OpenShift installs only) Domain name the Sysdig collector will be served on. When not configured it defaults to whatever is configured for sysdig.dnsName. Note that the master node may not be used as the DNS name when using hostNetwork mode.\ndeployment: Add deployment: openshift to the root of the values.yaml file. This option is applicable to OpenShift installs only.\nsysdig.ingressNetworking: The networking construct used to expose the Sysdig API and collector. The options are:\nhostnetwork: Sets the host networking in the ingress daemonset and opens host ports for the API and collector. This does not create a Kubernetes service.\nloadbalancer: Creates a service of type loadbalancer and expects that your Kubernetes cluster can provision a load balancer with your cloud provider.\nnodeport: Creates a service of type nodeport.The node ports can be customized with:\nsysdig.ingressNetworkingInsecureApiNodePort\nsysdig.ingressNetworkingApiNodePort\nsysdig.ingressNetworkingCollectorNodePort\nWhen not configured, sysdig.ingressNetworking defaults to hostnetwork.\nIf you are performing an airgapped install, you would also edit the following values:\nairgapped_registry_name: The URL of the airgapped (internal) docker registry. This URL is used for installations where the Kubernetes cluster can not pull images directly from Quay.\nairgapped_repository_prefix: This defines custom repository prefix for airgapped_registry. Tags and pushes images as airgapped_registry_name/airgapped_repository_prefix/image_name:tag\nairgapped_registry_password: The password for the configured airgapped_registry_username. Ignore this parameter if the registry does not require authentication.\nairgapped_registry_username: The username for the configured airgapped_registry_name. Ignore this parameter if the registry does not require authentication.\nFor Upgrades Only:\n[Generate and review the diff of changes the installer is about to introduce:\n./installer diff This will generate the differences between the installed environment and the upgraded version. The changes will be displayed in your terminal.\nIf you want to override a change, based on your environment\u0026rsquo;s custom settings, then contact Sysdig Support for assistance.\nRun the installer:\n./installer deploy See Output (below) to finish.\nSave the values.yaml file in a secure location; it will be used for future upgrades. You can also see a newly generated directory containing various Kubernetes configuration yaml files that were applied by the Installer against your cluster. It is not necessary to keep the generated directory, as the Installer can regenerate it consistently with the same values.yamlfile.\nAirgapped Installation OptionsThe installer can be used in airgapped environments, either with a multi-homed installation machine that has internet access or in an environment with no internet access.\nAirgapped with Multi-Homed Installation MachineThis assumes a private docker registry is used and the installation machine has network access to pull from quay.io and push images to the private registry.\nThe Prerequisites and workflow are the same as in the Quickstart Installation with the following exceptions:\nIn step 2, add the airgap registry information.\nAfter step 3, make the installer push Sysdig images to the airgapped registry by running:\n./installer airgap That will pull all the images into the images_archive directory as tar files and push them to the airgapped registry.\nIf you are upgrading, run the diff as directed in Step 4.\nRun the installer:\n./installer deploy Full Airgap InstallationThis assumes a private docker registry is used and the installation machine does not have network access to pull from quay.io but can push images to the private registry.\nIn this situation, a machine with network access (called the \u0026ldquo;jump machine\u0026rdquo;) will pull an image containing a self-extracting tarball which can be copied to the installation machine.\nAccess Requirements Sysdig license key (Monitor and/or Secure)\nQuay pull secret\nAnchore license file (if Sysdig Secure is licensed)\nJump Machine Requirements Network access to quay.io\nDocker\njq\nRequirements for installation Machine Network access to Kubernetes cluster\nDocker\nNetwork and authenticated access to the private registry\nEdited values.yaml with airgap registry details updated\nHost Disk Space Requirements: 4 GB or more; directory from which the installer is run with 8GB or more; and /var/lib/docker with 4GB or more.\nNOTE: The environment variable TMPDIR can be used to override the/tmp directory.\nLog In to Quay Retrieve Quay username and password from Quay pull secret. For example:\nAUTH=$(echo \u0026lt;REPLACE_WITH_quaypullsecret\u0026gt; | base64 --decode | jq -r \u0026#39;.auths.\u0026#34;quay.io\u0026#34;.auth\u0026#39;| base64 --decode) QUAY_USERNAME=${AUTH%:*} QUAY_PASSWORD=${AUTH#*:} Log in to quay.io. Use the username and password retrieved above.\ndocker login -u \u0026#34;$QUAY_USERNAME\u0026#34; -p \u0026#34;$QUAY_PASSWORD\u0026#34; quay.io WorkflowOn the Jump Machine Log in to quay.io.\nPull the image containing the self-extracting tar:\ndocker pull quay.io/sysdig/installer:5.1.2-2-uber Extract the tarball:\ndocker create --name uber_image quay.io/sysdig/installer:5.1.2-2-uber docker cp uber_image:/sysdig_installer.tar.gz . docker rm uber_image Copy the tarball to the installation machine.\nOn the Installation Machine Copy the current version of values.yaml to your working directory. The file given below is for version 5.1.4.\nwget https://github.com/draios/onprem-install-docs/blob/main/5.1/5.1.4/values.yaml Edit the following values:\nsize: Specifies the size of the cluster. Size defines CPU, Memory, Disk, and Replicas. Valid options are: small, medium, and large.\nquaypullsecret: quay.io provided with your Sysdig purchase confirmation mail.\nstorageClassProvisioner: Review the Storage Requirements.\nIf you have the default use case, enter aws or gke in the storageClassProvisioner field. Otherwise, refer to Use Case 2 or 3.\nsysdig.license: Sysdig license key provided with your Sysdig purchase confirmation mail\nsysdig.dnsname: The domain name the Sysdig APIs will be served on. Note that the master node may not be used as the DNS name when using hostNetwork mode.\nsysdig.collector.dnsName: (OpenShift installs only) Domain name the Sysdig collector will be served on. When not configured it defaults to whatever is configured for sysdig.dnsName. Note that the master node may not be used as the DNS name when using hostNetwork mode.\ndeployment: (OpenShift installs only) Add deployment: openshift to the root of the values.yaml file.\nsysdig.ingressNetworking: The networking construct used to expose the Sysdig API and collector. The options are:\nhostnetwork: Sets the hostnetworking in the ingress daemonset and opens host ports for the API and collector. This does not create a Kubernetes service.\nloadbalancer: Creates a service of type loadbalancer and expects that your Kubernetes cluster can provision a load balancer with your cloud provider.\nnodeport: Creates a service of type nodeport. The node ports can be customized with:\nsysdig.ingressNetworkingInsecureApiNodePort\nsysdig.ingressNetworkingApiNodePort\nsysdig.ingressNetworkingCollectorNodePort\nairgapped_registry_name: The URL of the airgapped (internal) docker registry. This URL is used for installations where the Kubernetes cluster can not pull images directly from Quay.\nairgapped_repository_prefix: This defines custom repository prefix for airgapped_registry. Tags and pushes images as airgapped_registry_name/airgapped_repository_prefix/image_name:tag\nairgapped_registry_password: The password for the configured airgapped_registry_username. Ignore this parameter if the registry does not require authentication.\nairgapped_registry_username: The username for the configured airgapped_registry_name. Ignore this parameter if the registry does not require authentication.\nCopy the tarball file to the directory where you have your values.yaml file.\nRun:\ninstaller airgap --tar-file sysdig_installer.tar.gz NOTE: This step will extract the images into the images_archive directory relative to where the installer was run and push the images to the airgapped_registry.\nFor Upgrades Only:\nGenerate and review the diff of changes the installer is about to introduce:\n./installer diff This will generate the differences between the installed environment and the upgraded version. The changes will be displayed in your terminal.\nIf you want to override a change, based on your environment\u0026rsquo;s custom settings, then contact Sysdig Support for assistance.\nRun the installer:\n./installer deploy See Output (below) to finish.\nSave the values.yamlfile in a secure location; it will be used for future upgrades.\nThere will also be a generated directory containing various Kubernetes configuration yaml files that were applied by the Installer against your cluster. It is not necessary to keep the generated directory, as the Installer can regenerate it consistently with the same values.yamlfile.\nUpdating Vulnerability Feed in Airgapped EnvironmentsNOTE: Sysdig Secure users who install in an airgapped environment do not have internet access to the continuous checks of vulnerability databases that are used in image scanning.\nAs of installer version 3.2.0-9, airgapped environments can also receive periodic vulnerability database updates.\nThis section is applicable only to the legacy scanning engine v1.\nWhen you install with the \u0026ldquo;airgapped_\u0026rdquo; parameters enabled (see Full Airgap Install instructions), the installer will automatically push the latest vulnerability database to your environment. Follow the steps below to reinstall/refresh the vuln db, or use the script and chron job to schedule automated updates (such as daily or weekly).\nTo automatically update the vulnerability database, you can:\nDownload the image file quay.io/sysdig/vuln-feed-database-ubi:latest from the Sysdig registry to the jump box server and save it locally.\nMove the file from the jump box server to the airgapped environment if needed.\nLoad the image file and push it to the airgapped image registry.\nRestart the pod sysdigcloud-feeds-db.\nRestart the feeds-api pod.\nThe feeds_database_update.sh script performs the following:\n#!/bin/bash QUAY_USERNAME=\u0026#34;\u0026lt;change_me\u0026gt;\u0026#34; QUAY_PASSWORD=\u0026#34;\u0026lt;change_me\u0026gt;\u0026#34; # Download image docker login quay.io/sysdig -u ${QUAY_USERNAME} -p ${QUAY_PASSWORD} docker image pull quay.io/sysdig/vuln-feed-database-ubi:latest # Save image docker image save quay.io/sysdig/vuln-feed-database-ubi:latest -o vuln-feed-database-ubi.tar # Optionally move image mv vuln-feed-database-ubi.tar /var/shared-folder # Load image remotely ssh -t user@airgapped-host \u0026#34;docker image load -i /var/shared-folder/vuln-feed-database-ubi.tar\u0026#34; # Push image remotely ssh -t user@airgapped-host \u0026#34;docker tag vuln-feed-database-ubi:latest airgapped-registry/vuln-feed-database-ubi:latest\u0026#34; ssh -t user@airgapped-host \u0026#34;docker image push airgapped-registry/vuln-feed-database-ubi:latest\u0026#34; # Restart database pod ssh -t user@airgapped-host \u0026#34;kubectl -n sysdigcloud rollout restart deploy sysdigcloud-feeds-db\u0026#34; # Restart feeds-api pod ssh -t user@airgapped-host \u0026#34;kubectl -n sysdigcloud rollout restart deploy sysdigcloud-feeds-api\u0026#34; Schedule a chron job to run the script on a chosen schedule (for example, every day):\n0 8 * * * feeds-database-update.sh \u0026gt;/dev/null 2\u0026gt;\u0026amp;1 OutputA successful installation should display output in the terminal such as:\nAll Pods Ready.....Continuing Congratulations, your Sysdig installation was successful! You can now login to the UI at \u0026#34;https://awesome-domain.com:443\u0026#34; with: username: \u0026#34;configured-username@awesome-domain.com\u0026#34; password: \u0026#34;awesome-password\u0026#34; There will also be a generated directory containing various Kubernetes configuration yaml files which were applied by the Installer against your cluster. It is not necessary to keep the generated directory, as the installer can regenerate consistently with the same values.yaml file.\nAdditional Installer Resources To see all the configuration parameters available, as well as their definitions, values, and examples, see configuration_parameters.md.\nFor advanced options, including static storage and patching, see Frequently Used Installer Configurations.\nExample values.yaml files:\nsingle-node values.yaml\nopenshift-with-hostpath values.yaml\n","url":"https://docs.sysdig.com/en/administration/onprem-installer-kubernetes-openshift/"},{"id":227,"title":"Integrate with CI/CD Tools","content":"Review the Types of Secure Integrations table for more context. The CI/CD Tools column lists the various options and their levels of support.\nEnd of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nInline ScanningSysdig provides a stand-alone inline scanner\u0026ndash; a containerized application that can perform local analysis on container images (both pulling from registries or locally built) and post the result of the analysis to Sysdig Secure.\nOther scanning integrations (i.e. the Jenkins CI/CD plugin make use of this component under the hood to provide local image analysis capabilities, but it can also be used as a stand-alone component for custom pipelines, or simply as a way to one-shot scan a container from any host.\nThe Sysdig inline scanner works as an independent container, without any Docker dependency (it can be run using other container runtimes), and can analyze images using different image formats and sources.\nThis feature has a variety of use cases and benefits:\nImages don\u0026rsquo;t leave their own environment\nSaaS users don\u0026rsquo;t send images and proprietary code to Sysdig\u0026rsquo;s SaaS service\nRegistries don\u0026rsquo;t have to be exposed\nImages can be scanned in parallel more easily\nImages can be scanned before they hit the registry, which can\ncut down on registry costs\nsimplify the build pipeline\nPrerequisitesAt a minimum, the inline scanner requires:\nSysdig Secure v2.5.0+ (with API token)\nInternet access to post results to Sysdig Secure (SaaS or On-Prem)\nAbility to run a container\nUsing the inline_script.sh is deprecated. This script uses a different set of parameters; for more information about porting the parameters to the inline scanner container, see changes-from-v1xx.\nImplement Inline ScanningQuick StartYou can scan an image from any host by executing:\ndocker run --rm quay.io/sysdig/secure-inline-scan:2 \u0026lt;image_name\u0026gt; --sysdig-token \u0026lt;my_API_token\u0026gt; --sysdig-url \u0026lt;secure_backend_endpoint\u0026gt; … … Status is pass View the full result @ https://secure.sysdig.com/#/scanning/scan-results/docker.io%2Falpine%3A3.12.1/sha256:c0e9560cda118f9ec63ddefb4a173a2b2a0347082d7dff7dc14272e7841a5b5a/summaries PDF report of the scan results can be generated with -r option. UpgradingYou can rerun this Docker command to upgrade to the latest inline scanning component at any time.\nCommon Parameters Parameter\nDescription\nImage name (mandatory)\nContainer image to be analyzed, following the usual registry/repo:tag format, i.e. docker.io/alpine:3.12.1. If no tag is specified, the latest will be used.\nDigest format is also supported, i.e.: docker.io/alpine@sha256:c0e9560cda118f9ec6...\n--sysdig-token (mandatory)\nSysdig API token, visible from the User Profile page.\n--sysdig-url:\nNot required for Sysdig Secure SaaS in the us-east region. For any other case, you must adjust this parameter. I.e. for SaaS us-west it is: --sysdig-url https://us2.app.sysdig.com. See also SaaS Regions and IP Ranges.\nQuick Help and Parameter List from -hDisplay a quick help and parameters description from the image itself by executing: docker run --rm quay.io/sysdig/secure-inline-scan:2 -h.\nSample output:\n$ docker run quay.io/sysdig/secure-inline-scan:2 -h Sysdig Inline Analyzer -- USAGE Container for performing analysis on local container images, utilizing the Sysdig analyzer subsystem. After image is analyzed, the resulting image archive is sent to a remote Sysdig installation using the -s \u0026lt;URL\u0026gt; option. This allows inline analysis data to be persisted \u0026amp; utilized for reporting. Usage: sysdig-inline-scan.sh -k \u0026lt;API Token\u0026gt; [ OPTIONS ] \u0026lt;FULL_IMAGE_TAG\u0026gt; == GLOBAL OPTIONS == -k \u0026lt;TEXT\u0026gt; [required] API token for Sysdig Scanning auth (ex: -k \u0026#39;xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\u0026#39;) Alternatively, set environment variable SYSDIG_API_TOKEN Alias: --sysdig-token -s \u0026lt;URL\u0026gt; [optional] Sysdig Secure URL (ex: -s \u0026#39;https://secure-sysdig.svc.cluster.local\u0026#39;). If not specified, it will default to Sysdig Secure SaaS URL (https://secure.sysdig.com). Alias: --sysdig-url --sysdig-skip-tls [optional] skip tls verification when calling secure endpoints -o [optional] Use this flag if targeting onprem sysdig installation Alias: --on-prem -a \u0026lt;TEXT\u0026gt; [optional] Add annotations (ex: -a \u0026#39;key=value,key=value\u0026#39;) Alias: --annotations -f \u0026lt;PATH\u0026gt; [optional] Path to Dockerfile (ex: -f ./Dockerfile) Alias: --dockerfile -m \u0026lt;PATH\u0026gt; [optional] Path to Docker image manifest (ex: -m ./manifest.json) Alias: --manifest -i \u0026lt;TEXT\u0026gt; [optional] Specify image ID used within Sysdig (ex: -i \u0026#39;\u0026lt;64 hex characters\u0026gt;\u0026#39;) Alias: --image-id -d \u0026lt;SHA256\u0026gt; [optional] Specify image digest (ex: -d \u0026#39;sha256:\u0026lt;64 hex characters\u0026gt;\u0026#39;) Alias: --digest -c [optional] Remove the image from Sysdig Secure if the scan fails -r \u0026lt;PATH\u0026gt; [optional] Download scan result pdf in a specified container-local directory (ex: -r /staging/reports) This directory needs to be previously mounted from the host to persist the data Alias: --report-folder -v [optional] Increase verbosity Alias: --verbose --format \u0026lt;FORMAT\u0026gt; [optional] The only valid format is JSON. It sets the output format to a valid JSON which can be processed in an automated way. --write-json \u0026lt;PATH\u0026gt; Write the final JSON report to \u0026lt;PATH\u0026gt;. --time-profile Output information about the time elapsed in the different stages of the scan process --malware-scan-enable Enables malware scan on container. WARNING: it is generally a very slow process. --malware-scan-db-path \u0026lt;PATH\u0026gt; Local container path with updated ClamAV database. Will be used to call clamscan command as \u0026#34;clamscan --database=\u0026lt;PATH\u0026gt; ...\u0026#34; --malware-scan-output \u0026lt;DIR-PATH\u0026gt; Save JSON output of scan to path. Will be saved to \u0026lt;PATH\u0026gt;/malware_findings.json. Output is a JSON array of {\u0026#34;path\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;signature\u0026#34;: \u0026#34;...\u0026#34;} objects. Note: path should exists and should be a directory. --malware-fail-fast true|false Fails immediately when a malware is found, skipping sending analysis results to Secure Backend. Default: true --malware-exclude REGEX Exclude dirs (and its content) and files which match the given regex. Arguments are passed to ClamAV --exclude AND --exclude-dir options, please refer to its official documentation. (https://www.clamav.net/documents/clam-antivirus-user-manual) == IMAGE SOURCE OPTIONS == [default] If --storage-type is not specified, pull container image from registry. == REGISTRY AUTHENTICATION == When pulling from the registry, the credentials in the config file located at /config/auth.json will be used (so you can mount a docker config.json file, for example). Legacy .dockercfg file is also supported. Alternatively, you can provide authentication credentials with: --registry-auth-basic username:password Authenticate using the provided \u0026lt;username\u0026gt; and \u0026lt;password\u0026gt; --registry-auth-token \u0026lt;TOKEN\u0026gt; Authenticate using this Bearer \u0026lt;Token\u0026gt; --registry-auth-file \u0026lt;PATH\u0026gt; Path to config.json or auth.json file with registry credentials --registry-auth-dockercfg \u0026lt;PATH\u0026gt; Path to legacy .dockercfg file with registry credentials == TLS OPTIONS == -n Skip TLS certificate validation when pulling image Alias: --registry-skip-tls --storage-type \u0026lt;SOURCE-TYPE\u0026gt; Where \u0026lt;SOURCE-TYPE\u0026gt; can be one of: docker-daemon Get the image from the Docker daemon. Requires /var/run/docker.sock to be mounted in the container cri-o Get the image from containers-storage (CRI-O and others). Requires mounting /etc/containers/storage.conf and /var/lib/containers docker-archive Image is provided as a Docker .tar file (from docker save). Tarfile must be mounted inside the container and path set with --storage-path oci-archive Image is provided as a OCI image tar file. Tarfile must be mounted inside the container and path set with --storage-path oci-dir Image is provided as a OCI image, untared. The directory must be mounted inside the container and path set with --storage-path --storage-path \u0026lt;PATH\u0026gt; Specifies the path to the source of the image to scan, that has to be mounted inside the container, it is required if --storage-type is set to docker-archive, oci-archive or oci-dir == EXIT CODES == 0 Scan result \u0026#34;pass\u0026#34; 1 Scan result \u0026#34;fail\u0026#34; 2 Wrong parameters 3 Error during execution Supported Execution Modes and Image FormatsThe inline scanner can pull the target image from different sources. Each case requires a different set of parameters and/or host mounts.\nDirectly pulling from a registry: default option if no other source is specified\nDocker daemon: Retrieve the image from the host-local Docker daemon\nDocker archive: Passing a Docker tar file (i.e. output of docker save)\nOCI archive: passing an OCI tar file\nOCI layout: OCI image directory\nContainer storage (CRI-O and others): CRI-O storage directory\nOutput OptionsWhen the inline scanner has completed the image analysis, it sends the metadata to the Sysdig Secure backend to perform the policy evaluation step. The scan results can then be consumed inline or by accessing the Secure UI.\nContainer Exit CodeThe container exit codes are:\n0 - image passed policy evaluation\n1 - image failed policy evaluation\n2 - incorrect parameters (i.e. no API token)\n3 - other execution errors\nUse the exit code, for example, to decide whether to abort the CI/CD pipeline.\nStandard OutputThe standard output produces a human-readable output including:\nImage information (digest, image ID, etc)\nEvaluation results, including the final pass / fail decision\nA link to visualize the complete scan report using the Sysdig UI\nIf you prefer JSON output, simply pass --format JSON as a parameter.\nJSON Output This feature is in Technical Preview status.\nYou can write a JSON report, while keeping the human-readable output in the console, by adding the following flag: --write-json /out/report.json\nRemember to bind mount the output directory from the host in the container and provide the corresponding write permissions.\nPDF ReportYou can also download the scan result PDF in a specified container-local directory. Remember to mount this directory from the host in the container to retain the data.\n--report-folder /output\nExecution ExamplesDocker DaemonScan a local image build; mounting the host Docker socket is required. You might need to include Docker options \u0026lsquo;-u root\u0026rsquo; and \u0026lsquo;--privileged\u0026rsquo;, depending on the access permissions for/var/run/docker.sock\ndocker build -t \u0026lt;image-name\u0026gt; . docker run --rm \\ -v /var/run/docker.sock:/var/run/docker.sock \\ quay.io/sysdig/secure-inline-scan:2 \\ --sysdig-url \u0026lt;omitted\u0026gt; \\ --sysdig-token \u0026lt;omitted\u0026gt; \\ --storage-type docker-daemon \\ --storage-path /var/run/docker.sock \\ \u0026lt;image-name\u0026gt; Docker ArchiveTrigger the scan, assuming the image is available as an image tarball at image.tar. For example, the command docker save \u0026lt;image-name\u0026gt; -o image.tar creates a tarball for \u0026lt;image-name\u0026gt;. Mount this file inside the container:\ndocker run --rm \\ -v ${PWD}/image.tar:/tmp/image.tar \\ quay.io/sysdig/secure-inline-scan:2 \\ --sysdig-url \u0026lt;omitted\u0026gt; \\ --sysdig-token \u0026lt;omitted\u0026gt; \\ --storage-type docker-archive \\ --storage-path /tmp/image.tar \\ \u0026lt;image-name\u0026gt; OCI ArchiveTrigger the scan assuming the image is available as an OCI tarball at oci-image.tar. Mount this file inside the container:\ndocker run --rm \\ -v ${PWD}/oci-image.tar:/tmp/oci-image.tar \\ quay.io/sysdig/secure-inline-scan:2 \\ --sysdig-url \u0026lt;omitted\u0026gt; \\ --sysdig-token \u0026lt;omitted\u0026gt; \\ --storage-type oci-archive \\ --storage-path /tmp/oci-image.tar \\ \u0026lt;image-name\u0026gt; OCI LayoutTrigger the scan assuming the image is available in OCI format in the directory./oci-image. Mount the OCI directory inside the container:\ndocker run --rm \\ -v ${PWD}/oci-image:/tmp/oci-image \\ quay.io/sysdig/secure-inline-scan:2 \\ --sysdig-url \u0026lt;omitted\u0026gt; \\ --sysdig-token \u0026lt;omitted\u0026gt; \\ --storage-type oci-dir \\ --storage-path /tmp/oci-image \\ \u0026lt;image-name\u0026gt; Container Storage: Build w/ Buildah \u0026amp; Scan w/ PodmanBuild an image using Buildah from a Dockerfile, and perform a scan. You might need to include docker options '-u root'and '--privileged', depending on the access permissions for /var/lib/containers. Mount the container storage folder inside the container:\nsudo buildah build-using-dockerfile -t myimage sudo podman run \\ --rm -u root --privileged \\ -v /var/lib/containers/:/var/lib/containers \\ quay.io/sysdig/secure-inline-scan:2 \\ --storage-type cri-o \\ --sysdig-token \u0026lt;omitted\u0026gt; \\ localhost/myimage Using a ProxyTo use a proxy, set the standard http_proxy and https_proxy variables when running the container.\nExample:\ndocker run --rm \\ -e http_proxy=\u0026#34;http://my-proxy:3128\u0026#34; \\ -e https_proxy=\u0026#34;http://my-proxy:3128\u0026#34; \\ quay.io/sysdig/secure-inline-scan:2 \\ --sysdig-url \u0026lt;omitted\u0026gt; \\ --sysdig-token \u0026lt;omitted\u0026gt; \\ alpine Both http_proxy and https_proxy variables are required, as some tools will use a per-scheme proxy.The no_proxy variable can be used to define a list of hosts that don\u0026rsquo;t use the proxy.\nPerform Inline Malware ScanningIt is now possible to scan the image contents for malware as part of the inline scanning process.\nNote two important details to consider:\nMalware scanning is resource intensive. Enable this mode for the required set of images only, i.e. images coming from an untrustworthy source.\nMalware contents in the image are not communicated back to the Sysdig backend. The default behavior if malware is found is to consider the scan failed, report malware details, and abort analysis.\nMalware Scanning Flags --malware-scan-enable:Enable malware detection as part of the inline scanner analysis process. Mounting an external malware database (Using ClamAV format) is highly recommended. If no existing malware database is detected, the analyzer will try to download one on the spot, which means the download time will be added to the analysis process and that it will require network connectivity to pull this database from the Internet.\n--malware-scan-db-path \u0026lt;PATH\u0026gt;:Local container path with updated ClamAV database. Will be used to call clamscan command as clamscan --database=\u0026lt;PATH\u0026gt;\n--malware-fail-fast true|false:Fail fast is true by default, meaning that, on malware found, the image contents will not be sent to the Sysdig backend for further policy evaluation. If you want to send the image contents to the Backend, even on malware detected, set this parameter to false.\nAbout this flag, note:\nIf no malware is detected, the image contents will be sent to the backend and follow the regular evaluation.\nIf malware is detected, the container will exit with error code 1.\n--malware-scan-output \u0026lt;DIR-PATH\u0026gt;: Save JSON output of scan to path. Will be saved to \u0026lt;PATH\u0026gt;/malware_findings.json. Path must exist and must be a directory; remember to mount this path from an external directory if you want to persist the data.\n--malware-exclude REGEX: It is possible to exclude image directories to speed up the malware analysis (for example directories that only contain signed software or sizable files).\nArguments are passed to ClamAV. For --exclude AND --exclude-dir options, please refer to their official documentation.\nExample: Mounting External Malware Database (Recommended)Note that /absolute/path/to/clamdb/folder (and its contained files) must have read and execute permissions set for the current Docker user.\nRefer to ClamAV official documentation.for how to download and keep a local database in sync.\ndocker run --rm -v /absolute/path/to/clamdb/folder:/malwaredb quay.io/sysdig/secure-inline-scan:2 --sysdig-token \u0026lt;API_Token\u0026gt; --malware-scan-enable --malware-scan-db-path /malwaredb malwares/malware-example:7 Skipping send analysis to Secure backend due to Malware scan failure. This behaviour can be tuned via --malware-fail-fast option. Path | Signature /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin | Win.Trojan.Emotet-6799923-0 /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin | Win.Trojan.Emotet-9769817-0 /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin | Win.Trojan.Emotet-9769818-0 /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin | Win.Trojan.Agent-1280578 /data/29D6161522C7F7F21B35401907C702BDDB05ED47.bin!(0) | Win.Trojan.Agent-1280578 Example: Download Malware Database Inlinedocker run --rm quay.io/sysdig/secure-inline-scan:2 --sysdig-token \u0026lt;API_Token\u0026gt; --malware-scan-enable malwares/malware-example:7 Malware detection is provided by a third-party software. Sysdig cannot directly remediate false negatives or false positives reported by this functionality.\nPipeline Integration ExamplesThere are well-documented examples for a variety of pipelines:\nGitLab\nGitHub Actions\nAWS Codepipeline\nAzure Pipelines\nCircleCI\nTekton Pipelines\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/integrate-with-cicd-tools/"},{"id":228,"title":"Integrate with Jenkins","content":"PrerequisitesSysdig Secure API token: Jenkins workers must have access to the image storage, whether it\u0026rsquo;s the local storage where the image was created or the registry where it\u0026rsquo;s stored.\nConfigurationTo configure the Sysdig Secure plugin:\nInstall the Sysdig plugin.\nFrom the main Jenkins menu, select Manage Jenkins.\nClick Configure System.\nScroll down to the Sysdig Secure Plugin section.\nIn the Sysdig Secure API Credentials drop-down:\nClick Add to create a new credential containing the Sysdig Secure API Token.\n​ You can find the token in the Settings \u0026gt; User Profile menu.\nEnter the password. You can keep the username field blank.\nSelect the new credential.\nEnter the Sysdig Secure API endpoint in the Sysdig Secure Engine URL field.\nFor On-Prem installations, this is the URL where your Secure API is exposed.\nFor the SaaS service:\nDefault region US East (North Virginia): https://secure.sysdig.com\nUS West (Oregon): https://us2.app.sysdig.com\nEuropean Union: https://eu1.app.sysdig.com\n​\tSee SaaS Regions and IP Ranges for a complete list of regions.\nIf you are connecting to an On-Prem instance using an invalid TLS certificate, then you need to either configure Jenkins to trust the certificate, or uncheck the Verify SSL checkbox.\nClick Save.\nExample: Run the Sysdig Plugin Inside a PipelineThe following is a simplified example executing the Sysdig plugin as a stage inside a pipeline:\nstages { stage(\u0026#39;Checkout\u0026#39;) { steps { checkout scm } } stage(\u0026#39;Build Image\u0026#39;) { steps { sh \u0026#34;docker build -f Dockerfile -t ${params.DOCKER_REPOSITORY} .\u0026#34; } } stage(\u0026#39;Scanning Image\u0026#39;) { steps { sysdigImageScan engineCredentialsId: \u0026#39;sysdig-secure-api-credentials\u0026#39;, imageName: \u0026#34;${params.DOCKER_REPOSITORY}\u0026#34; } } } The table below describes the configuration options.\nConfiguration Parameters Option Parameter Description Default Image name ImageName The name of the image to scan sysdig_secure_images Fail build on policy check STOP result bailOnFail Sysdig Secure policy evaluation returning a fail (STOP) indicates a Jenkins job failure. If this option is not selected, a failed policy evaluation will allow the build to continue. true Fail build on critical plugin error bailOnPluginFail If selected, and the Sysdig Secure Plugin experiences a critical error, the build is failed. This is typically used to ensure that a fault with Sysdig Secure, such as unavailable service, does not permit a failing image to be promoted to production. true Identifiers of policies to apply policiesToApply List of policies to apply to the image in addition to those marked as always apply in the sysdig ui Run Sysdig Plugin as a Jenkins StepThe following is an example of executing the Sysdig Secure plugin as a Jenkinsfile step, modifying the default parameters:\nsysdigImageScan bailOnFail: false, bailOnPluginFail: false, engineCredentialsId: \u0026#39;sysdig-secure-api-credentials\u0026#39;, engineURL: \u0026#39;https://secure.sysdig.com\u0026#39;, engineVerify: false, imageName: \u0026#39;ruby\u0026#39;, policiesToApply: \u0026#39;foo\u0026#39;, scannerBinaryPath: \u0026#39;/bin/sysdig-cli-scanner\u0026#39; Obtain Scan Results in JenkinsThe Sysdig plugin generates a scan report listed in the Jenkins build list.\nsysdig_secure_gates.json Scanning results for the Sysdig policy evaluation.\nsysdig_secure_security.json Detected vulnerability data\nsysdig_secure_raw-vulns_report-.json Raw vulnerability data\nLearn MoreSysdig Secure Container Image Scanner\n","url":"https://docs.sysdig.com/en/sysdig-secure/jenkin-integration/"},{"id":229,"title":"Kubernetes Troubleshooting","content":" In the Kubernetes | Troubleshooting page of Advisor, different tabs appear based on where in the infrastructure you are viewing. Your current position is indicated by the header in bold under Troubleshooting.\nEntire Infrastructure Cluster Namespace Workload Pod Overview ✓ ✓ ✓ ✓ ✓ Advisories ✓ ✓ ✓ ✓ ✓ Alerts ✓ ✓ ✓ ✓ ✓ Events ✓ ✓ ✓ ✓ ✓ Resource Allocation ✓ Capacity ✓ Nodes ✓ Workloads ✓ Monitoring Integrations ✓ Pods ✓ Disk ✓ Network ✓ Containers ✓ Processes ✓ Logs ✓ YAML ✓ Each tab provides a wealth of information relevant to different parts of your infrastructure:\nEntire Infrastructure\nOverview: A high level summary of the object, including telemetry and metadata (Kubernetes labels and Annotations). For more details, see Overview. Advisories: See the key problems in your infrastructure and how to resolve them. For more detail, see Advisories. Alerts: Triggered alerts. Events: Events from Kubernetes, container engines, and custom user events. Cluster only\nResource Allocation: Contains cluster information, such as requested resources and resource utilization. Capacity: Shows the capacity of your resources and the level of overcommit. Nodes: When you have a selected a cluster, this tab shows you the status of individual nodes. Namespace only\nWorkloads: Shows information about your workloads, including availability, limits, and resource usage. Monitoring Integrations: Displays list of application and infrastructure integrations. You can configure integrations from this tab. Workload only\nPods: Shows the status of pods in a workload, including details such as CPU and memory usage. Disk: The storage of the node. Provides file and disk metrics, such as network traffic and latency per workload. Network: Provides information related to networking and http traffic, such as the number of inbound connections, request latency, and TCP queue length per pod. Pod only\nContainers: Narrow into a single container in pod. Processes: View metrics such as CPU and memory usage, latency, and errors for a container. Logs: See live logs of your pods. For more detail, see Live Logs. YAML: View the YAML configuration of a container. For more detail, see YAML Configuration. OverviewThis tab includes a summary of the main categories, including advisories, status, and metadata.\nMetadata, such as Labels and Annotations, is displayed for clusters, namespaces, workloads and pods. This metadata is sourced from your infrastructure and is taken from the last four hours.\nGolden Signals are Service Level Indicators (SLIs) that measure key metrics such as latency, requests, traffic, and errors, derived from syscall and ebpf data.\nAdvisoriesAdvisories evaluate the thousands of data points being sent by the Sysdig agent, and display a prioritized view of key problems in your infrastructure that affect the health and availability of your clusters and the workloads running on them.\nWhen you select an advisory, relevant information related to the issue is surfaced, such as metrics, events, live logs, and remediation guidance. This enables you to pinpoint and resolve problems faster.\nExample Issues Detected Problem\nDescription\nCrashLoopBackOff\nA CrashLoopBackOff means that you have a pod starting, crashing, starting again, and then crashing again. This could cause applications to become unavailable.\nContainer Error\nPersistent application error resulting in containers being terminated. An application error, or exit code 1, means the container was terminated due to an application problem.\nCPU Throttling\nContainers are hitting their CPU limit and being throttled. CPU throttling will not result in the container being killed, but will starve the container of CPU, resulting in application slowdown.\nOOM Kill\nWhen a container reaches its memory limit it is terminated with an OOMKilled status, or exit code 137. This can lead to application instability or unavailability.\nImage Pull Error\nA container is failing to start as it cannot pull the image.\nAdvisories are automatically resolved when the problem is no longer detected.\nLive LogsAdvisor can display live logs for a container, which is the equivalent of running kubectl logs. This is useful for troubleshooting application errors or problems such as pods in a CrashLoopBackOff state.\nWhen you select a pod, the Logs tab will appear. If there are multiple containers within a pod, you can select the container you wish to view logs for. Once requested, logs are streamed for 3 minutes before the session is automatically closed. If necessary, you can simply re-start streaming.\nLive logs are tailed on-demand and thus not persisted. After a session is closed they are no longer accessible.\nManage User Access to Live LogsBy default live logs are available to users within the scope of their Sysdig Team. Use Custom Roles to manage live logs permissions.\nConfigure Agent for Live LogsLive logs are enabled by default in agent 12.7.0 or newer versions. Older versions of the Sysdig agent do not support live logs.\nYou can enable or disable Live logs by configuring the agent.\nTo turn live logs off globally for a cluster, add the following in the dragent.yaml file:\nlive_logs: enabled: false If using Helm, this is configured via sysdig.settings. For example:\nsysdig: # Advanced settings. Any option in here will be directly translated into dragent.yaml in the Configmap settings: live_logs: enabled: false Troubleshoot Live LogsIf there is a problem with live logs, the following errors will be returned. Contact Sysdig Support for additional help and troubleshooting.\nError Code Cause 401 kubelet doesn’t have the bearer token authorization enabled. 403 The sysdig-agent ClusterRole is outdated and does not have the node/proxy permission. Use Sysdig Helm Charts to automatically update the agent ClusterRole. YAML ConfigurationAdvisor can display the YAML configuration for pods, which is the equivalent of running kubectl get pod \u0026lt;pod\u0026gt; -o yaml. This is useful to see the applied configuration of a pod in a raw format, as well as metadata and status. To view the YAML, select a pod in Advisor and open the YAML tab.\nSupport for viewing YAML config is for pods only. Other object types are not yet supported. Manage Access to YAML ConfigurationBy default, displaying YAML configuration is available to users within the scope of their Sysdig Team. Use Custom Roles to manage permissions. The permission for displaying YAML configuration is Advisor - Kubernetes API.\nConfigure Agent for YAML ConfigurationYAML configuration can be enabled in agent 12.9.0 or newer versions. Older versions of the Sysdig agent do not support YAML configuration.\nYou can use the agent configuration to enable the YAML configuration.\nTo turn support for YAML configuration on globally for a cluster, add the following in the dragent.yaml file:\nk8s_command: enabled: true If you are using helm, edit sysdig.settings. For example:\nsysdig: # Advanced settings. Any option in here will be directly translated into dragent.yaml in the Configmap settings: k8s_command: enabled: true ","url":"https://docs.sysdig.com/en/sysdig-monitor/advisor-troubleshooting/"},{"id":230,"title":"Legacy Support Statement for On-Premises Releases","content":"Sysdig On-Premises releases are versioned and labeled as [Major Version].[Minor Version].[Patch Number] and a build number. On-Premises releases are categorized as:\nMajor Minor Patch A major release is defined as having significant changes to the application, such as changes in architecture, addition of a component or service, features, or infrastructure components.\nA minor release typically includes functionality or feature enhancements, new features, UX improvements, etc.\nA patch release is created when an issue is identified, either in the field or internally, that requires an immediate fix. These typically include bugs, or patches for newly discovered vulnerabilities.\nSupported ReleasesCustomers who run Sysdig on premise are encouraged to stay up to date with our latest releases. This ensures the most hardened code base, infrastructure components, vulnerability patches, and new features.\nSysdig provides support (in accordance with our on prem Support Services Policy) for the most recent major version (n) and one version prior (n -1). Once a release has become unsupported, Sysdig will continue to support that release for a period of three months. This allows our customers a window of planning for an upgrade to a supported version (n or n-1).\nAdditionally, Sysdig will work to patch the known and impacting vulnerabilities for the most recent version (n) as of the on-premises build date. This will include critical, high, medium, and low CVE severities.\nFor critical and high vulnerabilities that are not fixed with the latest build, Sysdig will provide a Security Advisory document that details the impact exposure. This can include false-positives or benign vulnerabilities. For vulnerabilities of grave consequence (such as Log4J), Sysdig may provide hot-fixes for the most recent version (n) and the version prior (n -1). All customers are encouraged to keep their environments to n and n-1 versions.\nVersion Supported Until EOS Date 6.x (Latest Version) 8.x 3 Months after 8.x release date 5.x 7.x 3 Months after 7.x release date 4.x 6.x August 2023 3.x Obsolete 2.x Obsolete If you have questions regarding Sysdig support policy, contact Sysdig Support.\n","url":"https://docs.sysdig.com/en/administration/onprem-legacy-support-statement/"},{"id":231,"title":"Dashboard Library","content":"Sysdig provides a number of pre-defined dashboards to assist users in monitoring their environments and applications. Dashboards in the library are essentially immutable dashboards that can\u0026rsquo;t be edited, and the scope is fixed. They can be used as is, or you can copy them to your dashboards to make modifications.\nIn older versions of Monitor and on-prem, Dashboard Library used to be called Dashboard Templates.\nAWS CloudWatch Dashboards PromQL Notes ALB Overview No AWS ALB Yes AWS EBS Yes AWS ECS Fargate Overview Yes AWS ECS Fargate Service Detail Yes AWS ELB Yes AWS Lambda Function Detail Yes AWS Lambda Overview Yes AWS RDS Yes AWS S3 Yes AWS SQS Yes DynamoDB Overview No EC2 Overview No ECS Overview No ECS Projects No ECS Services No ECS Task Families No ECS Tasks No ELB Overview No ElastiCache Overview No RDS Overview No SQS Overview No AWS Lambda Metrics Dashboards PromQL Notes AWS Lambda Metrics Yes AWS MetricsStream Dashboards PromQL Notes AWS ALB Yes AWS CloudFront Yes AWS EBS Yes AWS ECS/Fargate Yes AWS ELB Yes AWS Lambda Yes AWS RDS Yes AWS S3 Yes AWS SQS Yes Applications Dashboards PromQL Notes ActiveMQ No Apache (legacy) No Apache App Overview Yes Apache CouchDB No Apache HBase No Apache Kafka No Apache ZooKeeper No Calico Yes Cassandra Yes Cassandra By Node No Cassandra Overview No Ceph Yes Consul Yes Consul No Consul Envoy Yes Couchbase No Docker Engine Yes ElasticSearch Cluster Yes ElasticSearch Infra Yes Elasticsearch No Fluentd Yes Fluentd No Gearman No Go No Go Internals Yes HAProxy No HAProxy Ingress Overview Yes HAProxy Ingress Service Details Yes HDFS No HTTP No Harbor Yes Istio 1.0 Overview No Istio 1.0 Service No Istio 1.5 Overview No Istio 1.5 Service No Istio Control Plane Yes Istio Service Yes Istio Workload Yes JVM No Kafka Yes Keda Yes Knative Yes Kyoto Tycoon No Memcached No Memcached Yes Microsoft IIS - Application Pools and Workers Yes Microsoft IIS - Overview Yes Microsoft SQL Server Yes Microsoft SqlServer Overview Yes MongoDB (Server) No MongoDB Database Details Yes MongoDB Instance Health Yes MySQL Yes MySQL Server No NTP Yes Nginx Yes Nginx (legacy) No Nginx Ingress Yes OPA Gatekeeper Yes Oracle DB Yes PHP-FPM No Percona TokuMX No PgBouncer No Php-fpm Yes Portworx Cluster Yes Portworx Volumes Yes Postfix No PostgreSQL Database Details Yes PostgreSQL Instance Health Yes PostgreSQL Server No RabbitMQ No Rabbitmq Overview Yes Rabbitmq Usage Yes Redis Yes Redis (legacy) No Redis Enterprise Yes Riak No Riak CS No SAP HANA DB Yes SAP System Yes Solr Cluster No Solr Host No Tomcat No VMware Overview Yes Varnish No VoltDB No Windows Host Overview Yes Windows Node Overview (Legacy) Yes Windows Process Overview Yes Windows Services Overview Yes etcd No lighttpd No Azure Dashboards PromQL Notes Azure API Management Yes Azure Blob Storage Yes Azure Cluster Autoscaler Yes Azure Files Yes Azure Kubernetes Service Yes Azure Queue Storage Yes Azure SQL Yes Azure Storage Accounts Yes Azure Synapse Analytics Yes Azure Table Storage Yes Azure Virtual Machine Scale Sets Yes Azure Virtual Machines Yes Compliance And Security Dashboards PromQL Notes Docker Compliance Report No Kubernetes Compliance Report (v1.4) No Security Summary No Containers Dashboards PromQL Notes Container CPU \u0026amp; Memory Limits No Container Disk Usage \u0026amp; Performance No Container Network No Container Resource Usage No Docker Dashboards PromQL Notes Overview No Projects No Services No Swarm Overview No Swarm Services No Swarm Tasks No GCP Dashboards PromQL Notes GCP Cloud MySQL Yes GCP Cloud PostgreSQL Yes GCP Cloud SQL Server Yes GCP Compute Engine Yes GCP Memorystore Redis Yes Host Infrastructure Dashboards PromQL Notes File System Usage \u0026amp; Performance No Host Resource Usage No Linux Host Overview Yes Network No IBM Dashboards PromQL Notes Enterprise Application Service Yes IBM Cloud Kubernetes Service Control Plane Dashboards PromQL Notes IBM Kubernetes API Server Yes K8s Control Plane Dashboards PromQL Notes Kubernetes API Server Yes Kubernetes Controller Manager Yes Kubernetes CoreDNS Yes Kubernetes Etcd Yes Kubernetes Kubelet Yes Kubernetes Proxy Yes Kubernetes Scheduler Yes K8s cAdvisor Dashboards PromQL Notes K8s cAdvisor full Dashboards PromQL Notes cAdvisor Yes Kubernetes Dashboards PromQL Notes CPU Allocation Optimization No Deprecated Cluster / Namespace Available Resources Yes Cluster Capacity Planning Yes Cluster Overview No Deprecated Cluster and Node Capacity No Deprecated Container Resource Usage \u0026amp; Troubleshooting Yes DaemonSet Overview No Deprecated Deployment Overview No Deprecated Health Overview No Deprecated Horizontal Pod Autoscaler Yes Horizontal Pod Autoscaler (legacy) No Deprecated Job Overview No KSM Cluster / Namespace Available Resources Yes KSM Container Resource Usage \u0026amp; Troubleshooting Yes KSM Pod Status \u0026amp; Performance Yes KSM Workload Status \u0026amp; Performance Yes Kubernetes Jobs Yes Memory Allocation Optimization No Deprecated Namespace Overview No Deprecated Node Overview No Deprecated Node Status \u0026amp; Performance Yes PVC and Storage Yes Pod Overview No Deprecated Pod Rightsizing \u0026amp; Workload Capacity Optimization Yes Pod Scheduling Troubleshooting Yes Pod Status \u0026amp; Performance Yes ReplicaSet Overview No Deprecated Resource Quota No Deprecated Service Golden Signals No Deprecated Service Health No Deprecated StatefulSet Overview No Deprecated Workload Status \u0026amp; Performance Yes Workloads CPU Usage and Allocation No Deprecated Workloads Memory Usage and Allocation No Deprecated Marathon Dashboards PromQL Notes Applications No Groups No Master Node No Overview No Mesos Dashboards PromQL Notes Frameworks No Master Node No Overview No Slave Node No Tasks No OpenShift Dashboards PromQL Notes OpenShift HAProxy Ingress Overview Yes OpenShift HAProxy Ingress Service Details Yes OpenShift v3 API Server Yes OpenShift v3 Controller Manager Yes OpenShift v3 Kubelet Yes OpenShift v4 State Metrics Yes OpenShift Control Plane Dashboards PromQL Notes OpenShift v4 API Server Yes OpenShift v4 Controller Manager Yes OpenShift v4 CoreDNS Yes OpenShift v4 Etcd Yes OpenShift v4 Kubelet Yes OpenShift v4 Scheduler Yes Rancher RKE Control Plane Dashboards PromQL Notes Rancher RKE API Server Yes Rancher RKE Controller Manager Yes Rancher RKE CoreDNS Yes Rancher RKE Proxy Yes Rancher RKE Scheduler Yes Rancher RKE2 Control Plane Dashboards PromQL Notes Rancher RKE2 API Server Yes Rancher RKE2 Controller Manager Yes Rancher RKE2 CoreDNS Yes Rancher RKE2 Etcd Yes Rancher RKE2 Kube Proxy Yes Rancher RKE2 Scheduler Yes Sysdig Cost Dashboards PromQL Notes Cluster Cost Overview Yes Cluster Metrics Showcase Yes Workload Cost Metrics Showcase Yes Workload Cost Overview Yes Sysdig Monitor Dashboards PromQL Notes Agents and Jobs Time Series Yes New Time Series Usage Yes Sysdig Agent Health \u0026amp; Status Yes Time Series Usage Yes Sysdig Secure Dashboards PromQL Notes Serverless Agents Fargate Usage No Sysdig Admission Controller Yes Troubleshooting Dashboards PromQL Notes MongoDB Troubleshooting Yes Network Connections Table No Process Resource Usage No SQL Troubleshooting No Top Processes No ","url":"https://docs.sysdig.com/en/sysdig-monitor/dashboard-templates/"},{"id":232,"title":"Linux Agent Release Notes","content":" Deprecation Notice Support Ended\nKernel Support Policy\nThe minimum supported Linux kernel version is 3.10.\nUsers running older kernel versions should plan to upgrade to maintain compatibility and support.\nEnd of Support for Python 2.7\nTo enhance security, stability, and performance, support for Python 2.7 has been discontinued. Python 2.7 reached its official End of Life in January 2020. Sysdig recommends updating to a supported Python version. Deprecation of Custom App Checks\nTo improve Sysdig Monitor’s functionality and streamline integrations, Sysdig has now sunset Custom App Checks.\nSysdig strongly recommends transitioning to Monitoring Integrations for better performance and support.\nStarting from version 13.9.0, the new Linux Host Shield release notes will be available on Linux Host Shield Release Notes page.\n13.9.0 May 1, 2025See Linux Host Shield Release Notes\n13.8.1 March 25, 2025 Supported sysdig-deploy version: 1.78.7 Supported Falco Engine version: 1000.39.0 Supported Shield: 1.0.0 EnhancementsAgent Local ForwardingAdded support for SASL/PLAIN and SASL/SCRAM authentication for Kafka. See Event Forwarding to Kafka\nVulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2024-56171 CVE-2025-22868 CVE-2025-22869 CVE-2025-22870 CVE-2025-24928 Defect FixesFixed jq Error Messages in Standard OutputFixed an issue causing jq errors being printed on stderr.\n13.8.0 February 20, 2025 Supported sysdig-deploy version: 1.77.0 Supported Falco Engine version: 1000.39.0 EnhancementsImproved Monitoring for Horizontal Pod AutoscalersAdded kube_hpa_status_condition metric to provide visibility into the status conditions of Kubernetes Horizontal Pod Autoscalers (HPA). This helps you to track scaling decisions and overall HPA health.\nNew Configuration Option for Remote Filesystem StatisticsThe new configuration option in the Linux Agent: remotefs_stats.enabled controls whether filesystem operation and traffic statistics are collected for each mount entry. By default, it is set to true. Additionally, the Agent now limits the collection of these statistics exclusively to remote mount points, ensuring more targeted data reporting.\nCollector Connection Configuration Added to Host ShieldYou can now specify the connection information for the Sysdig collector in the host-shield.yaml file as follows:\nsysdig_endpoint: collector: host: \u0026lt;host\u0026gt; port: \u0026lt;port\u0026gt; Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2024-45341 CVE-2024-45336 CVE-2024-12797 CVE-2022-49043 CVE-2020-11023 CVE-2019-12900 Defect fixes Fixed an issue where compiling the kernel module failed on recent distributions, such as Fedora 40, which uses GCC 14. The application now verifies FIPS support during execution. Fixed an issue where suppressed process exit events could result in unexpected resource accumulation. This update ensures proper resource cleanup and improves memory efficiency. 13.7.2 January 17, 2025 Supported sysdig-deploy version: 1.74.1 Supported Falco Engine version: 1000.36.0 Vulnerability FixesThis hotfix addresses the following security vulnerability:\nCVE-2024-45338 Defect FixesFixed a defect that could prevent the scan result from generating when the host has a large number of kernels installed.\n","url":"https://docs.sysdig.com/en/release-notes/linux-agent-release-notes/"},{"id":233,"title":"Linux Host","content":" In the Linux Host page of Advisor, different tabs appear depending on the current level in the Scope Tree: Non-clustered hosts, or in a specific Linux Host.\nNon-clustered hosts Host Overview ✅ ✅ Advisories ✅ ✅ Alerts ✅ ✅ Events ✅ ✅ Disk ❌ ✅ Network ❌ ✅ Processes ❌ ✅ Each tab provides a wealth of information relevant to different parts of your infrastructure:\nAll Non-Clustered Hosts Overview: A high level summary of your Linux Hosts status. Number of hosts, resource usage in a per-host basis, and a summary of all the advisories happening in the Linux Hosts. Advisories: See the key problems in your Linux Hosts and how to resolve them. For more detail, see Advisories. Alerts: Triggered alerts. Events: Events from your Linux Host. One Specific Linux Host Overview: A high level summary of your Linux Hosts status. Number of hosts, resource usage in a per-host basis, and a summary of all the advisories happening in the Linux Hosts. Advisories: See the key problems in your Linux Hosts and how to resolve them. For more detail, see Advisories. Alerts: Triggered alerts. Events: Events from your Linux Host. Processes: A list of running processes, group by different categories: CPU, Memory, IO. Disk: Disk usage and throughput, running processes per file stat, and a disk usage forecast for the next 30 days. Network: Network activity in the host and connection information. AdvisoriesAdvisories evaluate the thousands of data points being sent by the Sysdig agent, and display a prioritized view of key problems in your infrastructure that affect the health and availability of your Linux Hosts.\nWhen you select an advisory, relevant information related to the issue is surfaced, such as metrics and events. This enables you to pinpoint and resolve problems faster.\nExample Issues Detected Problem\nDescription\nHigh CPU usage\nCPU usage is hitting over 80% for the last hour.\nMemory Pressure\nMemory usage is hitting over 80% for the last hour.\nDisk will be full soon\nDisk usage is hitting 90% over the last hour.\nNetwork Errors\nHigh number of network errors detected on the host.\nAdvisories are automatically resolved when the problem is no longer detected.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/linux-host/"},{"id":234,"title":"Serverless Malware Detection","content":"The Sysdig Serverless Workload Agent provides runtime security for serverless on AWS Fargate. With Serverless Malware Detection, you can detect and alert on malicious files, scripts, and anomalous activity directly within your serverless containers.\nThreat actors often target container workloads to drop malicious binaries, spawn unauthorized processes, or run covert cryptominers. Leveraging Malware Detection gives your security teams the critical visibility needed to investigate these threats, streamline incident response, and uphold regulatory compliance standards.\nTo optimize performance and give you granular control over your deployment, Serverless Malware Detection is disabled by default.\nPrerequisitesBefore enabling Serverless Malware Detection, ensure you have:\nAn active Sysdig Secure account. The Sysdig Serverless Workload Agent instrumented in your serverless environment. The necessary IAM roles and permissions to update your container environment variables. Enable Malware DetectionYou can enable and configure Serverless Malware Detection by using the SYSDIG_EXTRA_CONF environment variable within your workload agent container definition.\nTo turn on malware scanning, provide the configuration options under the malware_control heading.\nConfiguration Parameters Option Default Description enabled false Determines whether the malware detection feature is active. Set to true to enable runtime malware detection for the Serverless Workload Agent. Configuration ExampleYou can append the malware control settings to your existing SYSDIG_EXTRA_CONF variable or create it if you are not currently using it.\nTo enable the feature, pass the following string to the SYSDIG_EXTRA_CONF environment variable in your task definition:\nSYSDIG_EXTRA_CONF=\u0026#39;{\u0026#34;malware_control\u0026#34;: {\u0026#34;enabled\u0026#34;: true}}\u0026#39; ","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-malware-detection/"},{"id":235,"title":"Manage Alerts","content":"The columns of the table can also be configured, to provide you with the necessary data for your use cases.\nSelect a group of alerts and perform several batch operations, such as filtering, deleting, enabling, disabling, or exporting to a JSON object. Select individual alerts to perform tasks such as creating a copy for a different team.\nView Alert DetailsThe bell button next to an alert indicates that you have not resolved the corresponding events. The Activity Over Last Two Weeks column visually notifies you with an event chart showing the number of events that were triggered over the last two weeks. The color of the event chart represents what severity level they are.\nTo view alert details, click the corresponding alert row. The slider with the alert details will appear. Click an individual event to Take Action. You can do one of the following:\nAcknowledge: Mark that the event has been acknowledged by the intended recipient.\nCreate Silence from Event: If you no longer want to be notified, use this option. You can choose the scope for alert silence. When silenced, alerts will still be triggered but will not send you any notifications.\nExplore: Use this option to troubleshoot by using the PromQL Query Explorer.\nThe event feed will be empty and The Activity Over Last Two Weeks column will have no event chart if no events are reported in the past two weeks.\nEnable and Disable AlertsAlert UIAlerts can be enabled or disabled using the slider or the customization bar. You can perform these operations on a single alert or on multiple alerts as a batch operation.\nFrom the Alerts module, check the boxes beside the relevant alerts.\nClick Enable Selected or Disable Selected as necessary.\nUse the slider beside the alert to disable or enable individual alerts.\nAutomatic DisablingSysdig automatically disables an alert in the following conditions:\nAlert has more than 10K segments.\nThe segmentation limit for an alert is limited to 10K. Any alert that exceeds this limit will be automatically disabled.\nAlert has accumulated more than 2000 alert notifications per day.\nIn these scenarios:\nAlert notifications will not be resolved when the alert is deactivated.\nAn event is generated notifying about the alert deactivation.\nFor more information, see Service Limits.\nManual Alert ResolutionAlerts can be manually resolved when the triggering entity no longer exists or simply to clean up the triggering alerts occurrences from the environment. You can do it in the following ways:\nFrom the Alerts page, all of the triggering segments for a given alert rule can be manually resolved. You can also bulk select multiple alerts rules and resolve all the alert occurrences for multiple alert rules.\n​ From the Events page, a single triggering segment can be manually resolved using the Take Action button. To do so, click the relevant event and select Take Action \u0026gt; Manually Resolve.\n​ Manually resolved alerts will still be evaluated after the resolution and if the alert condition is true, will return to a firing state.\nEdit an Existing AlertTo edit an existing alert:\nDo one of the following::\nClick the Edit button beside the alert.\nClick an alert to open the detail view, then click Edit on the top right corner.\nEdit the alert, and click Save to confirm the changes.\nCopy an AlertAlerts can be copied within the current team to allow for similar alerts to be created quickly, or copied to a different team to share alerts.\nCopy an Alert to the Current TeamTo copy an alert within the current team:\nSelect the alert to be copied.\nThe detail view is displayed.\nClick the Copy icon.\nThe Copy to team modal is displayed.\nSelect Current from the drop-down.\nClick Copy and Open.\nThe particular alert in the edit mode appears.\nMake necessary changes and save the alert.\nCopy an Alert to a Different Team Select the alert to be copied.\nThe detail view is displayed.\nClick the Copy icon.\nThe Copy to team screen is displayed.\nSelect the teams that the alert should be copied to.\nClick Send Copy.\nSearch for an AlertSearch Using StringsThe Alerts table can be searched using partial or full strings. For example, the search below displays only events that contain kubernetes:\nFilter AlertsThe alert feed can be filtered in multiple ways, to drill-down into the environment\u0026rsquo;s history and refine the alert displayed. The feed can be filtered by severity or status. Examples of each are shown below.\nThe example below shows only high and medium severity:\nExport Alerts as JSONA JSON file can be exported to a local machine, containing JSON snippets for each selected alert:\nClick the checkboxes beside the relevant alerts to be exported.\nClick Export JSON.\nDelete AlertsOpen the Alert page and use one of the following methods to delete alerts :\nHover on a specific alert and click Delete.\nHover on one or more alerts, click the checkbox, then click Delete on the bulk-action toolbar.\nClick an alert to see the detailed view, then click Delete on the top right corner.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/manage-alerts/"},{"id":236,"title":"Manage Posture Policies","content":"With Posture policies, you can:\nClone an existing policy and edit its metadata. Create, edit, and delete a custom policy. Create, edit, and delete requirements in a custom policy. Link and unlink available controls to policy requirements. In most cases, you might want to:\nStart from an existing policy Create or edit some requirements Link or unlink some controls Optionally create and link custom controls Save under a new name Connect the policy to a zone The process of policy creation is separate from activation, so you can take your time to design your policy as needed.\nReview a PolicyTo review a policy:\nLog in to Sysdig Secure.\nSelect Policies \u0026gt; Posture Policies.\nSelect a policy from the list to open a detailed page.\nSelect Requirements \u0026amp; Controls to view requirement groups and the nested requirements to which the controls are linked.\nFrom the right detail panel, you can enable or disable individual controls within a policy. The control will be enabled or disabled for only the targeted policy.\nUse the search bar, and filters to find specific controls. For details, see Search and Filter the List.\nCreate a Custom PolicyThere are two ways to create a policy:\nCreate a Policy from a Duplicate Create a Policy from Scratch Create a Policy from a Duplicate Log in to Sysdig Secure and Policies \u0026gt; Posture Policies.\nTo create a Policy from a duplicate, either:\nClick New Policy and select an existing policy name from the resulting drop-down, OR Select Duplicate from the three-dot menu next to a listed policy. To create a Policy from scratch:\nClick New Policy and in the Duplicate from dropdown, select None, start from scratch. Edit the Name and Description and click Save.\nFor duplicate policies, add, delete, or edit requirement groups and requirements, link or unlink existing controls, publish, and choose a zone.\nFor custom policies, create the requirement groups and requirements you want to use and manually link controls to them.\nSee Create Requirement Groups and Requirements.\nCreate Requirement Groups and RequirementsIn a custom policy, requirement groups and requirements can be removed or edited and new ones can be created and added. Requirements and groups are not shared between policies; to reuse a requirement from another policy, you must create a new group and requirement and then link the controls desired.\nSelect a policy.\nOn the policy page, click New Group.\nEnter the requirement group name and description and click Save.\nThe group name appears in the left panel.\nOptionally, add a subgroup.\nSelect a requirement group that you have created and click the three-dot menu. Select New Subgroup. Enter the Subgroup name and description Click Save. Add a requirement: Select a group or subgroup, click the 3-dot menu, and select New Requirement.\nEnter the Requirement name and description and click Save.\nYou can now link controls to your requirements.\nLink and Unlink ControlsOnce you have a requirement group and requirement, the Link Controls button is active.\nSelect a requirement within a requirement group in your policy.\nClick Link Controls in the right panel. All available controls are displayed, with the top 20 listed first.\nFilter for the desired controls by Type and Target.\nSelect the desired control and click Link. Repeat as needed.\nTo unlink, from the list of linked controls, hover over a control to reveal the Unlink option and click it.\nIf the policy has already been published, confirm that you want this control to no longer be evaluated by clicking Yes, Unlink. This action triggers a policy re-evaluation.\nPublish the PolicyWhen your custom policy is complete, click the Publish button at the top of the policy draft page and confirm. The Date Published is displayed from the moment of activation.\nAfter publication, any policy edit triggers a re-evaluation and fresh results are listed in the Compliance Views after a few minutes.\nLink the Policy to a ZoneBy default, newly created policies are not assigned to any zone. To see compliance results evaluated by the policy on the [Resources(en/sysdig-secure/inventory-resources/#navigate-the-resources-page) page, assign a zone to the policy.\nTo apply the policy to a zone:\nLog in to Sysdig Secure.\nSelect Policies \u0026gt; Posture Policies.\nSelect a policy from the list.\nThe Policy Detail page appears.\nIn the top right corner, select the three-dot menu icon.\nSelect Edit.\nBeside Assigned Zones, select Add Zones and apply the desired zones from the drop-down.\nClick Save.\nThe policy updates with the new zone assignment.\nIf you do not have a zone, see Create and Configure a Zone.\nFilter Linked ControlsLinked controls are filtered the same way on both the Policy page and Controls page.\nFor more information, see Filter the list.\nEdit Custom PoliciesFor custom policies, you can edit:\nPolicy name and description Requirement group and requirement names, descriptions Add/remove requirement groups and/or requirements Link and unlink controls Activated or deactivated status All such changes trigger a policy re-evaluation if the policy is active.\nDelete Custom PoliciesDeleting an active policy deletes its history of policy evaluations as well.\nSelect a custom policy.\nClick the three-dot menu icon in the top right corner.\nSelect Delete.\nAt the confirmation modal, select Yes to delete.\nA re-evaluation is triggered if the policy is active.\nRefresh Compliance Views to see the results.\nDelete RequirementsDeleting a requirement group or requirement from a policy also deletes all associations with linked controls.\nSelect a requirement group, subgroup, or requirement in a custom policy. From the three-dot menu, choose the Delete option and confirm Yes, Delete after the warning. A policy re-evaluation is triggered if the policy is active. Refresh Compliance Views to see the results.\n","url":"https://docs.sysdig.com/en/sysdig-secure/manage_posture_policies/"},{"id":237,"title":"Manage Users","content":" Users added in Sysdig Monitor will appear in the full list of users for both Sysdig Monitor and Sysdig Secure if both products are in use. However, users will not have login access to Sysdig Secure until they are added to a Sysdig Secure team.\nPrerequisitesOnly Admin users can configure user account information.\nFor on-premises environments, you may need to have pre-configured your SMTP parameters in your Kubernetes installation configmap.\nCreate a User Log in to Sysdig Monitor or Sysdig Secure as administrator.\nSelect Settings from the user menu.\nSelect Users.\nClick Add User.\nEnter the new user\u0026rsquo;s email address, first name, and last name:\nClick Save to send the user an invitation via email.\nThe new user appears in the list visible in the Users tab. Their status is listed as Pending until the invitation is accepted.\nEdit User InformationOnce you have added a user, you can edit their information to assign roles, teams, and permissions.\nAdmin privileges cannot be assigned until the invitation has been accepted, and the user has logged into the interface for the first time. They can, however, be added to additional teams or have team-based roles assigned. For more information on configuring teams roles, refer to Manage Teams and Roles.\nTo edit an existing user:\nLog in to Sysdig Monitor or Sysdig Secure as administrator and select Settings from the user menu.\nSelect Users.\nSelect the user from the table of users.\nOptional: Edit the first name / last name.\nOptional: Toggle the Admin switch to enable/disable administrator privileges.\nOptional: Disable the Authenticator App MFA switch to allow users to login if they lost access to the authenticator app.\nYou can not enable the MFA for a user. Each user must activate the MFA themselves.\nClick Save to save the changes or Cancel to revert the unsaved changes. User emails are read-only, and cannot be changed.\nBreak-Glass scenarioBreak-glass scenario implies a situation in which the IdP has stopped processing user requests for whatever reason and you need to regain access to Sysdig.\nSysdig allows you to Disable Password Authentication, while providing the ability to access the system with username and password in a break-glass scenario.\nUsers with Break-glass account enabled will be able to login using username and password even if Password Authentication is disabled. The prerequisite is to set the password for the account to allow the login.\nUser DeactivationDeactivating inactive users is a recommended security practice, aimed at reducing attack surface and the potential for insider threats and privilege escalation. Sysdig Platform Administrators can deactivate and reactivate users manually through the UI or set up automatic deactivation after a defined period of inactivity via API. Inactivity is measured by a lack of interactive access, such as UI logins.\nThis feature is disabled by default and can only be enabled via the API.\nDeactivate and Reactivate Users ManuallyAs an Admin, you can deactivate and reactivate users manually through the Sysdig UI:\nLog in to Sysdig Secure or Monitor as an Admin.\nFrom the user menu in the bottom left corner, navigate to Settings.\nSelect Users.\nSelect a user from the users list.\nThe user configuration page appears.\nToggle User Enabled off to deactivate, and on to reactivate the user.\nSelect Save to confirm your changes.\nAutomatically Deactivate UsersAdmins can configure Sysdig to automatically deactivate a user after a period of inactivity defined by you via API:\nLog in to Sysdig Secure or Monitor as an Admin.\nGather your API bearer token. This is required to execute API calls.\nFrom the user menu in the bottom left corner, select Next Gen API Docs.\nIn the API documentation, navigate to the User Deactivation section.\nUser the schema provided to build your payload.\nReactivate a UserTo reactivate a user:\nIf SSO (either SAML or OIDC) is enabled, the user will be automatically reactivated when using SSO for logging in. If SSO is not enabled, the user should contact their Admin. To reactive a user as an Admin, see Deactivate and Reactivate Users Manually. Delete a UserTo delete an existing user:\nDeleting a user cannot be undone.\nLog in to Sysdig Monitor or Sysdig Secure as administrator and select Settings from the user menu. `\nSelect Users.\nSelect the user from the table of users.\nClick Delete User.\nClick Yes, delete to confirm the change.\nYou can optionally delete the dashboards and artifacts that the user have created.\n","url":"https://docs.sysdig.com/en/administration/users-administration/"},{"id":238,"title":"Manage Vulnerability Exceptions and Global Lists","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nSysdig Secure allows users to add specific CVEs to Global Exception lists. Common reasons to exempt a vulnerability from consideration while scanning an image include, for example:\nKnowing that the vuln does not apply to your runtime or cannot be exploited\nKnowing that the suggested \u0026ldquo;fix version\u0026rdquo; will break a chain of dependencies, and you plan to evaluate how to patch this vulnerability in more detail\nKnowing that there is no available fix for the vulnerability yet and you absolutely must deploy this application in production. (You decide to use a temporary alternate security strategy to protect from the vulnerability.)\nWhen devising exception lists, you can detail what exceptions you introduce, for which images, and for how long, establishing a vulnerability exception management workflow.\nAdditionally, specific images can be marked as untrusted or globally trusted to ensure they always/never pass a scan.\nPrevious versions of Sysdig Secure called this feature Whitelist and Blacklist, and the options were located under the Scanning Policies tab.\nCreate Multiple Exception ListsBy default, a single list is provided. Its name, Default exceptions list, can be retitled or removed if desired.\nTo create additional lists:\nSelect Image Scanning \u0026gt; Vulnerability Exceptions and click the Add button on the left side of the screen.\nEnter a Name and Description and click Save.\nHover over the info bubble on an existing list to see its name, description, and last-modified date.\nFor an exception list to be applied to an image during a scan, you must set up a scanning policy assignment to map the image to the list.\nIf you delete or rename an exception list, the modification will be also applied to the policy assignments that contain that list.\nAdd a Vulnerability to a ListThere are two ways to add a vulnerability to a list: from the Exceptions List page, or from the Scan Results.\nFrom the Exceptions List Page SelectImage Scanning \u0026gt; Vulnerability Exceptions and choose the desired list from the left menu. (In this example, the Exception list is named \u0026ldquo;Python exceptions\u0026rdquo;.)\nClick the Add button on the right side of the screen.\nEnter the identifying details:\nCVE ID: Required\nExpiration Date: Required, but can be \u0026rsquo;never'\nNote Optional.\nFrom the Scan ResultsThe scan results for an image may flag vulnerabilities you don\u0026rsquo;t consider necessary. From the results list, you can quickly append those entries to exception lists as follows:\nSelect Image Scanning \u0026gt; Scan Results.\nSelect the Vulnerability type from the left menu and review the resulting list of flagged vulnerabilities.\nNote: The Exceptions column displays the number of lists already containing this vulnerability.\nClick the hover button to open the \u0026ldquo;Add Exception\u0026rdquo; dialog .\nEnter the details and click Save.\nList: Sysdig will indicate with a \u0026ldquo;radar\u0026rdquo; icon the lists that are being applied to this image according to the policy assignments which are relevant for the evaluation of this particular image\nYou can also enter additional list names in the field to create a new list.\nExpiration Date: Required, but can be \u0026rsquo;never'\nNote Optional.\nManage Vulnerabilities in a ListAn exception list can contain any number of vulnerabilities. Each vulnerability listing displays additional properties to help the security team understand the context, feed sources, and the justification and time span for the vulnerability to be on the list.\nFields in the List ViewSelect Image Scanning \u0026gt; Vulnerability Exceptions and choose a list from the left menu to review the vulnerability list details.\nReview the column data:\nEnabled: On/off toggle for whether the exception for this vulnerability is active. If the vulnerability exception is disabled, it will not disappear from the list but will not be taken into account when evaluating an image. Rows that have met their expiration date are automatically disabled.\nName: String entered by the user to identify the vulnerability. For example, CVE-2019-9639 or VULNDB-213986.\nDescription: Vulnerability description, provided by Sysdig once the Vuln ID is provided by the user.\nNotes: User-defined exception notes. Could be used to justify the decision or to append any additional links or information.\nExpiration date: Day configured by the user for this exception to expire.\nDefault is never, for a vulnerability that should not expire. If an expiration is set, then day is the minimum time resolution.\nAll expiration dates are evaluated against 0:00 UTC timezone\nAccess and Edit Additional DetailsClick on an exception row to see additional details about the vulnerability and to edit its properties.\nYou can:\nView the full description\nView and modify user notes\nView and modify Expiration date\nDisabled exceptions cannot be re-enabled until a future date is set.\nView segmented feed information, for every feed that is reporting this vulnerability:\nSeverity of the vulnerability as reported per each individual feed (color-coded)\nLink to vulnerability details as provided per feed\nAdd Images to a Global ListThere are two ways to add images to a Global Trusted or Untrusted list: from the list or from a scan result.\nFrom the Global list:\nFrom the Image Scanning module, select either Global - Trusted Images or Global - Untrusted Images.\nThe list of previously added images is displayed.\nClick the Add Image button.\nAdd each image in a comma-separated list, then click Ok.\nA tag name must be valid ASCII and may contain lowercase and uppercase letters, digits, underscores, periods and dashes.\nA tag name may not start with a period or a dash and may contain a maximum of 128 characters.\nFrom the Scan Results:\nFrom the Image Scanning module, choose the Scan Results tab.\nSelect the relevant repository from the list and open the relevant image.\nClick Add to List at the top of the page.\nSelect either Add Image to Trusted Images or Add Image to Untrusted Images as needed.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/manage-scanning-policies/manage-vulnerability-exceptions-and-global-lists/"},{"id":239,"title":"Mapping Classic Metrics with Context-Specific PromQL Metrics","content":" Sysdig Classic Metrics Context-Specific Metrics in Prometheus Notation cpu.cores.used sysdig_container_cpu_cores_usedsysdig_host_cpu_cores_usedsysdig_program_cpu_cores_used cpu.cores.used.percent sysdig_container_cpu_cores_used_percentsysdig_host_cpu_cores_used_percentsysdig_program_cpu_cores_used_percent cpu.used.percent sysdig_container_cpu_used_percentsysdig_host_cpu_used_percentsysdig_program_cpu_used_percent fd.used.percent sysdig_container_fd_used_percentsysdig_host_fd_used_percentsysdig_program_fd_used_percent file.bytes.in sysdig_container_file_in_bytessysdig_host_file_in_bytessysdig_program_file_in_bytes file.bytes.out sysdig_container_file_out_bytessysdig_host_file_out_bytessysdig_program_file_out_bytes file.bytes.total sysdig_container_file_total_bytessysdig_host_file_total_bytessysdig_program_file_total_bytes file.error.open.count sysdig_container_file_error_open_countsysdig_host_file_error_open_countsysdig_program_file_error_open_count file.error.total.count sysdig_container_file_error_total_countsysdig_host_file_error_total_countsysdig_program_file_error_total_count file.iops.in sysdig_container_file_in_iopssysdig_host_file_in_iopssysdig_program_file_in_iops file.iops.out sysdig_container_file_out_iopssysdig_host_file_out_iopssysdig_program_file_out_iops file.iops.total sysdig_container_file_total_iopssysdig_host_file_total_iopssysdig_program_file_total_iops file.open.count sysdig_container_file_open_countsysdig_host_file_open_countsysdig_program_file_open_count file.time.in sysdig_container_file_in_timesysdig_host_file_in_timesysdig_program_file_in_time file.time.out sysdig_container_file_out_timesysdig_host_file_out_timesysdig_program_file_out_time file.time.total sysdig_container_file_total_timesysdig_host_file_total_timesysdig_program_file_total_time fs.bytes.free sysdig_container_fs_free_bytessysdig_fs_free_bytessysdig_host_fs_free_bytes fs.bytes.total sysdig_container_fs_total_bytessysdig_fs_total_bytessysdig_host_fs_total_bytes fs.bytes.used sysdig_container_fs_used_bytessysdig_fs_used_bytessysdig_host_fs_used_bytes fs.free.percent sysdig_container_fs_free_percentsysdig_fs_free_percentsysdig_host_fs_free_percent fs.inodes.total.count sysdig_container_fs_inodes_total_countsysdig_fs_inodes_total_countsysdig_host_fs_inodes_total_count fs.inodes.used.count sysdig_container_fs_inodes_used_countsysdig_fs_inodes_used_countsysdig_host_fs_inodes_used_count fs.inodes.used.percent sysdig_container_fs_inodes_used_percentsysdig_fs_inodes_used_percentsysdig_host_fs_inodes_used_percent fs.largest.used.percent sysdig_container_fs_largest_used_percentsysdig_host_fs_largest_used_percent fs.root.used.percent sysdig_container_fs_root_used_percentsysdig_host_fs_root_used_percent fs.used.percent sysdig_container_fs_used_percentsysdig_fs_used_percentsysdig_host_fs_used_percent host.error.count sysdig_container_syscall_error_countsysdig_host_syscall_error_count info sysdig_agent_infosysdig_container_infosysdig_host_info memory.bytes.total sysdig_host_memory_total_bytessysdig_container_memory_used_bytessysdig_host_memory_used_bytessysdig_program_memory_used_bytes memory.bytes.virtual sysdig_container_memory_virtual_bytessysdig_host_memory_virtual_bytes memory.swap.bytes.used sysdig_container_memory_swap_used_bytessysdig_host_memory_swap_used_bytes memory.used.percent sysdig_container_memory_used_percentsysdig_host_memory_used_percent net.bytes.in sysdig_connection_net_in_bytessysdig_container_net_in_bytessysdig_host_net_in_bytessysdig_program_net_in_bytes net.bytes.out sysdig_connection_net_out_bytessysdig_container_net_out_bytessysdig_host_net_out_bytessysdig_program_net_out_bytes net.bytes.total sysdig_connection_net_total_bytessysdig_container_net_total_bytessysdig_host_net_total_bytessysdig_program_net_total_bytes net.connection.count.in sysdig_connection_net_connection_in_countsysdig_container_net_connection_in_countsysdig_host_net_connection_in_countsysdig_program_net_connection_in_count net.connection.count.out sysdig_connection_net_connection_out_countsysdig_container_net_connection_out_countsysdig_host_net_connection_out_countsysdig_program_net_connection_out_count net.connection.count.total sysdig_connection_net_connection_total_countsysdig_container_net_connection_total_countsysdig_host_net_connection_total_countsysdig_program_net_connection_total_count net.request.count sysdig_connection_net_request_countsysdig_container_net_request_countsysdig_host_net_request_countsysdig_program_net_request_count net.error.count sysdig_container_net_error_countsysdig_host_net_error_countsysdig_program_net_error_count net.request.count.in sysdig_connection_net_request_in_countsysdig_container_net_request_in_countsysdig_host_net_request_in_countsysdig_program_net_request_in_count net.request.count.out sysdig_connection_net_request_out_countsysdig_container_net_request_out_countsysdig_host_net_request_out_countsysdig_program_net_request_out_count net.request.time sysdig_connection_net_request_timesysdig_container_net_request_timesysdig_host_net_request_timesysdig_program_net_request_time net.request.time.in sysdig_connection_net_request_in_timesysdig_container_net_request_in_timesysdig_host_net_request_in_timesysdig_program_net_request_in_time net.request.time.out sysdig_connection_net_request_out_timesysdig_container_net_request_out_timesysdig_host_net_request_out_timesysdig_program_net_request_out_time net.server.bytes.in sysdig_container_net_server_in_bytessysdig_host_net_server_in_bytes net.server.bytes.out sysdig_container_net_server_out_bytessysdig_host_net_server_out_bytes net.server.bytes.total sysdig_container_net_server_total_bytessysdig_host_net_server_total_bytes net.sql.error.count sysdig_container_net_sql_error_countsysdig_host_net_sql_error_count net.sql.request.count sysdig_container_net_sql_request_countsysdig_host_net_sql_request_count net.tcp.queue.len sysdig_container_net_tcp_queue_lensysdig_host_net_tcp_queue_lensysdig_program_net_tcp_queue_len proc.count sysdig_container_proc_countsysdig_host_proc_countsysdig_program_proc_count thread.count sysdig_container_thread_countsysdig_host_thread_countsysdig_program_thread_count uptime sysdig_container_upsysdig_host_upsysdig_program_up ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics-and-labels-mapping/mapping-classic-metrics-with-context-specific-promql-metrics/"},{"id":240,"title":"Mapping Classic Metrics with PromQL Metrics","content":" Entity\nType\nPromQL Metric Name\nClassic Metric Name\nLabel\nClassic Label\nhost\ninfo\nsysdig_host_info\nNot exposed\nhost_mac\nhost_hostname\ninstance_id\nagent_tag_{*}\nhost.mac\nhost.hostName\nhost.instanceId\nagent.tag.{*}\nsysdig_cloud_provider_info\nhost_mac\ncloud_provider_provider_id\ncloud_provider_account_id\ncloud_provider_region\ncloud_provider_availability_zone\ncloud_provider_instance_type\ncloud_provider_tag_{*}\ncloud_provider_security_groups\ncloud_provider_host_ip_public\ncloud_provider_host_ip_private\ncloud_provider_host_name\ncloud_provider_name\nhost.mac\ncloudProvider.id\ncloudProvider.account.id\ncloudProvider.region\ncloudProvider.availabilityZone\ncloudProvider.instance.type\ncloudProvider.tag.{*}\ncloudProvider.securityGroups\ncloudProvider.host.ip.public\ncloudProvider.host.ip.private\ncloudProvider.host.name\ncloudProvider.name\ndata\nsysdig_host_cpu_used_percent\ncpu.used.percent\nhost_mac\nhost_hostname\nhost.mac\nhost.hostname\nsysdig_host_cpu_cores_used\ncpu.cores.used\nsysdig_host_cpu_user_percent\ncpu.user.percent\nsysdig_host_cpu_idle_percent\ncpu.idle.percent\nsysdig_host_cpu_iowait_percent\ncpu.iowait.percent\nsysdig_host_cpu_nice_percent\ncpu.nice.percent\nsysdig_host_cpu_stolen_percent\ncpu.stolen.percent\nsysdig_host_cpu_system_percent\ncpu.system.percent\nsysdig_host_fd_used_percent\nfd.used.percent\nsysdig_host_file_error_open_count\nfile.error.open.count\nsysdig_host_file_error_total_count\nfile.error.total.count\nsysdig_host_file_in_bytes\nfile.bytes.in\nsysdig_host_file_in_iops\nfile.iops.in\nsysdig_host_file_in_time\nfile.time.in\nsysdig_host_file_open_count\nfile.open.count\nsysdig_host_file_out_bytes\nfile.bytes.out\nsysdig_host_file_out_iops\nfile.iops.out\nsysdig_host_file_out_time\nfile.time.out\nsysdig_host_load_average_15m\nload.average.15m\nsysdig_host_load_average_1m\nload.average.1m\nsysdig_host_load_average_5m\nload.average.5m\nsysdig_host_memory_available_bytes\nmemory.bytes.available\nsysdig_host_memory_total_bytes\nmemory.bytes.total\nsysdig_host_memory_used_bytes\nmemory.bytes.used\nsysdig_host_memory_swap_available_bytes\nmemory.swap.bytes.available\nsysdig_host_memory_swap_total_bytes\nmemory.swap.bytes.total\nsysdig_host_memory_swap_used_bytes\nmemory.swap.bytes.used\nsysdig_host_memory_virtual_bytes\nmemory.bytes.virtual\nsysdig_host_net_connection_in_count\nnet.connection.count.in\nsysdig_host_net_connection_out_count\nnet.connection.count.out\nsysdig_host_net_error_count\nnet.error.count\nsysdig_host_net_in_bytes\nnet.bytes.in\nsysdig_host_net_out_bytes\nnet.bytes.out\nsysdig_host_net_tcp_queue_len\nnet.tcp.queue.len\nsysdig_host_proc_count\nproc.count\nsysdig_host_system_uptime\nsystem.uptime\nsysdig_host_thread_count\nthread.count\ncontainer\ninfo\nsysdig_container_info\nNot exposed\ncontainer_id\ncontainer.id\ncontainer_full_id\nnone\nhost_mac\nhost.mac\ncontainer_name\ncontainer.name\ncontainer_type\ncontainer.type\ncontainer_image\ncontainer.image\ncontainer_image_id\ncontainer.image.id\ncontainer_mesos_task_id\ncontainer.mesosTaskId\nOnly available in Mesos orchestrator.\nkube_cluster_name\nkubernetes.cluster.name\nPresent only if the container is part of Kubernetes.\nkube_pod_name\nkubernetes.pod.name\nPresent only if the container is part of Kubernetes\nkube_namespace_name\nkubernetes.namespace.name\nPresent only if the container is part of Kubernetes.\ndata\nsysdig_container_cpu_used_percent\ncpu.used.percent\nhost_mac\ncontainer_id\ncontainer_type\ncontainer_name\nhost.mac\ncontainer.id\ncontainer.type\ncontainer.name\nsysdig_container_cpu_cores_used\ncpu.cores.used\nsysdig_container_cpu_cores_used_percent\ncpu.cores.used.percent\nsysdig_container_cpu_quota_used_percent\ncpu.quota.used.percent\nsysdig_container_cpu_shares\ncpu.shares.count\nsysdig_container_cpu_shares_used_percent\ncpu.shares.used.percent\nsysdig_container_fd_used_percent\nfd.used.percent\nsysdig_container_file_error_open_count\nfile.error.open.count\nsysdig_container_file_error_total_count\nfile.error.total.count\nsysdig_container_file_in_bytes\nfile.bytes.in\nsysdig_container_file_in_iops\nfile.iops.in\nsysdig_container_file_in_time\nfile.time.in\nsysdig_container_file_open_count\nfile.open.count\nsysdig_container_file_out_bytes\nfile.bytes.out\nsysdig_container_file_out_iops\nfile.iops.out\nsysdig_container_file_out_time\nfile.time.out\nsysdig_container_memory_limit_bytes\nmemory.limit.bytes\nsysdig_container_memory_limit_used_percent\nmemory.limit.used.percent\nsysdig_container_memory_swap_available_bytes\nmemory.swap.bytes.available\nsysdig_container_memory_swap_total_bytes\nmemory.swap.bytes.total\nsysdig_container_memory_swap_used_bytes\nmemory.swap.bytes.used\nsysdig_container_memory_used_bytes\nmemory.bytes.used\nsysdig_container_memory_virtual_bytes\nmemory.bytes.virtual\nsysdig_container_net_connection_in_count\nnet.connection.count.in\nsysdig_container_net_connection_out_count\nnet.connection.count.out\nsysdig_container_net_error_count\nnet.error.count\nsysdig_container_net_in_bytes\nnet.bytes.in\nsysdig_container_net_out_bytes\nnet.bytes.out\nsysdig_container_net_tcp_queue_len\nnet.tcp.queue.len\nsysdig_container_proc_count\nproc.count\nsysdig_container_swap_limit_bytes\nswap.limit.bytes\nsysdig_container_thread_count\nthread.count\nProcess/ Program\nInfo\nsysdig_program_info\nnot exposed\nprogram_name\nproc.name\nprogram_cmd_line\nproc.commandLine\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\ndata\nsysdig_program_cpu_used_percent\ncpu.used.percent\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nprogram_name\nproc.name\nprogram_cmd_line\nproc.commandLine\nsysdig_program_memory_used_bytes\nmemory.bytes.used\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nprogram_name\nproc.name\nprogram_cmd_line\nproc.commandLine\nsysdig_program_net_in_bytes\nnet.bytes.in\ncontainer_id\ncontainer.id\nhost_mac\nhost.mac\ncontainer_type\ncontainer.type\nprogram_name\nproc.name\nprogram_cmd_line\nproc.commandLine\nsysdig_program_net_out_bytes\nnet.bytes.out\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nprogram_name\nproc.name\nprogram_cmd_line\nproc.commandLine\nsysdig_program_proc_count\nproc.count\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nprogram_name\nproc.name\nprogram_cmd_line\nproc.commandLine\nsysdig_program_thread_count\nthread.count\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nprogram_name\nproc.name\nprogram_cmd_line\nproc.commandLine\nfs\ninfo\nsysdig_fs_info\nnot exposed\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nfs_device\nfs.device\nfs_mount_dir\nfs.mountDir\nfs_type\nfs.type\ndata\nsysdig_fs_free_bytes\nfs.bytes.free\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nfs_device\nfs.device\nsysdig_fs_inodes_total_count\nfs.inodes.total.count\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nfs_device\nfs.device\nsysdig_fs_inodes_used_count\nfs.inodes.used.count\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nfs_device\nfs.device\nsysdig_fs_total_bytes\nfs.bytes.total\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nfs_device\nfs.device\nfs.bytes.used\nhost_mac\nhost.mac\ncontainer_id\ncontainer.id\ncontainer_type\ncontainer.type\nfs_device\nfs.device\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metrics-and-labels-mapping/mapping-classic-metrics-with-promql-metrics/"},{"id":241,"title":"Metrics Available in Monitor Light","content":" Sysdig Legacy ID Prometheus ID cpu.cores.used sysdig_host_cpu_cores_usedsysdig_container_cpu_cores_usedsysdig_program_cpu_cores_used cpu.cores.used.percent sysdig_host_cpu_cores_used_percentsysdig_container_cpu_cores_used_percentsysdig_program_cpu_cores_used_percent cpu.idle.percent sysdig_host_cpu_idle_percent cpu.iowait.percent sysdig_host_cpu_iowait_percent cpu.nice.percent sysdig_host_cpu_nice_percent cpu.stolen.percent sysdig_host_cpu_stolen_percent cpu.system.percent sysdig_host_cpu_system_percent cpu.used.percent sysdig_host_cpu_used_percentsysdig_container_cpu_used_percentsysdig_program_cpu_used_percent cpu.user.percent sysdig_host_cpu_user_percent load.average.percpu.1m sysdig_host_load_average_percpu_1m load.average.percpu.5m sysdig_host_load_average_percpu_5m load.average.percpu.15m sysdig_host_load_average_percpu_15m memory.bytes.available sysdig_host_memory_available_bytes memory.bytes.total sysdig_host_memory_total_bytes memory.bytes.used sysdig_host_memory_used_bytessysdig_container_memory_used_bytessysdig_program_memory_used_bytes memory.bytes.virtual sysdig_host_memory_virtual_bytessysdig_container_memory_virtual_bytessysdig_program_memory_virtual_bytes memory.pageFault.major None memory.pageFault.minor None memory.swap.bytes.available sysdig_host_memory_swap_available_bytes memory.swap.bytes.total sysdig_host_memory_swap_total_bytes memory.swap.bytes.used sysdig_host_memory_swap_used_bytes memory.swap.used.percent sysdig_host_memory_swap_used_percent memory.used.percent sysdig_host_memory_used_percentsysdig_container_memory_used_percentsysdig_program_memory_used_percent file.bytes.in sysdig_host_file_in_bytessysdig_container_file_in_bytes sysdig_program_file_in_bytes file.bytes.out sysdig_host_file_out_bytessysdig_container_file_out_bytes sysdig_program_file_out_bytes file.bytes.total sysdig_host_file_bytes_totalsysdig_container_file_bytes_total sysdig_program_file_bytes_total file.iops.in sysdig_host_file_in_iopssysdig_container_file_in_iops file.iops.out sysdig_host_file_out_iopssysdig_container_file_out_iops file.iops.total sysdig_host_file_iops_totalsysdig_container_file_iops_total sysdig_program_file_iops_total file.open.count sysdig_host_file_open_countsysdig_container_file_open_count file.time.in sysdig_host_file_in_timesysdig_container_file_in_time file.time.out sysdig_host_file_out_timesysdig_container_file_out_time file.time.total sysdig_host_file_time_totalsysdig_container_file_time_total sysdig_program_file_time_total fs.bytes.free sysdig_host_fs_free_bytessysdig_container_fs_free_bytessysdig_fs_free_bytes fs.bytes.total sysdig_fs_total_bytes\nsysdig_host_fs_total_bytes\nsysdig_container_fs_total_bytes fs.bytes.used sysdig_fs_used_bytes\nsysdig_host_fs_used_bytessysdig_container_fs_used_bytes fs.free.percent sysdig_fs_free_percent\nsysdig_host_fs_free_percentsysdig_container_fs_free_percent fs.inodes.total.count sysdig_fs_inodes_total_count sysdig_container_fs_inodes_total_count\nsysdig_host_fs_inodes_total_count fs.inodes.used.count sysdig_fs_inodes_used_count sysdig_container_fs_inodes_used_countsysdig_host_fs_inodes_used_count fs.inodes.used.percent sysdig_fs_inodes_used_percent sysdig_container_fs_inodes_used_percentsysdig_host_fs_inodes_used_percent fs.largest.used.percent sysdig_container_fs_largest_used_percent sysdig_host_fs_largest_used_percent fs.root.used.percent sysdig_container_fs_root_used_percent sysdig_host_fs_root_used_percent fs.used.percent sysdig_fs_used_percent sysdig_container_fs_used_percent sysdig_host_fs_used_percent net.bytes.in sysdig_host_net_in_bytessysdig_container_net_in_bytessysdig_program_net_in_bytes net.bytes.out sysdig_host_net_out_bytessysdig_container_net_out_bytessysdig_program_net_out_bytes net.bytes.total sysdig_host_net_total_bytessysdig_container_net_total_bytessysdig_program_net_total_bytessysdig_connection_net_total_bytes proc.count sysdig_host_proc_countsysdig_container_proc_countsysdig_program_proc_count thread.count sysdig_host_thread_countsysdig_container_thread_countsysdig_program_thread_count container.count sysdig_container_count system.uptime sysdig_host_system_uptime uptime sysdig_host_upsysdig_container_upsysdig_program_up ","url":"https://docs.sysdig.com/en/administration/metrics-available-in-monitor-light/"},{"id":242,"title":"Metrics Explorer","content":"To access Metrics Explorer:\nLog in to Sysdig Monitor as a Standard User or higher.\nSelect Explore \u0026gt; Metrics Explorer.\nFilter Infrastructure \u0026amp; MetricsYou can explore the infrastructure stack and get insight into the numerous metrics available to you at each level. To find these displays, select a top-level infrastructure object, then filter by scope for relevant infrastructure objects, or filter by metrics for desired metrics.\nSysdig Monitor displays only the metrics and dashboards that are relevant to the selected infrastructure object.\nSteps Preview On the Metrics Explorer tab, open the infrastructure filtering menu and select the infrastructure object you want to explore. (demo-kube-gke in the example) Navigate to Filter metrics and search or select the desired metric. (memory_bytes in the example). The metric will instantly be presented as a time chart. The scope of the metric, when viewed via the scope filtering menu, is set to the infrastructure object that you have currently selected. Multiple queries can be added either via the Metric list of by clicking on Add Query. GroupingsGroupings provides a hierarchical view of an infrastructure entities. With Groupings, you can segment your infrastructure by any label. You can use out-of-the-box groupings or create your own.\nSysdig Monitor offers two types of Groupings:\nAgent-only Groupings All-sources Groupings Switch GroupingsTo switch between available groupings follow the steps outlined below.\nStep On the Metrics Explorer page, select the name of the current Grouping (for example, Cloud Accounts) at the top of the page. The Groupings menu appears. Select the desired grouping from the list. Create a Grouping Step Preview On the Metrics Explorer page, select the current Grouping (for example, My Workloads) to open the Groupings menu. Beside the My Groupings section, select the + icon. In the new modal, click Add. Specify your Grouping Name, sharing settings, Scope, Source, and grouping Hierarchy. Click Save \u0026amp; Apply. Define GroupingsScopeWhen creating a grouping, you can specify a scope to restrict which entities will be considered when populating the Hierarchy.\nFor example, defining a grouping that only displays Cronjobs. In the scenario given below, kube_workload_type is cronjob is added as a Scope filter.\nThe filter then ensures that the only workloads displayed in the Hierarchy are Cronjobs.\nSourcesYou can use two sources when defining a grouping.\nGroupings Label source Data used Agent Only Any label from Extended Label Set (also known as Service Vision), emitted by any Sysdig Agent. Historical data in accordance to the time window selected. All Sources Any label, regardless of source. Real-time only (last 10-40 mins). Agent OnlyAgent Only Groupings are the oldest type of Groupings in Sysdig Monitor. They use any extended label emitted by any Sysdig Agent to build the infrastructure tree. These groupings accurately reflect the state of your infrastructure as the time navigation is shifted back in time. The most commonly used agent-only grouping is All Workloads, which organizes the infrastructure entities by the following labels: kube_cluster_name, kube_namespace_name, kube_workload_name, and kube_pod_name.\nAll SourcesAll Sources Groupings allow you to use any label to build the infrastructure tree, regardless of the source. This makes them more flexible than the agent-only groupings. An example of an all-sources groupings is Azure Resources, which organizes the entities by the following labels: subscription_name, cloud_provider_region_name, resource_group, and cloud_provider_resource_name.\nAll Sources Groupings solely use real-time data from the last 10 to 40 minutes.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/using-metrics-explorer/"},{"id":243,"title":"Migration Guide","content":" If you encounter issues during migration, contact your Sysdig representative or Sysdig Support for assistance.\nSysdig has deprecated the legacy organizational_unit_ids and org_units parameters used in earlier AWS Organization onboarding configurations. If you onboarded AWS before November 2025, your Terraform or CloudFormation templates may still include these fields.\nTo maintain compatibility and receive future updates, migrate your configuration to the supported parameters:\ninclude_ouids exclude_ouids include_accounts exclude_accounts This migration updates your configuration only. Your existing onboarding behavior remains the same unless you choose to adjust which OUs or accounts are included.\nBefore You BeginReview your current onboarding method:\nTerraform CloudFormation (CFT) Choose the instructions that match your environment and whether you want to keep the same Organization structure or modify it.\nTerraform MigrationScenario A: Keep the Same AWS Organization StructureUse this section if you want to migrate to the new include/exclude parameters without changing which OUs or accounts Sysdig monitors.\nFoundational/CSPM Only Map existing values. Copy values from organizational_unit_ids into include_ouids. If organizational_unit_ids is empty, keep include_ouids empty.\nUpdate the onboarding module.\nReplace this line\norganizational_unit_ids = [\u0026#34;ou-xxxx-xxxxxxxx\u0026#34;, \u0026#34;ou-xxxx-xxxx\u0026#34;] with\ninclude_ouids = [\u0026#34;ou-xxxx-xxxxxxxx\u0026#34;, \u0026#34;ou-xxxx-xxxx\u0026#34;] exclude_ouids = [] include_accounts = [] exclude_accounts = [] Update the config posture module.\nReplace this line\norg_units = [\u0026#34;ou-xxxx-xxxxxxxx\u0026#34;, \u0026#34;ou-xxxx-xxxx\u0026#34;] with\ninclude_ouids = module.onboarding.include_ouids exclude_ouids = module.onboarding.exclude_ouids include_accounts = module.onboarding.include_accounts exclude_accounts = module.onboarding.exclude_accounts Apply the changes.\nRun the following commands:\nterraform init --upgrade terraform apply Foundational/CSPM + Threat Detection Complete the above steps for Foundational/CSPM Only, then update the log-ingestion module. Replace this line\norg_units = module.onboarding.organizational_unit_ids with\ninclude_ouids = module.onboarding.include_ouids exclude_ouids = module.onboarding.exclude_ouids include_accounts = module.onboarding.include_accounts exclude_accounts = module.onboarding.exclude_accounts Apply the changes. Run the following commands:\nterraform init --upgrade terraform apply Foundational/CSPM + Host Scanning Replace the following in the host-scanning snippet:\norg_units = module.onboarding.organizational_unit_ids with\ninclude_ouids = module.onboarding.include_ouids exclude_ouids = module.onboarding.exclude_ouids include_accounts = module.onboarding.include_accounts exclude_accounts = module.onboarding.exclude_accounts Apply the changes. Run the following commands:\nterraform init --upgrade terraform apply Foundational/CSPM + Workload Scanning Replace the following in the workload-scanning snippet:\norg_units = module.onboarding.organizational_unit_ids with\ninclude_ouids = module.onboarding.include_ouids exclude_ouids = module.onboarding.exclude_ouids include_accounts = module.onboarding.include_accounts exclude_accounts = module.onboarding.exclude_accounts Apply the changes. Run the following commands:\nterraform init --upgrade terraform apply Scenario B: Change the AWS Organization Structure During MigrationFollow these instructions if you want to adjust which OUs or accounts Sysdig monitors.\nCreate a new working folder. Copy your existing terraform.tfstate file into the folder. Copy the latest foundational.tf file into the folder. Update the include_* / exclude_* values to match your desired structure. Remove deprecated fields. Delete all references to the old parameters from your configuration: organizational_unit_ids org_units These fields are no longer supported and will cause Terraform to fail if left in place. Apply the update: Run the following commands: terraform init --upgrade terraform apply Example ConfigurationsOnboard the Entire Organizationinclude_ouids = [\u0026#34;r-op65\u0026#34;] exclude_ouids = [] include_accounts = [] exclude_accounts = [] Onboard Specific OUsinclude_ouids = [\u0026#34;ou-op65-p8bpskxa\u0026#34;] Exclude Specific OUsexclude_ouids = [\u0026#34;ou-op65-example\u0026#34;] Exclude Individual Accountsexclude_accounts = [\u0026#34;562567805211\u0026#34;] Include OUs But Exclude Some Accounts Inside Theminclude_ouids = [\u0026#34;ou-op65-teamA\u0026#34;] exclude_accounts = [\u0026#34;123456789012\u0026#34;] CloudFormation (CFT) MigrationTo migrate CloudFormation-based onboarding, update your Organization settings using the includedOrganizationalGroups field.\nExample PUT request\n{ \u0026#34;managementAccountId\u0026#34;: \u0026#34;2786e484-888d-44bd-ad55-67a3bd0e2506\u0026#34;, \u0026#34;includedOrganizationalGroups\u0026#34;: [ \u0026#34;ou-op65-0glv51jv\u0026#34;, \u0026#34;ou-op65-p8bpskxa\u0026#34; ], \u0026#34;organizationRootId\u0026#34;: \u0026#34;r-op65\u0026#34; } Expected Behavior After MigrationNew AWS AccountsIf AWS accounts were created before the migration, Sysdig automatically detects and adds them.\nDeleted AWS AccountsIf accounts were deleted in AWS before the migration:\nThey may continue to appear in CloudAuth. CloudAuth may show a validation error for each deleted account (if automatic onboarding is disabled). terraform destroy may require manually removing CloudFormation StackSet instances in AWS. After You Migrate All future changes should use include_ouids, exclude_ouids, include_accounts, and exclude_accounts. Remove all references to deprecated parameters: organizational_unit_ids org_units Using the updated parameters ensures compatibility with upcoming enhancements and future onboarding updates.\n","url":"https://docs.sysdig.com/en/sysdig-secure/connect-cloud-accounts/aws/selective-cloud-account-onboarding/migration-guide/"},{"id":244,"title":"Migration Guide","content":" If you encounter issues during migration, contact your Sysdig representative or Sysdig Support for assistance.\nSysdig has deprecated the legacy management_group_ids parameter used in earlier Azure organization onboarding configurations.\nIf you onboarded Azure using Terraform module version 0.3.x, your Terraform templates may still include this field.\nTo maintain compatibility and receive future updates, migrate your configuration to the supported parameters:\ninclude_management_groups exclude_management_groups include_subscriptions exclude_subscriptions This migration updates your configuration only. Your existing onboarding behavior remains the same unless you choose to adjust which management groups or subscriptions are included.\nBefore You BeginReview your current onboarding setup:\nTerraform Which features you enabled: Foundational/CSPM Foundational/CSPM + CDR Foundational/CSPM + Host Scanning Foundational/CSPM + Workload Scanning Choose the instructions that match your environment and whether you want to keep the same Azure organization structure or modify it.\nTerraform MigrationScenario A: Keep the Same Azure Organization StructureUse this section if you want to migrate to the new include/exclude parameters without changing which management groups or subscriptions Sysdig monitors.\nFoundational/CSPM Only Map existing values.\nCopy the values from management_group_ids into include_management_groups. If management_group_ids is empty, keep include_management_groups empty.\nUpdate the onboarding module (main.tf).\nReplace:\nmanagement_group_ids = [\u0026#34;management-group-test\u0026#34;] with\ninclude_management_groups = [\u0026#34;management-group-test\u0026#34;] exclude_management_groups = [] include_subscriptions = [] exclude_subscriptions = [] Update the config posture module. Replace:\nmanagement_group_ids = module.onboarding.management_group_ids with\ninclude_management_groups = module.onboarding.include_management_groups exclude_management_groups = module.onboarding.exclude_management_groups include_subscriptions = module.onboarding.include_subscriptions exclude_subscriptions = module.onboarding.exclude_subscriptions Update the module versions.\nApply the changes. Run the following commands:\nterraform init --upgrade terraform apply Foundational/CSPM + CDR Complete the steps in Foundational/CSPM Only, then update the log-ingestion module snippet. In the old log-ingestion snippet file, replace:\nmanagement_group_ids = module.onboarding.management_group_ids with:\ninclude_management_groups = module.onboarding.include_management_groups exclude_management_groups = module.onboarding.exclude_management_groups include_subscriptions = module.onboarding.include_subscriptions exclude_subscriptions = module.onboarding.exclude_subscriptions Update the module version for this snippet to 2.0.1, if not already done.\nApply the changes. Run the following commands:\nterraform init --upgrade terraform apply Foundational/CSPM + Host Scanning Complete the steps in Foundational/CSPM Only, then update the host-scanning snippet. In the old host-scanning snippet file, in module \u0026ldquo;agentless-scanning\u0026rdquo;, replace:\nmanagement_group_ids = module.onboarding.management_group_ids with:\ninclude_management_groups = module.onboarding.include_management_groups exclude_management_groups = module.onboarding.exclude_management_groups include_subscriptions = module.onboarding.include_subscriptions exclude_subscriptions = module.onboarding.exclude_subscriptions Ensure this module also uses version 2.0.1.\nApply the changes. Run the following commands:\nterraform init --upgrade terraform apply Foundational/CSPM + Workload Scanning Complete the steps in Foundational/CSPM Only, then update the workload-scanning snippet. In the old workload-scanning snippet file, in module \u0026ldquo;vm_workload_scanning\u0026rdquo;, replace:\nmanagement_group_ids = module.onboarding.management_group_ids with:\ninclude_management_groups = module.onboarding.include_management_groups exclude_management_groups = module.onboarding.exclude_management_groups include_subscriptions = module.onboarding.include_subscriptions exclude_subscriptions = module.onboarding.exclude_subscriptions Ensure this module also uses version 2.0.1.\nApply the changes. Run the following commands:\nterraform init --upgrade terraform apply Scenario B: Change the Azure Organization Structure During or After MigrationFollow these instructions if you want to adjust which management groups or subscriptions Sysdig monitors.\nFirst migrate from management_group_ids to the new include/exclude fields by following the steps in Scenario A for your use case.\nIn the onboarding module, update the combinations of the following to match the desired target structure:\ninclude_management_groups exclude_management_groups include_subscriptions exclude_subscriptions Use the Include/Exclude workflow in the Sysdig UI as a guide to design your structure.\nApply the updated configuration. Run the following commands:\nterraform init --upgrade terraform apply ","url":"https://docs.sysdig.com/en/sysdig-secure/connect-cloud-accounts/azure/selective-cloud-account-onboarding/migration-guide/"},{"id":245,"title":"Migration Guide","content":" If you encounter issues during migration, contact your Sysdig representative or Sysdig Support for assistance.\nSysdig has deprecated the legacy management_group_ids parameter used in older GCP Organization onboarding configurations.\nTo maintain compatibility, update your configuration to use the supported include/exclude parameters:\ninclude_folders exclude_folders include_projects exclude_projects This migration does not change how Sysdig integrates with your GCP Organization. It only updates your Terraform configuration to use the supported parameters.\nBefore You BeginReview your existing onboarding method.\nIf you previously used:\nmanagement_group_ids (legacy) folders/123456789 You must migrate to the include/exclude format.\nTerraform MigrationScenario A: Keep the Same GCP Organization StructureUse this procedure if you only want to replace deprecated parameters without changing which folders or projects Sysdig monitors.\nFoundational/CSPM Only Map existing values. Copy values from management_group_ids into include_folders. management_group_ids values use the prefix folders/\u0026lt;id\u0026gt;. include_folders must contain only the numeric folder ID. Example Old: folders/123456789 New: 123456789 If the list was empty, leave include_folders empty. Update the Terraform configuration.\nReplace this line\nmanagement_group_ids = [\u0026#34;folders/123456789\u0026#34;] with\ninclude_folders = [\u0026#34;123456789\u0026#34;] exclude_folders = [] include_projects = [] exclude_projects = [] Use the supported provider versions.\nUpdate the Sysdig Terraform provider to version 1.48 or later. Use onboarding module version 1.0.0 or later. Apply the changes.\nRun the following commands:\nterraform init --upgrade terraform apply Optional: Change the Organization Structure After MigrationOnce you migrate, you can adjust which folders or projects are included or excluded.\nExample ConfigurationsInclude Specific Foldersinclude_folders = [\u0026#34;123456789\u0026#34;, \u0026#34;987654321\u0026#34;] Exclude Specific Foldersexclude_folders = [\u0026#34;987654321\u0026#34;] Include Projects Directlyinclude_projects = [\u0026#34;my-gcp-project-123456789\u0026#34;] Exclude Specific Projectsexclude_projects = [\u0026#34;legacy-project-22\u0026#34;] After You Migrate Remove all references to management_group_ids. Use only include_folders, exclude_folders, include_projects, and exclude_projects. Your onboarding will continue to function normally. You can now safely modify which parts of your Organization Sysdig monitors. ","url":"https://docs.sysdig.com/en/sysdig-secure/connect-cloud-accounts/gcp/selective-cloud-project-onboarding/migration-guide/"},{"id":246,"title":"Monitoring Integrations","content":" To access Monitoring Integrations, log in to Sysdig Monitor, and select Integrations \u0026gt; Monitoring Integrations from the left navigation bar.\nBrowse the list on the Monitoring Integrations page to see which workloads Sysdig has detected on your connected environments. Click a listing to find out about the workload in detail. Here, depending on the status of the integration, you can see what metrics are available, configure or manage an integration, and view associated dashboards and alerts.\nBy default, Sysdig only displays workloads for which it has a default integration. Click the toggle in the top right to Show Unidentified Workload. To collect metrics from unidentified workloads, see Custom Integrations.\nScope, Search, and Filter IntegrationsYou can narrow down the integrations visible in the Monitoring Integrations list in three ways: by scope, by filter, and by search.\nScope: Use the directory to the left of the workloads list to view workloads from either your Entire Infrastructure, or from an individual Cluster or Namespace. Search: Use the Search bar to search by instance name. Filter: Click Filter by type to open a dropdown, where you can filter the integrations identified in your environment. Integrations StatusThe list of All Instances, where every workload meeting your scope, filter and search conditions is listed, is further divided into five categories:\nReporting MetricsThese integrations are configured correctly and are reporting metrics. Click a listing to:\nSee when this integration was last checked. Enable or disable it globally or per cluster. Review types of metrics collected Create exceptions to limit the data being collected. See the Dashboards using these metrics. See linked Alerts. View compatibility and installation details. Needs AttentionThese integrations are not reporting metrics. Click on a listing to begin troubleshooting. The issue may be:\nThe integration was not correctly identified. See Custom Metrics. The agent settings have been configured to disable the integration. Check the configuration of the integration and, if necessary, contact support. Pending MetricsThese integrations have recently been configured and are waiting to receive metrics. This process takes up to 10 minutes to complete.\nRequires ConfigurationYou must configure these integrations to collect metrics. Open the detail page to decide the next steps.\nThere are two possibilities:\nA wizard-assisted configuration is available from Sysdig. No integration has been identified, and you need to create a custom integration. See Custom Integration for details. Available to EnableThese integrations are ready to collect metrics but are not yet enabled. You might incur costs if you enable them. See Time Series Billing.\nDefault and Custom IntegrationsThere are two types of integrations: default integrations and custom integrations.\nDefault integrations exist for applications found in Sysdig\u0026rsquo;s Integrations Library: Application integrations, cloud integrations, and infrastructure Integrations all belong under the umbrella of default integrations.\nCustom integrations are integrations not natively included by Sysdig. You use custom integrations to collect metrics from a source that is not found in the Integrations Library. This normally involves additional configuration. See Custom Integrations.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/monitoring-integrations/"},{"id":247,"title":"Netsec Policy Generation","content":"Set the ScopeDefine the Kubernetes entity and timeframe for which you want to aggregate communications.\nCommunications are aggregated using Kubernetes metadata to avoid having additional entries that are not relevant for the policy creation. For example, if pod A under deployment A communicates several times with pod B under deployment B, only one entry appears in the interface. Or, if pod A1 and pod A2, both under deployment A, both communicate with pod B, deployment A will represent all its pods.\nIn the Sysdig Secure UI, select Inventory \u0026gt; Network from the left panel.\nChoose a Cluster and Namespace from the drop-down.\nSelect the type of Kubernetes entity for which you want to create a policy:\nService: A Service in Kubernetes is an abstraction that defines a logical set of pods and a policy by which to access them, often defined by a selector. It ensures that applications running in different Pods can communicate with each other consistently and reliably. Deployment: A Deployment provides declarative updates to applications in Kubernetes. It manages the creation, scaling, and updating of a set of identical Pods, ensuring that the desired number of pods are running and available at all times. Daemonset: A DaemonSet ensures that all (or some) nodes run a copy of a specific pod. When nodes are added to the cluster, Pods are added to them as well. When nodes are removed from the cluster, those pods are also garbage collected. DaemonSets are typically used for background tasks like logging and monitoring. Stateful Set: A StatefulSet is used to manage stateful applications, providing guarantees about the ordering and uniqueness of Pods. It ensures that the pods are created and deleted in a specific order and that each Pod has a stable, unique identifier, which is useful for applications that require persistent storage. CronJob: A CronJob in Kubernetes manages time-based jobs, similar to cron jobs in Unix/Linux systems. It schedules and runs jobs at specified intervals, allowing tasks to be executed periodically and at fixed times, such as batch processing or automated maintenance. Choose CronJob to see communication aggregated to the CronJob (scheduler) level, rather than the Job, which may generate an excess number of entries. Job: A Job in Kubernetes is a controller that ensures a specified number of pods successfully complete a task. Unlike Deployments or StatefulSets, Jobs are used for finite tasks and run until completion, making them suitable for tasks like data processing or batch jobs. Choose Job to see entries where a Job has no CronJob parent. Select the timespan - how far back in time to aggregate the observed communications for the entity. The interface displays the Ingress and Egress tables for the Kubernetes entity and timeframe.\nManage Ingress and EgressThe ingress/egress tables detail the observed communications for the selected entity (pod owner) and time period.\nGranular and global assignments: You can then cherry-pick rows to include or exclude from the policy granularly, or establish general rules using the drop-down global rule options.\nUnderstanding unresolved IPs: For some communications, it may not be possible to resolve one of the endpoints to Kubernetes metadata and classify as Service or Deployment. For example, if a microservice is communicating with an external web server, that external IP address is not associated with any Kubernetes metadata in your cluster. The UI will still display these entities as \u0026ldquo;unresolved IPs.\u0026rdquo; Unresolved IPs are excluded by default from the Kubernetes network policy, but can be added manually via the ingress/egress interface.\nChoose Ingress or Egress to review and edit the detected communications:\nSelect the scope as described above.\nFor in-cluster entities: Edit the permitted communications as desired, by either:\nSelecting/deselecting rows of allowed communication, or\nChoosing General Ingress/Egress Rules: Block All, Allow All Inside Namespace, or Allow All.\nFor unresolved IPs (if applicable): If the tool detects many unresolved IPs, you can:\nSearch results by any text to locate particular listings\nFilter results by\nInternal: found within the cluster\nExternal: found outside the cluster\nAliased: displays any given alias\nUnknown: unable to tell if internal or external.\nFine-tune the handling of unknown IPs (admins only) .\nYou can assign an alias, set the IP to \u0026ldquo;allowed\u0026rdquo; status, or add a CIDR configuration so the IP so the IP is correctly categorized and labelled.\nRepeat on the other table, then proceed to check the topology and/or generate the policy.\nUse Topology VisualizationUse the Topology view to visually validate if this is the policy you want, or if something should be changed. The topology view is a high-level Kubernetes metadata view: pod owners, listening ports, services, and labels.\nCommunications that will not be allowed if you decide to apply this policy are color-coded red.\nPop-up detail panes: Hover over elements in the topology to see all the relevant details for both entities and communications.\nReview Applied PoliciesOnce policies have been generated, you can view the network policies applied to a cluster for a particular workload or workloads.\nYou can:\nReview the relevant policies applied to the pod-to-pod communication for the current view\nClick View Policy to see the raw yaml output of the network policy applied to that workload.\nTopology LegendWhen glancing at the topology, the color codes indicate:\nLines:\nBlack = resolved connection\nRed = connection not resolved; communication not included in the generated policy. Go to Ingress/Egress panels and select the relevant rows to allow the communication.\nEntities:\nBlue = the selected workload\nBlack = other services and deployments the selected workload communicates with\n4. Review and Download Generated PolicyIf you are satisfied with the rules and communication lines, simply click the Generated Policy tab to get an instantaneously generated file.\nReview the resulting YAML file and download it to your browser.\nSample Use CasesIn all cases, you begin by leaving the application running for at least 12 hours, to allow the agent to collect information.\nCase 1: Only Allow Specified Ingress/Egress CommunicationsAs a developer, you want to create a Kubernetes network policy that only allows your service/deployment to establish ingress and egress network communications that you explicitly allow.\nSelect the cluster namespace and deployment for your application. You should see pre-computed ingress and egress tables. You know the application does not communicate with any external IP for ingress or egress, so you should not see any unresolved IPs. The topology map shows the same information.\nChange a rule: You decide one service your application is communicating with is obsolete. You uncheck that row in the egress table.\nCheck the topology map. You will see the communication still exists, but is now drawn in red, meaning that it is forbidden using the current Kubernetes network policy (KNP).\nCheck the generated policy code. Verify that it follows your plan:\nNo ingress/egress raw IP No entry for the service you explicitly excluded Download the generated policy and upload it to your Kubernetes environment.\nVerify that your application can only communicate with the services that were marked in black in the topology and checked in the tables. Then generate and download the policy to apply it.\nCase 2: Allow Access to Proxy Static IPsAs a developer, you know your application uses proxies with a static IP and you want to configure a policy that allows your application to access them.\nSee the proxy IPs in the egress section of the interface\nUse the Allow Egress to IP mask to create a manual rule to allow those IPs in particular\nDe-select all the other entries in the ingress and egress tables\nLooking at the topology map, verify that only the communications to these external IPs are marked in black, the other communications with the other services/deployments are marked in red\nDownload the generated Kubernetes network policy and apply it.\nCase 3: Allow Communication Only Inside the NamespaceYou know that your application should only communicate inside the namespace, both for ingress and for egress.\nAllow ingress inside the namespace using the general rules\nAllow egress inside the namespace using the general rules\nGenerate the policy and confirm: everything inside the namespace is allowed, without nominating a particular service/deployment, then apply it.\nCase 4: Allow Access to a Specified Namespace, Egress OnlyYour application deployment A only communicates with applications in deployment B, which lives in a different namespace. You only need that egress traffic; there is no ingress traffic required for that communication.\nVerify that the ingress table is empty, both for Kubernetes entities and for raw IP addresses.\nVerify that the only communication listed on the Egress table is communication with deployment B.\nDownload the autogenerated policy, apply it, and verify:\nYour application cannot communicate with other entities inside A\u0026rsquo;s namespace.\nThe application can contact the cluster DNS server to resolve other entities.\nCase 5: Allow Access When a Deployment Has Been RelabeledAs a developer, you want to create a policy that only allows your service/deployment to establish ingress and egress network communications that you explicitly allow, and you need to make a change.\nAfter leaving the application running for a few hours, you realize you didn\u0026rsquo;t tag all the namespaces involved in this policy\nA message at the top of the view will state \u0026ldquo;you need to assign labels to this namespace\u0026rdquo;.\nConfirm the situation in the different views:\nThe generated policy should not have an entry for that communication\nThe Topology map should show the connection with a red line\nAttach a label to the namespace that was missing it. After some minutes, a row shows the updated information.\nWhitelist the connection appropriately.\nGenerate and download the policy and apply it.\n","url":"https://docs.sysdig.com/en/sysdig-secure/network-policy-generation/"},{"id":248,"title":"Observations","content":"PrerequisitesObservations require:\nAgent \u0026gt;= 13.6.0 Stateful Falco Rules Using ObservationsWithout the Observation extension, Falco rules evaluate conditions against information from a single event and its associated context, such as reconstructed state from past events. For example, an open() syscall event provides details like the file being opened, the process name, and the container environment.\nAlthough powerful, this evaluation is stateless — it cannot \u0026ldquo;remember\u0026rdquo; past events to evaluate them together with present events to create a runtime policy event. For example, when Falco detects an open() syscall, it cannot remember which other files a process has opened, or whether the process has performed other actions, such as opening a network connection or spawning a subprocess.\nThis limitation makes it difficult to detect multi-step attack patterns and generate a runtime policy event. For example, a spawning shell might be innocuous. However, when this occurs along with actions such as accepting an inbound connection, opening a temporary file, and executing a shell from that file, it is highly suspicious and a strong indicator of a remote code execution attack.\nSysdig Secure addresses this gap with Observations, which extend Falco\u0026rsquo;s rules file format and detection. Key features include:\nA new top level object, observation, to denote events that are notable but not necessarily worthy of a runtime policy event. A new top level object, obs_link_fields, specifies how two observations must be related to each other. Falco rules have a new event source, source: observation, with fields obs.link/obs.occurs that can be used to relate a group a set of observations into a runtime policy event. Any standard Falco rule can also be used in place of an observation. For example, rules with an event source of observation can group together a mix of observations and falco rules to generate a runtime policy event.\nThis example assumes there is an existing Linux workload rule \u0026ldquo;Terminal Shell in container\u0026rdquo;:\n- macro: package_management_program condition: (proc.name in (tar, rpm, dpkg)) - observation: Spawn Package Management Program condition: spawned_process and package_management_program - obs_link_fields: same_session fields: - [proc.sid, proc.sid] - rule: Spawn Package Management Program Below Container Exec desc: Detect an attempt to run a package management program from a container exec condition: \u0026gt;- obs.occurs[\u0026#34;Terminal shell in container\u0026#34;]=true and obs.link[\u0026#34;Terminal shell in container--\u0026gt;Spawn Package Management Program, same_session\u0026#34;]=true output: \u0026gt; An attempt was made to run a package management program from a container exec (user=%user.name cmdline=%proc.cmdline container_id=%container.id image=%container.image.repository) priority: WARNING source: observation This rule generates a policy event when someone execs into a container and then runs a package management program.\nLimitationsOnly Managed Policies can contain these extensions. Rules using these extensions can not be customized or tuned.\nObservations are only supported for Linux workload events, for example source: syscall, and not cloud or Kubernetes Audit events.\nNew Falco Rules ChangesTo implement Observations, the Falco rules syntax can add the following rules objects and additional event sources.\nThe top level observation objectIn Sysdig Secure, a new top level object called observation allows tracking notable activities without necessarily resulting in a runtime policy event. Here\u0026rsquo;s an example:\n- macro: open_write condition: \u0026gt;- ((evt.type=open or evt.type=openat) and evt.is_open_write=true and fd.typechar=\u0026#39;f\u0026#39; and fd.num\u0026gt;=0) - macro: spawned_process condition: (evt.type in (execve) and evt.dir=\u0026lt; and evt.arg.res=0) - observation: Write File condition: open_write - observation: Launch Process condition: spawned_process source: syscall An observation object has a name (for example, the value for the observation key), a condition, and an optional source key. The condition behaves identically to rule conditions, and can contain macro/list references. The source names the event source on which the observation runs. If not specified, the source is syscall.\nNote that there is no output, no priority, and no tags. This is because events that match observations are only held in memory. They are not sent to any output channel and do not result in a policy event.\nObservation Link Fields objects: relate observations to each otherIn Sysdig Secure, a new top level rules object called obs_link_fields specifies how one observation can relate to another. Here\u0026rsquo;s an example:\n- obs_link_fields: fd_matches_exepath fields: - [fd.name, proc.exepath] An obs_link_fields object has a name (for example, the value for the obs_link_fields key) and a list of field tuples under the fields property. For two observations to be related, the value of the field for the left hand side of the tuple, from the event matching the first observation, must be equal to the value of the field for the right hand side of the tuple, from the second observation.\nFor example, if the first observation were Write File and the second observation were Launch Process, the two events would be related if the value of the fd.name field (such as the written file) was equal to the value of the proc.exepath (the process being executed).\nObservation rules: generating policy events from a group of related observationsSysdig Secure defines a new Falco Rule event source called observation. Conditions for observation rules can contain the following fields:\nobs.occurs[\u0026lt;Observation/Rule Name\u0026gt;]: This field evaluates to true if an observation has occurred with the provided name. This field helps limit the number of events that need to be held in memory, by specifying an initial restriction. obs.link[\u0026lt;Observation/Rule 1\u0026gt;--\u0026gt;\u0026lt;Observation/Rule 2\u0026gt;, \u0026lt;obs_link_fields name\u0026gt;]: This field evaluates to true if there are existing observations 1 and 2 that are related by the fields named in the provided obs_link_fields object. Like other rules, Falco Rules with event source observation contain a description, condition, output, priority, tags, and source key.\nWhen generating the output string for a policy event, the last matching event (such as the final syscall) is used to fill in the templated output string.\nUsing the observations and obs_link_fields objects presented earlier, we could write the following rule:\n- obs_link_fields: same_session fields: - [proc.sid, proc.sid] - rule: Spawned Written File via Container Exec desc: Detect an attempt to spawn a program from an opened file below a container exec condition: \u0026gt;- obs.occurs[\u0026#34;Terminal shell in container\u0026#34;]=true and obs.link[\u0026#34;Terminal shell in container--\u0026gt;Write File, same_session\u0026#34;]=true and obs.link[\u0026#34;Write File--\u0026gt;Launch Process, fd_matches_exepath\u0026#34;]=true output: \u0026gt; A process was launched from a file written during a container exec (user=%user.name cmdline=%proc.cmdline container_id=%container.id image=%container.image.repository) priority: WARNING source: observation Breaking down the condition expression, the rule evaluates to true when:\nSomeone execs into a container using docker exec/kubectl exec/etc. Below that container exec, someone writes a file. The session id (value of proc.sid) of the process that denotes the exec into the container must be the same as the session id of the process writing the file. Someone launches a process using the written file as an executable. The value of fd.name for the syscall that writes the file must be the same as proc.exepath for the syscall that spawns the new process. ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-rules-extensions/"},{"id":249,"title":"Configure Okta for OIDC","content":"PrerequisitesSysdig Review OpenID Connect (SaaS). Okta Review the Prerequisites.\nAdministrative privileges\nConfigure an OIDC - OpenID Connect Web application separately for each Sysdig product: Sysdig Monitor and Sysdig Secure.\nFor more information, see Setting Up an OpenID Connect Application in Okta.\nThe topics below call out specific steps that require additional action.\nConfigure OktaThis topic describes the minimal configuration options in Okta. You may need to adjust them based on the specifics of your environment.\nGeneral SettingsSpecify the application name, and optionally, add a logo.\nIf you don’t intend to configure the IdP-initiated login flow, select Do not display application icon to users and Do not display application icon in the Okta Mobile app.\nLoginMake sure to disable option Allow wildcard * in login URI redirect.\nIdentify the correct Sign-in redirect URI associated with your Sysdig application and region. Enter the value in the field for Sign-in redirect URI. Click Save.\nSee Redirect URI section for more information.\nThis is the callback URL to which Okta sends the authentication response and ID token when an user attempts to log in to Sysdig using SSO.\nParameters Required for Sysdig ConfigurationCopy the following for the OpenID configuration parameters in the Sysdig authentication settings.\nClient ID: Copy the value from the Client Credentials section on the General tab. Client Secrets: Copy the Client Secrets from the General tab. Issuer URL: Copy the value from the OpenID Connect ID Token section on the Sign On tab. Configure Sysdig SettingsTo enable Okta OpenID functionality on the Sysdig application, specify the following:\nConfiguration Description Client ID Specify the value you have copied from the Client Credentials section on the General tab. Client Secret Specify the value you have copied from the Client Secrets section on the General tab. Issuer URL Specify the value you have copied from the OpenID Connect ID Token section on the Sign On tab. Base Issuer The value is your Okta domain name. For example, https://myOktaOrg.okta.com Authorization Endpoint To view the metadata tied to your Okta application, including the Authorization Endpoint, use the following endpoint. https://{myOktaOrg}/.well-known/openid-configuration?client_id={ClientId} Replace {myOktaOrg} with your Okta domain name and {ClientId} with the Client ID associated with your Okta web application. issuer: \u0026#34;https://myOktaOrg.okta.com\u0026#34;, authorization_endpoint: \u0026#34;https://myOktaOrg.okta.com/oauth2/v1/authorize\u0026#34;, token_endpoint: \u0026#34;https://myOktaOrg.okta.com/oauth2/v1/token\u0026#34;, userinfo_endpoint: \u0026#34;https://myOktaOrg.okta.com/oauth2/v1/userinfo\u0026#34;, registration_endpoint: \u0026#34;https://myOktaOrg.okta.com/oauth2/v1/clients/\u0026lt;redacted\u0026gt;\u0026#34;, jwks_uri: \u0026#34;https://myOktaOrg.okta.com/oauth2/v1/keys?client_id=\u0026lt;redacted\u0026gt;\u0026#34;, \u0026lt;redacted\u0026gt; ","url":"https://docs.sysdig.com/en/administration/saas-okta-openid/"},{"id":250,"title":"Configure Okta for SAML","content":"PrerequisitesSysdig Review SAML (SaaS). Okta Review the Prerequisites.\nConfigure a SAML application separately for each Sysdig product: Sysdig Monitor and Sysdig Secure.\nFor more information, see Setting Up a SAML Application in Okta.\nThe topics below call out specific steps that require additional action.\nConfigure OktaThis topic describe the minimal configuration options in Okta. You may need to adjust them based on the specifics of your environment.\nGeneral SettingsSpecify the application name, and optionally, add a logo.\nIf you don\u0026rsquo;t intend to configure the IdP-initiated login flow, select Do not display application icon to users and Do not display application icon in the Okta Mobile app.\nSAML SettingsSpecify the following:\nDefault Relay State: The format is #/\u0026amp;customer=\u0026lt;CUSTOMER-ID-NUMBER\u0026gt;. Replace \u0026lt;CUSTOMER-ID-NUMBER\u0026gt; with the number you have retrieved as described in Find Your Customer Number. Specify this option only if you wish to configure IdP-initiated login flow. If you have defined an integration name or are using multiple integrations, include the integration name in the Relay State parameter using the following format: \u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;, so it becomes #/\u0026amp;customer=\u0026lt;CUSTOMER-ID-NUMBER\u0026gt;\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\nSingle sign-on URL: For the correct URLs associated with your Sysdig application and region, see Redirect URLs for Authentication. For more information, see SaaS Regions and IP Ranges.\nAudience URI (SP Entity ID): For the correct Entity ID associated with your Sysdig application and region, see Redirect URLs for Authentication and SaaS Regions and IP Ranges.\nAttribute Statements (Optional)Specify the following:\nName Name Values Instead of the values shown in the Okta example, add the values:\nName Value email user.email first name user.firstName last name user.lastName Note that the attributes are case-sensitive, so use caution when entering them.\nOnly email is required as the attribute. However, we recommend including first and last names for these values to be included in the records created in the Sysdig database when new users successfully log in via SAML for the first time.\nSAML Metadata URLCopy the Metadata URL. You will use it while configuring Sysdig.\nTest Metadata (Optional)To ensure the metadata URL you copy at the end of the IdP configuration procedure is correct, you can test it by directly accessing it via your browser.\nWhen accessing the URL, your browser should immediately download an XML file that begins similarly to the example shown below. No entry of credentials or other security measures should be required to successfully download it. If this is not the case, revisit the IdP configuration.\n\u0026lt;md:EntityDescriptor xmlns:md=\u0026#34;urn:oasis:names:tc:SAML:2.0:metadata\u0026#34; entityID=\u0026#34;http://www.okta.com/exkd7ltpz8HOv6Rkf5d7\u0026#34;\u0026gt; \u0026lt;md:IDPSSODescriptor WantAuthnRequestsSigned=\u0026#34;false\u0026#34; protocolSupportEnumeration=\u0026#34;urn:oasis:names:tc:SAML:2.0:protocol\u0026#34;\u0026gt; \u0026lt;md:KeyDescriptor use=\u0026#34;signing\u0026#34;\u0026gt; \u0026lt;ds:KeyInfo xmlns:ds=\u0026#34;http://www.w3.org/2000/09/xmldsig#\u0026#34;\u0026gt; \u0026lt;ds:X509Data\u0026gt; \u0026lt;ds:X509Certificate\u0026gt;xyz\u0026lt;/ds:X509Certificate\u0026gt; \u0026lt;/ds:X509Data\u0026gt; \u0026lt;/ds:KeyInfo\u0026gt; \u0026lt;/md:KeyDescriptor\u0026gt; \u0026lt;md:NameIDFormat\u0026gt;urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified\u0026lt;/md:NameIDFormat\u0026gt; \u0026lt;md:NameIDFormat\u0026gt;urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress\u0026lt;/md:NameIDFormat\u0026gt; \u0026lt;md:SingleSignOnService Binding=\u0026#34;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST\u0026#34; Location=\u0026#34;https://domain.okta.com/app/domain_sysdigsecure/sso/saml\u0026#34;/\u0026gt; \u0026lt;md:SingleSignOnService Binding=\u0026#34;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect\u0026#34; Location=\u0026#34;https://domain.okta.com/app/domain_sysdigsecure/sso/saml\u0026#34;/\u0026gt; \u0026lt;/md:IDPSSODescriptor\u0026gt; \u0026lt;/md:EntityDescriptor\u0026gt; Configure SysdigTo configure Sysdig for Okta:\nLog in to Sysdig Platform.\nNavigate to Settings via the user menu icon at the bottom of the left navigation bar.\nUnder Access \u0026amp; Secrets, select Authentication (SSO).\nEdit existing or create a new SSO integration (type: SAML).\nEnter the Metadata URL you have copied earlier in the Metadata field.\nFor Email Parameter, write email.\nThe rest of the fields and toggles can be left as default.\nSelect Save Settings.\nEnable the integration by selecting the option from the Enabled column in the integration\n","url":"https://docs.sysdig.com/en/administration/saas-okta-saml/"},{"id":251,"title":"Okta (OpenID On-Prem)","content":"PrerequisitesSysdig Review OpenID Connect (On-Prem). Okta Review the Prerequisites.\nGet administrative privileges.\nConfigure an OIDC - OpenID Connect Web application separately for each Sysdig product: Sysdig Monitor and Sysdig Secure.\nFor more information, see Setting Up an OpenID Connect Application in Okta.\nThe topics below call out specific instructions that require additional action.\nConfigure OktaThis topic describes the minimal configuration options in Okta. You may need to adjust them based on the specifics of your environment.\nGeneral SettingsSpecify the application name, and optionally, add a logo.\nIf you don’t intend to configure the IdP-initiated login flow, select Do not display application icon to users and Do not display application icon in the Okta Mobile app.\nLoginFor Sign-in redirect URI enter one of the following values, replacing HOSTNAME with the hostname through which your users access the Sysdig application(s) and PORT with the TCP port number, which is typically 443:\nSysdig Monitor: https://HOSTNAME:PORT/api/oauth/openid/auth\nSysdig Secure: https://HOSTNAME:PORT/api/oauth/openid/secureAuth\nThis is the callback URL to which Okta sends the authentication response and ID token when an user attempts to log in to Sysdig using SSO.\nParameters Required for Sysdig ConfigurationCopy the following OpenID configuration parameters. You need them to complete the configuration in the Sysdig application.\nClient ID: Copy the value from the Client Credentials section on the General tab. Client Secrets: Copy the Client Secrets from the General tab. Issuer URL: Copy the value from the OpenID Connect ID Token section on the Sign On tab. Configure Sysdig SettingsTo enable Okta OpenID functionality on the Sysdig application, specify the following:\nConfiguration Description Client ID Specify the value you have copied from the Client Credentials section on the General tab. Client Secret Specify the value you have copied from the Client Secrets section on the General tab. Issuer URL Specify the value you have copied from the OpenID Connect ID Token section on the Sign On tab. Base Issuer The value is your Okta domain name. For example, https://myOktaOrg.okta.com Authorization Endpoint To view the metadata tied to your Okta application, including the Authorization Endpoint, use the following endpoint. https://{myOktaOrg}/.well-known/openid-configuration?client_id={ClientId} Replace {myOktaOrg} with your Okta domain name and {ClientId} with the Client ID associated with your Okta web application. ","url":"https://docs.sysdig.com/en/administration/onprem-openid-okta/"},{"id":252,"title":"Okta (SAML On-Prem)","content":"PrerequisitesSysdig Review SAML (On-Prem). Okta Review the Prerequisites.\nConfigure a SAML application separately for each Sysdig product: Sysdig Monitor and Sysdig Secure.\nFor more information, see Setting Up a SAML Application in Okta.\nThe topics below call out specific steps that require additional action.\nConfigure OktaThis topic describe the minimal configuration options in Okta. You may need to adjust them based on the specifics of your environment.\nGeneral SettingsSpecify the application name, and optionally, add a logo.\nIf you don\u0026rsquo;t intend to configure the IdP-initiated login, select Do not display application icon to users and Do not display application icon in the Okta Mobile app.\nSAML SettingsEnter the values shown in the table below, replacing HOSTNAME with the hostname through which your users access the Sysdig applications and PORT with the TCP port number, which is typically 443.\nReplace CUSTOMER-ID-NUMBER with the number retrieved as described in Find Your Customer Number. Normally the Customer ID will be 1 in on-prem installations.\nSetting\nValue for Sysdig Monitor\nValue for Sysdig Secure\nSingle sign-on URL\nhttps://HOSTNAME:PORT/api/saml/auth\nhttps://HOSTNAME:PORT/api/saml/secureAuth\nAudience URI (SP Entity ID)\nhttps://HOSTNAME:PORT/api/saml/metadata\nhttps://HOSTNAME:PORT/api/saml/metadata\nDefault Relay State\nThis is optional field. Specify this value only if you wish to configure IdP-initiated login method.\n#/\u0026amp;customer=CUSTOMER-ID-NUMBER\n#/\u0026amp;customer=CUSTOMER-ID-NUMBER\nYou must include the port number in the IDP-side configuration even though port 443 is the typical default for https:// URLs.\nAttribute Statements (Optional)Specify the following:\nName Name Values Instead of the values shown in the Okta example, add the values:\nName Value email user.email first name user.firstName last name user.lastName Note that the attributes are case-sensitive, so use caution when entering them.\nOnly email is required as the attribute. However, we recommend including first and last names for these values to be included in the records created in the Sysdig database when new users successfully log in via SAML for the first time.\nSAML Metadata URLCopy the Metadata URL. You will use it while configuring Sysdig.\nTest Metadata (Optional)To ensure the metadata URL you copy at the end of the IDP configuration procedure is correct, you can test it by directly accessing it via your browser.\nWhen accessing the URL, your browser should immediately download an XML file that begins similarly to the example shown below. No entry of credentials or other security measures should be required to successfully download it. If this is not the case, revisit the IDP configuration.\n\u0026lt;md:EntityDescriptor xmlns:md=\u0026#34;urn:oasis:names:tc:SAML:2.0:metadata\u0026#34; entityID=\u0026#34;http://www.okta.com/exkd7ltpz8HOv6Rkf5d7\u0026#34;\u0026gt; \u0026lt;md:IDPSSODescriptor WantAuthnRequestsSigned=\u0026#34;false\u0026#34; protocolSupportEnumeration=\u0026#34;urn:oasis:names:tc:SAML:2.0:protocol\u0026#34;\u0026gt; \u0026lt;md:KeyDescriptor use=\u0026#34;signing\u0026#34;\u0026gt; \u0026lt;ds:KeyInfo xmlns:ds=\u0026#34;http://www.w3.org/2000/09/xmldsig#\u0026#34;\u0026gt; \u0026lt;ds:X509Data\u0026gt; \u0026lt;ds:X509Certificate\u0026gt;xyz\u0026lt;/ds:X509Certificate\u0026gt; \u0026lt;/ds:X509Data\u0026gt; \u0026lt;/ds:KeyInfo\u0026gt; \u0026lt;/md:KeyDescriptor\u0026gt; \u0026lt;md:NameIDFormat\u0026gt;urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified\u0026lt;/md:NameIDFormat\u0026gt; \u0026lt;md:NameIDFormat\u0026gt;urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress\u0026lt;/md:NameIDFormat\u0026gt; \u0026lt;md:SingleSignOnService Binding=\u0026#34;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST\u0026#34; Location=\u0026#34;https://domain.okta.com/app/domain_sysdigsecure/sso/saml\u0026#34;/\u0026gt; \u0026lt;md:SingleSignOnService Binding=\u0026#34;urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect\u0026#34; Location=\u0026#34;https://domain.okta.com/app/domain_sysdigsecure/sso/saml\u0026#34;/\u0026gt; \u0026lt;/md:IDPSSODescriptor\u0026gt; \u0026lt;/md:EntityDescriptor\u0026gt; Configure SysdigOpen the SAML Connection Settings page and enter the Metadata URL you have copied earlier in the Metadata field.\n","url":"https://docs.sysdig.com/en/administration/onprem-saml-okta/"},{"id":253,"title":"Okta Integration","content":"Okta, which manages internal and external access to systems with a single login, is the leading platform in Identity-as-a-Service. As such, it has been the target of malicious attacks which may expose users\u0026rsquo; most critical assets and services. Enterprises can protect this area of their infrastructure using Sysdig\u0026rsquo;s log analysis Okta integration.\nPrerequisites Sysdig Secure SaaS and Admin permissions An Okta organization Super Administrator Okta account permissions Add IntegrationThe integration toggles between the Sysdig Secure UI and the Okta UI.\nStart from Sysdig Secure Log in to Sysdig Secure as Admin and select Integrations \u0026gt; Identity \u0026amp; Audit Logs.\nSelect Add Integration.\nEnter your Okta organization name or the URL for your Okta organization and click Launch Okta.\nYou are transferred to the Okta admin dashboard, to install the Sysdig API Service Integration.\nBy clicking on \u0026ldquo;Install \u0026amp; Authorize\u0026rdquo;, you will be provided with a Client Secret. The authentication secret is periodically rotated for an additional layer of security.\nCopy it and go back to Sysdig to paste it in the installation wizard.\nNow return to Okta and do the same with the Client ID.\nClick Validate Connection in the Sysdig wizard.\nWhen connection is established, click Complete as prompted.\nLogs from your Okta organization will be live-streamed to Sysdig. Sysdig performs threat detection through the configured policies and detections are reported as Runtime Events.\nStart from OktaWhen you install the API Service Integration app for Sysdig from Okta’s Admin Dashboard, the installation will prompt you to copy your Client Secret and Client ID. Save these to use on the Sysdig side.\nNow:\nLog in to Sysdig Secure SaaS as Admin and go to Integrations \u0026gt; Identity \u0026amp; Audit Logs.\nSelect Add Integration choose the option If you\u0026rsquo;ve already installed the Sysdig API Integration.\nEnter the Client Secret, Okta Domain, and Client ID you saved from Okta (toggling back to the Okta interface if needed).\nClick Validate Connection, and Complete.\nTroubleshoot the InstallationIf the installation is failing, you can:\nEnsure that among the API Service integrations listed on Okta, the one you chose is called \u0026ldquo;Sysdig\u0026rdquo;. Repeat the flow starting from Okta if you previously started from Sysdig, or vice-versa. Re-install the Sysdig API Service integration on Okta and copy all the values to Sysdig. Check that your Okta organization hasn\u0026rsquo;t already reached the maximum number of allowed Event Hooks. ValidateCheck the Connection StatusCheck the connection status of your integration in the Events page by navigating to Detection \u0026amp; Response \u0026gt; All Events. Select Okta from the Event Source drop-down menu.\nSee Events \u0026amp; Logs connection status.\nReview Okta Policies and RulesYou can review the suite of Okta-related managed policies delivered out-of-the-box and/or create custom policies of the type Okta.\nTo see the standard managed policies:\nIn Sysdig Secure, select Policies \u0026gt; Runtime Policies.\nFor the Managed Type filter, select Managed Policy and for the Select policy type filter, select Okta.\nThe list of default managed policies is displayed. Select one to review the rules that comprise it.\nIf desired, you can create custom Okta policies in the usual way.\nCheck Event Feed for Okta Entries In Sysdig Secure, select Detection \u0026amp; Response \u0026gt; All Events.\nEnter Okta in the Event Source search drop-down. Select any resulting policies in the list to drill into event details.\nEvents should arrive immediately after successful integration. If nothing appears within five minutes, check the status of Sysdig SaaS on https://sysdig.com/company/sysdig-status/.\nDelete an IntegrationIf you delete a configured integration:\nThe listing is removed from the Identity \u0026amp; Audit Logs page, located under Integrations Sysdig stops receiving logs from Okta Any created runtime events remain in the Events feed Appendix: Okta SetupSysdig relies on an API Service Integration to connect with your Okta organization. The integration provisions an Event Hook configured to send Sysdig the following events categories:\napplication.user_membership.add group.user_membership.add system.api_token.create system.org.rate_limit.violation user.account.lock user.account.privilege.grant user.account.reset_password user.account.update_password user.authentication.auth_via_mfa user.authentication.sso user.lifecycle.activate user.lifecycle.create user.lifecycle.deactivate user.lifecycle.suspend user.lifecycle.unsuspend user.mfa.factor.deactivate user.mfa.factor.reset_all user.session.start ","url":"https://docs.sysdig.com/en/sysdig-secure/integrations-okta/"},{"id":254,"title":"Group Mappings for Okta","content":" Log in to the Okta portal.\nFind the relevant SAML 2.0 Sysdig application from the Applications list.\nOn the General tab, scroll down to SAML settings and select Edit.\nSkip the General Settings by selecting Next.\nScroll down to Group Attribute Statements (optional).\nIn the Group Attribute Statements (optional) screen, specify the following:\nName: Attribute name, for example, \u0026ldquo;groups\u0026rdquo;. Name format: You can leave this as Unspecified unless there is a reason to change it. Filter: Here you can filter the group information that will be passed to Sysdig by several criteria. Choose the one that works best for you. If you want to send all group information, pick Matches regex from the dropdown menu and enter .* . Select Next, then Finish.\nLearn More Group Mappings for SAML Azure Active Directory Google Workspace ","url":"https://docs.sysdig.com/en/administration/group-mappings-okta_saml/"},{"id":255,"title":"Optimize AWS Group Entitlements","content":"Manage Group Entitlements with Detail DrawersThe Groups page organizes everything around the group.\nSummary: Displays the critical permissions issues detected for this group, sorted by Permission Criticality and Unused Permission Criticality. Risk Overview: Displays the critical permissions issues detected for this group, sorted by Permission Criticality and Unused Permission Criticality. Details: Displays a summary of this group\u0026rsquo;s details, including creation date, number of users, number of policies, and ARN details. Remediation Strategies: Displays remediation strategies, where applicable. See Apply Remediation Strategies. Connected IAM Resources: Displays the users that are members of this group and the policies that are associated with the group. Policies are sorted by unused permissions. To reduce entitlements for a particular Group, click on its name to open the detail drawer and subtabs. The remediation options for groups work similarly to users and roles.\nApply Remediation StrategiesSee the AWS User Optimization Examples and follow the same basic pattern for Groups. You can:\nAnalyze the group permissions details\nCreate a group-specific optimized policy\nOptimize a policy globally.\nFor more information, see the example.\nDelete an unused policy\nUser Permission WarningThe Users list in the Groups detail sub-tab may display a warning emoji when a user has been assigned permissions outside the group. We recommend streamlining user permissions and using group permissions when possible.\n","url":"https://docs.sysdig.com/en/sysdig-secure/optimize-aws-groups/"},{"id":256,"title":"Optimize AWS Role Entitlements","content":"Manage Role Entitlements with Detail DrawersThe Roles page organizes everything around the AWS role.\nSummary: Displays the critical permissions issues detected for this role, sorted by Permission Criticality and Unused Permission Criticality. Remediation Strategies: Summarizes all the potential strategies to reduce the permissions for this role. Connected IAM Resources: Displays a summary of this role\u0026rsquo;s total granted permissions, group associations, activity, user ARN ID, and findings. Displays the policies to which this role is connected, sorted by unused permissions. To reduce a role’s entitlements, click on the role name to open the detail drawer and subtabs. The remediation options for roles work the same way as for Users.\nRemediation StrategiesSee the AWS User Optimization Examples and follow the same pattern for Roles. You can:\nAnalyze the Role Permissions Details Optimize a policy globally Create a role-specific optimized policy Delete an unused policy ","url":"https://docs.sysdig.com/en/sysdig-secure/optimize-aws-roles/"},{"id":257,"title":"Optimize AWS User Entitlements","content":"Manage User Entitlements with Detail DrawersThe Users page organizes everything around the individual user account.\nOverview: Displays the critical permissions issues detected for this user account, sorted by Permission Criticality and Unused Permission Criticality. Attached IAM Policies: Displays the policies this user account is connected to, sorted by unused permissions and total permissions included in the policy. Attached Groups: Displays the groups this user account is connected to, sorted by unused permissions and permissions count. User Details: Displays a summary of total granted permissions, group associations, activity, user ARN ID, and findings associated with the select user account. To reduce a user entitlements, click on the user name to open the detail drawer and sub-tabs. The following examples provide various remediation options.\nUnderstand User Permissions Total Permissions are the total number of permissions granted to a user from all the policies the user is associated with. Unused Permissions/Permissions Unused are the total number of unused permissions from all the user\u0026rsquo;s policies. Permissions Given are the permissions granted to a user per policy. Investigate the Attached IAM Policies tab in a user\u0026rsquo;s detail drawer to see how the permission totals are divided and how to handle the surfaced risks.\nFor example, this user has been granted 15521 permissions, divided between multiple policies, all of which are unused.\nTo remediate the permissions in this example, you might:\nDelete an unused policy: In the example above, the policy with 103 permissions given has not been used by any IAM entity. Sysdig recommends removing this policy from your AWS environment.\nOptimize the Policy Globally.\nFor more information, see Create an Optimized User Policy.\nCreate an Optimized User Policy.\n​\tSee Understanding the Suggested Policy Changes for more information.\nApply Remediation StrategiesSysdig suggests the following remediation possibilities.\nCreate an Optimized User PolicyOn the Connected IAM Resources tab, select the policy you want to optimize. Open the Details tab of the policy, select Remediation Strategies, and click Optimize this IAM Policy with a subset of only used permissions. You can then download the suggested policy, upload it to your AWS Console, and associate it with this user. This option creates a new, user-specific policy that considers all the policies with which the user is associated.\nYou can also note the user\u0026rsquo;s policy associations listed in the Attached IAM Policies subtab and remove those associations in AWS.\nDelete an Inactive UserSometimes, a user may be associated with multiple policies and groups and have a very high cumulative number of permissions granted, but Sysdig detects no user activity in the environment for over 400 days. In this case, removing the user from your cloud environment is recommended.\nIn the example above, this would eliminate all 15,521 permissions granted and remove this identified Critical risk.\nOptimized for Potential CompromiseSysdig tracks all the permissions used by a user after they are flagged as potentially compromised. By default, these permissions are excluded from policy optimizations. This careful scrutiny helps maintain the integrity of security policies by granting only legitimate permissions and reducing the risk of privilege escalation and lateral movement by threat actors. This proactive approach helps ensure that policy optimizations remain secure against malicious actions.\nUse Case: Potentially Compromised UserOverly permissive credentials can lead to lateral movement and privilege escalation, resulting in cloud breaches. Sysdig helps prevent attacks by strengthening your identity posture by detecting anomalous or suspicious user actions and enabling real-time incident response. Sysdig offers the following findings to help correlate identity behavior with events, enabling detection and response to compromised user identities.\nPotentially Compromised User: Misconfigured identities and secrets, combined with certain operation patterns, often indicate a breach. Sysdig Threat Detection rules can identify suspicious account activity, such as privilege escalation and multiple account creations and flags these as Potentially Compromised, helping you start investigating promptly.\nPotentially Compromised is the finding that is triggered when Sysdig detects anomalous or suspicious user actions. It indicates that you should investigate this user.\nCompromised User: You have the capability to flag a user as Confirmed Compromised and it serves as a clear signal that the incident has been thoroughly triaged and is not a false positive. You can then take appropriate actions, such as deleting access keys, or deactivating or deleting the user.\nSysdig provides recommendations for each option, guiding you through the necessary steps to address the compromise. You see these recommendations when a user is flagged as Potentially Compromised, and they remain the same even if you mark the user as Compromised.\nAdditionally, you can view Potentially Compromised User Risk findings in the Risk module and pivot from a finding to the Identity \u0026gt; Overview panel for the affected AWS IAM user.\nCorrelate Events to IdentitiesThe Sysdig Events page displays the policy rule that triggered each event along with the associated user details, and it allows filtering. For example, you could filter by the Advanced Cloud Behavioral Analytics policy to find if any user has been identified as Potential Compromised. These event, essentially, indicate that an identity breach has occurred.\nTriage the EventYou can then triage the event as follows:\nClick one of the events to open the Events Details panel.\nClick Investigate.\nYou will directed to the Identity Investigation page, where you can see the cloud account, IP address, AWS region, user in question, and the user activities.\nClick the user to:\nSummary: View a summary of unused permissions, total permissions, criticality of permissions and unused permissions. The critically is determined by the excessive permission granted to the user through the roles attached to the User. The details panel also shows when the user was last active, User ARN, and account ID.\nThe Summary tab also shows that if the user is Compromised or Potentially Compromised.\nSysdig does not automatically mark a user as Compromised. After you review a Potentially Compromised User in the Identity \u0026gt; Findings panel, you can update the user\u0026rsquo;s status to keep it aligned with your investigation and response:\nRespond:\nMark as Compromised – confirm compromise. Mark as Compromise Resolved – indicate that remediation is complete. Remove Potentially Compromised flag – clear the flag and corresponding Risk finding if you confirm a false positive. Remove Compromised Flag – revert a user from Compromised back to Potentially Compromised when appropriate. Remediation Strategies: Provides two high level strategies to mitigate the risk.\nIn the Identity \u0026gt; Findings panel, click a user to open the drawer and choose the Remediate tab. It provides two high-level remediation strategies. Under Contain Compromise, you can address the compromise in the following ways:\nAdd Restrictive Policy for IP Deactivate User Delete User Force Password Reset Delete \u0026amp; Create New Access Keys Consolidate and Reduce Permissions : Create a new custom IAM Policy for the User with a subset of only used permissions. Select a strategy you prefer.\nFor example, if you decide to delete the user, mouse over Delete User and click View Remediation.\nView the remediation instructions for both AWS Management Console and AWS CLI.\nClick Open in Console to open the AWS Management Console to perform the actions given in the remediation instructions.\nOptionally, you can perform the operations using the AWS CLI.\nIf you want to consolidate and reduce the permissions assigned to the user, click View Remediation button next to the Create a new custom IAM Policy for this User with a subset of only used permissions option.\nSysdig offers smart policy optimization that excludes permissions used after a user is flagged as Potentially Compromised.\nReview the IAM policies and instructions to create a new IAM policy.\nClick Open in Console to open the AWS Management Console to perform the actions given in the remediation instructions.\nReturn to Sysdig Secure UI and mark the AWS IAM user as Compromise Resolved, as given in step 3.\nRemediation Strategies to Contain CompromiseThe following are the remediations strategies to address a Compromised AWS user. See the AWS Documentation for the up-to-date information.\nYou can use either AWS Management console or the AWS CLI to perform the operations.\nDeactivate UserAWS Management Console Sign in to the AWS and open the IAM Console.\nOn the navigation pane, select Users.\nChoose the user you want to deactivate.\nOpen the Permissions tab.\nClick Add inline policy.\nIn the JSON tab, paste the following policy to deny all the actions:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Effect\u0026#34;: \u0026#34;Deny\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;*\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } ] } Review the policy and click Create policy.\nAWS CLI Open your terminal or the command prompt.\nCreate a JSON file, for example deny_all_policy.json, with the following content.\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Effect\u0026#34;: \u0026#34;Deny\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;*\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } ] } Run the following command to attach the policy to the user:\naws iam put-user-policy --user-name \u0026lt;USERNAME\u0026gt; --policy-name DenyAllPolicy --policy-document file://deny_all_policy.json Replace with the actual username.\nDelete UserAWS Management Console Sign in to the AWS and open the IAM Console. On the navigation pane, select Users. Select the user name that you want to delete. At the top of the page, choose Delete. In the confirmation dialog box, enter the username in the text input field and confirm the deletion of the user. Click Delete. AWS CLI Delete the user password:\naws iam delete-login-profile Delete the user access keys:\naws iam list-access-keys # list the access keys aws iam delete-access-key # delete the access key Delete the user signing certificate:\naws iam list-signing-certificates # list the user\u0026#39;s signing certificates aws iam delete-signing-certificate # delete signing certificate Note that when you delete a security credential, it cannot be retrieved.\nDelete the user\u0026rsquo;s SSH public key:\naws iam list-ssh-public-keys # list the user\u0026#39;s SSH public keys aws iam delete-ssh-public-key # delete SSH public key Delete the user\u0026rsquo;s Git credentials.\naws iam list-service-specific-credentials # list the user\u0026#39;s git credentials aws iam delete-service-specific-credential Deactivate the user\u0026rsquo;s multi-factor authentication (MFA) device, if the user has one.\naws iam list-mfa-devices # list the user\u0026#39;s MFA devices aws iam deactivate-mfa-device # deactivate the device aws iam delete-virtual-mfa-device # permanently delete a virtual MFA device Delete the user inline policies.\naws iam list-user-policies # list the inline policies for the user aws iam delete-user-policy # delete the policy Detach any managed policies that are attached to the user.\naws iam list-attached-user-policies # list the managed policies attached to the user aws iam detach-user-policy # detach the policy Remove the user from any user groups.\naws iam list-groups-for-user # list the user groups to which the user belongs aws iam remove-user-from-group Delete the user.\naws iam delete-user Add Restrictive Policy for IPCreate an identity-based policy that denies access to all AWS operations in the account if the request originates from principals outside the specified IP ranges. This policy is useful when the IP addresses of your organization fall within the specified ranges. In this example, access will be denied unless the request comes from the CIDR ranges 192.0.2.0/24 or 203.0.113.0/24.\nAWS Management Console Sign in to the AWS and open the IAM Console.\nOn the navigation pane, select Users.\nChoose the user you want to deactivate.\nSelect the Permissions tab and click Add inline policy.\nIn the JSON tab, enter the following policy to deny all actions:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: { \u0026#34;Effect\u0026#34;: \u0026#34;Deny\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;*\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34;, \u0026#34;Condition\u0026#34;: { \u0026#34;NotIpAddress\u0026#34;: { \u0026#34;aws:SourceIp\u0026#34;: [ \u0026#34;192.0.2.0/24\u0026#34;, \u0026#34;203.0.113.0/24\u0026#34; ] } } } } Review the policy and click Create policy.\nAWS CLI Open the terminal or a command prompt.\nCreate a JSON file, for example deny_all_source_policy.json, with the following content:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: { \u0026#34;Effect\u0026#34;: \u0026#34;Deny\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;*\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34;, \u0026#34;Condition\u0026#34;: { \u0026#34;NotIpAddress\u0026#34;: { \u0026#34;aws:SourceIp\u0026#34;: [ \u0026#34;192.0.2.0/24\u0026#34;, \u0026#34;203.0.113.0/24\u0026#34; ] } } } } Run the following command to attach the policy to the IAM user:\naws iam put-user-policy --user-name \u0026lt;USERNAME\u0026gt; --policy-name DenyAllSourcePolicy --policy-document file://deny_all_source_policy.json Replace with the actual username.\nForce Password ResetAWS Management Console Sign in to the AWS and open the IAM Console. On the navigation pane, select Users. Choose the user you want to force password reset. Select the Security credentials tab. Click Manage console access and select Reset password. Select User must create new password at next sign-in. Click Reset password. AWS CLI Open the terminal or a command prompt.\nRun the following command to require a password reset:\naws iam update-login-profile --user-name \u0026lt;USERNAME\u0026gt; --password-reset-required ​\tReplace with the actual username.\nDelete and Create New Access KeysAWS Management Console Sign in to the AWS and open the IAM Console. On the navigation pane, select Users. Choose the user you want to force password reset. Select the Security credentials tab and locate the Access keys section. Select Delete from the Actions drop-down. Click on Deactivate. To confirm deletion, enter the access key ID in the text input field, and select Delete. Select the User must create new password at next sign-in. Click Reset password. To create a new access key:\nClick Create access key.\nClick Download .csv file or Show to save the new access key securely.\nMake sure that you store the new access key and secret access key in a secure place, as you will not be able to view the secret access key again.\nAWS CLI Open your terminal or command prompt.\nList the current access keys for the user to identify which keys exist:\naws iam list-access-keys --user-name \u0026lt;USERNAME\u0026gt; Replace \u0026lt;USERNAME\u0026gt; with the actual username. Delete an existing access key:\naws iam delete-access-key --user-name \u0026lt;USERNAME\u0026gt; --access-key-id \u0026lt;ACCESSKEYID\u0026gt; Replace with the actual username and with the ID of the access key you want to delete.\nCreate a new access key:\naws iam create-access-key --user-name \u0026lt;USERNAME\u0026gt; Replace with the actual username.\n","url":"https://docs.sysdig.com/en/sysdig-secure/optimize-aws-users/"},{"id":258,"title":"Optimize Azure Group Entitlements","content":"Manage Group Entitlements with Detail DrawersTo reduce the entitlements for a particular group, click on the account name to open the detail drawer and sub-tabs.\nThe Groups page organizes everything around the individual group.\nSummary: Displays the critical permissions issues detected for this group, sorted by Permission Criticality and Unused Permission Criticality. Remediation Strategies: Summarizes all the potential strategies to reduce the permissions for this group. Connected IAM Resources: Displays the users that are members of this group and the roles that are associated with the group. Roles are sorted by unused permissions. If Sysdig has been profiling a group for less than 90 days, you will see the following message:\nWe recommend a 90 day period to pass before applying remediation optimizations to establish a good baseline for used permissions.\nUnderstand Group PermissionsHover over the % Unused Permissions column to see the permissions granted to a Azure group:\nTotal Permissions: The total number of permissions granted to a group from all the roles the group is connected to. Unused Permissions: The total number of unused permissions from all the roles that connected to a given group. Apply Remediation StrategiesClick on the remediation recommendation to address the identity risk.\nDetach Role from the Group All the roles that are totally unused by this group will get this recommendation If there are multiple detach recommendation, they are sorted based on the largest reduction in unused permissions. Consolidate PermissionsCreate a new custom role for the group with only a subset of used permissions.\nThis mechanism considers all the actions taken by this group across all its roles and consolidate them into one group-specific custom role. There will only be one custom role suggestion per group account.\nReduce Permissions with Existing RolesReplace the existing role with a different role.\nSysdig recommends replacing a connected role with an existing role that includes all the necessary permissions of the current role but with fewer overall permissions, ensuring the highest access level remains the same or lower.\n","url":"https://docs.sysdig.com/en/sysdig-secure/optimize-azure-groups/"},{"id":259,"title":"Optimize Azure Role Entitlements","content":"Manage Role Entitlements with Detail DrawersTo reduce the entitlements for a particular role, click on the role name to open the detail drawer and subtabs.\nThe Roles page organizes everything around the Azure role.\nSummary: Displays the critical permissions issues detected for this user, sorted by Permission Criticality and Unused Permission Criticality. Remediation Strategies: Summarizes all the potential strategies to reduce the permissions for this user. Connected IAM Resources: Displays a summary of this role’s total granted permissions, group associations, activity, and service principals. Displays the policies to which this role is connected, sorted by unused permissions. If Sysdig has been profiling a user for less than 90 days, you will see the following message:\nWe recommend a 90 day period to pass before applying remediation optimizations to establish a good baseline for used permissions.\nUnderstand Role PermissionsHover over the % Unused Permissions column to see the permissions granted to a role:\nTotal Permissions: The total number of permissions granted to a role Unused Permissions: The total number of unused permissions from all the connected entities. Remediation Strategies Detach Users from this Role.\nAll the Users that have not used any permissions from this connected role can be detached\nDetach Service Accounts from this Role\nAll the Service Accounts that have not used any permissions from this connected role can be detached\nDetach Groups from this Role\nAll the Groups that have not used any permissions from this connected role can be detached\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/identity/roles/optimize-azure-roles/"},{"id":260,"title":"Optimize Azure Service Principal Entitlements","content":"Manage Service Principal Entitlements with Detail DrawersTo reduce the entitlements for a particular service principal, click on the service principal to open the detail drawer and sub-tabs.\nThe Service Principals page organizes everything around the individual service principal.\nSummary: Displays the critical permissions issues detected for this service principal, sorted by Permission Criticality and Unused Permission Criticality. Remediation Strategies: Summarizes all the potential strategies to reduce the permissions for this service principal. Connected IAM Resources: Displays a summary of total granted permissions, group associations, activity, and secret. If Sysdig has been profiling a service principal for less than 90 days, you will see the following message:\nWe recommend a 90 day period to pass before applying remediation optimizations to establish a good baseline for used permissions.\nUnderstand Service Principal PermissionsMouse over the % Unused Permissions column to view the permissions:\nTotal Permissions: The total number of permissions granted to a service principal from all the roles that the service principal is connected to. Unused Permissions: The total number of unused permissions from all the roles that connected to a service principal. Apply Remediation StrategiesDetach Role from the service principal All the roles that are totally unused by this service principal will get this recommendation If there are multiple detach recommendation, they are sorted based on the largest reduction in unused permissions. Consolidate and Reduce PermissionsCreate a new custom role for this service principal with a subset of only used permissions.\nThis mechanism considers all the actions taken by this service principal across all its roles and consolidate them into one service principal-specific custom role. There will only be one custom role suggestion per service principal.\nReduce Permissions with Existing RolesReplace the existing Role with a different Role.\nSysdig recommends replacing a connected role with an existing role that includes all the necessary permissions of the current role but with fewer overall permissions, ensuring the highest access level remains the same or lower.\n","url":"https://docs.sysdig.com/en/sysdig-secure/optimize-azure-service-principals/"},{"id":261,"title":"Optimize Azure User Entitlements","content":"Manage User Entitlements with Detail DrawersTo reduce the entitlements for a particular user, click on the account name to open the detail drawer and sub-tabs.\nThe Users page organizes everything around the individual user.\nSummary: Displays the critical permissions issues detected for this user, sorted by Permission Criticality and Unused Permission Criticality. Remediation Strategies: Summarizes all potential strategies to reduce the permissions for this user. If Sysdig has been profiling a user for less than 90 days, you will see the following message:\nWe recommend a 90 day period to pass before applying remediation optimizations to establish a good baseline for used permissions.\nUnderstand User PermissionsHover over the % Unused Permissions column to see the permissions granted to a user:\nTotal Permissions: The total number of permissions granted to a user from all the roles the user is connected to. Unused Permissions: The total number of unused permissions from all the roles that connected to a user. Remediation StrategiesDetach Role from this User All the roles that are totally unused by this user will get this recommendation. If there are multiple detach recommendations, they are sorted based on the largest reduction in unused permissions. Consolidate PermissionsCreate a new custom role for the user with only a subset of used permissions.\nThis mechanism considers all actions taken by this user across all its roles and consolidates them into one user-specific custom role. There will only be one custom role suggestion per user.\nReduce Permissions with Existing RolesReplace the existing role with a different role.\nSysdig recommends replacing a connected role with an existing role that contains all the permissions used by the current role but has fewer total permissions overall.\nEnable No MFA FindingsThe No MFA finding is not enabled by default for Azure accounts. If you want to capture those findings do the following on your Azure account:\nLog in to https://portal.azure.com/.\nSelect the appropriate Directory or Tenant.\nSearch for Enterprise Application.\nClick Enterprise Application and click View.\nOn the All Applications page, search for Sysdig.\nSelect the application with the name sysdig-secure-ENV_NAME.\nOn the left navigation pane, click Permissions.\nIf you do not see UserAuthenticationMethod.Read.All, click the Grant admin consent for button.\nOnce you complete these settings, wait for the next scan to display the No MFA finding for users that have no MFA set.\n","url":"https://docs.sysdig.com/en/sysdig-secure/optimize-azure-users/"},{"id":262,"title":"Optimize GCP Group Entitlements","content":" Review the permissions that you can grant to the Sysdig service account by enabling domain-wide delegation.\nGuidelinesWhile you can grant roles to groups at the organization, folder, or project level in Google Cloud, the resource collection workflow currently only considers groups defined at the project level. This means that only groups explicitly specified in the policy bindings document are evaluated during processing, and displayed on the Dashboard \u0026gt; Identity page. Policy inheritance is not currently supported.\nManage Group Entitlements with Detail DrawersTo reduce the entitlements for a particular group, click on the account name to open the detail drawer and sub-tabs.\nThe Groups page organizes everything around the individual group.\nSummary: Displays the critical permissions issues detected for this group, sorted by Permission Criticality and Unused Permission Criticality. Remediation Strategies: Summarizes all the potential strategies to reduce the permissions for this group. Connected IAM Resources: Displays the users that are members of this group and the roles that are associated with the group. Roles are sorted by unused permissions. If Sysdig has been profiling a group for less than 90 days, you will see the following message:\nNote: Sysdig recommends a 90-days period to pass before applying remediation optimizations to establish a good baseline for used permissions.\nUnderstand Group PermissionsHover over the % Unused Permissions column to see the permissions granted to a GCP group:\nTotal Permissions: The total number of permissions granted to a group from all the roles the group is bound to. Unused Permissions: The total number of unused permissions from all the roles that bound to a given group. Apply Remediation StrategiesClick on the remediation recommendation to address the identity risk.\nDetach Role from the Group All the roles that are totally unused by this group will get this recommendation If there are multiple detach recommendation, they are sorted based on the largest reduction in unused permissions. Consolidate PermissionsCreate a new custom role for the group with only a subset of used permissions.\nThis mechanism considers all the actions taken by this group across all its roles and consolidate them into one group-specific custom role. There will only be one custom role suggestion per group account.\nReduce Permissions with Existing RolesReplace the existing role with a different role.\nSysdig recommends replacing a bound role with an existing role that contains all the permissions used by the current role but has fewer total permissions overall.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/identity/groups/optimize-gcp-groups/"},{"id":263,"title":"Optimize GCP Role Entitlements","content":" Review the permissions that you can grant to the Sysdig service account by enabling domain-wide delegation.\nGuidelinesWhile Google Cloud, like other public cloud providers, offers a large number of roles and permissions, only the roles bound to at least one Google IAM principal are displayed on the identity roles page. This means that any roles not specified in the policy bindings associated with a member at the project level are not evaluated during processing and displayed on the Dashboard \u0026gt; Identity and scroll to the Service Identities section. Policy inheritance is not currently supported.\nManage Role Entitlements with Detail DrawersTo reduce the entitlements for a particular role, click on the role name to open the detail drawer and subtabs.\nThe Roles page organizes everything around the GCP role.\nSummary: Displays the critical permissions issues detected for this user, sorted by Permission Criticality and Unused Permission Criticality. Remediation Strategies: Summarizes all the potential strategies to reduce the permissions for this user. Connected IAM Resources: Displays a summary of this role\u0026rsquo;s total granted permissions, group associations, activity, user accounts, and findings. If Sysdig has been profiling a user for less than 90 days, you will see the following message:\nWe recommend a 90 day period to pass before applying remediation optimizations to establish a good baseline for used permissions.\nUnderstand Role PermissionsHover over the % Unused Permissions column to see the permissions granted to a role:\nTotal Permissions: The total number of permissions granted to a role Unused Permissions: The total number of unused permissions from all the bounded entities. Remediation Strategies Detach Users from this Role.\nAll the Users that have not used any permissions from this bound role can be detached\nDetach Service Accounts from this Role\nAll the Service Accounts that have not used any permissions from this bound role can be detached\nDetach Groups from this Role\nAll the Groups that have not used any permissions from this bound role can be detached\n","url":"https://docs.sysdig.com/en/sysdig-secure/optimize-gcp-roles/"},{"id":264,"title":"Optimize GCP Service Account Entitlements","content":" Review the permissions that you can grant to the Sysdig service account by enabling domain-wide delegation.\nGuidelinesWhile you can grant roles to service accounts at the organization, folder or project level in Google Cloud, the resource collection workflow currently only considers service accounts defined at the project level. This means that only service accounts explicitly specified in the policy bindings document are evaluated during processing. To see Critical and High Severity Findings, go to the Dashboards \u0026gt; Identity page. Policy inheritance is not currently supported. To see detailed findings, navigate to Attack Surface \u0026gt; Identity Findings.\nManage Service Account Entitlements with Detail DrawersTo reduce the entitlements for a particular service account, click on the service account to open the detail drawer and sub-tabs.\nThe Service Accounts page organizes everything around the individual service account.\nAffected Indentity Summary: Displays the critical permissions issues detected for this service account, sorted by Permission Criticality and Unused Permission Criticality. Remediate: Summarizes all the potential strategies to reduce the permissions for this service account. Connected IAM Resources: Displays a summary of total granted permissions, role and group associations, and keys. If Sysdig has been profiling a service account for less than 90 days, you will see the following message:\nWe recommend a 90 day period to pass before applying remediation optimizations to establish a good baseline for used permissions.\nUnderstand Service Account PermissionsMouse over the % Unused Permissions column to view the permissions:\nTotal Permissions: The total number of permissions granted to a service account from all the roles that the service account is bound to. Unused Permissions: The total number of unused permissions from all the roles that bound to a service account. Apply Remediation StrategiesDetach Role from the Service Account All the roles that are totally unused by this service account will get this recommendation If there are multiple detach recommendation, they are sorted based on the largest reduction in unused permissions. Consolidate and Reduce PermissionsCreate a new custom role for this service account with a subset of only used permissions.\nThis mechanism considers all the actions taken by this service account across all its roles and consolidate them into one service account-specific custom role. There will only be one custom role suggestion per service account.\nReduce Permissions with Existing RolesReplace the existing Role with a different Role.\nSysdig suggests replacing a bound role with another existing role that includes all the permissions currently used by this role but has fewer total permissions overall.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/identity/service-accounts/optimize-gcp-service-accout/"},{"id":265,"title":"Optimize GCP User Entitlements","content":" Review the permissions that you can grant to the Sysdig service account by enabling domain-wide delegation.\nGuidelinesWhile you can grant roles to users at the organization, folder, or project level in Google Cloud, the resource collection workflow currently only considers users defined at the project level. This means that only users explicitly specified in the policy bindings document are collected during the scan, evaluated during processing, and displayed on the Dashboard \u0026gt; Identity page. Policy inheritance is not currently supported.\nManage User Entitlements with Detail DrawersTo reduce the entitlements for a particular user, click on the account name to open the detail drawer and sub-tabs.\nThe Users page organizes everything around the individual user.\nSummary: Displays the critical permissions issues detected for this user, sorted by Permission Criticality and Unused Permission Criticality. Remediation Strategies: Summarizes all the potential strategies to reduce the permissions for this user Connected IAM Resources: Shows all the IAM resources that are associated with the selected user. Select a resource, such as a role, group, or policy, to take further remediation actions, or view a summary of permission criticality. If Sysdig has been profiling a user for less than 90 days, you will see the following message:\nWe recommend a 90 day period to pass before applying remediation optimizations to establish a good baseline for used permissions.\nUnderstand User PermissionsHover over the % Unused Permissions column to see the permissions granted to a user:\nTotal Permissions: The total number of permissions granted to a user from all the roles the user is bound to. Unused Permissions: The total number of unused permissions from all the roles that bound to a user. Remediation StrategiesDetach Role from this User All the roles that are totally unused by this user will get this recommendation If there are multiple detach recommendation, they are sorted based on the largest reduction in unused permissions. Consolidate PermissionsCreate a new custom role for the user with only a subset of used permissions.\nThis mechanism considers all the actions taken by this user across all its roles and consolidate them into one user-specific custom role. There will only be one custom role suggestion per user.\nReduce Permissions with Existing RolesReplace the existing role with a different role.\nSysdig recommends replacing a bound role with an existing role that contains all the permissions used by the current role but has fewer total permissions overall.\n","url":"https://docs.sysdig.com/en/sysdig-secure/optimize-gcp-users/"},{"id":266,"title":"Install Host Shield from a Package","content":"Prerequisites Review System Requirements Understand Agent Drivers Collect the following: Sysdig Access Key Collector Address and Port for COLLECTOR and PORT Secure API Endpoint to use for SYSDIG_API_ENDPOINT System Requirements A supported distribution or Kubernetes platform\nPort 6443 open for outbound traffic\nThe Host Shield communicates with the collector on port 6443. If you\u0026rsquo;re using a firewall, make sure to open port 6443 for outbound traffic so that the Host Shield can communicate with the collector.\nAllow traffic on port 12000 to communicate within the cluster for Kubernetes Security Posture Management (KSPM).\nKubernetes PlatformsThe supported Kubernetes platforms are:\nKubernetes (Vanilla)\nAmazon Elastic Kubernetes Service (EKS)\nNote: AWS Fargate is not supported on EKS\nGoogle Kubernetes Engine (GKE)\nAzure Kubernetes Service (AKS)\nRedHat Openshift\nIBM Kubernetes Service (IKS)\nRKE Government (RKE2)\nLinux DistributionsThe supported Linux distributions are:\nDebian Ubuntu 18.04 and above Ubuntu (Amazon) CentOS 7 and above Alma Linux Rocky Linux Red Hat Enterprise Linux (RHEL) 7 and above SuSE Linux Enterprise Server* RHEL CoreOS (RHCOS) Fedora Fedora CoreOS Linux Mint Amazon Linux (Original) Amazon Linux 2 (AL2) Amazon Linux 2023 (AL2023) Amazon Bottlerocket Google Container Optimized OS (COS) Oracle Linux (UEH) Oracle Linux (RHCK) Azure Linux (CBL-Mariner) EulerOS ArchLinux Alpine Linux 3.20 and above We may support additional Linux distributions depending on the feature required. For more details, Contact Sysdig Support.\nCPU ArchitecturesThe supported CPU architectures are:\nX86 ARM Migrate to Host ShieldYou can enable additional features such as Host Scanning, Host Security Posture Management, and Rapid Response directly from the package configuration.\nPackage Reference Driver Main Package Dependency Packages kmod (compatibility mode) draios-agent draios-agent-slim, draios-agent-kmodule kmod (recommended) draios-agent-kmodule draios-agent-slim legacy_ebpf draios-agent-legacy-ebpf draios-agent-slim universal_ebpf draios-agent-slim Debian and Ubuntu Trust the Sysdig GNU Privacy Guard (GPG) key, configure the apt repository, and update the package list by running the following commands:\ncurl -s https://download.sysdig.com/DRAIOS-GPG-KEY.public -o /usr/share/keyrings/sysdig-keyring.asc echo \u0026#39;deb [signed-by=/usr/share/keyrings/sysdig-keyring.asc] https://download.sysdig.com/stable/deb stable-$(ARCH)/\u0026#39; | sudo tee /etc/apt/sources.list.d/sysdig.list \u0026gt; /dev/null apt-get update [kmod/legacy eBPF] Install kernel development files:\nsudo apt-get -y install linux-headers-$(uname -r) Install the Host Shield:\nsudo apt-get -y install draios-agent Specify the agent driver: To select the Universal eBPF driver (Recommended for Linux Kernel 5.8 and above):\nsudo bash -c \u0026#39;cat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=universal_ebpf\u0026#34;\u0026#39; To select the kernel module driver (Recommended for below Linux Kernel 5.8):\nsudo bash -c \u0026#39;cat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=kmod\u0026#34;\u0026#39; Note: On new installations, the kernel module driver is selected by default, and specifying it explicitly in /etc/default/dragent is optional.\nTo select the legacy eBPF driver (Not Recommended):\nsudo bash -c \u0026#39;cat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#39;export SYSDIG_BPF_PROBE=\u0026#34;\u0026#34;\u0026#39;\u0026#39; sudo bash -c \u0026#39;cat \u0026gt;\u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=legacy_ebpf\u0026#34;\u0026#39; Configure Host Shield dragent.yaml: Collect the following information associated with your private registry: Access Key.\nCollector URL.\nCollector Port.\nSysdig Secure API Endpoint.\nsudo bash -c \u0026#39;cat \u0026gt; /opt/draios/etc/dragent.yaml \u0026lt;\u0026lt;EOF customerid: \u0026lt;ACCESS_KEY\u0026gt; collector: \u0026lt;COLLECTOR_URL\u0026gt; collector_port: \u0026lt;COLLECTOR_PORT\u0026gt; host_scanner: enabled: true host_fs_mount_path: / kspm_analyzer: enabled: true host_root: / features: respond: response_actions: enabled: true detections: drift_control: enabled: true malware_control: enabled: true file_integrity_monitoring: enabled: true ml_policies: enabled: true sysdig_api_endpoint: \u0026lt;SECURE_API_ENDPOINT\u0026gt; EOF\u0026#39; Restart the Host Shield: sudo service dragent restart For CentOS, RHEL, Fedora, Amazon AMI, Amazon Linux 2 Trust the Sysdig GPG key and configure the yum repository:\nsudo rpm --import https://download.sysdig.com/DRAIOS-GPG-KEY.public \u0026amp;\u0026amp; sudo curl -s -o /etc/yum.repos.d/draios.repo https://download.sysdig.com/stable/rpm/draios.repo [kmod/legacy eBPF] Install the EPEL repository:\nsudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm This command is required only if DKMS is not available in the base distribution.\n[kmod/legacy eBPF] Install the kernel development files:\nsudo yum -y install kernel-devel-$(uname -r) Install the Host Shield:\nInstall the Host Shield: sudo bash yum -y install draios-agent Specify the Host Shield driver: To select the Universal eBPF driver (Recommended for Linux Kernel 5.8 and above):\nsudo bash -c \u0026#39;cat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=universal_ebpf\u0026#34;\u0026#39; To select the kernel module driver (Recommended for below Linux Kernel 5.8):\nsudo bash -c \u0026#39;cat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=kmod\u0026#34;\u0026#39; Note: On new installations, the kernel module driver is selected by default, and specifying it explicitly in /etc/sysconfig/dragent is optional.\nTo select the legacy eBPF driver (Not Recommended):\nsudo bash -c \u0026#39;cat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#39;export SYSDIG_BPF_PROBE=\u0026#34;\u0026#34;\u0026#39;\u0026#39; sudo bash -c \u0026#39;cat \u0026gt;\u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=legacy_ebpf\u0026#34;\u0026#39; Configure Host Shield dragent.yaml: Collect the following information associated with your private registry:\nAccess Key.\nCollector URL.\nCollector Port.\nSysdig Secure API Endpoint.\nsudo bash -c \u0026#39;cat \u0026gt; /opt/draios/etc/dragent.yaml \u0026lt;\u0026lt;EOF customerid: \u0026lt;ACCESS_KEY\u0026gt; collector: \u0026lt;COLLECTOR_URL\u0026gt; collector_port: \u0026lt;COLLECTOR_PORT\u0026gt; host_scanner: enabled: true host_fs_mount_path: / kspm_analyzer: enabled: true host_root: / features: respond: response_actions: enabled: true detections: drift_control: enabled: true malware_control: enabled: true file_integrity_monitoring: enabled: true ml_policies: enabled: true sysdig_api_endpoint: \u0026lt;SECURE_API_ENDPOINT\u0026gt; EOF\u0026#39; Start the Host Shield: sudo systemctl enable dragent sudo systemctl start dragent Configure Proxy SettingsFor standalone hosts, configure proxy settings as follows:\nHost shield Proxy ConfigurationAdd the following to /opt/draios/etc/dragent.yaml:\nhttp_proxy: proxy_host: \u0026lt;PROXY_HOST\u0026gt; proxy_port: \u0026lt;PROXY_PORT\u0026gt; Host Scanner and KSPM Analyzer Proxy ConfigurationFor host-scanner and kspm-analyzer components, set environment variables in the dragent environment file:\nFor Debian and Ubuntu: /etc/default/dragent For CentOS, RHEL, Fedora, Amazon AMI, Amazon Linux 2: /etc/sysconfig/dragent Add the following lines:\nHTTP_PROXY=http://\u0026lt;PROXY_HOST\u0026gt;:\u0026lt;PROXY_PORT\u0026gt; HTTPS_PROXY=http://\u0026lt;PROXY_HOST\u0026gt;:\u0026lt;PROXY_PORT\u0026gt; NO_PROXY=\u0026lt;NO_PROXY_LIST\u0026gt; Replace \u0026lt;PROXY_HOST\u0026gt;, \u0026lt;PROXY_PORT\u0026gt;, and \u0026lt;NO_PROXY_LIST\u0026gt; with your actual proxy details.\nAfter configuring proxy settings, restart the Host Shield:\nsudo service dragent restart Or for systemd:\nsudo systemctl restart dragent Enable Rapid ResponseRapid Response lets you remotely execute commands on your hosts for incident response and troubleshooting. This feature is disabled by default.\nIf you want to enable Rapid Response, add the following configuration to your dragent.yaml file:\nrapid_response: enabled: true password: \u0026lt;RR_PASSWORD\u0026gt; Later, you can use the password you set up here to Start Rapid Response.\n","url":"https://docs.sysdig.com/en/sysdig-secure/install-package-host-shield/"},{"id":267,"title":"Permissions and Resources","content":"Review AWS Roles and PermissionsSecurity PrincipalsThere are two identities involved in the onboarding process:\nInstaller: The Identity, either a User or Role that will be used to perform the onboarding. Sysdig does not have access to this identity. Sysdig: A set of IAM Roles created during onboarding with specific, less permissive permissions attached. Sysdig will be given access to these Roles. Base AWS Integration - Cloud Security Posture Management (CSPM)Agentless Cloud Security Posture Management (CSPM) assesses and manages the security posture of your cloud resources without requiring agents.\nPermissions Required to InstallThe Installer must have at least the following policies assigned in the AWS Account or Organization\u0026rsquo;s Management account:\nPolicy Description IAMFullAccess Required to create IAM Roles and associated permissions. (Organization only) AWSKeyManagementServicePowerUser This policy provides access to AWS Key Management Service (KMS). (Organization only) AWSCloudFormationFullAccess This policy is required to create a CloudFormation StackSet that creates IAM roles in each Account in your Organization. (Organization only) AWSOrganizationsReadOnlyAccess This policy is required to list Accounts and OUIDs in your Organization. Permissions Granted to SysdigThe Sysdig IAM Roles will have the following policies attached:\nRole Policy Description sysdig-secure-onboarding-XXXX AWSAccountManagementReadOnlyAccess Allows Sysdig to retrieve Account Alias (Organization only) sysdig-secure-onboarding-XXXX AWSOrganizationsReadOnlyAccess Allows Sysdig to list accounts in your Organization. sysdig-secure-posture-XXXX SecurityAudit Allows Sysdig to list resources within your Account. sysdig-secure-posture-XXXX A Custom IAM Policy containing the following permissions:- account:GetContactInformation- elasticfilesystem:DescribeAccessPoints- lambda:GetFunction- lambda:GetRuntimeManagementConfig- macie2:ListClassificationJobs- waf-regional:ListRuleGroups- waf-regional:ListRules Allows Sysdig to list resources within your Account that are not covered by the Security Audit policy. Resources CreatedThe following resources will be created in your AWS Environment:\nResource Description aws_iam_role IAM Role with the name sysdig-secure-onboarding-XXXX. This role is used to manage the lifecycle of your Sysdig integration. aws_iam_role IAM Role with the name sysdig-secure-posture-XXXX. This role is used for CSPM. (Organization only) aws_cloudformation_stack_set Used to deploy the above Roles across all Accounts in your Organization. (Organization only) aws_cloudformation_stack_set_instance Used to deploy the above Roles across all Accounts in your Organization. Log IngestionThe Log Ingestion component is used to enable Threat Detection and Cloud Infrastructure Entitlement Management (CIEM)\nPermissions Required to InstallThe Installer must have at least the following policies assigned in the AWS Account or Organization\u0026rsquo;s Management account:\nPolicy Description IAMFullAccess Required to create IAM Roles and associated permissions. AWSCloudFormationFullAccess Required to create a CloudFormation Stack/StackSet to provision the resources across your infrastructure. AWSOrganizationsReadOnlyAccess This policy is required to list Accounts and OUIDs in your Organization. Additionally, the S3 method requires some permissions on some resources:\nPermission(s) Description sns:Subscribe, sns:SetTopicAttributes, sns:GetTopicAttributes Required to subscribe to SNS. sns:CreateTopic Required to create a SNS topic, if absent on the target Trail cloudtrail:UpdateTrail Required to attach the SNS topic to the target Trail, if absent kms:GetKeyPolicy, kms:SetKeyPolicy Required to subscribe to allow Sysdig to decrypt CloudTrail files Permissions Granted to SysdigThe Sysdig IAM Role will have the following policies attached:\nEventBridge Setup Role Policy Description sysdig-secure-events-XXXX A Custom IAM Policy containing the following permissions:- events:PutEvents- events:DescribeRule- events:ListTargetsByRule Allows EventBridge to send events to Sysdig and Sysdig to inspect EventBridge resources to perform validation. S3 setup Role Policy Description sysdig-secure-cloudlogs-XXXX A Custom IAM Policy containing: s3:Get* and s3:List* to read the trail files in the S3 bucket. kms:Decrypt to decrypt files, when encrypted by CloudTrail with KMS Allows Sysdig to access the bucket, unencrypt the files if encrypted and download them to process the logs they contain. Resources CreatedThe following resources will be created in your AWS Environment based on the selected setup method:\nResource Method Description aws_iam_role Both IAM Role with the name sysdig-secure-events-XXXX/sysdig-secure-cloudlogs-XXXX. See more in Permissions Granted to Sysdig aws_iam_role EventBridge IAM Role with the name sydig-secure-events-XXXX-AdministrationRole. This role is used to deploy EventBridge Rules in the selected regions in your account. aws_iam_role EventBridge IAM Role with the name sysdig-secure-events-XXXX-ExecutionRole. This role is used to deploy EventBridge Rules in the selected regions in your account. aws_cloudformation_stack_set EventBridge Used to deploy EventBridge Rules/Role in each Account/Region in your Organization. aws_cloudformation_stack_set_instance EventBridge Used to deploy EventBridge Rules/Role in each Account/Region in your Organization. aws_cloudwatch_event_rule EventBridge Defines which logs are to be sent to Sysdig. Deployed in each of the specified accounts and regions aws_cloudwatch_event_target EventBridge Defines Sysdig as target for the aws_cloudwatch_event_rule. Deployed in each of the specified accounts and regions aws_sns_topic_subscription S3 Subscribes to the specified SNS topic, for Sysdig to receive updates on new CloudTrail files written Cloud Response ActionsThe Cloud Response Actions component is used to enable Threat Response.\nPermissions Required to InstallThe Installer must have at least the following policies assigned in the AWS Account or the Organization\u0026rsquo;s Management account:\nPolicy Description IAMFullAccess Required to create IAM Roles and associated permissions. AWSCloudFormationFullAccess Required to create a CloudFormation StackSet that creates KMS Keys/Aliases in each region of the target accounts (Organization only) AWSOrganizationsReadOnlyAccess This policy is required to list Accounts and OUIDs in your Organization. Permissions Granted to SysdigCloud Response Actions create a cross-account IAM role that Sysdig assumes to invoke Lambda functions, along with Lambda execution roles that perform the actual response actions.\nRole Policy Description sysdig-secure-ra-XXXX-cross-account-invoker A Custom IAM Policy containing:- tag:GetResources- lambda:InvokeFunction (for enabled response action Lambdas)- lambda:GetFunction (for enabled response action Lambdas) Allows Sysdig platform to invoke Response Action Lambda functions the configured account (management account in the Organizational case). sysdig-secure-ra-XXXX-quarantine-user-role A Custom IAM Policy containing:- IAM user and policy management permissions (iam:AttachUserPolicy, iam:DetachUserPolicy, iam:PutUserPolicy, iam:DeleteUserPolicy, iam:GetUser, etc.)- IAM role and policy read permissions- sts:AssumeRole, sts:GetCallerIdentity Allows the quarantine user Lambda to attach deny-all policies to IAM users and roles. sysdig-secure-ra-XXXX-remove-policy-role A Custom IAM Policy containing:- iam:DetachUserPolicy, iam:DetachRolePolicy- IAM user and role read permissions- sts:GetCallerIdentity, sts:AssumeRole Allows the remove policy Lambda to un-quarantine IAM users and roles. sysdig-secure-ra-XXXX-fetch-cloud-logs-role A Custom IAM Policy containing:- cloudtrail:LookupEvents- sts:GetCallerIdentity, sts:AssumeRole Allows the fetch cloud logs Lambda to retrieve CloudTrail logs. sysdig-secure-ra-XXXX-confi-res-access-role A Custom IAM Policy containing:- S3 public access block permissions (s3:GetBucketPublicAccessBlock, s3:PutBucketPublicAccessBlock)- RDS instance modification permissions (rds:DescribeDBInstances, rds:ModifyDBInstance)- sts:GetCallerIdentity, sts:AssumeRole Allows the make private Lambda to remove public access from S3 buckets and RDS instances. The same permission is used for public access restore (reverse action). sysdig-secure-ra-XXXX-create-vol-snap-role A Custom IAM Policy containing:- EC2 snapshot creation and tagging permissions (ec2:CreateSnapshot, ec2:CreateTags, ec2:DescribeInstances, ec2:DescribeVolumes, ec2:DescribeSnapshots)- CloudWatch Logs permissions- sts:GetCallerIdentity, sts:AssumeRole Allows the create volume snapshot Lambda to create EBS snapshots for forensic investigation. sysdig-secure-ra-XXXX-delete-vol-snap-role A Custom IAM Policy containing:- EC2 snapshot deletion permissions (ec2:DeleteSnapshot, ec2:DescribeSnapshots)- CloudWatch Logs permissions- sts:GetCallerIdentity, sts:AssumeRole Allows the delete volume snapshot Lambda to delete EBS snapshots. Resources CreatedThe following resources will be created in your AWS Environment:\nResource Description aws_iam_role Cross-account invoker role with the name sysdig-secure-ra-XXXX-cross-account-invoker. This role is assumed by Sysdig to invoke Lambda functions in the configured account (management account in the Organizational case). aws_iam_role IAM Role with the name sysdig-secure-ra-XXXX-package-downloader-role. This role is used by the installer to download response action packages from Sysdig and upload them to regional S3 buckets. aws_iam_role IAM Role with the name sysdig-secure-ra-XXXX-stackset-admin. This role is used to administer CloudFormation StackSets. aws_iam_role IAM Role with the name sysdig-secure-ra-XXXX-stackset-execution. This role is used to execute CloudFormation StackSets. aws_lambda_function Lambda function with the name sysdig-secure-ra-XXXX-quarantine-user. Attaches a deny-all policy to IAM users to prevent further actions. aws_lambda_function Lambda function with the name sysdig-secure-ra-XXXX-remove-policy. Detaches policies from IAM users to undo quarantine actions. aws_lambda_function Lambda function with the name sysdig-secure-ra-XXXX-fetch-cloud-logs. Retrieves CloudTrail logs. aws_lambda_function Lambda function with the name sysdig-secure-ra-XXXX-configure-resource-access. Removes public access from S3 buckets and RDS instances (make private action). The same Lambda is used for public access restore (reverse action). aws_lambda_function Lambda function with the name sysdig-secure-ra-XXXX-create-volume-snapshots. Creates EBS volume snapshots for forensic investigation. aws_lambda_function Lambda function with the name sysdig-secure-ra-XXXX-delete-volume-snapshots. Deletes EBS volume snapshots. aws_cloudwatch_log_group CloudWatch Log Groups for Lambda function execution logs. One log group per Lambda function per region. aws_s3_bucket Regional S3 buckets with the name sysdig-secure-ra-XXXX-packages-{region}. These buckets store Lambda deployment packages. One bucket is created per region. aws_cloudformation_stack_set CloudFormation StackSet with the name sysdig-secure-ra-XXXX-lambda. Used to deploy Lambda functions and S3 buckets across specified regions. aws_cloudformation_stack_set_instance CloudFormation StackSet instances. One instance per region to deploy Lambda functions. aws_cloudformation_stack_set (Organization only) CloudFormation StackSet with the name sysdig-secure-ra-XXXX-delegate-roles. Used to deploy delegate roles across member accounts in your Organization. aws_cloudformation_stack_set_instance (Organization only) CloudFormation StackSet instances. One instance per organizational unit to deploy delegate roles to member accounts. Volume AccessThe Volume Access component is used to enable Vulnerability Management Host Scanning (VM)\nPermissions Required to InstallThe Installer must have at least the following policies assigned in the AWS Account or Organization\u0026rsquo;s Management account:\nPolicy Description IAMFullAccess Required to create IAM Roles and associated permissions. AWSCloudFormationFullAccess Required to create a CloudFormation StackSet that creates KMS Keys/Aliases in each Account in your Organization. (Organization only) AWSOrganizationsReadOnlyAccess This policy is required to list Accounts and OUIDs in your Organization. Permissions Granted to SysdigThe Sysdig IAM Role will have the following policies attached:\nRole Policy Description sysdig-secure-scanning-XXXX A Custom IAM Policy containing the following permissions:kms:ListKeys- kms:ListAliases- kms:ListResourceTags- kms:DescribeKey- kms:Encrypt- kms:Decrypt- kms:ReEncrypt*- kms:GenerateDataKey*- kms:CreateGrant- kms:ListGrants- ec2:Describe*- ec2:CreateSnapshot- ec2:CopySnapshot- ec2:CreateTags with the additional constraint of ec2:CreateAction being equal to either CreateSnapshot or CopySnapshot- ec2:ModifySnapshotAttribute with the additional constraint of ec2:Add/userId being equal to Sysdig\u0026rsquo;s Worker Account ID- ec2:DeleteSnapshot with the additional constraint of aws:ResourceTag/CreatedBy being equal to Sysdig (which we add when creating the Snapshot) Allows Sysdig to copy and scan Volumes. Resources CreatedThe following resources will be created in your AWS Environment:\nResource Description aws_iam_role IAM Role with the name sysdig-secure-scanning-XXXX. This role is used to copy and scan disk snapshots. aws_iam_role IAM Role with the name sydig-secure-scanning-XXXX-AdministrationRole. This role is used to deploy KMS Keys and Aliases in the selected regions in your account. aws_iam_role IAM Role with the name sysdig-secure-scanning-XXXX-ExecutionRole. This role is used to deploy KMS Keys and Aliases in the selected regions in your account. aws_iam_policy Custom IAM Policy with the permissions detailed above. aws_iam_policy_attachment Custom IAM Policy with the permissions detailed above. aws_iam_policy_document Custom IAM Policy with the permissions detailed above. aws_cloudformation_stack_set Used to deploy EventBridge Rules/Role in each Account/Region in your Organization. aws_cloudformation_stack_set_instance Used to deploy EventBridge Rules/Role in each Account/Region in your Organization. Workload AccessWorkload Access is used to perform agentless vulnerability scanning on ECR images for ECS and on Lambda functions.\nPermissions Required to InstallThe Installer must have at least the following policies assigned in the AWS Account or Organization\u0026rsquo;s Management account:\nPolicy Description IAMFullAccess Required to create the IAM Role and associated policies. (Organization only) AWSCloudFormationFullAccess Required to create a CloudFormation StackSet that deploys the IAM Role across all accounts in your Organization. (Organization only) AWSOrganizationsReadOnlyAccess Required to list accounts and OUIDs in your Organization. Permissions Granted to SysdigThe Sysdig IAM Role will have the following policies attached:\nRole Policy Description sysdig-vm-workload-scanning-XXXX A Custom IAM Policy containing the following permissions:- ecr:GetDownloadUrlForLayer- ecr:BatchGetImage- ecr:BatchCheckLayerAvailability- ecr:ListImages- ecr:GetAuthorizationToken Allows Sysdig to access and scan ECR images. sysdig-vm-workload-scanning-XXXX (Optional) A Custom IAM Policy containing the following permissions:- lambda:GetFunction- lambda:GetFunctionConfiguration- lambda:GetRuntimeManagementConfig- lambda:ListFunctions- lambda:ListTagsForResource- lambda:GetLayerVersionByArn- lambda:GetLayerVersion- lambda:ListLayers- lambda:ListLayerVersions Allows Sysdig to access and scan Lambda functions. This is enabled by setting the lambda_scanning_enabled variable to true. Resources CreatedThe following resources will be created in your AWS Environment:\nResource Description aws_iam_role IAM Role with the name sysdig-vm-workload-scanning-XXXX. This role is used by Sysdig to perform workload scanning. aws_iam_policy Custom IAM policies granting the permissions detailed above. aws_iam_policy_attachment Attaches the custom policies to the sysdig-vm-workload-scanning-XXXX role. (Organization only) aws_cloudformation_stack_set Used to deploy the sysdig-vm-workload-scanning-XXXX role and its policies across all accounts in your organization. (Organization only) aws_cloudformation_stack_set_instance Creates instances of the StackSet for the target accounts and organizational units. ","url":"https://docs.sysdig.com/en/sysdig-secure/aws-permissions-and-resources/"},{"id":268,"title":"Permissions and Resources","content":"Review Azure Roles and PermissionsSecurity PrincipalsThe onboarding process involves two security principals:\nInstaller: The primary security principal. This security principal will be used to perform the onboarding. Sysdig does not have access to this security principal. The Installer security principal can be either: A User A Service Principal Sysdig: A Service Principal (robot user) created during onboarding with specific, less permissive roles. Sysdig will be given access to this security principal. Azure Role TypesAzure IAM is separated into two control planes:\nEntra ID Roles: Applied to the entire Tenant. Azure RBAC Roles: Applied to the Subscription or Management Group being onboarded. Base Azure Integration - CSPMConnect Azure to Sysdig to enable Cloud Security Posture Management (CSPM). CSPM assesses and manages the security posture of your cloud resources without requiring agents.\nPermissions Required to InstallYou must assign the Installer security principal at least the following roles:\nRole Type Role Description Entra ID Application Administrator This role is required to create the Sysdig Service Principal in Entra ID. Entra ID Privileged Role Administrator This role is required to attach Entra ID roles, such as Directory Reader to the Sysdig Service Principal. See Permissions Granted to Sysdig. Azure RBAC User Access Administrator This role is required to attach Azure RBAC roles to the Sysdig Service Principal. To assign this role to a Service Principal Installer, see Assign User Access Administrator. To assign it to a User Installer, see Assign Roles and Permissions. Permissions Granted to SysdigThe Sysdig Service Principal will be granted the following roles:\nRole Type Role Description Entra ID Directory Readers Allows Sysdig to list Users and Service Principals. Azure RBAC Reader Allows Sysdig to list resources within your Subscriptions. Azure RBAC Custom Role containing: Microsoft.Web/sites/config/list/action Allows Sysdig to collect the AuthSettings object required by certain CSPM controls. Resources CreatedThe following resources will be created in your Azure Environment:\nResource Description azuread_service_principal Service principal used by Sysdig for secure posture management azuread_directory_role_assignment Assigns the \u0026ldquo;Directory Reader\u0026rdquo; role to the Sysdig Service Principal azurerm_role_assignment Assigns the \u0026ldquo;Reader\u0026rdquo; role to the Sysdig Service Principal. For single subscription installations, this is applied at the Subscription level; for tenant installations, it is applied to the root Management Group. azurerm_role_definition Custom role definition containing: Microsoft.Web/sites/config/list/action azurerm_role_assignment Assigns the custom role to the Sysdig Service Principal CDR and CIEMTo enable agentless Cloud Detection and Response (CDR) and Cloud Infrastructure Entitlement Management (CIEM)/Identity Access Management (IAM), set up log ingestion. The permissions required to do this are listed below.\nPermissions Required to InstallThe Installer must have at least the following roles assigned:\nRole Type Role Description Entra ID Application Administrator Required to create a Service Principal associated with a Sysdig-owned application. Entra ID Security Administrator Required to create Entra ID Diagnostic Settings. Azure RBAC Owner Required to attach Azure RBAC roles to the created Service Principal, and create Resource Groups, Event Hub resources and Diagnostic Settings. If you are using Service Principal to run terraform deployment please make sure to assign Contributor role to the Service principal for /providers/Microsoft.aadiam scope.\nPermissions Granted to SysdigThe Sysdig Service Principal will be granted the following roles:\nRole Type Role Description Azure RBAC Azure Event Hubs Data Receiver Allows Sysdig to receive data from Event Hubs. Resources CreatedThe following resources will be created in your Azure Environment:\nResource Description azuread_service_principal Service principal for Event Hub integration azurerm_resource_group Resource group to contain the Event Hub and related resources azurerm_eventhub_namespace Namespace for the Event Hub azurerm_eventhub Event Hub for log ingestion azurerm_eventhub_consumer_group Consumer group within the Event Hub azurerm_eventhub_namespace_authorization_rule Authorization rule for the Event Hub namespace azurerm_role_assignment Assigns the \u0026ldquo;Azure Event Hubs Data Receiver\u0026rdquo; role to the Sysdig service principal for the Event Hub namespace azurerm_monitor_diagnostic_setting Diagnostic settings for the subscription azurerm_monitor_aad_diagnostic_setting Diagnostic settings for Entra ID Vulnerability Management Agentless Host ScanningVulnerability Management (VM) Agentless Host Scanning performs vulnerability scanning using disk snapshots and Azure Lighthouse for accurate risk assessment and management.\nPermissions Required to InstallThe Installer must have at least the following roles assigned:\nRole Type Role Description Entra ID Application Administrator Required to create a Service Principal associated with a Sysdig-owned application. Entra ID Privileged Role Administrator Required to assign Entra ID roles to the created Service Principal. Azure RBAC Owner Required to create Azure Lighthouse Definition and Assignment. Please make sure Microsoft.ManagedServices resource provider is registered for the specific subscription. Please follow the instructions.\nPermissions Granted to SysdigThe Sysdig Service Principal will be granted the following roles:\nRole Type Role Description Azure RBAC VM Scanner Operator Allows Sysdig access to disk snapshot for security analysis. Resources CreatedThe following resources will be created in your Azure Environment:\nResource Description azurerm_lighthouse_definition Defines the Azure Lighthouse relationship azurerm_lighthouse_assignment Assigns the Lighthouse definition to target subscriptions Vulnerability Management Agentless Workload ScanningVulnerability Management Agentless Workload Scanning provides vulnerability scanning for Azure Functions, Azure Kubernetes Servies and Azure Container Apps.\nPermissions Required to InstallThe Installer must have at least the following roles assigned:\nRole Type Role Description Entra ID Application Administrator Required to create the Sysdig Service Principal in Entra ID. Azure RBAC Owner or User Access Administrator Required to create and assign custom roles to the Sysdig Service Principal. Permissions Granted to SysdigThe Sysdig Service Principal will be granted the following built-in and custom roles:\nRole Type Role Description Azure RBAC AcrPull Allows the service principal to pull images from the Azure Container Registry. Azure RBAC Storage File Data Privileged Reader Grants read access to file shares. Azure RBAC Storage Blob Data Reader Allows read access to blobs and their properties. Azure RBAC Custom Role for Azure Functions A custom role with permissions to read function app configurations (Microsoft.Web/sites/config/list/Action, microsoft.web/sites/config/appsettings/read) and access the Kudu API (Microsoft.Web/sites/publish/Action). Azure RBAC Custom Role for AKS Discovery (Optional) If AKS discovery is enabled, this role allows listing cluster admin credentials (Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action). Resources CreatedThe following resources will be created in your Azure Environment:\nResource Description azuread_service_principal A Service Principal linked to the Sysdig VM Workload Scanning application. azurerm_role_definition Custom role definitions for Azure Functions and optional AKS discovery. azurerm_role_assignment Assigns the required built-in and custom roles to the Sysdig Service Principal at the subscription or management group level. sysdig_secure_cloud_auth_account_component Registers the Service Principal with the Sysdig backend to enable the feature. Assign Roles and PermissionsTo apply roles in Azure, check out the Microsoft\u0026rsquo;s documentation, or use one of the Azure CLI commands given in the sections below.\nAfter you assign a role via the Azure CLI, ensure you Reload Credentials to save your changes.\nAssign User Access AdministratorTo assign the role User Access Administrator to a Service Principal Installer, use the following command template:\naz role assignment create --assignee \u0026#34;\u0026lt;SP_APP_ID\u0026gt;\u0026#34; --role \u0026#34;User Access Administrator\u0026#34; --scope \u0026#34;\u0026lt;ROOT_MANAGEMENT_GROUP_ID\u0026gt;\u0026#34; Fill in the values SP_APP_ID, and ROOT_MANAGEMENT_GROUP_ID. For example:\naz role assignment create --assignee \u0026#34;a686e05a-191d-48ba-a74e-6daf9445ef71\u0026#34; --role \u0026#34;User Access Administrator\u0026#34; --scope \u0026#34;/providers/Microsoft.Management/managementGroups/d1aed736-5b36-41ff-9d78-c8181a3435bb\u0026#34; For troubleshooting, see Insufficient Permission on Tenant.\nAssign Contributor PermissionTo assign the role Contributor to a Service Principal Installer, use the following command template:\naz role assignment create --assignee-principal-type ServicePrincipal --assignee-object-id \u0026lt;SP_OBJECT_ID\u0026gt; --scope \u0026#34;/providers/Microsoft.aadiam\u0026#34; --role Contributor SP_OBJECT_ID: This is the Service Principal Object ID for your Enterprise Application, not the Object ID of your application. This can be found:\nIn the Azure Portal: Azure Active Directory \u0026gt; Enterprise applications \u0026gt; Your SP In the Azure CLI with the command az ad sp show --id XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX --query id --output tsv where XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX is the appId of the Enterprise Application. Example:\naz ad sp show --id 21824912-8445-4a5e-b7d7-cc77c0fbxxxx --query id --output tsv Output:\n97683330-4e97-416c-9a3a-398f381exxxx Reload CredentialsAfter you update RBAC roles, reload the credentials in the Azure CLI to ensure your changes are reflected.\nTo update credentials, run the following command in Azure CLI to update credentials:\naz account clear \u0026amp;\u0026amp; az login Enable Root Management Group AccessTo grant Root Management Group Access (RBAC role assignment on root management group scope) to a security principal:\nGo to the Microsoft Azure portal.\nNavigate to Entra ID \u0026gt; Manage \u0026gt; Properties.\nUnder Access management for Azure resources, set the toggle to Yes.\nRoot Management Group Access is now enabled for the current user.\n","url":"https://docs.sysdig.com/en/sysdig-secure/azure-permissions-and-resources/"},{"id":269,"title":"Permissions and Resources","content":"Review GCP Roles and PermissionsSecurity PrincipalsThere are two security principals in the onboarding process:\nInstaller: The primary security principal, either a User or a Service Account. This security principal will be used to perform the onboarding. Sysdig does not have access to this security principal. Sysdig: A Service Account (robot user) created during onboarding with specific, less permissive roles. Sysdig will be given access to this service account. GCP RolesGCP IAM has a single control plane that applies to either at the organization or project level:\nGCP Roles: Applied to the entire organization or project. Base GCP Integration - Cloud Security Posture Management (CSPM)Agentless Cloud Security Posture Management (CSPM) assesses and manages the security posture of your cloud resources without requiring agents.\nPermissions Required to InstallThe Installer must have at least the following roles assigned:\nSingle Project InstallIf you are installing CSPM, the user/service account must have the following roles assigned on the Project you are onboarding:\nroles/iam.serviceAccountAdmin roles/iam.roleAdmin roles/resourcemanager.projectIamAdmin roles/iam.serviceAccountKeyAdmin roles/serviceusage.serviceUsageAdmin roles/iam.workloadIdentityPoolAdmin Organizational Install Note: Certain roles are required at the organization level. Other roles are required on a single project in which you will deploy shared resources. Ensure you have the correct roles assigned at the correct scope.\nIf you are installing CSPM, the user/service account must have the following roles assigned at the organizational level:\nroles/iam.organizationRoleAdmin roles/resourcemanager.organizationAdmin roles/serviceusage.serviceUsageAdmin If you are installing CSPM, the user/service account must have the following roles assigned at the project level:\nroles/iam.serviceAccountAdmin roles/iam.serviceAccountKeyAdmin roles/iam.workloadIdentityPoolAdmin Permissions Granted to SysdigThe installation creates a Service Account that Sysdig can access. This Service Account is granted the following roles and permissions:\nFor CSPM:\nroles/iam.browser roles/cloudasset.viewer roles/iam.workloadIdentityUser roles/logging.viewer roles/cloudfunctions.viewer roles/cloudbuild.builds.viewer roles/orgpolicy.policyViewer Resources CreatedThe following resources will be created in your GCP Environment:\nResource Deployed Name Description google_service_account sysdig-onboarding-${local.suffix} Service account for initial Sysdig authentication. google_service_account sysdig-posture-${local.suffix} Service account for ongoing posture management. google_iam_workload_identity_pool sysdig-secure-onboarding-${local.suffix} Workload Identity Pool for initial authentication. google_iam_workload_identity_pool sysdig-secure-posture-${local.suffix} Workload Identity Pool for posture management authentication. google_iam_workload_identity_pool_provider sysdig-onboarding-${local.suffix} Workload Identity Pool Provider for onboarding. google_iam_workload_identity_pool_provider sysdig-posture-${local.suffix} Workload Identity Pool Provider for posture management. google_project_iam_member / google_organization_iam_member (IAM Binding) Assigns necessary roles to the Sysdig Service Accounts. google_service_account_iam_member (IAM Binding) Attaches the Workload Identity Federation to the service accounts. sysdig_secure_cloud_auth_account_component secure-onboarding Registers the onboarding Service Principal with the Sysdig backend. sysdig_secure_cloud_auth_account_component secure-posture Registers the posture Service Principal with the Sysdig backend. Cloud Detection and Response (CDR)Agentless Cloud Detection and Response (CDR) performs threat detection using Falco rules and policies on platform logs.\nPermissions Required to InstallSingle Project InstallIf you are installing CDR and CIEM, you must have the following additional roles assigned on the Project you are onboarding:\nroles/pubsub.admin roles/logging.configWriter roles/iam.serviceAccountUser Organizational Install Note: Certain roles are required at the organization level. Other roles are required on a single project in which you will deploy shared resources. Ensure you have the correct roles assigned at the correct scope.\nIf you are installing CDR \u0026amp; CIEM, you must have the following additional roles assigned:\nroles/pubsub.admin (On the project where shared resources will be created) roles/logging.configWriter (At the Organization level) roles/iam.serviceAccountUser (On the project where shared resources will be created) Permissions Granted to SysdigThe installation creates a Service Account that Sysdig can access. This Service Account is granted the following roles and permissions:\nFor CDR \u0026amp; CIEM:\nroles/iam.workloadIdentityUser pubsub.topics.get pubsub.topics.list pubsub.subscriptions.get pubsub.subscriptions.list logging.sinks.get logging.sinks.list Resources CreatedThe following resources will be created in your GCP Environment:\nResource Deployed Name Description google_project_iam_audit_config / google_organization_iam_audit_config (IAM Policy) Enables Audit Log Configuration at the Project or Organizational level. google_pubsub_topic ingestion_topic_${local.suffix} Ingestion Pub/Sub topic created for CDR. google_pubsub_topic dl_ingestion_topic_${local.suffix} Dead-letter topic to store undeliverable messages for CDR. google_logging_project_sink / google_logging_organization_sink ingestion_topic_${local.suffix}_sink Sysdig sink to direct Audit Logs to the Pub/Sub topic for data gathering. google_pubsub_topic_iam_member (IAM Binding) Attaches roles \u0026amp; permissions needed for the Pub/Sub topic. google_service_account sysdig-ingestion-${local.suffix} Service account used by Sysdig for threat detection. google_pubsub_subscription ingestion_topic_${local.suffix}_push_subscription Creates the Pub/Sub subscription with topic name and custom role. google_iam_workload_identity_pool sysdig-ingestion-${local.suffix} Creates a Workload Identity Pool Federation for authentication. google_iam_workload_identity_pool_provider sysdig-ingestion-${local.suffix} Creates a Workload Identity Pool Provider ID for threat detection. google_project_iam_custom_role / google_organization_iam_custom_role SysdigIngestionAuthRole... Creates a custom role to access data ingestion resources. google_project_iam_member / google_organization_iam_member (IAM Binding) Binds the custom role to the service account. google_service_account_iam_member (IAM Binding) Attaches the Workload Identity Federation as a member to the service account for authentication. sysdig_secure_cloud_auth_account_component secure-runtime Registers the Webhook Datasource with the Sysdig backend. Vulnerability Management Agentless Host ScanningVulnerability Management Agentless Host Scanning performs vulnerability scanning using disk snapshots for accurate risk assessment and management.\nPermissions Required to InstallSingle Project InstallIf you are installing Vulnerability Host Scanning, you must have the following roles assigned:\nroles/iam.serviceAccountAdmin roles/iam.roleAdmin roles/resourcemanager.projectIamAdmin roles/iam.serviceAccountKeyAdmin roles/serviceusage.serviceUsageAdmin Organizational Install Note: Certain roles are required at the organization level. Other roles are required on a single project in which you will deploy shared resources. Ensure you have the correct roles assigned at the correct scope.\nIf you are installing Vulnerability Host Scanning, you must have the following roles assigned:\nroles/iam.serviceAccountAdmin (On the project where shared resources will be created) roles/iam.organizationRoleAdmin (At the Organization level) roles/resourcemanager.organizationAdmin (At the Organization level) roles/iam.serviceAccountKeyAdmin (On the project where shared resources will be created) roles/serviceusage.serviceUsageAdmin (At the Organization level) Permissions Granted to SysdigThe installation creates a Service Account that Sysdig can access. This Service Account is granted the following roles and permissions:\nFor Vulnerability Host Scanning:\nroles/iam.workloadIdentityUser compute.networks.list compute.networks.get compute.instances.list compute.instances.get compute.disks.list compute.disks.get iam.serviceAccounts.getAccessToken compute.zoneOperations.get compute.disks.get compute.disks.useReadOnly Resources CreatedThe following resources will be created in your GCP Environment:\nResource Deployed Name Description google_service_account sysdig-ahs-${local.suffix} Service account used by Sysdig for vulnerability management. google_iam_workload_identity_pool sysdig-ahs-${local.suffix} Creates a Workload Identity Pool Federation for authentication. google_iam_workload_identity_pool_provider sysdig-ahs-${local.suffix} or ...-gcp Creates a Workload Identity Pool Provider ID for vulnerability management. google_project_iam_custom_role / google_organization_iam_custom_role SysdigCloudVMDiscovery... Custom role for host discovery operations. google_project_iam_custom_role / google_organization_iam_custom_role SysdigCloudVMScan... Custom role for host scanning operations. google_project_iam_binding / google_organization_iam_binding (IAM Binding) Assigns the custom roles to the Sysdig Service Account. google_service_account_iam_member (IAM Binding) Attaches the Workload Identity Federation as a member to the service account for authentication. sysdig_secure_cloud_auth_account_component secure-scanning Registers the Service Principal with the Sysdig backend. Vulnerability Management Agentless Workload ScanningVM Workload Scanning performs agentless vulnerability scanning on Google Cloud Run Containers and Functions and Google Kubernetes Engine.\nPermissions Required to InstallSingle Project InstallIf you are installing Agentless Workload Scanning, the installer user/service account must have the following roles assigned on the Project you are onboarding:\nroles/iam.serviceAccountAdmin roles/iam.roleAdmin roles/resourcemanager.projectIamAdmin roles/iam.workloadIdentityPoolAdmin Organizational InstallIf you are installing VM Workload Scanning at the organizational level, the installer user/service account must have the following roles assigned:\nroles/iam.organizationRoleAdmin (At the Organization level) roles/resourcemanager.organizationAdmin (At the Organization level) roles/iam.serviceAccountAdmin (On the project where shared resources will be created) roles/iam.workloadIdentityPoolAdmin (On the project where shared resources will be created) Permissions Granted to SysdigThe installation creates a Service Account that Sysdig can access. This Service Account is granted a custom role with the following permissions, allowing access to container images:\nartifactregistry.repositories.downloadArtifacts artifactregistry.repositories.get artifactregistry.repositories.list artifactregistry.dockerimages.get artifactregistry.dockerimages.list storage.objects.get storage.buckets.list storage.objects.list iam.serviceAccounts.getAccessToken The Service Account is also granted the roles/iam.workloadIdentityUser role to allow it to be impersonated by the Sysdig backend.\nResources CreatedThe following resources will be created in your GCP Environment:\nResource Deployed Name Description google_service_account sysdig-ws-${local.suffix} Service account used by Sysdig for workload scanning. google_project_iam_custom_role / google_organization_iam_custom_role ...WorkloadController${title(local.suffix)} or ...vmWorkloadScanningRole${title(local.suffix)} Creates the custom role with permissions needed for workload scanning. google_project_iam_binding / google_organization_iam_member (IAM Binding) Assigns the custom role to the Sysdig Service Account. google_iam_workload_identity_pool sysdig-wl-${local.suffix} Creates a Workload Identity Pool for authentication. google_iam_workload_identity_pool_provider sysdig-wl-${local.suffix} Creates a Workload Identity Pool Provider for workload scanning. google_service_account_iam_member (IAM Binding) Attaches the Workload Identity Federation as a member to the service account for authentication. sysdig_secure_cloud_auth_account_component secure-vm-workload-scanning Registers the Service Principal with the Sysdig backend. ","url":"https://docs.sysdig.com/en/sysdig-secure/gcp-permissions-and-resources/"},{"id":270,"title":"Permissions and Resources","content":"Base Integration - Cloud Security Posture Management (CSPM)Agentless Cloud Security Posture Management (CSPM) assesses and manages the security posture of your cloud resources without requiring agents. It uses API access to gather information and identify potential security risks across the cloud infrastructure, providing a non-intrusive way to assess security configurations and compliance issues.\nPermissions Required to InstallThe Installer must have at least the following policies assigned in the root Compartment of the Tenancy being onboarded:\nPolicy Statement Description Allow \u0026lt;user\u0026gt; to manage policies in \u0026lt;root compartment\u0026gt; Required to create the Admit policy in the root Compartment. Allow \u0026lt;user\u0026gt; to manage users in \u0026lt;root compartment\u0026gt; Required to create the CSPM User in the default identity domain. Allow \u0026lt;user\u0026gt; to manage groups in \u0026lt;root compartment\u0026gt; Required to create the CSPM User Group in the default identity domain. Permissions Granted to SysdigSysdig will be granted the following permissions in your tenancy:\nPolicy Policy Statement Description AdmitSysdigSecureTenantOnboarding-XXXX Admit group onboardingGroup of tenancy sysdigTenancy to inspect tenancies in tenancy Allows Sysdig to retrieve Tenancy information AdmitSysdigSecureTenantOnboarding-XXXX Admit group onboardingGroup of tenancy sysdigTenancy to inspect compartments in tenancy Allows Sysdig to list compartments in your Tenancy. AllowSysdigSecureTenantConfigPosture-XXXX Allow group SysdigSecureConfigPostureGroup-XXXX to read all-resources in tenancy Allows Sysdig to list resources within your Tenancy. Resources CreatedThe following resources will be created in your Oracle Cloud Environment:\nResource Description oci_identity_policy Cross Tenancy IAM Policy with the name AdmitSysdigSecureTenantOnboarding-XXXX. This policy is used to manage the lifecycle of your Sysdig integration. oci_identity_user IAM User for CSPM. This will be created in the default identity domain. oci_identity_group IAM Group for CSPM. This will be created in the default identity domain. oci_identity_policy IAM Policy for CSPM. oci_identity_api_key API Key for the CSPM User. This key will be used to access this User from the Sysdig Backend. ","url":"https://docs.sysdig.com/en/sysdig-secure/oci-permissions-and-resources/"},{"id":271,"title":"Configure Priority Modes","content":"Serverless Agent v5.0.0 and AboveYou can decide if your Workload Agent needs runtime policies for initialization by configuring priority modes. Choose between Security or Availability modes to establish the initialization approach:\nSecurityThis mode allocates dedicated resources for the Workload Agent sidecar and attempts to capture every event. The Security mode prevents the secured applications from running in an unsecured manner. Consequently, secured applications will not execute commands until the Workload Agent receives the runtime policies.\nAvailabilityIn this mode, the serverless agent facilitates resource sharing between the Workload Agent sidecar and the workload itself. The Workload Agent can detect when resource pressure exceeds a set limit. When this occurs, the agent will pause event generation to reduce pressure. This optimization allows tasks to be provisioned with lower resource requests, ensuring efficient operation of the Workload Agent with spare resources from the workload.\nThe Availability mode prioritizes the availability of the secured applications and allows them to start even without having the runtime policies in place.\nConfigure Priority ModesUse the following parameters to prioritize between Security and Availability modes:\nSysdigPriority: Enables automatic Terraform or CloudFormation installers. SYSDIG_PRIORITY: Enables manual instrumentation. Provide this environment variable to the Sysdig sidecar container to use manual instrumentation. For more information on configuration, see the following:\nInstall Using Terraform Install Using CloudFormation Template Serverless Agent Versions up to 4.3.2In serverless agent versions up to 4.3.2, the instrumentation initiates the workload even without policies in place. This prevents workload starvation in cases of agent misconfiguration or network issues.\nYou can customize the workload starting policy by the following configurations:\nagentino.run_without_policiesThis environment variable defines whether the Sysdig instrumentation should continue running with no policies in place. true enables the workload to run unsecured. false disallows the workload to run unsecured so, the workload will not run at all without policies. The default is true.\nagentino.delay_startup_until_policies_timeout_sThis environment variable specifies the duration in seconds that Sysdig instrumentation should wait before initiating the workload. The time required for the Workload Agent to acquire policies varies based on factors like configuration, network latency, and load. A recommended value could be 60 seconds. The default is 0 (zero).\nYou can provide such configuration options to the Workload Agent via the SYSDIG_EXTRA_CONF environment variable. Note that SYSDIG_EXTRA_CONF expects either a valid YAML or JSON.\nExample: Delay Workload Startup and Start Workload Agent with No PoliciesSYSDIG_EXTRA_CONF=\u0026#39;\u0026#34;agentino\u0026#34;: {\u0026#34;delay_startup_until_policies_timeout_s\u0026#34;: 60}\u0026#39; This configuration does the following:\nDelays the workload startup for 60 secs to let Sysdig instrumentation acquire the policies Enables the workload to start with no policies in place Example: Delay Workload Startup and Prevent Workload Agent from Starting without PoliciesSYSDIG_EXTRA_CONF=\u0026#39;{\u0026#34;agentino\u0026#34;: {\u0026#34;run_without_policies\u0026#34;: false, \u0026#34;delay_startup_until_policies_timeout_s\u0026#34;: 60}}\u0026#39; This configuration does the following:\nDelays the workload startup for 60 secs to let Sysdig instrumentation acquire the policies. prevents the workload from starting after the waiting if policies are not in place. ","url":"https://docs.sysdig.com/en/sysdig-secure/configure-priority-modes-fargate/"},{"id":272,"title":"PromQL Variables","content":"Built-In PromQL Variables$__rangeRepresents the time range currently selected in the time navigation and it is used to adapt operations like calculating average for a selected time interval. In the Live mode, the value is constantly updated to reflect the new time range.\n$__range_secSame as $__range but this variable will be replaced with an absolute value in seconds.\n$__intervalRepresents a time interval and is automatically configured based on the time range. Use it within a PromQL query to apply the most appropriate sampling corresponding to the time range you have selected. Setting it, ensures that the most granular data is accessible for aggregation in long intervals of time. This in turn helps load panels quickly.\nYou currently have no control over the sampling visualized in a time chart. Sysdig determines the best and the maximum number of samples for aggregation from what’s currently available in the data store while maintaining good performance. Therefore $__interval offers a way to avoid referencing an explicit, static sampling, such as 1 minute, and instead allow for runtime substitution with the sampling that is picked by the Sysdig.\n$__interval_secSame as $__interval but this variable will be replaced with an absolute value in seconds.\nTime builtins summary$__interval and $__range are replaced with the time range you have selected, such as 10s, 1m, 10m, whereas $__interval_sec and $__range_sec are replaced with seconds and can be used everywhere in the query.\nIn the example below, if $__interval is 10m , $__interval_sec will be 600 . http_requests_total{job=\u0026quot;prometheus[$__interval]\nThe $__interval and $__range variables can be used in the range vector selector.\nIn normal cases, you cannot use the rate function to calculate the rate of gauge metrics. For example, sysdig_host_cpu_used_percent is a gauge metric and you can’t use the rate function because rate should only be used with counters while sysdig_host_cpu_used_percent is a gauge.\nIn such case, you can use $_interval_sec to compute the rate as follows:\nsum_over_time(sysdig_container_cpu_used_percent[$__interval]) / $__interval_sec sum_over_time(sysdig_container_cpu_used_percent[$__range]) / $__range_sec $__scope $__scope is only supported when a scope if defined (Currently only in Metrics Explorer and Dashboards)\nRepresents the selected scope that is applied to a PromQL query. The defined scope is applied by using the filter functionality of PromQL similar to how scope variables are applied. It allows you to apply whole Dashboard scope to the queries, instead of applying each scope variable individually. You can place this builtin anywhere within the query expression. Using multiple $__scope variages in a single expression is not allowed.\nSee Using $__scope.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/use-promql/promql-variables/"},{"id":273,"title":"Configure Rapid Response","content":"To enable Rapid Response:\nConfigure Rapid Response via the Shield chart Enable Response tools via the Shield chart For more details, see Rapid Response.\nConfigure Rapid ResponseYou can enable and configure Rapid Response with the following parameters in the shield chart values.yaml configuration file, under the features.respond.rapid_response section:\nProperty Description Type Required Default Example enabled Define whether to enable the feature boolean No false password Defines the password to authenticate from the Sysdig UI. string Yes, if the feature is enabled. Otherwise, no. Enable Response ToolsYou can configure the Shield Chart to enable Response tools which extend Host Shield\u0026rsquo;s default capabilities:\nExtend the Container Image Extend the cluster permissions Extend the Container ImageExtend the Host Shield container image to provision additional tools to the workload:\nCreate a custom Dockerfile.\nAdd any tool you want to respond to the Dockerfile. In this example, we add kubectl:\nFROM quay.io/sysdig/agent-slim:latest RUN curl -LO \u0026#34;https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl\u0026#34; \u0026amp;\u0026amp; \\ chmod +x kubectl \u0026amp;\u0026amp; \\ mv ./kubectl /usr/local/bin/kubectl Build the image and host it in a registry of your preference\nCustomize the shield chart to use it. Use host.image.registry, host.image.repository and host.image.shield_name to customize it.\nNote that the repository will be used to pull the agent-kmodule image as well. You can customize its name via host.image.kmodule_name. For information on available chart parameters and their specifications, see the Shield Chart.\nOnce you have provisioned additional tools for the workload, they will be available when needed later on.\nExtend the Cluster PermissionsTo execute actions on the Kubernetes control plane, provide the Host Shield role with additional permissions. There are two alternative ways to achieve this:\nYou can provide additional permissions via a custom ClusterRole, to be assigned to the Host Shield\u0026rsquo;s Service Account (default: shield-host) through a dedicated ClusterRoleBinding. For instance, here we\u0026rsquo;re adding the possibility to execute, attach, and portforward, as well as the possibility to modify networking rules: Expand apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: shield-host-rr rules: - apiGroups: - \u0026#34;\u0026#34; resources: - pods/exec - pods/attach - pods/portforward verbs: - create - get - apiGroups: - networking.k8s.io resources: - networkpolicies - ingresses verbs: - get - list - watch - create - delete - patch - update --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: shield-host-rr roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: shield-host-rr subjects: - kind: ServiceAccount name: sysdig-shield-host namespace: sysdig You can provision the Host Shield with a ServiceAccount of your preference, provisioned separately. You can proceed this way by setting host.rbac.create to false, as you will provide the ServiceAccount and host.rbac.service_account_name to the ServiceAccount name. Equivalently to the above: Expand apiVersion: v1 kind: ServiceAccount metadata: name: shield-host-rr namespace: sysdig --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: shield-host-rr rules: - apiGroups: - \u0026#34;\u0026#34; resources: - pods - replicationcontrollers - services - endpoints - events - limitranges - namespaces - nodes - nodes/metrics - nodes/proxy - resourcequotas - persistentvolumes - persistentvolumeclaims - configmaps - pods/log verbs: - get - list - watch - apiGroups: - \u0026#34;\u0026#34; resources: - events verbs: - create - patch - apiGroups: - \u0026#34;\u0026#34; resources: - pods/exec - pods/attach - pods/portforward verbs: - create - get - apiGroups: - apps resources: - daemonsets - deployments - replicasets - statefulsets verbs: - get - list - watch - apiGroups: - autoscaling resources: - horizontalpodautoscalers verbs: - get - list - watch - apiGroups: - batch resources: - cronjobs - jobs verbs: - get - list - watch - apiGroups: - networking.k8s.io resources: - networkpolicies - ingresses verbs: - get - list - watch - create - delete - patch - update - apiGroups: - extensions resources: - daemonsets - deployments - replicasets verbs: - get - list - watch - nonResourceURLs: - /metrics verbs: - get - apiGroups: - storage.k8s.io resources: - storageclasses verbs: - get - list - watch - apiGroups: - certificates.k8s.io resources: - certificatesigningrequests verbs: - get - list - watch - apiGroups: - policy resources: - poddisruptionbudgets verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: shield-host-rr roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: shield-host-rr subjects: - kind: ServiceAccount name: shield-host-rr namespace: sysdig ","url":"https://docs.sysdig.com/en/sysdig-secure/configure-rapid-response-with-shield/"},{"id":274,"title":"Rapid Response","content":"Prerequisites Setup the agent to enable Rapid Response Configure the Rapid Response permissions Creating a new team Using an existing team (Optional) Setup a S3 storage to persist session logs Configure Shield Enable Rapid Response: On Kubernetes, using the shield chart On Linux Hosts, using the containerized agent On Linux Hosts, using the agent package Create a Team for Rapid Response Rapid Response team members have access to a shell in the Sysdig Agent from within the Sysdig Secure UI. Provision permissions and capabilities accordingly.\nYou can configure a team to grant Rapid Response permissions to particular users. For example, if you have an existing team called CustomerResponse with 40 members and you\u0026rsquo;d like to grant 5 of those users Rapid Response capabilities, you could create a team called CustomerResponse_RR and add the 5 designated Advanced Users to it.\nTo create a team with Rapid Response permission:\nLog in to Sysdig Secure as Admin.\nSelect Settings \u0026gt; Teams.\nSelect Add team.\nEnter the team name and configure the team details.\nCheck the Rapid Response additional permission checkbox.\nSelect Save.\nEnable Rapid Response for an Existing TeamTo enable Rapid Response for an existing team:\nGo to Settings \u0026gt; Teams.\nChoose the applicable team to display the Edit Teams page.\nSelect the Rapid Response checkbox in the additional permissions section and click Save.\nStore Session InformationRapid Response can store session logs on S3, if a Custom S3 storage bucket is provided.\nT learn how to configure it, see Install Rapid Response.\nStart Rapid Response Log in to the Sysdig Secure UI as a Rapid Response team member.\nSelect Threats \u0026gt; Start Rapid Response.\nSelect the host as prompted and click Start Session.\nEnter the passphrase for that host.\nEnter the two-factor authentication code that was emailed to you and click Confirm.\nBegin your session.\nYou can dock the terminal window at the bottom or right panel of your page, or as a separate screen.\nLaunch a Rapid Response Session from Events Feed Log in to the Sysdig Secure UI as a Rapid Response team member.\nSelect Events and choose an event from the list to open the detail pane.\nClick Respond: Open Shell.\nEnter the two-factor authentication code that was emailed to you and click Confirm.\nBegin your session.\nYou can dock the terminal window at the bottom or right panel of your page, or as a separate screen.\nManage Rapid Response LogsWhen reviewing the logs, you can download completed log sessions or close sessions that are live.\nIf you\u0026rsquo;re using Sysdig SaaS, configure a storage for Rapid Response logs in order to store them.\nThe logs visible to you depend on the team and role under which you are logged in. Administrators will see the entire log list.\nThe Session Log list includes the session initiator, the timestamp, and the host name accessed.\nDownload Session Information Rapid Response will store session logs only if a Custom S3 storage is set up. To learn how, see Store Session Information to learn how.\nWhen the session is closed, you can download the content of the session from the UI (input and output) as an Open SSL-compatible gzip encrypted file.\nTo open the file, use the following command (session-file is the name of the downloaded file and \u0026lt;passphrase\u0026gt; is the passphrase you set up for that host during the installation):\ngzip -dc \u0026lt;session-file\u0026gt; | openssl enc -d -aes-256-ctr -pbkdf2 -k \u0026lt;passphrase\u0026gt; Close an Active SessionRapid Response team members can review the Session Log list and close any active session by clicking Close from the Actions column.\n","url":"https://docs.sysdig.com/en/sysdig-secure/rapid-response/"},{"id":275,"title":"Reporting","content":"OverviewSysdig Secure\u0026rsquo;s Reporting module provides:\nThe Reporting module comprises:\nReports Manager: Use this UI module to manage, create and delete reports. Scheduled Reports: Use this to manage and set report schedules. Generate Reports Across the UIYou can manage reports for different features throughout the Secure UI, based on available templates.\nIn the Secure UI, you can generate reports from:\nCompliance Overview Compliance Findings Report Manager TemplatesTemplates are the building blocks to create reports that can be used to generate and export data. Templates come in different levels of customizations, and functionality:\nLive view or export only:\nLive view templates let you view a sample of the data before exporting or creating a schedule. Export only templates provide configuration options as you create the report or schedule. Most templates provide some level of context within the program owner flows of what to expect, such as the “Policy Compliance Report” \u0026amp; “Resource Posture Report”. Historical or point-in-time:\nHistorical reports let you select timeframes either in the report editor in the live view, or when creating a schedule. Point-in-time reports provide only what is present within the platform at that point in time. Export formats\nPDF - Most reports support exporting to PDF. The exceptions are for export-only templates that are built for CSV exports. When exporting to PDF, table panels are limited to the first 7 columns and the first 500 rows. JSON - Most reports support exporting to JSON, except for export only templates. CSV - Only reports that have a single table panel support CSV export. Report HistoryView History lets you see and download reports that were generated either ad-hoc or on a schedule. Reports are available for 7 days from the time they’re created. After 7 days, they expire and are removed automatically.\nView Report History Go to Reporting \u0026gt; Reports Manager. Hover over the report you want to see the history for and click the three dots towards the right. Then choose View History. The Report History window appears.\nReport History columnsThe Report History table shows the following details for each generated report:\nDate Generated: When the report was created. Schedule: The schedule name, or blank for one-off reports. Frequency: How often the report runs (for scheduled reports). Zones: Number of Zones included in the report. Status: Shows the status of the report. File: Download link for the report. The Date Generated column shows relative time (for example, about 7 hours ago or 6 days ago). Reports are available for 7 days. On the 8th day, they expire exactly at the start of the day. Migrate from Vulnerability Management ReportsReporting builds upon and replaces the Vulnerability Management (VM) Reporting interface.\nThe legacy VM report types correspond to the following reporting templates.\nVM Report Type Template (NEW) Image Pipeline Pipeline Vulnerability Findings Image Registry Registry Vulnerability Findings Runtime Workloads Kubernetes Workload Vulnerability Findings Runtime Hosts Host Vulnerability Findings Runtime Container Container Vulnerability Findings Migrating Managed \u0026amp; Custom Reports to Reports \u0026amp; TemplatesPrior to May 28, 2025, you could:\nUse managed reports to generate ad-hoc reports or schedule exports without needing to create custom reports you would have to manage Copy managed reports to edit the queries within the panels as a custom report. As of May 28, 2025:\nThe distinction between managed and custom reports has been abolished. Managed reports have been converted to templates. You can generate reports from these templates. All managed reports that have a schedule associated with it, will be converted to a report. All custom reports will just be considered a report. For more details, see the Release Announcement.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/reporting/"},{"id":276,"title":"Respond","content":" Response Actions lets you take action directly from the Events feed. Response History provides a centralized audit trail of all response action executions across your environment. Rapid Response lets you connect to a remote shell within your environment and execute commands there. These features supplement the response capabilities of Threat Detection Policies. Several policy types, such as the Drift Detection Policy, let you configure actions to occur when a suspicious event is detected in the workload.\n","url":"https://docs.sysdig.com/en/sysdig-secure/threats-respond/"},{"id":277,"title":"Risk Definitions","content":"Use Policies \u0026gt; Risk Definitions to view, define, edit, enable, or disable both managed and custom risk definitions.\nView and Manage Risk DefinitionsThe Risk Definitions page provides a consolidated view of all available risk definitions. You can filter by:\nUse the search bar to find Risk Definitions that contain the given search string. Use the Crit, High, Med and Low buttons to view Risk Definitions of critical, high, medium and low severities. Risk Definition Tag: Risk Definitions can be tagged with metadata indicating the nature of the risk, affected resource types, or anything else that may be relevant to your specific environment. For example Exposed, Critical Vulnerability, HC Event, Kubernetes Workload, IAMRole, or Service-BillingEngine. Risk Definition Type: Managed (provided out of the box by Sysdig) or Custom (defined by the customer). Enabled Status: A Risk Definition that is enabled will continuously scan your environment for the conditions it\u0026rsquo;s designed to detect, generating risk findings when those conditions are met. When a Risk Definition is disabled, it is inactive and will not generate any new findings, allowing you to pause or remove a specific check without permanently deleting it. The table includes the following columns:\nRisk Definition: The definition name and description. Resource Type: The type of the resource matched by the risk definition. Severity: The assigned severity level (Critical, High, Medium, Low). Type: Designates whether the definition is Managed (authored by Sysdig) or Custom (created by the customer). Author: The user who created the risk definition. Managed Risk Definitions will list Sysdig as the author. Last update: The timestamp of when the definition was last updated. Tags: The metadata tags assigned to the risk definition. Select any Risk Definition row to display the SysQL query that defines it, as well as other metadata.\nCreate a New Custom Risk DefinitionSysdig provides a number of Managed Risk Definitions out-of-the-box. You can also create your own Custom Risk Definitions to tailor Risk Definitions to the needs of your organization\u0026rsquo;s cloud infrastructure. Custom Risk Definitons let you prioritize the risks and critical security issues that are the greatest threats to your circumstances. Additionally, the ability to customize using SysQL queries gives you greater control over your security posture, enhancing the efficiency and effectiveness of your security operations.\nTo create a Custom Risk Definition:\nLog in to Sysdig Secure. Select Policies \u0026gt; Risk Definitions. On the top-right corner of the page, select More \u0026gt; New Risk Definition. The Create Query page appears.\nDefine the query that will produce Risk Findings. See Build a Query. Build a QueryOn the Graph Search page, you can define a custom risk by using the SysQL query builder. For example, let\u0026rsquo;s build the following query:\nEC2 with Critical Vulnerabilities Click Start building your query and select Compute \u0026gt; EC2Instance.\nSelect That has Installed Package and click Go.\nThe query is ready to add more options.\nOn the query builder, click the + icon next to THAT HAS INSTALLED Package.\nYou have the option to hide, remove, or make the entity optional.\nSelect That Is Affected By Vulnerability.\nClick the + icon to open the menu options and select Severity.\nClick Go.\nOn the query builder, click the value for severity and choose Critical.\nClick Run to see all the entities that are at risk for this.\nClick Save as Risk to save the custom risk that you have defined.\nSpecify the following: Definition Name: A unique name to identify the custom risk that you have defined. Description: Details such as what this risk is. Risk Severity: Low, Medium, High, Critical. Optionally, enable the risk that you have just created. Optionally, specify any tags you may want to use when filtering or viewing the risk findings in your environment. Click Save.\nOnce saved, you can view the risk you have just created on the Risk Definitions page.\nDuplicate a Managed Risk DefinitionYou can use a Managed Risk Definition as a starting point for your Custom Risk Definition. This is desirable if an out of the box definition needs to be adjusted to suit your specific needs without having to build a new one from scratch. To do this:\nOn the Policies \u0026gt; Risk Definitions page, select an available managed risk definition. Select the SysQL Query and copy the text. Click the Cancel button in the top right to return to the Risk Definitions page. On the top-right corner of the page, click More and then New Risk Definition. Click the icon with three vertical dots at the right of the query text box and select Paste. Your browser may ask you for permission to paste from the clipboard. Edit the query to adapt it to your specific needs. Continue from step 9 in the build a query section above. Filter Risk DefinitionsOn the Policies \u0026gt; Risk Definitions page, you can search for and filter definitions you have created or that are managed by Sysdig in the following ways:\nSearch Bar: Use the search bar to locate a risk by its name. Severity: Filter by using the severity of the risk. Status: Filter for definitions that are Enabled or Disabled. Risk Definition Type: Filter by Managed or Custom definitions. Risk Definition Tags: Filter by specific tags applied to the risk definitions. Activate or Deactivate a Risk DefinitionOn the Risk Definitions page, use the slider next to each definition to enable or disable it. You can disable both managed and custom definitions.\nEdit a Custom Risk Definition On the Policies \u0026gt; Risk Definitions page, click the name of a custom risk definition. The definition\u0026rsquo;s details page appears. Click Edit Query to modify the SysQL, and click Update Query to save your changes. On the definition\u0026rsquo;s details page, you can change the name, description, severity, and tags. Make any desired changes and click Save. Query LimitationsConsider the following constraints while building a query to create a Custom Risk rule:\nThe query must point to one of the following resources:\nAWSLambda AWSRDSDatabaseCluster AWSRDSDatabaseInstance AzureFunction AzureStorageAccountBlobService AzureStorageAccountBlobServiceContainer AzureVirtualMachine CloudOrKubeResource EC2Instance GCPCloudFunction GCPCloudStorageBucket GCPComputeInstance KubeWorkload CloudResource CloudUser CloudRole CloudGroup CloudServiceIdentity CloudPolicy Kubernetes Resource S3Bucket VirtualMachine The query must have at least one filter applied to be evaluated as Risk. A filter can be:\nA WHERE clause that filters out the resource A relation matching some entity attached to the central resource This ensures that the result of the risk is not a plain list of resources but that these are filtered following some logic. The query must use only outgoing relations from entities that are resources:\nThe following query can\u0026rsquo;t be a risk, because it uses the Vulnerability as a \u0026ldquo;bridge\u0026rdquo; to get the workloads:\nMATCH EC2Instance AFFECTED_BY Vulnerability THAT_AFFECTS KubeWorkload This ensures that the risk represents a possible attack surface and that does not represent connections between resources that are not logically connected.\nA query can have only Resources as root nodes in the query.\nA query requires at least one filter or relationship in the query.\nOutgoing connections from the Package are not allowed except for Vulnerabilities.\nTo prevent users from creating invalid queries, outgoing connections are blocked from the following entities:\nMetadata Label Zone Region Policy Policy Vuln Vulnerability CriticalVulnerability Controls Control PrivilegedControl S3AcceptsHTTP S3VersioningDisabled ContainsAIPackage IAM Findings RiskFinding CompromisedState Runtime Events RuntimeEvent ","url":"https://docs.sysdig.com/en/sysdig-secure/risk-definitions/"},{"id":278,"title":"Scan Result Details","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nWhen you drill down into the Scan Results list, the details menu provides a variety of ways to view vulnerability and policy violation data at a glance.\nPolicy Summary views\nVulnerabilities summaries\nContent summaries\nThese summaries provide:\nAn easy-to-parse view of why a specific image failed\nWhich rules generated the most Warn and Stop actions\nOverview of how an image has performed against the various audit policies that have been put in place\nAbility to filter for high-severity CVEs, and see which have an available fix\nYou can also download the Policy Summary to PDF and the Vulnerabilities Summary to a CSV file.\nPolicy Results ViewsSummaryThe landing page of a Scan Results detail is the Policy Summary view.\nYou can:\nGet a birds-eye view of scanning status\nDrill down to a detail page\nClick Download as PDF to get a full report, including all underlying CVEs.\nAdded On: See the date and time the scan was added.\nAdded By: See the mechanism by which the scan was reported.\nPossible values are: Sysdig Secure UI, Node Image Analyzer, API, Sysdig Inline Scanner, or Scanning alert.\nRe-evaluate: Click the button to fetch the newest scan results\nSelect Dates for Past ScansFrom the dropdown, select the date of the scan you\u0026rsquo;d like to analyze.\nReview Scanning Policy DetailsSelect a listed Policy to see details about the STOP and WARN actions triggered in the Evaluation,\nas well as the underlying Rules affected.\nReview Vulnerability SummariesSelect either Operating System-related or Non-Operating System-related Vulnerability summaries to review.\nYou can:\nGet a birds-eye-view of vulnerability status\nClick a CVE number to get the full details and/or add it to an Exceptions list\nSearch or filter by severity: Critical, High, Medium, Negligible, Unknown. Also filter by whether it \u0026ldquo;Has a Fix\u0026rdquo;.\nClick Download CSV to get the vulnerabilities data as a CSV file\nOpen the Vulnerabilty Details panel on the right by selecting an image from the list\nAdded On: See the date and time the scan was added.\nRed Hat Vulnerability DetailsFor Red Hat vulnerabilities, the details panel provides both the Sysdig severity rating and the equivalent severity label from the Red Hat Security Tracker.\nThe labels are mapped as follows:\nSysdig Severity Red Hat Severity Red Hat Definition Critical Critical This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. Flaws that require authentication, local or physical access to a system, or an unlikely configuration are not classified as Critical impact. These are the types of vulnerabilities that can be exploited by worms. High Important This rating is given to flaws that can easily compromise the confidentiality, integrity or availability of resources. These are the types of vulnerabilities that allow local or authenticated users to gain additional privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication or other controls, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service. Medium Moderate This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity or availability of resources under certain circumstances. These are the types of vulnerabilities that could have had a Critical or Important impact but are less easily exploited based on a technical evaluation of the flaw, and/or affect unlikely configurations. Low Low This rating is given to all other issues that may have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences. This includes flaws that are present in a program\u0026rsquo;s source code but to which no current or theoretically possible, but unproven, exploitation vectors exist or were found during the technical analysis of the flaw. Negligible n/a n/a Vulnerability ComparisonThe vulnerability comparison allows users to compare two different tags within the same repo to see which vulnerabilities are new or have been fixed in version X compared to version Y.\nThis allows developers easily to compare the latest image to a previous version to easily report on which vulnerabilities have been addressed and which are new.\nSelect an image from a line in the Scan Results list.\nFrom the Compare To drop-down, select another version of this image with which to compare.\nThe comparison report is displayed.\nReview Content DetailsNavigate through node, ruby, python, java, OS packages, and the files in a container to search for details about a particular package or file.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/review-scan-results/scan-result-details/"},{"id":279,"title":"Selective Cloud Account Onboarding","content":" If you previously onboarded your AWS accounts using legacy parameters such as organizational_unit_ids or org_units, see the AWS onboarding migration guide to update to the include/exclude model.\nThis provides flexibility for organizations that don\u0026rsquo;t need to monitor all accounts in their cloud environment. The Include/Exclude option lets you select specific accounts/OUs during initial onboarding. Excluded accounts can still be onboarded later individually.\nInclude Exclude Account Selection OptionsYou can configure onboarding with three approaches:\nAllThis option lets you select all accounts in your cloud environment. This is the default setting.\nAll Accounts: Select all accounts in your cloud environment All accounts will be onboarded Include OUIDsThis option (include_ouids) lets you select specific OUIDs to include during onboarding. You can also exclude individual accounts from these OUIDs.\nExclude / Include Accounts (optional)This configuration lets you exclude specific accounts from the selected OUIDs. You can also include individual accounts from excluded OUIDs.\nYou have the following options:\nExclude Accounts: Exclude specific accounts from the selected OUIDs These accounts won\u0026rsquo;t be onboarded Include Extra Accounts: Include specific accounts from excluded OUIDs These accounts will be onboarded even if they are in excluded OUIDs Exclude OUIDsThis option (exclude_ouids) lets you select specific OUIDs to exclude during onboarding. You can also include individual accounts from these OUIDs.\nInclude / Exclude Accounts (optional)This configuration lets you include specific accounts from the selected OUIDs. You can also exclude individual accounts from included OUIDs. You have the following options:\nInclude Accounts: Include specific accounts from the selected OUIDs These accounts will be onboarded even if they are in excluded OUIDs Exclude Extra Accounts: Exclude specific accounts from the selected OUIDs These accounts won\u0026rsquo;t be onboarded ","url":"https://docs.sysdig.com/en/sysdig-secure/connect-cloud-accounts/aws/selective-cloud-account-onboarding/"},{"id":280,"title":"Selective Cloud Account Onboarding","content":" If you previously onboarded your Azure accounts using the legacy management_group_ids parameter, see the Azure onboarding migration guide to update to the include/exclude model.\nTo perform selective cloud account onboarding for Azure:\nLog in to Sysdig Secure as an Admin.\nNavigate to Integrations \u0026gt; Environments \u0026gt; Azure.\nFollow the steps to Configure Installation Permissions and Enter your Subscription Details.\nAt the step Subscriptions to Onboard, review the Account Selection Options.\nInclude Exclude Account Selection OptionsBy default, when you onboard an Azure account, all Management Groups are onboarded. You can configure Azure onboarding using the following methods:\nAllThis is the default option, which selects all subscriptions within the connected Azure tenant or Management Group.\nAll existing and newly created active subscriptions will be onboarded. Use this option if your organization wants full coverage across its Azure environment. Include Management GroupsThis option lets you explicitly include one or more Management Groups during onboarding.\nManagement Groups to Include All subscriptions under these Management Groups will be considered for onboarding. You can list one or more Management Groups to include during onboarding. If you are using Terraform, set them using include_management_groups. Exclude Subscriptions (optional) These subscriptions will not be onboarded, even though their parent Management Group is included. You can exclude certain subscriptions within included Management Groups. If you are using Terraform, set them using exclude_subscriptions. Include Extra Subscriptions (optional) These subscriptions will be onboarded even though their parent Management Groups are not included. You can include specific subscriptions from Management Groups that are not listed in include_management_groups by explicitly adding them to include_subscriptions. Exclude Management GroupsThis option lets you exclude one or more Management Groups from onboarding.\nManagement Groups to Exclude All subscriptions under these Management Groups will be skipped unless explicitly included. You can exclude one or more Management Groups from the onboarding process. If you are using Terraform, set them using exclude_management_groups. Include Subscriptions (optional) These subscriptions will be onboarded even if their parent Management Groups are excluded. You can include specific subscriptions from excluded Management Groups by adding their subscription IDs, ensuring they are still onboarded. If you are using Terraform, set them using include_subscriptions. Exclude Extra Subscriptions (optional) These subscriptions will not be onboarded even though their parent Management Groups are included. You can exclude specific subscriptions within included Management Groups by explicitly listing them. For both include and exclude inputs (for Management Groups and Subscriptions), always use the Azure resource IDs (for example, /providers/Microsoft.Management/managementGroups/abc-group or /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) and not display names.\nTerraform ConfigurationYou can also perform select cloud account onboarding via terraform, using the following variable:\nTerraform Variable Purpose include_management_groups Only subscriptions under these Management Groups are considered for onboarding. exclude_management_groups Any Management Groups listed here will be skipped. include_subscriptions Explicitly include these subscription IDs, even if they fall outside Management Groups exclude_subscriptions Exclude these subscriptions, even if they\u0026rsquo;re under included Management Groups ","url":"https://docs.sysdig.com/en/sysdig-secure/connect-cloud-accounts/azure/selective-cloud-account-onboarding/"},{"id":281,"title":"Selective Cloud Project Onboarding","content":" If you previously onboarded your GCP accounts using the legacy management_group_ids parameter, see the GCP onboarding migration guide to update to the include/exclude model.\nThe Selective Cloud Project Onboarding feature in Sysdig Secure gives you control over which Google Cloud folders and projects are onboarded during the initial setup.\nThis is useful for organizations that want to monitor only a subset of their cloud environment. Excluded projects can still be onboarded later individually.\nInclude Folders Exclude Folders Project Selection OptionsYou can configure onboarding with three approaches:\nAllThis option lets you select all folders in your cloud environment. This is the default selection.\nAll Folders All folders under the organization will be onboarded automatically. All projects within these folders will also be included. You can optionally exclude projects by providing their project IDs. Include FoldersThis option lets you select folders to include during onboarding. You can also exclude individual projects from these folders. You can do the following:\nSelect folders to onboard. Optionally exclude certain projects within those folders by providing their project IDs. Exclude / Include Projects (optional)This configuration allows for more granular control over project onboarding. You have the following options:\nExclude Projects: Skip onboarding for named projects within the selected folders. These projects will be skipped during onboarding, even if their parent folders are included. Include Extra Projects: Onboard individual projects from folders that were excluded. These projects will be onboarded even if their parent folders are excluded. Exclude FoldersThis option lets you omit folders from onboarding. All folders are included by default unless explicitly excluded. You can also fine-tune project-level onboarding from excluded folders.\nInclude / Exclude Projects (optional)This configuration allows for more granular control over project onboarding. You have the following options:\nInclude Projects: Onboard named projects from folders that were excluded. These projects will be onboarded, even if their parent folders are excluded. Exclude Extra Projects: Omit onboarding for named projects from included folders. These projects won\u0026rsquo;t be onboarded, even though their folders are included. Folder and project entries must be comma-separated.\nFolders: Use folder IDs, not names.\nFor example: 123456789012, 234567890123\nProjects: Use project IDs, not display names.\nFor example: my-project-id-123, my-project-id-456\n","url":"https://docs.sysdig.com/en/sysdig-secure/connect-cloud-accounts/gcp/selective-cloud-project-onboarding/"},{"id":282,"title":"Integrate Sysdig with Snyk","content":"Supported Snyk Integrations Risk Spotlight (In Use vulnerabilities) Snyk AppSec Pro Risk Spotlight IntegrationSnyk ingests and correlates Sysdig In-Use package context, enhancing prioritization.\nNote: This integration currently supports only on Kubernetes clusters.\nPrerequisites Ensure you have an active account and valid license for:\nSnyk Sysdig Secure Verify that In-Use results appear in your Sysdig screen:\nSee Attack Surface \u0026gt; Vuln Runtime Findings. If no in-use results are visible, nothing will be forwarded to Snyk.\nInstallation InstructionsBoth the Sysdig Agent and the Snyk Controller must be installed and interconnected in the same clusters. You must configure specific secrets in the Snyk Controller to interconnect them.\nIf the Sysdig Agent is not installed, install it by using the Sysdig Agent Install Guide or the Cluster Shield Installation Docs.\nIf the Snyk Controller is not installed, install it by following the Snyk Installation instructions.\nInstall the Snyk ControllerHere is a sample command:\nkubectl create secret generic snyk-monitor -n snyk-monitor \\ --from-literal=dockercfg.json={} \\ --from-literal=integrationId=abcd1234-abcd-1234-abcd-1234abcd1234 \\ --from-literal=serviceAccountApiToken=bdca4123-dbca-4343-bbaa-1313cbad4231 helm upgrade --install snyk-monitor snyk-charts/snyk-monitor \\ --namespace snyk-monitor \\ --set clusterName=\u0026#34;Production cluster\u0026#34; Once both components are installed in the same cluster, follow the Snyk Integration Docs for Sysdig to initialize the secrets required for the connection, and eventually upgrade your Snyk installation.\nInitialize secretsHere is a sample command:\nkubectl create secret generic snyk-sysdig-secret -n snyk-monitor \\ --from-literal=token=$SYSDIG_RISK_SPOTLIGHT_TOKEN \\ --from-literal=endpoint=$SYSDIG_ENDPOINT_URL \\ --from-literal=cluster=$SYSDIG_AGENT_CLUSTER Upgrade the Snyk Controller Run the following sample command: helm upgrade --install snyk-monitor snyk-charts/snyk-monitor \\ --namespace snyk-monitor \\ --set clusterName=\u0026#34;Production cluster\u0026#34; \\ --set sysdig.enabled=true Wait about 30 minutes for Snyk to collect all the information from Sysdig.\nLog in to Snyk Console and navigate to Integrations \u0026gt; Container Orchestration \u0026gt; Kubernetes.\nRe-import all the clusters and namespaces you want to enrich.\nVerifying Integration Results in the Snyk UI If the setup is successful, you can see that Runtime vulnerabilities are marked with the Executed at Runtime label in the Snyk UI.\nTroubleshootingCheck Snyk-Monitor pod logs to see if Sysdig information is being captured successfully.\nIntegrate Snyk AppRisk ProSnyk ingests and correlates data from Sysdig Cloud Inventory to collect information such as internet exposure.\nPrerequisites Ensure you have an active account and valid license for the following:\nSnyk Sysdig Secure Install Sysdig AgentEnsure that the Sysdig Agent is installed in the target clusters.\nFor the installation instructions, see Sysdig Agent Install Guide or the Cluster Shield Installation Docs.\nConfigure SnykTo configure Snyk integration, see Snyk AppRisk Pro Integrations Documentation.\nVerifying Integration Results in the Snyk UI You can view Sysdig listed as the source and new risk factors displayed on the Snyk AppRisk Inventory UI.\n","url":"https://docs.sysdig.com/en/sysdig-secure/appsec-integrations-snyk/"},{"id":283,"title":"Software Composition Analysis","content":"IntroductionSysdig\u0026rsquo;s Software Composition Analysis (SCA) integrations connect findings from your SCA tools with runtime vulnerability data discovered by Sysdig Secure. This integration enriches runtime package vulnerabilities with crucial source code context, directly addressing the core value proposition: SCA + Runtime Context = Enhanced Risk Understanding \u0026amp; Remediation.\nBy linking a runtime vulnerability back to its origin in the source code, teams can significantly accelerate triage, pinpoint ownership, and apply the correct fix efficiently.\nBenefits and Use CasesCombining SCA insights with Sysdig\u0026rsquo;s runtime data provides a clearer, more actionable path to reducing risk observed in your production environments.\nFaster Root Cause Analysis (The \u0026ldquo;WHERE\u0026rdquo;)Link runtime vulnerabilities back to the source context to immediately understand their origin.\nFor Security Teams: When investigating a runtime vulnerability, you can instantly see the associated source code repository and the specific dependency file (e.g., package.json, pom.xml) where the vulnerable package was declared. This provides a clear line of sight from runtime risk back to the codebase. For Developers and Engineers: When tasked with fixing a vulnerability, the source repository and file path are readily available. This eliminates guesswork and allows you to rapidly locate the specific code requiring modification. Better Fix Recommendations (The \u0026ldquo;HOW\u0026rdquo;)Provide actionable remediation guidance directly from SCA data.\nFor Developers and Engineers: Sysdig displays the specific, recommended safe version(s) to upgrade a vulnerable package to. This ensures you can efficiently apply the correct fix without spending time researching solutions. Links to relevant patch information or remediation advice are also provided for clear, actionable steps. For Security Teams: When assessing a runtime vulnerability, seeing the recommended fix version helps security teams understand the remediation path and effort required, facilitating better communication and planning with development teams. Process OverviewThe integration works by correlating runtime findings with data ingested from your configured SCA tool. This correlation is made possible by a specific label on your container images.\nConfigure the Integration: An administrator connects Sysdig Secure to your SCA provider (Semgrep or Snyk). Label Your Images: During your CI/CD build process, you must add the org.opencontainers.image.source label to your container images. This label tells Sysdig which source repository the image was built from. View Enriched Findings: Sysdig scans your running images. When a vulnerability is found in a package, Sysdig uses the image label to query the connected SCA tool for context about that package in the corresponding source repository. The runtime finding is then automatically enriched with details like the recommended fix version and the dependency file path. Prerequisite: Linking Source to RuntimeTo enable the correlation between runtime assets and source code, you must add a Docker label to your images at build time. This allows Sysdig to identify the source repository associated with a running container.\nTo correlate, the org.opencontainers.image.source label is required.\nDocker labels can be added in two ways:\nIn source code, by adding a LABEL statement to your Dockerfile. In your build pipeline, using the --label parameter of the docker build command. Example:\nYou can add the required label either directly in your Dockerfile or during the build process.\nAdd the LABEL instruction to your Dockerfile.\nFROM nginx:latest LABEL org.opencontainers.image.source=\u0026#34;https://github.com/${{ github.repository }}\u0026#34; Set up an SCA Integration Log in to Sysdig Secure as an administrator and select Integrations \u0026gt; Software Composition Analysis. If no integration has been added, the page is empty. If integrations already exist, a list is displayed showing the Integration Name, Type (Semgrep, Snyk), and Status. Click Add SCA Integration. Select the relevant integration type from the drop-down and complete the configuration. Aikido Ingest vulnerability and compliance data from Aikido to enrich image and runtime findings.\nArnica Connect Arnica to import risk and code security insights into Sysdig Secure.\nCheckmarx Sync Checkmarx SAST and SCA results to correlate source vulnerabilities with runtime data.\nGitHub Advanced Security Integrate with GitHub Advanced Security to enrich vulnerabilities with repository context.\nGitLab Connect GitLab projects to correlate dependency and code insights with Sysdig findings.\nMend Pull SCA results from Mend to provide enriched visibility into open-source vulnerabilities.\nSemgrep Integrate Semgrep scan data to surface code-level context within vulnerability findings.\nSnyk Connect Snyk for automatic enrichment of image and runtime vulnerabilities with fix guidance.\nAikidoCreate Client Credentials in Aikido From your Aikido settings, navigate to the Aikido public REST API integration page. Click the Add Client button to create a new integration. Give your integration a descriptive name and select Private App for the Type. Select the following permissions: issues:read clouds:read repositories:read containers:read basics:read After generating the credentials, copy the Client ID and Client Secret and store them in a safe place. Configure in Sysdig From the Add SCA Integration page, choose Aikido. Enter a unique Integration Name to identify this connection. Enter the Client ID and Client Secret you created in Aikido. Click Test Connection to validate the credentials. Upon a successful test, click Add Integration. ArnicaCreate an API Key in Arnica From your Arnica Console, navigate to the API page via the sidebar menu. Click the Create API key button. Give the API key a descriptive name. Select the risks:read permission. After the key is created, copy the value and store it in a safe place. Configure in Sysdig From the Add SCA Integration page, choose Arnica. Enter a unique Integration Name to identify this connection. Enter the Access Token (API Key) you created in Arnica. Click Test Connection to validate the credentials. Upon a successful test, click Add Integration. CheckmarxCreate an OAuth Client in Checkmarx Log in to your Checkmarx One environment and navigate to Settings \u0026gt; Identity and Access Management. Go to the OAuth Clients tab and click Create OAuth Client. Provide a name and description for the client. Assign the following minimum required scopes: View-applications View-projects View-scans View-results Alternatively, you can assign a default composite role such as ast-viewer. Click Save. Securely store the generated Client ID and Client Secret. Configure in Sysdig From the Add SCA Integration page, choose Checkmarx. Enter a unique Integration Name. Provide the following configuration parameters: API Base URL: The URL corresponding to your region. Region API Base URL US https://ast.checkmarx.net US2 https://us.ast.checkmarx.net EU https://eu.ast.checkmarx.net EU2 https://eu-2.ast.checkmarx.net Germany (DEU) https://deu.ast.checkmarx.net Australia \u0026amp; NZ https://anz.ast.checkmarx.net India https://ind.ast.checkmarx.net Singapore https://sng.ast.checkmarx.net UAE (MEA) https://mea.ast.checkmarx.net Israel (Gov-IL) https://gov-il.ast.checkmarx.net Tenant Name: Your Checkmarx One tenant name. Client ID: The Client ID from the previous step. Client Secret: The Client Secret from the previous step. Click Test Connection to validate the credentials. Upon a successful test, click Add Integration. GitHub Advanced SecurityThe GitHub Advanced Security integration uses an OAuth flow for a secure, browser-based authorization.\nConfigure in Sysdig From the Add SCA Integration page, choose GitHub Advanced Security. Enter a unique Integration Name to identify this connection. Click Connect to GitHub. You will be redirected to the GitHub website. Log in to GitHub if you are not already. Select the account or organization where you want to install the Sysdig app to grant access to Advanced Security Alerts. Choose the repositories to authorize for access (all or specific repositories). Click Install and Authorize to complete the installation. Upon successful authorization, you will be redirected back to the Sysdig Secure UI, and the connection will be finalized automatically. GitLabThe GitLab integration uses an access token to authenticate. You can create a Personal, Group, or Project Access Token depending on the desired scope of access.\nCreate a GitLab Access TokenCreate a Personal, Group, or Project access token in GitLab with the following configuration:\nRole: Developer Scopes: read_api read_repository read_registry Expiration Date: Set to the maximum possible date. Record your access token and store it in a safe place. You will not be able to see it again after closing the window.\nFor detailed instructions, refer to the official GitLab documentation for Project, Group, or Personal access tokens.\nFind Project IDs (Optional)If you use a token with broad access (like a Personal or Group token) and want to restrict the integration to specific projects, you will need their Project IDs.\nIn GitLab, navigate to the project’s main page. The Project ID is visible under the project name on the overview page or in Settings \u0026gt; General. Collect the IDs for all projects you wish to include. Configure in Sysdig From the Add SCA Integration page, choose GitLab. Enter a unique Integration Name. Enter the GitLab Access Token you created. (Optional) In the Allowed Project IDs field, enter a comma-separated list of Project IDs to restrict scanning to specific projects (e.g., 67411111,67422222). This is recommended if your token has access to more projects than you intend to scan. Click Test Connection to validate the credentials. Upon a successful test, click Add Integration. MendThe Mend integration requires an Organization UUID and a Service User key.\nGather Credentials from Mend Log in to the Mend Platform dashboard. Click the Settings (gear icon) and select Administration. On the General Configuration screen, copy the Organization UUID and save it. Navigate to the Users tab and click Add Service User. Enter a User Name. The Email Address will be auto-generated. Click OK to create the service user. In the Users table, find the new user, click the three dots (\u0026hellip;), and select Copy User Key. Securely store the Organization UUID, the auto-generated User Email, and the User Key. Configure in Sysdig From the Add SCA Integration page, choose Mend. Enter a unique Integration Name. Enter your Mend Organization UUID, User Email, and User Key. Click Test Connection to validate the credentials. Upon a successful test, click Add Integration. SemgrepThe Semgrep integration requires an API token with specific permissions.\nCreate the API Token in Semgrep Log in to your Semgrep account. Navigate to Settings \u0026gt; Tokens. Under API Tokens, click Create new token. In the pop-up window, enable the following scopes for the token: Agent CI Web API Record your API token and store it in a safe place. You will not be able to see it again after closing the window. Click Save. Configure in Sysdig From the Add SCA Integration page, choose Semgrep. Enter a unique Integration Name to identify this connection. Enter your Semgrep Organization Name. You can find this in your Semgrep URL (e.g., semgrep.dev/manage/my-org). Enter the API Token you created in the previous steps. Click Test Connection to validate the credentials. Upon a successful test, click Add Integration. SnykThe Snyk integration uses OAuth2 for a secure, browser-based authorization flow. You do not need to manually create or manage API tokens.\nNote Snyk EU Region Limitations\nDue to differences in the Snyk API for the EU region, some enrichment data may not be available for EU-based customers. This can include fields such as remediation advice, cvss_score, and whether a fix is patchable.\nConfigure in Sysdig From the Add SCA Integration page, choose Snyk. Enter a unique Integration Name to identify this connection. Enter your Snyk Organization ID. This can be found in your Snyk organization\u0026rsquo;s settings URL. Click Connect to Snyk. You will be redirected to the Snyk website in a new browser tab. Log in to Snyk if you are not already. A Snyk page will ask you to authorize Sysdig to access your resources. Review the permissions and click Authorize. Upon successful authorization, you will be redirected back to the Sysdig Secure UI. The connection will be finalized automatically. The status should show as Active. Validate the IntegrationOnce an integration is configured, its status will appear in the Software Composition Analysis integrations list.\nStatus: The status should be Active, indicating a successful connection between Sysdig Secure and your SCA provider. If there is an error, review your configuration details and credentials. Viewing Enriched Data: Validation is confirmed by observing the enriched data in your runtime vulnerability findings. Navigate to Vulnerabilities \u0026gt; Findings, and select a vulnerability associated with an image that has the org.opencontainers.image.source label. It may take up to 24 hours for the enriched data to appear. In the vulnerability details, you will now see new fields populated with data from your SCA tool:\nRepository, URL, Branch, Commit: Pinpoints the exact location in your source code where the vulnerable package originates, including the repository name, clone URL, branch, and specific commit hash. File Path: Shows the path to the manifest file (e.g., package.json) that declares the vulnerable dependency. Remediations: Provides actionable suggestions from the SCA tool, such as the safe version to upgrade to. Vendor Links: Offers direct links to the SCA provider\u0026rsquo;s resources, such as their knowledge base or a specific issue tracker for the vulnerability, for deeper investigation. ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/integrations-for-sysdig-secure/software-composition-analysis/"},{"id":284,"title":"Sysdig Agent","content":"Prerequisites Review Installation Requirements Understand Agent Drivers Collect the following: Sysdig access key Collector address For more information on agent configuration, see Configure Sysdig Agent.\nCustomized DeploymentThis option can be integrated with your enterprise deployment methods at a production scale.\nGuidelinesIn a customized Sysdig agent deployment, the Sysdig agent probe (kernel module) and the Sysdig agent are deployed as separate containers.\nWhen you upgrade the kernel, rebuild the Sysdig agent probe by rerunning the sysdig-agent-kmodule container.\nIf the kernel headers are missing on the node where the Sysdig agent is running, rerun the sysdig-agent-kmodule container after every OS reboot.\nGKE COS environments require the eBPF or Universal eBPF driver to run the Sysdig Agent. Agent versions 12.17.0 and newer ship with a pre-built Universal eBPF object embedded in the agent binary. Running the sysdig-agent-kmodule container is not necessary when using the Universal eBPF driver. Installation Build and load the kernel module or eBPF object file, kernel module and eBPF drivers, only:\nIf you are using the kernel module, driver, run:\ndocker run -it --privileged --rm --name sysdig-agent-kmodule \\ -v /usr:/host/usr:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules \\ quay.io/sysdig/agent-kmodule If you are using the eBPF driver, run:\ndocker run -it --privileged --rm --name sysdig-agent-kmodule \\ -e SYSDIG_BPF_PROBE=\u0026#34;\u0026#34; \\ -v /usr:/host/usr:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /etc/os-release:/host/etc/os-release:ro \\ -v /root/.sysdig:/root/.sysdig \\ quay.io/sysdig/agent-kmodule If you are using Universal eBPF, skip to step 3. Configure the kernel module to load during system boot, skip for eBPF and Universal eBPF:\nsudo mkdir -p /etc/modules-load.d sudo bash -c \u0026#34;echo sysdigcloud-probe \u0026gt; /etc/modules-load.d/sysdigcloud-probe.conf\u0026#34; Run the agent container providing the access key and, optionally, user-defined tags:\nIf you are using kernel module, run:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ --shm-size=512m \\ quay.io/sysdig/agent-slim If you are using eBPF, run:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e SYSDIG_BPF_PROBE=\u0026#34;\u0026#34; \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt; ] \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /root/.sysdig:/root/.sysdig \\ --shm-size=512m \\ quay.io/sysdig/agent-slim If you are using Universal eBPF, run:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e SYSDIG_AGENT_DRIVER=universal_ebpf \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt; ] \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /proc:/host/proc:ro \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ --shm-size=512m \\ quay.io/sysdig/agent-slim Replace \u0026lt;ACCESS_KEY\u0026gt; and \u0026lt;COLLECTOR_ADDRESS\u0026gt; with the access key and collector address collected in the prerequisites. \u0026lt;TAGS\u0026gt; is optional.\nVerify that the Sysdig Agent is running by running the following command:\ndocker ps You should see the sysdig-agent container listed in the output.\nFor additional configuration options, including on-premise, using a proxy, etc., see Agent Configuration.\nInstall As a Single Container (Legacy)The legacy way of installing an agent involves running it as a single container. It includes the components for downloading and building the kernel module, as well as for gathering and reporting on a wide variety of pre-defined metrics and events.\nSaaS Collect the necessary environment variables.\nRun the agent container providing the access key and, optionally, user-defined tags:\nIf you are using kernel module, use the following:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=512m \\ -v /etc/modprobe.d:/etc/modprobe.d \\ quay.io/sysdig/agent If you are using eBPF use the following:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] \\ -e SYSDIG_BPF_PROBE=\u0026#34;\u0026#34; \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=512m \\ quay.io/sysdig/agent If you are using Universal eBPF, use the following:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] \\ -e SYSDIG_AGENT_DRIVER=universal_ebpf \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ --shm-size=512m \\ quay.io/sysdig/agent-slim On-Premises Collect the necessary environment variables.\nRun the agent container providing the access key and, optionally, user-defined tags:\nIf you are using kernel module, run:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=512m \\ quay.io/sysdig/agent If you are using eBPF, run:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] -e SYSDIG_BPF_PROBE=\u0026#34;\u0026#34; \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=512m \\ quay.io/sysdig/agent If you are using Universal eBPF, run:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] -e SYSDIG_AGENT_DRIVER=universal_ebpf \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ --shm-size=512m \\ quay.io/sysdig/agent-slim Common Environment Variables for Agent Containers Option Description ACCESS_KEY The agent access key. You can retrieve this from Admin \u0026gt; Agent Access Keys in either Sysdig Monitor or Sysdig Secure. TAGS The list of tags for the host where the agent is installed. For example: role:webserver, location:europe COLLECTOR The collector URL for Sysdig Monitor or Sysdig Secure. This value is region-dependent in SaaS and is auto-completed on the Get Started page in the Monitor UI or Data Sources page in Secure. It is a custom value in on-prem installations. See SaaS Regions and IP Ranges. COLLECTOR_PORT The default is 6443. ADDITIONAL_CONF Optional. Use this option to provide custom configuration values to the agent as environment variables. If provided, will be appended to the agent configuration file. SYSDIG_AGENT_DRIVER Optional. The syscall capture driver that is used by the agent. Valid values are kmod, universal_ebpf, and legacy_ebpf. Agent defaults to kmod if this environment variable is not set SYSDIG_BPF_PROBE Optional. Deprecated and superseded by SYSDIG_AGENT_DRIVER. The old environment variable that is used to force the agent to load the current eBPF driver. Valid values are \u0026quot;\u0026quot; or a path within the container to a compatible eBPF object file.\nNote:The agent will exit with an error if SYSDIG_AGENT_DRIVER and SYSDIG_BPF_PROBE are set to conflicting values. See Understand the Agent Configuration for additional information on agent and container environment variables.\nMount PointsGiven below is the list of all the volumes that need to be shared from the agent and the host. For each container, you can see the volumes in the source:destination format.\nVolumes /dev: Required to interact with the ring buffer in the kmodule.\n/proc: Required to get information about the current processes running in the host.\n/etc: Required to get certain information about the system. The os-release to detect certain distros and passwd / group to get uids and gids.\n/etc/modprobe.d: Identify the kernel modules available. See the manpage for more information.\n/boot: Contains the information related to the kernel module required to compile the drivers or get the proper kernel hash if you need to download the driver from the CDN.\n/lib/modules: Contains the kernel module build environment.\n/usr: Gets /usr/src/linux for the kernel sources.\n/run: Some systems use this instead of /var/run.\n/var/lib: Provides visibility into container filesystems.\n/var/run: This is where the cri socket is stored for interacting with the CRI container runtime.\n/root/.sysdig: The directory where the ko file that you build is stored when you need to build the eBPF module that needs to be loaded by the agent.\n/sys/kernel/debug: Required to expose information available in the kernel into user space. See debugfs for more information.\nAlways /dev:/host/dev /proc:/host/proc /dev/shm:/dev/shm Agent Container with Kernel ModuleContainer image on Quay: https://quay.io/sysdig/agent\n/etc/modprobe.d:/etc/modprobe.d (read-only mode)\n/etc:/host/etc (read-only mode)\n/boot:/host/boot (read-only mode)\n/lib/modules:/host/lib/modules (read-only mode)\n/usr:/host/usr (read-only mode)\n/run:/host/run\n/var/lib:/host/var/lib (read-only mode)\n/var/run:/host/var/run\nAgent Container with eBPFContainer image on Quay https://quay.io/sysdig/agent\n/etc/modprobe.d:/etc/modprobe.d (read-only mode)\n/etc:/host/etc (read-only mode)\n/boot:/host/boot (read-only mode)\n/lib/modules:/host/lib/modules (read-only mode)\n/usr:/host/usr (read-only mode)\n/run:/host/run\n/var/lib:/host/var/lib (read-only mode)\n/var/run:/host/var/run\n/sys/kernel/debug:/sys/kernel/debug (read-only mode)\nSlim Agent Container with Kernel ModuleContainer image on Quay https://quay.io/sysdig/agent\n/etc:/host/etc (read-only mode)\n/run:/host/run\n/var/lib:/host/var/lib (read-only mode)\n/var/run:/host/var/run\nSlim Agent Container with eBPF or Universal eBPFContainer image on Quay https://quay.io/sysdig/agent\n/etc:/host/etc (read-only mode)\n/run:/host/run\n/var/lib:/host/var/lib (read-only mode)\n/var/run:/host/var/run\n/sys/kernel/debug:/sys/kernel/debug (read-only mode)\nAgent Kmodule Container with Kernel ModuleContainer image on Quay https://quay.io/sysdig/agent\n/etc/modprobe.d:/etc/modprobe.d (read-only mode)\n/etc:/host/etc (read-only mode)\n/boot:/host/boot (read-only mode)\n/lib/modules:/host/lib/modules (read-only mode)\n/usr:/host/usr (read-only mode)\nAgent Kmodule Container with eBPFContainer image on Quay https://quay.io/sysdig/agent\n/etc/modprobe.d:/etc/modprobe.d (read-only mode)\n/etc:/host/etc (read-only mode)\n/boot:/host/boot (read-only mode)\n/lib/modules:/host/lib/modules (read-only mode)\n/usr:/host/usr (read-only mode)\n/root/.sysdig:/root/.sysdig\nShares the eBPF driver between the container that builds the driver and the container that loads the driver\n/sys/kernel/debug:/sys/kernel/debug (read-only mode)\nNext StepsInstall the Host Scanner as a container\nInstall the Rapid Response as a container\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-container-agent/"},{"id":285,"title":"Sysdig Agent","content":"Customized DeploymentsPrerequisites Review Installation Requirements Understand Agent Drivers Collect the following: Sysdig access key Collector address Ensure that you have admin permissions to perform the operations. Supported DistributionsInstalling agent as a package is supported on the following :\nDebian, Ubuntu CentOS, RHEL, Fedora, Amazon AMI, Amazon Linux 2 Starting with agent version 13.1.0, separate packages will have to be installed depending on the driver to be used. See the table below.\nPackage Reference Driver Main Package Dependency Packages kmod (compatibility mode) draios-agent draios-agent-slim, draios-agent-kmodule kmod (recommended) draios-agent-kmodule draios-agent-slim legacy_ebpf draios-agent-legacy-ebpf draios-agent-slim universal_ebpf draios-agent-slim Debian and Ubuntu Trust the Sysdig GNU Privacy Guard (GPG) key, configure the apt repository, and update the package list by running the following commands:\ncurl -s https://download.sysdig.com/DRAIOS-GPG-KEY.public -o /usr/share/keyrings/sysdig-keyring.asc echo \u0026#39;deb [signed-by=/usr/share/keyrings/sysdig-keyring.asc] https://download.sysdig.com/stable/deb stable-$(ARCH)/\u0026#39; | sudo tee /etc/apt/sources.list.d/sysdig.list \u0026gt; /dev/null apt-get update Install kernel development files, (kernel module and eBPF drivers, only):\nsudo apt-get -y install linux-headers-$(uname -r) Install, configure, and restart the Sysdig agent:\nInstall the agent:\nsudo apt-get -y install draios-agent Specify the agent driver:\nTo select the eBPF driver: cat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#39;export SYSDIG_BPF_PROBE=\u0026#34;\u0026#34;\u0026#39; cat \u0026gt;\u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=legacy_ebpf\u0026#34; To select the Universal eBPF driver: cat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=universal_ebpf\u0026#34; To select the kernel module driver: cat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=kmod\u0026#34; Note: On new installations, the kernel module driver is selected by default, and specifying it explicitly in /etc/default/dragent is optional. Configure dragent.yaml:\nsudo bash -c \u0026#39;echo customerid: ACCESS_KEY \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml\u0026#39; sudo bash -c \u0026#39;echo tags: [TAGS] \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml\u0026#39; sudo bash -c \u0026#39;echo collector: COLLECTOR_ADDRESS \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml\u0026#39; Replace ACCESS_KEY and COLLECTOR_ADDRESS with the access key and collector address associated with your account. \u0026lt;TAGS\u0026gt; is optional and can be used to add custom tags to your metrics.\nRestart the agent:\nsudo service dragent restart For CentOS, RHEL, Fedora, Amazon AMI, Amazon Linux 2 Trust the Sysdig GPG key and configure the yum repository:\nsudo rpm --import https://download.sysdig.com/DRAIOS-GPG-KEY.public \u0026amp;\u0026amp; sudo curl -s -o /etc/yum.repos.d/draios.repo https://download.sysdig.com/stable/rpm/draios.repo Install the EPEL repository, (kernel module and eBPF drivers, only):\nsudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm This command is required only if DKMS is not available in the base distribution.\nInstall the kernel development files, (kernel module and eBPF drivers, only):\nsudo yum -y install kernel-devel-$(uname -r) Install, configure, and start the Sysdig Agent:\nInstall the agent: yum -y install draios-agent Specify the agent driver: To select the kernel module driver: cat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=kmod\u0026#34; Note: On new installations, the kernel module driver is selected by default, and specifying it explicitly in /etc/sysconfig/dragent is optional. To select the eBPF driver cat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#39;export SYSDIG_BPF_PROBE=\u0026#34;\u0026#34;\u0026#39; cat \u0026gt;\u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=legacy_ebpf\u0026#34; To select the Universal eBPF driver: cat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=universal_ebpf\u0026#34; Configure dragent.yaml: echo customerid: ACCESS_KEY \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml echo tags: [TAGS] \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml echo collector: COLLECTOR_ADDRESS \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml Replace ACCESS_KEY and COLLECTOR_ADDRESS with your own configuration parameters. [TAGS] is optional and can be used to add custom tags to the agent\u0026rsquo;s metrics. For example, env:production, cluster:east-cluster-a. Start the agent: sudo systemctl enable dragent sudo systemctl start dragent Next StepsInstall the Host Scanner using a package\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-hosts-packages-agent/"},{"id":286,"title":"Sysdig Agent","content":"Container PlatformsSysdig Secure supports the following platforms:\nKubernetes v1.11 and above\nWithin this, Sysdig supports:\nGoogle Kubernetes Engine (GKE)\nAmazon Elastic Kubernetes Service (EKS)\nNote: Amazon Web Services (AWS) Fargate is not supported on EKS\nAzure Kubernetes Service (AKS)\nIBM Cloud Kubernetes Service (IKS)\nRedHat OpenShift Kubernetes Service (ROKS) v4 and above\nAmazon ECS on EC2\nLinux DistributionsSysdig supports the following distributions:\nDebian Ubuntu 18.04 and above Ubuntu (Amazon) CentOS 7 and above Alma Linux Rocky Linux Red Hat Enterprise Linux (RHEL) 7 and above SuSE Linux Enterprise Server* RHEL CoreOS (RHCOS) Fedora Fedora CoreOS Linux Mint Amazon Linux Amazon Linux v2 Amazon Linux v3 Amazon Bottlerocket Google Container Optimized OS (COS) Oracle Linux (UEH) Oracle Linux (RHCK) Azure Linux (CBL-Mariner) EulerOS ArchLinux Alpine Linux 3.20 and above * Linux service install is not supported on SuSE Linux Enterprise Server.\nLinux Kernel Linux Kernel 3.10 and later Windows OS VersionsSysdig supports the following Windows OS versions:\nWindows Server 2019 and later Container RuntimesSysdig supports the following Container Runtimes:\nDocker LXC CRI-O containerd* Podman Mesos * Standalone containers that use the containerd Runtime are not supported.\nCPU Architectures X86 ARM* s390x (zLinux)** * Prebuilt probes and agent installation using the full agent container are not supported. Use agent-slim instead.\n** Prebuilt probes, Captures and agent installation using the agent container are not supported. s390x supports only RHEL and OpenShift.\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-req-agent/"},{"id":287,"title":"Sysdig On-Premises Release Support","content":"Sysdig On-Premises Release Versioning SystemSysdig utilizes a semantic versioning system for On-Premises releases. Each release version number is in the format of X.Y.Z, where X is the major version, Y is the minor version, and Z is the hotfix version, if there is one. Here is what each version category signifies:\nMajor Versions (X)A major release is defined as having significant changes to the software, such as changes in architecture, addition of infrastructure components and major services.\nMinor Versions (Y)A minor release typically includes new features, performance enhancements or vulnerability fixes.\nHotfix (Z)A hotfix is created when an issue is identified, either in the field or internally, that requires an immediate fix. They do not introduce new features, but aim to improve the stability and reliability of the software.\nSee the Sysdig On-Premises Releases Notes for specific changes introduced with each release version.\nSupport Period and DetailsIf you run Sysdig On-Premises, we encourage you to stay up to date with the latest releases. This ensures you benefit from the new features and defect fixes we offer.\nSysdig provides support for all minor releases for an 18-month period from their initial release date. For example, v6.9.0 was released in February 2024 and will be supported until August 2025. However, if a hotfix, for example v.6.9.1, is released in March 2024, this will not postpone the end of support date for v.6.9.x, in this case August 2025.\nIf an issue is found in a supported version, we expect you to upgrade to the latest available version with the fix. If none of the existing versions has the fix, a fix will be made available in an upcoming minor release. For example, if an issue arises in v6.9 and it is first fixed in v6.11 then you are expected to upgrade to v6.11 or higher.\nSupport for VulnerabilitiesSysdig will make commercially reasonable efforts to fix known and impacting vulnerabilities for the most recent On-Premises release. This includes critical, high, medium, and low CVE severities. For critical and high vulnerabilities that are not fixed with the latest minor version, Sysdig can provide a Security Advisory document that details the impact exposure.\nExtended Support PhaseOnce a release has become unsupported, Sysdig will continue with an extended support phase for 6 months following sunset of a particular release. Extended support is limited to configuration assistance and technical guidance for upgrades to supported versions. It will not cover engineering support for new feature requests, bug fixes, security patches or any type of support for non-production deployments (collectively, “Extended Support”).\nVersion Support Version Release Date Supported Until Extended Support Until 7.7.x April 2026 October 2027 April 2028 7.6.x February 2026 August 2027 February 2028 7.5.x November 2025 May 2027 November 2027 7.4.x August 2025 February 2027 August 2027 7.3.x June 2025 December 2026 June 2027 7.2.x April 2025 October 2026 April 2027 7.1.x April 2025 October 2026 April 2027 7.0.x February 2025 August 2026 February 2027 6.16.x January 2025 July 2026 January 2027 6.15.x December 2024 June 2026 December 2026 6.14.x September 2024 March 2026 September 2026 6.13.x July 2024 January 2026 July 2026 6.12.x June 2024 December 2025 June 2026 6.11.x April 2024 October 2025 April 2026 6.10.x March 2024 September 2025 March 2026 6.9.x February 2024 August 2025 February 2026 6.8.x January 2024 July 2025 January 2026 6.7.x December 2023 June 2025 December 2025 6.6.x November 2023 May 2025 November 2025 6.5.x September 2023 March 2025 September 2025 6.4.x August 2023 February 2025 August 2025 6.3.x July 2023 January 2025 July 2025 6.2.x June 2023 December 2024 June 2025 6.1.x May 2023 November 2024 May 2025 6.0.x April 2023 October 2024 April 2025 5.x End-of-Support If you have questions regarding Sysdig Support policy, contact Sysdig Support.\nKubernetes support matrixSysdig continuously validates multiple Kubernetes flavors, such as kOps, Openshift4, EKS, GKE, AKS, IKS, ROKS and RKE2.\nFor our Kubernetes support matrix, see K8s Support Matrix.\nIf you have a question about a custom flavor or Kubernetes version, contact Sysdig Support.\nSupported Migration PathsIn general, Sysdig tests and supports direct upgrades from two releases back to the current version.\nFor information on updating your version of On-Prem, see Supported Migration Paths.\n","url":"https://docs.sysdig.com/en/administration/sysdig-onprem-release-support/"},{"id":288,"title":"Sysdig Python SDK","content":"Sysdig Platform CLIThe Sysdig Platform CLI (sdc-cli) is a unified tool implemented using Sysdig Python SDK to manage Sysdig Monitor and Sysdig Secure using your terminal.\nSysdig Platform CLI is no longer under active maintenance. For the most up-to-date endpoints and support, use the Sysdig API.\nAccess the Platform CLI DocumentationSee sysdig-platform-cli.\nGuidelines For information on locating the SDC_MONITOR_TOKEN or SDC_SECURE_TOKEN, see Retrieve the Sysdig API Token\nFor SDC_MONITOR_URL and SDC_SECURE_URL: Use the endpoint for where your Sysdig application is deployed.\nSaaS: See SaaS Regions and IP Ranges\nOn-Premises: Self-defined\nOn-Premises: To disable SSL verification, usually needed for on-prem installs due to self-signed certificates, add the environmental option SDC_SSL_VERIFY with the value FALSE. The default value is TRUE.\nSysdig Python SDKSysdig Python SDK includes a Python library and a collection of Python sample scripts to expose and use some of the most common Sysdig API functions. Sysdig Python SDK is also known as the sdcclient. Typically, operations are either making minor modifications to a sample Python script to automate something simple, such as creating users or adding users to teams, or working along with the Sysdig professional services to customize samples and create more complex application integrations\nThis topic helps you install and instantiate the sdcclient using the Sysdig Platform CLI. For the latest information, see the following:\nSysdig Platform CL1 sysdig-sdk-python Prerequisites Python version 3.8 or above\nLatest pip version\npip is installed as part of the Python package for versions 2.7 and later\nvirtualenv (recommended)\nSysdig API token\nRetrieve the Sysdig API TokenWhen using the Sysdig API with custom scripts or applications, you must supply an API security token specific to each team.\nLog in to Sysdig Monitor or Sysdig Secure.\nSelect Settings \u0026gt; User Profile.\nThe API token is displayed (depending on which interface and team you logged in to).\nCopy the token for use, or click the Reset Token button to generate a new one.\nWhen reset, the previous token issued will immediately become invalid and you will need to make appropriate changes to your programs or scripts.\nInstall the Python ClientUse the following methods to install sdcclient:\nUse the Pip CommandInstall the client by using pip:\npip install sdcclient Identify Your API ServerSAASUse the endpoint for where your Sysdig application is deployed. Open it in a browser and check the drop-down to verify the API URL you should use in the client installation script.\nThe default region is US East and the URL is app.sysdig.cloud.com.\nOn-PremisesFor the On-Premises Sysdig Platform installations, you need to use the hostame or IP where your Sysdig API server is running.\nOption 1To do so, set the following environment variables before running your Python scripts:\nexport SDC_URL=\u0026#39;https://\u0026lt;YOUR-API-SERVER-HOSTNAME-OR-IP\u0026gt;\u0026#39; If you are using a self-signed certificate, set following variable:\nexport SDC_SSL_VERIFY=\u0026#39;false\u0026#39; Disable the SSL verification only if you don\u0026rsquo;t have a valid certificate.\nOption 2Alternatively, you can specify the additional arguments in your Python scripts as you instantiate sdcclient:\nclient = SdMonitorClient(api_token, sdc_url=\u0026#39;https://\u0026lt;YOUR-API-SERVER-HOSTNAME-OR-IP\u0026gt;\u0026#39;, ssl_verify=False) Proxy SupportThe sdcclient supports the following environment variables:\nHTTP_PROXY HTTPS_PROXY NO_PROXY Open the terminal and set the HTTPS_PROXY and NO_PROXY environment variables:\nexport HTTPS_PROXY=\u0026#34;http://myproxy.domain.com:8080\u0026#34; export NO_PROXY=\u0026#34;127.0.0.1,localhost,.myinternal.domain.com\u0026#34; Alternatively, you can add the following setting to your Python scripts as follows.\nimport os os.environ[\u0026#39;HTTPS_PROXY\u0026#39;] = \u0026#39;http://myproxy.domain.com:8080\u0026#39; os.environ[\u0026#39;NO_PROXY\u0026#39;] = \u0026#39;127.0.0.1,localhost,.myinternal.domain.com\u0026#39; Instantiate the Library ClassesThe library exports two classes, SdMonitorClient and SdSecureClient which are used to connect to the Sysdig Monitor and Secure backend and execute actions.\nFor backwards compatibility purposes, a third class sdcclient is exported which is an alias of SdMonitorClient.\nThey are instantiated as follows:\nfrom sdcclient import SdMonitorClient api_token =\u0026#34;MY_API_TOKEN\u0026#34; # # Instantiate the Sysdig Monitor client # client = SdMonitorClient(api_token) Once instantiated, all the methods documented in the Python Script Library can be called on the object.\nReturn ValuesEvery method in the SdMonitorClient or SdSecureClient classes returns a list with two entries. The first one is a boolean value indicating if the call was successful. The second entry depends on the result:\nIf the call was successful, it\u0026rsquo;s a dictionary reflecting the json returned by the underlying REST call\nIf the call failed, it\u0026rsquo;s a string describing the error\nFor an example on how to parse the output, see get_data_simple.py\nUse Logs for LearningIf your goal is to interact with the REST API directly, you can use the Python client library to understand the REST interactions by logging the actions it takes. This is useful because full documentation of the REST API has not yet been created; it also provides a complete example of known working operations.\nUse or modify an example, or write a new script against the Python sdcclient module.\nLog the HTTP requests made by the script.\nTo log all the requests made by your script in significant detail, add to your script:\nimport logging import httplib httplib.HTTPConnection.debuglevel = 1 logging.basicConfig() # you need to initialize logging, otherwise you will not see anything from requests logging.getLogger().setLevel(logging.DEBUG) requests_log = logging.getLogger(\u0026#34;requests.packages.urllib3\u0026#34;) requests_log.setLevel(logging.DEBUG) requests_log.propagate = True Then run the command as normal.\nNext Steps Explore the sample Python scripts\nSee the Sysdig SDK for Python\nLearn about using Sysdig Platform CLI\n","url":"https://docs.sysdig.com/en/developer-tools/sysdig-python-sdk/"},{"id":289,"title":"Threshold Alerts","content":" Threshold Alerts were formerly known as Metric Alerts.\nCreate a Threshold AlertTo create a Threshold Alert:\nLog in to Sysdig Monitor and open Alerts from the left navigation bar. Click Add Alert and choose Threshold to begin defining a Threshold Alert. Define a Threshold Alert Scope: The alert is set to apply to the Entire Infrastructure of your Team Scope by default. However, you can restrict the alert scope by filtering with specific labels, such as cloud_provider_region or kube_namespace_name.\nThreshold: Select the metric you want to monitor, and configure how you want the data to be aggregated. For instance, if you want to monitor the read latency of a Cassandra Cluster, you can set the metric to cassandra_read_latency. From there, you can choose the aggregation method that best suits your needs. For example, if you want to understand the mean latency across the entire cluster, you can use the average aggregation. Alternatively, if you want to identify nodes with the highest latency, you can use the maximum aggregation.\nGroup By: By grouping metrics by labels such as cloud_provider_availability_zone, a unique segment is generated for each availability zone. This allows you to quickly detect if a particular availability zone is responsible for increased cassandra_read_latency or other performance degradation.\nTime Aggregation: Also known as the Range, the Time Aggregation of an alert rule determines the time window over which the selected metric is aggregated. For example, if you select the avg time aggregation for the cassandra_read_latency with a value of 10m, it calculates the average value of the cassandra_read_latency metric over a rolling 10m window. This time aggregation defines how far back in time the metric values are considered for time aggregation.\nDuration: Duration defines the time an alert condition must continuously be satisfied before triggering an alert. For instance, a duration of 10m means the condition must be met for a continuous 10 minutes. If the alert condition is not satisfied at any time within this period, the 10-minute timer resets and must be satisfied for a full, uninterrupted 10 minutes again. Setting a longer duration reduces false positives by preventing alerts from being triggered by short-lived threshold violations\nTime Aggregation and DurationThe Time Aggregation of an alert query defines the time period over which the relevant metric data is evaluated. It should not be confused with the Duration of an alert rule, which refers to the length of time an alert condition must be met before it triggers an alert.\nFrequency of Alert Rule EvaluationThe Alert Editor automatically displays the time window that works best with your alert rule. Every data point in the alert preview corresponds with an evaluation of an alert rule.\nThe frequency at which an alert rule is evaluated depends on the Time Aggregation specified in its query. For example:\nIf you set up an alert query with a Time Aggregation of 40 minutes, the rule evaluates every 1 minutes If you set up a query with a Time Aggregation of 4 hours, the alert evaluates every 10 minutes. Re-notifications for an alert cannot be sent more frequently than the alert rule’s evaluation interval and must be a multiple of this interval. For example, if an alert rule is evaluated every 10 minutes, re-notifications can only occur at multiples of the evaluation frequency, such as 20 minutes, 30 minutes, and so forth.\nTime Aggregation of Alert Query Frequency of Alert Rule Evaluation up to 3h 1m up to 1d 10m up to 7d 1h up to 60d 1d 60d+ Not Supported To view time series data older than the recommended window, click Explore Historical Data in the top right corner of Alert Editor. This will populate a PromQL Query in the Explore module with your current settings.\nSnapshots in Alert NotificationsThreshold Alert notifications include a snapshot of the triggering time series data when forwarded to Slack, Email, Pagerduty, or Microsoft Teams. When the notification channel is configured to Notify when Resolved, a snapshot of the time series data that resolves the alert is also provided in the notification. For Slack notification channels, you can choose whether to include a snapshot in the notification channel settings. See Customize Notifications.\nNotification Channels that Support Snapshots in Alert Notifications Notification Channel Snapshot Support Email ✅ Slack ✅ Pagerduty ✅ Microsoft Teams ✅ Google Chat 🚫 Custom Webhook 🚫 OpsGenie 🚫 VictorOps 🚫 Prometheus Alertmanager 🚫 Enriched Labels in Threshold Alert NotificationsAll Threshold Alert notifications are enriched by default with contextual labels, which aid in faster issue identification and resolution. When an alert rule triggers, Sysdig automatically appends contextual labels to the alert notification, such as host_hostname, cloud_provider_region, and kube_cluster_name.\nMultiple ThresholdsIn addition to an alert threshold, a warning threshold can be configured. Warning thresholds and alert thresholds can be associated with different notification channels. In the following example, you may want to send a warning and alert notification to Slack, but also page the on-call team on Pagerduty if an alert threshold is met.\nIf both warning and alert thresholds are associated with the same notification channel, a metric immediately exceeding the alert threshold will ignore the warn threshold and only trigger the alert threshold.\nCreate an Alert on No DataWith the No Data alert configuration, you can choose how to handle situations when there is no incoming data for a metric across all its time series. In the Settings section, select from the two options for No Data:\nIgnore: Select this option if you prefer not to receive notifications when all time series of a metric stop sending data.\nNotify: Choose this if you want to be alerted when data stops coming in for all time series of a metric.\nA No Data alert will not be triggered by an individual time series ceasing to report data; it activates only when all time series for a metric stop reporting.\nThreshold Alerts in Sysdig Monitor do not auto-resolve when a time series that triggered an alert rule stops reporting data, unlike Prometheus alerts which can auto-resolve under similar conditions. This means you must manually resolve an alert occurrence if the time series that triggered the alert rule ceases to report data.\nTranslate to PromQLYou can automatically translate from Form to PromQL in order to leverage the flexibility and power of PromQL. Use the Translate to PromQL option to create more complex queries.\nThis query, for example, looks at the percentage of available memory on a host:\nsysdig_host_memory_available_bytes / sysdig_host_memory_total_bytes * 100\nThresholds are configured separately from the query. This means you can specify both an alert threshold and a warning threshold.\nExample: Alert When Data Transfer Over the ThresholdThe example given below shows an alert that triggers when the average bytes of data transferred by a container is over 500 KiB/s for a period of 1 minute.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/threshold-alerts/"},{"id":290,"title":"Monitor Time Series Billing","content":" Time Series billing only applies to time series generated by Custom Metrics. For more information on controlling metric usage, see Reduce Metrics Consumption.\nCustom Time Series EntitlementEntitlement, sometimes referred to as \u0026ldquo;Reserved Time Series\u0026rdquo;, is the maximum number of custom time series included in your Sysdig Monitor subscription before incurring additional charges. You can increase your custom time series entitlement by purchasing additional Sysdig Agents or time series packs.\nCustom time series consumption is totaled across all agents in your environment. For billing, whether one agent consumes 3000 time series and the other 1000, or if both agents use 2000 each; the total usage is the same.\nSee check your entitlement, see View Your Subscription.\nCustom Time Series BillingSysdig calculates the time series ingestion overage price in the following way:\nSysdig meters total custom time series consumption for each hour. Sysdig compares the hourly custom time series consumption to your hourly custom time series entitlement. Any custom time series ingestion exceeding your hourly limit is considered overage for that hour. Sysdig calculates your monthly bill using the 95th percentile of all hourly overage amounts, so you won\u0026rsquo;t be charged for brief spikes or occasional high usage periods. For a more detailed example, see Scenarios.\nTime Series PacksYou can purchase time series packs to increase your custom time series entitlements. A time series pack includes 1000 time series and is charged monthly. For example, if the time series entitlement in your account was 30,000, and you purchased 10 time series packs, the time series entitlement in your account would increase to 40,000.\nUnderstanding the 95th percentile Time Series BillingInfrastructure often scales up during peak usage or deployment phases, leading to temporary spikes in time series data usage. At Sysdig, we bill based on the 95th percentile of time series usage, meaning the top 5% of the highest usage hours are excluded from billing.\nFor example, in a 30-day month (720 hours), you won’t be charged for your 36 highest usage hours. This allows you to temporarily exceed your time series limit without being penalized for short-term spikes.\nLet\u0026rsquo;s say you have an entitlement of 40,000 time series. Between Hour 100 and Hour 125, your usage exceeds this entitlement by 10,000. Since the 25 hours of overage fall within the 36-hour grace period, you will not be charged for the overage.\nHour Time Series Utilization 1 35000 2 35000 \u0026hellip; 35000 99 35000 100 50000 \u0026hellip; 50000 125 50000 126 35000 \u0026hellip; 35000 720 35000 Monitor Time Series UsageView Your SubscriptionTo view your custom time series consumption:\nLog in to Sysdig Secure or Sysdig Monitor as an Admin.\nOpen the User Menu and select Settings \u0026gt; Subscription.\nThe following details can be seen:\nSubscription Details: Under Reserved, you can see the number of reserved agents and the number of time series included with the agents.\nHost Agents - Current Usage: The number of agents currently deployed. In Monitor, you can select Agent Dashboard to view individual time series consumption by agent, metrics type, and so on.\nTime Series - Previous Hour: The total number of time series consumed across all agents in the previous hour. You will see the total custom series entitlement and time series usage against your entitled amount, along with any time series overage beyond your entitlement.\nIn Monitor, you can click Usage Dashboard to view details on the total time series consumption for your account. You can also use the menu to download a Comma-separated values (CSV) file of your hourly usage. See Download Usage. Time Series Usage DashboardSysdig Monitor provides a New Time Series Usage Dashboard with insight into your time series usage data. You can view time series ingestion at a glance to discover and analyze trends. To help you identify the usage trends that are important to you, Sysdig additionally provides the following metrics:\nsysdig_ts_usage: The metric reports the number of time series ingested in a 20-minute interval. This metric can be segmented into metric categories as well. sysdig_ts_usage_10s: The metric reports the number of time series ingested in every 10-second window, per host (agent), and per metric category. Download UsageYou can download the hourly usage report as a CSV file. On the top right of the Subscription page, select Download Usage.\nCalculate Time Series UsageTime series usage is calculated by using the sysdig_ts_usage metric. The metric reports the number of time series ingested in an hour (sum of the maximum of three 20 minutes). For each hour, the number of time series ingested is calculated, and then the value is deducted from the number of reserved time series. This value is stored as the usage record.\nSysdig uses the 95th percentile to calculate the exceeding cost of usage. At the end of the month, the 95th percentile of the total number of active series ingested per hour is calculated. Calculating the 95th percentile reduces the chances of billing you for unexpected spikes caused by time series churns.\nChurn RateWhen a time series stops receiving new data points, it becomes inactive. This event is called time series churn. It occurs more often during an upgrade in a Kubernetes cluster or when containers are replaced by new ones. Restarts, redeploys, and dynamic workloads also cause churn and generate additional time series. For example, in cases where the container_id label in a container metric changes, all the existing time series are subsequently replaced by new time series (with the new container_id value).\nThe churn rate is the number of time series that churn over time. Sysdig uses the sysdig_ts_usage_10s metric to analyze these scenarios.\nThe New Time Series Usage Dashboard provides a ratio of time series detected at 1-hour period and 10-second period. This ratio is known as the churn percentage and it is expressed as this PromQL query:\n(sum (sysdig_ts_usage{metric_category!=\u0026#39;PROMETHEUS_REMOTE_WRITE\u0026#39;}) - sum (sysdig_ts_usage_10s)) / sum (sysdig_ts_usage{metric_category!=\u0026#39;PROMETHEUS_REMOTE_WRITE\u0026#39;}) * 100 Time series collected by Prometheus Remote Write are excluded from this ratio because they are not collected by the Sysdig agent.\nScenariosOn-Demand Time Series ConsumptionLet\u0026rsquo;s say you have a Sysdig Monitor account that primarily consumes metrics from downstream Prometheus servers via Prometheus Remote Write. As such, you have only licensed the account for one Sysdig Agent, which entitles your account to 2,000 time series.\nAssuming the following volume examples:\nTwo Prometheus Servers sending metrics to Sysdig via Remote Write Prometheus Server 1 generates a 50,000 time series consistently every hour during a month Prometheus Server 2 generates a 150,000 time series consistently every hour during a month One Sysdig agent which collects 1000 time series consistently every hour during a month The time series billing for the month is calculated as follows:\nTime series usage is the same for every hour: Total custom time series consumed - Subscription entitlement = (50,000 + 150,000 + 1,000) - 2,000 = 199,000 On-demand time series pricing is measured in blocks of 1000 time series per month. To determine the amount of on-demand time series you will be billed for, divide the total time series usage from the above calculation and divide by 1000:\nThe number of on-demand units consumed = (199,000 / 1000) = 199 Assuming an on-demand time series price of $7.5 for one unit of 1000 time series, the total monthly cost for this use case is $7.5 * 199 = $1592.50 per month.\nMetric Packs Time Series ConsumptionExtending the above example, you can see how purchasing individual time series packs will extend your time series entitlement.\nAssume:\nTwo Prometheus Servers: Prometheus Server 1 generates 50,000 time series Prometheus Server 2 generates 150,000 time series One Sysdig agent that collects 1000 time series 100 pre-purchased time series packs, which is equivalent to 100,000 time series The billing for the month is calculated as follows:\nTotal subscription capacity: (Total time series consumption - (time series entitlement from time series pack + subscription entitlement)) = (50,000 + 150,000 + 1,000) - (100,000 + 2,000) = 99,000 Pre-purchased time series packs also entitle you to 1000 time series per month per pack.\nAssuming the pre-purchase price for time series packs is $5 ($2.50 less per 1000 time series than the on-demand usage price), and you\u0026rsquo;ve purchased 100 packs, that brings your pre-purchase time series entitlement cost to $500 per month.\nTo calculate your overall monthly cost, you would determine the total time series entitlement subtracted from the total time series consumed, then include the amount already paid for in pre-paid time series packs. Any resulting time series overage beyond the included entitlement plus the pre-purchased time series pack entitlement would be billed at the on-demand rate (stipulated in your contract) for each 1000 time series block.\nTotal number of time series consumed = (50,000 + 150,000 + 1,000) = 201,000\nTotal time series entitlement: (100,000 + 2,000) = 102,000\nTime series overage: (201,000 - 102,000) = 99,000\nOn-demand time series cost: (99,000 / 1,000) * 7.50 = $742.50\n(you would be purchasing 99 1000-packs of on-demand time series as the overage above what is already covered by your entitlement)\nTotal monthly time series cost = Cost of pre-purchased time series packs + cost of total overage: ($500 + $742.50) =$1,242.50\n","url":"https://docs.sysdig.com/en/administration/timeseries_billing/"},{"id":291,"title":"Troubleshoot Oracle Cloud Agentless Installs","content":"Troubleshoot OnboardingTerraform: Ensure you have set up your Terraform environment to use valid Oracle Cloud Infrastructure (OCI) Credentials.\nBy default, the Terraform snippets provided by Sysdig will configure Terraform to use the DEFAULT OCI profile from your local OCI config (~/.oci/config). Ensure that this configuration is correct, and you have a valid API key. This can be verified using the OCI CLI, inserting your Tenancy OCID e.g.\noci iam tenancy get --tenancy-id TENANCY_OCID\nFor more details, see the Oracle Documentation\nAdmit Policies: Ensure the root Compartment of your Tenancy contains an IAM Policy named AdmitSysdigSecureTenantOnboarding-XXXX. This policy should allow access to read Tenancy and Compartment details\nTroubleshoot CSPMAdmit Policies: Ensure the root Compartment of your Tenancy contains an IAM Policy with the following names:\nAdmitSysdigSecureTenantOnboarding-XXXX AdmitSysdigSecureTenantConfigPosture-XXXX Troubleshoot TerraformWhen Terraform fails to destroy an organization deployment when CSPM enabled, it\u0026rsquo;s likely due to dependencies on active security configurations.\nSolutionTo resolve this, first manually offboard OCI. If the problem still persists, run the following terraform destroy command:\nterraform state rm module.config-posture.oci_identity_user_group_membership.cspm_user_to_group terraform destroy -target module.onboarding.sysdig_secure_organization.oracle_organization Check Terraform Provider and Module VersionEnsure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; OCI. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/oracle//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;2.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/oracle//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;2.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } ","url":"https://docs.sysdig.com/en/sysdig-secure/oci-troubleshoot/"},{"id":292,"title":"Troubleshoot Windows Agent","content":"EnvironmentsHostsSysdig Windows Agent lifecycle is managed by the Host Shield supervisor service.\nThe Host Shield supervisor automatically restarts the Agent process in light of unhealthy conditions. If the Agent process restarts frequently, a possible cause could be a runtime crash. In order to troubleshoot such crashes, Microsoft Windows supports generating process memory dumps. The steps to enable program specific crash dumps can be found in Collecting User-Mode Dumps.\nWindows registry configuration for collecting agent crash dumpsFollowing configuration enables dumps for Sysdig Windows Agent with type Full dump. The dump file count is limited to 10.\nCommand LinePlease ensure the following commands are run as local administrator.\nreg.exe add \u0026#34;HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\sysdig-agent.exe\u0026#34; /v DumpFolder /t REG_SZ /d \u0026#34;%PROGRAMFILES%\\Sysdig\\Shield\\Dumps\u0026#34; /f reg.exe add \u0026#34;HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\sysdig-agent.exe\u0026#34; /v DumpType /t REG_DWORD /d 2 /f reg.exe add \u0026#34;HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\sysdig-agent.exe\u0026#34; /v DumpCount /t REG_DWORD /d 10 /f Graphical UI Launch Windows Registry Editor regedit.exe as administrator.\nNavigate to the following registry key HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps.\nRight click LocalDumps and select New \u0026gt; Key and rename the new key to sysdig-agent.exe.\nRight click sysdig-agent.exe key and select New \u0026gt; String Value and rename the new string value to DumpFolder.\nDouble click the DumpFolder value and set the value to %PROGRAMFILES%\\Sysdig\\Shield\\Dumps.\nRight click sysdig-agent.exe key and select New \u0026gt; DWORD (32-bit) Value and rename the new DWORD value to DumpType.\nDouble click the DumpType value and set the value to 2.\nRight click sysdig-agent.exe key and select New \u0026gt; DWORD (32-bit) Value and rename the new DWORD value to DumpCount.\nDouble click the DumpCount value and set the value to 10.\nPlease repeat the above process for secmgr.exe.\nDump FilesThe generated dump file names are in the format of {sysdig-agent}.exe.{pid}.dmp.\n","url":"https://docs.sysdig.com/en/sysdig-secure/windows-agent-troubleshooting/"},{"id":293,"title":"Understand Cloud Accounts UI","content":"Access Cloud Accounts UI Log in to Sysdig Monitor as an Admin.\nIn the left-hand sidebar, select Integration \u0026gt; Cloud Accounts.\nThe Cloud Accounts page is displayed.\nView Account DetailsOn the Cloud Accounts page, you can view the following details:\nPlatform: The list of supported Cloud Accounts.\nAccount ID: The account ID associated with you Cloud Account.\nType: Type indicates the method you have used to configure the account connection.\nAWS: The supported types are Role Delegation and Key/Secret. GCP: The supported type is Key/Secret. Azure: The supported type is Key/Secret. Cost Data: The statuses associated with the Costs information. Currently only applicable to AWS.\nMetrics: Shows the metrics collection status. For more information, see Connection Status.\nAmazon CloudWatchView Operational DetailsFor a given account, you can view enabled services and namespaces, as well as a list of dashboards that you can launch to view health and operational details.\nOn the Cloud Accounts page, click the desired AWS account.\nThe slider appear on screen listing the namespaces and associated dashboards.\nClick a desired dashboard to open the dashboard page to view the performance and health of the service.\nDisable CloudWatch Metric StreamsTo stop ingesting AWS CloudWatch Metric Streams into Sysdig, you have to stop the stream on the AWS Console by disabling Sysdig as a Amazon Data Firehose HTTP endpoint. If you do not disable Metric Streams from pushing metrics into Sysdig via the Amazon Data Firehose HTTP endpoint, you will continue to ingest and store the metrics within Sysdig, which in turn will increase your time series consumption cost.\nCloudFormationIf metric streaming was set up using the Sysdig\u0026rsquo;s or your own CloudFormation template, delete the stack that you have created during the setup.\nAWS ConsoleDelete the following:\nCloudWatch Metric Streams connected to Sysdig. The Amazon Data Firehose delivery stream that forwards metrics to Sysdig. The backup S3 bucket linked to the Firehose. The IAM roles associated with the stream and all the resources that were created while setting up the stream. For information on disabling AWS CloudWatch Streams, see Using Metric Streams.\nMicrosoft AzureView Operational DetailsFor a given account, you can view enabled services and namespaces, as well as a list of dashboards that you can launch to view health and operational details.\nOn the Cloud Accounts page, click the desired Azure account. The slider appear on screen listing the namespaces and associated dashboards.\nClick a desired dashboard to open the dashboard page to view the performance and health of the service.\nYou can access the following out-of-the-box Azure Dashboards and Alerts:\nAzure Virtual Machines Azure Active Directory Azure AKSAzure Blob Storage Azure API Management See Connect an Azure Account for more information.\nDisable Microsoft AzureTo disable an Azure account:\nNavigate to Integrations \u0026gt; Cloud Accounts, and locate the Azure account you want to disable. Click the three-dots, and click Disable Metrics. You can enable the an disable metrics using the same menu option. Wait for up to 5 minutes for the metrics to be displayed on the UI.\nGoogle Cloud PlatformView Operational DetailsYou can access the following out-of-the-box GCP Dashboards and Alerts:\nGCP Cloud MySQL GCP Cloud PostgreSQL GCP Cloud SQL Server GCP Compute Engine GCP Memorystore for Redis Add a Cloud AccountTo add a Cloud Account:\nLog in to Sysdig Monitor and select Integrations \u0026gt; Cloud Accounts.\nSelect Add Account.\nSelect from AWS, Azure, and GCP and follow the wizard instructions.\nDelete a Cloud AccountTo delete an Cloud account:\nNavigate to Integrations \u0026gt; Cloud Accounts, and locate the account you want to delete. Click the three-dots, and click Delete Account. Connection StatusThe statuses associated to metric stream creation in a region are:\nConfiguring: The CloudFormation stack is being created at the moment. Configured: The account credentials are correct but no data has been loaded. This status is applicable only to the API integration type. Reporting metrics: Stack is created, metric stream is in running state, and no files are found with data in S3 backup storage. It appears either everything is working as expected, or at least one resource is loaded for the API integration type. Needs attention: Something went wrong. Either metric stream is stopped, or it cannot send data to endpoint, or somebody deleted metric stream from the stack. Error: An error occurred while checking the metric stream status. The statuses for account linkage are given below. They are related to the background jobs that are actually connect to the AWS and either grab metrics in case of API integrations or check stream status in case of stream integration.\nConfigured: The very first status set right after cloud integration is created and background jobs are executed. Loading: Background refresh job was scheduled Done: Background loading job successfully finished for the cloud integration Error: An error occurred during background refresh job execution. ","url":"https://docs.sysdig.com/en/sysdig-monitor/understand-cloud-accounts-ui/"},{"id":294,"title":"Use Cases","content":" Basic Advanced Section Panel Name Tooltip User Story Overview Critical \u0026amp; High Severity Findings Critical \u0026amp; High Severity Findings is the total number of urgent Identity hygiene issues. Use this to assess the overall scope of severe identity risks. As a Program Owner, I want to quickly understand the total number of severe hygiene issues so I can assess the overall risk and prioritize immediate remediation efforts. Overview Critical \u0026amp; High Severity Findings (Last 30 Days) Shows the trend of severe identity hygiene issues over time. Use this to track changes and evaluate remediation efforts. As a Program Owner, I want to track the trend of severe identity hygiene issues over time, broken down by identity type, so I can measure the effectiveness of my hygiene improvement efforts, identify emerging problems, and prioritize resources for the most critical areas. Overview Top Critical \u0026amp; High Severity Findings Shows the most common urgent identity hygiene issues. Use this to identify and prioritize the most critical misconfiguration. As a Program Owner, I want to view the most critical identity hygiene findings, so I can address high-risk misconfiguration without delay. Identity Hygiene Key Management Findings Summarizes issues related to access key misconfiguration. Use this to mitigate risks from exposed or improperly managed access keys. As a Program Owner, I want to monitor identities with access key misconfiguration (for example, \u0026ldquo;Access Key Not Rotated\u0026rdquo; or \u0026ldquo;Multiple Active Keys\u0026rdquo;), so I can reduce risks of key misuse. Section Panel Name Tooltip User Story Overview Average Unused Permissions Average percentage of excessive permissions across all identities. Use this to evaluate adherence to least privilege. As a Program Owner, I want to see the average percentage of excessive permissions across my identities so I can gauge the overall effectiveness of my least privilege enforcement efforts. Overview Average Unused Permissions (Last 30 days) Shows the trend of excessive permissions over time. Use this to monitor progress in reducing over-permissioned identities. As a Program Owner, I want to track the trend of excessive permissions over time, broken down by identity type, so I can measure progress, identify potential regressions, and understand which identity types require the most attention. Least Privilege IAM Policies With Most Unused Permissions Lists IAM policies with the highest percentages of excessive permissions. Use this to target policies for least privilege refinement. As a Program Owner, I want to identify IAM Policies with high percentages of unused permissions, so I can refine and enforce least privilege effectively. Least Privilege Groups With Most Unused Permissions Lists IAM groups with the highest percentages of unused permissions. Use this to refine group-level access and reduce excessive permissions. As a Program Owner, I want to identify groups with high percentages of excessive permissions so I can focus on right-sizing group permissions and reducing the risk of widespread privilege escalation. Least Privilege Users With Most Unused Permissions Lists IAM users with the highest percentages of unused permissions. Use this to identify users for access rights cleanup. As a Program Owner, I want to identify individual users with high percentages of excessive permissions so I can investigate potential insider threats or compromised accounts and enforce least privilege principles. Least Privilege Roles With Most Unused Permissions Lists IAM roles with the highest percentages of unused permissions. Use this to refine over-permissioned roles. As a Program Owner, I want to identify Roles with high percentages of unused permissions, so I can refine and enforce least privilege effectively. Least Privilege Service Identities With Most Unused Permissions Lists service identities with the highest percentages of unused permissions. Use this to refine automated account access and enforce least privilege. As a Program Owner, I want to identify Service Identities with high percentages of unused permissions, so I can refine and enforce least privilege effectively. Identity Hygiene Inactive Identities by Resource Family Shows a breakdown of inactive identities by resource family. Use this to identify dormant accounts and improve lifecycle hygiene. As a Program Owner, I want to see the count of inactive identities by Resource Family so I can identify accounts that may be vulnerable to takeover and improve my identity lifecycle management processes. Identity Hygiene Longest Inactive Users Lists users with the longest periods of inactivity. Use this to identify stale accounts and reduce exposure to compromise. As a Program Owner, I want to identify users with the longest periods of inactivity so I can assess the risk of compromised accounts and enforce account lifecycle policies (for example, disable or remove stale accounts). ","url":"https://docs.sysdig.com/en/sysdig-secure/identity-overview/use-cases/"},{"id":295,"title":"User Profile and Password","content":"Access the User Profile Page Log in to Sysdig Monitor or Sysdig Secure. Click the user menu from the bottom left corner of the screen. Select Settings. Select User Profile. Review the settings and perform actions given below. Review User DetailsThe current user\u0026rsquo;s login email address, subscription type, current team, and role on that team are listed in the User Info section.\nCustomize AppearanceCustomize the appearance of Sysdig UI by selecting from the different themes in the drop-down menu.\nChange Administrator SettingsThis option is visible to administrators only.\nIf logged on as Administrator, you can access Admin Privileges on this page which apply globally.\nHide Agent Install: Toggle the slider to hide the Agent Access Key link in the Settings menu from non-admin users.\nChange Your PasswordUse Reset Password to change the password associated with the currently logged-in user.\nRequirements: Minimum 8 characters. Not identical to the last password used.\nRecommendations: Follow the most up-to-date recommendations by NIST with an emphasis on length and uniqueness.\nMulti-Factor AuthenticationMulti-Factor Authentication (MFA) provides an additional layer of validation to the login process, increasing security. You can enable it with an authenticator app, such as Google Authenticator, via a QR code in the UI.\nTo enable Multi-Factor Authentication:\nIn the Multi-Factor Authentication section, toggle Authenticator App MFA on. A modal appears. The modal has a QR code and a key.\nScan the QR code with your authenticator app. Alternatively, you can manually enter the key.\nA verification code appears in your authenticator app.\nEnter the code into the text box in the modal, and click Confirm.\nMulti-factor authentication is now enabled. Next time you log in, you will be prompted to verify with your authenticator app.\nTo disable Multi-Factor Authentication:\nIn the Multi-Factor Authentication section, toggle Authenticator App MFA on. A modal appears. The modal has a QR code and a key.\nScan the QR code with your authenticator app. Alternatively, you can manually enter the key.\nA verification code appears in your authenticator app.\nEnter the code into the text box in the modal, and click Confirm.\nIf you cannot log in, contact your administrator.\nFor more details, see Multi-Factor Authentication.\nEnable Beta Functions from Sysdig LabsToggle the feature settings listed under Sysdig Labs to enable and disable specific beta functionalities in your installation. Data that has already been stored will not be affected by toggles.\nIf there are no beta features, Sysdig Labs will not be displayed.\nLearn More Navigate the Settings Panel Agent Installation: Overview and Key ","url":"https://docs.sysdig.com/en/administration/user_profile_pwd/"},{"id":296,"title":"(Legacy) Collect Prometheus Metrics","content":"From a metric collection standpoint, a lightweight Prometheus server is directly embedded into the Sysdig agent to facilitate metric collection. This also supports targets, instances, and jobs with filtering and relabeling using Prometheus syntax. You can configure the agent to identify these processes that expose Prometheus metric endpoints on its own host and send it to the Sysdig collector for storing and further processing.\nThis document uses metric and time series interchangeably. The description of configuration parameters refers to “metric”, but in strict Prometheus terms, those imply time series. That is, applying a limit of 100 metrics implies applying a limit on time series, where all the time series data might not have the same metric name.\nThe Prometheus product itself does not necessarily have to be installed for Prometheus metrics collection.\nSee the Sysdig agent versions and compatibility with Prometheus features:\nLatest versions of agent (v12.0.0 and above): The following features are enabled by default:\nAutomatically scraping any Kubernetes pods with the following annotation set: prometheus.io/scrape=true Automatically scrape applications supported by Monitoring Integrations. Sysdig agent prior to v12.0.0: Manually enable Prometheus in dragent.yaml file:\nprometheus: enabled: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycollect-prometheus-metrics/"},{"id":297,"title":"(Legacy) Set up the Environment","content":"Quick Start For Kubernetes EnvironmentsPrometheus users who are already leveraging Kubernetes Service Discovery (specifically the approach in this sample prometheus-kubernetes.yml) may already have Annotations attached to the Pods that mark them as eligible for scraping. Such environments can quickly begin scraping the same metrics using the Sysdig Agent in a couple of easy steps.\nEnable the Prometheus metrics feature in the Sysdig Agent. Assuming you are deploying using DaemonSets, the needed config can be added to the Agent\u0026rsquo;s dragent.yaml by including the following in your DaemonSet YAML (placing it in the env section for the sysdig-agent container):\n- name: ADDITIONAL_CONF value: \u0026#34;prometheus:\\n enabled: true\u0026#34; Ensure the Kubernetes Pods that contain your Prometheus exporters have been deployed with the following Annotations to enable scraping (substituting the listening exporter-TCP-port) : spec: template: metadata: annotations: prometheus.io/scrape: \u0026#34;true\u0026#34; prometheus.io/port: \u0026#34;exporter-TCP-port\u0026#34; The configuration above assumes your exporters use the typical endpoint called /metrics. If an exporter is using a different endpoint, this can also be specified by adding the following additional optional Annotation, substituting the exporter-endpoint-name:\nprometheus.io/path: \u0026#34;/exporter-endpoint-name\u0026#34; If you try this Kubernetes Deployment of a simple exporter, you will quickly see auto-discovered Prometheus metrics being displayed in Sysdig Monitor. You can use this working example as a basis to similarly Annotate your own exporters.\nIf you have Prometheus exporters not deployed in annotated Kubernetes Pods that you would like to scrape, the following sections describe the full set of options to configure the Agent to find and scrape your metrics.\nQuick Start for Container EnvironmentsIn order for Prometheus scraping to work in a Docker-based container environment, set the following labels to the application containers, substituting \u0026lt;exporter-port\u0026gt; and \u0026lt;exporter-path\u0026gt; with the correct port and path where metrics are exported by your application:\nio.prometheus.scrape=true\nio.prometheus.port=\u0026lt;exporter-port\u0026gt;\nio.prometheus.path=\u0026lt;exporter-path\u0026gt;\nFor example, if mysqld-exporter is to be scraped, spin up the container as follows:\ndocker -d -l io.prometheus.scrape=true -l io.prometheus.port=9104 -l io.prometheus.path=/metrics mysqld-exporter ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycollect-prometheus-metrics/setting-up-the-environment/"},{"id":298,"title":"On-Prem Release Notes 2019","content":"Release 3.0.0, December 19, 2019Upgrade ProcessSysdig Platform has been tested and qualified against the following:\nSupported Upgrade From 2.4.1, 2.5.0 Platform Version Vanilla Kubernetes 1.13.4, 1.15.3 and 1.16.0 OpenShift 3.11, 4.1 and 4.2 GKE v1.14.6-gke.13 EKS v1.14-eks.7 Rancher v2.3.3 IBM Unqualified PKS Unqualified Agent Version sysdig/agent 0.93.1 Components Replicated Kubernetes with Statefulsets Redis 4.0.12.7 4.0.12.7 MySQL 5.6.44.0 8.0.16.2 ElasticSearch 5.6.16.15 5.6.16.15 Cassandra 2.1.21.16 2.1.21.16 RDS n/a 8.0.16 Postgres (image scanning) n/a 10.6.11 Anchore (image scanning) n/a 0.5.1. NATS Exporter n/a 0.6.0.1 NATS Streaming n/a 0.16.2.1 Related Documents Installation\nReplicated\nObsolete\nKubernetes\nInstaller-based:\nInstaller (Kubernetes | OpenShift) 2.5.0-3.2.2\nManual:\nManual Install 3.0.0+ (Kubernetes)\nSysdig SecureActivity Audit (Beta)The Activity Audit in Sysdig Secure allows you to browse a live stream of activity from your Kubernetes containers and nodes. Audit takes the highly detailed data from syscalls and Kubernetes audit logs captured at the agent level, and makes it always-on, searchable, and indexed against your cloud-native assets.\nThis stream includes executed commands, network activity, and kubectl exec requests to the Kubernetes API. The Activity Audit allows users to view different data sources in-depth for monitoring, troubleshooting, diagnostics, or to meet regulatory controls (SOC2, NIST, PCI, etc).\nFlexible filtering and scoping to help you focus on what\u0026rsquo;s relevant: Filters allow you to search, sort, and surface meaningful data and connections as they are needed. You can filter by data source type, data source attributes (like command name or Kubernetes user) and dynamic Kubernetes scope\nAutomatically trace a kubectl exec session : The built-in trace functionality allows you to isolate and trace akubectl exec access to a pod, automatically correlating the original Kubernetes user and IP that accessed the pod with the activity that was performed during the interactive session, including commands and network connections.\nActivity Audit is a Preview Beta feature. Contact your customer success manager to learn more about rolling out this feature.\nKubernetes Policy Advisor (Beta)With the Kubernetes Policy Advisor, Sysdig Secure auto-generates Pod Security Policies (PSPs) to significantly decrease the time spent configuring Kubernetes Policies. Strict security policies reduce risk, but can also break applications. Sysdig tests the impact of pod security policies through simulations, enabling teams to adjust misconfigurations before shifting to production. There are three main features that comprise the Kubernetes Policy Advisor:\nAuto generation: Sysdig Secure can parse any Kubernetes yaml file that includes a pod spec to generate a tailor-made PSP based on the configuration.\nSimulations: Start a simulation of the auto-generated PSP or any user-inputted PSP to see what pods would have been blocked from running if this PSP had been actively applied to the cluster.\nEvents and tuning: Each pod/activity that would have violated the PSP will generate an event. Within the event details, users can see information about potential modifications they may need to make to the policy or the pod configuration.\nScanning ImprovementsNew Scanning Rules\nFile attributes can now be verified as part of the image scan analysis. A specific file can be validated against a node or sha256 hash.\nScale Improvements to Scanning Reporting\nNo query conditions are required as part of the Package and Policy Queries.\nGoogle Distro-less OS\nSupport for images based on Google distro-less OS, including detection of base OS/version and installed OS dpkg packages.\nSysdig MonitorOverview Is GAOverview is now generally available. Overview leverages Sysdig\u0026rsquo;s unified Kubernetes data platform to monitor, secure, and troubleshoot your Kubernetes clusters and workloads.\nPlease contact your Sysdig Technical Account Manager or email support to enable Overview for on-premises environments.\nCluster Overview Major highlights of Overview GA include but are not limited to:\nMulti-cloud view of the health, risk, and capacity of your Kubernetes infrastructure— a single pane of glass for Kubernetes Clusters, Nodes, Namespaces, and Workloads across a multi- and hybrid-cloud environment. You can easily filter by any of these entities and view associated events and health data. View the infrastructure organized by Clusters, Nodes, Workloads\nShows metrics prioritized by event count and severity, allowing you to get to the root cause of the problem faster.\nDrill down to Dashboards for instant insights.\nTo learn about the capabilities of the Overview feature, see Overview.\nEnhanced Out-of-the-box DashboardsIn an attempt to improve the Dashboards experience, the following changes have been introduced:\nThe following Dashboards are added:\nKubernetes Cluster Overview: Provides nodes and workloads availability and highlights the high-level health of your Clusters. It also summarizes resources consumption (CPU, memory) across Nodes and Namespaces to pinpoint possible anomalies and node disk utilization\nKubernetes Node Overview: Provides availability of the Nodes, indicating potential issues reported by Kubernetes; a summary of resource (CPU and Memory) allocation and utilization, as well as Network and Disk utilization.\nKubernetes Namespace Overview: Provides a high-level summary of availability, and resource allocation and utilization across all the Workloads in the selected Namespace.\nKubernetes Deployment Overview: Provides a detailed summary of pod status, pod restarts, as well as resource allocation and utilization across pods for each Workload.\nKubernetes StatefulSet Overview: Provides a detailed summary of pod status, pod restarts, as well as resource allocation and utilization across pods for each StatefulSet.\nKubernetes DaemonSet Overview: Provides a detailed summary of pod status, pod restarts, as well as resource allocation and utilization across pods.\nKubernetes Job Overview: Provides a detailed summary of job status, completion trend, pod restarts, as well as resource allocation and utilization across pods.\nKubernetes ReplicaSet Overview: Provides a detailed summary of pod status, pod restarts, as well as resource allocation and utilization across pods for each ReplicaSet.\nKubernetes Pod Overview: Provides a detailed summary of pod status, pod restarts, and resource allocation and utilization in a selected pod.\nKubernetes Workloads CPU Usage and Allocation: Helps you verify that CPU requests are properly configured and actual utilization is expected.\nKubernetes Workloads Memory Usage and Allocation: Helps you verify that memory requests are properly configured and actual utilization is expected.\nKubernetes CPU Allocation Optimization: Helps you verify that infrastructure resources are available for future needs and are not wasted.\nKubernetes Memory Allocation Optimization: Helps you verify that infrastructure resources are available for future needs and are not wasted.\nThe following Dashboards are retained:\nHealth Overview (applicable to all the objects in the environment)\nHorizontal Pod Autoscaler (the default Dashboard when selecting an HPA)\nResource Quota\nService Health (the default dashboard when selecting a service)\nCluster and Node Capacity\nThe following Dashboards are removed:\nState Overview\nDaemonset State\nNamespace State\nStateful State\nNodes State\nDeployment State\nDeployment Health\nNodes Health\nNamespace Health\nPod State\nPod Health\nReplica Set Health\nFor more information, see Pre-Defined Dashboards\nFiltering Events by ScopeEvents are now filtered by Scope to show the most relevant Events in Explore and Dashboards. This is an extension of the existing Event Scope functionality. You can toggle between showing Event feed from the entire infrastructure and only from the particular scope you are interested in within the infrastructure. Event scoping for Dashboards and Explore is enabled by default.\nBy default, Events are filtered to show only the relevant ones. However, you can turn the filtering off and see Events from the complete scope. To do so:\nClick the Dashboard Settings (three dots) icon and select Events.\nUse the toggle button to turn off Filter events by dashboard Scope.\nClick Save.\nSimilarly, you can filter Events by Scope in Explore.\nWhat\u0026rsquo;s n/a?The Sysdig Monitor UI displays n/a in several scenarios associated with labeling. The Explore UI has now been enhanced to add a tooltip for n/a to help you understand the scenario. See The Meaning of n/a for more information.\nRelease 2.5.0, October 29, 2019Upgrade ProcessKubernetes and OpenShift environments upgrade to 2.5.0 using the new installer tool (see below).\nSupported Upgrade Path: 2.3.0, 2.4.1\nSysdig PlatformNew Installer Tool for Kubernetes/OpenShift EnvironmentsWith this release, Sysdig platforms can be installed and upgraded using a semi-automated installer tool that greatly simplifies the installation process. Available for Kubernetes and OpenShift environments.\nSeeInstaller (Kubernetes | OpenShift) 2.5.0-3.2.2.\nEnhancement: New Documentation Site at docs.sysdig.comSysdig\u0026rsquo;s documentation platform has been upgraded and moved to docs.sysdig.com.\nImprovements include:\nLook and feel: Updated to match the rest of the Sysdig branding\nSearch: Enhanced search speed, accuracy, and ease\nStructure and content: Enhancements to content have been added and are being continuously updated\nFeedback: Buttons on each page enable users to communicate directly with the documentation team.\nSysdig CLIThe Sysdig CLI provides an easy way to interact with the cli via the command line. Read more here.\nUsage:\nRun it without parameters to get a list of all the commands.\n$ sdc-cli Usage: sdc-cli [OPTIONS] COMMAND [ARGS]... You can provide the monitor/secure tokens by the SDC_MONITOR_TOKEN and SDC_SECURE_TOKEN environment variables. Options: -c, --config TEXT Uses the provided file as a config file. If the config file is not provided, it will be searched at ~/.config/sdc-cli/config.yml and /etc/sdc-cli/config.yml. -e, --env TEXT Uses a preconfigured environment in the config file. If it\u0026#39;s not provided, it will use the \u0026#39;main\u0026#39; environment or retrieve it from the env var SDC_ENV. --json Output raw API JSON --version Show the version and exit. --help Show this message and exit. Commands: alert Sysdig Monitor alert operations backup Backup operations capture Sysdig capture operations command Sysdig Secure commands audit operations compliance Sysdig Secure compliance operations dashboard Sysdig Monitor dashboard operations event Sysdig Monitor events operations policy Sysdig Secure policy operations scanning Scanning operations settings Settings operations profile Profile operations Sysdig MonitorAbility to \u0026ldquo;Favorite\u0026rdquo; a DashboardUsers can click the star icon to mark a \u0026ldquo;Favorite\u0026rdquo; dashboard, which will then be listed under \u0026ldquo;My Favorites\u0026rdquo; in the Dashboard view.\nSysdig SecureIn-Line ScanningImages can now be analyzed locally before they are pushed to a registry. This has a few key benefits to users.\nImages can be analyzed before they\u0026rsquo;re pushed to a registry and reduce registry cost\nCustomers using the Sysdig Secure SaaS offering don\u0026rsquo;t need to expose their registry to our SaaS for images to be scanned\nFor OpenShift users, the in-lince scan option can be integrated into the S2I process to scan images without needing to expose a local cluster registry via a route\nLearn more and access the script here: https://github.com/sysdiglabs/secure-inline-scan\nSSO Configuration Pages Available in SecureA UI for configuring Single Sign-On for Sysdig Secure is now available from the Settings menu. See Authentication and Authorization (On-Prem Options).\nNew Package ReportsPackage name/version are now grouped together to provide easy parsing of all CVE\u0026rsquo;s associated with a package and the images using that package.\nNew Trigger Parameters for CVSS ScoreImage Vulnerabilities can now be evaluated against their CVSS (Common Vulnerabilities Scoring System) score. If a vulnerability is =, \u0026lt;;\u0026gt;, \u0026lt;=, or\u0026gt;= to a specific score, then the rule can trigger a warn/stop action.\nTime Ranges UpdatedThe default time range options have been updated in Sysdig Secure.\nThe default time ranges are now set to:\n10 Minutes\n30 Minutes\n1 HR\n6 HRs\n1 Day\n3 Days\nTo look at a custom window of time, use the manual time window.\nSysdig Secure Summary Dashboard in Sysdig MonitorSysdig Monitor includes default dashboards that provide metrics about number of agents installed, active policies, events that have occurred, and the policies that have triggered them. Use these dashboards to identify trends, report on coverage, or facilitate the tuning process.\nRelease 2.4.1, September 18, 2019Supported upgrade path: 2.3.0\nSysdig PlatformSecure Authentication for Cassandra and Elasticsearch on ReplicatedCassandra and Elasticsearch datastores now have an extra layer of security on Replicated. Sysdig Replicated install allows you to enable authentication and secure communication between Sysdig backend components and the Elasticsearch or Cassandra datastores.\n[BETA] Audit LoggingThe following APIs have been introduced to support administrators to view a log of user activities and modifications to the components in the system:\nAppAttributes\nAuditEvents\nAudit logs stand for chronologically cataloged events to provide a history of operational actions and to mitigate challenges. The ability to trace an event back to its origin provides proof of compliance, operational integrity, and protection from unsolicited use. For more information, see [BETA] Auditing Sysdig Platform Activities.\nKnown IssuesIf you want to use Audit logging and have MySQL in your Kubernetes HA environment, run kubectl -n sysdigcloud delete pod -l role=worker to ensure Audit logging works as expected. This issue is observed only in Kubernetes HA environments.\nSysdig MonitorNew Default Kubernetes GroupingGroupings for Kubernetes have been modified. This updated Grouping is available to new teams. Default groupings are immutable–-they cannot be modified or deleted other than by copying. Modifying a copy is allowed.\nNew Groupings:\nClusters and Nodes (cluster.name \u0026gt; node.name \u0026gt; pod.name \u0026gt; container.name)\nDeployments (cluster.name \u0026gt; namespace.name \u0026gt; deployment.name \u0026gt; pod.name \u0026gt; container.name)\nServices ( cluster.name \u0026gt; namespace.name \u0026gt; service.name \u0026gt; pod.name \u0026gt; container.name)\nStatefulsets (cluster.name \u0026gt; namespace.name \u0026gt; statefulset.name \u0026gt; pod.name \u0026gt; container.name)\nDaemonsets (cluster.name \u0026gt; namespace.name \u0026gt; daemonset.name \u0026gt; pod.name \u0026gt; container.name)\nReplicaSets (cluster.name \u0026gt; namespace.name \u0026gt; deployment.name \u0026gt; replicaset.name \u0026gt; pod.name)\nHPAs (cluster.name \u0026gt; namespace.name \u0026gt; hpa.name \u0026gt; pod.name \u0026gt; container.name)\nFor more information, see Using Labels.\nUnits for MetricsThe format of metric units are the same for the following:\nThe CPU and Memory metrics for Host and Container.\nKube-state CPU and Memory metrics.\nIntroducing the same format now makes the comparison of those metrics easier on a chart.\nContainer SegmentationSysdig now supports segmenting all net.* metrics at container or pod level by low level net.* dimensions, such as net.http.url or net.http.status.code. Container-based teams now display segmentations for net.http.* metrics as expected. The net.http.url and net.http.status.codes are displayed if you select a container-based team as it does for a host-based team for the same cluster.\nEnhanced Event NotificationThe ability to customize the subject and body of alert notifications with variables has been extended to Event notifications. Event titles and notification messages are in sync in the following cases:\nEvent feed on the Events page\nEvent overlay on Dashboards page\nFor more information, see Events.\nDefault Dashboard for Cluster and Node CapacityKubernetes Cluster and Node Capacity Dashboard has been refreshed to add actual usage of CPU and Memory compared to Requests, Limits and Allocatable capacity.\nAggregation for Kubernetes Nodes HealthAggregation method has been refreshed for Kubernetes Node metrics. The Kubernetes Node Health dashboard has been updated with metric aggregations that are \u0026lsquo;summed\u0026rsquo; across all containers running on the node to reflect accurate node level data.\nBug Fixes Export CSV/JSON was missing columns, not all data was exported as expected. All columns from the dashboard should exist in the exported output.\nAll data and columns are is now exported as expected.\nSysdig SecurePolicy Editor*Please upgrade to an agent version 0.92.0 or greater\nThis UX overhaul brings three major improvements for every Sysdig Secure user:\nRuntime policies can import any number of security rules. You can scope the security policy using container, cloud and Kubernetes metadata.\nTighter Falco integration, directly from the web UI. You will be able to define a new trigger condition or append to the list of forbidden external IPs just clicking on the rule.\nA more structured way to group, classify and lookup rules, following the standard Cloud native procedure: tags and labels.\nRules LibraryVisualize your runtime rules properties in just a glance:\nWhere this rule comes from (Published By). The security team can instantly recognize whether a rule came from a specific Sysdig update, from a custom rules file created within the organization or from an external rules source (like the Falco community rules).\nWhen was the last time it was updated (Last Updated). You can use this information to audit your rules or if you schedule periodic updates, to confirm when last happened.\nRule tags: An effective method for organizing your rules. You can use these tags to describe the targeted entity (host, k8s, process), the compliance standard it belongs to (MITRE, PCI, CIS Kubernetes) or any other criteria you want to use to annotate your rules.\nFalco ListsEasily browse, append, and re-use lists to create new rules. Lists can also be updated directly via API if users want to add existing feeds of malicious domains, or IPs.\nFalco MacrosEasily browse, append, and re-use macros to create new rules.\nImage Scanning ReportsPlease contact Sysdig Support to enable this feature\nThe reports feature allows users to query the contents of a scan against a static or run-time scope to generate a report that shows the risk, exposure, or components of an image.\nUse cases could include:\nA new CVE has been announced, let me find all the running images in my US East Cluster that are exposed to that CVE\nShow me all images within my Google Container registry that have the tag prod and have a vulnerability with a fix that\u0026rsquo;s more than 30 days old\nShow me all images with a high severity vulnerability with a fix that are running in my billing namespace\nImage Scanning - View Scan ResultsScan Results Page - The existing repositories page has been renamed \u0026ldquo;Scan Results\u0026rdquo; this page also includes new capabilities to filter based on where the images are deployed, and to easily browse/expand the different repositories to see the image:tag\u0026rsquo;s that were evaluated and their results\nWhitelist labels available in vulnerabilities view - If a vulnerability has been added to a whitelist then that status is reflected in the Vulnerability report within the scan results.\nEvent ForwardingSysdig Secure can forward policy events to tools like Splunk or events can be forwarded via syslog as an easy way to send policy events to any downstream SIEM.\nRelease 2.3.0, July 29, 2019Supported upgrade paths: 1929, 2435.\nImportant Note for Kubernetes UpgradesDue to the new Secure Elasticsearch and Cassandra feature, Kubernetes installations must follow an expanded upgrade process.\nThis version of Sysdig On-Premises requires Elasticsearch to be at 5.6.x, which is done automatically when you follow the Expanded Upgrade process.\nIf you are running your own instance of ES, you will need to update it to 5.6.x.\nSysdig PlatformOption to Secure Elasticsearch and Cassandra (Kubernetes only)It is now possible to secure Elasticsearch and the Cassandra DB with password authentication and/or SSL/TLS protection.\nSysdig MonitorEnhanced Dashboard MenuThe Dashboard menu features a drawer-style popover that displays on-demand to provide maximum real estate for your Dashboards. The menu displays an alphabetical list of Dashboards you own and those shared by your team. With the popover menu, you can add new Dashboards and search for existing ones. Click a Dashboard name to access the relevant Dashboard page where you can continue with the regular Dashboard settings.\nCustomize Alert Notification TemplateSysdig Monitor alerts now provide an option to customize the messages that are sent with alert notifications in email and other channels, such as Pagerduty and Webhook.\nUse the Alert Editor to input dynamic variables, such as hostname, or a hyperlink, and to add custom messages in plain text to the notifications for intended recipients. You can modify both the subject and the body of the alert notification with a hyperlink or a variable. For example, you can add an agent id or a link to a Dashboard to the message. This can help provide context for troubleshooting the errors that triggered the alert.\nFor more information, see Customizing Alert Notification.\nPrometheus Remote ScrapingSysdig Monitor can now collect Prometheus metrics from remote endpoints with minimal configuration.\nRemote endpoints (remote hosts) refer to hosts where the Sysdig agent cannot be deployed, e.g., a Kubernetes master node on managed Kubernetes services such as GKE and EKS, where user workload cannot be deployed. To enable remote scraping on such hosts, simply identify an agent to perform the scraping and declare the endpoint configurations in the agent configuration file.\nThe collected Prometheus metrics are reported under and associated with the agent that performed the scraping, rather than with a process. See Collecting Prometheus Metrics from Remote Hosts for details.\nEnhancements to Kafka App CheckKafka integrations can now support authentication and SSL/TLS. If the authentication or SSL/TLS are enabled in Kafka, see Apache Kafka Example 5 for how to enable configuration details on the Sysdig side.\nTwo New Metrics for Accurate Pod CountsTwo new Kubernetes metrics, kubernetes.namespace.pod.desired.count and kubernetes.namespace.pod.available.count, have been added at the Namespace level to track desired and available pod counts.\nSysdig SecureImage Scanning: New Trigger Options New Image Analyzed - Send notifications to different channels when images with a particular registry, repo, tag are scanned.\nSome users implement these type of alerts for implementing workflows for image promotion, i.e.\n\u0026quot;Push an image from staging to prod registry after a webhook is sent that the image was scanned and it passed.\u0026quot; CVE Update - Be notified whenever a vulnerability is added, updated, or removed from an image within a registry.\nRepository AlertsReceive alerts about activity and changes that occur within your registry. See Manage Scanning Alerts.\nSlack NotificationsSample output of a CVE alert:\nSample output of an image-analyzed alert:\nImage Scanning: Policies - New rule parameter availableA new field: Max days since creation is now available. This allows users to only take Stop or Warn actions if a vulnerability has been in the feed for a certain number of days.\nFor example: Only stop a build if an image has a high-severity CVE with a fix, and the CVE is more than 30 days old.\nImage Scanning: Policy Assignments - New compliance audits availablePolicy assignments now support the ability to add audit policies to provide a second step of validation of container images. Additional audit policies evaluate images against Dockerfile Best Practices, PCI, and NIST 800-190. These Audit policies have \u0026ldquo;Warn\u0026rdquo; actions set by default and are intended to validate compliance/audit use cases and not cause CI/CD builds to fail.\nUpdated Menu Navigation in Sysdig SecureThe top-menu navigation has been replaced by a context-sensitive drawer-style side navigation bar.\nImage Scanning: Scan Results RedesignScan results have been expanded to help users get a better idea about the policy evaluation status and vulnerabilities present in an image. This new version of scan results allows the user to\nGet a breakdown of the different OS/Non-OS Critical, High, Medium, Low CVEs present in the image\nSee the different policies the image has been evaluated against\nSee which specific rules have triggered the most stop/warn actions and identify areas needing attention\nA breakdown of the evaluation result has been added to give users a better idea about what has triggered warn/stop actions as part of the evaluation.\nIn this case, we can look at the Dockerfile Best Practice policy to see the image\nHas an effective user of root\nDoesn\u0026rsquo;t include a Healthcheck\nUses apt-get upgrade as part of a Run instruction\nIncludes an ADD instruction\nThe Vulnerabilities section also now supports enhanced sorting and filtering by severity level and whether or not a fix is available.\nImage Scanning: PDF ReportsPDF reports, which include a summary of the policy evaluation and all vulnerabilities present in the image, can be downloaded from the console.\nBug Fixes Explore display fix\nFixed an issue where, when the Explore Table had no columns configured, the Explore view showed an error.\nEnable/disable alerts fix\nFixed a problem where users were unable to toggle alerts.\nEvent posting fix\nFixed an issue where events posted in Slack did not appear in the event stream. Now they do.\nMonitor Spotlight fix\nFixed issue where Monitor Spotlight incorrectly alerted to update on-premises releases all the time. Update alert now turns on only when an update is actually available.\nImproved access to kube-state metrics\nTeams based on \u0026lsquo;hosts\u0026rsquo; (e.g., scoped by agent.tag.* ) will now have access to all host and container data, including kube-state metrics and dashboards. In previous versions, kube-state metrics were not available for host-based teams.\nRelease 2435, July 24, 2019 Release 2435 replaces version 2172, 2266 and 2304 which were released on May 28, 2019, June 17, 2019 and June 21, 2019. If you installed 2172, 2266 or 2304, upgrade to 2435.\nSupported upgrade paths: 1765, 1929.\n(Note that if you installed 2172, 2266 or 2304, please upgrade to 2435. Otherwise, skip 2172, 2266 and 2304.)\nImportant Note Regarding Dashboard Migration V1 \u0026gt; V2If you are upgrading from a previous version, the Dashboards will be upgraded from V1 to V2. The process requires 20-30 minutes on large systems, and the environment remains live throughout the rolling upgrade.\nDO NOT create or delete dashboards during the upgrade. After upgrading, if you have saved v1 dashboards previously and need to upload them to the v2 environment, see Migrate Saved Dashboards from V1 to V2.\nSysdig Platform FixCustom certificates fixFixed an install issue caused when using custom certificates.\nRelease 2304, June 21, 2019 Release 2304 replaces version 2172 and 2266 which were released on May 28, 2019 and June 17, 2019. If you installed 2172 or 2266, upgrade to 2304.\nSupported upgrade paths: 1765, 1929.\n(Note that if you installed 2172 or 2266, please upgrade to 2304. Otherwise, skip 2172 and 2266.)\nImportant Note Regarding Dashboard Migration V1 \u0026gt; V2If you are upgrading from a previous version, the Dashboards will be upgraded from V1 to V2. The process requires 20-30 minutes on large systems, and the environment remains live throughout the rolling upgrade.\nDO NOT create or delete dashboards during the upgrade. After upgrading, if you have saved v1 dashboards previously and need to upload them to the v2 environment, see Migrate Saved Dashboards from V1 to V2.\nArchitecture Change in the ContainersIn previous releases, there was a single backend container which ran several processes.\nAs of version 2266, the processes have been divided into unique containers, following container best practices.\nPrevious:\nquay.io/sysdig/sysdigcloud-backend:\u0026lt;earlier release\u0026gt; New:\nquay.io/sysdig/sysdigcloud-backend:2266-allinone-java\nquay.io/sysdig/sysdigcloud-backend:2266-nginx\nquay.io/sysdig/sysdigcloud-backend:2266-email-renderer\nSysdig Platform FixRedis Client FixUpdated an underlying tool (Jedis 2.9.1) to Jedis 2.9.3, to address a bug in the connection pool.\nSysdig MonitorManage Notification Frequency for AlertsUsers now have the ability to specify how often they want to be reminded about an alert if the event is unresolved. Available under \u0026lsquo;Notify\u0026rsquo; section of the alert configuration screen. See Alerts.\nAdvanced Scope SelectionThe scope editor (for dashboards, alerts, teams, etc.) has added improved granularity, intelligent scope restriction, and the ability to add custom values on-the-fly. The editor now restricts the scope of the selection for subsequent filters by rendering values that are specific to the selected label. The values that are only relevant to the previous selection are displayed.\nAbility to Choose Unit of MetricSysdig Monitor now automatically detects the type of input and scale for custom metrics. Earlier, custom metrics were marked as numbers on both Explore and Dashboard UI. The UI now supports custom unit scale for custom metrics. The supported units are byte, percent, and time. This enhancement simplifies the mapping of units of measurement with that of integrated application metrics, such as Prometheus.\nKubernetes Horizontal Pod Autoscaling (HPA) metricsSupport for the following HPA metrics has been introduced: kubernetes.hpa.replicas.min, kubernetes.hpa.replicas.max, k ubernetes.hpa.replicas.current, and k ubernetes.hpa.replicas.desired. For more information, see Resource Usage.\nExpose Dashboard Scope in URLThe Dashboard URL can include scope parameters, including scope variables. Users can now share the URL with non-Sysdig Monitor users and allow them to collaborate on dashboard scope. Collaborators with a valid link can change the scope parameters without having to sign in. They can edit either on the UI or in the URL.\nSysdig SecureImage Scanning: Policy AssignmentsPolicy assignments allow you to specify where your image scanning policies are applied. A policy assignment can include a Registry, Repository, Tag combination and has full wildcard support for each of those fields.\nPolicy assignments are evaluated in descending order, so be sure to specify the most important policies first.\nExamples\nTo evaluate all images with a \u0026ldquo;Prod\u0026rdquo; tag with your Example Prod Image Policy, use the assignment: */*/Prod\nTo evaluate all images from gcr.io with an Example Google Policy, use the assignment: gcr.io/*/*\nSee Manage Scanning Policies.\nImage Scanning: Map Internal Registries (for OpenShift environments)The recommended way to run an image registry for an OpenShift cluster is to run it locally. The Sysdig agent will detect the internal registry names, but for the Anchore engine to pull and scan the image it needs access to the internal registry itself. There can now set this path in the Registries UI. See Manage Registry Credentials.\nCompliance: Custom Report FiltersWhen running CIS benchmark tests, you can filter your view of the results to show only high-priority items or selected controls.\nBug Fixes Improved metric aggregation defaults in Explore window\nWhen a metric is first selected on the Explore page, the time and group aggregation will be pre-populated with the most reasonable choice, rather than average/average.\nTopology view fixes: Implemented fixes for proper loading of Topology panels in public dashboards, and proper \u0026ldquo;group by\u0026rdquo; and \u0026lsquo;scope\u0026quot; Topology Views.\nSee Visualizing Metrics using Topology View.\nNon-root user security enhancements\nAdded changes to permit running Sysdig applications as non-root user.\nImage scanning fix in Sysdig Secure\nBug fix in the Jenkins plugin used to scan images in Sysdig Secure.\nRelease 1929, April 12, 2019 This release supports upgrades from\n1149, 1245, 1402 (1511), 1586 (1630), 1765 New FeaturesSysdig PlatformCRI-O SupportSysdig on Kubernetes now provides support for CRI-O, an implementation of the Kubernetes Container Runtime Interface (CRI).\nSee Sysdig documentation.\nCRI-O container runtimes can be identified by the symbol beside the entry in the Explore table:\nCustomize Data Retention Times using Sysdig REST APIThe Sysdig platform has predefined data retention settings determined by license plan. Using the Sysdig REST API, it is possible to configure separate retention times (up to plan limit).\nSee Customize Data Retention for details.\nSysdig SecureGlobal WhitelistsSysdig Secure allows users to manage CVEs and images that may impact builds by defining them as globally trusted or blacklisted. See Manage Vulnerability Exceptions and Global Lists for more information.\nKubernetes Audit LoggingSysdig Secure allows users to create Falco security rules based on a stream of Kubernetes audit events, integrating Kubernetes audit logging with the Sysdig Agent. This allows users to track changes made to the cluster, and send alerts where necessary. See Kubernetes Audit Logging for more information.\nEnhancementsManual PagerDuty Notification Channel SetupSysdig has expanded the PagerDuty notification channel configuration process to allow users that have a team role of Manager, but a user role of Team Responder or lower, to manually configure the channel settings in order to add new channels. See PagerDuty Notifications for more details.\nAgent Installation ChangesThe default agent installation instructions in the UI have been updated to ensure all agents use SSL. If SSL is not required, the following JVM parameter will need to be set in the backend:\n-Ddraios.agents.installParams.sslEnabled=false See Integrate JMX Metrics from Java Virtual Machines.\nBug FixesAnchore issue that caused scanning to hang when adding a registryAn issue occurred where scanning stopped functioning when adding a new image scanning registry to an environment. This was caused by a bug found in the Anchore open-source engine. This on-premises release includes the approved workaround patch that corrects the issue. The next release of the Anchore open-source engine will include the full fix.\nScanning service degradation due to orphaned servicesAn issue occurred in systems with substantial churn where the event system became overloaded/flooded with orphaned service events, resulting in service and performance degradation. This was caused by the Anchore engine emitting an event each time it found a service that was down/orphaned. This issue has been resolved.\nImages with host/port component weren\u0026rsquo;t flagged with the correct analysisAn issue occurred where images with a host/port component were not flagged correctly, resulting in them showing as unscanned. This was caused by a bug in the scanning backend and has now been resolved.\nScan alert e-mailAn issue occurred in on-premises version 1765, where email alerts for scanning results directed users to an internal Sysdig environment, rather than their own. This has been corrected.\nSome panels in self-monitored dashboards not workingAn issue occurred where some panels in the Self-Monitored default dashboards were not displaying data correctly, because of an error in the default dashboard configuration file. This error has been corrected.\nRelocated \u0026ldquo;Control Plane\u0026rdquo; from Default Dashboard in ExploreKubernetes Control Plane Health dashboard has relocated to the Dashboards module. This dashboard allows users to monitor the health of Kubernetes master components (kube-apiserver, etcd, kube-scheduler, kube-controller-manager). The Kubernetes Control Plane health dashboard has been removed from the list of default dashboards available under Resource Usage.\nElasticSearch on Replicated Restarts into Split BrainWhen a customer restarted their Replicated environment, ElasticSearch sometimes came up in a split-brain scenario (generally 2 + 1). This issue has now been addressed.\nInstall code lines for Sysdig Agent corrected\nOn the Agent Installation page of the Sysdig UI, the supplied install strings for Docker and Linux were incorrect and would not work \u0026ldquo;out of the box\u0026rdquo; for a Replicated deployment. This issue has been addressed.\nRelease 1765, March 13, 2019 This release supports upgrades from: 987, 1149, 1245, 1402 (1511), 1586\nUpgrade Process for Sysdig in Kubernetes Environments If you are running Sysdig Secure in OpenShift OR if you are running more than 400 agents, please contact Sysdig Support before upgrading.\nIf you are running Sysdig in Kubernetes, then the upgrade process for this release is comprised of two parts:\nRun the migration script:\nThis accommodates the backend transition to a different library for communicating with the database.\nPerform the Upgrade:\nFor Sysdig Monitor Only: If you have not licensed Sysdig Secure and run only Sysdig Monitor, use the Basic Upgrade instructions.\nFor Sysdig Platform (including Secure): If you have licensed both Sysdig Monitor and Sysdig Secure, you must follow the v1765 Upgrade (Kubernetes) instructions. These steps add the components necessary to run the Scanning feature.\nNew FeaturesSysdig PlatformContainerd SupportThe Sysdig agent will automatically detect containerd metadata, as well as any Docker metadata, in your environment. Note that you must have agent version 0.88.1 or higher. See the agent install instructions for details.\nIf you are upgrading from an earlier version of the agent, note that you must also download the latest sysdig-agent-daemonset-v2.yamlfrom GitHub for containerd functionality.\nSysdig MonitorImproved Notification Channels ConfigurationA newly redesigned notification channels page under settings has been implemented. For more information, see Set Up Notification Channels.\nNew Kubernetes DashboardsAdded two new default Kubernetes dashboards to help users monitor Cluster / Node health and Namespace health. The dashboards are available under the default dashboard list in Explore.\nSysdig SecureImproved Registry Credential UIThe user interface for adding registry credentials has been redesigned to improve user experience and add new configuration functionality. See Registries.\nEvent ForwardingSysdig Secure policy events can now be forwarded to Splunk. See Event Forwarding.\nNew Scanning PoliciesNew scanning policies have been added for compliance use cases and best practices, interpreting NIST 800-190 and PCI controls to detect misconfigured images.\nRemediation InformationRemediation information has been added to assist in solving non-passing test results, in order to bring an environment into compliance.\nIdentify the Kubernetes Master NodeA new label has been added to the Compliance task results page to assist in identifying the Kubernetes master node.\nRun a Compliance Task ManuallyUsers can now choose to run a compliance task immediately, rather than scheduling a task for later.\nJenkins Plugin Available in Jenkins CommunityThe Sysdig Secure Jenkins plugin is now available here: https://wiki.jenkins.io/display/JENKINS/Sysdig+Secure+Jenkins+Plugin\nEnhancementsSysdig MonitorUser Interface ChangesThe Intercom button has been moved from the bottom right corner of the Sysdig Monitor UI to the bottom left to facilitate a better user experience, as the previous location interfered with other UI elements. It can now be found below the Help, Spotlight, and User menus.\nBug FixesThe following issues have been fixed in this release:\nDashboard data display issueAn issue occurred when users in a team scoped by container tried to access a dashboard. While building the read requests, the correct team filters were used, but the write request incorrectly set the domain to host instead of container, resulting in the backend not reading the data correctly. This issue has been resolved.\nAWS data display issueFor some AWS queries, data displayed incorrectly because the backend could not determine the AWS resource type being queried, so the aws.resource.type metadata was added to the request scope.\nAssign User to Team in SecureIn some cases, users could not be added to Sysdig Secure teams, because of a backend issue that occurred when loading the list of available users to add to a team. This has been resolved.\nRelease 1630 Hotfix, January 31, 2019 This release supports upgrades from: 1149. 1245, 1402, 1511, and 1586.\nPerformance IssuesA performance issue was found when creating snapshots for large number of teams and large number of custom metrics. This issue has been fixed.\nRelease 1586, January 21, 2019 This release supports upgrades from: 1149. 1245, 1402, and 1511.\nNew FeaturesSysdig MonitorNew Events FeedA redesigned Events Feed is now available. The new design unifies all of your infrastructure-related events, alerts, and other activity in a single view to help you quickly identify critical issues that need your attention. For more information, refer to the Events documentation.\nNew Topology is now GAThe new topology map functionality in Sysdig Monitor has moved from a labs feature to full general availability. It features a redesigned layout and enhanced interaction model to provide insight into dependencies with drill-down to the container-process level.\nAuthentication UIAdministrators can now configure single sign-on authentication methods (LDAP, SAML, OpenID, Google OAuth) via the Sysdig Monitor UI. For more information, refer to the Authentication and Authorization (On-Prem Options) documentation.\nEnhancementsNew MetricsAn additional metric (kubernetes.pod.restart.rate) has been added to show the number of pod restarts since the last check.\nKubernetes GroupingsIn previous releases, the default Kubernetes groupings used kubernetes.cluster.id. This has been changed to kubernetes.cluster.name to improve user experience.\nJava Virtual Machine (JVM)The JVM flag -UseContainerSupport has been disabled for performance reasons.\nAlert Delay at StartupSysdig alert jobs begin immediately at start-up. However, in instances where Sysdig goes down unexpectedly, or without proper shutdown/startup procedures implemented, data can be missing, triggering alert notifications.\nA start-up delay in alert jobs can be configured in on-premises environments, by setting the draios.alerts.startupDelay parameter during the installation process. The parameter requires a duration value; the example below shows a duration of 10 minutes:\ndraios.alerts.startupDelay=10m This parameter can be configured for either Replicated or Kubernetes environments:\nFor Replicated environments, add the parameter to the Sysdig application JVM options list. For more information, refer to the Install Using the Replicated GUI documentation.\nFor Kubernetes environments, add the parameter to the sysdigcloud.jvm.worker.options parameter in the configmap. For more information, refer to the Sysdig Install with Kubernetes 1.9+ documentation.\nSysdig SecureCompliance (Benchmarks) CIS compliance benchmarks now support customizable schedules, using a selection of intervals, days, and times, for different compliance tasks to execute on.\nUsers can now download individual compliance results as a CSV file.\nThe Compliance scheduling page now displays when the next compliance test will run.\nAn error log is now displayed when a compliance test fails.\nUsers can now search the list of compliance tests by hostname.\nBug FixesMesos.*percent metrics do not currently have \u0026lsquo;%\u0026rsquo; as a selectable unit scaleMesos.*percent metrics did not include percentage as an option for the metric unit scale. This has been corrected in the backend.\nSplit brain in Elasticsearch when launching Kubernetes HA envA bug in the Elasticsearch container configuration created the potential for the nodes to fail to discover all of the members of their cluster at start-up. This resulted in a \u0026ldquo;split-brain\u0026rdquo; in the Elasticsearch cluster, where nodes created multiple separate clusters, instead of a single cohesive cluster.\nThe configuration of the container was re-tooled to allow the Kubernetes cluster to expose the existence of the pods to their peers before they finish starting up, and the cluster pods will now be aware of all of the cluster members at start-up.\nRelease 1511 Hotfix, January 8, 2019Issue: Better Handle Unknown Container RuntimesIn previous releases, snapshot jobs would fail if data for computing aggregations for Kubernetes pods from unsupported container runtimes was present. Containers in unknown runtimes are now skipped when computing these aggregations to circumvent the error.\nThese containers are still present, and the metrics can be seen in non-kubernetes contexts, as well as some Kubernetes contexts. (For Kubernetes contexts, they are listed as null).\nIssue: JVM Settings FixPrior to JVM update 191, the JVM was not container-aware, and used system-level resources for auto-configuration. Update 191 changed this behavior to use container values instead. Sysdig has now updated the default settings in order to use system-level resources for auto-configuration.\nUsers who want to fix the issue, but do not want to upgrade to the new Sysdig hotfix, need to update the JVM settings in either the config.yaml or the Replicated console, by adding the -XX:-UseContainerSupport flag.\n","url":"https://docs.sysdig.com/en/release-notes/sysdig-on-premises-release-notes/2019-archive/"},{"id":299,"title":"Sysdig Agent for Windows Release Notes (2024)","content":"1.3.1 December 19, 2024Supported sysdig-deploy version: 1.72.5\nFeature EnhancementsGenerate dump files when the Agent stopsMinidump files are generated when the Agent stops to enable swift debugging.\nDefect FixesFixed the issue where the container metadata was occasionally not attached to the process. Solidified the mechanism for container process matching to consider additional heuristics when deciding whether the created process pertains to the container.\nFixed the issue where the process token SID was obtained from an invalid memory buffer. Enhanced the Agent’s resilience against invalid memory buffers when retrieving the security identifier from the process token.\nVulnerability Fixes\nCVE-2024-6119 CVE-2024-5535 CVE-2024-2511 CVE-2024-4741 CVE-2024-4603 1.3.0 November 28, 2024Supported sysdig-deploy version: 1.69.0\nFeature EnhancementsPolicy Events Enhanced with AWS and Azure MetadataPolicy events are now enriched with metadata from supported cloud providers, currently AWS and Azure.\nRetain Custom Agent Configuration during UpgradesThe configuration file generated during the installation is retained when the agent is upgraded.\nOptimized Agent ArchitectureEnhanced the Agent process architecture, improving reliability and performance while reducing the resource footprint.\nDefect FixesImproved Process Tree ResiliencyResolved an issue with process tree cycles that could cause agent unresponsiveness.\nInstrumentation Engine Startup FailuresFixed an issue preventing the instrumentation engine from bootstrapping the processing of event sources.\nFixed Proxy Connection IssueResolved proxy connection issue occurring when the Agent does not use the double-SSL connection style.\n1.2.0 October 14, 2024Feature EnhancementsProcess TreeProcess tree is available in policy events. By default, all the policy events are decorated with the process lineage (tree) showing the hierarchy of process ancestors.\nDefect FixesFixed the Misbehavior Observed while Splitting the Empty Command Line ArgumentThe fix circumvents argument splitting for empty command line strings.\n1.1.0 September 20, 2024Feature EnhancementsRed Hat OpenShift SupportThe Windows Agent is now supported on Red Hat OpenShift on SaaS and on-premises.\nDefect FixesMitigated an issue where the Windows Agent becomes unresponsive during shutdown.\n1.0.2 July 25, 2024Defect FixesFixed the issue where enabling the Prometheus feature caused the Agent to crash during bootstrap. The fix now gracefully handles the presence of the incompatible Prometheus feature and discards it during Agent initialization.\n1.0.1 July 5, 2024Feature EnhancementsEnriched Policy Events MetadataPolicy events now include a container identifier in their metadata which is used to enrich events with additional Kubernetes metadata.\nImproved Rule Matching PerformanceImproved the performance of event processing to considerably reduce CPU utilization when evaluating security events against the rule set.\nReduced Event LoadSysdig now prevents events that are irrelevant for threat detection from being processed to reduce CPU utilization.\nKnown IssuesThe Windows Agent cannot start if Prometheus is enabled. To prevent this, disable Prometheus for Windows Agent in the dragent.yaml file:\nprometheus: enabled: false 1.0.0 June 28, 2024Feature EnhancementsKubernetes Deployment SupportThe Windows Agent can now be deployed to Kubernetes clusters by using the sysdig-deploy Helm chart.\nCollect Kubernetes Events Enriched with Kubernetes MetadataThe agent exposes filter fields to collect Kubernetes metadata and automatically enrich every security event with the basic workload information.\nConfigurable Pipes CRI Container EnginesYou can specify the additional CRI container engines named pipes by using the windows.cri_engine_named_pipes configuration property.\nAbility to Collect Exceptions and Stack Traces for Root Cause AnalysisFor unhandled exceptions such as accessing an invalid memory location, the agent now generates the backtrace and dumps it to a file. You can use the stack trace information for root cause triaging.\nDefect FixesSecurity ReviewThe Windows Agent source code underwent a security review and incorporated mitigation steps for any potential issues.\nVulnerability FixesUpdated the OpenSSL library to v3.2.2 in the Windows Agent and addressed the following:\nCVE-2024-4741 CVE-2024-4603 CVE-2024-2511 CVE-2023-5678 CVE-2023-6129 CVE-2023-6237 CVE-2024-0727 0.9.2 May 22, 2024Feature EnhancementsPerformance EnhancementsRedesigned the interprocess communication system to improve overall stability and performance of the Windows Agent.\nDefect FixesRemove Visual C++ 2015-2022 Redistributable Package RequirementThe Visual C++ 2015-2022 Redistributable package prerequisite is no longer required as it is now bundled with the Agent installer.\nEliminate Misleading LogsImproved the timestamp calculation of the metrics messages to eliminate misleading and excessive logs\n0.9.1 April 03, 2024Feature EnhancementsAbility to deploy Windows Agent as Host Process ContainerYou can now deploy the Windows Agent container image as a Host Process Container to allow access to the host instrumentation facilities.\nAbility to Automatically Detect vmcompute and containerd ServicesThe Agent can now detect both vmcompute and containerd processes even after the initial startup. This capability enhances resiliency in scenarios where these services may not be running during agent startup.\nDefect FixesFixed Memory Leak During Querying Object TypesThe catalog of available system object types was being repeatedly repopulated every time a handle was fetched from the process handle table. This resulted in a memory leak as the catalog continued to grow indefinitely. This issue has been fixed in this release.\n0.9.0 March 07, 2024Feature EnhancementsContainer EnrichmentThe agent is now capable of gaining visibility into containerized processes, allowing the containerd-based containers to be secured along with the host operating system.\nAvailability of Docker Image for Windows Server v2019 and v2022The Windows Agent is now available as a Docker image for Windows Server 2019 and Server 2022.\nDefect FixesVulnerability Fixes CVE-2023-45853 CVE-2024-0727 CVE-2023-5678 CVE-2023-6237 Ability to Handle Wide Characters from AmsiScanBuffer EventsAMSI events carry the buffer parameter that contains the executed payload, such as Powershell cmdlet and loaded .NET assembly. This conveys that the parameter structure is dynamic and will greatly depend on the data source emitting the AMSI telemetry. As a consequence, the event parsing mechanism has been adapted to treat the parameters as dynamic, and thus derive the content of the AMSI buffer as dictated by the application type emitting the event.\n0.8.0 December 20, 2023Defect FixesRule Detection ReliabilityImprove the reliability of detection capabilities.\nVulnerability FixesFixed the following vulnerabilities:\nCVE-2020-1971 CVE-2021-23840 CVE-2021-23841 CVE-2021-3449 CVE-2021-3450 CVE-2021-3711 CVE-2021-3712 CVE-2021-4160 CVE-2022-0778 CVE-2022-1292 CVE-2022-2068 CVE-2022-2097 CVE-2022-4304 CVE-2022-4450 CVE-2023-0215 CVE-2023-0286 CVE-2023-0464 CVE-2023-0465 CVE-2023-0466 CVE-2023-2650 CVE-2023-3817 CVE-2023-4807 CVE-2023-5363 New FeaturesUser TelemetryAdd audit telemetry for user-related activities including:\nLogin and logoff Account creation and deletion Enable Control Flow GuardEnable Control Flow Guard for Windows Agent applications.\nEnhanced Detection CapabilitiesImprove event metadata parsing to enable more finely tuned rules.\n0.7.0 October 25, 2023Sysdig Windows Agent Released as Controlled AvailabilitySysdig is pleased to announce the controlled availability of the Windows Agent that delivers enhanced threat detection and visibility into malicious activities on Windows systems in the cloud. It includes a comprehensive set of curated policies and rules designed to detect a wide range of malicious activities, from the execution of known malicious Powershell cmdlets to the addition of users to the Administrators group. Additional rules will continue to be developed during the CA.\nFor more information, see Sysdig Agent for Windows.\n","url":"https://docs.sysdig.com/en/release-notes/windows-agent-release-notes/2024-archive/"},{"id":300,"title":"Host Shield for Windows Release Notes (2025)","content":"0.12.3 December 16, 2025 Supported shield chart version: 1.25.1 Supported Agent version: 2.2.3 Defect Fixes Fixed an issue that prevented the MSI wizard from successfully upgrading previous versions; Fixed an issue that occasionally caused false positive vulnerabilities on Windows systems; Fixed an issue that prevented successful IBM and OCI cloud metadata retrieval; Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-47914 CVE-2025-58181 CVE-2025-61727 CVE-2025-61729 0.12.2 November 25, 2025 Supported shield chart version: 1.23.3 Supported Agent version: 2.2.2 Defect Fixes Fixed an issue in the MSI wizard that incorrectly displayed the EU2 collector hostname. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-9230 CVE-2025-9231 CVE-2025-9232 CVE-2024-25621 CVE-2025-52881 CVE-2025-64329 0.12.1 October 28, 2025 Supported shield chart version: 1.21.3 Supported Agent version: 2.2.1 Defect Fixes Fixed an issue that occasionally caused duplicate packages to appear on Windows systems. 0.12.0 September 29, 2025 Supported shield chart version: 1.21.0 Supported Agent version: 2.2.1 EnhancementsWindows HostProcess Containers Now SupportedSysdig Windows container images are now based on the Windows Host Process Containers base image. From this release forward, only Kubernetes environments with HostProcess Containers (HPC) are supported.\nIf you are already using the Sysdig shield Helm chart, no action is required. It has been configured to run as HostProcess Containers by default.\nEnsure you are running containerd version 1.6.8 or later to avoid compatibility issues.\nVulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-4674 CVE-2025-47907 0.11.0 August 27, 2025 Supported shield chart version: 1.16.0 Supported Agent version: 2.2.1 Defect Fixes Fixed a defect that could affect detection of Windows vulnerabilities. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-4674 CVE-2025-47907 0.10.0 July 29, 2025 Supported shield chart version: 1.14.0 Supported Agent version: 2.2.1 EnhancementsConsistent Region Selection Format in MSI InstallerThe Region dropdown in the MSI installation wizard now uses the same format as the Sysdig SaaS login page. This ensures a consistent experience across the installer and web login, making it easier to select the appropriate region.\nEnhanced Scanner Events Updated Scanner Events to report the Shield version and the feature generating events. Defect Fixes Improved resilience of the network communication layer to socket disconnects. Implemented the purging mechanism to remove stale I/O request packets from the internal queue. Fixed a bug causing the host scanner to skip some Python packages during host scans. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2024-36350 CVE-2024-36357 CVE-2025-47980 CVE-2025-47981 CVE-2025-48822 CVE-2024-21302 CVE-2025-47159 CVE-2025-47971 CVE-2025-47972 CVE-2025-47973 CVE-2025-47975 CVE-2025-47976 CVE-2025-47982 CVE-2025-47984 CVE-2025-47985 CVE-2025-47986 CVE-2025-47987 CVE-2025-47991 CVE-2025-47996 CVE-2025-47998 CVE-2025-47999 CVE-2025-48000 CVE-2025-48001 CVE-2025-48003 CVE-2025-48799 CVE-2025-48800 CVE-2025-48803 CVE-2025-48804 CVE-2025-48805 CVE-2025-48806 CVE-2025-48808 CVE-2025-48811 CVE-2025-48814 CVE-2025-48815 CVE-2025-48816 CVE-2025-48817 CVE-2025-48818 CVE-2025-48819 CVE-2025-48820 CVE-2025-48821 CVE-2025-48823 CVE-2025-48824 CVE-2025-49657 CVE-2025-49658 CVE-2025-49659 CVE-2025-49660 CVE-2025-49661 CVE-2025-49663 CVE-2025-49664 CVE-2025-49665 CVE-2025-49666 CVE-2025-49667 CVE-2025-49668 CVE-2025-49669 CVE-2025-49670 CVE-2025-49671 CVE-2025-49672 CVE-2025-49673 CVE-2025-49674 CVE-2025-49675 CVE-2025-49676 CVE-2025-49678 CVE-2025-49679 CVE-2025-49680 CVE-2025-49681 CVE-2025-49684 CVE-2025-49685 CVE-2025-49686 CVE-2025-49687 CVE-2025-49688 CVE-2025-49689 CVE-2025-49690 CVE-2025-49691 CVE-2025-49716 CVE-2025-49721 CVE-2025-49722 CVE-2025-49723 CVE-2025-49724 CVE-2025-49725 CVE-2025-49726 CVE-2025-49727 CVE-2025-49729 CVE-2025-49730 CVE-2025-49732 CVE-2025-49733 CVE-2025-49740 CVE-2025-49742 CVE-2025-49744 CVE-2025-49753 0.9.0 June 24, 2025 Supported shield chart version: 1.10.0 Enhancements Improved Posture Connectivity Resiliency Changed the default transport protocol for the Posture feature from nats to https to improve resilience against transient network failures and round-trip communication issues.\nVulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-22874 CVE-2025-4673 CVE-2025-0913 0.8.0 May 29, 2025 Supported shield chart version: 1.7.0 Enhancements You can now configure proxy settings from the host-shield.yaml file when deployed on hosts. Streamlined log output by preventing unexpected certificate loading warnings. Defect Fixes Fixed an issue where the Host Scanner could send invalid scan status data to the backend when scanning containers. Fixed an issue where the Host Scanner could display an error when interacting with older versions of the Sysdig on-premises backend. Fixed an issue where the Host Scanner did not detect Flatcar OS installations correctly. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-29824 CVE-2025-29810 CVE-2025-29809 CVE-2025-27742 CVE-2025-27741 CVE-2025-27740 CVE-2025-27739 CVE-2025-27738 CVE-2025-27737 CVE-2025-27736 CVE-2025-27735 CVE-2025-27733 CVE-2025-27732 CVE-2025-27731 CVE-2025-27730 CVE-2025-27727 CVE-2025-27487 CVE-2025-27486 CVE-2025-27485 CVE-2025-27484 CVE-2025-27483 CVE-2025-27481 CVE-2025-27479 CVE-2025-27478 CVE-2025-27477 CVE-2025-27476 CVE-2025-27474 CVE-2025-27473 CVE-2025-27471 CVE-2025-27470 CVE-2025-27469 CVE-2025-27467 CVE-2025-26688 CVE-2025-26687 CVE-2025-26680 CVE-2025-26679 CVE-2025-26678 CVE-2025-26676 CVE-2025-26674 CVE-2025-26673 CVE-2025-26672 CVE-2025-26671 CVE-2025-26669 CVE-2025-26668 CVE-2025-26667 CVE-2025-26666 CVE-2025-26665 CVE-2025-26664 CVE-2025-26652 CVE-2025-26648 CVE-2025-26647 CVE-2025-26644 CVE-2025-26641 CVE-2025-26640 CVE-2025-26637 CVE-2025-26635 CVE-2025-24074 CVE-2025-24073 CVE-2025-24060 CVE-2025-24058 CVE-2025-21222 CVE-2025-21221 CVE-2025-21205 CVE-2025-21204 CVE-2025-21203 CVE-2025-21197 CVE-2025-21191 CVE-2025-21174 CVE-2024-21302 0.7.1 April 15, 2025EnhancementsKubernetes Cluster Name in MetricsMetrics message tags now include the Kubernetes cluster name for better traceability.\nImproved Metrics ResiliencyEnhanced the internal Agent metrics sender infrastructure to increase reliability and fault tolerance.\n0.7.0 March 31, 2025Introducing Host Shield on Windows! Host Shield simplifies the deployment, management, and configuration of Sysdig security tools by consolidating components such as Runtime Threat Detection, Host Scanner and Posture into Host Shield.\nEnhancementsPosture for Windows Server in Standalone HostsSysdig now provides compliance scanning for Windows Server standalone hosts, enabling security and regulatory compliance checks for Windows environments. This feature helps organizations enforce compliance policies and detect security misconfiguration.\nThis feature only supports standalone Windows Server hosts. It does not apply to Windows Server nodes running inside Kubernetes clusters or Containers based on Windows images.\nVulnerability Detection for Windows Server Adding detection for Windows Operating System Vulnerabilities sourced from Microsoft Security Response Center Adding detection for Non-OS Packages Support for Custom CA Certificates from Windows Certificate StoresYou can use a custom CA certificate residing in Windows certificate stores\nFor installation steps, see Windows Hosts and Windows Kubernetes.\nFor more information, see Posture Policies Included.\n","url":"https://docs.sysdig.com/en/release-notes/windows-host-shield-release-notes/archive-2025/"},{"id":301,"title":"Add Browser Files","content":"After generating the files, add them to the Support ticket you created.\nSubmit a Web Browser Log Using HAR FilesUse a HARfile to log a web browser\u0026rsquo;s interaction with Sysdig Monitor or Sysdig Secure.\nWhen debugging issues (particularly for On-Premises installations) you may be asked to provide a HAR file to Sysdig Support to help isolate the root cause of an issue.\nNOTE: HAR files contain sensitive information from your browser session while recording, such as the content of the pages you downloaded, cookies, or other personal details.\nSee below for browser-specific steps to gathering HAR files.\nChromeRecord your session using the Network tab in the Developer Tools in Chrome. Follow the steps 1-6 below to prepare for recording and steps 7-9 to record your problematic operation.\nLogin to Sysdig Monitor and navigate to a page where you are experiencing an issue\nOpen the Developer Tools from the Chrome menu (Menu \u0026gt; More Tools \u0026gt; Developer tools)\nClick on the Network tab\nLook for a round button at the top left of the Network tab. Make sure it is red. If it is grey, click it once to start recording.\nMake sure the box next to \u0026ldquo;Preserve log\u0026rdquo; is unchecked and next to \u0026ldquo;Disable cache\u0026rdquo; is checked\nIn the main browser window, refresh the page in the Sysdig Monitor application\nReproduce your issue in as few steps as possible\nClick the red Record button to stop the recording.\nSave the capture by right-clicking anywhere within the on the grid and choosing \u0026ldquo;Save All as HAR with Content\u0026rdquo;\nClose Developer Tools by pressing the in the upper-right of the console\nFirefoxRecord your HTTP session using the Network option in the Developer Tools in Firefox. Follow the steps 1-4 below to prepare for recording and steps 5-6 to record your problematic operation.\nLogin to Sysdig Monitor and navigate to a page where you are experiencing an issue\nOpen the Developer Tools from the menu in the upper-right of your Firefox window\nClick on Network in the Developer menu\nIn the main browser window, refresh the page in the Sysdig Monitor application\nReproduce your issue in as few steps as possible\nSave the capture by right-clicking anywhere within the on the grid and choosing \u0026ldquo;Save All As HAR\u0026rdquo;\nClose Developer Tools by pressing the in the upper-right of the console\nOther BrowsersChrome and Firefox are the only browsers for which Sysdig currently provides steps for gathering HAR file data. If you have an issue that requires reproducing with a different browser, contact Sysdig Support.\n","url":"https://docs.sysdig.com/en/docs/support/submit-a-support-ticket/add-browser-files/"},{"id":302,"title":"Additional Metrics Available in Troubleshooting","content":"In addition to the extensive set of metrics available in the monitor mode, additional metrics, such as net.sql and net.mongodb, as well as additional segments for file and network metrics are available. For example, suppose we have the sysdig_host_file_open_count metric. This is available in both Monitor mode and Troubleshooting mode. Each mode would provide the following output:\nMode Output Monitor sysdig_host_file_open_count{} 10 Troubleshooting sysdig_host_file_open_count{file=\u0026quot;/tmp/file1.txt\u0026quot;} 4 sysdig_host_file_open_count{file=\u0026quot;/tmp/file2.txt\u0026quot;} 6 Available MetricsMetrics available in Troubleshooting Mode include:\nSysdig Legacy ID Prometheus ID Additional Metrics Values Available When Segmented by file.error.total.count sysdig_host_file_error_total_count\nsysdig_container_file_error_total_count\nsysdig_program_file_error_total_count file.name and file.mount labels file.bytes.total sysdig_host_file_total_bytessysdig_container_file_total_bytessysdig_program_file_total_bytes file.bytes.in sysdig_host_file_in_bytessysdig_container_file_in_bytessysdig_program_file_in_bytes file.bytes.out sysdig_host_file_out_bytessysdig_container_file_out_bytessysdig_program_file_out_bytes file.open.count sysdig_host_file_open_count\nsysdig_container_file_open_count\nsysdig_program_file_open_count file.time.total sysdig_host_file_total_timesysdig_container_file_total_timesysdig_program_file_total_time host.count None host.error.count sysdig_host_syscall_error_countsysdig_container_syscall_error_count proc.count sysdig_host_proc_countsysdig_container_proc_countsysdig_program_proc_count proc.start.count None net.mongodb.collection all net.mongodb.error.count sysdig_host_net_mongodb_error_countsysdig_container_net_mongodb_error_count net.mongodb.operation net.mongodb.request.count sysdig_host_net_mongodb_request_countsysdig_container_net_mongodb_request_count net.mongodb.request.time sysdig_host_net_mongodb_request_timesysdig_container_net_mongodb_request_time net.sql.query all net.sql.error.count sysdig_host_net_sql_error_countsysdig_container_net_sql_error_count net.sql.query.type net.sql.request.count sysdig_host_net_sql_request_countsysdig_container_net_sql_request_count net.sql.request.time sysdig_host_net_sql_request_timesysdig_container_net_sql_request_time net.sql.table net.http.error.count sysdig_host_net_http_error_countsysdig_container_net_http_error_count net.http.url net.http.method None net.http.request.count sysdig_host_net_http_request_countsysdig_container_net_http_request_count net.http.request.time sysdig_host_net_http_request_time\nsysdig_container_net_http_request_time net.bytes.in sysdig_host_net_in_bytessysdig_container_net_in_bytessysdig_program_net_in_bytes net.bytes.out sysdig_host_net_out_bytessysdig_container_net_out_bytessysdig_program_net_out_bytes net.request.time.worst.out None net.request.count sysdig_host_net_request_countsysdig_container_net_request_countsysdig_program_net_request_count net.request.time sysdig_host_net_request_timesysdig_container_net_request_timesysdig_program_net_request_time net.bytes.total sysdig_host_net_total_bytessysdig_container_net_total_bytessysdig_program_net_total_bytessysdig_connection_net_total_bytes net.http.request.time.worst all ","url":"https://docs.sysdig.com/en/administration/additional-metrics-troubleshooting/"},{"id":303,"title":"Administration","content":"Administer Sysdig PlatformThis section helps you navigate to the topics of administering the Sysdig user and notification management.\nFeature Documentation Description Super Admin Management Locate the super admin, super user, and login tokens. User and Team Administration Understand Sysdig\u0026rsquo;s users, teams, and role permissions. Notifications Management Add, edit, or delete a variety of notification channel types, and disable or delete notifications when they are not needed. Find Your Customer ID and Name Find customer ID for SaaS deployments. Authentication and Authorization (SaaS) Set up secure access control for SaaS deployments. License ManagementThis section helps you navigate to the topics on license management.\nFeature Documentation Description Subscription Review your account status regarding payment tier and licensed numbers of agents, serverless agents, cloud accounts. Troubleshoot Sysdig PlatformThis section helps you troubleshoot on-premises and agent installation.\nFeature Documentation Description Troubleshoot On-Prem Installations Review general issues and troubleshooting tips for on-prem installations. Troubleshoot On-Prem Installations. Troubleshoot Sysdig Agent Browse troubleshooting tips for Sysdig agents. Contact Sysdig Support Get help from Sysdig Support. On-Premises DeploymentsThis section provides guidelines for deploying a Sysdig Platform on-premises.\nFeature Documentation Description System Architecture Understand the Sysdig Platform components and their relationships to each other and the environment. System Requirements Review the hardware components and software resources required to host the Sysdig Platform. Install Sysdig Platform On-PremisesWhen installing Sysdig Platform on-premises, follow the instructions specific to your environment. Where available, Sysdig recommends using the Installer tool.\nFor release 3.6.0 and higher, this material has moved to version-specific folders in GitHub.\nFor legacy installation instructions, see On-Premises Installation.\nAdministration for Sysdig Platform On-PremisesThis section helps you navigate to the topics on securing the Sysdig Platform components.\nFeature Documentation Description Manage User Profile and Password Access the current user\u0026rsquo;s login credentials, team, and role, and retrieve the API token to use with custom scripts or applications. Authentication and Authorization (On-Prem Options) Set up secure access control for the on-prem deployments. Access the Admin PanelAdministrators can perform user and team management, set up authentication and authorization, add notification channels, manage subscriptions, and enable secure storage. You can access the Admin panel from both Sysdig Monitor and Sysdig Secure UIs. The options available will depend on your access privileges. Administrators have the rights to manage Users, Teams, and Licenses. Non-administrative users will not see these settings.\nLog in to Sysdig Monitor or Sysdig Secure.\nHover over the User menu in the lower-left corner of the navigation bar.\nAccess the Admin panel using one of the following:\nQuick links in the User menu, organized into their usage groups.\n​ The Admin gear symbol in the top right corner of the user menu, which takes you to the Admin panel.\n","url":"https://docs.sysdig.com/en/docs/administration/"},{"id":304,"title":"Agent","content":"sysdig_agent_info Prometheus ID sysdig_agent_info Legacy ID info Metric Type gauge Unit number Description The metrics will always have the value of 1. Additional Notes sysdig_agent_timeseries_count_appcheck Prometheus ID sysdig_agent_timeseries_count_appcheck Legacy ID metricCount.appCheck Metric Type gauge Unit number Description The total number of time series received from appcheck integrations. Additional Notes sysdig_agent_timeseries_count_jmx Prometheus ID sysdig_agent_timeseries_count_jmx Legacy ID metricCount.jmx Metric Type gauge Unit number Description The total number of time series received from JMX integrations. Additional Notes sysdig_agent_timeseries_count_prometheus Prometheus ID sysdig_agent_timeseries_count_prometheus Legacy ID metricCount.prometheus Metric Type gauge Unit number Description The total number of time series received from Prometheus integrations. Additional Notes sysdig_agent_timeseries_count_statsd Prometheus ID sysdig_agent_timeseries_count_statsd Legacy ID metricCount.statsd Metric Type gauge Unit number Description The total number of time series received from StatsD integrations. Additional Notes scrape_samples_scraped Prometheus ID scrape_samples_scraped Legacy ID Metric Type gauge Unit number Description PromScrape/Agent related metric. The number of samples/timeseries the target exposed which were scrapped, usually associated to a job/integration. Additional Notes scrape_duration_seconds Prometheus ID scrape_duration_seconds Legacy ID Metric Type gauge Unit number Description PromScrape/Agent related metric. Duration of the scrape in seconds, usually associated to a job/integration. Additional Notes scrape_samples_post_metric_relabeling Prometheus ID scrape_samples_post_metric_relabeling Legacy ID Metric Type gauge Unit number Description PromScrape/Agent related metric. The number of samples remaining after metric relabeling was applied. PromScraping supports relabeling, which can be used for manipulating per-metric labels, filtering scrape targets and samples. Additional Notes scrape_series_added Prometheus ID scrape_series_added Legacy ID Metric Type gauge Unit number Description PromScrape/Agent related metric. The approximate number of new series in this scrape. Additional Notes up Prometheus ID up Legacy ID Metric Type gauge Unit number Description In the context of PromScrape, the up metric is particularly useful for monitoring and alerting on the health of a scrape job. It is set to 0 in case anything goes wrong with the scrape target, either because it is not reachable, because the connection times out while scraping, or because the samples from the target could not be processed. When the target is behaving normally, the up metric is set to 1. Additional Notes ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/agent/"},{"id":305,"title":"Agent","content":"Note: Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. However, this page still shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\ndragent.analyzerdragent is the main process in the agent that collects and collates data from multiple sources, including syscall events from the kernel in order to generate metrics. The analyzer module that runs in the dragent process does much of the work involved in generating metrics. These internal metrics are used to troubleshoot the health of the analyzer component.\nSysdig Monitor provides the following analyzer metrics:\nMetrics Type Minimum Agent Version Description dragent.analyzer.processes gauge 0.80.0 or above The number of processes found by the analyzer. dragent.analyzer.threads The number of threads found by the analyzer. dragent.analyzer.threads.dropped counter The number of threads not reported due to thread limits. dragent.analyzer.containers gauge The number of containers found by the analyzer. dragent.analyzer.javaprocs The number of java processes found by the analyzer. dragent.analyzer.appchecks The number of application checks reporting to the analyzer. dragent.analyzer.mesos.autodetect If the agent is configured to autodetect a Mesos environment, value is 1, otherwise is 0. dragent.analyzer.mesos.detected If the agent actually found a Mesos environment, value is 1, otherwise, value is 0 dragent.analyzer.fp.pct100 The analyzer flush CPU % (0-100) dragent.analyzer.fl.ms The analyzer flush duration (milliseconds) dragent.analyzer.sr The current sampling ratio (1=all events, 2= half of events analyzed, 4=one fourth of events analyzed, and so on. dragent.analyzer.n_evts The number of events processed dragent.analyzer.n_drops The number of events dropped dragent.analyzer.n_drops_buffer The number of events dropped due to the buffer being full. dragent.analyzer.n_preemptions The number of driver preemptions. dragent.analyzer.n_command_lines The number of command lines collected and sent to the collector. dragent.analyzer.command_line_cats.n_none dragent.analyzer.n_container_healthcheck_command_lines 0.80.1 or above The number of command lines identified as container health checks. This metric does not change even if healthcheck command lines are not sent to the collector. ","url":"https://docs.sysdig.com/en/sysdig-monitor/sysdig-legacy-format/agent/"},{"id":306,"title":"Agent Configuration for Secure","content":"Configure Malware ControlMalware Control, which is comprised of Malware Detection and Prevention, is enabled by default for containers. Malware Detection is enabled by default for hosts, but Malware Prevention is disabled by default for hosts.\nYou can configure the agent to:\nEnable or disable Malware Control for both hosts and containers. Enable or disable Malware Prevention for hosts. To configure the agent, see Understand the Agent Configuration.\nPrerequisites Sysdig Agent v13.0.1 and above Linux kernel v5.0 and above Enable or Disable Malware ControlTo enable Malware Control for hosts and containers, use this configuration:\nagent: sysdig: settings: malware_control: enabled: true Alternatively, use the following Helm command:\n--set agent.sysdig.settings.malware_control.enabled=true To disable Malware Control for hosts and containers, use this configuration:\nagent: sysdig: settings: malware_control: enabled: false Enable or Disable Malware Prevention for HostsMalware Prevention, by default, is disabled for Hosts. To enable it, use the following configuration:\nprotections: malware_control: enable_prevention_on_host: true To disable Malware Prevention on hosts, use the following configuration:\nprotections: malware_control: enable_prevention_on_host: false Enable or Disable Malware Detection on Opens and WritesMalware Detection is enabled for opens and writes by default with the following configuration:\nprotections: malware_control: enable_elf_object_malware_scanning: true To disable Malware Detection on opens and writes, use the following configuration:\nprotections: malware_control: enable_elf_object_malware_scanning: false Configure Container Limits For kernel versions below v5.13, Malware can monitor up to 128 containers per node.\nFor kernel versions v5.13 or above, modify the container limit using one of the following methods:\nOpen the sysctl -n fs.fanotify.max_user_groups file and set the new value using sysctl -w fs.fanotify.max_user_groups=\u0026lt;new_limit\u0026gt;.\nCheck the current limit using cat /proc/sys/fs/fanotify/max_user_groups file and use echo \u0026lt;new_limit\u0026gt; \u0026gt; /proc/sys/fs/fanotify/max_user_groups to set the new limit.\nConfigure Drift DetectionSysdig Agent v12.16.0+Drift Detection is enabled by default on agent versions 12.16.0+.\nOptional ValuesEnable detections from mounted/persistent volumes.\nConfigurationdrift_deny_execution_from_volumes: true Helm Command--set agent.sysdig.settings.drift_deny_execution_from_volumes=true Sysdig Agent v12.14.0This configuration is deprecated for newer agent versions.\nConfigurationEnable Driftdrift_killer: enabled: true Disable Driftdrift_killer: enabled: false Here is an example configuration:\nagent: ebpf: enabled: \u0026#34;true\u0026#34; kind: \u0026#34;universal_ebpf\u0026#34; sysdig: settings: enrich_with_process_lineage: \u0026#34;true\u0026#34; drift_control: enabled: false Helm Command --set agent.sysdig.settings.drift_killer.enabled=true Configure Container Limits For kernel versions below v5.13, Drift Detection can monitor up to 128 containers per node.\nFor kernel versions v5.13 or above, modify the container limit using one of the following methods:\nOpen the sysctl -n fs.fanotify.max_user_groups file and set the new value using sysctl -w fs.fanotify.max_user_groups=\u0026lt;new_limit\u0026gt;.\nOpen the cat /proc/sys/fs/fanotify/max_user_groups file and run echo \u0026lt;new_limit\u0026gt; \u0026gt; /proc/sys/fs/fanotify/max_user_groups.\nReplace \u0026lt;new_limit\u0026gt; with your choice of container limit.\nConfigure Falco Rule Matching StrategySysdig agent v.12.18+From Sysdig agent v12.18.0+, the agent evaluates an event against all the rules, potentially triggering multiple alerts. In previous versions, the agent stopped evaluating rules after the first match.\nTo control this behavior, a new option has been added to dragent.yaml: security.falco_match_strategy\nsecurity: falco_match_strategy: all To evaluate all rules for every event; set it to all. This is the default option.\nTo stop evaluation after the first match; set it to first.\nReport Actions in Kubernetes EventsSysdig agent v.12.18+For a full description of the feature, see Threat Detection Policies.\nPermissions\nHelm: If you deploy the agent using Helm, the permissions to enable create and patch actions for events on all APIs are automatically granted.\nManual: If you deploy manually, you must set up a Kubernetes cluster role with those permissions enabled. Example without cluster role binding:\napiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: sysdig-agent rules: - apiGroups: - \u0026#34;\u0026#34; resources: - events verbs: - create - patch Example with cluster role binding:\napiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: sysdig-agent rules: - apiGroups: - \u0026#34;\u0026#34; resources: - events verbs: - create - patch --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: sysdig-agent roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: sysdig-agent subjects: - kind: ServiceAccount name: sysdig-agent namespace: sysdig-agent --- Ignore Container Actions at the Agent LevelSysdig agent v12.10+For Threat Detection policies, you can use the agent-level configuration, ignore_container_action to prevent the Sysdig agent from taking potentially disruptive container operations, such as kill, pause, stop, regardless of the runtime threat detection policy.\nThis configuration is disabled by default. To enable it, add the following to the dragent.yaml file:\nsecurity: ignore_container_action: true See Configure the Agent.\nWhen the configuration is enabled, and a policy instructs the agent to perform a container operation, the agent ignores the policy and creates an Info log message explaining the agent did not perform the action because of the configuration.\nSee Linux Workload Policy for an example of the container action at the policy level.\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-secure-agent-configuration/"},{"id":307,"title":"Alert Types","content":"The types of alerts available in Sysdig Monitor:\nThreshold Alerts: Monitor your infrastructure by comparing any metric against user-defined thresholds\nPrometheus Alerts: Monitor your infrastructure with PromQL queries, maintaining full compatibility with OSS Prometheus.\nEvent Alerts: Monitor your infrastructure by tracking specific events, and alert if the total number of occurrences exceeds a user-defined threshold\nGroup Outlier Alerts: Monitor unusual patterns by detecting deviations from expected group behavior.\nPercentage of Change Alerts: Compare the percentage of change of a metric over two specific time frames, such as comparing the last 5 minutes to the previous hour.\nDowntime Alerts: Monitor any type of entity - host, container, process, service, etc - and alert when the entity goes down.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/alert-types/"},{"id":308,"title":"Apache Kafka","content":"The Sysdig agent automatically collects metrics from Kafka via JMX polling. You need to provide consumer names and topics in the agent config file to collect consumer-based Kafka metrics.\nThis page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nKafka SetupKafka will automatically expose all metrics. You do not need to add anything on the Kafka instance.\nZstandard, one of the compressions available in the Kafka integration, is only included in Kafka versions 2.1.0 or newer. See also Apache documentation.\nSysdig Agent ConfigurationReview how to edit dragent.yaml to Integrate or Modify Application Checks.\nMetrics from Kafka via JMX polling are already configured in the agent\u0026rsquo;s default-settings configuration file. Metrics for consumers, however, need to use app-checks to poll the Kafka and Zookeeper API. You need to provide consumer names and topics in dragent.yaml file.\nDefault ConfigurationSince consumer names and topics are environment-specific, a default configuration is not present in dragent.default.yaml.\nRefer to the following examples for adding Kafka checks to dragent.yaml. Remember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1: Basic ConfigurationA basic example with sample consumer and topic names:\napp_checks: - name: kafka check_module: kafka_consumer pattern: comm: java arg: kafka.Kafka conf: kafka_connect_str: \u0026#34;127.0.0.1:9092\u0026#34; # kafka address, usually localhost as we run the check on the same instance zk_connect_str: \u0026#34;localhost:2181\u0026#34; # zookeeper address, may be different than localhost zk_prefix: / consumer_groups: sample-consumer-1: # sample consumer name sample-topic-1: [0, ] # sample topic name and partitions sample-consumer-2: # sample consumer name sample-topic-2: [0, 1, 2, 3] # sample topic name and partitions Example 2: Store Consumer Group Info (Kafka 9+)From Kafka 9 onwards, you can store consumer group config info inside Kafka itself for better performance.\napp_checks: - name: kafka check_module: kafka_consumer pattern: comm: java arg: kafka.Kafka conf: kafka_connect_str: \u0026#34;localhost:9092\u0026#34; zk_connect_str: \u0026#34;localhost:2181\u0026#34; zk_prefix: / kafka_consumer_offsets: true consumer_groups: sample-consumer-1: # sample consumer name sample-topic-1: [0, ] # sample topic name and partitions If kafka_consumer_offsets entry is set to true the app check will look for consumer offsets in Kafka. The appcheck will also look in Kafka if zk_connect_str is not set.\nExample 3: Aggregate Partitions at the Topic LevelTo enable aggregation of partitions at the topic level, use kafka_consumer_topics with aggregate_partitions = true.\nIn this case the app check will aggregate the lag \u0026amp; offset values at the partition level, reducing the number of metrics collected.\nSet aggregate_partitions = false to disable metrics aggregation at the partition level. In this case, the appcheck will show lag and offset values for each partition.\napp_checks: - name: kafka check_module: kafka_consumer pattern: comm: java arg: kafka.Kafka conf: kafka_connect_str: \u0026#34;localhost:9092\u0026#34; zk_connect_str: \u0026#34;localhost:2181\u0026#34; zk_prefix: / kafka_consumer_offsets: true kafka_consumer_topics: aggregate_partitions: true consumer_groups: sample-consumer-1: # sample consumer name sample-topic-1: [0, ] # sample topic name and partitions sample-consumer-2: # sample consumer name sample-topic-2: [0, 1, 2, 3] # sample topic name and partitions Example 4: Custom TagsOptional tags can be applied to every emitted metric, service check, and/or event.\napp_checks: - name: kafka check_module: kafka_consumer pattern: comm: java arg: kafka.Kafka conf: kafka_connect_str: \u0026#34;localhost:9092\u0026#34; zk_connect_str: \u0026#34;localhost:2181\u0026#34; zk_prefix: / consumer_groups: sample-consumer-1: # sample consumer name sample-topic-1: [0, ] # sample topic name and partitions tags: [\u0026#34;key_first_tag:value_1\u0026#34;, \u0026#34;key_second_tag:value_2\u0026#34;, \u0026#34;key_third_tag:value_3\u0026#34;] Example 5: SSL and AuthenticationIf SSL and authentication are enabled on Kafka, use the following configuration.\napp_checks: - name: kafka check_module: kafka_consumer pattern: comm: java arg: kafka.Kafka conf: kafka_consumer_offsets: true kafka_connect_str: \u0026#34;127.0.0.1:9093\u0026#34; zk_connect_str: \u0026#34;localhost:2181\u0026#34; zk_prefix: / consumer_groups: test-group: test: [0, ] test-4: [0, 1, 2, 3] security_protocol: SASL_SSL sasl_mechanism: PLAIN sasl_plain_username: \u0026lt;USERNAME\u0026gt; sasl_plain_password: \u0026lt;PASSWORD\u0026gt; ssl_check_hostname: true ssl_cafile: \u0026lt;SSL_CA_FILE_PATH\u0026gt; #ssl_context: \u0026lt;SSL_CONTEXT\u0026gt; #ssl_certfile: \u0026lt;CERT_FILE_PATH\u0026gt; #ssl_keyfile: \u0026lt;KEY_FILE_PATH\u0026gt; #ssl_password: \u0026lt;PASSWORD\u0026gt; #ssl_crlfile: \u0026lt;SSL_FILE_PATH\u0026gt; Configuration Keywords and Descriptions Keyword\nDescription\nDefault Value\nsecurity_protocol (str) Protocol used to communicate with brokers.\nPLAINTEXT\nsasl_mechanism (str) String picking SASL mechanism when security_protocol is SASL_PLAINTEXT or SASL_SSL\nCurrently only PLAIN is supported\nsasl_plain_username (str) Username for SASL PLAIN authentication.\nsasl_plain_password (str) Password for SASL PLAIN authentication.\nssl_context (ssl.SSLContext) Pre-configured SSLContext for wrapping socket connections. If provided, all other ssl_* configurations will be ignored.\nnone\nssl_check_hostname (bool) Flag to configure whether SSL handshake should verify that the certificate matches the broker's hostname.\ntrue\nssl_cafile (str) Optional filename of ca file to use in certificate veriication.\nnone\nssl_certfile (str) Optional filename of file in pem format containing the client certificate, as well as any CA certificates needed to establish the certificate's authenticity.\nnone\nssl_keyfile (str) Optional filename containing the client private key.\nnone\nssl_password (str) Optional password to be used when loading the certificate chain.\nnone\nssl_crlfile (str) Optional filename containing the CRL to check for certificate expiration. By default, no CRL check is done.\nWhen providing a file, only the leaf certificate will be checked against this CRL. The CRL can only be checked with 2.7.9+.\nnone\nExample 6: Regex for Consumer Groups and TopicsAs of Sysdig agent version 0.94, the Kafka app check has added optional regex (regular expression) support for Kafka consumer groups and topics.\nRegex Configuration:\nNo new metrics are added with this feature\nThe new parameter consumer_groups_regex is added, which includes regex for consumers and topics from Kafka. Consumer offsets stored in Zookeeper are not collected.\nRegex for topics is optional. When not provided, all topics under the consumer will be reported.\nThe regex Python syntax is documented here: https://docs.python.org/3.7/library/re.html#regular-expression-syntax\nIf both consumer_groups and consumer_groups_regex are provided at the same time, matched consumer groups from both parameters will be merged\nSample configuration:\napp_checks: - name: kafka check_module: kafka_consumer pattern: comm: java arg: kafka.Kafka conf: kafka_connect_str: \u0026#34;localhost:9092\u0026#34; zk_connect_str: \u0026#34;localhost:2181\u0026#34; zk_prefix: / kafka_consumer_offsets: true # Regex can be provided in following format # consumer_groups_regex: # \u0026#39;REGEX_1_FOR_CONSUMER_GROUPS\u0026#39;: # - \u0026#39;REGEX_1_FOR_TOPIC\u0026#39; # - \u0026#39;REGEX_2_FOR_TOPIC\u0026#39; consumer_groups_regex: \u0026#39;consumer*\u0026#39;: - \u0026#39;topic\u0026#39; - \u0026#39;^topic.*\u0026#39; - \u0026#39;.*topic$\u0026#39; - \u0026#39;^topic.*\u0026#39; - \u0026#39;topic\\d+\u0026#39; - \u0026#39;^topic_\\w+\u0026#39; Example\nRegex\nDescription\nExamples Matched\nExamples NOT Matched\ntopic_\\d+\nAll strings having keyword topic followed by _ and one or more digit characters (equal to [0-9])\nmy-topic_1\ntopic_23\ntopic_5-dev\ntopic_x\nmy-topic-1\ntopic-123\ntopic\nAll strings having topic keyword\ntopic_x\nx_topic123\nxyz\nconsumer*\nAll strings have consumer keyword\nconsumer-1\nsample-consumer\nsample-consumer-2\nxyz\n^topic_\\w+\nAll strings starting with topic followed by _ and any one or more word characters (equal to [a-zA-Z0-9_])\ntopic_12\ntopic_x\ntopic_xyz_123\ntopic-12\nx_topic\ntopic__xyz\n^topic.*\nAll strings starting with topic\ntopic-x\ntopic123\nx-topic\nx_topic123\n.*topic$\nAll strings ending with topic\nx_topic\nsampletopic\ntopic-1\nx_topic123\nMetrics AvailableKafka Consumer Metrics (App Checks)See Apache Kafka Consumer Metrics.\nJMX MetricsSee Apache Kafka JMX Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/apache-kafka/"},{"id":309,"title":"Apache Kafka JMX Metrics","content":"See Application Integrations for more information.\nThe kafka.consumer.* and kafka.producer.* metrics are only available with JMX customization as documented in Integrate JMX Metrics from Java Virtual Machines.\nkafka.consumer.bytes_consumedThe average number of bytes consumed for a specific topic per second.\nkafka.consumer.bytes_inThe rate of bytes coming in to the consumer.\nkafka.consumer.delayed_requestsThe number of delayed consumer requests.\nkafka.consumer.expires_per_secondThe rate of delayed consumer request expiration.\nkafka.consumer.fetch_rateThe minimum rate at which the consumer sends fetch requests to a broker.\nkafka.consumer.fetch_size_avgThe average number of bytes fetched for a specific topic per request.\nkafka.consumer.fetch_size_maxThe maximum number of bytes fetched for a specific topic per request.\nkafka.consumer.kafka_commitsThe rate of offset commits to Kafka.\nkafka.consumer.max_lagThe maximum consumer lag.\nkafka.consumer.messages_inThe rate of consumer message consumption.\nkafka.consumer.records_consumedThe average number of records consumed per second for a specific topic.\nkafka.consumer.records_per_request_avgThe average number of records in each request for a specific topic.\nkafka.consumer.zookeeper_commitsThe rate of offset commits to ZooKeeper.\nkafka.expires_secThe rate of delayed producer request expiration.\nkafka.follower.expires_per_secondThe rate of request expiration on followers.\nkafka.log.flush_rateThe log flush rate.\nkafka.messages_inThe incoming message rate.\nkafka.net.bytes_inThe incoming byte rate.\nkafka.net.bytes_outThe outgoing byte rate.\nkafka.net.bytes_rejectedThe rejected byte rate.\nkafka.producer.available_buffer_bytesThe total amount of buffer memory, including unallocated buffer memory and memory in the free list, that is not being used.\nkafka.producer.batch_size_avgThe average number of bytes sent per partition per-request.\nkafka.producer.batch_size_maxThe maximum number of bytes sent per partition per-request.\nkafka.producer.buffer_bytes_totalThe maximum amount of buffer memory the client can use.\nkafka.producer.bufferpool_wait_timeThe fraction of time an appender waits for space allocation.\nkafka.producer.bytes_outThe rate of bytes going out for the producer.\nkafka.producer.compression_rateThe average compression rate of record batches for a topic.\nkafka.producer.compression_rate_avgThe average compression rate of record batches.\nkafka.producer.delayed_requestsThe number of producer requests delayed.\nkafka.producer.expires_per_secondsThe rate of producer request expiration.\nkafka.producer.io_waitThe producer I/O wait time.\nkafka.producer.message_rateThe producer message rate.\nkafka.producer.metadata_ageThe age of the current producer metadata being used, in seconds.\nkafka.producer.record_error_rateThe average number of retried record sends for a topic per second.\nkafka.producer.record_queue_time_avgThe average time that record batches spent in the record accumulator, in milliseconds.\nkafka.producer.record_queue_time_maxThe maximum amount of time record batches can spend in the record accumulator, in milliseconds.\nkafka.producer.record_retry_rateThe average number of retried record sends for a topic per second.\nkafka.producer.record_send_rateThe average number of records sent per second for a topic.\nkafka.producer.record_size_avgThe average record size.\nkafka.producer.record_size_maxThe maximum record size.\nkafka.producer.records_per_requestThe average number of records sent per second.\nkafka.producer.request_latency_avgThe average request latency of the producer.\nkafka.producer.request_latency_maxThe maximum request latency in milliseconds.\nkafka.producer.request_rateThe number of producer requests per second.\nkafka.producer.requests_in_flightThe current number of in-flight requests awaiting a response\nkafka.producer.response_rateThe number of producer responses per second.\nkafka.producer.throttle_time_avgThe average time in a request was throttled by a broker, in milliseconds.\nkafka.producer.throttle_time_maxThe maximum time in a request was throttled by a broker, in milliseconds.\nkafka.producer.waiting_threadsThe number of user threads blocked waiting for buffer memory to enqueue their records.\nkafka.replication.isr_expandsThe rate of replicas joining the ISR pool.\nkafka.replication.isr_shrinksThe rate of replicas leaving the ISR pool.\nkafka.replication.leader_electionsThe leader election rate.\nkafka.replication.unclean_leader_electionsThe unclean leader election rate.\nkafka.replication.under_replicated_partitionsThe number of unreplicated partitions.\nkafka.request.fetch.failedThe number of client fetch request failures.\nkafka.request.fetch.failed_per_secondThe rate of client fetch request failures per second.\nkafka.request.fetch.time.99percentileThe time for fetch requests for the 99th percentile.\nkafka.request.fetch.time.avgThe average time per fetch request.\nkafka.request.handler.avg.idle.pctThe average fraction of time the request handler threads are idle.\nkafka.request.metadata.time.99percentileThe time for metadata requests for 99th percentile.\nkafka.request.metadata.time.avgThe average time for a metadata request.\nkafka.request.offsets.time.99percentileThe time for offset requests for the 99th percentile.\nkafka.request.offsets.time.avgThe average time for an offset request.\nkafka.request.produce.failedThe number of failed produce requests.\nkafka.request.produce.failed_per_secondThe rate of failed produce requests per second.\nkafka.request.produce.time.99percentileThe time for produce requests for the 99th percentile.\nkafka.request.produce.time.avgThe average time for a produce request.\nkafka.request.update_metadata.time.99percentileThe time for update metadata requests for the 99th percentile\nkafka.request.update_metadata.time.avgThe average time for a request to update metadata.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/apache-kafka-jmx-metrics/"},{"id":310,"title":"Automatic Cloud Account Onboarding","content":"Automatic Cloud Account Onboarding simplifies the onboarding of Azure subscriptions by:\nAutomatically detecting and onboarding newly created Azure subscriptions under a connected Azure tenant. Allowing you to enable or disable this behavior via the Sysdig UI. Providing visibility into newly discovered subscriptions and any additional configuration needed. Automatically removing (offboarding) any deleted/disabled subscriptions from a connected Azure tenant. This capability reduces the manual effort of maintaining visibility across a dynamic Azure environment.\nWhen automatic onboarding and offboarding is enabled, newly created Azure subscriptions are automatically detected and onboarded within 24 hours.\nPrerequisites Sysdig Secure account with organization admin rights. A connected Management Group or Subscription hierarchy in Azure. Enable Automatic Onboarding and OffboardingTo enable automatic onboarding and offboarding for Azure:\nLog in to Sysdig Secure.\nNavigate to Integrations \u0026gt; Environments \u0026gt; Azure.\nClick Add Azure Account.\nSelect Tenant.\nUnder Terraform, when preparing for onboarding or offboarding, go to the step Subscriptions to Onboard.\nYou will see Automatic Onboarding \u0026amp; Offboarding enabled by default.\nWhen deploying via Terraform, ensure the variable enable_automatic_onboarding = true is present in your configuration.\nSysdig will periodically poll Azure Resource Graph to detect, and onboard and offboard new subscriptions from the configured Azure Management Group(s) or tenant.\nValidate Automatic OnboardingOnce one Azure subscription is successfully onboarded, you can create new subscriptions in your Azure tenant.\nSysdig will automatically detect and onboard them, assuming they meet the following conditions:\nThe subscription is in active state. The subscription is under a Management Group or tenant that Sysdig has visibility into. To verify onboarding:\nLog in to Sysdig Secure.\nGo to Integrations \u0026gt; Environments \u0026gt; Azure.\nNewly discovered subscriptions will be listed with a status of Connected once onboarded successfully.\nFor example: TroubleshootingAutomatic Onboarding Fails for New Azure SubscriptionsSysdig may detect the subscription but fail to onboard it if:\nThe subscription is not in an active state. Workaround Confirm that the subscription is fully active and visible via Azure Resource Graph. Ensure the connected Management Group includes the new subscription. Confirm that your Secure app has the required permissions at the tenant or management group level. ConsiderationsFoundational, CSPM, Basic CIEM \u0026amp; Workload scanningThese features operate at the Management Group level and inherit cloud resources accordingly. When new Azure subscriptions are created under an onboarded management group, they are automatically included, and no further action is required.\nAdvanced CIEM, CDR \u0026amp; Agentless Host ScanningThese features require subscription-level access to cloud resources. When new subscriptions are added under an onboarded tenant or management group, you must re-run terraform apply. This ensures that the necessary cloud resources are provisioned for the new subscriptions, allowing these features to function correctly.\n","url":"https://docs.sysdig.com/en/sysdig-secure/connect-cloud-accounts/azure/automatic-onboarding/"},{"id":311,"title":"Automatic Cloud Project Onboarding","content":"Newly created GCP projects are automatically detected and onboarded within 24 hours.\nAutomatic Cloud Project Onboarding enhances the GCP onboarding experience. This functionality:\nAllows you to selectively enable or disable this behavior using the UI or Terraform. Provides visibility into newly added projects without any additional setup required. This capability reflects the dynamic nature of modern cloud environments and reduces the manual overhead required to maintain up-to-date infrastructure visibility.\nPrerequisites GCP organization or folder-level access with the required permissions Sysdig Secure account with organization admin rights Automatic Cloud Project Onboarding StepsThe following steps outline the process for automatic GCP project onboarding:\nLog in to Sysdig Secure. Go to Integrations \u0026gt; Environments \u0026gt; GCP. Click Add GCP Account. Select Organization. In the step Projects to Onboard, you will see Automatic Onboarding \u0026amp; Offboarding enabled by default. When you deploy Terraform, you will notice enable_automatic_onboarding = true in the snippet.\nVerifying Automatic Cloud Project OnboardingOnce you have completed onboarding of your organization, you can go ahead and create additional projects within the selected GCP folders or organization.\nAny newly created GCP projects that are in active state will be automatically detected and onboarded. You can verify this through Integrations \u0026gt; Environments \u0026gt; GCP. The new projects will be listed and the status should show as Connected.\nFor example, the following image shows a newly onboarded project: ","url":"https://docs.sysdig.com/en/sysdig-secure/gcp/automatic-onboarding/"},{"id":312,"title":"AWS CloudTrail Policy","content":"The AWS Cloud Trail category includes several types of policies, such as Sysdig AWS Threat Intelligence and Sysdig AWS Notable Events. These policies detect noteworthy occurrences, such as a suspicious IP Inbound Request, or a Console Login Without Multi-Factor Authentication (MFA).\nEvent notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nBehavioral AnalyticsSysdig AWS Behavioral Analytics is a unique case under the AWS CloudTrail policy. Instead of triggering at single incidents, its rules detect both suspicious sequences of actions and unusual clusters of activities across various AWS services, such as Identity and Access Management (IAM), Elastic Compute Cloud (EC2) and Simple Storage Service (S3). This improves detection of sophisticated threats, such as privilege escalation attempts and reconnaissance activities.\nYou can turn rules for Sysdig AWS Behavioral Analytics on or off, and edit existing exceptions field values, but you cannot duplicate it to create custom or ruleset policies, as you can with other managed policies. This is because behavioral analytics is not based on the Falco rules engine.\nView Behavioral AnalyticsTo see behavioral analytics policies:\nLog in to Sysdig Secure.\nSelect Policies \u0026gt; Runtime Policies.\nUnder the AWS CloudTrail policy, find the managed policy type Sysdig AWS Behavioral Analytics.\nSelect the policy to review its rules in detail.\nTo see behavioral analytics events:\nLog in to Sysdig Secure.\nSelect Detection \u0026amp; Response \u0026gt; Threats.\nBehavioral analytics events will show up in the event feed.\nStats and Sequence are are the two types of behavioral analytics. Stats have a list of API names and a corresponding count of how often that API was hit in the time interval. Sequence events show the sequence of APIs that were hit to match the condition of the rule.\nBehavioral Analytics events do not appear in the insights view.\nAdd ExceptionsBehavioral Analytics do not support custom exceptions, but you can add values to existing exceptions. Exception definitions are added by the Sysdig threat research team. To add values to exceptions:\nLog in to Sysdig Secure.\nSelect Policies \u0026gt; Runtime Policies.\nUnder the AWS CloudTrail policy, select Sysdig AWS Behavioral Analytics.\nThe detail panel appears.\nSelect the pencil icon in the top right.\nThe editor appears.\nSelect a rule to which you want to add an exception.\nThe rule detail panel appears.\nSelect the pencil icon in the top right.\nThe rule page appears.\nSelect Open Exceptions Editor.\nThe exceptions modal appears.\nSelect the pencil icon on an exception to add values.\nThe exception comparator supports regex, in, and = field matching.\nBehavioral analytics do not support Suggested Exceptions or auto tuning.\nFill in the exception values and click Apply.\nCreate an AWS CloudTrail PolicyTo create an AWS CloudTrail policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select AWS CloudTrail.\nConfigure an AWS CloudTrail PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. The underlying rule priorities and the severity you assign to the policy do not affect each other.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate personnel.\nSee also: Set Up Notification Channels.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and AWS CloudTrail.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose AWS CloudTrail to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/aws_cloudtrail_policy/"},{"id":313,"title":"AWS Cloudwatch Licensing","content":"The license count:\nIncludes Reserved agents plus On-Demand agents (even if not in use).\nIs used to determine how many AWS resources are displayed for each service in each region.\nIs not transferable between different AWS services.\nAWS Service Type Priorities and LimitsFor each AWS service type, services are displayed in the following priority:\nElastic Compute Cloud (EC2): Pick instances with agents installed, then instances belonging to Elastic Container Service (ECS), instance is launched before another, alphabetically by instance ID, up to license count.\nRelational Database Service (RDS): Pick by creation time, oldest instances first, up to license count.\nElastic Load Balancer (ELB): Pick by number of balanced instances (larger ELBs 1st), then by creation time, oldest first, up to license count.\nElastiCache: Sort by name and display up to license count items.\nSimple Queue Service (SQS): Sort queues by name and pick up to license count number of queues to fetch. Data is shown only for queues that are reporting metrics.\nDynamoDB: Sort by name and display up to license count items.\nApplication Load Balancer (ALB): Sort by name and display up to license count items.\nFor more information on AWS metrics, see AWS in the Metrics Dictionary.\nSample Use CaseSuppose you have 200 AWS instances, have purchased 100 Sysdig agent licenses, and have actually installed 50 agents.\nThe following limits would apply to your views of AWS services, per region:\nEC2: The 50 instances with agents installed would be shown first, then 50 more instances, first from EC2, then from ECS, then per uptime.\nRDS: 100 RDS listings would be shown, oldest first.\nELB: 100 ELBs would be shown (largest first), then by creation time, oldest first.\nElastiCache: 100 ElastiCache objects would be shown, alphabetically by name.\nSQS: 100 SQS queues that are reporting metrics would be shown.\nDynamoDB: 100 DynamoDBs would be shown, alphabetically by name.\nALB: 100 ALBs would be shown, alphabetically by name.\nTo increase the limit of items in the AWS Services views, contact Sysdig Sales to enable additional resources depending on your license agreement.\n","url":"https://docs.sysdig.com/en/administration/aws_cloudwatch/"},{"id":314,"title":"AWS Cost and Usage Reporting","content":"For AWS Cost and Usage Reporting, you can use one of the following methods to connect to an AWS account:\nUse the CloudFormation template that Sysdig provides.\nSysdig recommends using CloudFormation because it automatically creates all the resources required and it allows for setting up AWS Cost and Usage Reports and Athena automatically. You can do it using either of the following :\nUse an AWS access key and secret key, and manually managing/rotating them as needed. Use AWS Role Delegation. Manually enter the AWS configuration.\nConnect an AWS Account Log in to Sysdig Monitor as an Admin.\nFrom the left sidebar, select Integrations \u0026gt; Cloud Accounts.\nThe Cloud Accounts page is displayed.\nOn the Cloud Accounts screen, select Add Account \u0026gt; AWS.\nSelect Cost and Usage Reporting.\nAdd a new account or select an existing account.\nIf you are adding a new account, select an appropriate integration method.\nRole Delegation: Specify the following:\nAccount ID: Your AWS account ID. Role: The name you will enter for the SysdigCostAccessRoleName field in the CloudFormation template. This role will be used by Sysdig to access the cost and billing data. The Outputs tab on the Sysdig-PrivateBilling Stacks details page gives you the SysdigCostAccessRoleName, which will be listed as the PrivateBillingRoleName. For more information on Role Delegation, see Role Delegation. Access Key: Specify the following:\nAccess Key ID: Your AWS access key ID. Secret Access Key: The secret access key associated with your account. For more information, see Integrate AWS Account and CloudWatch Metrics. Continue with one of the following:\nUsing the CloudFormation Template Configure Manually Complete the installation and click Confirm.\nConfigure Using the CloudFormation TemplateOn Sysdig Monitor UI On the Complete Configuration screen, click Use CloudFormation Template.\nYou will be redirected to log in to your AWS account. Continue with On AWS Console.\nOn AWS ConsoleSysdig provides a CloudFormation Template to create a stack corresponding to AWS Private Billing. The stack you create feeds cost data into Sysdig in each region specified in the template.\nTo see the CloudFormation Template, download the YAML file.\nTo continue with configuration:\nEnsure you are logged in to your AWS account.\nThe following information, except CreateNewRole, will be populated in the QuickCreate page. Change if necessary.\nStack Name: This is the unique name to identify the stack you create.\nFor Cost and Usage Reporting, the default name is Sysdig-PrivateBilling.\nS3 Region: The region where your S3 bucket is located. Select a region from the drop-down.\nS3 Bucket Name: Specify a unique name for the S3 bucket where your AWS cost and usage data will be stored.\nS3BucketPrefix: The prefix for the cost and usage reporting files inside the S3 bucket. The default is billing-data.\nS3 Athena Bucket Prefix: The prefix of the Athena query results inside S3 bucket. The default is athena-cur-query-results.\nSysdig Cost Access Role Name: Specify a name for the role. The role will be used by Sysdig to access the cost and billing data. Enter the same name you have used while configuring the account in the Sysdig Monitor UI.\nCreate New Role: Select true if you are creating a new role. If you are using an existing role, select false.\nSysdig AWS Account ID: The Sysdig AWS account ID that will assume the SysdigCostAccessRoleName to collect the private billing data.\nSysdig External ID: Your Sysdig External ID which will be used when assuming roles in the account\nSpotDataFeedBucketName: Optional. The bucket where the spot data feed is sent if you enable the Setting up the Spot Data feed.\nClick Acknowledge that AWS CloudFormation might create IAM resources with custom names.\nClick Create Stack. Expect a 10-15 minute delay to complete creating the stack.\nCopy the following from the Outputs tab of your Sysdig-PrivateBilling stack to complete the configuration in the Sysdig Monitor UI:\nMonitor UI AWS Bucket Name S3BucketName Region AthenaRegion Database AthenaDatabase Table AthenaTable Workgroup AthenaWorkgroup Spot Prices Feed Bucket Name SpotPricesBucketName Configure ManuallyIf you\u0026rsquo;ve already created a Sysdig-PrivateBilling stack for AWS cost and usage reporting, you can manually associate your AWS account for AWS private billing.\nOn the Complete Configuration screen, click configure your account manually.\nProvide the following information that you have copied from the Outputs tab of your Sysdig-PrivateBilling stack.\nMonitor UI AWS Bucket Name S3BucketName Region AthenaRegion Database AthenaDatabase Table AthenaTable Workgroup AthenaWorkgroup Spot Prices Feed Bucket Name SpotPricesBucketName Complete the installation and click Confirm.\nNecessary Role PermissionsWhen you set up Cost and Usage Reporting via CloudFormation Template, a role is configured for Sysdig and a trust relationship is created to allow Sysdig to assume the role.\nThe SysdigCostAccessRoleName role requires the following policy:\nExpand { \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Action\u0026#34;: [ \u0026#34;athena:*\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:athena:us-east-1:\u0026lt;AWS account id\u0026gt;:workgroup/\u0026lt;Athena workgroup name\u0026gt;\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Sid\u0026#34;: \u0026#34;AthenaAccess\u0026#34; }, { \u0026#34;Action\u0026#34;: [ \u0026#34;glue:GetDatabase*\u0026#34;, \u0026#34;glue:GetTable*\u0026#34;, \u0026#34;glue:GetPartition*\u0026#34;, \u0026#34;glue:GetUserDefinedFunction\u0026#34;, \u0026#34;glue:BatchGetPartition\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:glue:*:*:catalog\u0026#34;, \u0026#34;arn:aws:glue:*:*:database/\u0026lt;Athena database\u0026gt;\u0026#34;, \u0026#34;arn:aws:glue:*:*:table/\u0026lt;Athena table with CUR data\u0026gt;/*\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Sid\u0026#34;: \u0026#34;ReadAccessToAthenaCurDataViaGlue\u0026#34; }, { \u0026#34;Action\u0026#34;: [ \u0026#34;s3:GetBucketLocation\u0026#34;, \u0026#34;s3:GetObject\u0026#34;, \u0026#34;s3:ListBucket\u0026#34;, \u0026#34;s3:ListBucketMultipartUploads\u0026#34;, \u0026#34;s3:ListMultipartUploadParts\u0026#34;, \u0026#34;s3:AbortMultipartUpload\u0026#34;, \u0026#34;s3:CreateBucket\u0026#34;, \u0026#34;s3:PutObject\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:s3:::\u0026lt;S3 bucket name for Athena query results\u0026gt;/\u0026lt;prefix for Athena query results\u0026gt;*\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Sid\u0026#34;: \u0026#34;AthenaQueryResultsOutput\u0026#34; }, { \u0026#34;Action\u0026#34;: [ \u0026#34;s3:Get*\u0026#34;, \u0026#34;s3:List*\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:s3:::\u0026lt;S3 bucket for CUR data\u0026gt;*\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Sid\u0026#34;: \u0026#34;S3ReadAccessToAwsBillingData\u0026#34; }, { \u0026#34;Action\u0026#34;: [ \u0026#34;organizations:ListAccounts\u0026#34;, \u0026#34;organizations:ListTagsForResource\u0026#34;, \u0026#34;organizations:ListAccountsForParent\u0026#34;, \u0026#34;organizations:ListParents\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;*\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Sid\u0026#34;: \u0026#34;ReadAccessToAccountTags\u0026#34; }, { \u0026#34;Action\u0026#34;: [ \u0026#34;ec2:DescribeInstances\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;*\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Sid\u0026#34;: \u0026#34;ListEC2Metadata\u0026#34; }, { \u0026#34;Action\u0026#34;: [ \u0026#34;lakeformation:GetDataAccess\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;*\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Sid\u0026#34;: \u0026#34;LakeFormation\u0026#34; } ] } This will be provisioned as part of the CloudFormation template.\nTo allow Sysdig to assume this role, the CloudFormation template also sets up a trust relationship for the role:\nExpand { \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: { \u0026#34;AWS\u0026#34;: \u0026#34;arn:aws:iam::\u0026lt;Sysdig AWS account id\u0026gt;:root\u0026#34; }, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34;, \u0026#34;Condition\u0026#34;: { \u0026#34;StringEquals\u0026#34;: { \u0026#34;sts:ExternalId\u0026#34;: \u0026#34;\u0026lt;customer\u0026#39;s external id\u0026gt;\u0026#34; } } } ] } You can retrieve the values for both the Sysdig AWS Account ID and the External ID via an API call to /api/v2/providers/info/awsCloudInformation:\ncurl --location \u0026#39;{host}/api/v2/providers/info/awsCloudInformation\u0026#39; \\ --header \u0026#39;Content-Type: application/json\u0026#39; \\ --header \u0026#39;Authorization: Bearer {api_token}\u0026#39; The response should look like this:\n{ \u0026#34;apiToken\u0026#34; : \u0026#34;\u0026lt;Your user API token\u0026gt;\u0026#34;, // not needed in this case \u0026#34;externalId\u0026#34; : \u0026#34;\u0026lt;customer\u0026#39;s external id\u0026gt;\u0026#34;, \u0026#34;awsSystemAccountId\u0026#34; : \u0026#34;\u0026lt;Sysdig AWS account id\u0026gt;\u0026#34; } ","url":"https://docs.sysdig.com/en/sysdig-monitor/connect-aws-account/cost-and-usage-reporting/"},{"id":315,"title":"Backup and Restore High Availability PostgreSQL Clusters","content":"The tool can be leveraged in the following scenarios:\nPostgreSQL cluster cannot start, for example, due to corrupted data. You need to restore databases in a new Postgres HA instance.\nKubernetes cluster is not fully functional, and you need to recreate all Postgres databases in a new cluster for fast recovery.\nBack Up a PostgreSQL HA ClusterUse the Installer to deploy the backup tool in the cluster so it creates periodical backups to Amazon S3 or S3-compatible object storage. Later on, you can use the most recent copy to restore the databases. Install the backup tool as a cronjob called pg-backup-ha-cronjob in the sysdigcloud namespace. By default, it creates backups every 6 hours.\nPrerequisites Provision an S3 or S3-compatible bucket. AWS Access Key ID and AWS Secret Access Key with appropriate privileges to use the bucket. Backup ConfigurationUse the configuration parameters in the values.yaml associated with the Installer to configure the backup operation.\nManually Trigger a BackupYou can trigger a backup on-demand using the following command:\nkubectl create job pg-backup --from=cronjob/pg-backup-ha-cronjob -n sysdigcloud Verify Backup OperationIn the sysdigcloud namespace, run the following command, replacing \u0026lt;backup-pod-name\u0026gt; with the pod in which the latest backup job is executed:\nkubectl get pods -n sysdigcloud | grep \u0026#34;pg-backup-ha-cronjob\u0026#34; kubectl logs \u0026lt;backup-pod-name\u0026gt; -n sysdigcloud The log of the pod provides the details about the backup operations. A successful backup job should generate logs similar to this:\n2023-11-07T23:06:21+00:00 - INFO - Checking envs 2023-11-07T23:06:21+00:00 - INFO - Validating S3 Bucket 2023-11-07T23:06:21+00:00 - INFO - Aws: S3 region is: us-east-1 2023-11-07T23:06:21+00:00 - INFO - Starting 2023-11-07T23:06:21+00:00 - INFO - Checking envs 2023-11-07T23:06:21+00:00 - INFO - Connecting to S3 and backing up 2023-11-07T23:06:21+00:00 - INFO - Done Restore a PostgreSQL HA BackupThe restore tool relies on the Kubernetes Job. As datastore restoration is carried out only upon request. It is not bundled in the Installer binary. You can trigger the database restore operation by applying the given YAML file. The duration of the restoration process will vary depending on the size of the databases.\nExecuting the restore necessitates scaling down all deployments in the sysdig namespace and a StatefulSet. This ensures a seamless and error-free database restoration.\nThis topic assumes that the most recent backup can be found in the S3 bucket in the path as indicated in the Backup section.\nScale Down the Workloads Count the amount of replicas of the StatefulSet sysdigcloud-netsec-ingest:\nkubectl get sts sysdigcloud-netsec-ingest -n sysdigcloud An example output:\nNAME READY AGE sysdigcloud-netsec-ingest 1/1 4h11m Note it down for future use.\nCount the number of ready replicas for the all the sysdig deployments:\nkubectl get deploy -n sysdigcloud An example output:\nNAME READY UP-TO-DATE AVAILABLE AGE ingress-default-backend 1/1 1 1 4h7m registry-scanner-api 2/2 2 2 3h55m sysdig-alert-manager 1/1 1 1 4h4m Note it down for future use.\nScale down the workloads:\nkubectl scale deployment --replicas 0 --all -n sysdigcloud kubectl scale sts sysdigcloud-netsec-ingest --replicas=0 -n sysdigcloud Apply the Kubernetes JobApply the example Kubernetes job file to the cluster in the sysdigcloud namespace:\nAn example Job for Restore:\napiVersion: batch/v1 kind: Job metadata: name: pg-restore-ha-job namespace: sysdigcloud generateName: pg-restore-ha spec: ttlSecondsAfterFinished: 200 template: spec: restartPolicy: Never containers: - image: quay.io/sysdig/postgres-backup-onprem:0.1.3 name: pg-backup-ha command: [\u0026#34;/usr/local/bin/pg-restore.sh\u0026#34;] env: - name: TZ value: Etc/UTC - name: LOGICAL_BACKUP_PROVIDER value: s3 - name: LOGICAL_BACKUP_S3_BUCKET value: example-bucket - name: LOGICAL_BACKUP_S3_REGION value: us-east-1 - name: LOGICAL_BACKUP_PATH value: \u0026#34;demo-path\u0026#34; - name: PGPORT value: \u0026#34;5432\u0026#34; - name: PGHOST value: sysdigcloud-postgres-cluster - name: PGUSER valueFrom: secretKeyRef: name: root.sysdigcloud-postgres-cluster.credentials.postgresql.acid.zalan.do key: username - name: PGDATABASE value: postgres - name: PGSSLMODE value: require - name: PGPASSWORD valueFrom: secretKeyRef: name: root.sysdigcloud-postgres-cluster.credentials.postgresql.acid.zalan.do key: password - name: AWS_ACCESS_KEY_ID value: XXXXXXXXXX - name: AWS_SECRET_ACCESS_KEY value: YYYYYYYYYY imagePullSecrets: - name: sysdigcloud-pull-secret Verify Restore OperationYou can run the following command in the sysdigcloud namespace to get the name of the pod which runs the restore job.\nkubectl get pods -n sysdogcloud | grep \u0026#34;pg-restore-ha-job\u0026#34; kubectl logs \u0026lt;restore-pod-name\u0026gt; -n sysdigcloud The pod logs provides the indication whether the job is completed successfully or not.\n2024-01-07T09:00:00+00:00 - INFO - Starting 2024-01-07T09:00:00+00:00 - INFO - Checking envs 2024-01-07T09:00:00+00:00 - INFO - Connecting to S3 and restoring 2024-01-07T09:20:00+00:00 - INFO - Done Scaling Up the WorkloadsWhen the job is complete, scale up each deployment and StatefulSet by using the number of replicas noted down earlier.\nDeploymentsFor example:\nkubectl scale deployment registry-scanner-api --replicas 2 -n sysdigcloud kubectl scale deployment ingress-default-backend --replicas 1 -n sysdigcloud kubectl scale deployment sysdig-alert-manager --replicas 1 -n sysdigcloud StatefulSetFor example:\nkubectl scale sts sysdigcloud-netsec-ingest --replicas=1 -n sysdigcloud Configuration Parameters Parameter Value Example logicalBackupS3Bucket The AWS S3 bucket name. example-bucket logicalBackupS3Region The AWS Region where S3 bucket resides. us-east-1 logicalBackupPath The path to the backup files. logicalBackupProvider AWS S3 S3 awsAccessKeyID AWS Access Key ID awsSecretAccessKey AWS Secret Access Key deploymentEnvironment The variable that determines whether the backups includes all databases, or Sysdig only databases.* If the value is left blank, then all databases will be backed up.* If the value is set to sysdig_databases, all the databases are backed up except template0, template1 ,postgres . sysdig_databases enabled The variable name that determines whether the backup is enabled or disabled . The value can be enabled or disabled. The default is enabled. enabled schedule The frequency to perform the database backup operation. \u0026quot;* */6 * * *\u0026quot; ","url":"https://docs.sysdig.com/en/administration/onprem-backup-restore-ha-postgressql-clusters/"},{"id":316,"title":"Captures (Secure)","content":"LimitationsThe Sysdig Agent can record only one capture per host at a time due to the volume of data collected. If multiple policies, each configured to create a capture, are triggered simultaneously on the same host, only the first event will store the capture successfully. Subsequent attempts to initiate captures will fail with the error: Maximum number of outstanding captures (1) reached. This issue also occurs with overlapping captures, often caused by lengthy capture durations.\nAccess CapturesTo access the Captures:\nLog in to Sysdig Secure.\nSelect Threats \u0026gt; Investigate | Captures\nNavigate CapturesThe Captures page contains a table listing the:\nStatus: When the status is Ok, the file has been successfully transmitted from the Sysdig agent to the storage bucket, and is available for download and analysis. Name: The capture file name. Time: The time the capture was taken. Duration: The period of time captured. Trigger: The cause that triggered the capture. Infrastructure: The host the capture was retrieved from. You can also search for captures using the search bar, or filter them by Error or Expiring.\nTake a CaptureYou can take a capture:\nManually As a Policy action Take a Capture ManuallyTo take a capture manually:\nGo to Threats \u0026gt; Investigate |Captures from the left navigation bar.\nSelect Take Capture from the top right corner.\nThe Take Capture window appears.\nSpecify the following information:\nName: Define the Name of the capture, also used as capture file name. Host Name: Specify the Host where you want to take a capture Container ID: Configure the Container ID to set as a predefined filter when you open the Capture using Sysdig Inspect. Storage: Choose your storage options. The default is Sysdig Secure Storage. To configure alternative storage options, see Configure Capture Storage. Duration: Define the duration of the capture. The default time is 5 seconds; the maximum length is 300 seconds (five minutes). Filter: Optionally, set a filter for the capture. This restricts the data streaming captured (syscalls, i/o streams), while it doesn\u0026rsquo;t apply to the inspector tables (file descriptors, network connections, open ports, thread table, process list, containers). Applicable filters match the syntax for Falco conditions. See Condition Syntax. Click Start.\nThe capture is taken.\nAfter the capture is complete, select whether to Keep it or Discard the capture. Capture you keep are displayed in the Captures report page.\nTake a Capture as Policy ActionTo take a capture in Sysdig Secure, set up a policy with the capture Action available, or manually take a capture in the Captures page.\nPolicies that offer the capture action include:\nList Matching Linux Workload To configure a capture to be taken as Policy Action:\nSelect Policies \u0026gt; Runtime Policies from the left navigation bar.\nSelect an existing List Matching or Workload Policy, or create a new one.\nComplete the configuration under the Actions section:\nCapture: Toggle on or off. File Name: Define the Name of the capture, also used as capture file name. Storage: Choose your storage options. The default is Sysdig Secure Storage, where captures are stored for 90 days. To configure alternative storage options, see Configure Capture Storage. Time interval: Define the time interval of the capture. The default time is from 5 seconds before to 20 seconds after the event; the maximum length is 300 seconds (five minutes). Filter: Optionally, set a filter for the capture. This restricts the data streaming captured (syscalls, i/o streams), while it doesn\u0026rsquo;t apply to the inspector tables (file descriptors, network connections, open ports, thread table, process list, containers). Applicable filters match the syntax for Falco conditions. See Condition Syntax. Review a CaptureFrom the Captures page you can perform multiple operations on the previously taken Captures:\nOpen with Sysdig Inspect Download Delete Delete a Capture File From the Captures page, select the capture files to be deleted.\nClick the Delete (trash can) icon.\nClick Yes to confirm deleting the capture, or the No to cancel.\nReview a Capture with Sysdig InspectTo review the capture file with Sysdig Inspect:\nFrom the Captures page, navigate to the target capture file.\nHover your cursor over the target capture file.\nClick on the Sysdig Inspect button to open Sysdig Inspect in a new browser tab.\nSysdig Inspect is not available for captures over 200 MB.\nDownload a Capture FileTo download a capture file:\nFrom the Captures page, select the three-dot menu on the side of a capture listing.\nSelect Download File.\nThe capture downloads in .scap format. You can open this with:\nSysdig Inspect sysdig or csysdig Delete a Capture FileYou can delete a single capture file or multiple files.\nTo delete a single file:\nFrom the Captures page, navigate to the target capture file.\nHover your cursor over the target capture file.\nSelect the three-dot menu icon from the right hand side of the capture listing.\nSelect the Delete (trash can) button.\nClick Delete to confirm deleting the capture, or No to cancel.\nTo delete multiple files:\nFrom the Captures page, select the capture files to be deleted.\nSelect the option Delete next to the number of selected captures in the top right corner.\nOn the Delete Captures prompt, click the Yes button to confirm, or the No button to cancel.\nDisable Capture FunctionalitySometimes, security requirements dictate that capture functionality should not be available. To disable the Captures feature, see Disable Captures.\nCapture Files StorageSysdig capture files are stored in Sysdig\u0026rsquo;s storage (for SaaS environments), or in the Cassandra DB (for on-premises environments) by default. Captures saved in the Sysdig Storage (SaaS environments) for longer than the Runtime retention period are automatically deleted. See [the dedicated documentation]((https://docs.sysdig.com/en/administration/data-retention/#sysdig-secure-retention-limits) to learn more about it. Both environments have the option to use a S3-compatible custom storage, such as Minio or IBM Cloud Object Storage. This lets you store captures for longer periods of time. To configure a custom storage, see S3 Capture Storage.\nCapture ThresholdEnablement and ConfigurationThe agent monitors memory usage during Captures to prevent restarts caused by intensive computational demands. You can adjust the default values by adding the following configuration to the dragent.yaml:\ncapture_memory_thresholds: enabled: true critical_percentage: 95 # critical if the memory used is 95% of limits warning_percentage: 90 # warning if the memory used is 90% of limits Capture Threshold LoggingWhen the Warning or Critical threshold is reached, the agent logs the following messages:\n-skipping capture due to high memory usage -interrupting capture. Agent memory is too high\n","url":"https://docs.sysdig.com/en/sysdig-secure/captures/"},{"id":317,"title":"Collect Event Data","content":"The following applications are currently supported:\nDocker\nKubernetes\nContainerD\nYou can configure Sysdig Monitor to collect additional events through Custom Events. See Custom Events for more information on ingesting custom events into Sysdig Monitor.\nEnable EventsBy default, only a limited set of events are collected for a supported application and are listed in the agent configuration file. To enable collecting other supported events, add an events entry to the dragent.yaml file. Events marked with * are enabled by default and are listed in the default configuration file. See Understand the Agent Configuration.\nYou can also change the log entry in dragent.yaml to filter events by severity.\nSee the following sections for more detail.\nCustomize Events CollectionTo customize the default events collected for a specific application (by either enabling or disabling events), add an events entry todragent.yaml as described in the examples below.\nAn entry in a section in dragent.yaml overrides the entire section in the default configuration.\nFor example, the Pulling entry below will permit only the kubernetes pod Pulling events to be collected and all other kubernetes pod events settings in the default configuration file will be ignored.\nHowever, other kubernetes sections - node and replicationController - remain intact and will be used as specified in the default configuration file.\nExample 1: Collect Only Certain EventsCollect only \u0026lsquo;Pulling\u0026rsquo; events from Kubernetes for pods:\nevents: kubernetes: pod: - Pulling Example 2: Disable All Events in a SectionTo disable all events in a section, set the event section to none:\nevents: kubernetes: none docker: none Example 3: Combine MethodsThese methods can be combined. For example, disable all kubernetes node and docker image events and limit docker container events to[attach, commit, copy] . The components events in other sections will be collected as specified by default:\nevents: kubernetes: node: none docker: image: none container: - attach - commit - copy Format Sequences as List or Single LineIn addition to bulleted lists, sequences can also be specified in a bracketed single line. For example:\nevents: kubernetes: pod: [Pulling, Pulled, Failed] Therefore, the following two settings are equivalent, permitting only Pulling, Pulled, Failed events for pods to be emitted:\nevents: kubernetes: pod: [Pulling, Pulled, Failed] events: kubernetes: pod: - Pulling - Pulled - Failed Change Event Collection by SeverityEvents are limited globally at the agent level based on severity, using the logsettings in dragent.yaml.\nThe default setting for the events severity filter is information. Only warning and higher severity events are transmitted.\nValid severity levels are: fatal, emergency, critical, error, warning, alert, notice, information, debug, trace, none\nExample 1: Block Low-Severity MessagesBlock all the low-severity messages (notice, information, debug):\nlog: event_priority: warning Example 2: Block All Event CollectionBlock all the event collection:\nlog: event_priority: none For other uses of the log settings see Optional: Change the Agent Log Level.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/collect-event-data/"},{"id":318,"title":"Configuration","content":"The Sysdig Serverless Workload Agent uses the SYSDIG_EXTRA_CONF environment variable as a unified configuration block for advanced features. This variable accepts values in either YAML or JSON format.\nFor more information, see:\nAgent Logs Configuration Connect to HTTP Proxy Feature Management ","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-configuration/"},{"id":319,"title":"Configuration Library","content":"Sysdig Windows AgentGeneric Configuration Configuration dragent.yaml Description Default Access Key customerid See Sysdig Agent Access Keys to learn how to retrieve the agent keys.\nAgent Tags tags The list of tags to identify the host where the agent is installed. For example: role:webserver, location:europe, role:webserver. See Quick Install Sysdig Windows Agent for more information. Proxy http_proxy Allows the agent to communicate with Sysdig collector through http_proxy. See Enable HTTP Proxy for Agents for more information.\nHTTP Proxy Host http_proxy.proxy_host The host IP of the proxy server.\nHTTP Proxy Port http_proxy.proxy_port See Enable HTTP Proxy for Agents for more information.\nHTTP Proxy User http_proxy.proxy_user See Enable HTTP Proxy for Agents for more information.\nHTTP Proxy Password http_proxy.proxy_password See Enable HTTP Proxy for Agents for more information.\nEnable HTTP Proxy http_proxy.ssl See Enable HTTP Proxy for Agents for more information.\nHTTP Proxy SSL verification http_proxy.ssl_verify_certificate See Enable HTTP Proxy for Agents for more information.\nHTTP Proxy CA certificate http_proxy.ca_certificate See Enable HTTP Proxy for Agents for more information.\nCollector endpoint collector Enter the host name or IP address of the Sysdig collector service. Note that when used within dragent.yaml, must be lowercase collector.\nSee On-Premises Installation for more information.\nCollector Port collector_port On-prem only. The port used by the Sysdig collector service. 6443 Event capture settings windows Controls various internal configuration knobs that influence the variety of captured events Enable thread events windows.enable_thread Controls if thread events are captured true Enable module events windows.enable_image Controls if image loading/unloading events are captured true Enable network events windows.enable_network Controls if network events are captured true Enable file events windows.enable_file Controls if file system events are captured true Enable registry events windows.enable_registry Controls if registry events are captured true Enable handle events windows.enable_handle Controls if object manager events are captured false Enable Audit API events windows.enable_audit_api Controls if Audit API events are captured true Enable AMSI events windows.enable_amsi_scan_interface Controls if Antimalware Scan Interface events are captured true ","url":"https://docs.sysdig.com/en/sysdig-secure/windows-configuration-library/"},{"id":320,"title":"Connect AWS Account in Sysdig Monitor","content":" Cloud Watch Monitoring : Monitor your AWS infrastructure for health and performance.\nYou can use one of the following methods to connect an AWS account to Sysdig:\nCloudWatch Metric Streams\nAWS CloudWatch APIs\nAfter connecting an AWS account, data will become visible in the Sysdig Monitor UI after a 10-15 minute delay.\nCost and Usage Reporting: View AWS billing reports and savings estimates. Connect an AWS account using one of the following:\nAn AWS access key and secret key AWS Role Delegation ","url":"https://docs.sysdig.com/en/sysdig-monitor/connect-aws-account/"},{"id":321,"title":"Integrate Sysdig with Docker Scout","content":"The APIs capture which images are running and where. In addition, they provide details about which packages are in use. This lets you view the Scout Dashboard and understand the potential impact to their deployed environments. Among the images in production, you can check which vulnerable packages are actually used, represent real risk, and therefore should be prioritized for remediation.\nPrerequisites Have administrator rights to your Sysdig Secure SaaS account and have the Sysdig Agent installed in the clusters you want to integrate. Have a Docker account and have organizational owner rights to enable the integration in the Docker Scout Dashboard. Contact Sysdig Support to explicitly enable Risk Spotlight in the backend for your Sysdig account. IntegrationEnsure that your Sysdig Agents are properly configured. Contact your Sysdig representative to enable Risk Spotlight in the backend.\nGenerate a Token for the Integration Select Integrations \u0026gt; Third Party | Risk Spotlight. The Spotlight Integration page appears with a list of existing tokens and their expiry dates.\nClick +Add Token at the top right.\nFill in the attributes and click Create Token.\nName: Choose a name that indicates the integration with which the token is associated Expiration: Select an expiration date (1/3/6 monthsor 1 year) Copy the new token as it is displayed in the list.\nStore the token in a safe place; it will not be visible or recoverable again.\nContinue with the Docker Scout integration guide.\nTo Renew a token at any time, click the Renew button, reset the expiry, and confirm.\nTo Delete a token, click the X beside the token name and confirm. This action will sever the integration between Sysdig and the 3rd-party tool.\nCheck Integration in DockerSysdig runtime insights information enriches Docker Scout images and findings, streamlining the prioritization process.\nFor more information about Docker Scout, see environment monitoring and how CLI and Web UI results are enriched with this integration.\n","url":"https://docs.sysdig.com/en/sysdig-secure/appsec-integrations-docker-scout/"},{"id":322,"title":"Domain-Wide Delegation Permissions","content":"GCP Users Permissions CIEM Basic CIEM Advanced (Domain-Wide Delegation) Risk Findings Editor Role AppliedOwner Role AppliedInactive No MFAAdminEditor Role AppliedOwner Role AppliedInactive Profiling Label Learning Learning Permissions Calculation Available Available Highest Access Evaluation Available Available Risk Scoring Available Available Role Remediations Available Available Download CSV Reports Available Available GCP Service Accounts Permissions CIEM Basic CIEM Advanced (Domain-Wide Delegation) Risk Findings User Managed KeyAccess Key(s) Not RotatedMultiple Access Keys ActiveOwner Role Applied Inactive Admin Lateral MovementUser Managed KeyAccess Key(s) Not RotatedMultiple Access Keys ActiveOwner Role Applied Inactive Admin Profiling Label Learning Learning Permissions Calculation Available Available Highest Access Evaluation Available Available Risk Scoring Available Available Role Remediations Available Available Download CSV Reports Available Available GCP Groups Permissions CIEM Basic CIEM Advanced (Domain-Wide Delegation) Risk Findings Editor Role AppliedOwner Role AppliedAdmin InactiveAdminEditor Role AppliedOwner Role Applied Profiling Label Learning Learning Permissions Calculation Unavailable Available Highest Access Evaluation Available Available Risk Scoring Unavailable Available Role Remediations Unavailable Available Download CSV Reports Available Available GCP Roles Permissions CIEM Basic CIEM Advanced (Domain-Wide Delegation) Risk Findings InactiveAdmin InactiveAdmin Profiling Label Learning Learning Permissions Calculation Available Available Highest Access Evaluation Available Available Risk Scoring Available Available Role Remediations Available Available Download CSV Reports Available Available Membership Evaluation Unavailable Available ","url":"https://docs.sysdig.com/en/sysdig-secure/gcp-domain-wide-delegation/"},{"id":323,"title":"Configure ECS Fargate Serverless Agent","content":" Configure Priority Modes\nYou can use environment variables to customize the workload priority modes for Serverless Agents on ECS Fargate.\nFetching Secrets from Secrets Manager\nYou can retrieve the Sysdig Access Key from the AWS Secrets Manager when deploying the Workload Agent.\nManage Serverless Agent Logs\nEven if the Workload Agent runs in the same container as the workload it instruments, their log streams are handled separately.\n","url":"https://docs.sysdig.com/en/sysdig-secure/configure-serverless-ecs-fargate/"},{"id":324,"title":"Elastic Application Load Balancing (ALB)","content":"For more information, refer to the Elastic Application Load Balancer documentation.\naws.alb.ActiveConnectionCountThe total number of concurrent TCP connections active from clients to the load balancer and from the load balancer to the targets.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.ClientTLSNegotiationErrorCountThe number of TLS connections initiated by the client that did not establish a session with the load balancer.\nPossible causes include a mismatch of ciphers or protocols.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.ConsumedLCUsThe number of load balancer capacity units (LCU) used by the load balancer.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.HTTPCode_ELB_4XX_CountThe number of HTTP 4XX client error codes that originate form the load balancer. Client errors are generated when requests are malformed or incomplete. These requests have not been received by the target.\nThis count does not include any response codes generated by the targets.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.HTTPCode_ELB_5XX_CountThe number of HTTP 5XX server error codes that originate from the load balancer. Server errors are generated when requests are malformed or incomplete. These requests have not been received by the target.\nThis count does not include any response codes generated by the targets.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.HTTPCode_Target_2XX_CountThe number of HTTP 2XX response codes generated by the target.\nThis count does not include any response codes generated by the load balancer.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.HTTPCode_Target_3XX_CountThe number of HTTP 3XX response codes generated by the target.\nThis count does not include any response codes generated by the load balancer.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.HTTPCode_Target_4XX_CountThe number of HTTP 4XX response codes generated by the target.\nThis count does not include any response codes generated by the load balancer.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.HTTPCode_Target_5XX_CountThe number of HTTP 5XX response codes generated by the target.\nThis count does not include any response codes generated by the load balancer.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.HealthyHostCountThe number of targets that are considered healthy.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.IPv6ProcessedBytesThe total number of bytes processed by the load balancer over IPv6.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.IPv6RequestCountThe total number of data requested by the load balancer over IPv6.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.NewConnectionCountThe total number of new TCP connections established from clients to the load balancer and from the load balancer to targets.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.ProcessedBytesThe total number of bytes processed by the load balancer over IPv4 and IPv6.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.RejectedConnectionCountThe number of connections that were rejected because the load balancer had reached its maximum number of connections.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.RequestCountThe number of requests processed over IPv4 and IPv6. This count only includes the requests with a response generated by a target of the load balancer.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.RequestCountPerTargetThe average number of requests received by each target in a target group.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.RuleEvaluationsThe number of rules processed by the load balancer given a request rate averaged over an hour.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.TargetConnectionErrorCountThe number of connections that were not successfully established between the load balancer and target.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.TargetResponseTimeThe time elapsed, in seconds, after the request leaves the load balancer until a response from the target is received.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.TargetTLSNegotiationErrorCountThe number of TLS connections initiated by the load balancer that did not establish a session with the target.\nPossible causes include a mismatch of ciphers or protocols.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.alb.UnHealthyHostCountThe number of targets that are considered unhealthy.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/sysdig-monitor/aws-metrics-legacy/elastic-application-load-balancing-alb/"},{"id":325,"title":"Enable Kubernetes Audit Logging","content":"The integration lets you audit:\nCreation and destruction of pods, services, deployments, and daemon sets Creating/updating/removing config maps or secrets Attempts to subscribe to changes to any endpoint There are two primary deployment methods:\nUsing the admission-controller Helm chart Platform-based individual deployment Prerequisites Helm v3.8 or above\nInstalled Sysdig Components on Kubernetes using Helm\nFor On-Prem, a Sysdig Secure API token.\nUse a custom role with the following permissions for Sysdig Secure:\nPolicies | Runtime Policies = READ\nDeployment Recommended: Replace helm install with helm upgrade --install.\nTo enable Kubernetes audit logging in your existing Sysdig Secure Helm install command, add the following flags:\n--set clusterShield.cluster_shield.features.audit.enabled=true For additional configuration options, including on-premises, using a proxy etc., see the admission-controller readme.\nWhile using the sysdig-deploy chart, ensure that all the extra parameters set within the admission subchart are prefixed with admissionController.\nVerify the Installation Install the Admission Controller on your Kubernetes cluster.\nThis feature is enabled by default through the features.k8sAuditDetections value.\nCheck your current Kubernetes Audit policies in Policies \u0026gt; Runtime Policies as you will be triggering one of those to prove it\u0026rsquo;s working correctly.\nWe recommend using \u0026ldquo;Create Privileged Pod\u0026rdquo; but you can choose any.\nActivate just the installed component logs to have them at sight:\nkubectl logs -f -n sysdig-admission-controller -l app.kubernetes.io/component=webhook Trigger the following command to force an unwanted audit detection:\nkubectl run nginx --image nginx --privileged If you have activated logs, you should see something like this:\n{\u0026#34;level\u0026#34;:\u0026#34;info\u0026#34;,\u0026#34;component\u0026#34;:\u0026#34;console-notifier\u0026#34;,\u0026#34;message\u0026#34;:\u0026#34;Pod started with privileged container (user=** pod=nginx ns=default images=nginx)\u0026#34;} Confirm that the event is displayed in Events in the Sysdig Secure UI.\nAuditLog OptionsIf you do not want to use the Helm installation option, choose the steps appropriate to your environment, below.\nThese instructions assume:\nThe Kubernetes cluster has NO audit configuration or logging in place. The steps add configuration only to route audit log messages to the Sysdig agent. Sysdig only supports the webhook backend, available in Kubernetes version 1.11. There is a beta script automating many of these steps, which is suitable for proof-of-concept/non-production environments. In any case, we recommend reading the step-by-step instructions carefully before continuing.\nThe table below summarizes the tested options:\nDistro/Platform Version Uses Webhook Uses Dynamic Uses Other OpenShift 4.2, 4.3 (legacy) X OpenShift 4.4+ not yet supported MiniShift 3.11 X Kops 1.15, 1.18, 1.20 X GKE (Google) 1.13 X (bridge) EKS (Amazon) eks.5/ Kubernetes 1.14 on AWS Cloud or AWS Outpost X CloudWatch AKS (Azure) 1.15+ X (bridge) RKE (Rancher) RKE v1.0.0/Kubernetes 1.13+ X IKS (IBM) 1.15 X Minikube 1.11+ X Kubeadm 1.11+ X Prerequisites: Install Sysdig Agent and Apply the Agent ServiceThese instructions assume that the Sysdig agent has already been deployed to the Kubernetes cluster. See Agent Installation for details. When the agent(s) are installed, have the Sysdig agent service account, secret, configmap, and daemonset information on hand.\nIf the sysdig-agent-service.yaml was not explicitly deployed during agent installation, you need to apply it now:\nkubectl apply -f https://raw.githubusercontent.com/draios/sysdig-cloud-scripts/master/agent_deploy/kubernetes/sysdig-agent-service.yaml -n sysdig-agent Or with Helm\n--set auditLog.enabled=true MiniShift 3.11Like OpenShift 3.11, Minishift 3.11 supports webhook backends, but the way Minishift launches the Kubernetes API server is different. Therefore, the command line arguments are somewhat different than in the instructions above.\nCopy the provided audit-policy.yaml file to the Minishift VM into the directory /var/lib/minishift/base/kube-apiserver/.\n(The file will be picked up by Minishift services running in containers because this directory is mounted into the kube API server container at /etc/origin/master.)\nCreate a Webhook Configuration File and copy it to the Minishift VM into the directory /var/lib/minishift/base/kube-apiserver/.\nModify the master configuration by adding the following to /var/lib/minishift/base/kube-apiserver/master-config.yamlon the Minishift VM, merging/updating as required.\nNote:master-config.yaml also exists in other directories such as /var/lib/minishift/base/openshift-apiserver and /var/lib/minishift/base/openshift-controller-manager/.\nYou should modify the one in kube-apiserver:\nkubernetesMasterConfig: apiServerArguments: audit-log-maxbackup: - \u0026#34;1\u0026#34; audit-log-maxsize: - \u0026#34;10\u0026#34; audit-log-path: - /etc/origin/master/k8s_audit_events.log audit-policy-file: - /etc/origin/master/audit-policy.yaml audit-webhook-batch-max-wait: - 5s audit-webhook-config-file: - /etc/origin/master/webhook-config.yaml audit-webhook-mode: - batch Restart the API server by running the following:\n(For minishift) # minishift openshift restart Once restarted, the server will route Kubernetes audit events to the Sysdig agent service.\nOpenShift 4.2, 4.3 (Legacy)By default, OpenShift 4.2/4.3 enables Kubernetes API server logs and makes them available on each master node, at the path /var/log/kube-apiserver/audit.log. However, the API server is not configured by default with the ability to create dynamic backends.\nYou must first enable the creation of dynamic backends by changing the API server configuration. You then create audit sinks to route audit events to the Sysdig agent.\nRun the following to update the API server configuration:\noc patch kubeapiserver cluster --type=merge -p \u0026#39;{\u0026#34;spec\u0026#34;:{\u0026#34;unsupportedConfigOverrides\u0026#34;:{\u0026#34;apiServerArguments\u0026#34;:{\u0026#34;audit-dynamic-configuration\u0026#34;:[\u0026#34;true\u0026#34;],\u0026#34;feature-gates\u0026#34;:[\u0026#34;DynamicAuditing=true\u0026#34;],\u0026#34;runtime-config\u0026#34;:[\u0026#34;auditregistration.k8s.io/v1alpha1=true\u0026#34;]}}}}\u0026#39; Wait for the API server to restart with the updated configuration.\nCreate a Dynamic Audit Sink.\nOnce the dynamic audit sink is created, it will route Kubernetes audit events to the Sysdig agent service.\nKopsYou will modify the cluster configuration using kops set, update the configuration using kops update, and then perform a rolling update using kops rolling-update.\nCreate a Webhook Configuration File and save it locally.\nGet the current cluster configuration and save it to a file:\nkops get cluster \u0026lt;your cluster name\u0026gt; -o yaml \u0026gt; cluster-current.yaml To ensure that webhook-config.yaml is available on each master node at /var/lib/k8s_audit, and that the kube-apiserver process is run with the required arguments to enable the webhook backend, you will edit cluster.yaml to add/modify the fileAssets and kubeAPIServer sections as follows:\napiVersion: kops.k8s.io/v1alpha2 kind: Cluster spec: ... fileAssets: - name: webhook-config path: /var/lib/k8s_audit/webhook-config.yaml roles: [Master] content: | \u0026lt;contents of webhook-config.yaml go here\u0026gt; - name: audit-policy path: /var/lib/k8s_audit/audit-policy.yaml roles: [Master] content: | \u0026lt;contents of audit-policy.yaml go here\u0026gt; ... kubeAPIServer: auditLogPath: /var/lib/k8s_audit/audit.log auditLogMaxBackups: 1 auditLogMaxSize: 10 auditWebhookBatchMaxWait: 5s auditPolicyFile: /var/lib/k8s_audit/audit-policy.yaml auditWebhookConfigFile: /var/lib/k8s_audit/webhook-config.yaml ... A simple way to do this using yq would be with the following script:\ncat \u0026lt;\u0026lt;EOF \u0026gt; merge.yaml spec: fileAssets: - name: webhook-config path: /var/lib/k8s_audit/webhook-config.yaml roles: [Master] content: | $(cat webhook-config.yaml | sed -e \u0026#39;s/^/ /\u0026#39;) - name: audit-policy path: /var/lib/k8s_audit/audit-policy.yaml roles: [Master] content: | $(cat audit-policy.yaml | sed -e \u0026#39;s/^/ /\u0026#39;) kubeAPIServer: auditLogPath: /var/lib/k8s_audit/audit.log auditLogMaxBackups: 1 auditLogMaxSize: 10 auditWebhookBatchMaxWait: 5s auditPolicyFile: /var/lib/k8s_audit/audit-policy.yaml auditWebhookConfigFile: /var/lib/k8s_audit/webhook-config.yaml EOF yq m -a cluster-current.yaml merge.yaml \u0026gt; cluster.yaml Configure Kops with the new cluster configuration:\nkops replace -f cluster.yaml Update the cluster configuration to prepare changes to the cluster:\nkops update cluster \u0026lt;your cluster name\u0026gt; --yes Perform a rolling update to redeploy the master nodes with the new files and API server configuration:\nkops rolling-update cluster --yes GKE These instructions assume you have already created a cluster and configured the gcloud and kubectl command-line programs to interact with the cluster. Note the known limitations, below.\nGKE already provides Kubernetes audit logs, but the logs are exposed using Stackdriver and are in a different format than the native format used by Kubernetes.\nTo simplify things, we have written a bridge programthat reads audit logs from Stackdriver, reformats them to match the Kubernetes-native format, and sends the logs to a configurable webhook and to the Sysdig agent service.\nCreate a Google Cloud (not Kubernetes) service account and key that has the ability to read logs:\ngcloud iam service-accounts create swb-logs-reader --description \u0026#34;Service account used by stackdriver-webhook-bridge\u0026#34; --display-name \u0026#34;stackdriver-webhook-bridge logs reader\u0026#34; gcloud projects add-iam-policy-binding \u0026lt;your gce project id\u0026gt; --member serviceAccount:swb-logs-reader@\u0026lt;your gce project id\u0026gt;.iam.gserviceaccount.com --role \u0026#39;roles/logging.viewer\u0026#39; gcloud iam service-accounts keys create $PWD/swb-logs-reader-key.json --iam-account swb-logs-reader@\u0026lt;your gce project id\u0026gt;.iam.gserviceaccount.com Create a Kubernetes secret containing the service account keys:\nkubectl create secret generic stackdriver-webhook-bridge --from-file=key.json=$PWD/swb-logs-reader-key.json -n sysdig-agent Deploy the bridge program to your cluster using the provided stackdriver-webhook-bridge.yamlfile:\nkubectl apply -f stackdriver-webhook-bridge.yaml -n sysdig-agent GKE LimitationsGKE uses a Kubernetes audit policy that emits a more limited set of information than the one recommended by Sysdig. As a result, there are several limitations when retrieving Kubernetes audit information for the Events feed and Activity Audit features in Sysdig Secure.\nRequest Object\nIn particular, audit events for config maps in GKE generally do not contain a requestObject field that contains the object being created/modified.\nPod exec does not Include command/container\nFor many Kubernetes distributions, an audit event representing a pod exec includes the command and specific container as arguments to the requestURI. For example:\n\u0026#34;requestURI\u0026#34;:\u0026#34;/api/v1/namespaces/default/pods/nginx-deployment-7998647bdf-phvq7/exec?command=bash\u0026amp;container=nginx1\u0026amp;container=nginx1\u0026amp;stdin=true\u0026amp;stdout=true\u0026amp;tty=true In GKE, the audit event is missing those request parameters.\nImplications for the Event Feed\nIf the rule condition trigger includes a field that is not available in the Kubernetes audit log provided by GKE, the rule will not trigger.\nAs a result, the following rule from k8s_audit_rules.yaml will not trigger: Create/Modify Configmap With Private Credentials. (The contents of configmaps are not included in audit logs, so the contents can not be examined for sensitive information.)\nThis will limit the information that can be displayed in the outputs of rules. For example the command=%ka.uri.param[command] output variable in the Attach/Exec Pod rule will always return N/A.\nImplications for Activity Audit\nkubectl exec elements will not be scoped to the cluster name; they will only be visible scoping by entire infrastructure\u0026quot;\nA kubectl exec item in Activity Audit will not display command or container information\nDrilling down into a kubectl exec will not provide the container activity as there is no information that allows Sysdig to correlate the kubectl exec action with an individual container.\nEKSAmazon EKS does not provide webhooks for audit logs, but it allows audit logs to be forwarded to CloudWatch.\nTo access CloudWatch logs from the Sysdig agent, proceed as follows:\nEnable CloudWatch logs for your EKS cluster.\nAllow access to CloudWatch from the worker nodes.\nAdd a new deployment that polls CloudWatch and forwards events to the Sysdig agent.\nYou can find anexample configurationthat can be implemented with the AWS UI, along with the code and the image for an example audit log forwarder. (In a production system this would be implemented as IaC scripts.)\nPlease note that CloudWatch is an additional AWS paid offering. In addition, with this solution, all the pods running on the worker nodes will be allowed to read CloudWatch logs through AWS APIs.\nAKSThese instructions assume you have already created a cluster and configured the Azure CLI and kubectl command-line programs to interact with the cluster.\nRun the following script:\ncurl -s https://raw.githubusercontent.com/sysdiglabs/aks-audit-log/master/install-aks-audit-log.sh | bash -s -- -g YOUR_RESOURCE_GROUP_NAME -c YOUR_AKS_CLUSTER_NAME Resources will be created in the same resource group as your cluster:\nStorage Account, to coordinate event consumers\nEvent Hubs, to receive audit log events\nDiagnostic setting in the cluster, to send audit log to Event Hubs\nKubernetes deployment aks-audit-log-forwarder, to forward the log to Sysdig agent\nYou can verify that the audit logs are being forwarded by executing:\nkubectl get pods -n sysdig-agent # take note of the pod name for aks-audit-log-forwarder kubectl logs aks-audit-log-forwarder-XXXX -f For additional information, optional parameters, and architecture details, seethe repository.\nTo UninstallUse the same parameters as for installation. The script will delete all created resources and configurations.\ncurl -s https://raw.githubusercontent.com/sysdiglabs/aks-audit-log/master/uninstall-aks-audit-log.sh | bash -s -- -g YOUR_RESOURCE_GROUP_NAME -c YOUR_AKS_CLUSTER_NAME RKE with Kubernetes 1.13+These instructions were verified with RKE v1.0.0 and Kubernetes v1.16.3. It should work with versions as old as Kubernetes v1.13.\nAudit support is already enabled by default, but the audit policy must be updated to provide additional granularity. These instructions enable a webhook backend pointing to the agent\u0026rsquo;s service. Dynamic audit backends are not supported as there isn\u0026rsquo;t a way to enable the audit feature flag.\nOn each Kubernetes API Master Node, create the directory /var/lib/k8s_audit.\nOn each Kubernetes API master node, copy the provided audit-policy.yaml file to to the master node into the directory /var/lib/k8s_audit. (This directory will be mounted into the API server, giving it access to the audit/webhook files.)\nCreate a Webhook Configuration File and copy it to each Kubernetes API master node, into the directory /var/lib/k8s_audit.\nModify your RKE cluster configuration cluster.yml to add extra_args and extra_binds sections to the kube-api section. Here\u0026rsquo;s an example:\nkube-api: ... extra_args: audit-policy-file: /var/lib/k8s_audit/audit-policy.yaml audit-webhook-config-file: /var/lib/k8s_audit/webhook-config.yaml audit-webhook-batch-max-wait: 5s extra_binds: - /var/lib/k8s_audit:/var/lib/k8s_audit ... This changes the command-line arguments for the API server to use an alternate audit policy and to use the webhook backend you created.\nRestart the RKE cluster via rke up.\nIKSIKS supports routing Kubernetes audit events to a single configurable webhook backend URL. It does not support dynamic audit sinks and does not support the ability to change the audit policy that controls which Kubernetes audit events are sent.\nThe instructions below were adapted from the IBM-provided documentation on how to integrate with Fluentd. It is expected that you are familiar with (or will review) the IKS tools for forwarding cluster and app logs described there.\nLimitation: The Kubernetes default audit policy generally does not include events at the Request or RequestResponse levels, meaning that any rules that look in detail at the objects being created/modified (e.g. rules using the ka.req.* and ka.resp.* fields) will not trigger. This includes the following rules:\nCreate Disallowed Pod\nCreate Privileged Pod\nCreate Sensitive Mount Pod\nCreate HostNetwork Pod\nPod Created in Kube Namespace\nCreate NodePort Service\nCreate/Modify Configmap With Private Credentials\nAttach to cluster-admin Role\nClusterRole With Wildcard Created\nClusterRole With Write Privileges Created\nClusterRole With Pod Exec Created\nThese instructions describe how to redirect from Fluentd to the Sysdig agent service.\nSet the webhook backend URL to the IP address of the sysdig-agent service:\nhttp://$(kubectl get service sysdig-agent -o=jsonpath={.spec.clusterIP} -n sysdig-agent):7765/k8s_audit Verify that the webhook backend URL has been set:\nibmcloud ks cluster master audit-webhook get --cluster \u0026lt;cluster_name_or_ID\u0026gt; Apply the webhook to your Kubernetes API server by refreshing the cluster master. It may take several minutes for the master to refresh.\nibmcloud ks cluster master refresh --cluster \u0026lt;cluster_name_or_ID\u0026gt; Minikube and KubeadmThese instructions were verified using Minikube 1.19.0. Other Minikube versions should also work as long as they run Kubernetes versions 1.11. In all cases below, \u0026ldquo;the Minikube VM\u0026rdquo; refers to the VM created by Minikube. In cases where you\u0026rsquo;re using --vm-driver=none, this means the local machine.\nCreate the directory /var/lib/k8s_audit on the master node. (On Minikube, it must be on the Minikube VM.)\nFor Kubernetes 1.11 to 1.18: Copy the provided audit-policy.yaml file into the directory /var/lib/k8s_audit. (This directory will be mounted into the API server, giving it access to the audit/webhook files. On Minikube, it must be on the Minikube VM.)\nFor Kubernetes 1.19: Use this audit-policy.yaml file instead.\n[Create a Webhook Configuration File](/en/install-audit-logging/ #create-a-webhook-configuration-file) and copy it to each Kubernetes API master node, into the directory /var/lib/k8s_audit.\nModify the Kubernetes API server manifest at /etc/kubernetes/manifests/kube-apiserver.yaml, adding the following command-line arguments:\n--audit-log-path=/var/lib/k8s_audit/k8s_audit_events.log --audit-policy-file=/var/lib/k8s_audit/audit-policy.yaml --audit-log-maxbackup=1 --audit-log-maxsize=10 --audit-webhook-config-file=/var/lib/k8s_audit/webhook-config.yaml --audit-webhook-batch-max-wait=5s Command-line arguments are provided in the container spec as arguments to the program /usr/local/bin/kube-apiserver. The relevant section of the manifest will look like this:\nspec: containers: - command: - kube-apiserver --allow-privileged=true --anonymous-auth=false --audit-log-path=/var/lib/k8s_audit/audit.log --audit-policy-file=/var/lib/k8s_audit/audit-policy.yaml --audit-log-maxbackup=1 --audit-log-maxsize=10 --audit-webhook-config-file=/var/lib/k8s_audit/webhook-config.yaml --audit-webhook-batch-max-wait=5s ... Modify the Kubernetes API server manifest at /etc/kubernetes/manifests/kube-apiserver.yamlto add a mount of /var/lib/k8s_audit into the kube-apiservercontainer. The relevant sections look like this:\nvolumeMounts: - mountPath: /var/lib/k8s_audit/ name: k8s-audit readOnly: true ... volumes: - hostPath: path: /var/lib/k8s_audit type: DirectoryOrCreate name: k8s-audit ... Modifying the manifest restart the Kubernetes API server automatically. Once restarted, it will route Kubernetes audit events to the Sysdig agent\u0026rsquo;s service.\nPrepare WebhookMost of the platform-specific instructions will use one of these methods.\nCreate a Webhook Configuration FileSysdig provides a templated resource file that sends audit events to an IP associated with the Sysdig agent service, via port 7765.\nIt is \u0026ldquo;templated\u0026rdquo; in that the actual IP is defined in an environment variable AGENT_SERVICE_CLUSTERIP, which can be plugged in using a program like envsubst.\nDownload webhook-config.yaml.in.\nRun the following to fill in the template file with the ClusterIP IP address associated with the sysdig-agent service you created, either when installing the agent or in the prereq step:\nAGENT_SERVICE_CLUSTERIP=$(kubectl get service sysdig-agent -o=jsonpath={.spec.clusterIP} -n sysdig-agent) envsubst \u0026lt; webhook-config.yaml.in \u0026gt; webhook-config.yaml Note: Although service domain names like sysdig-agent.sysdig-agent.svc.cluster.local can not be resolved from the Kubernetes API server (they\u0026rsquo;re typically run as pods but not really a part of the cluster), the ClusterIPs associated with those services are routable.\n(BETA) Script to Automate Configuration ChangesAs a convenience, Sysdig has created a script: enable-k8s-audit.sh, which performs the necessary steps for enabling audit log support for all Kubernetes distributions described above, except EKS.\nYou can run it via:bash enable-k8s-audit.sh \u0026lt;distribution\u0026gt; where \u0026lt;distribution\u0026gt; is one of the following:\nminishift-3.11 gke iks rke-1.13 kops minikube-1.13 Run from the sysdig-cloud-scripts/k8s_audit_configdirectory.\nIn some cases, it may prompt for the GCE project ID, IKS cluster name, etc..\nFor Minikube/OpenShift-3.11/Minishift 3.11, it will use ssh/scpto copy files to and run scripts on the API master node. Otherwise, it should be fully automated.\nTest the IntegrationTo test that Kubernetes audit events are being properly passed to the agent, you can do any of the following:\nEnable the All K8s Object Modifications policy and create a deployment, service, configmap, or namespace to see if the events are recorded and forwarded.\nEnable other policies, such as Suspicious K8s Activity,if and test them.\nYou can use the falco-event-generator Docker image to generate activity that maps to many of the default rules/policies provided in Sysdig Secure. You can run the image via a command line like the following:\ndocker run -v $HOME/.kube:/root/.kube -it falcosecurity/falco-event-generator k8s_audit This will create resources in a namespace falco-event-generator.\nSee the native Falco documentation for more information about this tool.\nAdvanced Configuration for Helm InstallationProxy UsageThere are several configuration parameters for the proxy usage\nTwo involved components webhook.* and scanner.*; reference to the first for communications to the Sysdig backend, while second communicates with the registry from where to pull the image to be scanned. configuration values *.httpProxy, *.httpsProxy and *.noProxy. Make sure to use at least https version for Sysdig Secure Backend. If your Proxy is served with TLS:\nThe URL for those *.httpProxy and *.httpsProxy must be https:// If using a self-signed certificate you will need to also configure one of the following two options Set the verifySSL=false parameter Or set *.ssl.ca.cert for both components webhook and scanner On-Prem SettingsSysdig On-Prem installations might use a TLS self-signed server certificate or one from an untrusted CA, so it requires an extra configuration.\nIgnore TLS certificate verificationUse the following command to deploy in an on-prem and ignore the untrusted certificate using verifySSL=false:\n$ helm upgrade --install sysdig-admission-controller sysdig/admission-controller \\ --create-namespace -n sysdig-admission-controller \\ --set clusterName=CLUSTER_NAME \\ --set sysdig.secureAPIToken=SECURE_API_TOKEN \\ --set verifySSL=false Install with Custom CADeploy admission-controller with a custom CA using the following command.\n$ helm upgrade --install sysdig-admission-controller sysdig/admission-controller \\ --create-namespace -n sysdig-admission-controller \\ --set clusterName=CLUSTER_NAME \\ --set sysdig.secureAPIToken=SECURE_API_TOKEN \\ --set webhook.ssl.ca.cert=YOUR_CA_CERT_AS_PEM_ENCODED \\ --set scanner.ssl.ca.cert=YOUR_CA_CERT_AS_PEM_ENCODED The custom CA certificate is added to the trusted certificates store.\nTroubleshooting Helm InstallationAlert Is Not Triggered for an Event with the ka.verb=get ConditionThough Kubernetes Extensible Admission Controller webhook support it, Sysdig Admission Controller does only handle CREATE, UPDATE, DELETE and CONNECT type of events. Also, beware Kubernetes apiGroups are scoped.\nIf required, you can use the legacy Sysdig Kubernetes Audit Log which do support additional verbs.\nSwitching to debug VerboseIf you have used helm to install, you can edit the helm values.yaml to set webhook.logLevel=debug Alternatively, you can edit the webhook ConfigMap and add the LOG_LEVEL=debug key-value pair and restart the webhook.\nkubectl edit configmaps -n sysdig-admission-controller sysdig-admission-controller-webhook kubectl rollout restart deployment -n sysdig-admission-controller sysdig-admission-controller-webhook Receiving Many TLS handshake ErrorsYou observe this when DEBUG is enabled; however, Admission Controller works as expected. These calls are some non-Sysdig direct calls to the Admission Controller without TLS, which raises this informational log by the Go internal library.\nAdmission Controller Is Slow and Cluster Is Not Scaling in a GKE Cluster with Private NetworkGKE clusters run the Kubernetes API outside of the cluster. If Private Network is enabled, the Kubernetes API might be unable to reach the Admission Controller webhook that validates each API request, so eventually every API request times out and is processed, but the performance is impacted in the process. In such cases, you might observe the following error:\n\u0026#34;Failed calling webhook, failing open audit.secure.sysdig.com: failed calling webhook \u0026#34;audit.secure.sysdig.com\u0026#34;: Post \u0026#34;https://sysdig-ac-webhook.sysdig-agent.svc:443/k8s-audit?timeout=10s \u0026lt;https://sysdig-ac-webhook.sysdig-agent.svc/k8s-audit?timeout=10s\u0026gt;\u0026#34;: context canceled\u0026#34; As specified in GKE Private Cluster Webhook Timeouts, the default firewall configuration does not allow TCP connections for ports other than 443 and 10250. Admission Controller\u0026rsquo;s webhook run on 5000 TCP port, so you need to enable a new rule that allows the Control Plane\u0026rsquo;s network to access it.\nFollow the instructions in GKE-Adding firewall rules to cluster to enable inbound connections to our webhook.\nReceiving Permission Denied ErrorSome users on old versions of GKE reported that the permissions to access serviceAccount token, mounted in the filesystem, was set to 0600 permissions, not allowing the pods to actually read from it. In such cases, you might see the following error;\n\u0026#34;error getting the cluster id from kubernetes: open /var/run/secrets/kubernetes.io/serviceaccount/token:permission denied Changing the securityContext.fsGroup to the value 65534 on the pod is recommended. You can specify this in the helm chart with the following parameter:\n--set webhook.podSecurityContext.fsGroup=65534 Receiving Readiness Probe Errors and Failing to Startup13m Warning FailedComputeMetricsReplicas horizontalpodautoscaler/sysdig-admission-controller-webhook invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server could not find the requested resource (get pods.metrics.k8s.io) HorizontalAutoScaler requires your kubernetes cluster to be able to use metrics API, which in some lightweight installations, such as minikube, must be enabled through a plugin.\nFor minikube, enable metric-server plugin as follows:\nminikube addons list | grep metrics-server $ minikube addons enable metrics-server Receiving Unverified Certificate ErrorSysdig installation is made with an unverified certificate, such as self-signed, SECURE_URL being https, you will see the following error:\n\u0026#34;x509: certificate signed by unknown authority\u0026#34; To fix this issue, add --set verifySSL=false to your installation parameters.\nKubernetes Audit Events Are not Generated for EKS Cluster Deployed Using TerraformIf Kubernetes Audit Events are not generated after installation of Admission Controller on EKS cluster that was deployed by using EKS terraform module, additional node security group rule to allow traffic to port TCP/5000 might need to be added for the traffic originating from EKS cluster Control Plane towards webhook deployment of Admission Controller. See the example of the Terraform code snippet that needs to be added to the EKS module resource.\n# Additional node security group rules to allow access from the control plane to the Sysdig Admission Controller webhook port node_security_group_additional_rules = { ingress_allow_access_from_control_plane_to_sysdig_ac = { type = \u0026#34;ingress\u0026#34; protocol = \u0026#34;tcp\u0026#34; from_port = 5000 to_port = 5000 source_cluster_security_group = true description = \u0026#34;Allow access from control plane to webhook port of Sysdig Admission Controller\u0026#34; } } Next StepsSee results in the Sysdig Secure UI and work with the relevant policies and rules, as described in Kubernetes Audit Logging.\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-audit-logging/"},{"id":326,"title":"Enable Prometheus Native Service Discovery","content":"For metric collection, a lightweight Prometheus server, named promscrape, is directly embedded into the Sysdig agent to facilitate metric collection. Promscrape supports filtering and relabeling targets, instances, and jobs and identify them using the custom jobs configured in the prometheus.yaml file. The latest versions of Sysdig agent (above v12.0.0) by default identify the processes that expose Prometheus metric endpoints on its own host and send it to the Sysdig collector for storing and further processing. On older versions of Sysdig agent, you enable these features by configuring dragent.yaml.\nWorking with PromscrapePromscrape is a lightweight Prometheus server that is embedded with the Sysdig agent. Promscrape scrapes metrics from Prometheus endpoints and sends them for storing and processing.\nPromscrape has two versions: Promscrape V1 and Promscrape V2.\nPromscrape V2\nPromscrape itself discovers targets by using the standard Prometheus configuration (native Prometheus service discovery), allowing the use of relabel_configs to find or modify targets. An instance of promscrape runs on every node that is running a Sysdig agent and is intended to collect metrics from local as well as remote targets specified in the prometheus.yaml file. The prometheus.yaml file you create is shared across all such nodes.\nPromscrape V2 is enabled by default on Sysdig agent v12.5.0 and above. On older versions of Sysdig agent, you need to manually enable Promscrape V2, which allows for native Prometheus service discovery, by setting the prom_service_discovery parameter to true in dragent.yaml.\nPromscrape V1\nSysdig agent discovers scrape targets through the Sysdig process_filter rules. For more information, see Process Filter.\nAbout Promscrape V2Supported FeaturesPromscrape V2 supports the following native Prometheus capabilities:\nRelabeling: Promscrape V2 supports Prometheus native relabel_config and metric_relabel_configs. Relabel configuration enables the following:\nDrop unnecessary metrics or unwanted labels from metrics\nEdit the label format of the target before scraping the labels\nSample format: In addition to the regular sample format (metrics name, labels, and metrics reading), Promscrape V2 includes metrics type (counter, gauge, histogram, summary) to every sample sent to the agent.\nScraping configuration: Promscrape V2 supports all types of scraping configuration, such as federation, blackbox-exporter, and so on.\nLabel mapping: The metrics can be mapped to their source (pod, process) by using the source labels which in turn map certain Prometheus label names to the known agent tags.\nUnsupported Features Promscrape V2 does not support calculated metrics.\nPromscrape V2 does not support cluster-wide features such as recording rules and alert management.\nService discovery configurations in Promscrape V1 (process_filter) and Promscrape V2 (prometheus.yaml) are incompatible and non-translatable.\nPromscrape V2 collects metrics from both local and remote targets specified in the prometheus.yaml file and therefore it does not make sense to configure promscrape to scrape remote targets, because you will see metrics duplication in this case.\nPromscrape V2 does not have the cluster view and therefore it ignores the configuration of recording rules and alerts, which is used in the cluster-wide metrics collection. Therefore, the following Prometheus Configurations are not supported\nalert_relabel_configs\nalertmanager_config\nRecording Rules\nremote_write\nremote_read\nSysdig uses __HOSTNAME__, which is not a standard Prometheus keyword.\nEnable Promscrape V2 on Older Versions of Sysdig AgentTo enable Prometheus native service discovery on agent versions prior to 11.2:\nOpen dragent.yaml file.\nSet the following Prometheus Service Discovery parameter to true:\nprometheus: prom_service_discovery: true If true, promscrape.v2 is used. Otherwise, promscrape.v1 is used to scrape the targets.\nRestart the agent.\nCreate Custom JobsPrerequisitesEnsure the following features are enabled:\nMonitoring Integration Promscrape V2 If you are using Sysdig agent v12.0.0 or above, these features are enabled by default.\nPrepare Custom JobYou set up custom jobs in the Prometheus configuration file to identify endpoints that expose Prometheus metrics. Sysdig agent uses these custom jobs to scrape endpoints by using promscrape, the lightweight Prometheus server embedded in it.\nGuidelines Ensure that targets are scraped only by the agent running on the same node as the target. You do this by adding the host selection relabeling rules.\nUse the sysdig specific relabeling rules to automatically get the right workload labels applied.\nExample Prometheus Configuration fileThe prometheus.yaml file comes with a default configuration for scraping the pods running on the local node. This configuration also includes the rules to preserve pod UID and container name labels for further correlation with Kubernetes State Metrics or Sysdig native metrics.\nHere is an example prometheus.yaml file that you can use to set up custom jobs.\nglobal: scrape_interval: 10s scrape_configs: - job_name: \u0026#39;my_pod_job\u0026#39; sample_limit: 40000 tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: # Look for pod name starting with \u0026#34;my_pod_prefix\u0026#34; in namespace \u0026#34;my_namespace\u0026#34; - action: keep source_labels: [__meta_kubernetes_namespace,__meta_kubernetes_pod_name] separator: / regex: my_namespace/my_pod_prefix.+ # In those pods try to scrape from port 9876 - source_labels: [__address__] action: replace target_label: __address__ regex: (.+?)(\\\\:\\\\d)? replacement: $1:9876 # Trying to ensure we only scrape local targets # __HOSTIPS__ is replaced by promscrape with a regex list of the IP addresses # of all the active network interfaces on the host - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ # Target only running pods - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name Default Scrape JobIf Monitoring Integration is not enabled for you and you still want to automatically collect metrics from pods with the Prometheus annotations set (prometheus.io/scrape=true), add the following default scrape job to your prometheus.yaml file:\n- job_name: \u0026#39;k8s-pods\u0026#39; sample_limit: 40000 tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: # Trying to ensure we only scrape local targets # __HOSTIPS__ is replaced by promscrape with a regex list of the IP addresses # of all the active network interfaces on the host - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] target_label: __metrics_path__ regex: (.+) - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name Default Prometheus Configuration FileHere is the default prometheus.yaml file.\nglobal: scrape_interval: 10s scrape_configs: - job_name: \u0026#39;k8s-pods\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: # Trying to ensure we only scrape local targets # __HOSTIPS__ is replaced by promscrape with a regex list of the IP addresses # of all the active network interfaces on the host - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] regex: true - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running # Drop for nginx-ingress - action: drop source_labels: - __meta_kubernetes_pod_container_name regex: \u0026#39;controller|nginx-ingress-controller\u0026#39; # Drop for ceph - action: drop source_labels: [__meta_kubernetes_pod_container_name, __meta_kubernetes_pod_annotation_prometheus_io_port] separator: ; regex: (chown-container-data-dir|log-collector|mgr|watch-active);9283 # Drop for consul - action: drop source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port] regex: \u0026#39;20200|8500\u0026#39; # Drop for istio - action: replace source_labels: [__meta_kubernetes_pod_annotationpresent_sidecar_istio_io_status] target_label: __tmp_pod_has_istio regex: \u0026#39;true\u0026#39; replacement: \u0026#39;true\u0026#39; - action: drop source_labels: [__tmp_pod_has_istio, __meta_kubernetes_pod_container_name] regex: \u0026#39;true;(discovery)|(.{0}$)\u0026#39; # Drop for opa - action: drop source_labels: - __meta_kubernetes_pod_container_name regex: \u0026#39;manager.*\u0026#39; # Drop for kafka - action: drop source_labels: - __meta_kubernetes_pod_container_name regex: \u0026#39;kafka-jmx-exporter|kafka-exporter\u0026#39; # Drop for keda - action: drop source_labels: - __meta_kubernetes_pod_container_name regex: \u0026#39;keda-operator-metrics-apiserver\u0026#39; # Drop for ntp - action: drop source_labels: - __meta_kubernetes_pod_container_name regex: \u0026#39;ntp-exporter\u0026#39; # Drop for openshift-state-metrics - action: drop source_labels: [__meta_kubernetes_pod_container_name] regex: \u0026#39;openshift-state-metrics\u0026#39; # Drop for portworx - action: drop source_labels: [__meta_kubernetes_pod_container_name] regex: \u0026#39;portworx\u0026#39; # Drop for rabbitmq - action: drop source_labels: [__meta_kubernetes_pod_container_name] regex: \u0026#39;(rabbitmq|prepare-plugins-dir)\u0026#39; - action: drop source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_port] regex: \u0026#39;15691\u0026#39; # Drop for Sysdig Admission Controller - action: drop source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_prometheus_io_port regex: admission-controller;(8080|5000) - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path] target_label: __metrics_path__ regex: (.+) - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name Understand the Prometheus SettingsScrape IntervalThe default scrape interval is 10 seconds. However, the value can be overridden per scraping job. The scrape interval configured in the prometheus.yaml is independent of the agent configuration.\nPromscrape V2 reads prometheus.yaml and initiates scraping jobs.\nThe metrics from targets are collected per scrape interval for each target and immediately forwarded to the agent. The agent sends the metrics every 10 seconds to the Sysdig collector. Only those metrics that have been received since the last transmission are sent to the collector. If a scraping job for a job has a scrape interval longer than 10 seconds, the agent transmissions might not include all the metrics from that job.\nHostname Selection__HOSTIPS__ is replaced by the host IP addresses. Selection by the host IP address is preferred because of its reliability.\n__HOSTNAME__ is replaced with the actual hostname before promscrape starts scraping the targets. This allows promscrape to ignore targets running on other hosts.\nRelabeling ConfigurationThe default Prometheus configuration file contains the following two relabeling configurations:\n- action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name These rules add two labels, sysdig_k8s_pod_uid and sysdig_k8s_pod_container_name to every metric gathered from the local targets, containing pod ID and container name respectively. These labels will be dropped from the metrics before sending them to the Sysdig collector for further processing.\nConfigure Prometheus Configuration File Using the Agent ConfigmapHere is an example for setting up the prometheus.yaml file using the agent configmap:\napiVersion: v1 data: dragent.yaml: | new_k8s: true k8s_cluster_name: your-cluster-name metrics_excess_log: true 10s_flush_enable: true app_checks_enabled: false use_promscrape: true promscrape_fastproto: true prometheus: enabled: true prom_service_discovery: true log_errors: true max_metrics: 200000 max_metrics_per_process: 200000 max_tags_per_metric: 100 ingest_raw: true ingest_calculated: false snaplen: 512 tags: role:cluster prometheus.yaml: | global: scrape_interval: 10s scrape_configs: - job_name: \u0026#39;haproxy-router\u0026#39; basic_auth: username: USER password: PASSWORD tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: # Trying to ensure we only scrape local targets # We need the wildcard at the end because in AWS the node name is the FQDN, # whereas in Azure the node name is the base host name - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;default/router-1-.+\u0026#39; # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name kind: ConfigMap metadata: labels: app: sysdig-agent name: sysdig-agent namespace: sysdig-agent ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/custom-integrations/enable-prometheus-native-service-discovery/"},{"id":327,"title":"Event Sources","content":"Different source values are applicable to different Event Types.\nSources can be used to narrow down the set of events to be considered in Event Alerts and in setting up an Event Overlay.\nAlert Event and Sysdig Event SourcesAlert Events that are triggered by Sysdig are added to the event feed. Since Alert Events are determined through alert configuration, they are not populated with a source value. The same applies to Sysdig Events: since they come from the system itself, the source field is empty.\nInfrastructure Event SourcesInfrastructure events have different source values based on their origin:\nFor Infrastructure Events, the source field will have a different value based on the service the event is drawn from. For example, the source will be:\ndocker for Docker events containerd for ContainerD events kubernetes for Kubernetes events Custom Event SourcesCustom events ingested through the Events API will have the source field set to api. You can view these tags on the Event overlay.\nYou can customize this value by specifying it in the ingestion payload, in two different ways:\nAs a source field in the JSON event object\nFor example, the following call will ingest an event with a customized source equal to jenkins:\n#!/bin/bash SDC_ACCESS_TOKEN=\u0026#39;626abc7-YOUR-TOKEN-HERE-3a3ghj432\u0026#39; ENDPOINT=\u0026#39;app.sysdigcloud.com\u0026#39; curl -X POST -s https://${ENDPOINT}/api/v2/events \\ -H \u0026#39;Content-Type: application/json; charset=UTF-8\u0026#39; \\ -H \u0026#39;Accept: application/json, text/javascript, */*; q=0.01\u0026#39; -H \u0026#34;Authorization: Bearer ${SDC_ACCESS_TOKEN}\u0026#34; \\ --data-binary \u0026#39; {\u0026#34;event\u0026#34;: {\u0026#34;name\u0026#34;: \u0026#34;Jenkins - start wordpress deploy\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;deploy\u0026#34;, \u0026#34;severity\u0026#34;: \u0026#34;MEDIUM\u0026#34;, \u0026#34;source\u0026#34;: \u0026#34;jenkins\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;host.hostName = \\\u0026#34;ip-10-1-1-1\\\u0026#34; and build = \\\u0026#34;89\\\u0026#34;\u0026#34;}} \u0026#39; sleep 5 Note: You will need to replace the URL in the line ENDPOINT='app.sysdigcloud.com' with an endpoint that matches your subscription. See SaaS Regions and IP Ranges for further details.\nAs a tag with key source in the tags section of the event object\nFor example, the following call will ingest an event with a customised source equal to jenkins:\n#!/bin/bash SDC_ACCESS_TOKEN=\u0026#39;626abc7-YOUR-TOKEN-HERE-3a3ghj432\u0026#39; ENDPOINT=\u0026#39;app.sysdigcloud.com\u0026#39; curl -X POST -s https://${ENDPOINT}/api/v2/events \\ -H \u0026#39;Content-Type: application/json; charset=UTF-8\u0026#39; \\ -H \u0026#39;Accept: application/json, text/javascript, */*; q=0.01\u0026#39; -H \u0026#34;Authorization: Bearer ${SDC_ACCESS_TOKEN}\u0026#34; \\ --data-binary \u0026#39; {\u0026#34;event\u0026#34;: {\u0026#34;name\u0026#34;: \u0026#34;Jenkins - start wordpress deploy\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;deploy\u0026#34;, \u0026#34;severity\u0026#34;: \u0026#34;MEDIUM\u0026#34;, \u0026#34;tags\u0026#34;: {\u0026#34;source\u0026#34; : \u0026#34;jenkins\u0026#34;}, \u0026#34;scope\u0026#34;: \u0026#34;host.hostName = \\\u0026#34;ip-10-1-1-1\\\u0026#34; and build = \\\u0026#34;89\\\u0026#34;\u0026#34;}}\u0026#39; sleep 5 ","url":"https://docs.sysdig.com/en/sysdig-monitor/event-sources/"},{"id":328,"title":"Filter Processes","content":" Wanting to alert reliably whenever a given process goes down. The total number of processes can exceed the reporting limit; when that happens, some processes are not reported. In this case, an unreported process could be misinterpreted as being \u0026ldquo;down.\u0026rdquo; Specify a filter for 30-40 processes to guarantee that they will always be reported.\nWanting to limit the number of noisy but inessential processes being reported, for example: sed, awk, grep, and similar tools that may be used infrequently.\nWanting to prioritize workload-specific processes, perhaps from integrated applications such as NGINX, Supervisord or PHP-FPM.\nNote that you can report on processes and containers independently; the including/excluding of one does not affect the including/excluding of the other.\nPrerequisitesThis feature requires the following Sysdig component versions: Sysdig agent version 0.91 or higher\nFor on-premises installations: version 3.2.0.2540 or higher\nUnderstand Process Filtering BehaviorBy default, processes are reported according to internal criteria such as resource usage (CPU/memory/file and net IO) and container count.\nIf you choose to enable process filtering, processes in the include list will be given preference over other internal criteria.\nProcesses are filtered based on a standard priority filter description already used in Sysdig yaml files. It is comprised of -include and -exclude statements which are matched in order, with evaluation ceasing with the first matched statement. Statements are considered matched if EACH of the conditions in the statement is met.\nUse Process FilteringEdit dragent.yaml per the following patterns to implement the filtering you need.\nProcess Condition Parameters and RulesThe process: condition parameters and rules are described below.\nName Value Description app_checks_always_send: true/false Legacy config that causes the agent to emit any process with app check. With process filtering, this translates to an extra \u0026ldquo;include\u0026rdquo; clause at the head of the process filter which matches a process with any app check, thereby overriding any exclusions. Still subject to limit. flush_filter: Definition of process filter to be used if flush_filter_enabled == true. Defaults to -include all flush_filter_enabled: true/false Defaults to false (default process reporting behavior). Set to true to use the rest of the process filtering options. limit: N (chosen number) Defines the approximate limit of processes to emit to the backend, within 10 processes or so. Default is 250 processes. top_n_per_container: N (chosen number) Defines how many of the top processes per resource category per emitted container to report after included processes. Still subject to limit. Defaults to 1. top_n_per_host: N (chosen number) Defines how many of the top processes per resource category per host are reported before included processes. Still subject to limit. Defaults to 1. The process: Condition Parameters\nRules\ncontainer.image: my_container_image Validates whether the container image associated with the process is a wild card match of the provided image name\ncontainer.name: my_container_name Validates whether the container name associated with the process is a wild card match of the provided image name\ncontainer.label.XYZ: value Validates whether the label XYZ of the container associated with the process is a wildcard match of the provided value\nprocess.name: my_process_name Validates whether the name of the process is a wild card match of the provided value\nprocess.cmdline: value Checks whether the executable name of a process contains the specified value, or any argument to the process is a wildcard match of the provided value\nappcheck.match: value Checks whether the process has any appcheck which is a wildcard match of the given value\nall Matches all processes, but does not whitelist them, nor does it blacklist them. If no filter is provided, the default is -include all. However, if a filter is provided and no match is made otherwise, then all unmatched processes will be blacklisted. In most cases, the definition of a process filter should end with -include: all.\nExamplesBlock All Processes from a ContainerBlock all processes from a given container. No processes from some_container_name will be reported.\nprocess: flush_filter_enabled: true flush_filter: - exclude: container.name: some_container_name - include: all Prioritize Processes from a ContainerSend all processes from a given container at high priority.\nprocess: flush_filter_enabled: true flush_filter: - include: container.name: some_container_name - include: all Prioritize \u0026ldquo;java\u0026rdquo; Processes {#prioritize-\u0026ldquo;java\u0026rdquo;-processes}Send all processes that contain \u0026ldquo;java\u0026rdquo; in the name at high priority.\nprocess: flush_filter_enabled: true flush_filter: - include: process.name: java - include: all Prioritize \u0026ldquo;java\u0026rdquo; Processes from a Particular Container {#prioritize-\u0026ldquo;java\u0026rdquo;-processes-from-a-particular-container}Send processes containing \u0026ldquo;java\u0026rdquo; from a given container at high priority.\nprocess: flush_filter_enabled: true flush_filter: - include: container.name: some_container_name process.name: java - include: all Prioritize \u0026ldquo;java\u0026rdquo; Processes not in a Particular Container {#prioritize-\u0026ldquo;java\u0026rdquo;-processes-not-in-a-particular-container}Send all processes that contain \u0026ldquo;java\u0026rdquo; in the name that are not in container some_container_name.\nprocess: flush_filter_enabled: true flush_filter: - exclude: container.name: some_container_name - include: process.name: java - include: all Prioritize \u0026ldquo;java\u0026rdquo; Processes even from an Excluded Container {#prioritize-\u0026ldquo;java\u0026rdquo;-processes-even-from-an-excluded-container}Send all processes containing \u0026ldquo;java\u0026rdquo; in the name. If a process does not contain \u0026ldquo;java\u0026rdquo; in the name and if the container within which the process runs is named some_container_name, then exclude it.\nNote that each include/exclude rule is handled sequentially and hierarchically so that even if the container is excluded, it can still report \u0026ldquo;java\u0026rdquo; processes.\nflush_filter: - flush_filter_enabled: true - include: process.name: java - exclude: container.name: some_container_name - include: all Prioritize \u0026ldquo;java\u0026rdquo; Processes and \u0026ldquo;sql\u0026rdquo; Processes from Different Containers {#prioritize-\u0026ldquo;java\u0026rdquo;-processes-and-\u0026ldquo;sql\u0026rdquo;-processes-from-different-containers}Send Java processes from one container and SQL processes from another at high priority.\nprocess: flush_filter: - flush_filter_enabled: true - include: container.name: java_container_name process.name: java - include: container.name: sql_container_name process.name: sql - include: all Report ONLY Processes in a Particular ContainerOnly send processes running in a container with a given label.\nprocess: flush_filter: - flush_filter_enabled: true - include: container.label.report_processes_from_this_container_example_label: true - exclude: all ","url":"https://docs.sysdig.com/en/sysdig-monitor/filter-processes/"},{"id":329,"title":"Forwarding to Cribl","content":"Prerequisites The events for forwarding originate from region-specific IPs.\nFor the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to forward events to Cribl.\nCreate an HTTP source on Cribl and copy the agent HTTPs URL.\nConfigure Standard Event ForwardingTo forward event data to Cribl:\nLog in to Sysdig Secure as Admin and navigate to Integrations \u0026gt; Add Integrations.\nSearch and choose Webhook.\nConfigure the mandatory parameters:\nIntegration Name: Define an integration name.\nEndpoint: Enter a Cribl HTTP agent URL.\nThe URL is similar to https://\u0026lt;yoursite\u0026gt;.cribl.cloud:10080/cribl/_bulk.\nAuthentication: Configure authentication if you previously set an authentication method in Cribl.\nNo authentication required by default.\nData to Send: Select the types of Sysdig data to forward.\nThe available list depends on the Sysdig features and products you have enabled.\nSelect if you want to Allow insecure connections, such as invalid or self-signed certificate on the receiving side.\nToggle the Enabled switch as necessary. You will need to Test Integration with the button below before enabling the integration.\nClick Save.\nView Events in Cribl Log in to your Cribl Streams account.\nNavigate to Worker Groups \u0026gt; Default \u0026gt; Routing.\nSelect the HTTP source icon and click Capture.\nView how the data is ingested in real time. Here is an example of how policy events forwarded from Sysdig Secure are displayed on the Cribl UI:\n","url":"https://docs.sysdig.com/en/sysdig-secure/event-forwarding-to-cribl/"},{"id":330,"title":"Host Shield for Windows Release Notes","content":"0.17.0 May 26, 2026 Supported shield chart version: 1.41.0 Supported Agent version: 2.3.0 Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2026-39836 CVE-2026-33997 CVE-2026-34040 CVE-2026-33814 CVE-2026-42499 CVE-2026-39820 0.16.0 April 28, 2026 Supported shield chart version: 1.36.0 Supported Agent version: 2.3.0 Enhancements You can now define tags directly in the Windows MSI Wizard, both through the UI and via the CLI (for example, TAGS=env:prod,team:backend), making it easier to label and organize your hosts during installation. For more information, see Tags in Windows Host Bug Fixes Fixed a bug where Host Posture sent requests incompatible with on-prem \u0026lt; 7.7.0, preventing Host Posture scans from being scheduled. Fixed a bug where Host Posture could send duplicated results for the same host, preventing Host Posture evaluation from being performed. 0.15.0 March 31, 2026 Supported shield chart version: 1.32.0 Supported Agent version: 2.3.0 Bug Fixes Fixed an issue causing KSPM Analyzer to log the Sysdig backend access key when log level was set to debug. Fixed a bug which could cause host scanner to use a wrong socket path when connecting to the container runtime. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2023-46129 CVE-2021-20329 0.14.0 February 24, 2026 Supported shield chart version: 1.29.0 Supported Agent version: 2.3.0 Enhancements Shield can load the access key from the system environment variable. The access key must be stored in the SYSDIG_HOST_SHIELD_SYSDIG_ENDPOINT__ACCESS_KEY environment variable. Vulnerability FixesThis release addresses the following security vulnerabilities:\nCVE-2025-61732 CVE-2025-68121 0.13.0 January 27, 2026 Supported shield chart version: 1.26.0 Supported Agent version: 2.2.4 Defect Fixes Fixed metadata retrieval in IBM standalone virtual server instances. ","url":"https://docs.sysdig.com/en/release-notes/windows-host-shield-release-notes/"},{"id":331,"title":"IaC Policy Controls","content":"You can evaluate IaC resources using the same Posture policies and controls as CSPM.\nThe set of policies that apply when evaluating a folder in a repository is defined by creating Zones.\nYou can navigate in the product to Policies \u0026gt; Posture Policies to find the list of requirements and controls for each policy.\n","url":"https://docs.sysdig.com/en/sysdig-secure/iac-policy-controls/"},{"id":332,"title":"IAM Policies","content":" Deprecation Notice Upcoming Changes to Sysdig Product Line\nThe legacy Identity pages are now deprecated and will be phased out over a transition period. During this time, both the legacy and new experiences will remain available. We encourage you to start using the new Identity Overview and Findings pages to become familiar with the updated experience.\nFilter and SortSortable ColumnsUnused Permission CriticalityValues: Critical, High, Medium, Low`\nUnused Permission Criticality focuses on unused permissions, while Permission Criticality looks at all permissions. Unused Permission Criticality is designed to help you achieve Least Permissive access.\nRiskValues: Critical, High, Medium, Low\nThis is a calculation of risk based on all permissions. See Understanding Risk Scoring for more information.\n% of Unused PermissionsThis shows the number of unused permissions per total permissions, shown as a percentage graph.\nWhen remediating, immediately target the policies with the greatest exposure and refine them according to the suggestions.\nAdditional information in the Detail Drawers.\nPolicy TypeThese reflect the policy types from AWS. See also the AWS documentation of policy types.\nAWS Managed: A standalone policy that is created and administered by AWS. Customer: Customer-managed standalone policies in the user\u0026rsquo;s own AWS account that the user can attach to principal entities, and change and update freely. Inline: An AWS policy created for a single IAM identity (a user, group, or role). Inline policies maintain a strict one-to-one relationship between a policy and an identity. SharedThe number of IAM entities (users, roles, and/or groups) assigned to a policy. When remediating, focus on the policies affecting the greatest number of entities and make a global policy change.\nHighest AccessSee Understand Highest Access.\nValues:\nAdmin: Admin access granted Write: Write access granted Read: Read access granted Empty Access: No permissions are granted at all FindingsPolicies can be listed as Unused on this page. It is recommended to delete Unused policies if possible.\nAvailable Filters Search: Free text search on terms in the resource name Unused Permission Criticality: By severity Cloud Accounts: Account name/number by the cloud provider (e.g. AWS) Access Categories: Admin, Write, Read, or Empty Access Policy Types: AWS-Managed, Customer, Inline Findings: Unused indicates unused policies Analyze and RemediateTo reduce the entitlements globally for a particular policy:\nClick on a policy name to open the detail drawer and open tabs as needed.\nUnder the Remediation Strategies tab, click Optimize this IAM Policy with a subset of only used permissions to resolve critical permissions issues on the policy.\nSee Understand the Suggested Policy Changes.\nYou can follow the instructions, or open the adjusted policy directly in the AWS console.\nIf you have configured the Jira Ticketing integration with Sysdig Secure, you can also open a Jira ticket to optimize the policy code.\nSee Jira Ticketing integration.\nManage Policies with Detail DrawersThe IAM Policies page organizes everything around the policy. Click on a policy name to open the details drawer and subtabs.\nSummary: Displays the critical permissions issues detected on the IAM Policy, sorted by Permission Criticality and Unused Permission Criticality. Remediation Strategies: Displays suggested Remediations, with instructions. Connected IAM Resources: Displays the Identity and Access Management (IAM) resources connected to the policy. Configuration: Displays the policy\u0026rsquo;s yaml configuration. You can edit, download, or copy it. Optimize a Policy GloballySysdig may suggest that you Optimize an IAM Policy on the IAM Policy page or subtab. If you click the button and download the proposed policy, it should be used to replace the existing policy in your AWS Console. It will affect all entities (users, roles, groups) associated with the policy.\nIn the example below, the Policy risk is Critical. There are 151 IAM entities listed in the Shared column, which are divided between Assigned Users, Groups, and Roles.\nClick the row to view the entity list on the detail drawer. A number of the Attached Users are Inactive.\nOn the Remediation Strategies tab, click Optimize this IAM Policy.. for a streamlined policy suggestion that considers the attached entities. In this case, it reduces 5311 unused permissions. Upload this policy to your AWS Console and associate with appropriate users, roles, and groups. Recommended: Deactivate the old policy and potentially remove the detected inactive users in AWS. ","url":"https://docs.sysdig.com/en/sysdig-secure/iam-policies/"},{"id":333,"title":"On-Premises Installation","content":" Organize resources for a test environment and the production environment.\nUnderstand the architecture, component requirements, an installation options in Architecture \u0026amp; System Requirements.\nReview the supported platforms and orchestrators. You can find the the official matrix in the onprem-install-docs repository. Click the on-premises version and navigate to the release notes page to view the supported platforms.\nSee the installation instructions in the onprem-install-docs repository.\nDecide the orchestrator to install Sysdig on.\nConsider the Single Sign On (SSO) options and plan accordingly. See Authentication and Authorization (On-Prem Options).\nOversight Services for Installations and UpgradesAs part of our continued focus on our customers, Sysdig is now offering oversight services for all on-premises installs and upgrades. Your Technical Account Manager (TAM), in conjunction with our support organization and Professional Services [where applicable], will work with you to:\nAssess your environment to ensure it is configured correctly.\nReview your infrastructure to validate if appropriate storage capacities are available.\nReview and provide recommendations for backing up your Sysdig data.\nWork with you to ensure our teams are ready to assist you during the install and upgrade process.\nProvide the software for the installation.\nBe available during the process to ensure a successful deployment.\nYou can always review the process in the documentation in the repository or the documentation site.\n","url":"https://docs.sysdig.com/en/administration/on-premises-installation/"},{"id":334,"title":"Integrate AWS Lambda Telemetry API","content":" Feature Availability\nThis feature is currently available only to SaaS users and is provided as Preview. It is still being actively worked on and is subject to significant change in the upcoming releases. This feature is an extension to the existing AWS Lambda monitoring capabilities via the AWS CloudWatch Metric Streams.\nList of MetricsSysdig Lambda Extension collects the following metrics. The metrics are measured in milliseconds.\nMetrics Description aws_lambda_invocations The number of times the function code is invoked. This count includes both successful invocations and invocations that resulted in a function error. aws_lambda_duration The amount of time the function code spends processing an event. aws_lambda_error The number of invocations that result in a function error. These errors include the exceptions that the code throws and the exceptions that the Lambda runtime throws. aws_lambda_postruntime_extensions_duration The cumulative amount of time that the runtime spends running code for extensions after the function code has been completed. List of LabelsSysdig enriches the Lambda metrics with the following labels:\nLabel Description cloud_provider_account_id The unique ID associated with your AWS account. cloud_provider_name The source of the metrics. In this case, AWS. cloud_provider_region_name The region associated with your AWS account. extention_id The unique identifier of the Sysdig Lambda Extension. function_name The name of the Lambda function you monitor. ingest_source The method by which you are collecting the metrics. In this case, the value is lambda exporter. Configure the Lambda FunctionTo configure the Lambda function, add the Sysdig Lambda Extension as a layer to your Lambda function, set the Sysdig-specific environment variables, and then run the function.\nPublish the Extension Download Sysdig Monitor Lambda Extension. Log in to your AWS account. Publish the extension. You can use either the AWS UI or CLI. AWS Console Navigate to Lambda \u0026gt; Layers.\nOn the Layers page, click Create Layer.\nUnder Layer configuration, specify the following:\nName: Specify a unique name for your Sysdig Lambda Extension. Description: Optionally, give a description that can help you identify the extension. Select Upload a .zip file.\nUpload the Sysdig Lambda Extension zip file.\nOptionally, you can enter other configuration information as described in Creating Layers\nClick Create.\nAWS CLI Run the following command:\naws lambda publish-layer-version --layer-name \u0026#34;sysdig-monitor-lambda-extension-v1\u0026#34; --region \u0026lt;your-region\u0026gt; --zip-file \u0026#34;fileb://\u0026lt;path-to-sysdig-monitor-lambda-extension.zip\u0026gt;\u0026#34; Replace the following:\n\u0026lt;your-region\u0026gt; with the Amazon region where you are running your AWS Lambda function\n\u0026lt;path-to-sysdig-monitor-lambda-extension-v1.zip\u0026gt; with the path to the sysdig-monitor-lambda-extension-v1.zip file.\nYou should see output similar to the following:\n{ \u0026#34;Content\u0026#34;: { \u0026#34;Location\u0026#34;: \u0026#34;https://awslambda-us-east-2-layers.s3.us-east-2.amazonaws.com/snapshots/059797578166/sysdig-lambda-extension-....\u0026#34;, \u0026#34;CodeSha256\u0026#34;: \u0026#34;gLJlfhvhm28Xp+21aFf+sthrio8XzjPWHwB+mSbUGs4+\u0026#34;, \u0026#34;CodeSize\u0026#34;: 4202227 }, \u0026#34;LayerArn\u0026#34;: \u0026#34;arn:aws:lambda:us-east-2:059797578166:layer:sysdig-monitor-lambda-extension-v1\u0026#34;, \u0026#34;LayerVersionArn\u0026#34;: \u0026#34;arn:aws:lambda:us-east-2:059797578166:layer:sysdig-monitor-lambda-extension-v1:3\u0026#34;, \u0026#34;Description\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;CreatedDate\u0026#34;: \u0026#34;2022-10-31T19:12:33.965+0000\u0026#34;, \u0026#34;Version\u0026#34;: 4 } Copy the ARN value. Specify the ARN while adding the extension as a layer to your Lambda function.\nIn this example, arn:aws:lambda:us-east-2:059797578166:layer:sysdig-lambda-extension\nAdd the LayerThis section assumes that you have already created the Lambda function that you want to monitor.\nLog in to your AWS account. On the Lambda function page, select the function you want to monitor. On the Function overview page, click Add a layer. Click Specify an ARN and paste the ARN you copied earlier. Optionally, verify the specified ARN is correct. Click Add. Add Environment Variables From the Lambda function page, select your Lambda function.\nOn the function page, click Configuration.\nSelect Environment variables and specify the following:\nSYSDIG_API_TOKEN: The Sysdig Monitor API associated with your Sysdig account. SYSDIG_API_TOKEN_ENCRYPTED: If you want the Sysdig API token to be encrypted in transit, set this option to TRUE. See Encrypt Sysdig API Token for more information. SYSDIG_SITE The Collector URL associated with your Sysdig region. Click Save.\nEncrypt Sysdig API TokenIf you want the Sysdig API Token to be encrypted prior to sending it to your Lambda function, you can do so by using the Encryption configuration option. Encrypted Sysdig API token will be obscured in the Lambda console and API output, even for the users who have permission to use the key. In your code, the encrypted value will be retrieved from the environment and will be decrypted by using the AWS KMS API.\nOn the Functions page of the Lambda console, click your function.\nChoose Configuration, then select Environment variables from the left navigation bar.\nIn the Environment variables section, click Edit.\nExpand Encryption configuration.\nUnder Encryption in transit, select Enable helpers for encryption in transit.\nSelect Encrypt next to the SYSDIG_API_TOKEN environment variable.\nUnder AWS KMS key to encrypt in transit, select a customer-managed key that you have created.\nCopy the Execution role policy in JSON format.\nYou need the JSON snippet while setting the permissions.\nSelect Save.\nSet up permissions. Because you are enabling the client-side encryption for securing the Sysdig API token in transit, your function needs permission to call the kms:Decrypt API operation.\nFrom your function page, select Configuration, and then click Permissions. Click the Role name. On the role\u0026rsquo;s page, click Add permissions \u0026gt; Create inline policy. Click JSON and paste the JSON snippet you copied earlier. Click Review Policy For more information, see Securing environment variables.\nRun the FunctionOn the function page, run your function a few times by clicking Test. When you run it for the first time, you will be asked to specify a name.\nVerify the Connection Log in to Sysdig Monitor.\nOpen Explore \u0026gt; Metrics Explorer.\nSelect Entire Infrastructure on the scope tree.\nSearch for one of the metrics listed above. For example, aws_lambda_invocations.\nIf you can view the list of lambda metrics, the connection is live. You can continue with building dashboards, creating alerts, and exploring with Advisor.\nUpgrade Sysdig Monitor Lambda ExtensionTo upgrade Sysdig Lambda Extension, you need to first download the latest one, create a new version of the layer that you have already created, then attach it to your function.\nCreate a new version of the layer.\nNavigate to Lambda \u0026gt; Layers. On the Layers page, select your layer, then click Create Version. Under Layer version configuration, specify the following: Name: Specify a unique name for your Sysdig Lambda Extension. Description: Optionally, give a description that can help you identify the extension. Select Upload a .zip file. Upload the new Sysdig Lambda Extension zip file. Optionally, you can enter other configuration information as described in Creating Layers Click Create. Attach the new version to your function.\nOn the Lambda function page, select your function. On the bottom of the page under Layer, Click Edit. On the Edit layers page, select the version you want to use. Click Save. Compare AWS Metric Streams and AWS Telemetry APIs Metric Streams Telemetry APIs Ingests metrics into Sysdig from a Firehose connection. Processes metrics from Lambda events that are generated in Lambda execution environments in real time. Collects a larger volume of metrics every 1 minute. Collects specific Lambda metrics every 10 seconds. Consuming all the Lambda metrics might incur a higher cost. Collecting specific Lambda metrics keeps the cost lower. ","url":"https://docs.sysdig.com/en/sysdig-monitor/connect-aws-account/aws-lambda/"},{"id":335,"title":"Integrate with AWS Role Delegation","content":"This page also covers how to authorize Sysdig Monitor to: - discover cloud assets - grab CloudWatch metrics from your AWS account - utilize custom Simple Storage Service (S3) buckets for storing captures\nUpon integrating with an AWS role, you can delegate access to AWS resources that are not associated with your Sysdig AWS account.\nSetting up cross-account access through roles eliminates the need to create individual Identity Access Management (IAM) users in each account. In addition, users don\u0026rsquo;t have to sign out of one account and sign in to another in order to access resources in different AWS accounts.\nRole delegation is an alternative to the existing integration method of using the access keys. This method is considered more secure as sharing developer access keys with third-parties is not recommended by Amazon.\nPrerequisites and GuidelinesThis topic assumes that you you are familiar with AWS and have the following ready:\nSysdig Monitor API Token\nExternal ID\nAPI endpoint. In this topic, it is referred to as {{host}}\nSaaS: See SaaS Regions and IP Ranges and identify the correct domain URL associated with your Sysdig application and region. For example, in US East, the endpoints are:\nMonitor: https://app.sysdigcloud.com\nSecure: https://secure.sysdig.com\nFor other regions, the format is https://\u0026lt;region\u0026gt;.app.sysdig.com. Replace \u0026lt;region\u0026gt; with the region where your Sysdig application is hosted. For example, for Sysdig Monitor in the EU, you use https://eu1.app.sysdig.com.\nOn-Prem: Depends on the on-prem deployment.\nAdministrator privileges to configure AWS integration\nAPI client. Examples in this topic use curl\nAWS account ID\nSaaS: The default AWS account ID is 273107874544 (US East region). For other regions, check AWS account IDs .\nOn-Prem: Customer-specific.\nEnable AWS Role Delegation with APIThis section describes how to enable AWS role delegation using an API with an Amazon Resource Name (ARN).\nInstructions for SaaS Get Your External ID.\nConfigure Role Delegation.\nGet Role ARN.\nAdd the AWS Account.\nInstructions for On-Prem Get Your External ID.\nConfigure Role Delegation.\nGet Role ARN.\nAdd the AWS Account.\nFollow Additional Configuration for On-Prem.\nGet Your External IDRetrieve your external ID as follows:\ncurl -k --request GET \\ --url host/api/users/me \\ --header \u0026#39;authorization: Bearer e71d7c0f-501e-47d4-a159-39da8b716f44\u0026#39; | jq \u0026#39;.[] | .customer | .externalId\u0026#39; An example External ID from the response will be 04acdd59-4c98-4d11-8ee5-424326248161.\nConfigure Role DelegationIntegrating the Sysdig Platform with Amazon Web Services requires configuring role delegation using AWS IAM.\nCreate a new role in the AWS IAM Console:\nFor the role type, select Another AWS account.\n(SaaS) Enter the Sysdig account ID for Account ID.\nThis means that you are granting read-only access to your AWS data.\nSelect Require external ID and enter the one you retrieved in the previous step. Leave Multi-Factor Authorisation (MFA) disabled.\nClick Next: Permissions.\nCreate the following policies:\nsysdig_cloudwatch: Gives access to the list and describe supported AWS resources and get CloudWatch metrics for them.\nsysdig_s3: Defines the bucket name where you wish to store the captures.\nFor more information on policies, see IAM Policy Code to Use.\nFor detailed instructions on how to create a policy, see Integrate AWS Account Manually.\nIf a policy has already been created, search for it on this page and select it, then skip to the next step. Otherwise, click Create Policy, which opens in a new window.\nClick Review policy.\nName the policy and provide an apt description, for example, \u0026ldquo;sysdig_cloudwatch\u0026rdquo;.\nClick Create Policy.\nYou can now close this window.\nIn the Create role window, refresh the list of policies and select the policies you just created.\nClick Next: Review.\nGive the role a name and an apt description, for example, \u0026ldquo;sysdig_role\u0026rdquo;.\nClick Create Role.\nGet Role ARN Select Roles \u0026gt; sysdig-role.\nCopy Role ARN.\nAdd the AWS AccountUsing the role that you have created, add an AWS account on the Sysdig Monitor side. Use the following API call:\ncurl --request POST \\ --url {{host}}/api/providers \\ --header \u0026#39;authorization: Bearer e71d7c0f-501e-47d4-a159-39da8b716f44\u0026#39; \\ --header \u0026#39;content-type: application/json\u0026#39; \\ --data \u0026#39;{\u0026#34;name\u0026#34;: \u0026#34;aws\u0026#34;,\u0026#34;credentials\u0026#34;: {\u0026#34;role\u0026#34;: \u0026#34;\u0026lt;Role_ARN\u0026gt;\u0026#34;},\u0026#34;alias\u0026#34;: \u0026#34;role_delegation\u0026#34;}\u0026#39; Replace \u0026lt;Role_ARN\u0026gt; with the one that you have copied in the previous section.\nThe response lists all the providers. An example response is given below:\n{ \u0026#34;provider\u0026#34;: { \u0026#34;id\u0026#34;: 7, \u0026#34;name\u0026#34;: \u0026#34;aws\u0026#34;, \u0026#34;credentials\u0026#34;: { \u0026#34;id\u0026#34;: \u0026#34;role_delegation\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;arn:aws:iam::485365068658:role/sysdig-access3\u0026#34; }, \u0026#34;tags\u0026#34;: [], \u0026#34;status\u0026#34;: { \u0026#34;status\u0026#34;: \u0026#34;configured\u0026#34;, \u0026#34;lastUpdate\u0026#34;: null, \u0026#34;percentage\u0026#34;: 0, \u0026#34;lastProviderMessages\u0026#34;: [] }, \u0026#34;alias\u0026#34;: \u0026#34;role_delegation\u0026#34; } } Verify the role delegation has been created.\nLog in to Sysdig Monitor as an administrator.\nDo one of the following:\nSelect Integrations \u0026gt; AWS CloudWatch.\nFrom the user menu, select Settings \u0026gt; AWS.\nThe role that you have been created will be added to the list of AWS Accounts.\nProceed to enable CloudWatch and AWS S3 bucket.\nSee AWS: Integrate AWS Account and CloudWatch Metrics (Legacy) for more information.\nAdditional Configuration for On-Prem Create an AWS user that will be used to fetch temporary credentials.\nAssign a policy to the user to allow AssumeRole. For example:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: { \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;arn:aws:iam::{ACCOUNT-ID}:role/{ROLE_NAME}*\u0026#34; } } Make the access keys available to users from one of the sources:\nEnvironment variables\nJava system properties\nInstance profile credentials delivered through the Amazon EC2 metadata service.\nEC2 metadata service is recommended if the installation is on AWS.\nExample: Set Environment Variables on a Kubernetes Installation Create Secret:\napiVersion: v1 kind: Secret metadata: name: aws-credentials type: Opaque data: aws.accessKey: {{BASE64_ENCODED_ACCESS_KEY_ID}} aws.secretKey: {{BASE64_ENCODED_ACCESS_KEY_SECRET}} Expose variables in deployment descriptors (sysdigcloud-collector, sysdigcloud-worker, sysdigcloud-api) and reference values in the newly created Secret:\n- name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: key: aws.accessKey name: aws-credentials - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: key: aws.secretKey name: aws-credentials Add variables to descriptors on each platform update until new variables are part of the installer.\nSet Up Resource DiscoveryThe supported AWS are EC2, RDS, Elastic Load Balancer (ELB), ElastiCache, Simple Queue Service (SQS), DynamoDB, and Application Load Balancer (ALB).\nBy default, all the resources are fetched for all regions supported by AWS. You can avoid this by whitelisting regions when creating a provider key via the API. Example body of the provider key request when whitelisting regions:\n{ \u0026#34;name\u0026#34;: \u0026#34;aws\u0026#34;, \u0026#34;credentials\u0026#34;: { \u0026#34;role\u0026#34;: \u0026#34;arn:aws:iam::676966947806:role/test-assume-role\u0026#34; }, \u0026#34;additionalOptions\u0026#34;: \u0026#34;{\\\u0026#34;regions\\\u0026#34;:[\\\u0026#34;US_EAST_1\\\u0026#34;,\\\u0026#34;US_EAST_2\\\u0026#34;]}\u0026#34; } Enable AWS Role Delegation with UIUse the AWS option in the Settings menu to configure AWS role delegation.\nLog in to Sysdig Monitor as an administrator.\nDo one of the following:\nSelect Integrations \u0026gt; AWS CloudWatch.\nFrom the user menu, select Settings \u0026gt; AWS.\nThe AWS Account page is displayed.\nClick Add Accounts.\nThe Identity Authentication page opens to the Role Delegation tab.\nSpecify the following:\nRole ARN: The Role ARN associated with the role you have created for role delegation. The ID is available on the summary page of the role on the AWS console. For more information, see Integrate with AWS Role Delegation.\nAWS External ID: Ensure that AWS External ID is displayed on the page.\nSaaS: For account IDs corresponding to your region, see SaaS Regions and IP Ranges\nOn-Prem: Customer-specific.\nClick Save.\n","url":"https://docs.sysdig.com/en/administration/aws-role-delegation/"},{"id":336,"title":"Integrate with Container Registries","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nECR Registry ScanningECR Registry Scanning automatically scans all container images pushed to all your Elastic Container Registries, so you have a vulnerability report available in your Sysdig Secure dashboard at all times, without having to set up any additional pipeline.\nAn ephemeral CodeBuild pipeline is created each time a new image is pushed, which executes an inline scan based on your defined scan policies. Default policies cover vulnerabilities and dockerfile best practices, and you can define advanced rules yourself.\nUsage Steps Deploy: Deploy Sysdig Secure for cloud on AWS and choose the ECR Image Registry Scanning option.\nInsights becomes your default landing page in Sysdig Secure.\nReview the Scan Results to confirm that AWS Registry appears and use the feature.\nManage Registry CredentialsRegistry credentials are required for Sysdig Secure to pull and analyze images. Each of the registry types has unique input fields for the credentials required (e.g., username/password for docker.io; JSON key for Google Container Registry).\nThe login requires at least read permissions.\nAdd a New Registry From the Image Scanning module, select Registry Credentials and click Add Registry.\nThe New Registry page is displayed.\nEnter the basic identification information:\nRegistry Name: Self-defined\nPath The path to the registry, e.g. docker.io\nNOTE: In some cases, you may have a registry with various namespaces, each with different permissions.\nYou can use a partial path name with a wildcard (*) to subsume all those credentials into the single set of credentials you configure on this page.\nThe wildcard indicates that any image located under the partial path inside the registry (/rg-2-1er in the screenshot) will use the registry credentials configured in step 3, below.\nType Select from the from the drop-down menu.\nConfigure the registry-specific credentials (based on the Type chosen).\nDocker V2 There are many Docker V2 registries, and the credential requirements may differ.\nFor Azure Container Registry:\nAdmin Account\nUsername: in the 'az acr credentials show --name \u0026lt;registry name\u0026gt;' command result\nPassword: The password or password2 value from the 'az acr credentials show' command result\nService Principal\nUsername: The service principal app id\nPassword: The service principal password\nGoogle Container Registry:\nJSON Key\n(Primarily for OpenShift clusters): Add an internal registry address.\nThe recommended way to run an image registry for an OpenShift cluster is to run it locally. The Sysdig agent will detect the internal registry names, but for the Anchore engine to pull and scan the image it needs access to the internal registry itself.\nExample:\nExternal name: mytestregistry.example.com\nInternal name: docker-registry.default.svc:5000\nSysdig maps the internal registry name to the external registry name, so the Runtime and Repository lists will show only the external names.\nOptional: Toggle the switch to Allow Self-Signed certificates.\nBy default, the UI will only pull images from a TLS/SSL-enabled registry.\nToggle Allow Self-Signed to instruct the UI not to validate the certificate (if the registry is protected with a self-signed certificate or a cert from an unknown certificate authority).\nOptional: Toggle the Test Credentialsswitch to validate your entries.\nWhen enabled, Sysdig will attempt to pull the image using the entered credentials. If it succeeds, the registry will be saved. If it fails, you will receive an error and can correct the credentials or image details.\nIf enabled, then enter the test registry path in the format :\nregistry/repo:tag E.g. quay.io/sysdig/agent:0.89\nClick Save.\nEdit a Registry From the Image Scanning module, select Registry Credentials.\nSelect an existing registry to open the Edit window.\nUpdate the parameters as necessary and click Save.\nThe registry Type cannot be edited. Delete a Registry From the Image Scanning module, select Registry Credentials.\nSelect the existing registry to open the Edit window.\nClick Delete Registryand click Yes to confirm the change.\nNext StepsWhen at least one registry has been added successfully, it is possible to scan images and review scan results taking advantage of the Default scanning policy provided.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/integrate-with-container-registries/"},{"id":337,"title":"JFrog Artifactory Configuration","content":"PrerequisitesPerform a pre-installation check to identify your Artifactory configuration. Identify the following configuration parameters:\nregistryURL: The Registry URL corresponding to your Artifactory environment. registryApiUrl: The Registry API URL corresponding to your Artifactory environment. InstallationConnect with an externally managed version of Jfrog Artifactory.\nEnsure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=artifactory \\ --set config.registryUser=\u0026lt;JFROG_ARTIFACTORY_USER\u0026gt; \\ --set config.registryPassword=\u0026lt;JFROG_ARTIFACTORY_PASSWORD\u0026gt; --set config.registryURL=\u0026lt;JFROG_ARTIFACTORY_REGISTRY_URL\u0026gt; \\ --set config.registryApiUrl=\u0026lt;JFROG_ARTIFACTORY_REGISTRY_API_URL\u0026gt; LimitationsMulti-arch Docker manifest/packages are not supported.\nArtifactory Cloud Versions 5.x and AboveVerify Your Artifactory SetupIf your server name is my-server (my-server.jfrog.io), your registry (Artifactory Docker repo) is my-repo, and you pull images using the following pattern:\ndocker pull my-server.jfrog.io/my-repo/image-name You can confirm that you are using an Artifactory Cloud versions that is 5.x or above. Alternatively, you can also check your Artifactory version following the instructions at JFrog Artifactory.\nRegistry URLmy-server.jfrog.io/my-repo\nRegistry API URLmy-server.jfrog.io/artifactory/api/docker/my-repo\nArtifactory Cloud Versions 4.x and BelowVerify Your Artifactory SetupIf your server name is my-server (my-server.jfrog.io), your registry (Artifactory Docker repo) is my-repo, and you pull images using the following pattern:\ndocker pull my-server-my-repo-name.jfrog.io/image-name You can confirm that you are using an Artifactory Cloud version that is v4.x or below. You can also check your Artifactory version following the instructions at https://jfrog.com/help/r/how-can-i-check-artifactory-version-number-on-my-artifactory-saas-account\nRegistry URLmy-server-my-repo.jfrog.io\nRegistry API URLmy-server.jfrog.io/artifactory/api/docker/my-repo\nArtifactory On-Prem SubdomainVerify Your Artifactory SetupIf your server name is host.mycompany.com, your registry (Artifactory Docker repo) is my-repo, and you pull images using the following pattern:\ndocker pull my-repo.host.mycompany.com/image-name You can confirm that you are on an Artifactory On-Prem version using the Subdomain method.\nRegistry URLmy-repo.host.mycompany.com\nRegistry API URLhost.mycompany.com/artifactory/api/docker/my-repo\nArtifactory On-Prem Repository PathVerify Your Artifactory SetupIf your server name is host.mycompany.com, your registry (Artifactory Docker repo) is my-repo, and you pull images using the following pattern:\ndocker pull host.mycompany.com/my-repo/image-name You can confirm that you are on an Artifactory on-prem version using the repository path method.\nRegistry URLhost.mycompany.com/my-repo\nRegistry API URLhost.mycompany.com/artifactory/api/docker/my-repo\nArtifactory On-Prem PortVerify Your Artifactory SetupIf your server name is host.mycompany.com, your registry (Artifactory Docker repo) is my-repo, and you pull images using the following pattern:\ndocker pull host.mycompany.com:5000/image-name You can confirm that you are on an Artifactory on-prem version using the port method.\nYou will have a port dedicated to my-repo.\nRegistry URLhost.mycompany.com:5000\nRegistry API URLhost.mycompany.com:5000/artifactory/api/docker/my-repo\n","url":"https://docs.sysdig.com/en/sysdig-secure/jfrog/"},{"id":338,"title":"Kubernetes Audit Integration","content":"This integration allows you to observe and monitor:\nCreation and destruction of pods, services, deployments, daemon sets Creating/updating/removing config maps or secrets Attempts to subscribe to changes to any endpoint and other operations performed on Kubernetes resources.\nSetup methodsThere are two alternative ways to set up this integration:\nEmulated audit logs (default): uses a Dynamic Admission Control to get notified whenever a resource change is submitted: It\u0026rsquo;s standard across all Kubernetes distributions, and easy to set up It doesn\u0026rsquo;t provide logs for Get/List/Watch operations It doesn\u0026rsquo;t provide IPs/User Agents Audit backend: relies on logs generated by the API server for any operation, as per the Audit Policy. It has the most complete visibility on all APIs, along with IPs and User Agents It officially needs to be set up to access the control plane, so set it up on managed when that access is not available, like in Managed distributions, is different on each use case, and logs can also have different formats. It is only available on Linux Prerequisites Helm v3.8 or above Install Sysdig Shield on Kubernetes using Helm Emulated audit logs method setup Recommended: Replace helm install with helm upgrade --install.\nTo enable Kubernetes audit logging in your existing Sysdig Secure Helm install command, add the following flag:\n--set features.detections.kubernetes_audit.enabled=true For On-Prem \u0026lt; 7.4, set the Sysdig Secure API token. The API Token needs to belong to a user with a Role containing the permission Policies | Runtime Policies = READ.\nSet that in Helm as well:\n--set sysdig_endpoint.secure_api_token=\u0026#34;\u0026lt;YOUR_SYSDIG_API_TOKEN_HERE\u0026gt;\u0026#34; For additional configuration options, refer to the installation guide and the configuration reference.\nAudit backend method setupThis setup exposes a webhook through a Kubernetes Service, using the Shield chart. It then needs to be manually connected to the Kubernetes cluster audit log.\nThis setup heavily depends on Kubernetes distributions and their versions. We guide you through setting up the Service and only provide examples to connect this in some distributions.\nFor further support, please contact your Sysdig representative or Sysdig support.\nAudit Log Webhook deployment The following instructions apply to Cluster Shield 1.22 and above. Update it or refer to the legacy setup instructions.\nRecommended: Replace helm install with helm upgrade --install.\nTo enable the Audit Log Webhook in your existing Shield chart Helm install command, add the following flags:\n--set features.detections.kubernetes_audit.method=audit_backend This will allow the Cluster Shield to receive Kubernetes Audit logs at http://sysdig-shield-cluster:6443/k8s_audit. Kubernetes Audit Logs are defined in the audit.k8s.io/v1 API Group. Read more in the official Kubernetes documentation.\nWith Cluster Shield \u0026lt; 1.22 Recommended: Replace helm install with helm upgrade --install.\nTo enable the Audit Log Webhook in your existing Sysdig Secure Helm install command, add the following flags:\n--set host.additional_settings.security.k8s_audit_server_enabled=true --set host.additional_settings.security.k8s_audit_server_url=0.0.0.0 --set host.additional_settings.security.k8s_audit_server_port=7765 Create a Service to expose it:\napiVersion: v1 kind: Service metadata: name: sysdig-shield-audit namespace: sysdig spec: type: ClusterIP ports: - port: 7765 protocol: TCP name: audit selector: app.kubernetes.io/instance: shield app.kubernetes.io/name: shield sysdig/component: host This will create a Webhook listening on 0.0.0.0:7765, which can be reached via http://sysdig-shield-audit.sysdig.svc.cluster.local:7765/k8s_audit. Use this URL as the destination for the Audit logs instead of the one suggested, as it applies to setups using the new version. Kubernetes Audit Logs are defined in the audit.k8s.io/v1 API Group. Read more in the official Kubernetes documentation.\nSending Audit Logs to the WebhookThis section provides examples of how to configure this in different Kubernetes distributions.\nOpenShiftStarting from Logging 5.7, it\u0026rsquo;s possible to set up a ClusterLogForwarder to send Audit Logs to an HTTP backend.\nIt relies on a Service Account to operate, so:\nStart the creation with kubectl create serviceaccount logging-sa -n sysdig Bind it to the ClusterRole required kubectl create clusterrolebinding logging-sa-binding \\ --clusterrole=cluster-admin --serviceaccount=sysdig:logging-sa Then, install the operator:\nOpen the OpenShift Web Console. Navigate to Ecosystem -\u0026gt; Software Catalog Select sysdig in the project list. Search for “openshift logging” in the search bar. Install the Red Hat OpenShift Logging operator. Choose sysdig as the Installed namespace. Create a ClusterLogForwarder using the configuration below. apiVersion: observability.openshift.io/v1 kind: ClusterLogForwarder metadata: name: logging namespace: sysdig spec: outputs: - name: cluster-shield-audit-webhook http: method: POST url: \u0026#34;http://sysdig-shield-cluster:6443/k8s_audit\u0026#34; type: http pipelines: - inputRefs: - audit name: audit-log-pipeline outputRefs: - cluster-shield-audit-webhook serviceAccount: name: logging-sa KopsTo implement this in kops you need to edit the cluster configuration.\nStart by obtaining the current cluster configuration and saving it to a file:\nkops get cluster \u0026lt;your cluster name\u0026gt; -o yaml \u0026gt; cluster-current.yaml Edit cluster-current.yaml, merging it with the YAML below, replacing what already exists and adding what\u0026rsquo;s missing. You can find the content of the webhook-config and audit-policy file assets in the dedicated sections:\nAudit Policy, to replace AUDIT_POLICY_FILE_CONTENT Webhook configuration, to replace WEBHOOK_CONFIG_FILE_CONTENT. spec: fileAssets: - name: webhook-config path: /var/lib/k8s_audit/webhook-config.yaml roles: [Master] content: | WEBHOOK_CONFIG_FILE_CONTENT - name: audit-policy path: /var/lib/k8s_audit/audit-policy.yaml roles: [Master] content: | AUDIT_POLICY_FILE_CONTENT kubeAPIServer: auditLogPath: /var/lib/k8s_audit/audit.log auditLogMaxBackups: 1 auditLogMaxAge: 10 auditLogMaxSize: 100 auditWebhookBatchMaxWait: 5s auditPolicyFile: /var/lib/k8s_audit/audit-policy.yaml auditWebhookConfigFile: /var/lib/k8s_audit/webhook-config.yaml Configure Kops with the new cluster configuration:\nkops replace -f cluster.yaml Update the cluster configuration to prepare changes to the cluster:\nkops update cluster \u0026lt;your cluster name\u0026gt; --yes Perform a rolling update to redeploy the master nodes with the new files and API server configuration:\nkops rolling-update cluster --yes GKEGKE provides Kubernetes audit logs, but the logs are stored in Cloud Logging and are in a different format than the native format used by Kubernetes. You can read more in the official documentation.\nAs a preliminary step, enable the Audit log generation in your cluster.\nUsing the CLI: gcloud container clusters update YOUR_CLUSTER_NAME --logging=SYSTEM,WORKLOAD,API_SERVER. See the Google Cloud documentation for additional details Using the Console: GKE Cluster -\u0026gt; Details tab -\u0026gt; Features section -\u0026gt; Logging option. Edit it and select \u0026ldquo;Enable Logging\u0026rdquo;. Select at least \u0026ldquo;Workloads\u0026rdquo; and \u0026ldquo;API Server\u0026rdquo; among the available components. Additional information is available in the official documentation.\nOnce this step is completed, logs are available to be queried in Logs Explorer:\nprotoPayload.@type=\u0026#34;type.googleapis.com/google.cloud.audit.AuditLog\u0026#34; resource.labels.cluster_name=\u0026#34;YOUR_CLUSTER_NAME\u0026#34; Those logs need to be now routed to the Service and converted from the Google to the Kubernetes Audit format. As an example, you can have a worker reading from Google Cloud Logging, transforming the logs and sending those events to the Service. You can find that in a public repository.\nTo deploy it:\nCreate a Google Cloud (not Kubernetes) service account and key that has the ability to read logs:\ngcloud iam service-accounts create swb-logs-reader --description \u0026#34;Service account used by stackdriver-webhook-bridge\u0026#34; --display-name \u0026#34;stackdriver-webhook-bridge logs reader\u0026#34; gcloud projects add-iam-policy-binding \u0026lt;your gce project id\u0026gt; --member serviceAccount:swb-logs-reader@\u0026lt;your gce project id\u0026gt;.iam.gserviceaccount.com --role \u0026#39;roles/logging.viewer\u0026#39; gcloud iam service-accounts keys create $PWD/swb-logs-reader-key.json --iam-account swb-logs-reader@\u0026lt;your gce project id\u0026gt;.iam.gserviceaccount.com Create a Kubernetes secret containing the service account keys:\nkubectl create secret generic stackdriver-webhook-bridge --from-file=key.json=$PWD/swb-logs-reader-key.json -n sysdig Deploy the bridge program to your cluster using the provided stackdriver-webhook-bridge.yaml file:\nkubectl apply -f stackdriver-webhook-bridge.yaml -n sysdig GKE uses a Kubernetes audit policy that emits a more limited set of information than the one recommended by Sysdig. As a result, there are several limitations when retrieving Kubernetes audit information for the Events feed and Activity Audit features in Sysdig Secure.\nRequest Object\nIn particular, audit events for config maps in GKE generally do not contain a requestObject field that contains the object being created/modified.\nPod exec does not Include command/container\nFor many Kubernetes distributions, an audit event representing a pod exec includes the command and specific container as arguments to the requestURI. For example:\n\u0026#34;requestURI\u0026#34;: \u0026#34;/api/v1/namespaces/default/pods/nginx-deployment-7998647bdf-phvq7/exec?command=bash\u0026amp;container=nginx1\u0026amp;container=nginx1\u0026amp;stdin=true\u0026amp;stdout=true\u0026amp;tty=true In GKE, the audit event is missing those request parameters.\nImplications for the Event Feed\nIf the rule condition includes a field that is not available in the Kubernetes audit log provided by GKE, the rule will not trigger.\nFor example, rules targeting changes to ConfigMap content containing specific information or specific commands being executed will not trigger, leading to missed detections/false negatives.\nThis will also limit the information that can be displayed in the outputs of rules. For example the command=%ka.uri.param[command] output variable in the Attach/Exec Pod rule will always return N/A.\nImplications for Activity Audit\nkubectl exec elements will not be scoped to the cluster name; they will only be visible scoping by entire infrastructure\u0026quot;\nA kubectl exec item in Activity Audit will not display command or container information\nDrilling down into a kubectl exec will not provide the container activity as there is no information that allows Sysdig to correlate the kubectl exec action with an individual container.\nEKSAmazon EKS does not provide webhooks for audit logs, but it allows audit logs to be forwarded to CloudWatch.\nTo enable your EKS cluster generating Audit logs in CloudWatch:\nOpen your cluster in EKS Select the Observability tab In the Control plane logs section, Click \u0026ldquo;Manage\u0026rdquo; Ensure \u0026ldquo;Audit\u0026rdquo; is selected and click \u0026ldquo;Save changes\u0026rdquo; Afterward, you\u0026rsquo;ll need to send those logs from CloudWatch to your listening webhook. You can achieve this in different ways. For example:\nHave a workload in your cluster periodically read from CloudWatch and relay the logs to the webhook. Here you can find an example for that setup. Set up a subscription to a Lambda, sending those logs to the webhook. Please remember that logs must be in the Kubernetes Audit format in order to be processed, so a Firehose subscription isn\u0026rsquo;t a suitable option as of now, unless you intend to unwrap that payload before sending it to the webhook.\nFor logs from the Sysdig agent, proceed as follows:\nEnable CloudWatch logs for your EKS cluster. Allow access to CloudWatch from the worker nodes. Add a new deployment that polls CloudWatch and forwards events to the Sysdig agent. You can find anexample configuration that can be implemented with the AWS UI, along with the code and the image for an example audit log forwarder. (In a production system this would be implemented as IaC scripts.)\nPlease note that CloudWatch is an additional AWS paid offering. In addition, with this solution, all the pods running on the worker nodes will be allowed to read CloudWatch logs through AWS APIs.\nAKSIn AKS, you can enable Audit Logs generation using Diagnostic Settings for the cluster. You can refer to the official documentation to set this up.\nThose Diagnostic Settings will be used to route those logs to a destination which, unfortunately, can\u0026rsquo;t be the Sysdig webhook, directly. There are a few alternative architectures, but our suggestion is to employ Event Hub as a target.\nIf you choose this route, you will need something to subscribe to the Event Hub stream and send those events to the webhook. This can be achieved in many ways, among those:\nUse a Kubernetes deployment, like in the example available in this repository Use Logic App, triggering on events available on Event Hub and sending requests to the service, correctly exposed. RKE/K3sAudit support is already enabled by default, but the audit policy must be updated to provide additional granularity. These instructions enable a webhook backend pointing to the agent\u0026rsquo;s service.\nThe following steps need to be applied on each node in the control plane:\nFollow the official documentation to edit the Audit policy. This is the link to v2.13; verify the exact procedure for your version. You can find a suggested Policy here.\nNext, create the Webhook Configuration. Based on the distribution/version: /var/lib/rancher/{rke2,k3s}/server/audit-webhook.yaml. You can find the content here, where you can use the pod network option.\nThis configuration then needs to be used by the Cluster. This is applied via the control plane configuration (/etc/rancher/rke2/config.yaml) or as arguments (SystemD approach)\naudit-policy-file=/var/lib/rancher/rke2/server/audit.yaml audit-webhook-config-file=/var/lib/rancher/rke2/server/audit-webhook.yaml audit-webhook-batch-max-size=100 audit-webhook-batch-max-wait=5s Finally, restart the nodes\nIKSIKS supports generating Audit Logs and forwarding them to an HTTP endpoint. The sole caveat is that the API server runs outside the cluster network and, therefore, needs to reach the webhook through its IP. The other limitation is on the generated logs, where the configured policy cannot be changed.\nYou can refer to IBM documentation to set this up. The Webhook URL can be obtained by looking at the Service previously set up\u0026quot;\necho \u0026#34;http://$(kubectl get service sysdig-shield-cluster -n sysdig -o jsonpath=\u0026#39;{.spec.clusterIP}\u0026#39;):6443/k8s_audit\u0026#34; MinikubeMinikube lets you manage the Control plane directly, so you can specify the Audit Policy and the Audit backend directly. This is accomplished using the --extra-config parameter of the minikube start command, changing the apiserver configurations, as shown in the tutorial of Minikube. See the reference for the minikube start command in the Minikube documentation and the apiserver configurations in the official Kubernetes documentation.\nIn each node of the Control plane, as suggested by the tutorial, create the audit-policy.yaml as well as the webhook-config.yaml files in the ~/.minikube/files/etc/ssl/certs directory. Afterward, you can restart Minikube by specifying the following options:\n--extra-config=apiserver.audit-policy-file=/etc/ssl/certs/audit-policy.yaml --extra-config=apiserver.audit-log-path=- --extra-config=apiserver.audit-webhook-config-file=/etc/ssl/certs/webhook-config.yaml --extra-config=apiserver.audit-webhook-batch-max-size=10 --extra-config=apiserver.audit-webhook-batch-max-wait=5s KubeadmWith Kubeadm you manage the Control Plane directly so you can create the audit-policy.yaml and the webhook-config.yaml files in the /etc/kubernetes/ folder.\nThen, make the Control plane use them. Create /etc/kubernetes/kubeadm-audit-config.yaml with:\napiVersion: kubeadm.k8s.io/v1beta4 kind: ClusterConfiguration kubernetesVersion: v1.16.0 apiServer: extraArgs: - name: \u0026#34;audit-policy-file\u0026#34; value: \u0026#34;/etc/kubernetes/audit-policy.yaml\u0026#34; - name: \u0026#34;audit-log-path\u0026#34; value: \u0026#34;-\u0026#34; - name: \u0026#34;audit-webhook-config-file\u0026#34; value: \u0026#34;/etc/kubernetes/webhook-config.yaml\u0026#34; - name: \u0026#34;audit-webhook-batch-max-size\u0026#34; value: \u0026#34;10\u0026#34; - name: \u0026#34;audit-webhook-batch-max-wait\u0026#34; value: \u0026#34;5s\u0026#34; Finally, run kubeadm init --config /etc/kubernetes/kubeadm-audit-config.yaml\nSee the official documentation for additional information.\nReference: Audit PolicyThis is a general-purpose Audit Policy you can use to audit all the relevant events in the Control Plane. Adjust it based on your use case, if needed.\napiVersion: audit.k8s.io/v1 kind: Policy omitStages: - \u0026#34;RequestReceived\u0026#34; rules: # Ignore low-impact read-only URLs - level: None userGroups: [\u0026#34;system:authenticated\u0026#34;] nonResourceURLs: - \u0026#34;/api*\u0026#34; - \u0026#34;/version\u0026#34; - \u0026#34;/healthz\u0026#34; - \u0026#34;/readyz\u0026#34; - \u0026#34;/livez\u0026#34; # Ignore system noise - level: None users: - \u0026#34;system:kube-proxy\u0026#34; - \u0026#34;system:kube-scheduler\u0026#34; - \u0026#34;system:kube-controller-manager\u0026#34; verbs: [\u0026#34;get\u0026#34;, \u0026#34;list\u0026#34;, \u0026#34;watch\u0026#34;] # Log exec, attach, port-forward at RequestResponse (capture commands) - level: RequestResponse verbs: [\u0026#34;create\u0026#34;] resources: - group: \u0026#34;\u0026#34; resources: [\u0026#34;pods/exec\u0026#34;, \u0026#34;pods/attach\u0026#34;, \u0026#34;pods/portforward\u0026#34;] # Log security-sensitive resources at RequestResponse level - level: RequestResponse resources: - group: \u0026#34;\u0026#34; resources: [\u0026#34;secrets\u0026#34;, \u0026#34;serviceaccounts\u0026#34;] - group: \u0026#34;rbac.authorization.k8s.io\u0026#34; resources: [\u0026#34;roles\u0026#34;, \u0026#34;rolebindings\u0026#34;, \u0026#34;clusterroles\u0026#34;, \u0026#34;clusterrolebindings\u0026#34;] - group: \u0026#34;networking.k8s.io\u0026#34; resources: [\u0026#34;networkpolicies\u0026#34;] - group: \u0026#34;policy\u0026#34; resources: [\u0026#34;podsecuritypolicies\u0026#34;] # Log pod and deployment changes at RequestResponse - level: RequestResponse resources: - group: \u0026#34;\u0026#34; resources: [\u0026#34;pods\u0026#34;, \u0026#34;services\u0026#34;, \u0026#34;persistentvolumes\u0026#34;, \u0026#34;persistentvolumeclaims\u0026#34;] - group: \u0026#34;apps\u0026#34; resources: [\u0026#34;deployments\u0026#34;, \u0026#34;daemonsets\u0026#34;, \u0026#34;statefulsets\u0026#34;, \u0026#34;replicasets\u0026#34;] # Log configmap changes - level: Request resources: - group: \u0026#34;\u0026#34; resources: [\u0026#34;configmaps\u0026#34;] # Catch-all at Metadata level - level: Metadata omitStages: - \u0026#34;RequestReceived\u0026#34; Reference: Webhook configurationThis is a standard configuration for the audit webhook. Based on the networking your Control Plane uses, you should set AUDIT_WEBHOOK_ENDPOINT differently:\nsysdig-shield-cluster if it uses the pod networking and can access the Cluster DNS The ClusterIP corresponding to the Service, if it runs outside the pod networking. This can be obtained via: kubectl get service sysdig-shield-cluster -n sysdig -o jsonpath=\u0026#39;{.spec.clusterIP}\u0026#39;) apiVersion: v1 kind: Config clusters: - name: sysdig cluster: server: http://AUDIT_WEBHOOK_ENDPOINT:6443/k8s_audit users: - name: sysdig contexts: - context: cluster: sysdig user: sysdig name: sysdig current-context: sysdig Next StepsOnce this is set up, you will see:\nEvents in the Events Feed, if you enabled Kubernetes Audit Threat detection policies and any Audit log matches the rules they contain. Activity Audit entries for the Kubernetes Data source (attach/exec). ","url":"https://docs.sysdig.com/en/sysdig-secure/kube-audit/"},{"id":339,"title":"Kubernetes Benchmarks","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\ncompliance.k8s-bench.api-server.pass_pctThe percentage of Kubernetes benchmark tests run on the API server that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.api-server.tests_failThe number of Kubernetes benchmark tests run on the API server that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.api-server.tests_passThe number of Kubernetes benchmark tests run on the API server that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.api-server.tests_totalThe total number of Kubernetes benchmark tests run on the API server.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.api-server.tests_warnThe number of Kubernetes benchmark tests run on the API server that returned a result of WARN.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configuration-files.pass_pctThe percentage of Kubernetes benchmark tests run on the configuration files of non-master nodes that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configuration-files.tests_failThe number of Kubernetes benchmark tests run on the configuration files of non-master nodes that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configuration-files.tests_passThe number of Kubernetes benchmark tests run on the configuration files that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configuration-files.tests_totalThe total number of Kubernetes benchmark tests run on the configuration files of non-master nodes.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configuration-files.tests_warnThe number of Kubernetes benchmark tests run on the configuration files of non-master nodes that returned a result of WARN.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configure-files.pass_pctThe percentage of Kubernetes benchmark tests run on the master node configuration files that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configure-files.tests_failThe number of Kubernetes benchmark tests run on the master node configuration files that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configure-files.tests_passThe number of Kubernetes benchmark tests run on the master node configuration files that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configure-files.tests_totalThe total number of Kubernetes benchmark tests run on the master node configuration files.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.configure-files.tests_warnThe number of Kubernetes benchmark tests run on the master node configuration files that returned a result of WARN.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.controller-manager.pass_pctThe percentage of Kubernetes benchmark tests run on the controller manager that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.controller-manager.tests_failThe number of Kubernetes benchmark tests run on the controller manager that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.controller-manager.tests_passThe number of Kubernetes benchmark tests run on the controller manager that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.controller-manager.tests_totalThe total number of Kubernetes benchmark tests run on the controller manager.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.controller-manager.tests_warnThe number of Kubernetes benchmark tests run on the controller manager that returned a result of WARN.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.etcd.pass_pctThe percentage of Kubernetes benchmark tests run on the etcd key value store that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.etcd.tests_failThe number of Kubernetes benchmark tests run on the etcd key value store that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.etcd.tests_passThe number of Kubernetes benchmark tests run on the etcd key value store that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.etcd.tests_totalThe total number of Kubernetes benchmark tests run on the etcd key value store.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.etcd.tests_warnThe number of Kubernetes benchmark tests run on the etcd key value store that returned a result of WARN.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.general-security-primitives.pass_pctThe percentage of Kubernetes benchmark tests run on the security primitives that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.general-security-primitives.tests_failThe number of Kubernetes benchmark tests run on the security primitives that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.general-security-primitives.tests_passThe number of Kubernetes benchmark tests run on the security primitives that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.general-security-primitives.tests_totalThe total number of Kubernetes benchmark tests run on the security primitives.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.general-security-primitives.tests_warnThe number of Kubernetes benchmark tests run on the security primitives that returned a result of WARN.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.kubelet.pass_pctThe percentage of Kubernetes benchmark tests run on the non-master node Kubernetes agent that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.kubelet.tests_failThe number of Kubernetes benchmark tests run on the non-master node Kubernetes agent that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.kubelet.tests_passThe number of Kubernetes benchmark tests run on the non-master node Kubernetes agent that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.kubelet.tests_totalThe total number of Kubernetes benchmark tests run on the non-master node Kubernetes agent.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.kubelet.tests_warnThe number of Kubernetes benchmark tests run on the non-master node Kubernetes agent that returned a result of WARN.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.pass_pctThe percentage of Kubernetes benchmark tests that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.scheduler.pass_pctThe percentage of Kubernetes benchmark tests run on the scheduler that passed.\nMetadata Description Metric Type Gauge Value Type % Segment By Container Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.scheduler.tests_failThe number of Kubernetes benchmark tests run on the scheduler that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.scheduler.tests_passThe number of Kubernetes benchmark tests run on the scheduler that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.scheduler.tests_totalThe total number of Kubernetes benchmark tests run on the scheduler.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.scheduler.tests_warnThe number of Kubernetes benchmark tests run on the scheduler that returned a result of WARN.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.tests_failThe number of Kubernetes benchmark tests that failed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.tests_passThe number of Kubernetes benchmark tests that passed.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.tests_totalThe total number of Kubernetes benchmark tests run.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max compliance.k8s-bench.tests_warnThe number of Kubernetes benchmark tests that returned a result of WARN.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/kubernetes-benchmarks/"},{"id":340,"title":"Login Message","content":"Create a Custom BannerTo create a customized login banner:\nNavigate to Settings \u0026gt; Login Message from Sysdig Monitor or Sysdig Secure.\nEnter your desired text in the message box. Use Markdown to format.\nTo make the message appear on login, toggle the Enabled slider on. If only this option is selected, the message will appear only to regular Users, not Admin users.\nTo make the message appear to Admin users, toggle the Show to all users on. Option Enabled must be enabled as well for the message to appear at login.\nClick the three dots in the upper right corner to Clear the existing text, or to Preview Message.\nWhen you are happy with the message, click Save.\nLog out and log back in to see the message displayed.\n","url":"https://docs.sysdig.com/en/administration/login_message/"},{"id":341,"title":"Manage File Logging for Agent Components","content":"By controlling logging at the fine-grained component level, you can avoid excessive logging from certain components in draios.log or enable extra logging from specific components for troubleshooting.\nThe Agent components can also have an optional feature level logging that can provide a way to control the logging for a particular feature in Sysdig Agent.\nTo set feature-level or component-level logging:\nDetermine the agent feature or component you want to set the log level:\nTo do so,\nOpen the /opt/draios/logs/draios.log file.\nCopy the component name.\nThe format of the log entry is:\n\u0026lt;timestamp\u0026gt;, \u0026lt;\u0026lt;pid\u0026gt;.\u0026lt;tid\u0026gt;\u0026gt;, \u0026lt;log level\u0026gt;, [feature]:\u0026lt;component\u0026gt;[pid]:[line]: \u0026lt;message\u0026gt; For example, the given snippet from a sample log file shows log messages from promscrape feature, sdjagent, mountedfs_reader, watchdog_runnable, protobuf_file_emitter, connection_manager, and dragent.\n2020-09-07 17:56:01.173, 27979.28018, Information, sdjagent[27980]: Java classpath: /opt/draios/share/sdjagent.jar 2020-09-07 17:56:01.173, 27979.28018, Information, mountedfs_reader: Starting mounted_fs_reader with pid 27984 2020-09-07 17:56:01.174, 27979.28019, Information, watchdog_runnable:105: connection_manager starting 2020-09-07 17:56:01.174, 27979.28019, Information, protobuf_file_emitter:64: Will save protobufs for all message types 2020-09-07 17:56:01.174, 27979.28019, Information, connection_manager:282: Initiating connection to collector 2020-09-07 17:56:01.175, 27979.27979, Information, dragent:1243: Created Sysdig inspector 2020-09-07 18:52:40.065, 27979.27980, Debug, promscrape:prom_emitter:72: Sent 927 Prometheus metrics of 7297 total 2020-09-07 18:52:41.129, 27979.27981, Information, promscrape:prom_stats:45: Prometheus timeseries statistics, 5 endpoints To set feature-level logging:\nOpen /opt/draios/etc/dragent.yaml.\nEdit the dragent.yaml file and add the desired feature:\nIn this example, you are setting the global level to notice and promscrape feature level to info.\nlog: file_priority: notice file_priority_by_component: - \u0026#34;promscrape: info\u0026#34; The log levels specified for feature override global settings.\nTo set component-level logging:\nOpen /opt/draios/etc/dragent.yaml.\nEdit the dragent.yaml file and add the desired feature:\nIn this example, you are setting the global level to notice and promscrape feature level to info, sdjagent, mountedfs_reader component log level to debug, watchdog_runnable component log level to warning and promscrape:prom_emitter component log level to debug.\nlog: file_priority: notice file_priority_by_component: - \u0026#34;promscrape: info\u0026#34; - \u0026#34;promscrape:prom_emitter: debug\u0026#34; - \u0026#34;watchdog_runnable: warning\u0026#34; - \u0026#34;sdjagent: debug\u0026#34; - \u0026#34;mountedfs_reader: debug\u0026#34; The log levels specified for feature override global settings. The log levels specified for component override feature and global settings.\nRestart the agent.\nFor example, if you have installed the agent as a service, then run:\n$ service dragent restart ","url":"https://docs.sysdig.com/en/sysdig-secure/file-logging-classic-agent/"},{"id":342,"title":"Manage Teams, Roles, and Service Accounts","content":" Teams and roles must be assigned separately in Sysdig Monitor and Sysdig Secure.\nFor more information, including foundational concepts, see User and Team Administration.\nTeams OverviewTo access the Teams page:\nLog in to Secure or Monitor as an Admin.\nGo to Settings \u0026gt; Teams.\nOn the Teams page, you can create, modify, and review teams. The page is divided into two parts. The Summary section displays statistics and information about the default team. Underneath, there is a searchable list of all teams.\nThe Summary displays:\nNumber of teams: This is a total number of teams in all available Sysdig products. Secure Default team: Shows the default Secure team. Click View Team to review the configuration and make changes. Note: Available only for Secure customers. Monitor Default team: Shows the default Monitor team. Click View Team to review the configuration and make changes. Note: Available only for Monitor customers. Create a Team Log in to Monitor or Secure as Admin.\nSelect Settings from the user menu.\nSelect Teams.\nClick Add Team.\nEnter the team name, configure the team details, and click Save.\nFor more information on each configuration option, see Team Settings.\nYou will not be able to assign users or create service accounts until you provide at least a name and click Save.\nTeam names must be unique across Monitor and Secure. Each team name is unique on the customer level and a team name used in one product cannot be re-used in the other. For example, if you attempt to create a team in Secure with the same name as one created in Monitor, you will see an error message stating that a team with the same name already exists and the team won’t be created.\nEdit a Team Log in to Monitor or Secure as Admin.\nSelect Admin from the user menu.\nSelect Teams.\nSelect a team to edit from the team list.\nYou can use the search box to find the specific team.\nSelect the option Edit team from the three dot menu on the right side.\nAfter making the necessary changes, select Save to save the changes.\nTeam Settings Setting Required Description Color Yes Assigns a color to the team to make them easier to identify in a list. Name Yes The name of the team. Description No Enter a description for the team. Default Team No If this is toggled on, users that are not assigned to any team will be added to this team by default. Default User Role No The default role given to users added to this team. You can choose either Custom Roles or Sysdig Team-Based Roles. Advanced User is the default. Default Entry Point Yes Select which page of Monitor opens first when a user logs in through this team. The default is Explore. To select a dashboard, open the secondary Dashboard drop-down, or type the name of the dashboard to select it. The drop-down is only populated with shared dashboards accessible to everyone on the team.This setting is only available in Monitor. Zones Yes Zones are in Controlled Availability for Teams. Contact Sysdig Support to request access. This is an experimental feature, and will not work for Vulnerability Management (VM) and Threat Detection. To learn more, see Team Zones.\nSelect zones to allow the team to see data in Inventory, Posture, Compliance, Vulnerabilities, Runtime, Registry and Pipeline. Select All Zones to give the team total visibility.Otherwise, chose Selected Zones to give your team permission to view particular areas. You can create new zones and edit existing zones in Inventory \u0026gt; Zones. Team Scope (Legacy) Yes Determines the highest level of the data to which team members will have visibility.Agent Metrics: If set to Host, Team members can see all Host-level and Container-level information. If set to Container, Team members can see only Container-level information.Prometheus Remote Write Metrics: Visible if Prometheus Remote Write is enabled for your Monitor account. Use this option to determine what level of Prometheus Remote Write data your Team members can view.You can further limit what data team members can see by specifying tag/value expressions for metrics for each data source. The drop-down menu defaults to is, but can be changed to is not, in, contains, and so on. Complex policies can be created through AND chains of several expressions.Note that making changes to the Team Scope settings can have a dramatic impact on what\u0026rsquo;s visualized in the pre-configured Team\u0026rsquo;s Dashboards, so you may want to carefully review these before and after your change. Note that Vulnerability Reports can only be created from the following filters:\nkubernetes.cluster.name\nkubernetes.pod.name\nkubernetes.pod.container.name\nkubernetes.workload.name\nkubernetes.workload.type\ncloudProvider.account.id\ncloudProvider.region\nhost.hostName\nkubernetes.cluster.name\ncloudProvider.account.id\ncloudProvider.name\ncloudProvider.region\nregistry.image.repo\nregistry.name\nregistry.vendor\nAdditional Permissions No Sysdig Capture: Enable this option to allow this team to take Sysdig Captures. The Captures will only be visible to members of this team.WARNING: Captures will include detailed information from every container on a host, regardless of the team\u0026rsquo;s Scope.Agent CLI: Enable this option to give this team access to Using the Agent Console. Infrastructure Events: Enable this option to allow this team to view all Infrastructure and Custom Events from every user and agent. Otherwise, this team will only see infrastructure events sent specifically to this team.Rapid Response: Enable this option to give this Secure team access to Rapid Response. See Rapid Response.AWS Data: Enable this option to give this team access to AWS metrics and tags. All AWS data is made available, regardless of the team\u0026rsquo;s Scope. Team UsersManage the members of a team from the Team Users page. Here, administrators can add and remove users, configure roles, and review team members.\nUsers added in Sysdig Monitor will appear in the full list of users for both Sysdig Monitor and Sysdig Secure, if both products are in use. However, users will not have login access to Sysdig Secure until they are added to a Sysdig Secure team.\nAssign a User to a TeamUsers can be assigned to multiple teams. To add a user to a team:\nLog in to Sysdig Monitor or Sysdig Secure as Admin.\nSelect Settings from the user menu.\nSelect Teams.\nFind the relevant team on the list, or use the search box, and then select the relevant team.\nIn the Team Users section, click Assign User.\nSelect the user from the User drop-down list.\nThe drop-down list supports searching. You can select only one user at a time.\nThe user list contains all users, including Admin users. Admin users are already members of all teams, so those are disabled.\nIf you select a user who is already a member of team and add this user with a different role, the system replaces the existing user role with the newly selected role.\nClick the Role drop-down menu to select the User Role. The role list includes Custom Roles.\nOptional: Repeat steps 5 to 7 for each additional user.\nClick Save.\nRemove a User from a TeamTo remove a user from a team:\nLog in to Secure or Monitor as an Admin.\nSelect Settings \u0026gt; Teams.\nSelect a team.\nThe Edit Team page appears.\nClick the Team Users tab.\nFind the user from the Team Users list.\nYou can use the search box.\nHover over the user\u0026rsquo;s name to make the three-dot menu icon appear on the right.\nClick on the three dot menu, and select Remove user.\nClick Yes to confirm.\nUser RolesFor a detailed overview of roles, review Team-Based Roles and Privileges\nNote that:\nAdvanced User permissions can be further refined into either a View-only User or a Team Manager.\nManagers can add or delete members from a team, or toggle members' rights between Edit, Read, or Manager.\nAdmins have universal rights and are not designated as Team Managers, Advanced Users, View-Only Users, or Standard Users.\nManager or Advanced User permissions can be assigned even to Pending users; administrators do not have to wait for the user\u0026rsquo;s first login to set these roles.\nTo assign a role to a user on a team, see Assign a User to a Team\nUpdate a User RoleTo change the role of a user in a team:\nFind the user from the Team Users list.\nYou can use the search box.\nClick on the three dot menu on the right, and select Update role.\nSelect the preferred role from the Role dropdown.\nClick Save.\nService AccountsApplications or scripts can use Service Accounts to access Sysdig APIs. Service accounts are not bound to a user, but to a team. You can generate as many team service accounts as you need. Each service account has exactly one role.\nService Accounts are team-based and are available when editing a team.\nUnlike users, service accounts have no permissions out of the box. They only have the permissions granted by the role you assign them. In addition, these tokens are not retrievable after they are generated and have a pre-defined retention time.\nCreate a New Service Account Log in to Sysdig Monitor or Sysdig Secure as Admin.\nSelect Settings from the user menu.\nSelect Teams.\nFind the relevant team on the list, or use the search box, and then select the relevant team.\nIn the Service Accounts section, click Add service account.\nDefine the following:\nName: Arbitrary token name Role: Any role. See Team Based Roles and Privileges Expiration: Click to open a calendar, where you can choose a date for the service account to expire. Optional: Repeat steps 5 to 6 for each additional service account.\nClick Save.\nRenew a Service Account TokenService accounts expire after a set period. When this happens, you must generate a new token, and paste it into any scripts or applications that were using the old token. To renew a service account token:\nLog in to Sysdig Monitor or Sysdig Secure as Admin.\nSelect Settings from the user menu.\nSelect Teams.\nSelect the relevant team from the list.\nIn Service Accounts tab, find the service account you want to revew.\nSelect Renew, and confirm Yes.\nCopy the newly generated token ID into any applications or scripts you have configured with the service account.\nExpiry NotificationsYou can configure a notification to appear days before a service account expires, so you can renew the service account token in a timely manner. To set up an expiry notification:\nLog in to Sysdig Monitor or Sysdig Secure as an Admin.\nSelect Settings from the user menu.\nSelect Teams.\nSelect a team with a service account.\nThe Team details page appears.\nSelect the Service Accounts tab.\nFor a new notification setup, select Create Notification Settings. Otherwise, proceed to the next step.\nThe Create Notification Settings for Service Accounts modal appears.\nConfigure the notification settings:\nEnabled: Toggle to enable or disable the notification.\nNotification reminders: Choose how many days before expiration you want to be reminded. For example, you can be notified of an upcoming expiration a month, a week, and a day in advance. You can create up to 5 notification reminders, and up to 60 days in advance.\nNotification channels: Select the notification channel through which you want to be notified. You cannot select a notification channel that is not shared with the team that owns the service account. See Share a Notification Channel. You can select up to 5 notification channels to use. You must select at least one notification reminder and at least one notification channel before you can save the settings.\nOnce you have selected at least one notification reminder, and at least one notification channel, select Save Settings.\nOnce a Service Account Notification Setting is saved, you can edit it or delete it from the Service Accounts tab on that team page:\nTo edit existing Service Account Notification Settings select Edit notification settings.\nTo delete existing Service Account Notification Settings select Delete notification settings.\nAlternatively, you can manage service account expiry notification settings via the API:\nLog in to Sysdig Secure or Sysdig Monitor.\nFrom the user menu in the bottom left corner, select Next Gen API Docs.\nProvide your login credentials.\nThe Next Gen API documentation page appear.\nSelect Service Account Notification Settings.\nHere, you can create, edit and delete expiry notifications for service account tokens. To learn more about our API, see Sysdig API.\nDelete a TeamWhen a team is deleted, some users may become \u0026ldquo;orphans\u0026rdquo;, as they are no longer a part of any team. These users will be moved to the default team.\nThe default team cannot be deleted. A new default team must be selected before the old default team can be deleted.\nTo delete a created team:\nLog in to Monitor or Secure as Admin.\nSelect Settings from the user menu.\nSelect Teams.\nSelect the relevant team from the list, or\nYou can search for it with the search box.\nClick Delete Team, then Yes, delete to confirm the change.\n","url":"https://docs.sysdig.com/en/administration/teams-administration/"},{"id":343,"title":"Manual Installation on Kubernetes","content":" All on-premises installations and upgrades are now scheduled with and guided by Sysdig technical account managers and professional services division. See Oversight Services Now Offered for All Installs and Upgrades. For customers, the instructions in this section are for review purposes only.\nWhen installing the Sysdig platform with Kubernetes as the orchestrator, you install each backend component with separate kubectl commands.\nInstallation with the Installer tool is recommended from version 2.5.0 onwards. To perform a manual install on OpenShift, see Manual Install (OpenShift). The manual install on Kubernetes 1.9+ is described below.\nPrerequisites Access to a running Kubernetes cluster 1.9+\n(Note: if your environment is installed elsewhere, such as your own data center, contact Sysdig Professional Services to customize the installation instructions appropriately.)\nTwo items from your Sysdig purchase-confirmation email:\nYour Sysdig license key\nYour Sysdig quay.io pull secret\nkubectl installed on your machine and communicating with the Kubernetes cluster\n(Note that your kubectl and Kubernetes versions should match to avoid errors.)\nAn External Load Balancer (required for production – see below)\nIf installing in a cloud-provider environment (such as AWS, GCloud, or Azure), you will deploy an HAProxy load balancer and point a DNS record to that load balancer.\nIf installing in your own data center, then you will need two DNS records, one for the collector and one for the UI.\nA DNS server and control over a DNS name that you can point to Sysdig\nConsider Elasticsearch Default PrivilegesBy default, the Elasticsearch container will be installed in privileged (root-access) mode. This mode is only needed so the container can reconfigure the hosts\u0026rsquo; Linux file descriptors if necessary. See Elasticsearch\u0026rsquo;s description here.\nIf you prefer not to allow Elasticsearch to run with root access to the host, you will need to:\nSet your own file descriptors on all Linux hosts in the Kubernetes cluster.\nIf one host were to go down, Kubernetes could choose a different node for Elasticsearch, so each Linux host must have the file descriptors set.\nSet privileged:false in the elasticsearch-statefulset.yaml file.\nSee the step under Configure Backend Components, below, for details.\nConfigure Storage ClassIf you are using EKS or GKE, default storage classes are provided; check for them (step 1).\nIn other environments, you may need to create a storage class (step 2).\nFinally, enter the storageClassName in the appropriate .yaml files (step 3).\nVerify whether a storage class has been created, by running the command:\nkubectl get storageclass If no storage class has been defined, create a manifest for one, and then deploy it.\nFor example, a manifest could be named sysdigcloud-storageclass.yamland contain the following contents (for a storage class using GP2 volumes in AWS):\napiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: gp2 annotations: storageclass.beta.kubernetes.io/is-default-class: \u0026#34;true\u0026#34; labels: kubernetes.io/cluster-service: \u0026#34;true\u0026#34; addonmanager.kubernetes.io/mode: EnsureExists provisioner: kubernetes.io/aws-ebs parameters: type: gp2 Now run the command:\nkubectl apply -f sysdigcloud-storageclass.yaml Download the Source Files to a New NamespaceSysdig provides the necessary scripts, images, and .yaml files in a GitHub repository. The first step is to clone those files and check out the latest version. (These examples use 1234.)\nFind the current release tag from https://github.com/draios/sysdigcloud-kubernetes/releases/latest.\nRun the command:\ngit clone https://github.com/draios/sysdigcloud-kubernetes.git cd sysdigcloud-kubernetes git checkout tags/\u0026lt;1234\u0026gt; Create a namespace called sysdigcloud:\nkubectl create namespace sysdigcloud Add External Load BalancerCreate a TCP load balancer (i.e., AWS NLB) that forwards ports 80, 443, 6443 to the Kubernetes worker nodes, with a healthcheck to /healthz on port 10253.\nThis can be done in three ways:\nUse an existing external load balancer. Sysdig relies heavily on DNS; you need a DNS record pointing to the load balancer.\nCreate a load balancer in your cloud provider. (For example in AWS, see https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-network-load-balancer.html.) You need a DNS record that points to the load balancer. This is the fully qualified domain name required later in the config.yaml, api-ingress.yaml and/or api-ingress-with-secure.yaml.\nCreate a yaml with the following content and apply it to the sysdigcloud namespace. This automatically creates a load balancer in the cloud provider environment, with an external DNS name.\nThis is the fully qualified domain name required later in the config.yaml, api-ingress.yaml and/or api-ingress-with-secure.yaml.\napiVersion: v1 kind: Service metadata: name: haproxy-ingress-lb-service spec: type: LoadBalancer ports: - name: http port: 80 targetPort: 80 - name: https port: 443 targetPort: 443 - name: https2 port: 6443 targetPort: 6443 selector: run: haproxy-ingress Apply the changes to the sysdigcloud namespace.\nkubectl -n sysdigcloud apply -f \u0026lt;yourlbfile.yamlservice.yaml\u0026gt; To get the DNS name, run the command:\nkubectl get svc -o wide -n sysdigcloud The output shows the External-IP (DNS name):\nNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR haproxy-ingress-lb-service LoadBalancer 100.66.118.183 sample123.us-east-1.elb.amazonaws.com 80:31688/TCP,443:32324/TCP,6443:30668/TCP 1d run=haproxy-ingress DNS Entry (For Test Environments without a Load Balancer) Not for production environments.\nCreate a DNS entry for your Sysdig install using the fully qualified domain name that contains all the external IPs as A records. This will use DNS round-robin to load balance your clients to the Kubernetes cluster.\nPrepare the EnvironmentThe install images, scripts, and other files are located in a GitHub repository:https://github.com/draios/sysdigcloud-kubernetes\nStep 1 Configure Backend ComponentsThe ConfigMap (config.yaml) is populated with information about usernames, passwords, SSL certs, and various application-specific settings.\nThe steps below give the minimum edits that should be performed in a test environment.\nIt is necessary to review and customize the entries in config.yaml before launching in a production environment.\nSee Apply Configuration Changes for the kubectl format to use for post-install edits, such as adding third-party authenticators like LDAP.\nIf you are not installing Sysdig Secure, set the following attributes to false in the config.yaml:\nnats.enabled: \u0026quot;false\u0026quot; nats.forward.enabled: \u0026quot;false\u0026quot; Add your license key:\nIn config.yaml, enter the key that was emailed to you in the following parameter:\n# Required: Sysdig Cloud license sysdigcloud.license: \u0026#34; Change the super admin name and password, which are the super admin credentials for the entire system. See here for details.\nFind the settings in config.yaml here:\nsysdigcloud.default.user: test@sysdig.com # Required: Sysdig Cloud super admin user password # NOTE: Change upon first login sysdigcloud.default.user.password: test Change the mysql.password from change_me to desired credentials.\nmysql.password: change_me # Required: Cassandra endpoint DNS/IP. If Cassandra is deployed as a Kubernetes service, this will be the service name. # If using an external database, put the proper address (the address of a single node will be sufficient) **Edit the collector endpoint and api-url:**Change the defaults (sysdigcloud-collector and sysdigcloud-api:443) to point to the DNS name you have established for Sysdig.\nNote: The collector port should remain 6443.\ncollector.endpoint: \u0026lt;DNS_NAME\u0026gt; collector.port: \u0026#34;6443\u0026#34; api.url: https://\u0026lt;DNS_NAME\u0026gt;:443 Recommended: edit the file to set the JVM options for Cassandra, Elasticsearch, and API, worker, and collector as well.\n(To use the AWS implicit key, edit the JVM options as described in AWS: Integrate AWS Account and CloudWatch Metrics (Optional).)\nFor installations over 100 agents, it is recommended to allocate 8 GB per JVM.\ncassandra.jvm.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; elasticsearch.jvm.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; sysdigcloud.jvm.api.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; sysdigcloud.jvm.worker.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; sysdigcloud.jvm.collector.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; Note: If you do not wish to use SSL between the agent and the collector, use the following settings instead:\ncassandra.jvm.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; elasticsearch.jvm.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; sysdigcloud.jvm.api.options: \u0026#34;-Xms8G -Xmx8G -Ddraios.agents.installParams.sslEnabled=false\u0026#34; sysdigcloud.jvm.worker.options: \u0026#34;-Xms8G -Xmx8G -Ddraios.agents.installParams.sslEnabled=false\u0026#34; sysdigcloud.jvm.collector.options: \u0026#34;-Xms8G -Xmx8G -Ddraios.agents.installParams.sslEnabled=false\u0026#34; See also: Step 5: Set Up SSL Connectivity to the Backend.\nOptional: Change ElasticSearch container setting to non-privileged.\nTo change the default setting, edit the file elasticsearch-statefulset.yamland set privileged: false.\ncontainers: - name: elasticsearch image: quay.io/sysdig/elasticsearch:5.6.16.15 securityContext: privileged: false Deploy the configuration map and secrets for all services by running the commands:\nFor Sysdig Monitor:\nkubectl -n sysdigcloud apply -f sysdigcloud/config.yaml To add Sysdig Secure:\nkubectl -n sysdigcloud apply -f sysdigcloud/scanning-secrets.yaml kubectl -n sysdigcloud apply -f sysdigcloud/anchore-secrets.yaml Apply the secret for the policy advisor:\nkubectl -n sysdigcloud apply -f sysdigcloud/policy-advisor-secret.yaml Configure DNS name inapi-ingress.yaml (or api-ingress-with-secure.yaml if using Secure). (Files located in sysdigcloud/)\nEdit: host: \u0026lt;EXTERNAL-DNS-NAME\u0026gt; to suit your DNS name\nDefine namespace in ingress-clusterrolebinding.yaml. (File located in sysdigcloud/ingress_controller/) Edit namespace: sysdigcloud\nStep 2 Add Storage Class to ManifestsUsing either the existing storage class name from step 1, or the storage class name defined in the previous step, edit the storageClassName in the following .yaml files:\nFor Monitor:\ndatastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml datastores/as_kubernetes_pods/manifests/mysql/mysql-deployment.yaml With Secure:\ndatastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml Step 3 (Secure-Only): Edit mysql-deployment yamlIf using Sysdig Secure:\nEdit the MySQL deployment to uncomment the MYSQL_EXTRADB_* environment variables.\nThis forces MySQL to create the necessary scanning database on startup.\nFile location: datastores/as_kubernetes_pods/manifests/mysql/mysql-deployment.yaml\n- name: MYSQL_EXTRADB_SCANNING_DBNAME valueFrom: configMapKeyRef: name: sysdigcloud-config key: scanning.mysql.dbname - name: MYSQL_EXTRADB_SCANNING_USER valueFrom: configMapKeyRef: name: sysdigcloud-config key: scanning.mysql.user - name: MYSQL_EXTRADB_SCANNING_PASSWORD valueFrom: secretKeyRef: name: sysdigcloud-scanning key: scanning.mysql.password The scanning service will not start unless MySQL creates the scanning database.\nStep 4 Deploy Your Quay Pull SecretA specific Quay pull secret is sent via email with your license key.\nEdit the file sysdigcloud/pull-secret.yaml and change the place holder \u0026lt;PULL_SECRET\u0026gt; with the provided pull secret.\nDeploy the pull secret object:\nkubectl -n sysdigcloud apply -f sysdigcloud/pull-secret.yaml Step 5 Set Up SSL Connectivity to the BackendSSL-secured communication is used between user browsers and the Sysdig API server(s), and between the Sysdig agent and the collectors.\nTo set this up, you must:\nUse existing standard certs for API and collector, or\nCreate self-signed certificates and keys for API and collector\nTo Disable SSL between Agent and CollectorTo disable SSL between agents and collectors, set JVM options when configuring backend components.\nTo Create Self-Signed CertsRun these commands (edit to add your API_DNS_NAMEand COLLECTOR_DNS_NAME):\nopenssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj \u0026#34;/C=US/ST=CA/L=SanFrancisco/O=ICT/CN=\u0026lt;API_DNS_NAME\u0026gt;\u0026#34; -keyout server.key -out server.crt openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj \u0026#34;/C=US/ST=CA/L=SanFrancisco/O=ICT/CN=\u0026lt;COLLECTOR_DNS_NAME\u0026gt;\u0026#34; -keyout collector.key -out collector.crt To Create Kubernetes SecretsThis uses two different certificates, one for the API/UI, and one for the collector.\nkubectl -n sysdigcloud create secret tls sysdigcloud-ssl-secret --cert=server.crt --key=server.key kubectl -n sysdigcloud create secret tls sysdigcloud-ssl-secret-collector --cert=collector.crt --key=collector.key Step 6 (Optional) Use CA Certs for External SSL ConnectionThe Sysdig platform may sometimes open connections over SSL to certain external services, including:\nLDAP over SSL\nSAML over SSL\nOpenID Connect over SSL\nHTTPS Proxies\nIf the signing authorities for the certificates presented by these services are not well-known to the Sysdig Platform (e.g., if you maintain your own Certificate Authority), they are not trusted by default.\nTo allow the Sysdig platform to trust these certificates, use the command below to upload one or more PEM-format CA certificates. You must ensure you\u0026rsquo;ve uploaded all certificates in the CA approval chain to the root CA.\nkubectl -n sysdigcloud create secret generic sysdigcloud-java-certs --from-file=certs1.crt --from-file=certs2.crt Install ComponentsInstall Datastores and Backend ComponentsFor Sysdig Monitor:\nCreate the datastore statefulsets for Elasticsearch and Cassandra. Elasticsearch and Cassandra are automatically set up with --replica=3 generating full clusters.\nkubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-service.yaml kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-service.yaml kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml Wait for those processes to be running, then create the database and caching systems: MySQL, and Redis.\nkubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/mysql/mysql-deployment.yaml kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/redis/redis-deployment.yaml To add Sysdig Secure: Create the PostgreSQL database:\nkubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-service.yaml kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml Wait until datastore pods are in ready state:\nRun the command:\nkubectl -n sysdigcloud get pods Then look in the READY column to ensure all pods are ready. For example, displaying a 1/1 means 1 of 1 pods is ready\nApply the NATS service and deployment to deliver events to Sysdig backend components:\nkubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/nats-streaming/nats-streaming-deployment.yaml kubectl -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/nats-streaming/nats-streaming-service.yaml Apply the API deployment. Pause until all containers in the API pod are running, then apply the collector and worker deployments.\nkubectl -n sysdigcloud apply -f sysdigcloud/api-deployment.yaml kubectl -n sysdigcloud apply -f sysdigcloud/collector-deployment.yaml kubectl -n sysdigcloud apply -f sysdigcloud/worker-deployment.yaml Create the service for the API and collector:\nkubectl -n sysdigcloud apply -f sysdigcloud/api-headless-service.yaml kubectl -n sysdigcloud apply -f sysdigcloud/collector-headless-service.yaml Sysdig Secure only Create anchore-engine deployments and service (used in scanning):\nkubectl -n sysdigcloud apply -f sysdigcloud/anchore-service.yaml kubectl -n sysdigcloud apply -f sysdigcloud/anchore-core-config.yaml kubectl -n sysdigcloud apply -f sysdigcloud/anchore-core-deployment.yaml kubectl -n sysdigcloud apply -f sysdigcloud/anchore-worker-config.yaml kubectl -n sysdigcloud apply -f sysdigcloud/anchore-worker-deployment.yaml Wait 60 seconds to ensure the Anchore components are up and running. Then deploy custom Sysdig Secure scanning components:\nkubectl -n sysdigcloud apply -f sysdigcloud/scanning-service.yaml kubectl -n sysdigcloud apply -f sysdigcloud/scanning-api-deployment.yaml kubectl -n sysdigcloud apply -f sysdigcloud/scanning-alertmgr-service.yaml kubectl -n sysdigcloud apply -f sysdigcloud/scanning-alertmgr-deployment.yaml Sysdig Secure only Create services, deployments, and a janitor job for the activity audit and policy advisor features:\nkubectl -n sysdigcloud apply -f sysdigcloud/policy-advisor-service.yaml kubectl -n sysdigcloud apply -f sysdigcloud/activity-audit-api-service.yaml kubectl -n sysdigcloud apply -f sysdigcloud/activity-audit-api-deployment.yaml kubectl -n sysdigcloud apply -f sysdigcloud/policy-advisor-deployment.yaml kubectl -n sysdigcloud apply -f sysdigcloud/activity-audit-worker-deployment.yaml kubectl -n sysdigcloud apply -f sysdigcloud/activity-audit-janitor-cronjob.yaml Connecting to the ClusterAdd Cluster-Admin to User (GKE/GCloud Only)kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user $(gcloud config get-value account) Add Ingress ControllerFor Sysdig Monitor:\nTo permit incoming connections to the Sysdig API and collector, deploy the following ingress yaml files.\nkubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-clusterrole.yaml kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-clusterrolebinding.yaml kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-role.yaml kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-rolebinding.yaml kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-serviceaccount.yaml kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/default-backend-service.yaml kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/default-backend-deployment.yaml kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-configmap.yaml kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-tcp-services-configmap.yaml kubectl -n sysdigcloud apply -f sysdigcloud/ingress_controller/ingress-daemonset.yaml If NOT using Sysdig Secure, then apply the following ingress.yaml:\nkubectl -n sysdigcloud apply -f sysdigcloud/api-ingress.yaml For Sysdig Secure:\nIf you ARE using Secure, replace the api-ingress.yaml with the following line:\nkubectl -n sysdigcloud apply -f sysdigcloud/api-ingress-with-secure.yaml Install CompleteWhen the terminal messages indicate that installation was successfully completed:\nPoint your browser tohttps://API_DNS_NAME.\nYou will be prompted to log in with the Admin credentials you set in Step 2 Configure Backend Components.\nLog in as Super Admin.\nThe Welcome Wizard is launched and prompts you to install your first Sysdig agent.\nInstall the agent(s).\nThe Welcome Wizard should be populated with install parameters from your environment (access key, collector name, and collector port). For example:\ndocker run -d --name sysdig-agent --restart always --privileged --net host --pid host -e ACCESS_KEY=xxxxxxxxxx -e COLLECTOR=abc.us-west.elb.amazonaws.com -e COLLECTOR_PORT=6443 -e CHECK_CERTIFICATE=false -e TAGS=example_tag:example_value -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro --shm-size=350m quay.io/sysdig/agent Apply Configuration ChangesReplace kubectl with oc for OpenShift.\nUpdate the Config MapThere are two ways to change the original installation parameters in the config map: edit or overwrite.\nTo edit the config map, run the following command:\nkubectl edit configmap/sysdigcloud-config --namespace sysdigcloud A text editor is presented with the config map to be edited. Enter parameters as needed, then save and quit.\nThen restart the config map (below).\nTo overwrite the config map that is edited on the client-side, (e.g. to keep it synced in a git repository), use the following command:\nkubectl replace -f sysdigcloud/config.yaml --namespace sysdigcloud Then restart the config map (below).\nRestart ConfigmapAfter updating the configmap, the Sysdig components must be restarted for the changed parameters to take effect. This can be done by forcing a rolling update of the deployments.\nA possible way to do so is to change something innocuous, which forces a rolling update. E.g.:\nkubectl -n sysdigcloud patch deployment [deploymnet] -p \\ \u0026#34;{\\\u0026#34;spec\\\u0026#34;:{\\\u0026#34;template\\\u0026#34;:{\\\u0026#34;metadata\\\u0026#34;:{\\\u0026#34;annotations\\\u0026#34;:{\\\u0026#34;date\\\u0026#34;:\\\u0026#34;$(date +\u0026#39;%s\u0026#39;)\\\u0026#34;}}}}}\u0026#34; Replace kubectl with oc for OpenShift.\n","url":"https://docs.sysdig.com/en/administration/onprem-manual-installation-kubernetes/"},{"id":344,"title":"Mapping Legacy Sysdig Kubernetes Metrics with Prometheus Metrics","content":"For descriptions on Kubernetes State Metrics, see Kubernetes State Metrics.\nResource\nSysdig Metrics\nKubernetes State Metrics\nLabel\nExample / More Information\nPod\nkubernetes.pod.containers.waiting\nkube_pod_container_status_waiting\ncontainer_name=\u0026lt;container-name\u0026gt;\nkube_pod_name=\u0026lt;pod-name\u0026gt;\nkube_namespace_name=\u0026lt;pod-namespace\u0026gt;\nkubernetes.pods.limits_cpu_cores\nkubernetes.pods.limits_mem_bytes\nkubernetes.pods.limits_cpu_cores\nkube_pod_container_resource_limits\nkube_pod_sysdig_resource_limits_memory_bytes\nkube_pod_sysdig_resource_limits_cpu_cores\nresource=\u0026lt;resource-name\u0026gt;\nunit=\u0026lt;resource-unit\u0026gt;\nkube_pod_name=\u0026lt;pod-name\u0026gt;\nkube_namespace_name=\u0026lt;pod-namespace\u0026gt;\nkube_node_name=\u0026lt; node-name\u0026gt;\n{kube_namespace_name=\"default\",kube_pod_name=\"pod0\",container=\"pod1_con1\",resource=\"cpu\",unit=\"core\"}\n{kube_namespace_name=\"default\",kube_pod_name=\"pod0\",container=\"pod1_con1\",resource=\"memory\",unit=\"byte\"}\nkubernetes.pods.requests_cpu_cores\nkubernetes.pods.requests_mem_bytes\nkube_pod_container_resource_requests\nkube_pod_sysdig_resource_requests_cpu_cores\nkube_pod_sysdig_resource_requests_memory_bytes\nresource=\u0026lt;resource-name\u0026gt;\nunit=\u0026lt;resource-unit\u0026gt;\ncontainer_name=\u0026lt;container-name\u0026gt;\nkube_pod_name=\u0026lt;pod-name\u0026gt;\nkube_namespace_name=\u0026lt;pod-namespace\u0026gt;\nkube_node_name=\u0026lt; node-name\u0026gt;\n{kube_namespace_name=\"default\",kube_pod_name=\"pod0\",container=\"pod1_con1\",resource=\"cpu\",unit=\"core\"}\n{kube_namespace_name=\"default\",kube_pod_name=\"pod0\",container=\"pod1_con1\",resource=\"memory\",unit=\"byte\"}\nkubernetes.pods.status_ready\nkube_pod_status_ready\nkube_pod_name=\u0026lt;pod-name\u0026gt;\nkube_namespace_name=\u0026lt;pod-namespace\u0026gt;\ncondition=\u0026lt;true|false|unknown\u0026gt;\nkubernetes.pods.common\nkubernetes.pods.containers_ids\nkubernetes.pods.host_ip\nkubernetes.pods.internal_ip\nkubernetes.pods.node_name\nkube_pod_info\nkube_pod_name=\u0026lt;pod-name\u0026gt;\nkube_namespace_name=\u0026lt;pod-namespace\u0026gt;\nhost_ip=\u0026lt;host-ip\u0026gt;\nkube_pod_name_ip=\u0026lt;pod-ip\u0026gt;\nkube_node_name=\u0026lt;node-name\u0026gt;\nkube_pod_uid=\u0026lt;pod-uid\u0026gt;\n{kube_namespace_name=\"default\",kube_pod_name=\"pod0\",host_ip=\"1.1.1.1\",pod_ip=\"1.2.3.4\",kube_pod_uid=\"abc-0\",kube_node_name=\"node1\",created_by_kind=\"\u0026lt;none\u0026gt;\",created_by_name=\"\u0026lt;none\u0026gt;\",priority_class=\"\"}\nkube_pod_owner\nkube_pod_name=\u0026lt;pod-name\u0026gt;\nkube_namespace_name=\u0026lt;pod-namespace\u0026gt;\nowner_kind=\u0026lt;owner kind\u0026gt;\nowner_name=\u0026lt;owner name\u0026gt;\n{kube_namespace_name=\"default\",kube_pod_name=\"pod0\",owner_kind=\"\u0026lt;none\u0026gt;\",owner_name=\"\u0026lt;none\u0026gt;;\",owner_is_controller=\"\u0026lt;none\u0026gt;\"}\nkubernetes.pods.common\nkube_pod_labels\nkube_pod_name=\u0026lt;pod-name\u0026gt;\nkube_namespace_name=\u0026lt;pod-namespace\u0026gt;\nlabel_pod_label=\u0026lt;POD_LABEL\u0026gt;\n{kube_namespace_name=\"default\",kube_pod_name=\"pod0\", label_app=\"myApp\"}\nkube_pod_container_info\nkube_pod_name=\u0026lt;pod-name\u0026gt;\nkube_namespace_name=\u0026lt;pod-namespace\u0026gt;\ncontainer_id=\u0026lt;containerid\u0026gt;\n{kube_namespace_name=\"default\",kube_pod_name=\"pod0\",container=\"container2\",image=\"k8s.gcr.io/hyperkube2\",image_id=\"docker://sha256:bbb\",container_id=\"docker://cd456\"}\nnode\nkubernetes.nodes.allocatable_cpu_cores\nkube_node_status_allocatable_cpu_cores\nkube_node_name=\u0026lt;node-address\u0026gt;\nresource=\u0026lt;resource-name\u0026gt;\nunit=\u0026lt;resource-unit\u0026gt;\nkube_node_name=\u0026lt;node-address\u0026gt;\nresource/unit have one of the values: (cpu, core); (memory, byte); (pods, integer). Sysdig currently supports only CPU, pods, and memory resources for kube_node_status_capacity metrics.\n\u0026quot;# HELP kube_node_status_capacity The capacity for different resources of a node. kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-master\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;hugepages_1Gi\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;byte\u0026quot;\u0026quot;} 0 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-master\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;hugepages_2Mi\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;byte\u0026quot;\u0026quot;} 0 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-master\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;memory\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;byte\u0026quot;\u0026quot;} 4.16342016e+09 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-master\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;pods\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;integer\u0026quot;\u0026quot;} 110 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node1\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;pods\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;integer\u0026quot;\u0026quot;} 110 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node1\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;cpu\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;core\u0026quot;\u0026quot;} 2 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node1\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;hugepages_1Gi\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;byte\u0026quot;\u0026quot;} 0 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node1\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;hugepages_2Mi\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;byte\u0026quot;\u0026quot;} 0 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node1\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;memory\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;byte\u0026quot;\u0026quot;} 6.274154496e+09 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node2\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;hugepages_1Gi\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;byte\u0026quot;\u0026quot;} 0 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node2\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;hugepages_2Mi\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;byte\u0026quot;\u0026quot;} 0 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node2\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;memory\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;byte\u0026quot;\u0026quot;} 6.274154496e+09 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node2\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;pods\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;integer\u0026quot;\u0026quot;} 110 kube_node_status_capacity{kube_node_name=\u0026quot;\u0026quot;k8s-node2\u0026quot;\u0026quot;,resource=\u0026quot;\u0026quot;cpu\u0026quot;\u0026quot;,unit=\u0026quot;\u0026quot;core\u0026quot;\u0026quot;} 2 kubernetes.nodes.allocatable_mem_bytes\nkube_node_status_allocatable_memory_bytes\nkubernetes.nodes.allocatable_pods\nkube_node_status_allocatable_pods\nkubernetes.nodes.capacity_cpu_cores\nkube_node_status_capacity_cpu_cores\nkube_node_name=\u0026lt;node-address\u0026gt;\nresource=\u0026lt;resource-name\u0026gt;\nunit=\u0026lt;resource-unit\u0026gt;\nkube_node_name=\u0026lt;node-address\u0026gt;\nkubernetes.nodes.capacity_mem_bytes\nkube_node_status_capacity_memory_bytes\nkubernetes.nodes.capacity_pods\nkube_node_status_capacity_pods\nkubernetes.nodes.disk_pressure\nkubernetes.nodes.mem_pressure\nkubernetes.nodes.net_unavailable\nkubernetes.nodes.out_of_disk\nkubernetes.nodes.ready\nkube_node_status_condition\nkube_node_name=\u0026lt;node-address\ncondition=\u0026lt;node-condition\u0026gt;\nstatus=\u0026lt;true|false|unknown\u0026gt;\nkubernetes.nodes.unschedulable\nkube_node_spec_unschedulable\nkube_node_name=\u0026lt;node-address\u0026gt;\nkubernetes.nodes.common kube_node_info\nkube_node_name=\u0026lt;node-address\u0026gt;\nkubernetes.nodes.common kube_node_labels\nkube_node_name=\u0026lt;node-address\u0026gt;\nlabel_NODE_LABEL=\u0026lt;NODE_LABEL\u0026gt;\nDeployment\nkubernetes.deployment.replicas.available\nkube_deployment_status_replicas_available\nkube_deployment_name=\u0026lt;deployment-name\u0026gt;\nkube_namespace_name=\u0026lt;deployment-namespace\u0026gt;\nkube_deployment_spec_replicas\nkube_deployment_spec_paused\nkube_deployment_status_replicas\nkube_deployment_status_replicas_unavailable\nkube_deployment_status_replicas_updated\nkube_deployment_labels\njob\nkubernetes.jobs.completions\nkube_job_spec_completions\njob_name=\u0026lt;job-name\u0026gt;\nkube_namespace_name=\u0026lt;job-namespace\u0026gt;\nkubernetes.jobs.num_failed\nkube_job_failed\nkubernetes.jobs.num_succeeded\nkube_job_complete\nkubernetes.jobs.parallelism\nkube_job_spec_parallelism\nkubernetes.jobs.status_active kube_job_status_active\nkubernetes.jobs.common kube_job_info\nkube_job_owner\njob_name=\u0026lt;job-name\u0026gt;\nkube_namespace_name=\u0026lt;job-namespace\u0026gt;\nowner_kind=\u0026lt;owner kind\u0026gt;\nowner_name=\u0026lt;owner name\u0026gt;\nkubernetes.jobs.common kube_job_labels\njob_name=\u0026lt;job-name\u0026gt;\nkube_namespace_name=\u0026lt;job-namespace\u0026gt;\nlabel_job_label=\u0026lt;job_label\u0026gt;\ndaemonSet\nkubernetes.daemonsets.desired_scheduled\nkube_daemonset_status_desired_number_scheduled\ndaemonset=\u0026lt;daemonset-name\u0026gt;\nkube_namespace_name=\u0026lt;daemonset-namespace\u0026gt;\nkubernetes.daemonsets.pods_misscheduled\nkube_daemonset_status_number_misscheduled\nkubernetes.daemonSet.pods.ready\nkube_daemonset_status_number_ready\nkubernetes.daemonSet.pods.scheduled\nkube_daemonset_status_current_number_scheduled\nkube_daemonset_labels\ndaemonset=\u0026lt;daemonset-name\u0026gt;\nkube_namespace_name=\u0026lt;daemonset-namespace\u0026gt;\nlabel_daemonset_label=\u0026lt;daemonset_label\u0026gt;\nreplicaSet\nkube_replicaset_status_fully_labeled_replicas\nreplicaset=\u0026lt;replicaset-name\u0026gt;\nkube_namespace_name=\u0026lt;replicaset-namespace\u0026gt;\nkube_replicaset_status_ready_replicas\nkube_replicaset_status_replicas\nkube_replicaset_spec_replicas\nkube_replicaset_owner\nreplicaset=\u0026lt;replicaset-name\u0026gt;\nkube_namespace_name=\u0026lt;replicaset-namespace\u0026gt;\nowner_kind=\u0026lt;owner kind\u0026gt;\nowner_name=\u0026lt;owner name\u0026gt;\nkube_replicaset_labels\nlabel_replicaset_label=\u0026lt;replicaset_label\u0026gt;\nreplicaset=\u0026lt;replicaset-name\u0026gt;\nkube_namespace_name=\u0026lt;replicaset-namespace\u0026gt;\nstatefulset\nkubernetes.statefulsets.replicas\nkube_statefulset_replicas\nstatefulset=\u0026lt;statefulset-name\u0026gt;\nkube_namespace_name=\u0026lt;statefulset-namespace\u0026gt;\nkubernetes.statefulset.status.replicas\nkube_statefulset_status_replicas\nkubernetes.statefulset.status.replicas.current\nkube_statefulset_status_replicas_current\nkubernetes.statefulset.status.replicas.ready\nkube_statefulset_status_replicas_ready\nkubernetes.statefulset.status.replicas.updated\nkube_statefulset_status_replicas_updated\nkube_statefulset_labels\nhpa\nkubernetes.hpa.replicas.min\nkube_horizontalpodautoscaler_spec_min_replicas\nhpa=\u0026lt;hpa-name\u0026gt;\nkube_namespace_name=\u0026lt;hpa-namespace\u0026gt;\nkubernetes.hpa.replicas.max\nkube_horizontalpodautoscaler_spec_max_replicas\nkubernetes.hpa.replicas.current\nkube_horizontalpodautoscaler_status_current_replicas\nkubernetes.hpa.replicas.desired\nkube_horizontalpodautoscaler_status_desired_replicas\nkube_horizontalpodautoscaler_labels\nresourcequota\nkubernetes.resourcequota.configmaps.hard\nkubernetes.resourcequota.configmaps.used\nkubernetes.resourcequota.limits.cpu.hard\nkubernetes.resourcequota.limits.cpu.used\nkubernetes.resourcequota.limits.memory.hard\nkubernetes.resourcequota.limits.memory.used\nkubernetes.resourcequota.persistentvolumeclaims.hard\nkubernetes.resourcequota.persistentvolumeclaims.used\nkubernetes.resourcequota.cpu.hard\nkubernetes.resourcequota.memory.hard\nkubernetes.resourcequota.pods.hard\nkubernetes.resourcequota.pods.used\nkubernetes.resourcequota.replicationcontrollers.hard\nkubernetes.resourcequota.replicationcontrollers.used\nkubernetes.resourcequota.requests.cpu.hard\nkubernetes.resourcequota.requests.cpu.used\nkubernetes.resourcequota.requests.memory.hard\nkubernetes.resourcequota.requests.memory.used\nkubernetes.resourcequota.requests.storage.hard\nkubernetes.resourcequota.requests.storage.used\nkubernetes.resourcequota.resourcequotas.hard\nkubernetes.resourcequota.resourcequotas.used\nkubernetes.resourcequota.secrets.hard\nkubernetes.resourcequota.secrets.used\nkubernetes.resourcequota.services.hard\nkubernetes.resourcequota.services.used\nkubernetes.resourcequota.services.loadbalancers.hard\nkubernetes.resourcequota.services.loadbalancers.used\nkubernetes.resourcequota.services.nodeports.hard\nkubernetes.resourcequota.services.nodeports.used\nkube_resourcequota\nresourcequota=\u0026lt;quota-name\u0026gt;\nkube_namespace_name=\u0026lt;namespace\u0026gt;\nresource=\u0026lt;ResourceName\u0026gt;\ntype=\u0026lt;quota-type\u0026gt;\nnamespace\nkube_namespace_labels\nkube_namespace_name=\u0026lt;namespace-name\u0026gt;\nlabel_ns_label=\u0026lt;ns_label\u0026gt;\nreplicationcontroller\nkubernetes.replicationcontroller.replicas.desired\nkube_replicationcontroller_spec_replicase\nreplicationcontroller=\u0026lt;replicationcontroller-name\u0026gt;\nkube_namespace_name=\u0026lt;replicationcontroller-namespace\u0026gt;\nkubernetes.replicationcontroller.replicas.running\nkube_replicationcontroller_status_replicas\nkube_replicationcontroller_status_fully_labeled_replicas\nkube_replicationcontroller_status_ready_replicas\nkube_replicationcontroller_status_available_replicas\nkube_replicationcontroller_status_observed_generation\nkube_replicationcontroller_metadata_generation\nkube_replicationcontroller_created\nkube_replicationcontroller_owner\nreplicationcontroller=\u0026lt;replicationcontroller-name\u0026gt;\nkube_namespace_name=\u0026lt;replicationcontroller-namespace\u0026gt;\nowner_kind=\u0026lt;owner kind\u0026gt;\nowner_name=\u0026lt;owner name\u0026gt;\nservice\nkube_service_info\nservice=\u0026lt;service-name\u0026gt;\nkube_namespace_name=\u0026lt;service-namespace\u0026gt;\ncluster_ip=\u0026lt;service cluster ip\u0026gt;\nexternal_name=\u0026lt;service external name\u0026gt;\nload_balancer_ip=\u0026lt;service load balancer ip\u0026gt;\nkube_service_labels\nservice=\u0026lt;service-name\u0026gt;\nkube_namespace_name=\u0026lt;service-namespace\u0026gt;\nlabel_service_label=\u0026lt;service_label\u0026gt;\npersistentvolume\nkubernetes.persistentvolume.storage\nkube_persistentvolume_capacity_bytes\npersistentvolume=\u0026lt;pv-name\u0026gt;\nkube_persistentvolume_info\npersistentvolume=\u0026lt;pv-name\u0026gt;\nkube_persistentvolume_labels\npersistentvolume=\u0026lt;pv-name\u0026gt;\nkube_namespace_name=\u0026lt;label_persistentvolume_label=\u0026lt;persistentvolume_label\u0026gt;\npersistentvolumeclaim\nkubernetes.persistentvolumeclaim.requests.storage\nkube_persistentvolumeclaim_resource_requests_storage_bytes\nkube_namespace_name=\u0026lt;persistentvolumeclaim-namespace\u0026gt;\npersistentvolumeclaim=\u0026lt;persistentvolumeclaim-name\u0026gt;\nkube_persistentvolumeclaim_info\nkube_persistentvolumeclaim_labels\npersistentvolumeclaim=\u0026lt;persistentvolumeclaim-name\u0026gt;\nkube_namespace_name=\u0026lt;persistentvolumeclaim-namespace\u0026gt;\nlabel_persistentvolumeclaim_label=\u0026lt;persistentvolumeclaim_label\u0026gt;\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics-and-labels-mapping/mapping-legacy-sysdig-kubernetes-metrics-with-prometheus-metrics/"},{"id":345,"title":"Configure OneLogin for OIDC","content":"PrerequisitesReview OpenID Connect (SaaS).\nOpenID Provider Configuration for OneLoginThe notes below describe minimal steps to be taken in OneLogin. You may need to adjust the steps based on the specifics of your environment.\nLog in to your OneLogin organization as a user with administrative privileges and click to Apps \u0026gt; Custom Connectors, then click the New Connector button.\nCreate a new Connector:\nEnter your choice of connector name.\nSelect a Sign on Method of OpenID Connect.\nFor Redirect URI, enter one of the following values:\nSee SaaS Regions and IP Ranges and identify the correct domain URL (redirect URL) associated with your Sysdig application and region. For example, domain URLs of Monitor and Secure for US East are:\nSysdig Monitor: https://app.sysdigcloud.com/api/oauth/openid/auth\nSysdig Secure: https://secure.sysdig.com/api/oauth/openid/secureAuth\nFor other regions, the format is https://\u0026lt;region\u0026gt;.app.sysdig.com.\nReplace \u0026lt;region\u0026gt; with the region where your Sysdig application is hosted. For example, for Sysdig Secure you use https://eu1.sysdig.com/api/oauth/openid/secureAuth.\nClick Save.\nFrom the More Actions pull-down menu, select Add App to Connector.\nClick Save to add the app to your catalog. Once clicked, additional tabs will appear.\nClick to the SSO tab. Change the setting in the Token Endpoint drop-down to POST, then click Save.\nWhile still on the SSO tab, take note of the Client ID and Client Secret that are shown (click Show client secret to reveal it).\nYou will need them in the OpenID settings.\nNote that the Issuer URL will consist of https://YOUR-ONELOGIN-DOMAIN.onelogin.com/oidc\nYou will need them in the OpenID settings.\nDuring testing, we’ve found OneLogin sometimes does not keep changes that are made in the OpenID Provider configuration. If you make changes to your OneLogin configuration and experience issues such as HTTP 400 Bad Request when attempting to log in to your Sysdig application, you may need to delete your Custom Connector and App config in OneLogin and recreate it from scratch.\nConfigure Sysdig SettingsTo enable OneLogin OpenID functionality on the Sysdig application, you need the following:\nClient ID\nClient Secret\nIssuer URL.\nSee Enable OpenID in Settings to learn how to complete your configuration.\n","url":"https://docs.sysdig.com/en/administration/saas-onelogin-openid/"},{"id":346,"title":"Configure OneLogin for SAML","content":"Prerequisites Review SAML (SaaS).\nTo configure Sysdig Monitor and/or Sysdig Secure as a SAML application, consult OneLogin\u0026rsquo;s article on the Advanced SAML Custom Connector.\nThe notes below call out specific steps that require additional action.\nSysdig-Specific Steps for OneLogin ConfigurationAdd the SAML Test ConnectorTo add a SAML Test Connector in OneLogin:\nLog in to OneLogin and select the Applications tab.\nSelect Add App.\nSearch for SAML Custom Connector.\nSelect SAML Custom Connector (Advanced).\nChoose a Display Name and click Save to access the configuration.\nIf you don\u0026rsquo;t intend to configure IdP-initiated login flow, uncheck the slider so it will no longer be Visible in portal.\nConfigure Test ConnectorIn the SAML Test Connector Configuration tab, enter the values shown in the table below.\nReplace Customer ID with the number retrieved as described in Find Your Customer Number.\nSee Redirect URLs for Authentication and SaaS Regions and IP Ranges) to identify the correct URLs associated with your Sysdig application and region. For example, given below are the URLs for the US East region.\nField Value for Sysdig Monitor Value for Sysdig Secure RelayState (optional) #/\u0026amp;customer=Customer ID #/\u0026amp;customer=Customer ID Audience (EntityID) https://app.sysdigcloud.com https://secure.sysdig.com Recipient https://app.sysdigcloud.com/api/saml/auth https://secure.sysdig.com/api/saml/secureAuth ACS (Consumer) URL Validator https://app.sysdigcloud.com https://secure.sysdig.com ACS (Consumer) URL https://app.sysdigcloud.com/api/saml/auth https://secure.sysdig.com/api/saml/secureAuth If you have defined an integration name or are using multiple integrations, include the integration name in the Relay State parameter using the following format: \u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;, so it becomes #/\u0026amp;customer=\u0026lt;CUSTOMER-ID-NUMBER\u0026gt;\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;.\nRelayState is only required if you intend to use IdP-initiated login flow.\nFor other regions, the format is https://\u0026lt;region\u0026gt;.app.sysdig.com. Replace \u0026lt;region\u0026gt; with the region where your Sysdig application is hosted. For example, for Sysdig Monitor in the EU, you use https://eu1.app.sysdig.com/api/saml/auth. For other regions, see SaaS Regions and IP Ranges.\nFor SAML signature element, select Both from the drop-down. This will allow you to enabled Signed Assertion when you set up SAML in Sysdig Platform.\nYou can leave the other configuration settings as default.\nEmail and Name Values (Optional)If you want the user\u0026rsquo;s First Name and Last Name to be included in the records created in the Sysdig platform\u0026rsquo;s database when new users successfully login via SAML for the first time:\nOpen the Parameters tab.\nClick + to add a New Field.\nCreate the following fields with the names and values given in the table below.\nEach time you add a field, ensure you Include in SAML assertion:\n| Field Name | Value | |--------------|--------------| | `email` | `Email` | | `first name` | `First Name` | | `last name` | `Last Name` | Edit each field and select the Value shown from the drop-down menu. Field Names are case sensitive; therefore, enter them in lowercase.\nSave your changes.\nThe following shows an example of a correctly-configured field for First Name:\nIssuer URLClick the SSO tab and copy the Issuer URL. Save this for later.\nYou will need it for the Metadata field when you set up SAML in Sysdig Platform. See Configure Sysdig.\nAssign PrivilegesTo give SAML permission to a user:\nOpen the Privileges tab.\nUnder Add new user search for the desired user and select Check.\nSelect the user and click Add Admin.\nSave your changes.\nConfigure SysdigTo configure Sysdig for OneLogin:\nLog in to Sysdig Platform.\nNavigate to Settings via the user menu icon at the bottom of the left navigation bar.\nUnder Access \u0026amp; Secrets, select Authentication (SSO).\nEdit existing or create a new SSO integration (type: SAML).\nEnter the URL you have copied earlier in the Metadata field. See Issuer URL.\nEnable Signed Assertion.\nSigned Assertions are available if you selected Both in the SAML signature element drop-down in OneLogin. See Configure Test Connector.\nFor Email Parameter, write email.\nThe rest of the fields and toggles can be left as default.\nSelect Save Settings.\nEnable the integration by selecting the option from the Enabled column in the integration\nTest Metadata (Optional)To ensure the metadata URL you copy at the end of the IdP configuration procedure is correct, you can test it by directly accessing it via your browser.\nWhen accessing the URL, your browser should immediately download an XML file that begins similarly to the example shown below. No entry of credentials or other security measures should be required to successfully download it. If this is not the case, revisit the IdP configuration steps.\n\u0026lt;?xml version= \u0026quot;1.0\u0026quot; ?\u0026gt; \u0026lt;EntityDescriptor xmlns= \u0026quot;urn:oasis:names:tc:SAML:2.0:metadata\u0026quot; entityID= \u0026quot;https://app.onelogin.com/saml/metadata/680358\u0026quot; \u0026gt; `\u0026lt;IDPSSODescriptor xmlns:ds=` `\u0026quot;http://www.w3.org/2000/09/xmldsig#\u0026quot; ` `protocolSupportEnumeration=` `\u0026quot;urn:oasis:names:tc:SAML:2.0:protocol\u0026quot;` `\u0026gt;names:tc:SAML:` `2.0` `:metadata` `\u0026quot; entityID=\u0026quot;` ` https://app.onelogin.com/saml/metadata/ ` `680358` `\u0026quot;\u0026gt;` ... ","url":"https://docs.sysdig.com/en/administration/saas-onelogin-saml/"},{"id":347,"title":"OneLogin (OpenID On-Prem)","content":"Review OpenID Connect (On-Prem) before you begin.\nThe notes below describe minimal steps to be taken in OneLogin. You may need to adjust the steps based on the specifics of your environment.\nLogin to your OneLogin organization as a user with administrative privileges and click to Apps \u0026gt; Custom Connectors, then click the New Connector button.\nCreate a new Connector\nEnter your choice of connector name\nSelect a Sign on Method of OpenID Connect\nFor Redirect URI to, enter one of the following values, replacing HOSTNAME with the hostname through which your users access the Sysdig application(s) and PORT with the TCP port # (typically 443):\nIf configuring Sysdig Monitor, enter: https://HOSTNAME:PORT/api/oauth/openid/auth\nIf configuring Sysdig Secure, enter: https://HOSTNAME:PORT/api/oauth/openid/secureAuth\nClick the Save button\nFrom the More Actions pull-down menu, select Add App to Connector.\nClick Save to add the app to your catalog. Once clicked, additional tabs will appear.\nClick to the SSO tab. Change the setting in the Token Endpoint drop-down to POST, then click Save.\nWhile still on the SSO tab, take note of the Client ID and Client Secret that are shown (click Show client secret to reveal it), as you will need them to complete the configuration in the Sysdig platform.\nNote that the Issuer URL you will need to complete the Sysdig platform configuration will consist of https://YOUR-ONELOGIN-DOMAIN.onelogin.com/oidc\nReturn to the bottom section of the OpenID Connect (On-Prem) article for instructions on using the helper script to complete the configuration in the Sysdig platform.\n","url":"https://docs.sysdig.com/en/administration/onprem-openid-onelogin/"},{"id":348,"title":"OneLogin (SAML On-Prem)","content":"Review SAML (On-Prem) before you begin.\nSysdig-Specific Steps for OneLogin ConfigurationAdding the SAML Test ConnectorAt the step for \u0026ldquo;Adding the SAML Test Connector\u0026rdquo;, select SAML Test Connector (IdP w/ attr w/ sign response). If you don\u0026rsquo;t intend to configure IDP-initiated login flow, uncheck the slider so it will no longer be \u0026ldquo;Visible in portal\u0026rdquo;.\nTest Connector Configuration Page SettingsAt the \u0026ldquo;Test Connector Configuration Page\u0026rdquo;, enter the values shown in the table below. If you wish to configure IDP-initiated login flow, replace CUSTOMER-ID-NUMBER with the number retrieved as described in the Find Your Customer Number article.\nField\nValue for Sysdig Monitor\nValue for Sysdig Secure\nRelayState\n(optional - only configure if you intend to use IDP-initiated login flow)\n#/\u0026amp;customer=CUSTOMER-ID-NUMBER\n#/\u0026amp;customer=CUSTOMER-ID-NUMBER\nRecipient\nhttps://HOSTNAME:PORT/api/saml/auth https://HOSTNAME:PORT/api/saml/secureAuth ACS (Consumer) URL Validator\nhttps://HOSTNAME:PORT https://HOSTNAME:PORT ACS (Consumer) URL\nhttps://HOSTNAME:PORT/api/saml/auth https://HOSTNAME:PORT/api/saml/secureAuth\nYou must include the port number in the IDP-side configuration, even though port 443 is the typical default for https:// URLs.\n(Optional) If you want the user\u0026rsquo;s First Name and Last Name to be included in the records created in the Sysdig platform\u0026rsquo;s database when new users successfully login via SAML for the first time, click to the Parameters tab. Click Add parameter and create each of two New Fields, checking the box each time to Include in SAML assertion. Then click to Edit each field and select the Value shown from the drop-down menu before clicking Save.\nField Name Value first name First Name last name Last Name Note that the Field Names are case sensitive , so be careful to enter them as all lowercase.\nThe following shows an example of a correctly-configured field for First Name:\nIssuer URLClick to the SSO tab, copy the Issuer URL, and paste in the Metadata entry on the SAML Configuration page in the SAML connection settings.\nTest Metadata (Optional)To ensure the metadata URL you copy at the end of the IDP configuration procedure is correct, you can test it by directly accessing it via your browser.\nWhen accessing the URL, your browser should immediately download an XML file that begins similarly to the example shown below. No entry of credentials or other security measures should be required to successfully download it. If this is not the case, revisit the IDP configuration steps.\n\u0026lt;?xml version= \u0026quot;1.0\u0026quot; ?\u0026gt; \u0026lt;EntityDescriptor xmlns= \u0026quot;urn:oasis:names:tc:SAML:2.0:metadata\u0026quot; entityID= \u0026quot;https://app.onelogin.com/saml/metadata/680358\u0026quot; \u0026gt; `\u0026lt;IDPSSODescriptor xmlns:ds=` `\u0026quot;http://www.w3.org/2000/09/xmldsig#\u0026quot; ` `protocolSupportEnumeration=` `\u0026quot;urn:oasis:names:tc:SAML:2.0:protocol\u0026quot;` `\u0026gt;names:tc:SAML:` `2.0` `:metadata` `\u0026quot; entityID=\u0026quot;` ` https://app.onelogin.com/saml/metadata/ ` `680358` `\u0026quot;\u0026gt;` ... ","url":"https://docs.sysdig.com/en/administration/onprem-saml-onelogin/"},{"id":349,"title":"Packages","content":" Agent Host Scanner Next StepsInstall the Agent using a package\nInstall the Host Scanner using a package\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-hosts-packages/"},{"id":350,"title":"Pipeline","content":"Terms, such as Development, CI/CD, Pipeline, or Shift-Left, refer to scanning performed on container images that are not yet executed in a runtime workload. You can scan these images using the sysdig-cli-scanner tool, and explore the results directly in the console or on the Sysdig Secure UI.\nThis document applies only to the Vulnerability Management engine, released April 20, 2022. Make sure you are using the correct documentation: Which Scanning Engine to Use\nPrerequisiteEnsure that you have deployed sysdig-cli-scanner in your environment. For information on installation, see Install Sysdig CLI Scanner.\nReview Pipeline Scan ResultsYou can explore the details for every image that has been scanned by executing the sysdig-cli-scanner in Sysdig Secure UI.\nLog in to Sysdig Secure, and select to Attack Surface \u0026gt; Vuln Pipeline Findings.\nThe Policy Evaluation column reflects the policy state at evaluation time for that image and the assigned policies.\nFailed: If any of the policies used to evaluate the image is failing, the image is considered \u0026ldquo;Failed\u0026rdquo;. Passed: If no violation of any of the rules contained in any of the policies occurred, the image is considered \u0026ldquo;Passed\u0026rdquo;. Use the toggle beside the search bar to filter findings by Passed or Failed.\nDrill into Scan Result DetailsSelect a result from the Pipeline list to see the details, parsed in different ways depending on your needs.\nOverview TabShows the recommendations, provides an overview of vulnerabilities and fixable packages associated with the selected image. You can also view the policy details on this tab. Click on the desired row to see detailed information in the Packages, Policies, or Recommendations tabs.\nRecommendations TabShows image hierarchy, surfaces image layers, identify vulnerability issues in packages contained in each layer, and provides actionable instructions to fix the issues.\nVulnerabilities TabIn the Vulnerabilities tab, you can find expanded filters and a list of CVEs.\nClick a CVE listing to open the full CVE details, including source data and fix information.\nThe same security finding, such as a particular vulnerability, can be present in more than one rule violation table if it happens to violate several rules.\nYou can view the image hierarchy and the layers belong to the selected image. Click on a layer to view the packages, their versions, and vulnerabilities detected in the layer.\nYou can refine your view further within the Vulnerabilities tabs:\nSearch by keyword or CVE name Use filters: Severity (\u0026gt;=) CVSS Score (\u0026gt;=) Vuln Type Has Fix Exploitable CISA KEV Risk Acceptance Packages TabThis is organized by software packages, with expanded filters and clickable CVE cells. You can also view the image hierarchy and the layers belong to the selected image. Click on a layer to view the packages, their versions, and vulnerabilities detected in the layer.\nYou can refine your view further within the Packages tabs:\nSearch by the keyword or the package name. Filter by Package Type. Filter by Severity \u0026gt;=|= Critical, High, Medium, Low, Negligible. Policies TabShows the list of CVEs organized by failed policies. Use the toggle to show or hide passed policies. Click the CVE names for details.\nDetail TabUse the Detail tab to get the image information, such as the image ID, digest, author, labels used, and the operating system.\nAccept Risk: PipelineYou can choose to accept the risk of a detected vulnerability or asset. The process for handling Accepted Risk is the same for both Pipeline and Runtime.\nUse the Runtime instructions, with the following differences:\nThe pipeline scan results are point-in-time, so there is no automatic re-evaluation.\nTo trigger a new evaluation containing the accept:\nYou must execute the pipeline process again over the same image. The N+1 scan will contain the accepted risk. Filter by Risks AcceptedOn the Vulnerabilities tab of the scan result, you can filter out accepted risks to help you focus on active, unresolved issues.\nSelect one of the following options:\nAll Risks: See all the risks. Risks Accepted : View only accepted risks. Risks Not Accepted: Hide all the accepted risks. ","url":"https://docs.sysdig.com/en/sysdig-secure/vm-pipeline/"},{"id":351,"title":"Policies","content":"Key FeaturesSysdig Secure Policies provide the following benefits:\nVisibility and understanding - The policies offer visibility into the security and integrity of cloud environments. They help you understand the behavior of your systems and identify potential threats. Actionable information - Sysdig Secure policies generate events based on real-time data, providing actionable information. You can leverage these events to take prompt and informed actions to mitigate risks. Built-in policies - Sysdig Secure provides a range of built-in policies that offer immediate value. These pre-configured policies are designed to address common security and integrity concerns in cloud environments. Customization - You can fine-tune the behavior of built-in policies to align them with your specific requirements. You have the flexibility to change default configurations, enable or disable policies, and create new ones tailored to your environment. UsesYou can use Sysdig Secure Policies to:\nEvaluate built-in policies and identify areas that need customization. Modify policy configurations to align with your organizational needs. Enable or disable policies based on their relevance and impact on your environment. Create brand new policies that address specific security concerns unique to your environment. You can optionally use the following tools to automate policy creation:\nRuntime Threat Detection Policy Tuning for reducing noisy false positives in the events feed Network Security Policy Tool to author and fine-tune Kubernetes network policies Warranty DisclaimerCustomer understands and agrees that it is impossible under any current available technology for any security software to identify one hundred percent (100%) of cloud threats, vulnerabilities, malicious software or attacker’s behavior. Sysdig Secure relies upon threat feeds, behavioral analysis, machine learning, and other techniques, but these may not be enough to discover all attacks. Additionally, Customer understands and agrees that Sysdig Secure may incorrectly identify cloud threats, vulnerabilities, potentially malicious software or attacker’s behavior as a potential threat (“False Positive”). SYSDIG DOES NOT GUARANTEE OR WARRANT THAT IT WILL FIND, LOCATE, OR DISCOVER ALL THREATS OR THAT ALL THREATS IT SURFACES ARE FREE FROM FALSE POSITIVES, AND IN USING SYSDIG SECURE CUSTOMER ASSUMES ALL RISK AND LIABILITY.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/policies/"},{"id":352,"title":"Prometheus Alerts","content":" Prometheus Alerts were formerly known as PromQL Alerts.\nTo create a Prometheus Alert:\nLog in to Sysdig Monitor and open Alerts from the left navigation bar. Click Add Alert and choose Prometheus. Define a Prometheus Alert Condition: Enter a valid PromQL expression. Unlike Threshold Alerts, PromQL queries only return time series that meet the specified condition. For example, if you enter sysdig_host_cpu_used_percent \u0026gt; 80, only the hosts with CPU usage above 80% will be included in the query results. If all hosts are below this threshold, the query will return a resolved state, which is identical to a No Data state. Users may experience confusion when determining whether an alert has truly been resolved or if the metric has disappeared and failed silently. This is because the No Data state in Prometheus is indistinguishable from a resolved state. Strategies for dealing with this can be found in the No Data and Multiple Thresholds.\nDuration: The duration is how long an alert condition must remain true before triggering an alert. Prometheus Alerts have three states: Resolved, Pending, and Firing. If a duration of 10m is set, it means that the alert condition must be consistently satisfied for a continuous period of 10 minutes before transitioning into the Firing state. Alerts whose expression are satisfied but haven\u0026rsquo;t met the required duration are in a Pending state.\nKeep Firing For: This setting enables the continuous firing of an alert occurrence for a user-defined duration even after the alert condition is no longer satisfied. Alerts that tend to flap or undergo bridges of No Data in the underlying metric can be configured with Keep Firing For in order to prevent unnecessary noise and false resolutions. If the alert condition is once again met before the Keep Firing For has elapsed, the alert will continue to trigger without needing to satisfy the duration once again.\nFrequency of Alert Rule EvaluationThe Alert Editor automatically chooses the time window that works best with your alert rule. Every data point in the alert preview corresponds with an evaluation of an alert rule.\nThe frequency at which an alert rule is evaluated depends on the range specified in its query, defined in PromQL by the time specified in the brackets. Using a larger time window for data aggregation can lead to less frequent checks of the alert rule. For instance, consider monitoring a service\u0026rsquo;s error rate: occasional errors might be tolerable, but a steady stream of errors over a certain period could indicate a problem. By setting up an alert query like min_over_time(service_error_rate[4h]), the alert rule is evaluated every 10 minutes. Each evaluation analyzes the error rate over the past 4 hours to determine if the alert rule should be triggered.\nRe-notifications for an alert cannot be sent more frequently than the alert rule’s evaluation interval and must be a multiple of this interval. For example, if an alert rule is evaluated every 10 minutes, re-notifications can only occur at multiples of the evaluation frequency, such as 20 minutes, 30 minutes, etc.\nRange of Alert Query Frequency of Alert Rule Evaluation up to 3h 1m up to 1d 10m up to 7d 1h up to 60d 1d 60d+ Not Supported Users seeking to explore metric data outside the window recommended by the alert editor can navigate to Explore Historical Data in order to view the time series data older than the recommended window.\nRange and DurationThe duration of an alert refers to the length of time a specific condition must persist before triggering the alert. It should not be confused with the range of an alert, which defines the time period over which the relevant metric data is evaluated.\nIn the example below, the highNetworkTrafficFoo alert examines the average network transmittance over the previous hour. If this average exceeds 10MB for a continuous duration of 5 minutes, the alert is triggered.\nOn the other hand, highNetworkTrafficBar focuses on the average network transmittance over the past 5 minutes. If this average exceeds 10MB for the last hour, the alert is triggered.\nrules: - alert: highNetworkTrafficFoo expr: avg(rate(network_bytes_total[1h])) \u0026gt; 10000000 for: 5m - alert: highNetworkTrafficBar expr: avg(rate(network_bytes_total[5m])) \u0026gt; 10000000 for: 1h While using a longer duration can help reduce noisy alerts, it also means that some alerts may meet the threshold momentarily without triggering. Therefore, there is a trade-off between suppressing noisy alerts and potentially delaying notifications for certain conditions.\nLabel Enrichment in Alert NotificationsContextual labels are automatically appended to alert notifications when Prometheus Alert rules trigger. Examples of such labels are host_hostname, cloud_provider_region, and kube_cluster_name. This additional context aids in faster issue identification, troubleshooting, and resolution.\nCompare Prometheus Alerts and Threshold AlertsPrometheus Alerts query the same metrics as Threshold Alerts. The difference between the two alert types lies in the evaluation algorithm.\nThreshold Alerts Prometheus Alerts No Data state does not cause Alert Resolution No Data state is the same as Resolved State Multi-threshold Support Must create two alerts for multiple thresholds Duration supported Duration supported Queries return all the time series by default Queries only return time series that satisfy the alert query No Data and Multiple ThresholdsTo avoid an alert resolution in No Data scenarios or to configure multiple thresholds, you can switch from a Prometheus Alert to a Threshold Alert.\nTo create a Threshold Alert with these advanced capabilities, follow:\nCreate a new Threshold Alert. Switch the alert creation mode from Form to PromQL. Continue with configuring a Threshold Alert using PromQL. Optionally, add a warning threshold and notify on No Data. By transitioning to a Threshold Alert with PromQL, you can fully utilize the multiple threshold and No Data capabilities provided by Sysdig\u0026rsquo;s monitoring solution.\nImport Prometheus Alert RulesSysdig Alert allows you to import Prometheus rules. Click the Upload Prometheus Rules option and enter the rules as YAML in the Upload Prometheus Rules YAML editor. Importing your Prometheus alert rules will convert them to Prometheus alerts.\nEach alert rule should include the following mandatory fields.\nalert expr for Example: Alert Prometheus Crash LoopingThis alert detects potential restart loops on the prometheus, pushgateway or alertmanager jobs.\ngroups: - name: crashlooping rules: - alert: PrometheusTooManyRestarts expr: changes(process_start_time_seconds{job=~\u0026#34;prometheus|pushgateway|alertmanager\u0026#34;}[10m]) \u0026gt; 2 for: 0m labels: severity: warning annotations: summary: Prometheus too many restarts (instance {{ $labels.instance }}) description: Prometheus has restarted more than twice in the last 15 minutes. It might be crashlooping.\\n VALUE = {{ $value }}\\n Example: Alert HTTP Error RateNginxHighHttp5xxErrorRate detects an http error rate of 5% or higher.\nNginxLatencyHigh monitors the p99 latency for 3 seconds or higher for all hosts and nodes.\nTo alert HTTP requests with status 5xx (\u0026gt; 5%) or high latency:\ngroups: - name: default rules: # Paste your rules here - alert: NginxHighHttp5xxErrorRate expr: sum(rate(nginx_http_requests_total{status=~\u0026#34;^5..\u0026#34;}[1m])) / sum(rate(nginx_http_requests_total[1m])) * 100 \u0026gt; 5 for: 1m labels: severity: critical annotations: summary: Nginx high HTTP 5xx error rate (instance {{ $labels.instance }}) description: Too many HTTP requests with status 5xx - alert: NginxLatencyHigh expr: histogram_quantile(0.99, sum(rate(nginx_http_request_duration_seconds_bucket[2m])) by (host, node)) \u0026gt; 3 for: 2m labels: severity: warning annotations: summary: Nginx latency high (instance {{ $labels.instance }}) description: Nginx p99 latency is higher than 3 seconds Learn More PromQL Query Explorer\nPromQL Library\nRun PromQL Queries Faster with Extended Label Set\n","url":"https://docs.sysdig.com/en/sysdig-monitor/prometheus-alerts/"},{"id":353,"title":"Query Inspector","content":" Feature Availability\nThis feature is currently available only to SaaS users. Using Query Inspector Query Inspector currently supports only PromQL-based panels.\nStep Preview In a PromQL Panel, click the link given next to a No Data message. Alternatively, you can acess it in a similar fashion when editing or viewing dashboards panels, and using Metrics Explorer. The Inspect floating window opens. Underlying Causes of No Data Inspector checks for underlying No Data causes in the below order, which means diagnostics are run sequentially.\nAs you leverage the Query Inspector to gain insights on No Data situations, you can use this page to obtain a better understanding of the underlying root causes.\nUnable to run Diagnostics due to missing metric nameThis scenario occurs when a PromQL query does not contain any metric name, for example:\nScalars such as 1024 Functions such as hour() Metric doesn\u0026rsquo;t exist or was never reportedCheck the metric name being used to spot potential spelling mistakes. PromQL Query Explorer, Metrics Explorer, and Dashboards come with a built-in auto-complete for metric names, which can be used to assist in this task. Alternatively, see the information in the Metrics and Labels in Prometheus Format docs.\nIf a metric is being provided by an integration, check they have been configured as required. This information is outlined in the Monitoring Integration docs.\nIf the metric is being scrapped by Prometheus and sent to Monitor via Prometheus Remote Write, check your Prometheus configuration.\nMetric has not been reported recently within the current selected team scopeThis message is raised by Inspector to signal the metric exists, but not within the currently selected team scope. When you encounter this error, you might want to validate whether you are using the correct Team and consider switching to the appropriate one as outlined in the Switching Teams in the UI docs.\nMetric last reported data on [date]This message is raised by Inspector when you are using a time window where the selected metric isn\u0026rsquo;t reporting any time series. This means its source likely stopped emitting the metric.\nCauses for this issue vary, but you are invited to perform the same check as mentioned in Metric doesn\u0026rsquo;t exist or was never reported.\nAdditionally, you can leverage our Events page to check for relevant events close to the last reported date as outlined in the Filter and Search Events docs. This allows you to identify what caused the metric to stop being emitted by the source.\nLabel filtering doesn\u0026rsquo;t match recent known label values of metric within the last dayYou can check the label filtering doesn\u0026rsquo;t contain any typos such as {enviroment=\u0026quot;production}\u0026quot; or {environment=\u0026quot;poduction\u0026quot;}. PromQL Query Explorer, Metrics Explorer, and Dashboards come with a built-in auto-complete for label names, which can be used to assist in this task.\nAdditionally, you might be looking for an entity (ie. container, node, host) that no longer exists.\nQuery is not returning dataThis catch-all message is used when Inspector is not able to determine the underlying reason a query yields No Data.\nThese are some of the additional reasons you may be seeing No Data:\nusing operators with metrics that do not have matching sets of labels (see Prometheus docs about vector matching) using a time range, in a range vector selector (my_metric[1s]), for which there are no data points this could happen also when using an instant query Form panel(Number, Toplist, Table) with a sparse metric (see Use of Latest Displayed Value with Sparse Metric) ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/use-promql/query-inspector/"},{"id":354,"title":"Registry","content":"Registries are a fundamental stage in the lifecycle of container images. Container registries accumulate a large number of images, some of which are obsolete or no longer suitable for runtime, and registry scanning provides the necessary security to avoid degradation of the posture.\nSee the Sysdig Vulnerability Management cycle for the benefits of scanning in pipeline, registry, and runtime phases.\nThe Registry page allows you to:\nSearch and view the list of integrated registries and repositories. Determine the overall vulnerability score and exploits. Drill down the images to view the security posture of associated packages and versions. Prerequisites To use Registry Scanning, install the Registry Scanner and configure it on your private registries. See Install Registry Scanning. On-Prem Deployments Network and port requirements: Ensure port 443* is open for outbound traffic, allowing Sysdig to download the latest external vulnerability feeds.\nSee On-Prem Network and Port for more information.\nIP requirements: For Sysdig to scan private repositories, your firewall must allow inbound requests from the Sysdig IP addresses.\nView Registry Scan ResultsOn the Registry page, you can search images and tags and assess the security posture of your images.\nThe Registry page displays scanning results from:\nThe registry scans that leverage the registry scanner. By default, these scans are scheduled weekly; you can also trigger manual registry scans. Instant image scanning using the Scan Now feature. This does not require deploying CLI tools into your environment. To view scan results:\nEnsure that the registry scanner is installed and at least one scheduled scan job is completed, or have one manual scan using Scan Now completed.\nLog in to Sysdig Secure and open Attack Surface \u0026gt; Vuln Registry Findings. You can:\nBrowse or search registries or repositories. Search by image or tag. Review detected vulnerabilities by severity and exploit status. Select an image to access the tabs in the detail panel: Overview, Vulnerabilities, and Content.\nTabs Preview Overview: View packages and filter packages that are fixable. Click the individual cells to view the Vulnerabilities list. Recommendations: View the recommendations to improve security posture of your image. Vulnerabilities: Use the expanded filters and clickable list of CVEs to view complete CVE details, including source data and fix information. The same security finding, such as a particular vulnerability, can be present in more than one rule violation table if it violates several rules. You can filter the result of vulnerabilities with Critical Severity, Has Fix, Accepted Risk, and Exploitable. Package: You can view data organized by package view, with expanded filters and clickable CVE cells. Use the Package tab to view cases, such as the software packages that are most dangerous. Instant Image Scanning with Scan NowYou can instantly scan images in your registries and view results without deploying any CLI-based components. To do so:\nIntegrate with a private container registry. Use the Scan Now button to initiate platform-based image scanning. Add a Container RegistryYou can integrate private container registries and retrieve target images for scanning by configuring necessary registry credentials. Each of the registry types has unique input fields for the credentials required. For example, username/password for Docker Registry and JSON key for Google Container Registry.\nLog in to Sysdig Secure and select Attack Surface \u0026gt; Vuln Registry Findings.\nSelect Scan Now \u0026gt; Registry Credentials.\nClick Add Registry and enter:\nRegistry Name: A unique name to identify the registry.\nPath: The path to the container registry, such as Docker Hub. The format is \u0026lt;hostname\u0026gt;:\u0026lt;port\u0026gt; or \u0026lt;hostname\u0026gt;:\u0026lt;port\u0026gt;/\u0026lt;path\u0026gt;. For example, us-west1-docker.pkg.dev/my-registry/example-repo\nIf you are providing repository-specific credentials, provide the path to the repository.\nA registry might contain multiple namespaces in certain scenarios, each with distinct permissions. To encompass all the credentials under a single set, you can employ a partial path.\nAny image located within the partial path inside the registry will use the configured registry credentials.\nType: Select the type of Registry you are adding. Depending on your selection, additional parameters will appear, such as the Access Key and Secret Key for AWS ECR.\nSkip TLS Validation: Toggle to disable secure validation.\nClick Add Registry Credential.\nScan Now Select Vulnerabilities \u0026gt; Scan Now.\nThe Scan Image screen appears.\nEnter your image reference to scan it directly from the registry.\nClick Scan Image.\nYou will encounter an error if you have not integrated the registry from which you are pulling the image.\nTo see the status of the scanning, select Scan Now \u0026gt; Queue.\nClick on the row corresponding to an image to view the scan results.\nNext StepsGenerate a registry report\n","url":"https://docs.sysdig.com/en/sysdig-secure/vm-registry/"},{"id":355,"title":"SAML (SaaS)","content":"PrerequisitesThis topic is specific to cloud-based (SaaS) Sysdig environments. To configure an On-Premises Sysdig environment, see SAML(On-Prem).\nIf you want to set up SAML for both Sysdig Monitor and Sysdig Secure, you need to complete the setup process twice. Setting up SAML on one will not automatically set it up on the other.\nTo configure SAML Single Sign-On (SSO), you need:\nAn Administrator role. Customer ID and Customer Name: See Find Your Customer ID, Name, and External ID. Sysdig does not support signed AutthNRequests for AuthNRequest with embedded signature (HTTP-POST binding) requirements. For a possible alternative, see OpenID Connect.\nRedirect URLs for Authentication Region App Single Sign-on URL Service Provider Entity ID au1 Monitor https://app.au1.sysdig.com/api/saml/auth https://app.au1.sysdig.com au1 Secure https://app.au1.sysdig.com/api/saml/secureAuth https://app.au1.sysdig.com eu1 Monitor https://eu1.app.sysdig.com/api/saml/auth https://eu1.app.sysdig.com eu1 Secure https://eu1.app.sysdig.com/api/saml/secureAuth https://eu1.app.sysdig.com/secure/ in1 Monitor https://app.in1.sysdig.com/api/saml/auth https://app.in1.sysdig.com in1 Secure https://app.in1.sysdig.com/api/saml/secureAuth https://app.in1.sysdig.com/secure/ me2 Monitor https://app.me2.sysdig.com/api/saml/auth https://app.me2.sysdig.com me2 Secure https://app.me2.sysdig.com/api/saml/secureAuth https://app.me2.sysdig.com/secure/ us Monitor https://app.sysdigcloud.com/api/saml/auth https://app.sysdigcloud.com us Secure https://secure.sysdig.com/api/saml/secureAuth https://secure.sysdig.com us2 Monitor https://us2.app.sysdig.com/api/saml/auth https://us2.app.sysdig.com us2 Secure https://us2.app.sysdig.com/api/saml/secureAuth https://us2.app.sysdig.com/secure/ us4 Monitor https://app.us4.sysdig.com/api/saml/auth https://app.us4.sysdig.com us4 Secure https://app.us4.sysdig.com/api/saml/secureAuth https://app.us4.sysdig.com/secure/ If multiple integrations are used with the same IdP, make sure to enable Unique Entity ID. It appends a hash to the Entity ID which is unique for each integration.\nExamples for EU1:\nMonitor 1: https://eu1.app.sysdig.com/225992664c8fb69dd4cc7c12d158b1289d40eeae Monitor 2: https://eu1.app.sysdig.com/f0f703fede16e024e28c6fc77c715815d1e79124 Secure 1: https://eu1.app.sysdig.com/secure/7d1fc014f0d7501a1fb150b7ef94a0404ea7af0e Secure 2: https://eu1.app.sysdig.com/secure/348917fddb39b5bdcf286615a00ea705df295a11 To learn more about SaaS regions, see SaaS Regions and IP Ranges\nBasic Enablement Workflow Contact Sysdig Support to set your company name on the account. This is applicable to all supported IdPs. To obtain your Company Name, See Find Your Customer ID, Name, and External ID.\nWhich IdP to Use?Determine which IdP your company uses and will be configuring. The following IdPs have been tested:\nOkta (SAML)\nOneLogin (SAML)\nMicrosoft Entra ID (SAML)\nGoogle Workspace (SAML)\nUnlisted IdPs might work with the Sysdig platform. For help, contact Sysdig Support.\nWhich Login Flow to Use?Decide which login flow you want users to experience from the following options:\nLogin From the Sysdig Login PageClick the SAML button on the login page and enter Company Name.\nOpen the domain URL corresponding to your Sysdig application and region and enter your company name.\nFor example, domain URLs of Monitor and Secure for US East are app.sysdigcloud.com and secure.sysdig.com respectively.\nFor other regions, see Redirect URLs for Authentication.\nType or Bookmark a URLType or bookmark a URL in the browser.\nExamples (with no integration name):\nUS East\nMonitor: https://app.sysdigcloud.com/api/saml/COMPANY_NAME?redirectRoute=%2F\u0026amp;companyName=\u0026lt;COMPANY_NAME\u0026gt;\nSecure: https://secure.sysdig.com/api/saml/COMPANY_NAME?product=SDS\u0026amp;redirectRoute=%2F\u0026amp;companyName=\u0026lt;COMPANY_NAME\u0026gt;\nEU\nMonitor: https://eu1.app.sysdig.com/api/saml/COMPANY_NAME?redirectRoute=%2F\u0026amp;companyName=\u0026lt;COMPANY_NAME\u0026gt;\nSecure: https://eu1.app.sysdig.com/api/saml/COMPANY_NAME?product=SDS\u0026amp;redirectRoute=%2F\u0026amp;companyName=\u0026lt;COMPANY_NAME\u0026gt;\nIf multiple integrations are used, the integration name must be appended.\nExamples (WITH integration name):\nUS East\nMonitor: https://app.sysdigcloud.com/api/saml/COMPANY_NAME?redirectRoute=%2F\u0026amp;companyName=\u0026lt;COMPANY_NAME\u0026gt;\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\nSecure: https://secure.sysdig.com/api/saml/COMPANY_NAME?product=SDS\u0026amp;redirectRoute=%2F\u0026amp;companyName=\u0026lt;COMPANY_NAME\u0026gt;\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\nEU\nMonitor: https://eu1.app.sysdig.com/api/saml/COMPANY_NAME?redirectRoute=%2F\u0026amp;companyName=\u0026lt;COMPANY_NAME\u0026gt;\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\nSecure: https://eu1.app.sysdig.com/api/saml/COMPANY_NAME?product=SDS\u0026amp;redirectRoute=%2F\u0026amp;companyName=\u0026lt;COMPANY_NAME\u0026gt;\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\nAccess from IdP interfaceLog in from an IdP interface. The individual IdP integration pages describe how to add Sysdig to the IdP interface.\nYou need your Customer ID.\nConfigure IdPPerform the configuration steps in your IdP interface and collect the resulting configuration attributes.\nCollect metadata URL (or XML) and test it. If you intend to configure IdP-initiated login flow, have your Customer ID ready (see Prerequisites).\nSelect your IdP from the list below, and follow the instructions:\nOkta (SAML)\nOneLogin (SAML)\nMicrosoft Entra ID (SAML)\nGoogle Workspace (SAML)\nConfigure SysdigLog in to Sysdig Monitor or Sysdig Secure Settings as Admin, enter the necessary configuration information in the UI and enable the integration.\nEnsure that you enter a separate redirect URL in your IdP for each product; otherwise, the integration processes are the same.\nAdding or managing existing SAML SSO integrationTo enable baseline SAML functionality:\nCreate New SAML SSO IntegrationIf you are a Platform customer, make sure to repeat the process in both Sysdig Monitor and Sysdig Secure.\nLog in to Sysdig Monitor or Sysdig Secure as administrator.\nSelect Settings from the User Profile button in the left navigation.\nSelect Authentication (SSO).\nSelect New Configuration.\nSelect type SAML and click Add.\n(Optional) Integration Name - Integration name must be provided if more than one SSO integration of the same type is required.\nEnter the relevant parameters (see table below) and click Save Settings.\nConnection Setting Options Description Metadata Discovery URL The URL provided at the end of the IdP configuration steps. XML An option you can use for an IdP that doesn\u0026rsquo;t support extracting metadata XML via URL. Unique Entity ID off/on When enabled Entity ID becomes unique for each integration to allow the usage of multiple SAML integrations with the same IdP. Verify Signed Assertion off/on Specify whether Sysdig should check for assertions signed in responses (to assist in validating correct IdP). We strongly recommend you toggle this on to increase security. Email Parameter email The parameter for the user email in SAML response. Sysdig uses this to extract the user\u0026rsquo;s email from the response. Validate Signature off/on Specify whether Sysdig backend should verify that the response is signed. We strongly recommend you toggle this on to increase security. Verify Destination Field off/on Specify whether Sysdig should check the \u0026ldquo;destination\u0026rdquo; field in the SAMLResponse. We recommend you toggle this on to increase security. You may toggle it off in special cases, such as when there is a proxy in front of the Sysdig back end. Create User on Login off/on Specify whether a user record should be created in the Sysdig database after the first successful SAML login. SAML Single Logout off/on Specify whether to use SAML single logout. See Configure SAML Single Logout. SAML Encryption off/on Specify whether to enable enable encrypted SAML response. See Encrypted SAML response. Username and Password Login off/on Specify whether to enable user name and password login. Control if SSO Integration is in UseMake sure at least one integration is enabled to be able to use it for logging users in.\nFind the integration that you want to control.\nSelect the toggle on the left side of the integration and slide it to the right to enable or left to disable.\nIf you want to manage multiple integration, repeat the process\nEditing existing SSO Integration Log in to Sysdig Monitor or Sysdig Secure as administrator.\nSelect Settings from the User Profile button in the left navigation.\nSelect Authentication (SSO).\nSelect the pen icon on the right hand side of the window to edit the existing integration\nConfigure SAML Single LogoutSysdig supports SAML Single Logout (SLO).\nSLO is a feature in federated authentication where Sysdig users can sign out of both their Sysdig session (Service Provider) and associated IdP (Identity Provider) simultaneously. SLO lets you terminate all sessions established via SAML SSO with a single logout process. This prevents unauthorized users from gaining access to Sysdig resources.\nSLO ProcessWhen you initiate a logout, Sysdig sends a digitally signed logout request to the IdP. The IdP validates the request and terminates the current login session, then redirects you back to the Sysdig login page.\nConfigure IdP Configure logout URLs:\nMonitor: \u0026lt;base_URL\u0026gt;/api/saml/slo/logout\nSecure: \u0026lt;base_URL\u0026gt;/api/saml/slo/secureLogout\nChoose HTTP Redirect as the binding method.\nThis option is an alternative to the HTTP POST method, which Sysdig does not support.\nIf your IdP mandates, upload the signing certificate for Sysdig. For more information, see Retrieving the Public Keys.\nCertain IdPs, such as Microsoft Entra ID, don\u0026rsquo;t require you to upload the public key.\nEncrypted SAML responseEnable encryption of SAML assertions to add an extra layer of security to your SSO authentication.\nTo enable encrypted SAML response:\nObtain the encryption certificate. For information on obtaining the key, see Retrieving the Public Keys.\nUpload the certificate to your IdP.\nEnable encryption on IdP.\nSome IdPs require the certificate in .crt format. You need to convert the X509Certificate from metadata to .crt format before uploading.\nRetrieving the Public KeysYou can retrieve the public key from metadata.\nYou can obtain the metadata as follows:\nMonitor: \u0026lt;base_URL\u0026gt;/api/saml/metadata/{customerName}\nSecure: \u0026lt;base_URL\u0026gt;/api/saml/secureMetadata/{customerName}\nIf you provided an integration name or multiple integrations are used, you can obtain the metadata as follows:\nMonitor: \u0026lt;base_URL\u0026gt;/api/saml/metadata/{customerName}?integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\nSecure: \u0026lt;base_URL\u0026gt;/api/saml/secureMetadata/{customerName}?integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\n{customerName} must be URL encoded.\nFollow these instructions to find your {customerName}.\nTwo types of KeyDescriptor \u0026lt;md:KeyDescriptor\u0026gt; are provided:\nSigning certificate: \u0026lt;md:KeyDescriptor use=”signing”\u0026gt; - Used to sign the SLO request. Encryption certificate: \u0026lt;md:KeyDescriptor use=”encryption”\u0026gt; - Used to decrypt the encrypted assertions that we receive from the IdP. If you are having issues retrieving the key, contact Sysdig Support to retrieve the public key associated with your deployment.\nEnd User Login to SysdigYou can offer users three ways to log in with a SAML configuration:\nThey can begin at the Sysdig SaaS URL and click the SAML button.\nSee SaaS Regions and IP Ranges and identify the correct Sysdig SaaS URL associated with your Sysdig application and region. For example, URLs of Monitor and Secure for US East are:\nMonitor: app.sysdigcloud.com\nSecure: secure.sysdig.com\nThey will be prompted to enter a Company Name, so the Sysdig platform can redirect the browser to your IdP for authentication.\nContact Sysdig Support to set your company name on the account.\nYou can provide an alternative URL to avoid the user having to enter a company name, in the format:\nSysdig Monitor: https://us2.app.sysdig.com/api/saml/\u0026lt;COMPANY_NAME\u0026gt;\nSysdig Secure: https://us2.app.sysdig.com/api/saml/\u0026lt;COMPANY_NAME\u0026gt;?product=SDS\nReplace \u0026lt;COMPANY_NAME\u0026gt; with your company name.\nIf you are using multiple integrations and/or the integration name is not null, the integration name should be included in this information:\nSysdig Monitor: https://us2.app.sysdig.com/api/saml/\u0026lt;COMPANY_NAME\u0026gt;?integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\nSysdig Secure: https://us2.app.sysdig.com/api/saml/\u0026lt;COMPANY_NAME\u0026gt;?integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\u0026amp;product=SDS\nFor other regions, the format is https://\u0026lt;region\u0026gt;.app.sysdig.com/api/saml/. Replace \u0026lt;region\u0026gt; with the region where your Sysdig application is hosted. For example, for Sysdig Secure in the EU, you use https://eu1.app.sysdig.com/api/saml/secureAuth.\nYou can configure an IdP-initiated login flow when configuring your IdP. The users then select the Sysdig application from your IdP\u0026rsquo;s app directory and do not browse directly to a Sysdig application URL at all.\nUsers that complete their first successful SAML login to Sysdig Secure may receive the error message \u0026ldquo;User doesn\u0026rsquo;t have permission to log in to Sysdig Secure\u0026rdquo;. This is because only members of the Secure Operations team are permitted access to Sysdig Secure, and newly-created logins are not in this team by default. Such a user should contact an Administrator for the Sysdig environment to be added to the Secure Operations team.\nEnvironments that wish to have all the users access Sysdig Secure by default could use this sample Python script to frequently \u0026ldquo;sync\u0026rdquo; the team memberships.\nSee Developer Documentation for tips on using the sample Python scripts provided by Sysdig.\nSee User and Team Administration for information on creating users.\n","url":"https://docs.sysdig.com/en/administration/saml-saas/"},{"id":356,"title":"SAML (On-Prem)","content":"This section describes how to integrate and enable SAML with both Sysdig Monitor and Sysdig Secure.\nPrerequisitesTo set up SAML authentication, you need:\nA Super-Admin role These instructions are specific to On-Premises Deployments of the Sysdig platform. If you are using the cloud-based (SaaS) Sysdig platform, refer to SAML (SaaS) instead.\nFor specific IdP integration information, refer to:\nOkta (SAML On-Prem)\nOneLogin (SAML On-Prem)\nAzure Active Directory (SAML On-Prem)\nADFS (SAML On-Prem)\nLimitations SAML Assertion Encryption/Decryption is not currently supported.\nSAML Single Logout is not supported. Therefore, users should take care to log out directly from Sysdig application(s).\nBasic Enablement Workflow Step\nOptions\nNotes\n1. Know which IdP your company uses and will be configuring.\nOkta (SAML On-Prem)\nOneLogin (SAML On-Prem)\nAzure Active Directory (SAML On-Prem)\nADFS (SAML On-Prem)\nThese are the IdPs for which Sysdig has performed detailed interoperability testing and confirmed how to integrate using their standard docs.\nIf your IDP is not listed, it may still work with the Sysdig platform. Contact Sysdig Support for help.\n2. Decide the login flow you want users to experience (choose from three options):\nClick SAML button\nFrom https://HOSTNAME/ or https://HOSTNAME/secure/\nType/bookmark a URL in browser\nMonitor:https://HOSTNAME/api/saml\nSecure: https://HOSTNAME/api/saml?product=SDS\nLog in from an IdP interface\nThe individual IdP integration pages describe how to add Sysdig to the IdP interface.\nYou will need your Sysdig customer number on hand. Normally 1 for on-premises.\n3. Perform the configuration steps in your IdP interface and collect the resulting config attributes.\nOkta (SAML On-Prem)\nOneLogin (SAML On-Prem)\nAzure Active Directory (SAML On-Prem)\nADFS (SAML On-Prem)\nCollect metadata URL (or XML) and test it.\nIf you intend to configure IDP-initiated login flow, have your Sysdig customer number on hand. It will be referenced in later configuration steps as CUSTOMER_ID_NUMBER. Normally 1.\n4 a. Log in to Sysdig Monitor (as \"super\" admin) and enter the necessary configuration information in the UI. Enable SAML as your SSO.\n4b. Log in to Sysdig Secure (as \"super\" admin) and repeat the above.\nAdministrator StepsConfigure IdPSelect the appropriate IdP from the list below, and follow the instructions:\nOkta (SAML On-Prem)\nOneLogin (SAML On-Prem)\nAzure Active Directory (SAML On-Prem)\nActive Directory Federation Service (SAML On-Prem)\nUI-Based: Configure SAML in SettingsAt this time, the Authorization UI is available only for Sysdig Monitor.\nTo enable baseline SAML functionality:\nEnter SAML Connection Settings Log in to Sysdig Monitor or Sysdig Secure as administrator and select Settings.\nSelect Authentication.\nSelect the SAML tab.\nEnter the relevant parameters (see table below) and click Save.\nIt is strongly recommended that \u0026quot;Signed Assertion\u0026quot; and \u0026quot;Validate Signature\u0026quot; are enabled to ensure that the SAML SSO process is as secure as possible. Connection Setting Options Description Metadata Discovery URL The URL provided at the end of the IdP configuration steps. XML An option you can use for an IdP that doesn\u0026rsquo;t support extracting metadata XML via URL. Verify Signed Assertion off/on Specify whether Sysdig should check for assertions signed in responses (to assist in validating correct IdP). We strongly recommend you toggle this on to increase security. Email Parameter email The parameter for the user email in SAML response. Sysdig uses this to extract the user\u0026rsquo;s email from the response. Validate Signature off/on Specify whether Sysdig backend should verify that the response is signed. We strongly recommend you toggle this on to increase security. Verify Destination Field off/on Specify whether Sysdig should check the \u0026ldquo;destination\u0026rdquo; field in the SAMLResponse. We recommend you toggle this on to increase security. You may toggle it off in special cases, such as when there is a proxy in front of the Sysdig back end. Create User on Login off/on Specify whether a user record should be created in the Sysdig database after the first successful SAML login. SAML Single Logout off/on Specify whether to use SAML single logout. See Configure SAML Single Logout. SAML Encryption off/on Specify whether to enable enable encrypted SAML response. See Encrypted SAML response. Username and Password Login off/on Specify whether to enable user name and password login. (Optional) Inactive Session Expiration off/on Specify the period of time a user can be inactive before the authenticated session will be suspended. See Configure Customized Session Expiration. Select SAML for SSO Select SAMLfrom the Enabled Single Sign-On dropdown\nClick Save Authentication.\nRepeat entire enablement process for Sysdig Monitor or Sysdig Secure, if you want to enable on both applications.\nScript-Based: Configure SAML Using ScriptsThe configuration of the SAML feature can be viewed, updated, and deleted by the \u0026ldquo;super\u0026rdquo; Admin. A saml_config.sh helper script is available in the SSO folder at sysdig-cloud-scripts repository to assist in completing this configuration. Invoking the script with no options will display help text.\n# ./saml_config.sh Must specify the Sysdig App whose SAML configuration will be viewed/set Usage: ./saml_config.sh [OPTIONS] Affect SAML login settings for your Sysdig software platform installation If no OPTIONS are specified, only the help output is displayed. To use the helper script, modify env.sh to set the required values for API_TOKEN of the \u0026ldquo;super\u0026rdquo; Admin user and the URL for accessing the Sysdig platform API (which will be the same URL that your users access for the Sysdig Monitor application).\nDepending if the API_TOKEN has been obtained from the Sysdig Monitor or Sysdig Secure application UI, the settings will be applied to the relevant product.\nInitially no SAML settings are set. A initial run of the script would confirm that:\n# ./saml_config.sh No saml settings are set Run for further info: ./saml_config.sh -h Add the -s option to set the SAML configuration for a particular Sysdig application. When setting the config, you\u0026rsquo;ll also include the metadata URL you saved in the earlier IDP configuration step (-m option) and specify the name of a supported IDP configuration (-i option), which will tailor other details of your SAML configuration to the specifics of that IDP. If the configuration is successfully posted to the Sysdig platform, the new configuration will be echoed back.\nAn example of creating the two separate SAML configurations for both Monitor and Secure, each using Okta IDP settings:\n# ./saml_config.sh -s -m \u0026#39;https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata\u0026#39; -i okta { \u0026#34;authenticationSettings\u0026#34;: { \u0026#34;id\u0026#34;: 1, \u0026#34;version\u0026#34;: 1, \u0026#34;createdOn\u0026#34;: 1547539750000, \u0026#34;type\u0026#34;: \u0026#34;saml\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;SYSTEM\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;metadataUrl\u0026#34;: \u0026#34;https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata\u0026#34;, \u0026#34;metadata\u0026#34;: null, \u0026#34;validateSignature\u0026#34;: true, \u0026#34;emailParameter\u0026#34;: \u0026#34;email\u0026#34;, \u0026#34;signedAssertion\u0026#34;: true, \u0026#34;verifyDestination\u0026#34;: true, \u0026#34;createUserOnLogin\u0026#34;: true } } } If you are using an IDP other than those available with the -i option, contact Sysdig Support for assistance with determining the correct settings.\nOnce you\u0026rsquo;ve completed this configuration, clicking the SAML button at the login screen of the appropriate Sysdig application(s) should redirect to your IDP for authentication.\nIf you wish to delete your SAML configuration, invoke the -d option. If successful, the disabled configuration will be printed.\n# ./saml_config.sh -a monitor -d { \u0026#34;authenticationSettings\u0026#34;: { \u0026#34;id\u0026#34;: 1, \u0026#34;version\u0026#34;: 1, \u0026#34;createdOn\u0026#34;: 1547539750000, \u0026#34;type\u0026#34;: \u0026#34;saml\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;SYSTEM\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;metadataUrl\u0026#34;: \u0026#34;https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata\u0026#34;, \u0026#34;metadata\u0026#34;: null, \u0026#34;validateSignature\u0026#34;: true, \u0026#34;emailParameter\u0026#34;: \u0026#34;email\u0026#34;, \u0026#34;signedAssertion\u0026#34;: true, \u0026#34;verifyDestination\u0026#34;: true, \u0026#34;createUserOnLogin\u0026#34;: true } } } Configure SAML Single LogoutSysdig supports SAML Single Logout (SLO).\nSLO is a feature in federated authentication where Sysdig users can sign out of both their Sysdig session (Service Provider) and associated IdP (Identity Provider) simultaneously. SLO allows you to terminate all sessions established via SAML SSO by initiating a single logout process. Closing all user sessions prevents unauthorized users from gaining access to Sysdig resources.\nSLO ProcessWhen a user initiates a logout, Sysdig sends a digitally-signed logout request to the IdP. The IdP validates the request and terminates the current login session, then redirects the user back to the Sysdig login page.\nCaveats SLO is currently supported only in US-West and EU-Central regions.\nSysdig does not support HTTP Post binding for single logout, and therefore, SLO with Okta is not functional at this point.\nConfigure IdP Configure logout URLs:\nMonitor: \u0026lt;base_URL\u0026gt;/api/saml/slo/logout\nSecure: \u0026lt;base_URL\u0026gt;/api/saml/slo/secureLogout\nChoose HTTP Redirect as the binding method.\nThis option is an alternative to the HTTP POST method, which Sysdig does not support currently.\nIf your IdP mandates, upload the public key for Sysdig.\nContact Sysdig Support to retrieve the public key associated with your deployment.\nCertain IDPs, such as Azure, don\u0026rsquo;t require uploading the public key.\nConfigure Sysdig Log in to Sysdig Monitor or Sysdig Secure as a super admin.\nFrom the user profile in the left navigation, select Settings.\nNavigate to Authentication.\nUnder Connection Settings, select the SAML tab. Enter the SAML configuration.\nEnsure that Enable SAML single logout is toggled on.\nClick Save.\nEnsure that you select SAML from the Enable Single Sign On drop-down.\nOptional: Auto-creation of user recordsWhen a user successfully authenticates via SAML, if a user record does not yet exist in the Sysdig platform database for their email address, one will be created at that time (default behavior). Some environments may not like this approach and may instead only want to permit logins for users whose records already exist (such as may have been already created via email invite or creation via the API).\nTo disable the auto-creation of user records after SAML authentication, add the -n option to your command line when applying your settings. This will set createUserOnLogin to false .\n# ./saml_config.sh -s -n -m \u0026#39;https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata\u0026#39; -i okta { \u0026#34;authenticationSettings\u0026#34;: { \u0026#34;id\u0026#34;: 2, \u0026#34;version\u0026#34;: 1, \u0026#34;createdOn\u0026#34;: 1547539856000, \u0026#34;type\u0026#34;: \u0026#34;saml\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;SYSTEM\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;metadataUrl\u0026#34;: \u0026#34;https://dev-824158.oktapreview.com/app/exkfpgqiskSoGZrjE0h7/sso/saml/metadata\u0026#34;, \u0026#34;metadata\u0026#34;: null, \u0026#34;validateSignature\u0026#34;: true, \u0026#34;emailParameter\u0026#34;: \u0026#34;email\u0026#34;, \u0026#34;signedAssertion\u0026#34;: true, \u0026#34;verifyDestination\u0026#34;: true, \u0026#34;createUserOnLogin\u0026#34;: false } } } User ExperienceAs noted in the Basic Workflow, above, you can offer users the following ways to log in with a SAML configuration:\nYou can provide an alternative URL to avoid the user having to enter a company name, in the format:\nSysdig Monitor: https://\u0026lt;HOSTNAME\u0026gt;/api/saml\nSysdig Secure: https://\u0026lt;HOSTNAME\u0026gt;/api/saml/secureAuth\nYou can configure an IdP-initiated login flow when configuring your IdP. The users then select the Sysdig application from your IDP\u0026rsquo;s app directory and do not browse directly to a Sysdig application URL at all.\nUsers that complete their first successful SAML login to Sysdig Secure may receive the error message \u0026ldquo;User doesn\u0026rsquo;t have permission to login in Sysdig Secure\u0026rdquo;. This is because only members of the Secure Operations team are permitted access to Sysdig Secure, and newly-created logins are not in this team by default. Such a user should contact an Administrator for the Sysdig environment to be added to the Secure Operations team.\nEnvironments that wish to have all users access Secure by default could use this example script to frequently \u0026ldquo;sync\u0026rdquo; the team memberships.\nSee also User and Team Administration for information on creating users.\n","url":"https://docs.sysdig.com/en/administration/onprem-saml-auth/"},{"id":357,"title":"Scanning Policy Gates and Triggers","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nThis information can also be obtained using the CLI:\nuser@host:~$ sdc-cli policy describe (--gate \u0026lt;gatename\u0026gt; (--trigger \u0026lt;triggername)) AlwaysThis gate provides users with a valuable testing resource, as it will be triggered unconditionally.\nalwaysThe always trigger / gate will trip if it is present in the policy.\nThe Always gate is useful for testing whether the image blacklist/whitelist is working as expected.\nDockerfileThe dockerfile gate reviews the contents of a Dockerfile, or the assumed contents of a dockerfile if one is not provided, for exposed ports and instructions that do not follow best practices.\nThe gate can assume what the contents would be based on the Docker layer history.\neffective_userThis trigger reviews whether the effective user matches the user provided, and will fire based on the configured type.\nParameter Description Example type Determines whether the user should be whitelisted or blacklisted. N/A user The name of the user. root,docker exposed_portsThis trigger evaluates the set of exposed ports to determine whether they should be whitelisted or blacklisted.\nParameter Description Example actual_dockerfile_only Defines whether the evaluation should skip inferred or guessed Dockerfiles, and only evaluate user-provided Dockerfiles. The default value is false. true ports A comma-separated list of port numbers. 80,8080,8088 type Defines whether the ports should be whitelisted or blacklisted. N/A instructionThis trigger evaluates whether any directives/instructions in the list match the conditions in the Dockerfile.\nParameter Description Example actual_dockerfile_only Defines whether the evaluation should skip inferred or guessed dockerfiles, and only evaluate user-provided dockerfiles. The default value is false. true check The type of check to perform. = instruction The dockerfile instruction to check. FROM value The value to check the dockerfile instruction against. scratch no_dockerfile_providedThis trigger will trip if there is no Dockerfile supplied with the image. No parameters are required for this trigger.\nFilesThe Files gate reviews files within the analyzed image. This evaluation covers file content, names, and filesystem attributes.\ncontent_regex_matchThis trigger is tripped for each file where a match has been found using the configured regex in the analyzer_config.yaml content_search section.\nFor more information regarding the regex values, refer to the analyzer_config.yaml file.\nParameter Description Example regex_name The regex string that appears in the FILECHECK_CONTENTMATCH analyzer parameter. .*password.* name_matchThis trigger is tripped if the name of a file in the container matches the provided regex.\nThis trigger has a performance impact on policy evaluation.\nParameter Description Example regex The regex to search for. .*\\.pem suid_or_guid_setThis trigger is tripped for each file that has a set-user identification (SUID) or set-group identification (SGID) configured. No parameters are required.\nLicensesThis gate is used to review software licenses found in the container image, to ensure, for example, that packages that violate internal company policy are not being used.\nblacklist_exact_matchThis trigger will be tripped if the image contains packages distributed under the exact license specified.\nParameter Description Example licenses A comma-separated list of license names to blacklist. GPLv2+,GPL-3+,BSD-2-clause blacklist_partial_matchThis trigger will be tripped if the image contains packages distributed under a license that includes the partial strings provided.\nParameter Description Example licenses A comma-separated list of strings to blacklist for licenses. LGPL,BSD MetadataThis gate reviews image metadata, including the size, operating system, and architecture.\nattributeThe attribute trigger is tripped if a named image metadata value matches the given condition.\nParameter Description Example attribute The attribute name to check. size check The operation to perform for the evaluation. \u0026gt; value The value used for the evaluation. 1073741824 PackagesThe Packages gate reviews all packages within the image, verifying names, versions, and whitelisted / blacklisted packages.\nblacklistThis trigger is tripped if the image contains packages that have been blacklisted by either name, or name and version.\nParameter Description Example name The name of blacklisted package/s. openssh-server version The exact version of the package that should be blacklisted. 1.0.1 required_packageThe required_package trigger is tripped if the specified package / version is not found in the image.\nParameter Description Example name The name of the required package. libssl version The required package version. 1.10.3rc3 version_match_type Defines whether the trigger should require the exact package and version (exact), or just a version of the package (minimum). This is only relevant if the version is defined. exact verifyThis trigger reviews the package integrity against the package database in the image, and is tripped for change or removal of content in either all or a defined list of directories provided.\nParameter Description Example check Defines whether the check should focus on missing packages, changed packages, or all. changed only_directories Defines the list of directories the check should be limited to. /usr,/var/lib only_packages Defines the list of packages that should be verified. libssl,openssl Passwd FileThis gate reviews /etc/passwd for blacklisted users, groups, and shells.\nblacklist_full_entryThis trigger trips if the whole password is found in the /etc/password file.\nParameter Description Example entry The full entry to match in /etc/passwd. ftp:x:14:50:FTP User:/var/ftp:/sbin/nologin blacklist_groupidsThis trigger is tripped if the designated group id/s are found in the /etc/passwd file.\nParameter Description Example group_ids A numeric, comma separated list of group ids that will cause the trigger to trip. 999,20 blacklist_shellsThis trigger will trip if a designated login shell is found under any user in the /etc/passwd file.\nParameter Description Example shells The list of shell commands to blacklist. /bin/bash,/bin/zsh blacklist_useridsThis trigger will be tripped if the specified user ID is present in /etc/passwd.\nParameter Description Example user_ids The numerical, comma-separated list of user IDs to blacklist. 0,1 blacklist_usernamesThe blacklist_usernames trigger will trip if the specified username is found in the /etc/passwd file.\nParameter Description Example user_names A comma-separated list of usernames to blacklist. daemon,ftp content_not_availableThe content_not_available trigger will trip if the /etc/passwd file is not present in the image. No parameters are required.\nSecret ScansSecret scans determine, based on configured regex, whether secrets that could be available if an image was compromised have been baked into the image.\ncontent_regex_checksThe content_regex_checks trigger trips if the content search analyzer finds a match with the configured and named regexes. Matches are filtered by the content_regex_name, and the filename_regex, if either are set.\nThe content_regex_name should be a value from the secret_search section of analyzer_config.yaml.\nParameter\nDescription\nExample\ncontent_regex_name\nThe name of the variable / content. If found in the image, this should trip the trigger.\nThe names available by default are AWS_ACCESS_KEY, AWS_SECRET_KEY, PRIV_KEY, DOCKER_AUTH, and API_KEY.\nAWS_ACCESS_KEY\nfilename_regex\nFilters the files that should be analyzed for the presence of the content_regex_name.\n/etc/.*\nVulnerabilitiesCVE / vulnerability checks can be used to ensure the included packages don\u0026rsquo;t have vulnerabilities above a set level, are older than a designated period, or if data is unavailable.\npackageThe package trigger is tripped if a vulnerability in an image matches the configured comparison criteria. The table below outlines the available parameters and criteria:\nParameter Description Example fix_available If present, the fix availability for the vulnerability record must match the value of the parameter. true package_type The specific type of package. all severity The vulnerability severity. high severity_comparison The type of comparison to perform for the security evaluation. \u0026gt; vendor_only If true, an available fix for this CVE must not be explicitly marked as \u0026ldquo;Won\u0026rsquo;t be addressed by the vendor\u0026rdquo;. true stale_feed_dataThe stale_feed_data trigger will be tripped if the CVE data is older than the window specified.\nParameter Description Example max_days_since_sync Determines how old in days sync data can be before the trigger is tripped. 10 vulnerability_data_unavailableIf no vulnerability data is available, the vulnerability_data_unavailable trigger will trip. No parameters are required for this trigger.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/manage-scanning-policies/scanning-policy-gates-and-triggers/"},{"id":358,"title":"Search","content":"Search provides a powerful, in-depth view of your cloud and container environments. This holistic approach helps security teams gain visibility into how connected cloud resources can be impacted during an attack by identifying potential security risks, such as attack paths, hidden threats, and vulnerabilities. With the Search feature, teams can uncover these threats and respond faster.\nChoose Graph Search to access the search feature.\nChoose from the library or use the Search query window to create custom queries to search for security risks in their environment. Search is grouped by Risk, Posture, and Vulnerabilities based on fields and relationships using the following:\nPrerequisitesRead permissions to Search.\nEnsure that you are assigned to a Custom Role with read permissions to Search.\nExporting data will also require the export permission to Search.\nForm-Based Query BuilderThis lets you define an initial simplified SysQL query by selecting the primary entity and a set of relationships or conditions for it.\nThe form-based query builder is classified by categories. The left window contains:\nEntity selector Suggestions library Favorite Queries Entity SelectorUse the search interface to set the primary entity to search and select a set of fields or relationship conditions for it. From left to right, displayed as three columns, you select a category, the entity, and optionally a set of entity conditions.\nCategories: The first column shows a list of categories. Categories group the following entities:\nApplication: User-facing software components and services Compute: Virtual machines, containers, and other resources that provide processing power to run workloads and applications. Environment: Cloud accounts, regions, zones, and other cloud-environment related entities. Findings: Security issues that have been identified, such as a misconfigurations or a vulnerability. Identity: Entities such as Users, Roles, Service Accounts, or Access Policies. Kubernetes: Kubernetes-specific entities, such as Cluster, Node, or Deployment. Secrets: Entities such as Encryption Keys or Managed Certificates. Storage: Storage-related entities such as databases or buckets. Entities: The second column shows the entities that are grouped by the selected category.\nEntity Conditions: The third column lets you select the fields associated with the chosen entity, or relationships between the selected entity to another. For instance, you can select the Name field of an entity or the relationship, \u0026ldquo;With Zone\u0026rdquo;.\nAssisted QueriesUse the Ask me a question\u0026hellip; field at the top of the page to build a query automatically based on natural language.\nSuggestions LibraryThe Suggestions Library contains a list of suggested Search queries.\nFavorite QueriesYou can add a query as a favorite to use later. Once you have created a simplified SysQL string, click the icon. Your list of favorite queries is available in the query builder window under the Favorite queries tab.\nBuild a Search QueryTo build a search query using the form-based query builder:\nClick the Start building your query\u0026hellip; box.Suggestions appear from the drop-down.\nClick the icon and select a Category. A second column appears showing the list of entities for that category.\nSelect the entity that you want to search. Another column appears showing the available field and relationship conditions for the entity.\nIn the third column, click a single or multiple checkboxes to select relationships or field conditions.\nSelect Go.\nThe search query is created.\nSearch Query Examples To find all S3 buckets in EU regions: Resource Type contains S3 AND Region startsWith eu\nTo search for all Workloads of type host with names starting with prod: Resource Type is host AND Name startsWith prod\nTo view all resources that are not labeled: Labels not exists\nEdit a QueryAfter you create a query, you can add, remove, or mark certain parameters as optional. For every query you build, hover over the query on each line to view the following options:\nDelete entity or condition. Mark condition as optional. For example, marking the condition THAT IS AFFECTED BY Vulnerability as Optional, will show also the results that do not match that condition. You cannot mark the primary entity or a field-condition (WHERE clause) as optional. Hide entity. You can hide an entity from appearing in the results. Add a condition to this Entity. You can add nested conditions to the entity defined in that row. Write Your Query with SysQL EditorTo write your own SysQL query, use the SysQL editor. To access it, do one of the following:\nSysQL Editor icon on the Search page.\nNavigate to Graph Search.\nClick the SysQL Editor icon.\nEnter your query and click Run.\nEdit in Code Editor option on the Query builder.\nSelect the three-dots menu on the Query builder to access the SysQL Editor.\nEdit the query and click Run.\nSave the Query as Custom RiskWhen creating custom risks from queries, consider the following:\nRisks on ResourcesResource entities represent the foundational nodes that are interconnected in your infrastructure, and Finding entitites represent security related detections on the resources, such as events or vulnerabilities. To save as Risk, the primary entity must be a Resource.\nRisks with Query ConditionsThe query must include at least one filter to be considered a risk query. You can apply filter in the following two ways:\nA WHERE clause that refines the resource selection. A relation that matches entities connected to the primary resource. This ensures the query yields meaningful results, rather than a plain list of resources, by applying logical filtering.\nFrom Resources to FindingsThe query should only use outgoing relationships from resource entities. For example, the following query cannot be considered a valid risk query because it uses a vulnerability as a \u0026ldquo;bridge\u0026rdquo; to connect unrelated workloads:\nMATCH (EC2Instance) -[:AFFECTED_BY]-\u0026gt;(Vulnerability) -[:THAT_AFFECTS]-\u0026gt;(KubeWorkload) This constraint ensures that the identified risks represent valid attack surfaces, not accidental relationships between unconnected resources.\nFor more information, see Custom Risks\nRestricted Outgoing ConnectionsThe following entities cannot have outgoing connections to prevent invalid queries:\nMetadata Label Zone Region Policy Policy Vuln Vulnerability CriticalVulnerability Controls Control PrivilegedControl S3AcceptsHTTP S3VersioningDisabled ContainsAIPackage IAM Findings RiskFinding CompromisedState Runtime Events RuntimeEvent Resource DetailsWhen you click on any of the search queries, the Resource Details drawer appears. To learn more about the resource drawer, see View Resource Details.\nDownload Search DataYou can download the results of a Search query as a file in CSV format from the Search table. To download:\nRun a Search query or navigate to the Search result.\nOn the Search results page, click the three-dot menu at the top-right corner of the search results table.\nClick Download CSV.\nThe default number of lines in the CSV will be 10,000, after which the search results will be cut off.\nTo view the Download history, click Download History.\nYou can view the name of the file, completion status, and the date when the CSV file is generated.\nHover over any of the rows in the table to reveal a Download button that you can use to download the file.\nView Malware Scanning ResultsWhen Malware Scanning is enabled, you can view results in the Search module. To view Malware Scanning results:\nLog in to Sysdig Secure.\nNavigate to Graph Search.\nSpecify the following SysQL Graph Query:\nMATCH CloudResource CONTAINS Malware RETURN DISTINCT CloudResource, Malware LIMIT 50; Click Run. The Search returns any available Malware Scanning findings.\nFor more details on Malware Scanning, see Malware Scanning.\n","url":"https://docs.sysdig.com/en/sysdig-secure/search/"},{"id":359,"title":"Serverless Agent Release Notes","content":"Serverless Patcher 5.4.4 May 13, 2026Vulnerability FixesAddressed the following vulnerabilities in Serverless Patcher:\nCVE-2026-32280 CVE-2026-32281 CVE-2026-32283 CVE-2026-33811 CVE-2026-33814 CVE-2026-39836 CVE-2026-4878 CVE-2026-32282 CVE-2026-32288 CVE-2026-32289 CVE-2026-39820 CVE-2026-39823 CVE-2026-39825 CVE-2026-39826 CVE-2026-42499 Serverless Agent 6.2.1 May 12, 2026Defect Fixes Fixed an issue where termination signals were not properly forwarded to the agent in sidecar mode. Fixed an issue on ARM64 that could occur in workloads containing specific Go binaries. Vulnerability FixesAddressed the following vulnerabilities in Workload Agent:\nCVE-2026-32280 CVE-2026-32281 CVE-2026-32283 CVE-2026-33811 CVE-2026-33814 CVE-2026-39836 CVE-2026-32282 CVE-2026-32288 CVE-2026-32289 CVE-2026-39820 CVE-2026-39823 CVE-2026-39825 CVE-2026-39826 CVE-2026-42499 Serverless Patcher 5.4.3 March 18, 2026Vulnerability FixesAddressed the following vulnerabilities in Serverless Patcher:\nCVE-2025-15281 CVE-2025-61726 CVE-2025-61728 CVE-2025-61730 CVE-2025-68121 CVE-2025-68212 CVE-2026-0861 CVE-2026-0915 CVE-2025-15558 CVE-2026-25679 CVE-2026-27139 CVE-2026-27142 Serverless Agent 6.2.0 March 16, 2026EnhancementsMalware Detection for AWS ECS Fargate Sysdig now extends Malware Detection to AWS ECS Fargate via Workload Agent sidecar deployments. This allows security teams to identify malicious binaries and known malware hashes within serverless workloads without sacrificing cloud-native scalability. For more information, see Malware Detection. The feature is disabled by default. Defect Fixes Fixed an issue where instrumented Go workloads could occasionally terminate unexpectedly while instrumenting socket system calls. Vulnerability FixesAddressed the following vulnerabilities in Workload Agent:\nCVE-2025-25679 CVE-2025-27139 CVE-2025-27142 CVE-2025-61726 CVE-2025-61728 CVE-2025-61730 CVE-2025-68121 Serverless Patcher 5.4.2 December 19, 2025Vulnerability FixesAddressed the following vulnerabilities in Serverless Patcher:\nCVE-2025-61727 CVE-2025-61729 ","url":"https://docs.sysdig.com/en/release-notes/serverless-agent-release-notes/"},{"id":360,"title":"Submit a Support Ticket","content":"Specify Ticket DetailsAdd details in the Description box. See below for tips on what to enter:\nOperating System: Orchestrator: Agent Version: Company Name: Operating SystemReview Host Requirements for Agent Installation to confirm that your operating system is supported.\nSubmitting the output of uname -a and lsb_release -a will help Sysdig support determine if the kernel is supported.\nIf you have a custom kernel and the kernel development headers are not available, you will not be able to install our agent.\nAlso note if the Linux distribution used inside your application\u0026rsquo;s container is not the same as the host.\nlsb_release is part of a software package called the LSB core, which is not necessarily installed on your system by default. If it is not installed, see https://wiki.itcollege.ee/index.php/Lsb_release.\nOrchestrator DetailsWhen using the Sysdig agent in an orchestration infrastructure, such (Kubernetes, GKE, etc., submit the details of how the the infrastructure was installed.\nFor example:\nWhich Kubernetes version\nThe cloud provider being run under (AWS, GKE, etc.)\nThe number of nodes\nThe authentication method configured for the API server\nAgent VersionTo verify which agent version you are running, either:\nOn the product UI, select Integrations \u0026gt; Sysdig Agents.\nUse the following command:\nAgent in a non-container environment:\n/opt/draios/bin/dragent --version Agent in a container:\nsudo docker exec -it \u0026lt;container_id\u0026gt; /opt/draios/bin/dragent --version Agent in Kubernetes:\nkubectl -n sysdig-agent exec -ti \u0026lt;agent_pod\u0026gt; -c sysdig -- bash -c \u0026#34;/opt/draios/bin/dragent --version\u0026#34; Known issues may be resolved by upgrading to the latest agent version.\nAgent release numbers are shown in the agent build list, and agent release notes can be accessed from the Release Notes\nSee Agent Upgrade.\nUpload FilesIf basic ticket information is insufficient to resolve the issue, a Sysdig support engineer may ask you to upload additional log files or support bundles.\nThe following sections describe how to collect and deliver them to Sysdig support.\nAdd Agent Files\nAdd Browser Files\nAdd Backend Files (On-Premises Only)\nFile Uploading Tips Attach files rather than cutting/pasting logs or configuration files into the email body. Important formatting will be preserved.\nCompress large files before attaching. Files over 20MB will require Sysdig support to supply you with a download link.\nInclude the host name the files came from.\n","url":"https://docs.sysdig.com/en/docs/support/submit-a-support-ticket/"},{"id":361,"title":"SysQL Reference Library","content":"How Does SysQL Work?Sysdig stores your resource inventory together with the security findings, such as events or vulnerabilities, in the Sysdig datastore. This allows you to design queries that match complex paths through the connected data. SysQL is available in a web user interface that helps designing queries in an interactive way with the following widgets:\nSysQL builder: Enables you to build your query from scratch by defining entities. SysQL editor: Helps you update your SysQL query, and add more entities. Additionally, you can use the SysQL Public APIs to build queries and retrieve resources from the Sysdig Secure datastore programmatically.\nClauses and SubclausesSysQL uses the following basic key clauses to structure and filter queries:\nClauses Description MATCH Defines the pattern to match in the graph OPTIONAL Used with MATCH to specify optional patterns WHERE Filters results based on specified criteria A Clause is the fundamental component of a SysQL and it defines specific operations or constraints. SysQL is structured using different clauses to manipulate and retrieve graph data efficiently. MATCH and OPTIONAL MATCH are the main clauses in SysQL.\nFor example: MATCH Vulnerability LIMIT 10;\nA Subclause typically refers to a part of a larger SysQL query that performs a specific function or operation within the query. These subclauses help to organize and refine the query logic.\nFor example: LIMIT 10\nMATCHMATCH is the first clause of every SysQL query. Multiple MATCH clauses combine into a single pattern. MATCH is logically similar to the FROM clause in SQL.\nThe MATCH clause is the starting point of every SysQL statement. It defines the patterns to search for in the graph and is the main way to retrieve data. Typically, it is used with WHERE to refine results. Multiple MATCH clauses can be combined into one pattern.\nExample: Get Vulnerability DataYou can retrieve vulnerability data stored in the graph by executing the following SysQL statement:\nMATCH Vulnerability LIMIT 10; OPTIONAL MATCHOPTIONAL MATCH functions similarly to MATCH in pattern matching within the graph database. The key difference is that if no matches are found, OPTIONAL MATCH returns null for the missing parts of the pattern instead of failing. It can be considered the SysQL equivalent of an outer join in SQL, where either the entire pattern is matched or null is returned for unmatched elements.\nIf a relationship is optional, use the OPTIONAL MATCH clause. This works like a SQL outer join—returning the relationship if it exists or null if it does not.\nExample: Retrieve all the Affected Kubernetes WorkloadsIf you want to retrieve all Kubernetes workloads affected by vulnerabilities, and optionally list any runtime events generated by them, issue the following SysQL statement:\nMATCH KubeWorkload AS k AFFECTED_BY Vulnerability OPTIONAL MATCH RuntimeEvent GENERATED_BY k; WHEREWHERE is not a standalone clause but can be placed after a MATCH clause. It adds constraints to the pattern in a MATCH or OPTIONAL MATCH clause, functioning as an optional component rather than a separate clause.\nExample: List Vulnerabilities with Names Ending 123To list vulnerabilities with names ending in \u0026lsquo;123\u0026rsquo; that also affect packages, run the following SysQL statement:\nMATCH Vulnerability AS v AFFECTS Package WHERE v.name =~ \u0026#39;CVE-.\\*123\u0026#39;; Comparison OperatorsThe comparison operators comprise:\nEquality: = Inequality: \u0026lt;\u0026gt; Less than: \u0026lt; Greater than: \u0026gt; Less than or equal to: \u0026lt;= Greater than or equal to: \u0026gt;= IS NULL IS NOT NULL Additional Operators STARTS WITH: Performs case-sensitive prefix searching on STRING values. ENDS WITH: Performs case-sensitive suffix searching on STRING values. CONTAINS: Performs case-sensitive inclusion searching in STRING values. =~: Regular expression for matching a pattern. RETURNRETURN is logically similar to the SELECT clause in SQL.\nThe RETURN clause specifies what to include in the query result. It is an essential part of your SysQL statement, where you define the parts of the pattern you are interested in. These can include nodes, relationships, or properties of these elements.\nThe term \u0026ldquo;entity\u0026rdquo; refers to either a node or a relationship within the graph.\nExample: Return an Entity or NodeTo return a node, list it in the RETURN statement:\nMATCH ​​AWSAccount AS a WHERE a.id = \u0026#39;474668386876\u0026#39; RETURN a; The query returns the AWS Account entity with the account ID \u0026lsquo;474668386876’.\nExample: Return the RelationshipsTo return a relationship, just include it in the RETURN list.\nMATCH AWSAccount AS a IN AWSOrganization AS b WHERE a.id = \u0026#39;474668386876\u0026#39; RETURN IN; The query returns the IN relationship.\nMATCH Vulnerability AS v AFFECTS Package RETURN v.name AS NAME, AFFECTS.vulnPkgId LIMIT 50 OFFSET 5; Example: Return the PropertiesTo return a property, use dot notation:\nMATCH AWSAccount AS a WHERE a.id = \u0026#39;474668386876\u0026#39; RETURN a.name; The query returns the AWS Account name of the account ID \u0026lsquo;474668386876’.\nExample: Return all the ElementsTo return all elements, run the following query:\nMATCH AWSAccount AS a IN AWSOrganization AS b WHERE a.id = \u0026#39;474668386876\u0026#39; RETURN a, IN, b; The query returns the AWS Account, AWS Organization, and the IN relationship.\nExample: Alias a FieldTo rename a field, use AS :\nMATCH AWSAccount AS a WHERE a.id = \u0026#39;474668386876\u0026#39; RETURN a.name AS accountName; Returns the name of the AWS account, but renames the field as accountName.\nDISTINCTDISTINCT retrieves only the unique records based on the fields selected for output.\nMATCH AWSAccount AS a RETURN DISTINCT a; The query returns node AWSAccount once.\nReturn ItemsYou can request for nodes, property references, functions, certain other operators like existential and pattern comprehension in the query result.\nMATCH AWSAccount AS a RETURN a ORDER BY a.name; PaginationORDER BYORDER BY is a sub-clause following RETURN, and it specifies how the output should be sorted.\nTo return sorted results, use the following syntax:\nMATCH AWSAccount AS a RETURN a ORDER BY a.name; LIMIT/OFFSETLIMIT constrains the number of records in the output. It accepts any expression that evaluates to a positive integer.\nTo return a subset of the result, run the following query:\nMATCH AWSAccount AS a RETURN a LIMIT 10; # returns the first 10 results MATCH AWSAccount AS a RETURN a LIMIT 10 OFFSET 10; # returns the results 10 - 20 MATCH AWSAccount AS a RETURN a LIMIT 10 OFFSET 20; ## returns the results 20 - 30 SysQL ConceptsGraph PatternsA graph pattern is the core component of MATCH, existential operators, and pattern comprehensions.\nIt consists of a mandatory node followed by an optional, unbounded alternation between edges and nodes.\nNode EDGE Node\\*\nNodesNodes are the primary objects in the graph. They are always represented as nouns and written in title case, such as KubeNode or AWSRegion.\nAliasingNodes in the MATCH clause are implicitly aliased with the node label. In a simple query like:\nMATCH AWSAccount RETURN AWSAccount; AWSAccount serves as both the node label and the node alias. To assign a custom alias, use the AS keyword.\nMATCH AWSAccount AS a RETURN a; This is sometimes necessary, as in:\nMATCH AWSResource AS parent PARENT_OF AWSResource AS child RETURN parent, child; If no aliases are introduced using AS:\nMATCH AWSResource PARENT_OF AWSResource; The query would search for an AWSResource connected to itself by a PARENT_OF relationship.\nRelationshipsRelationships are directed connections between nodes in a graph. They represent the associations between entities (nodes) and have both a type and direction. Each relationship can also have properties associated with it, just like nodes. Relationships are used to model how entities are related to one another in the graph, and they form the backbone of graph data models.\nVirtual RelationshipsVirtual relationships are not explicitly stored in the database but are inferred or computed at query time. They help simplify queries by representing patterns or connections without adding physical edges to the graph.\nFunctions and Other OperatorsScalar FunctionsSysQL provides scalar functions, which are built-in functions that process a single value and return a single result. These functions enhance data manipulation efficiency and simplify complex calculations within SysQL.\nMathematical Numerical FunctionsThese functions operate only on numeric expressions and will return an error if used with any other data types. The following are the supported numeric mathematical functions:\nabs()abs() returns the absolute value of the given number.\nSyntax: abs(expression)\nTo retrieve the absolute CVSS score of vulnerability, you can use the following query:\nMATCH Vulnerability AS v RETURN abs(v.cvssScore) AS score, v.name; Aggregating FunctionsSysQL provides aggregation capabilities similar to SQL’s GROUP BY for computing aggregated data.\nAggregating functions process a set of values to compute a single aggregated result. Examples include\navg(): calculates the average of multiple numeric values min(): finds the smallest numeric or string value within a dataset. When using an aggregation function on a set of values, it applies the inner expression, for example n.CvssScore, to all records within the same aggregation group.\nTo sort the result set using aggregations, the aggregation must be included in the RETURN clause so that it can be referenced in ORDER BY.\nYou can use the DISTINCT operator alongside aggregation to ensure all values are unique before applying the aggregate function.\nAggregating functions are not a GROUP BY clause. All RETURN items that are aggregated serve as grouping keys. A grouping key is essentially a unique tuple (a window or bin), and aggregates are computed independently for each unique grouping key.\ncount()count() returns the number for values or records. It returns an integer.\nSyntax: count(expression)\nTo retrieve the total count of vulnerabilities with Critical severity, use the following query:\nMATCH Vulnerability AS v WHERE v.severity = \u0026#39;Critical\u0026#39; RETURN count(1) AS criticalVulnerabilityCount; min()min() returns the minimum value in a set of values.\nSyntax: min(expression)\nYou can use the following syntax to retrieve the vulnerability with the lowest CVSS score.\nMATCH Vulnerability AS v RETURN min(v.cvssScore) AS score, v.name; max()max() returns the maximum value in a set of values.\nSyntax: max(expression)\nYou can use the following syntax to retrieve the vulnerability with the highest CVSS score.\nMATCH Vulnerability AS v RETURN max(v.cvssScore) AS score, v.name; avg()avg() returns the average of a set of numerical values. It returns either an Integer or a Float, based on the expression\u0026rsquo;s values and whether the calculation results in an overflow.\nSyntax: avg(expression)\nYou can use the following syntax to retrieve the vulnerability with the highest CVSS score.\nMATCH Vulnerability AS v RETURN avg(v.cvssScore) AS score, v.name; collect()collect() returns a list of values produced by an expression, aggregating multiple records or values into a single list. The resulting list can contain heterogeneous elements, with types determined by the values returned by the expression.\nSyntax: avg(expression)\nYou can use the following syntax to collect the distinct severities in a single list.\nMATCH Vulnerability AS v RETURN collect(DISTINCT v.severity) AS severities; Invalid Query ExamplesWhen using SysQL, certain queries may not return results or could be invalid. Following are a few examples:\nQuery Reason MATCH EC2Instance THAT IS AFFECTED BY Vulnerability THAT AFFECTS KubeWorkload EC2Instances and KubeWorkloads are unrelated in your real infrastructure. They appear related in the graph only due to the vulnerability, but this does not reflect an actual relationship. MATCH KubeWorkload THAT IS AFFECTED BY Vulnerability THAT AFFECTS KubeWorkload This query creates a cyclic traversal, leading to an empty result set. ","url":"https://docs.sysdig.com/en/sysdig-secure/sysql-reference/"},{"id":362,"title":"System Requirements","content":"Supported DistributionsLinux DistributionsFor each server instance, a 64-bit Linux distribution with a minimum kernel version of 3.10, and support of docker-engine 1.7.1 or later, is required.\nRecommended Linux distributions: RedHat, Ubuntu, Amazon Machine Images (AMI), Amazon Linux 2.\nDocker RequirementsFor the Docker installation, running devicemapper in \u0026rsquo;loopback mode\u0026rsquo; is not supported. It has known performance problems and a different storage driver should be used. See this note from our Replicated infrastructure partner: devicemapper-installation-warning.\nInstalling the latest version of Docker is recommended.\nCassandraCassandra is used as the metrics store for Sysdig agents. It is the most dynamic component of the system, and requires additional attention to ensure your system is highly responsive and performing well.\nThis component is stateful, and should be treated more carefully than stateless components. Cassandra sizing is based on a minimum replication factor as well as the number of agents writing data.\nA minimum replication factor of 3 is recommended for the Sysdig application, which allows the cluster to survive the failure of 1 Cassandra instance.\nEach agent consumes anywhere from 500MB to 2GB of Cassandra storage, with average sizing at 1.5GB per agent. Because of Sysdig\u0026rsquo;s data aggregation model, this storage should comfortably handle multi-year history. This needs to then be multiplied by the replication factor to determine the total disk space required. A rough calculation might be:\n100 agents = 150GB raw X replication factor of 3 = 450GB total\nTo be safe, we recommend you size some additional disk space as buffer (say 25-50%) on top of that.\nNetwork ConfigurationThe following firewall/security configurations are required for the Sysdig platform\u0026rsquo;s inbound and outbound traffic:\nPorts Port\nState\nDirection\nDescription\n6666\nOpen (optional)\nInbound\nAgent communication (unencrypted).\n6443\nOpen\nInbound\nAgent Communication (TLS/encrypted).\n443\nOpen\nInbound\nSysdig Monitor user-interface access inbound.\n443*\nOpen\nOutbound\nOptional: Used if collecting Amazon Web Service (AWS) CloudWatch metrics. See Integrate AWS Account and CloudWatch Metrics (Optional).\n443*\nOpen\nOutbound\nOptional: Needed if using Sysdig Secure Image Scanning to download vulnerability definitions.\nMust be open to Cloudflare IP ranges: https://www.cloudflare.com/ips/.\n8800\nOpen\nInbound\nReplicated Management Console access (for on-premises installations that don't use Kubernetes).\nWarning: Port 6666 should only be opened if agents will be communicating with the collectors without encryption.\nAdditional ports may need to be configured for the Replicated infrastructure manager. See Replicated port requirements for more information.\nHTTP/HTTPS and Proxy SupportAll non-airgapped hosts require outbound HTTP/S internet access for:\nLicense validation\nPulling Sysdig/Agent containers from the Docker hub repository\nChecking for release updates\nNote: Sysdig does not support HTTP and HTTPS proxies for Sysdig platform components.\nSummary: Plan Proxy Support for Notification Channels, CloudWatch Metrics, Capture StorageIn the Sysdig platform back-end, you can configure outgoing HTTP/HTTPS connections via proxy. This has been tested and supports outgoing web connections needed to support the following features:\nNotification Channels\nPagerDuty\nSlack\nAmazon Simple Notification Service (SNS)\nVictorOps\nOpsGenie\nWebHook\nGathering of AWS CloudWatch data\nCapture storage to an AWS Simple Storage Service (S3) bucket\nProxied web connectivity to support authentication mechanisms, such as Security Assertion Markup Language (SAML), OpenID Connect, and OAuth, are not supported.\nConfigure Proxy Using JVM OptionsYou configure proxy settings via the Java virtual machine (JVM) options passed to the Sysdig software components. JVM options can be added at any time, with a required restart.\nIn a Kubernetes-based on-premises install, set the sysdigcloud.jvm.options in the config.yaml used to set the ConfigMap:\n# Optional: Sysdig Cloud application JVM options. For heavy load environments you\u0026#39;ll need to tweak # the memory or garbage collection settings sysdigcloud.jvm.api.options: \u0026#34;\u0026#34; sysdigcloud.jvm.worker.options: \u0026#34;\u0026#34; sysdigcloud.jvm.collector.options: \u0026#34;\u0026#34; Enter the proxy parameters, as in the example below.\nThis JVM options string will forward all HTTP and HTTPS traffic via outgoing port 8888 on a proxy at hostname proxy.example.com. The IP address may be specified instead of hostname.\n-Dhttp.proxyHost=proxy.example.com -Dhttp.proxyPort=8888 -Dhttps.proxyPort=8888 -Dhttps.proxyHost=proxy.example.com # Optional: Sysdig Cloud application JVM options. For heavy load environments you\u0026#39;ll need to tweak # the memory or garbage collection settings sysdigcloud.jvm.api.options: -Xms2048m -Xmx2048m -Dhttp.proxyHost=xxx.xxx.sysdig.com -Dhttp.proxyPort=80 -Dhttps.proxyHost=xxx.xxx.sysdig.com -Dhttps.proxyPort=80 Exclusions Do not use local host or 127.0.0.1. By default, HTTP/HTTPS requests to localhost or 127.0.0.1 will not be directed by the back-end toward any configured proxy, which is necessary for the functioning of some web components internal to the Sysdig platform containers.\nIf you deploy the Sysdig platform in AWS, add an additional proxy parameter:\n-Dhttp.nonProxyHosts=169.254.169.254\nRationale: This provides a work-around for the backend occasionally making HTTP requests to a special instance metadata address 169.254.169.254, which is undesirable when using a proxy.\nThis IP address will be excluded from proxying by default in a future release.\nIf you have additional proxy exclusions you wish to specify that are unique to your environment, these can also be added using the pipe separator.\nFor example, assume your deployment was in AWS and you also had a webhook target 192.168.1.2 that was not reachable via your proxy. To exclude both:\nKubernetes: when setting the sysdigcloud.jvm.api.options and sysdigcloud.jvm.worker.options in the config.yaml for the ConfigMap, the pipe separator must be double-escaped, such as:\n-Dhttps.proxyPort=80 -Dhttps.proxyHost=xx.xx.sysdig.com -Dhttp.nonProxyHosts=169.123.169.123\\\\|127.0.0.1\\\\|localhost\\\\|.sysdig.com\u0026#34; Time SynchronizationThe Sysdig platform requires hosts to have synchronized system clocks. When provisioning hosts for installation, ensure the system clocks are synchronized.\nSysdig recommends you install Network Time Protocol (NTP) to ensure all host clocks stay synchronized.\n","url":"https://docs.sysdig.com/en/administration/onprem-system-req/"},{"id":363,"title":"Troubleshoot GCP Agentless Connections","content":"Check for Workload Identity Federation ConfigurationMisconfigured GCP Workload Identity Federation (WIFs) can commonly hinder Sysdig\u0026rsquo;s operation by denying required permissions. To check for WIFs that may impact Sysdig Integrations (replace PROJECTID and PROJECTNUMBER as needed):\nLog into GCP console and select the affected project in the homepage.\nIn Workload Identity Pool, the associated Workload Identity Pool provider that\u0026rsquo;s configured must have an ID with the prefix sysdig-*.\nYou can choose any display name.\nThe configured pool should have a connected service account with the name prefix sysdig-*. This was was configured when the account was created. The service account should have the email sysdig-*@PROJECTID.iam.gserviceaccount.com.\nThis service account should allow access to the following principal set:\nFor webhook-datasource: principalSet://iam.googleapis.com/projects/PROJECTNUMBER/locations/global/workloadIdentityPools/sysdig-*/attribute.aws_role/arn:aws:sts::263844535661:assumed-role/us-west-2-production-secure-assume-role/77135e36ab5102091c579abfd9eab3a5\nFor agentless-scan and workload-scan with AWS Sysdig Backend: principalSet://iam.googleapis.com/sysdig-*/attribute.aws_account/\u0026lt;sysdig backend AWS account id\u0026gt;\nFor agentless-scan and workload-scan with GCP Sysdig Backend: principalSet://iam.googleapis.com/sysdig-*/attribute.sa_id/\u0026lt;sysdig backend GCP account id\u0026gt;\nThe service account should have either the iam.workloadIdentityUser role or more specifically iam.serviceAccounts.getAccessToken role, as well as iam.workloadIdentityUser role on the target project. For agentless-scan, it should have a custom role containing the host discovery and host scan related permissions.\nThe pool provider should allow access to the AWS account ID: 263844535661. This is Sysdig\u0026rsquo;s trusted identity and can be retrieved with curl --location --request GET 'https://us2.app.sysdig.com/api/cloud/v2/gcp/trustedIdentity.\nFor scanning, such as agentless-scan or workload-scan using the GCP Backend, allow access to the GCP account ID.\nTroubleshoot Agentless CSPM and Identity Ensure the service account created in the affected account contains the following roles: browser role. iam.workloadIdentityUser , cloudasset.viewer, logging.viewer, cloudfunctions.viewer and cloudbuild.builds.viewer roles. For identity management, ensure the service account has the following roles attached: iam.serviceAccountViewer, recommender.viewer, iam.roleViewer, container.clusterViewer and compute.viewer roles. Ensure the service account has a key created and it is enabled. Troubleshoot Agentless CDR Ingestion resources: Ensure that all the resources are correctly deployed in the target project: A Pub/Sub topic prefixed with ingestion_topic. A Log Router (also called sink) sending logs to that topic. Organizational setups will use an aggregate sink. A push subscription created on that topic, prefixed with ingestion_topic. The IAM Logging Service Account service-\u0026lt;PROJECT_ID\u0026gt;@gcp-sa-logging.iam.gserviceaccount.com needs the Pub/Sub Publisher role to publish the ingestion logs on the topic. To find the permissions: Open the topic in Google Cloud. Disable Show inherited roles in table. Ensure the Pub/Sub Publisher role is assigned to the IAM Logging Service Account. Ensure you enable the Cloud Pub/Sub API in the management project.\nEnsure the push subscription has the correct push endpoint configuration.\nEnsure you provision the Pub/Sub Service Account for the subscription include the roles/pubsub.serviceAgent role.\nWhen you enable the Pub/Sub API, you provision the Pub/Sub Service Account with the Cloud Pub/Sub Service Agent role: service-*@gcp-sa-pubsub.iam.gserviceaccount.com. To verify it:\nRun the following gcloud command, replacing \u0026lt;PROJECT_ID\u0026gt; with your management project ID: gcloud projects get-iam-policy \u0026lt;PROJECT_ID\u0026gt; --flatten=\u0026#34;bindings[].members\u0026#34; --format=\u0026#39;table(bindings.role, bindings.members)\u0026#39; | grep @gcp-sa-pubsub.iam.gserviceaccount.com It should return this line: roles/pubsub.serviceAgent serviceAccount:service-\u0026lt;PROJECT_ID_NUMBER\u0026gt;@gcp-sa-pubsub.iam.gserviceaccount.com If no line is returned: Disable and enable the Cloud Pub/Sub API in your management project and check again. If it\u0026rsquo;s still not working, from your GCP console: Open the Subscriptions page on the Pub/Sub service Select ingestion_topic_push_subscription If the service agent doesn\u0026rsquo;t have the right role, you\u0026rsquo;ll be prompted to assign it through a message. Grant it. Ensure the Sysdig Log ingestion Service Account has been provisioned with the correct roles.\nThe Sysdig Log ingestion Service Account can be identified by its email starting with sysdig-ingestion-. It needs to have the roles/iam.workloadIdentityUser role assigned to it. To verify this through the gcloud CLI tool:\nLocate the Service Account with the following command: gcloud iam service-accounts list --filter=\u0026#34;email:sysdig-ingestion*\u0026#34; --format=\u0026#34;table(email)\u0026#34; If the Service Account has been correctly deployed you will be able to copy its email. With that you can then execute the following command (replacing \u0026lt;SA_EMAIL\u0026gt; with the email you just obtained): gcloud iam service-accounts get-iam-policy \u0026lt;SA_EMAIL\u0026gt; --format=\u0026#34;table(bindings.role) | grep roles/iam.workloadIdentityUser\u0026#34; If no line is returned:\nFrom the GCP console disable and enable the subscription authentication: Open Pub/Sub Subscriptions page Edit the ingestion_topic_push_subscription subscription Disable the authentication and hit \u0026ldquo;Update\u0026rdquo; Enable the authentication, selecting the sysdig-ingestion-* Service Account and setting the audience to sysdig_secure If the previous solution was not successful, remove the current setup with terraform destroy and start from a clean install. Troubleshoot Agentless Vulnerability Scanning To discover compute Virtual Private Cloud (VPC)/Instance/Volume resources, ensure the service account created in the affected account has the host discovery permissions attached. To discover compute zone operations and disks resource, ensure the service account created in the affected account has the host scan permissions attached. If certain resources (such as compute instances / volumes) are not being scanned, ensure those resources don\u0026rsquo;t have sysdig-secure-scan/sysdig-secure-data-volumes-scan tags set to false. Offboard GCP Projects, Folders, and Organizational Domain Using TerraformProblem: Terraform Fails to Destroy Organization Deployment with Enabled Security FeaturesTerraform fails to destroy an organization deployment when Host Scanning, Workload Scanning, or CDR is enabled, likely due to dependencies on active security configurations.\nSolutionTo resolve this, first manually offboard GCP. If the problem still persists, run the following terraform destroy command:\nterraform destroy -target module.onboarding.sysdig_secure_organization.google_organization Check Terraform Provider and Module VersionEnsure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; GCP. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/google//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;2.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/google//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;2.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } ","url":"https://docs.sysdig.com/en/sysdig-secure/gcp-troubleshoot/"},{"id":364,"title":"Kernel Header","content":"About Kernel Headers and the Kernel ModuleThe Sysdig agent requires a kernel module in order to install successfully on a host. This can be obtained in three ways:\nAgent compiles the module using kernel headers.\nIf the hosts in your environment already have kernel header files pre-installed, no special action is needed. Or you can install the kernel headers manually; see below.\nAgent auto-downloads precompiled modules from Sysdig\u0026rsquo;s AWS storage location.\nIf the headers are not already installed but the agent is able to auto-download, no special action is needed. If there is no internet connectivity, you can use method 3 (download from an internal URL).\nAgent downloads precompiled modules from an internal URL.\nUse the environment variable SYSDIG_PROBE_URL. See also Understanding the Agent Config Files. Contact Sysdig support for assistance.\nAgent Installation on SELinux-Enabled Linux DistributionsOn Fedora 35 or similar SELinux-enabled distributions with default restrictive policies, the agent init container, agent-kmodule, will not install the downloaded kernel module raising an error similar to the following:\ninsmod: ERROR: could not insert module /root/.sysdig/sysdigcloud-probe-12.3.1-x86_64-5.16.11-200.fc35.x86_64-67098c7fdcc97105d4b9fd0bb2341888.ko: Permission denied\nIn such cases, we recommend that you use eBPF option while running agent-kmodule instead.\nTracePointsAll supported distribution released kernels have this support but if creating a custom kernel, it must support the following options:\nCONFIG_TRACEPOINTS CONFIG_HAVE_SYSCALL_TRACEPOINTS To Install Kernel HeadersIn some cases, the host(s) in your environment may use Unix versions that do not match the provided headers, and the agent may fail to install correctly. In those cases, you must install the kernal headers manually.\nDebian-StyleFor Debian-syle distributions, run the command:\napt-get -y install linux-headers-$(uname -r) RHEL-StyleFor RHEL-style distributions, run the command:\nyum -y install kernel-devel-$(uname -r) RancherOSFor RancherOS distributions, the kernel headers are available in the form of a system service and therefore are enabled using the ros service command:\nsudo ros service enable kernel-headers-system-docker sudo ros service up -d kernel-headers-system-docker NOTE: Some cloud hosting service providers supply pre-configured Linux instances with customized kernels. You may need to contact your provider\u0026rsquo;s support desk for instructions on obtaining appropriate header files, or for installing the distribution\u0026rsquo;s default kernel.\nTo Correct Kernel Header Errors in AWS AMIDuring an agent installation in an Amazon machine image (AMI) you may encounter the following errors while the installer is trying to compile the Sysdig kernel module:\nErrors\n\u0026ldquo;Unable to find kernel development files for the current kernel version\u0026rdquo; or\n\u0026ldquo;FATAL: Module sysdigcloud-probe not found\u0026rdquo;\nThis indicates your machine is running a kernel in an older AMI for which the kernel headers are no longer available in the configured repositories. The issue has to do with Amazon purging packages in the yum repository when new Amazon Linux machine images are released.\nThe solution is either to update your kernel to a version for which header files are readily available (recommended), or perform a one-time installation of the kernel headers for your older AMI.\nOption 1: Upgrade Your Host\u0026rsquo;s KernelFirst install a new kernel and reboot your instance:\nsudo yum -y install kernel sudo reboot After rebooting, check to see if the host is reporting metrics to your Sysdig account. If not, you may need to issue three more commands to install the required header files:\nsudo yum -y install kernel-devel-$(uname -r) sudo /usr/lib/dkms/dkms_autoinstaller start sudo service dragent restart Option 2: Install Older Kernel HeadersAlthough it is recommended to upgrade to the latest kernel for security and performance reasons, you can alternatively install the older headers for your AMI.\nFind the the AMI version string and install the appropriate headers with the commands:\nreleasever=$(cat /etc/os-release | grep \u0026#39;VERSION_ID\u0026#39; | grep -Eo \u0026#34;[0-9]{4}\\.[0-9]{2}\u0026#34;) sudo yum -y --releasever=${releasever} install kernel-devel-$(uname -r) Issue the remaining commands to allow the Sysdig Agent to start successfully:\nsudo /usr/lib/dkms/dkms_autoinstaller start sudo service dragent restart Reference: Find Your AWS Instance Image VersionThe file /etc/image-id shows information about the original machine image with which your instance was set up:\n[ec2-user ~]$ cat /etc/image-id image_name=\u0026#34;amzn-ami-hvm\u0026#34; image_version=\u0026#34;2017.03\u0026#34; image_arch=\u0026#34;x86_64\u0026#34; image_file=\u0026#34;amzn-ami-hvm-2017.03.0.20170401-x86_64.ext4.gpt\u0026#34; image_stamp=\u0026#34;26a3-ed31\u0026#34; image_date=\u0026#34;20170402053945\u0026#34; recipe_name=\u0026#34;amzn ami\u0026#34; recipe_id=\u0026#34;47cfa924-413c-d460-f4f2-2af7-feb6-9e37-7c9f1d2b\u0026#34; This file will not change as you install updates from the yum repository.\nThe file /etc/system-release will tell what version of the AWS image is currently installed:\n[ec2-user ~]$ cat /etc/system-release Amazon Linux AMI release 2017.03 ","url":"https://docs.sysdig.com/en/sysdig-secure/kernel-header-troubleshooting/"},{"id":365,"title":"Vulnerability Host Scanner (Containers)","content":"Prerequisites Retrieve your access key to use for SYSDIG_ACCESS_KEY=\u0026lt;your-access-key\u0026gt; Check your Sysdig Secure endpoint by region to use for SYSDIG_API_URL=https://\u0026lt;sysdig-url\u0026gt; See Host Scanner installation requirements for remaining requirements. InstallationRun the following Docker command to deploy the Sysdig Host Scanning container:\ndocker run --detach -e HOST_FS_MOUNT_PATH=/host -e SYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; -e SYSDIG_API_URL=\u0026lt;sysdig-secure-endpoint\u0026gt; -e SCAN_ON_START=true -v /:/host:ro -v /var/run:/host/var/run:ro --uts=host --net=host quay.io/sysdig/vuln-host-scanner:$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt) This command downloads and starts the Sysdig Host Scanning container.\nReplace with your agent access key, and with the URL for your Sysdig Secure endpoint by region.\nOnce the container is running, the scanner will begin scanning your host for vulnerabilities and providing security recommendations. You can view the results in the Sysdig Secure UI within 12 hours of installation as scans are refreshed every 12 hours.\nNext StepsUse the Vuln Host Scanner in the Sysdig Secure UI\n","url":"https://docs.sysdig.com/en/classic-container-vulnerabity-scanner/"},{"id":366,"title":"Vulnerability Host Scanner (Packages)","content":"Prerequisites Retrieve your access key to use for SYSDIG_ACCESS_KEY=\u0026lt;your-access-key\u0026gt; Check your Sysdig Secure endpoint by region to use for SYSDIG_API_URL=https://\u0026lt;sysdig-url\u0026gt; See Host Scanner installation requirements for remaining requirements. If you are using an RPM-based operating system, ensure RPM and YUM are installed. InstallationRPM-Based Operating System Configure the RPM repository and Sysdig GPG key:\nsudo rpm --import https://download.sysdig.com/DRAIOS-GPG-KEY.public sudo curl -o /etc/yum.repos.d/draios.repo https://download.sysdig.com/stable/rpm/draios.repo Install the vuln-host-scanner package:\nsudo yum install vuln-host-scanner --refresh -y Note: On RHEL/CentOS platforms, use sudo yum clean expire-cache \u0026amp;\u0026amp; sudo yum install vuln-host-scanner -y\nCreate the vuln-host-scanner configuration file:\ncat \u0026lt;\u0026lt; EOF | sudo tee /opt/draios/etc/vuln-host-scanner/env SYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; SYSDIG_API_URL=\u0026lt;api-url\u0026gt; # optional SCAN_ON_START=true EOF Enable and start the vuln-host-scanner.service service:\nsudo systemctl enable --now vuln-host-scanner.service Check logs to see if everything is working as it should:\nsudo journalctl -fu vuln-host-scanner.service Scan for ContainersYou can extend the host scanner to scan for containers such as Docker and Podman.\nSee Container Scanning for details.\nFor Other Operating Systems and Raw Binary Download the latest version of sysdig-host-scanner with:\nIntel Processor (AMD64)\ncurl -LO \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-host-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)/linux/amd64/sysdig-host-scanner\u0026#34; ARM Processor (ARM64)\ncurl -LO \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-host-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)/linux/arm64/sysdig-host-scanner\u0026#34; Optionally, you can check the sha256sum as follows:\nIntel Processor (AMD64)\nsha256sum -c \u0026lt;(curl -sL \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-host-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)/linux/amd64/sysdig-host-scanner.sha256\u0026#34;) ARM Processor (ARM64)\nsha256sum -c \u0026lt;(curl -sL \u0026#34;https://download.sysdig.com/scanning/bin/sysdig-host-scanner/$(curl -L -s https://download.sysdig.com/scanning/sysdig-host-scanner/latest_version.txt)/linux/arm64/sysdig-host-scanner.sha256\u0026#34;) Set the executable flag on the file:\nchmod +x ./sysdig-host-scanner You only need to download and set the executable once.\nYou can scan the host by running the sysdig-host-scanner command:\nSYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; SYSDIG_API_URL=\u0026lt;api-url\u0026gt; ./sysdig-host-scanner Optionally, create an environment file to store the configuration and a systemd unit file to run the binary as a service:\nsudo mv ./sysdig-host-scanner /usr/local/bin/vuln-host-scanner sudo restorecon -Rv /usr/local/bin/vuln-host-scanner sudo mkdir -p /opt/draios/etc/vuln-host-scanner/ cat \u0026lt;\u0026lt; EOF | sudo tee /opt/draios/etc/vuln-host-scanner/env SYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; SYSDIG_API_URL=\u0026lt;api-url\u0026gt; # optional SCAN_ON_START=true EOF cat \u0026lt;\u0026lt; EOF | sudo tee /etc/systemd/system/vuln-host-scanner.service [Unit] Description=Sysdig Vuln Host Scanner component StartLimitIntervalSec=500 StartLimitBurst=5 [Service] EnvironmentFile=/opt/draios/etc/vuln-host-scanner/env ExecStart=/usr/local/bin/vuln-host-scanner Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable --now vuln-host-scanner.service Option: Scan for ContainersYou can extend the host scanner to scan for containers such as Docker and Podman.\nSee Container Scanning for details.\nAdditional ConfigurationsYou can include additional configuration options in the configuration file.\nThese options are added to /opt/draios/etc/vuln-host-scanner/env:\n#required SYSDIG_ACCESS_KEY=\u0026lt;access-key\u0026gt; SYSDIG_API_URL=\u0026lt;api-url\u0026gt; # optional HOST_DIRS_TO_SCAN=\u0026lt;comma-separated list of directories of the host filesystem that will be analyzed\u0026gt; (Using this will override the default directories) (Default directories - /etc,/var/lib/dpkg,/usr/local,/usr/lib/sysimage/rpm,/var/lib/rpm,/lib/apk/db) ADDITIONAL_HOST_DIRS_TO_SCAN=\u0026lt;comma-separated list of directories of the host filesystem that will be analyzed in addition to the default ones\u0026gt; HOST_DIRS_TO_SKIP=\u0026lt;comma-separated list of directories of the host filesystem that will be skipped\u0026gt; SCAN_ON_START=\u0026lt;true/valse on whether to perform the first analysis immediately after teh service is started rathe than waiting for the schedule\u0026gt; (Default is false) HTTP_PROXY=\u0026lt;address of proxy\u0026gt; HTTPS_PROXY=\u0026lt;address of proxy\u0026gt; NO_PROXY=\u0026lt;comma-separated list of addresses to exclude from the defined proxy\u0026gt; Kubernetes MetadataIf your node is part of an existing Kubernetes installation and you’re not using the official Helm chart, you’ll be in charge of setting node name and cluster name via:\nK8S_CLUSTER_NAME K8S_NODE_NAME Next StepsInstall the Agent using a package\nUse the Host Scanner in the Sysdig Secure UI\n","url":"https://docs.sysdig.com/en/sysdig-secure/vulnerability-host-scanner-package/"},{"id":367,"title":"Vulnerability Host Scanner Requirements","content":"Linux Distributions Alibaba Cloud Linux (Aliyun Linux) AlmaLinux Amazon Linux 2022/2023 Amazon Linux 2 CentOS 7 CentOS 8-stream CentOS 9-stream Debian 10 Debian 11 Debian 12 Flatcar Container Linux Google Container-Optimized OS (COS), build 89+ Oracle Linux (7/8/9) Open SuSE RedHat Red Hat Enterprise Linux Core OS RedHat Red Hat Enterprise Linux 7 RedHat Red Hat Enterprise Linux 8 RedHat Red Hat Enterprise Linux 9 Rocky Linux 7 Rocky Linux 8 Ubuntu 20.04 Ubuntu 22.04 Ubuntu Kinetic (v22.10) Ubuntu Lunar (v23.04) Alpine Linux 3.20 and above CPU Architectures X86 ARM Next StepsInstall on a Kubernetes cluster\nInstall on a Host\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-req-vm-scanner/"},{"id":368,"title":"Windows Agent Release Notes","content":" Starting from March 31, 2025, Windows Agent release notes are now available on Host Shield for Windows Release Notes page.\n1.3.2 January 30, 2025Supported sysdig-deploy version: 1.75.1\nDefect FixesFixed an issue to improve the agent stability and connection with the collector to prevent unexpected restarts.\n","url":"https://docs.sysdig.com/en/release-notes/windows-agent-release-notes/"},{"id":369,"title":"(Legacy) Configuring Sysdig Agent","content":" This feature is not supported with Promscrape V2. For information on different versions of Promscrape and migrating to the latest version, see Migrating from Promscrape V1 to V2.\nAs is typical for the agent, the default configuration for the feature is specified in dragent.default.yaml, and you can override the defaults by configuring parameters in the dragent.yaml. For each parameter, you do not set in dragent.yaml, the defaults in dragent.default.yaml will remain in effect.\nMain Configuration Parameters Parameter\nDefault\nDescription\nprometheus\nSee below\nTurns Prometheus scraping on and off.\nprocess_filter\nSee below\nSpecifies which processes may be eligible for scraping. See Process Filter.\nuse_promscrape\nSee below.\nDetermines whether to use promscrape for scraping Prometheus metrics.\npromscrapePromscrape is a lightweight Prometheus server that is embedded with the Sysdig agent. The use_promscrape parameter controls whether to use it to scrape Prometheus endpoints.\nParameters\nDefault\nDescription\nuse_promscrape\ntrue\nPromscrape has two versions: Promscrape V1 and Promscrape V2. With V1, Sysdig agent discovers scrape targets through the process_filter rules. With V2, promscrape itself discovers targets by using the standard Prometheus configuration, allowing the use of relabel_configs to find or modify targets.\nprometheusThe prometheus section defines the behavior related to Prometheus metrics collection and analysis. It allows for turning the feature on, set a limit from the agent side on the number of metrics to be scraped, and determines whether to report histogram metrics and log failed scrape attempts.\nParameter\nDefault\nDescription\nenabled\nfalse\nTurns Prometheus scraping on and off.\ninterval\n10\nHow often (in seconds) the agent will scrape a port for Prometheus metrics\nprom_service_discovery\ntrue\nEnables native Prometheus service discovery. If disabled, promscrape.v1 is used to scrape the targets. See Enable Prometheus Native Service Discovery.\nOn agent versions prior to 11.2, the default is false.\nmax_metrics\n1000\nThe maximum number of total Prometheus metrics that will be scraped across all targets. This value of 1000 is the maximum per-agent, and is a separate limit from other Custom Metrics. For example, StatsD, JMX, and App Checks.\nhistograms\nfalse\nDetermines whether to report histogram metrics. By default, it does not.\ntimeout\n1\nUsed to configure the amount of time the agent will wait while scraping a Prometheus endpoint before timing out. The default value is 1 second.\nAs of agent v10.0, this parameter is only used when promscrape is disabled. Since promscrape is now default, timeout can be considered deprecated, however it is still used when you explicitly disable promscrape.\nProcess FilterThe process_filter section specifies which of the processes known by an agent may be eligible for scraping.\nNote that once you specify a process_filter in your dragent.yaml, this replaces the entire Prometheus process_filter section (i.e. all the rules) shown in the dragent.default.yaml.\nThe Process Filter is specified in a series of include and exclude rules that are evaluated top-to-bottom for each process known by an Agent. If a process matches an include rule, scraping will be attempted via a /metrics endpoint on each listening TCP port for the process, unless a conf section also appears within the rule to further restrict how the process will be scraped. See conf for more information.\nMultiple patterns can be specified in a single rule, in which case all patterns must match for the rule to be a match (AND logic).\nWithin a pattern value, simple \u0026ldquo;glob\u0026rdquo; wildcarding may be used, where * matches any number of characters (including none) and ? matches any single character. Note that due to YAML syntax, when using wildcards, be sure to enclose the value in quotes (\u0026quot;*\u0026quot;).\nThe table below describes the supported patterns in Process Filter rules. To provide realistic examples, we\u0026rsquo;ll use a simple sample Prometheus exporter (source code here) which can be deployed as a container using the Docker command line below. To help illustrate some of the configuration options, this sample exporter presents Prometheus metrics on /prometheus instead of the more common /metrics endpoint, which will be shown in the example configurations further below.\n# docker run -d -p 8080:8080 \\ --label class=\u0026#34;exporter\u0026#34; \\ --name my-java-app \\ luca3m/prometheus-java-app # ps auxww | grep app.jar root 11502 95.9 9.2 3745724 753632 ? Ssl 15:52 1:42 java -jar /app.jar --management.security.enabled=false # curl http://localhost:8080/prometheus ... random_bucket{le=\u0026#34;0.005\u0026#34;,} 6.0 random_bucket{le=\u0026#34;0.01\u0026#34;,} 17.0 random_bucket{le=\u0026#34;0.025\u0026#34;,} 51.0 ... Pattern name\nDescription\nExample\ncontainer.image\nMatches if the process is running inside a container running the specified image\n- include:\ncontainer.image: luca3m/prometheus-java-app\ncontainer.name\nMatches if the process is running inside a container with the specified name\n- include:\ncontainer.name: my-java-app\ncontainer.label.*\nMatches if the process is running in a container that has a Label matching the given value\n- include:\ncontainer.label.class: exporter\nkubernetes.\u0026lt;object\u0026gt;.annotation.* kubernetes.\u0026lt;object\u0026gt;.label.*\nMatches if the process is attached to a Kubernetes object (Pod, Namespace, etc.) that is marked with the Annotation/Label matching the given value.\nNote: This pattern does not apply to the Docker-only command-line shown above, but would instead apply if the exporter were installed as a Kubernetes Deployment using this example YAML.\nNote: See Kubernetes Objects, below, for information on the full set of supported Annotations and Labels.\n- include:\nkubernetes.pod.annotation.prometheus.io/scrape: true\nprocess.name\nMatches the name of the running process\n- include:\nprocess.name: java\nprocess.cmdline\nMatches a command line argument\n- include:\nprocess.cmdline: \"*app.jar*\"\nport\nMatches if the process is listening on one or more TCP ports.\nThe pattern for a single rule can specify a single port as shown in this example, or a single range (e.g.8079-8081), but does not support comma-separated lists of ports/ranges.\nNote: This parameter is only used to confirm if a process is eligible for scraping based on the ports on which it is listening. For example, if a process is listening on one port for application traffic and has a second port open for exporting Prometheus metrics, it would be possible to specify the application port here (but not the exporting port), and the exporting port in the conf section (but not the application port), and the process would be matched as eligible and the exporting port would be scraped.\n- include:\nport: 8080\nappcheck.match\nMatches if an Application Check with the specific name or pattern is scheduled to run for the process.\n- exclude:\nappcheck.match: \"*\"\nInstead of the **`include`** examples shown above that would have each matched our process, due to the previously-described ability to combine multiple patterns in a single rule, the following very strict configuration would also have matched: - include: container.image: luca3m/prometheus-java-app container.name: my-java-app container.label.class: exporter process.name: java process.cmdline: \u0026#34;*app.jar*\u0026#34; port: 8080 confEach include rule in the port_filter may include a conf portion that further describes how scraping will be attempted on the eligible process. If a conf portion is not included, scraping will be attempted at a /metrics endpoint on all listening ports of the matching process. The possible settings:\nParameter name\nDescription\nExample\nport\nEither a static number for a single TCP port to be scraped, or a container/Kubernetes Label name or Kubernetes Annotation specified in curly braces. If the process is running in a container that is marked with this Label or is attached to a Kubernetes object (Pod, Namespace, etc.) that is marked with this Annotation/Label, scraping will be attempted only on the port specified as the value of the Label/Annotation.\nNote: The Label/Annotation to match against will not include the text shown in red.\nNote: See Kubernetes Objectsfor information on the full set of supported Annotations and Labels.\nNote: If running the exporter inside a container, this should specify the port number that the exporter process in the container is listening on, not the port that the container exposes to the host.\nport: 8080\n- or -\nport: \"{container.label.io.prometheus.port}\" - or -\nport: \"{kubernetes.pod.annotation.prometheus.io/port}\" port_filter\nA set of include and exclude rules that define the ultimate set of listening TCP ports for an eligible process on which scraping may be attempted. Note that the syntax is different from the port pattern option from within the higher-level include rule in the process_filter. Here a given rule can include single ports, comma-separated lists of ports (enclosed in square brackets), or contiguous port ranges (without brackets).\nport_filter:\n- include: 8080 - exclude: [9092,9200,9300] - include: 9090-9100\npath\nEither the static specification of an endpoint to be scraped, or a container/Kubernetes Label name or Kubernetes Annotation specified in curly braces. If the process is running in a container that is marked with this Label or is attached to a Kubernetes object (Pod, Namespace, etc.) that is marked with this Annotation/Label, scraping will be attempted via the endpoint specified as the value of the Label/Annotation.\nIf path is not specified, or specified but the Agent does not find the Label/Annotation attached to the process, the common Prometheus exporter default of /metrics will be used.\nNote: A Label/Annotation to match against will not include the text shown in red.\nNote: See Kubernetes Objects for information on the full set of supported Annotations and Labels.\npath: \"/prometheus\"\n- or -\npath: \"{container.label.io.prometheus.path}\" - or -\npath: \"{kubernetes.pod.annotation.prometheus.io/path}\" host\nA hostname or IP address. The default is localhost.\nhost: 192.168.1.101 - or - host: subdomain.example.com - or - host: localhost use_https\nWhen set to true, connectivity to the exporter will only be attempted through HTTPS instead of HTTP. It is false by default.\n(Available in Agent version 0.79.0 and newer)\nuse_https: true\nssl_verify\nWhen set to true, verification will be performed for the server certificates for an HTTPS connection. It is false by default. Verification was enabled by default before 0.79.0.\n(Available in Agent version 0.79.0 and newer)\nssl_verify: true\nAuthentication IntegrationAs of agent version 0.89, Sysdig can collect Prometheus metrics from endpoints requiring authentication. Use the parameters below to enable this function.\nFor username/password authentication:\nusername\npassword\nFor authentication using a token:\nauth_token_path For certificate authentication with a certificate key:\nauth_cert_path\nauth_key_path\nToken substitution is also supported for all the authorization parameters. For instance a username can be taken from a Kubernetes annotation by specifying\nusername: \u0026quot;{kubernetes.service.annotation.prometheus.openshift.io/username}\u0026quot;\nconf Authentication ExampleBelow is an example of the dragent.yaml section showing all the Prometheus authentication configuration options, on OpenShift, Kubernetes, and etcd.\nIn this example:\nThe username/password are taken from a default annotation used by OpenShift.\nThe auth token path is commonly available in Kubernetes deployments.\nThe certificate and key used here for etcd may normally not be as easily accessible to the agent. In this case they were extracted from the host namespace, constructed into Kubernetes secrets, and then mounted into the agent container.\nprometheus: enabled: true process_filter: - include: port: 1936 conf: username: \u0026#34;{kubernetes.service.annotation.prometheus.openshift.io/username}\u0026#34; password: \u0026#34;{kubernetes.service.annotation.prometheus.openshift.io/password}\u0026#34; - include: process.name: kubelet conf: port: 10250 use_https: true auth_token_path: \u0026#34;/run/secrets/kubernetes.io/serviceaccount/token\u0026#34; - include: process.name: etcd conf: port: 2379 use_https: true auth_cert_path: \u0026#34;/run/secrets/etcd/client-cert\u0026#34; auth_key_path: \u0026#34;/run/secrets/etcd/client-key\u0026#34; Kubernetes ObjectsAs described above, there are multiple configuration options that can be set based on auto-discovered values for Kubernetes Labels and/or Annotations. The format in each case begins with \u0026quot;kubernetes.OBJECT.annotation.\u0026quot; or \u0026quot;kubernetes.OBJECT.label.\u0026quot; where OBJECT can be any of the following supported Kubernetes object types:\ndaemonSet\ndeployment\nnamespace\nnode\npod\nreplicaSet\nreplicationController\nservice\nstatefulset\nThe configuration text you add after the final dot becomes the name of the Kubernetes Label/Annotation that the Agent will look for. If the Label/Annotation is discovered attached to the process, the value of that Label/Annotation will be used for the configuration option.\nNote that there are multiple ways for a Kubernetes Label/Annotation to be attached to a particular process. One of the simplest examples of this is the Pod-based approach shown in Quick Start For Kubernetes Environments. However, as an example alternative to marking at the Pod level, you could attach Labels/Annotations at the Namespace level, in which case auto-discovered configuration options would apply to all processes running in that Namespace regardless of whether they\u0026rsquo;re in a Deployment, DaemonSet, ReplicaSet, etc.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycollect-prometheus-metrics/configuring-sysdig-agent/"},{"id":370,"title":"On-Prem Release Notes 2018","content":"Release 1472, December 13, 2018Tuned the configuration of metrics rollups to handle high-scale environmentsRelease 1402 December 3, 2018Sysdig MonitorGlobal silence alerts for scheduled downtimeAdministrators can now temporarily disable alert events to mute notifications during planned downtime or maintenance. The new feature also supports sending a downtime notification to selected channels. Access the new capability via Settings \u0026gt; Notification Channels. See Disable or Delete a Notification Channel.\nDashboard TemplatingNew dashboard templating enables users to create and configure a fixed dashboard that enables alternating between multiple scope variables. Users can assign custom names for labels and choose to set fixed or variable label selection values.\nIntegration with AWS IAM role to grant permissionsNew support for Amazon Web Services IAM roles grants permissions via IAM to applications running on Amazon.\nSee the Integrate AWS Account Using the Implicit Key (On-Prem Only)in the AWS integration documentation.\nUpdated Users and Teams Settings PagesThe Users and Teams settings pages have been updated to improve performance and now feature a streamlined full-page edit layout. See Manage Teams and Roles.\nSysdig SecureCIS Compliance ChecksThe ability to schedule CIS compliance tasks for the agent to run on your infrastructure is now available.\nThese tasks will generate metrics that are available in Sysdig Monitor and reports that are available in Sysdig Secure.\nBug FixesSeveral minor enhancements to improve performance and usability.\nRelease 1245 November 05, 2018 Please skip this release and install 1402 instead.\nEnhanced connection tracking featuresSecurity updates Backend updates to address security vulnerabilities.\nTeams functionality is now available in Sysdig Secure.\nCaching on image scanning run-time page for performance improvements.\nVarious bug fixes and improvementsRelease 1149 September 14, 2018PrerequisitesYour on-premises Sysdig installation MUST be running release v1091 before you can upgrade to this release v1149. Please upgrade to v1091 before proceeding.\nUnified Events table and migration tool (Required before upgrade)A change was introduced in how events are indexed and stored in the Sysdig platform. In prior versions, the three types of events were stored in three separate indexes based on their different sources. After migration and upgrade are complete, they will be combined in one index. Before upgrading to v1149 it is necessary to run a Unified Events migration tool.\nSysdig Agent Crash custom eventGenerates a custom event if a Sysdig agent crash is experienced.\nNode Ready alert resetEnables transition of a notification from active =\u0026gt; ok for a down node (NodeNotReady) when the node with the same scope becomes ready again (NodeReady).\nImproved Mesos/Marathon label handlingImproved handling of Mesos/Marathon labeling to ensure proper display of containers within the Sysdig UI.\nVarious bug fixes and improvementsRelease 1091 August 16, 2018Component updates and CVE patchesDelivers minor-minor upgrades and CVE patches for all 3rd party components in Replicated install. The Kubernetes install includes a major upgrade for MySQL from 5.6.34 to 8.0.11. Please see product README for upgrade guidance and details.\nStatefulSets for Kubernetes deploymentProvides StatefulSet option for select Redis and MySQL with Kubernetes. Please see product README for usage eligibility and further details.\nNew \u0026lsquo;Standard User\u0026rsquo; role and RBAC changesIntroduces new \u0026lsquo;Standard User\u0026rsquo; role for developers that includes edit access to dashboards, alerts, events but NO access to Explore. Renames \u0026lsquo;Edit user\u0026rsquo; role to \u0026lsquo;Advanced user\u0026rsquo; and \u0026lsquo;Read only\u0026rsquo; role to \u0026lsquo;View only\u0026rsquo;. See Manage Teams and Roles for details.\nTeam scoping performance improvementWhen creating or editing teams, the first 30 labels and tags are displayed with the ability to search for additional options.\nMulti-select alerts and bulk actionsNew checkboxes on the alerts page enable selection of multiple alerts for bulk actions.\nKubernetes Node Ready alertA new alert provides notification when a Kubernetes node is not ready. Default alert level is \u0026lsquo;warning\u0026rsquo; (user-configurable).\nRelease 987 July 11, 2018Solr dashboards updateModifications to default Solr dashboard\nMetrics aggregation fixFixed an issue with metrics aggregation\nRelease 963 June 26, 2018LDAP enhancements Enabling and disabling of LDAP authentication is now performed via API configuration rather than Replicated console or K8S ConfigMap. See LDAP for details.\nAn option has been added to allow chasing of referrals during LDAP authentication. See the documentation for details.\nHTTPS enforcementSysdig is now enforcing HTTPS connectivity and using secure cookies. With this change, we have disabled TLS v1.0. Users should modify any scripts and/or applications to use HTTPS and TLS v1.2 for uninterrupted operation.\nText PanelsYou can now add text panels to your dashboards to provide additional information. Text panels can be used as title headers or to provide additional context that you would like to communicate. Features limited markdown support .\nMultiple segments for a single metricYou can now add up to five different segments for a given metric in time-series and stacked area panels.\nDefault entry pointAdmins can now set a default entry point for a team to simplify the onboarding process. This determines the first page users see when they start the application (e.g., a specific dashboard, settings, etc.).\nDefault Istio dashboardsSysdig provides out of the box dashboards for monitoring Istio using Prometheus exporters.\nTest notification channelsNew test function lets you pre-test your notification channels such as email, Slack, PagerDuty, etc.\nCopy and share groupingsCopy and share unique groupings with all of your teams.\nIcon labelsNew icon labels appear on hover to clarify underlying function for users.\nAlert on rate of changeIntroducing a new \u0026lsquo;rate of change\u0026rsquo; math function for metrics. Now you can alert by the rate at which a metric changes vs. a static threshold. For example, a default alert: Rate of change of disk usage alerts you if your disk usage increases more than x% in a day.\nRelease 925 June 10, 2018Solr dashboards improvementIncreased number of segments for Solr default dashboard panels\nPublic dashboards fixFixed an issue that caused errors when loading public dashboards due to missing metrics\nRelease 917 June 7, 2018Google OAuth fixFixed an issue with Google OAuth (On-Prem) login.\nUpgrades in LDAP environmentsFixed an issue in upgrades with [LDAP Authentication Configuration for Platform v.1149 - 1511\nRelease 914 June 6, 2018Solr dashboardsAdded application dashboards for Solr metrics.\nRelease 904 May 31, 2018Performance improvementsEnhancements to improve Sysdig Monitor response time during login.\nRelease 893 May 9, 2018Daily metric rollup fixFixed an issue caused during daily metric rollup due to Cassandra-14092.\nRelease 892 May 2, 2018Various bug fixes and improvements.\nRelease 890 April 30, 2018New default ports for API/Collector containers (Replicated)New default TCP ports are exposed from Sysdig backend API/collector containers to the host level in Replicated-based installs. Read this support article for info on avoiding possible port conflicts.\n\u0026lsquo;SSO CA certificate in PEM format\u0026rsquo; optionReplicated-based installs using SSO that access their IDP via SSL/TLS and need to import a CA certificate for Sysdig to trust the connection can now do using the SSO CA certificate in PEM formatoption. This is available under the \u0026lsquo;Advanced\u0026rsquo; section of the \u0026lsquo;Settings\u0026rsquo; tab in the Admin console. Kubernetes-based installs can do the equivalent as described in this README. LDAP settings changesLDAP authentication settings are now configured via the Sysdig Platform Admin API. Environments running releases pre-890 will have their LDAP settings automatically migrated to the new API endpoints automatically when upgrading to 890.\nNew UI designOur new user interface provides a more modern framework for interacting with the product. Navigation is re-oriented from a top-of-screen menu to an icon-driven left side panel, providing more space for viewing your metrics and dashboards. Click here for a quick video introduction!.\nAlert on rate of changeIntroducing a new \u0026lsquo;rate of change\u0026rsquo; math function for metrics. Now you can alert by the rate at which a metric changes vs. a static threshold. For example, a default alert: Rate of change of disk usage alerts you if your disk usage increases more than x% in a day.\nSupport for Prometheus histogram metricsSysdig Monitor can now ingest a Prometheus histogram metric type and visualize them in a chart to show the distribution of specific metrics.\nLink to Grafana pluginDid you know you can add Sysdig as a Grafana data source? To help you get started visualizing Sysdig-collected metrics in Grafana, we\u0026rsquo;ve added a Grafana Plugin link to the help menu that takes you to the setup instructions.\nRevised alerting with Kubernetes metricsAlert configuration settings for Kubernetes metrics now limit scope and segmentation based on the metric that is selected to allow for more accurate alerting. Check out our support page for more details.\nCompare-to for timeseriesIn your time series line charts you can now compare time-shifting metrics to easily spot trends and anomalies. With compare-to for time series you can configure and observe how one or more metrics have changed since a previous time (e.g., 1 hour ago or 2 days ago).\n\u0026lsquo;Compare to\u0026rsquo; for number panelsMetric number panels now feature a configurable \u0026lsquo;Compare to\u0026rsquo; function to display the change in measurement since a previous time frame. Provides insight into the increase or decrease of metrics over time.\nNew Metrics for CPU Core UsageWe\u0026rsquo;ve added cpu.cores.used and cpu.cores.used.percent that align with the way Kubernetes exposes CPU usage. Now you can compare values using kube-state-metrics such as kubernetes.node.capacity.cpuCores, kubernetes.pod.resourceLimits.cpuCores in order to determine if resources are oversubscribed. These metrics are also key for capacity planning and chargeback calculations.\nImproved documentation for CPU metricsThe Sysdig Monitor Metrics Dictionary now features updated CPU metrics descriptions to provide more insight into each available metric.\nResizable columnsThe UI now allows columns to be resized for all tables in the application including alerts, events, teams, and users.\nSuggest ModeSuggest mode auto-selects only the relevant dashboards and metrics, hiding any inapplicable views. This is now the normal mode of operation. The turn on/off option is no longer available.\nRedesigned login screenWe\u0026rsquo;ve put a new, more modern face on the Sysdig Monitor login screen.\nRelease 858 April 12, 2018Captures and Sysdig Inspect fixUpgrades the open source sysdig version in on-prem build to resolve sysdig capture and Sysdig Inspect compatibility issue.\nCustomers running version 693 and above can upgrade directly to release 858.\nRelease 800 March 13, 2018New Explore designWe\u0026rsquo;ve redesigned Sysdig Monitor\u0026rsquo;s Explore page to give you extra screen space to view your killer dashboards and metrics. The new vertical layout helps you see more and get to what you need faster.\nGolden Signals dashboardsNew Service Golden Signal dashboards provide out-of-the-box metrics that developers need when launching and monitoring a service or app. Includes slowest transactions, latency, request volume, error rates, and most requested URLs.\nSpotlightWant a simple way to quickly see what matters most in your environment? Spotlight helps you quickly discover, detect, and optimize your infrastructure and services. A Spotlight health check shows you new integrations, infrastructure, app, and agent status, and more at-a-glance.\nExport table data as JSON/CSVYou can now download table data in JSON or CSV format for offline viewing and analysis.\nUI updatesWe\u0026rsquo;ve simplified the dashboard panel copy function and added a duplicate panel option in menu. We\u0026rsquo;ve also redesigned the dropdowns in the top-right header including making it easier to quickly see and select your teams.\nAdditional itemsVarious bug fixes and improvements including:\nPerformance and stability fixes for metrics\nFix for issue with ElasticSearch migration\nConfigurable program retention by customer (default limit 12)\nFix for migrations using BE mapper – now use dedicated customer mapper.\nRelease 760 February 23, 2018Explore grouping and scoping enhancementsWe\u0026rsquo;ve massively simplified grouping and scopes. Our new approach gives you better, more precise data - with less chance of invalid groupings (e.g. Kubernetes deployment \u0026gt; hostname). Have questions? Watch this video, read this article, or contact Customer Success and we\u0026rsquo;ll analyze your account for you!\nkube-state-metricsSysdig Monitor now collects kube-state-metrics for monitoring and alerting on the state of Kubernetes objects. New dashboards provide visibility of metrics for nodes, namespaces, services, daemonSets, jobs, replicaSets and pods. Requires update to the Sysdig agent version 0.77.0 or higher.\nPublic URL dashboardsEver want to share a killer dashboard with a colleague who is not a Sysdig Monitor user? Now you can! Just pick, click, and send your URL.\nTeam Manager roleWe\u0026rsquo;ve introduced a new \u0026lsquo;Team Manager\u0026rsquo; role that provides the privilege to add, delete, and modify team users as well as grant read or edit access.\nProxy support for outgoing HTTP/HTTPS connectionsYou can now configure outgoing HTTP/HTTPS connections to be made via proxy. Supports outgoing web connections to support notification channels, PagerDuty, Slack, Amazon SNS, VictorOps, OpsGenie, WebHooks, AWS CloudWatch data gathering. Read more here.\nSuggest mode enabled by defaultLast year we introduced suggest mode – available in \u0026lsquo;Settings\u0026gt;Sysdig Labs\u0026rsquo; – as a way to boost your efficiency by showing only the views, metrics, and grouping presets applicable to your environment. This option has proven so popular that it is now enabled by default.\nCustom headers for webhooksWhen using webhooks, typically used to pass authentication credentials, you can now add custom headers to pass along additional details with an outgoing request.\nRename of Admin team to Monitor OperationsAs part of the broader Sysdig Platform initiative, \u0026lsquo;Admin Team\u0026rsquo; within Sysdig Monitor is now renamed to \u0026lsquo;Monitor Operations.\u0026rsquo; The Monitor Operations team will continue to behave the same as the previous Admin team:\nThe Monitor Operations team cannot be deleted.\nMonitor Operations users have full visibility to all resources.\nTo change settings for any team, admins must switch to the Monitor Operations team.\nSupport for JMX metrics from Java 9Sysdig Monitor now supports JMX monitoring for Java 9 applications. To enable collection of Java 9 metrics, update to the latest Sysdig Agent. For more details, review the Sysdig Agent changelogs.\nIntroducing read-only usersUsers can have different roles for each of the teams they belong to, either \u0026lsquo;Read user\u0026rsquo; or \u0026lsquo;Edit user\u0026rsquo;. A read user can only use the app in read-only mode, with no permission to create/edit/delete dashboards, alerts, etc while the edit user is allowed to make those changes. This is a per team role defined by Admin users.\nMemcached default dashboardA new default dashboard has been added to the Explore page where you can see the most important Memcached performance monitoring metrics: connections, commands, get hits/misses, evictions, etc.\nPython client changes: Team/User configsChanges to support Role Based Access Control (RBAC) modify how \u0026lsquo;Teams\u0026rsquo; and \u0026lsquo;User\u0026rsquo; configurations are stored and modified via the API. This affects the functionality of the Python client. If you currently have scripts that use these methods, click here for details on how to upgrade your Python client and make the necessary changes to your scripts.\nRelease 722 January 8, 2018CPU usage host-level segmentationCPU usage at host level can now be segmented by CPU core.\nAWS and Cloudwatch improvementsEnabled more reliable AWS metadata by separating AWS metadata from Cloudwatch metrics\nAdditional itemsVarious bug fixes and improvements.\nIt is recommended to follow upgrade best practices\nKeep upgrades current Test upgrades in a non-mission-critical or staging environment before rolling into production. ","url":"https://docs.sysdig.com/en/release-notes/sysdig-on-premises-release-notes/2018-archive/"},{"id":371,"title":"Add Backend Files (On-Premises Only)","content":"After generating the files, add them to the Support ticket you created. Review the file upload tips on that page.\nFor a Kubernetes InstallationIf you are running the Sysdig Platform on-premises Kubernetes version, generate the application support bundle via a script that is provided in the Sysdig GitHub repository\nSupply the script with the namespace, and optionally the context where Sysdig is deployed, and it will generate a tarball with backend logs and configuration information.\n./scripts/get_support_bundle.sh -n sysdigcloud The version of the Sysdig Application is visible in the application\u0026rsquo;s container image files:\nkubectl -n sysdigcloud get deployment sysdigcloud-api -ojsonpath=\u0026#39;{.spec.template.spec.containers[0].image}\u0026#39; | awk \u0026#39;match($0, /[0-9]\\.[0-9]\\.[0-9]/) {print substr($0, RSTART, RLENGTH)}\u0026#39; ","url":"https://docs.sysdig.com/en/docs/support/submit-a-support-ticket/add-backend-files-on-premises-only/"},{"id":372,"title":"Admission Controller","content":" Using the Admission Controller functionality can impact production workloads. Misconfigured or overly strict policies may block deployments or modify workload behavior. Sysdig strongly recommends testing all Admission Controller policies in non-production or lower-tier environments before applying them broadly across your infrastructure.\nPrerequisites Cluster Shield version 1.13.0 or higher. To enable Admission Controller in your Secure SaaS account, contact Sysdig Support.\nOnce enabled, follow the steps on Installation and Configuration.\nFeaturesInstalling the Admission Controller enables multiple layers of security checks across runtime security, audit logging, and posture management with the following features:\nDeploy-Time Image Scanning: Admission Controller integrates with scan policies to evaluate images at deployment time, blocking workloads that use images with CVEs, misconfigurations, or policy violations. Workloads are rejected before scheduling to a node, eliminating unnecessary risk. Kubernetes Audit Logging: This feature enables Audit Detections to record API-level admission decisions, including who attempted deployments, when, and why actions were allowed or blocked. This provides a complete audit trail for security investigations and policy tuning. See also: Kubernetes Audit Logging. Kubernetes Posture Enforcement: This feature applies posture policies to define best practices, such as preventing privileged containers, enforcing non-root users, or applying resource limits. The Admission Controller evaluates these policies during admission and blocks non-compliant deployments. You can assign different policies per Zone to account for environment-specific constraints (for example, staging versus production). Key Capabilities HTTP Webhook Architecture\nAdmission Controller uses HTTP webhooks instead of gRPC, improving integration, compatibility, and maintainability across Kubernetes environments. Flexible Configuration and Helm Chart Enhancements\nGranular controls to enable or disable enforcement modules based on use case. For example, enabling vulnerability validation while disabling posture management. Configurable backend connection timeout settings for better reliability and control. Enhanced defaulting and override options for flexible and resilient deployments. Unified Enforcement Path\nAdmission Controller logic is unified with the Vulnerability Management Admission Validation Engine. This simplifies deployment architecture, reduces operational overhead, and prepares the platform for further innovation. Benefits Improved Security Posture at Deploy Time\nWith Admission Controller, you can prevent insecure or vulnerable workloads from being deployed by enforcing security and compliance policies earlier in the deployment pipeline.\nUnified Security Foundation\nThis release establishes a foundation for expanding and unifying cloud-native security enforcement across Kubernetes and other environments.\nHow it WorksThe Admission Controller uses standard Kubernetes ValidatingAdmissionWebhook architecture for Dynamic Admission Controller.\nAPI server sends an AdmissionReview request to registered validating webhooks that match the object operation.\nWebhooks run in parallel and must either allow or reject the resource, but cannot modify.\nThe resources are evaluated against the Sysdig SaaS backend to determine if they comply with applied Vulnerability or Posture Policies.\nThe server waits up to timeout duration (default 10s, max 30s). On timeout or error, failure_policy (Fail/Ignore) determines whether to reject or allow the resource.\nAdmission Controller ResultsYou can view Admission Controller events in two places within the Sysdig Secure Platform:\nEvents Feed Command Line Interface For examples, see Vulnerability Policies or Posture Policies.\n","url":"https://docs.sysdig.com/en/sysdig-secure/admission-controller/"},{"id":373,"title":"Configure Agent Modes","content":"You can choose one of the following modes to do so. Review the features available in different agent modes before determining the mode you want to opt for.\nFeatures Monitor Mode Secure Mode Secure Light Mode Monitor withSecure License Troubleshooting Mode Runtime Policy X\nX\nX\nActivity Audit X\nX\nX\nCaptures\nMonitor\nSecure X\nX\nX\nX\nX\nNetwork Security Policy X\nX\nX\nPrometheus X\nX\nX\nApp Checks X\nX\nX\nJMX X\nX\nX\nX\nStatsD X\nX\nX\nLive Logs\nMonitor\nSecure The Live Logs feature is not accessible for Secure-only users at the moment. This functionality is available in the Sysdig Platform as a part of the Sysdig Secure offering. X\nX\nX\nX\nX\nAdditional Metrics X\nEnable Agent ModesIf you have a Platform license (Sysdig Monitor and Sysdig Secure), no configuration is required. You get all the features by default. If you are opting a subset of features, determine the agent mode corresponding to your requirement.\nTo enable the mode you have selected, add the corresponding configuration to the values.yaml or dragent.yaml file, and restart the agent. See Configure the Agent for detailed instructions.\nThe following sections provide configuration snippets corresponding to each agent mode.\nMonitorThe Monitor mode offers an extensive collection of metrics. We recommend this mode to monitor enterprise environments.\nmonitor is the default mode if you are running the Enterprise tier.\ndragent.yamlcommandlines_capture: enabled: false drift_control: enabled: false drift_killer: enabled: false falcobaseline: enabled: false feature: mode: monitor memdump: enabled: false network_topology: enabled: false secure_audit_streams: enabled: false security: enabled: false k8s_audit_server_enabled: false Helmagent: monitor: enabled: true secure: enabled: false Monitor LightMonitor Light caters to the users that run agents in a resource-restrictive environment, or to those who are interested only in a limited set of metrics.\nThis mode provides CPU, Memory, File, File system, and Network metrics. For more information, see Metrics Available in Monitor Light.\ndragent.yamlapp_checks_enabled: false drift_control: enabled: false drift_killer: enabled: false falcobaseline: enabled: false feature: mode: monitor_light jmx: enabled: false memdump: enabled: false network_topology: enabled: false prometheus: enabled: false statsd: enabled: false Helmagent: monitor: enabled: true secure: enabled: false sysdig: settings: feature: mode: monitor_light SecureThe secure mode supports only Sysdig Secure features.\nSysdig agent collects no metrics in the secure mode, which, in turn, minimizes network consumption and storage requirement in the Sysdig backend. Lower resource usage can help reduce costs and improve performance.\nIn the Secure mode, the Monitor UI shows no data because no metrics are sent to the collector.\nThis feature requires agent v10.5.0 or above.\ndragent.yamlapp_checks_enabled: false feature: mode: secure jmx: enabled: false prometheus: enabled: false statsd: enabled: false Helmagent: monitor: enabled: false secure: enabled: true sysdig: settings: feature: mode: secure Secure LightThe secure light mode supports only the following Sysdig Secure features:\nRuntime Policies Activity Audit Captures Sysdig agent running in secure_light mode consumes fewer resources than that of running in the secure mode.\nThis feature requires agent v12.10.0 or above.\nNote: Do not enable Monitor features in Secure Light. If you do, you might encounter configuration errors.\ndragent.yamlapp_checks_enabled: false feature: mode: secure_light jmx: enabled: false memdump: enabled: false network_topology: enabled: false prometheus: enabled: false statsd: enabled: false Note: falcobaseline.enabled should be set to false in agents v12.18.0 and below.\nHelmagent: monitor: enabled: false secure: enabled: true sysdig: settings: feature: mode: secure_light TroubleshootingTroubleshooting mode offers sophisticated metrics with detailed diagnostic capabilities. Some of these metrics are heuristic in nature.\nIn addition to the extensive metrics available in the Monitor mode, Troubleshooting mode provides additional metrics such as net.sql and additional segmentation for file and network metrics. For more information, see Additional Metrics Values Available in Troubleshooting.\ndragent.yamlIf your account is enabled for Secure, add the following:\napp_checks_enabled: false drift_control: enabled: false drift_killer: enabled: false falcobaseline: enabled: false feature: mode: troubleshooting jmx: enabled: false memdump: enabled: false network_topology: enabled: false prometheus: enabled: false statsd: enabled: false If your account is enabled for Monitor, add the following:\nHelmIf your account is enabled for Monitor, add the following:\nagent: monitor: enabled: true secure: enabled: false sysdig: settings: feature: mode: troubleshooting If your account is enabled for Secure, add the following:\nagent: monitor: enabled: false secure: enabled: true sysdig: settings: feature: mode: troubleshooting Custom Metrics Only ModeCustom Metrics Only mode collects the same metrics as the Monitor Light mode, but also adds the ability to collect the following:\nCustom Metrics: StatsD, JMX, App Checks, and Prometheus Kubernetes State Metrics As such, Custom Metrics Only mode is suitable if would like to use most of the features of Monitor mode but are limited in resources.\nThis mode is not compatible with Secure. If your account is configured for Secure, you must explicitly disable Secure in the agent configuration if you wish to use this mode.\nThis mode requires agent v12.4.0 or above.\nEnable Custom Metrics Only Mode Open the dragent.yaml file.\nAdd the following configuration parameter:\nfeature: mode: custom-metrics-only If your account is enabled for Secure, add the following:\nsecurity: enabled: false secure_audit_streams: enabled: false falcobaseline: enabled: false This configuration explicitly disables the Secure features in the agent. If you do not disable Secure, the agent will not start due to incompatiblity issues.\nRestart the agent.\n","url":"https://docs.sysdig.com/en/administration/configure-agent-modes/"},{"id":374,"title":"Alerts Library","content":"Powered by Monitoring Integrations, Sysdig automatically detects the applications and services running in your environment and recommends alerts that you can enable.\nAccess Alerts Library Log in to Sysdig Monitor.\nSelect Alerts from the left navigation pane.\nIn the Alerts module, select Library.\nThere are two types of alert templates in the Alerts Library:\nRecommended: Alert suggestions based on the services that are detected running in your infrastructure.\nAll Templates: You can browse templates for all the services. For some templates, you might need to configure Monitor Integrations.\nImport an Alert Locate the service that you want to configure an alert for.\nTo do so, either use the text search or identify from a list of services.\nFor example, click Redis.\nFrom a list of template suggestions, choose the desired template.\nThe Redis page shows the alerts that are already in use and that you can enable.\nEnable one or more alert templates. To do so, you can do one of the following:\nClick Enable Alert.\nBulk enable templates. Select the check box corresponding to the alert templates and click Enable Alert on the top-right corner.\nClick on the alert template to display the slider. Click the Enable Alert on the slider.\nOn the Configure Redis Alert page, specify the Scope and select the Notification channels.\nClick Enable Alert.\nYou will see a message stating that the Redis Alert has been successfully created.\nUse Alerts LibraryIn addition to importing an alert, you can also do the following with the Alerts Library:\nIdentify Alert templates associated with the services running in your infrastructure by hovering your cursor over the number of services.\nBulk import Alert templates. See Import an Alert.\nView alerts that are already configured.\nFilter Alert templates. Enter the search string to display the matching results.\nDiscover the workloads where a service is running. To do so, click on the Alert template to display the slider. On the slider, click Workloads.\nView the alerts in use. To do so, select an Alert template to open the specific template page. Here, you will see Alerts in use where applicable.\nConfigure an alert.\nAdditional alert configuration, such as changing the alert name, description, and severity can be done after the import.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/alerts-library/"},{"id":375,"title":"Automatic Cloud Account Onboarding","content":"Newly created cloud accounts are automatically detected and onboarded within 24 hours.\nAutomatic Cloud Account Onboarding enhances the cloud account onboarding experience. This functionality:\nAllows you to selectively enable or disable this behavior using the UI or Terraform. Provides visibility into newly added accounts and any additional setup required. This capability reflects the dynamic nature of modern cloud environments and reduces the manual overhead required to maintain up-to-date infrastructure visibility.\nPrerequisites AWS account with administrative privileges Sysdig Secure account with organization admin rights Automatic Cloud Account Onboarding StepsThe following steps outline the process for automatic cloud account onboarding:\nLog in to Sysdig Secure. Go to Integrations \u0026gt; Environments \u0026gt; AWS. Click Add AWS Account. Select Organization. Under Terraform, when you prepare for onboarding, go to the step Accounts to Onboard. You will see Automatic Onboarding \u0026amp; Offboarding enabled by default. When you deploy Terraform, you will notice enable_automatic_onboarding = true in the snippet.\nTesting Automatic Cloud Account OnboardingOnce you have completed onboarding of one account, you can go ahead and add multiple accounts to your organization. Any newly created AWS accounts that are in active state within the organization will be automatically detected and onboarded. You can verify this through Integrations \u0026gt; Environments \u0026gt; AWS. The new accounts will be listed and the status should show as Connected.\nFor example, the following image shows the newly onboarded account: TroubleshootingAutomatic Cloud Account Onboarding Fails for New AWS AccountsWhen a new AWS account is created, it is automatically scraped by Sysdig regardless of its registration status. However, Automatic Cloud Account Onboarding fails for this newly created account if the account has not completed the registration process.\nWorkaroundEnsure that the newly added AWS account is fully registered with AWS.\n","url":"https://docs.sysdig.com/en/sysdig-secure/aws/automatic-onboarding/"},{"id":376,"title":"AWS GuardDuty Policy","content":" Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nPrerequisitesGuardDuty findings are only available when the connected AWS cloud account has GuardDuty enabled. To enable GuardDuty on your AWS account, see Getting started with GuardDuty.\nCreate an AWS GuardDuty PolicyTo create an AWS GuardDuty policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nSelect + Add Policy \u0026gt; AWS GuardDuty.\nName: Enter a policy name.\nDescription: Provide a meaningful and searchable description or keep the default one.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the severity level you would like to see in the Runtime Policies UI: High, Medium, Low, Info.\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or create a New Rule. See Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nNotify: Select a notification channel from the drop-down for sending notifications of events to appropriate personnel.\nSee Set Up Notification Channels for more information.\nSearch for Existing PoliciesTo review the existing AWS GuardDuty policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and AWS GuardDuty.\nEither edit a managed policy and duplicate it to create a custom policy,\nor\nClick + Add Policy, and choose AWS GuardDuty to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/aws_guardduty_policy/"},{"id":377,"title":"Azure","content":"Cloud Security Posture Management (CSPM)Cloud Security Posture Management (CSPM):\nMonitors and detects misconfigurations in your cloud resources. Ensures your cloud environment complies with industry standards and regulations. Provides a comprehensive inventory of all cloud assets, helping you maintain visibility and control over your environment. To enable CSPM, connect your Azure environment.\nReview Azure Roles and PermissionsSecurity PrincipalsThe onboarding process involves two security principals:\nInstaller: The primary security principal, either a User or a Service Principal. This security principal will be used to perform the onboarding. Sysdig does not have access to this security principal. Sysdig: A Service Principal (robot user) created during onboarding with specific, less permissive roles. Sysdig will be given access to this security principal. Azure Role TypesAzure Identity and Access Management (IAM) is separated into two control planes:\nEntra ID Roles: Applied to the entire Tenant. Azure RBAC Roles: Applied to the Subscription or Management Group being onboarded. Prerequisites Sysdig Secure SaaS with Admin permissions Terraform v1.5.0+ installed Azure CLI installed. See How to install the Azure CLI. A security principal with the permissions required to install, as mentioned in Security Principals. For the required permissions, see Permissions Required to Install. To grant permissions, you need: SP_ID: Your Installer security principal ID. To retrieve this, open the Azure CI and use the command az ad sp list --display-name \u0026quot;terraform-runner\u0026quot; --query \u0026quot;[0].appId\u0026quot; --output tsv. ROOT_MANAGEMENT_GROUP_ID: Your Root Management Group ID. To retrieve this, open the Azure CLI and use the command az account management-group list --query \u0026quot;[].{name:name, id:id}\u0026quot; --output tsv. Supported Azure RegionsSysdig supports agentless scanning in the following Azure regions:\nRegion Display Name australiaeast Australia East brazilsouth Brazil South canadacentral Canada Central centralindia Central India centralus Central US eastasia East Asia eastus East US eastus2 East US 2 francecentral France Central germanywestcentral Germany West Central japaneast Japan East koreacentral Korea Central northeurope North Europe norwayeast Norway East qatarcentral Qatar Central southafricanorth South Africa North southeastasia Southeast Asia swedencentral Sweden Central switzerlandnorth Switzerland North uaenorth UAE North uksouth UK South westeurope West Europe westus2 West US 2 westus3 West US 3 Need support for a region not listed? Contact your Sysdig representative to request additional region coverage.\nPrepare Your Environment1. Configure Installation PermissionsEnsure the principal you log in to Azure with has the necessary roles and permissions to install. You can:\nUse an existing principal who meets the permissions requirements. Create a new principal and set up permissions. Add permissions to an existing principal. Log in to Azure. Check Entra ID Roles: Navigate to the Entra ID console and select Roles and Administrators. Verify and add necessary roles. Check Azure RBAC Roles: For Single Subscriptions: Navigate to Subscriptions, select the target subscription, and verify roles. For Management Groups: Navigate to Management Groups, select the target group, and verify roles. 2. Authenticate and Configure TerraformA common way to do this is:\nEnsure you are logged in to the correct Tenant.\nLog in using the Azure CLI:\naz login --tenant \u0026#34;TENANT_ID_OR_DOMAIN\u0026#34; You will be presented with a web page to select your user account. Be sure to log in as the user you configured in Step 1.\nConfirm you are logged in as the correct user by running:\naz ad signed-in-user show For alternative ways to authenticate Terraform, see the Terraform documentation: Authenticating to Azure Active Directory and Authenticating to Azure.\n3. Collect your Azure Tenant ID and Subscription IDTenant ID Sign in to the Azure portal. Navigate to Microsoft Entra ID \u0026gt; Properties. Scroll down to the Tenant ID section. Find your tenant ID in the box. Select the Copy to clipboard icon shown next to the Tenant ID. Store this value. You can paste this value into a text document or other location. Subscription ID Sign in to the Azure portal. Under the Azure services heading, select Subscriptions. If you don\u0026rsquo;t see Subscriptions here, use the search box to find it. Find the subscription in the list, and note the Subscription ID shown in the second column. If no subscriptions appear, or you don\u0026rsquo;t see the right one, you may need to switch directories to show the subscriptions from a different Microsoft Entra tenant. To easily copy the Subscription ID, select the subscription name to display more details. Select the Copy to clipboard icon shown next to the Subscription ID in the Essentials section. You can paste this value into a text document or other location. Install Azure Using the Wizard Log in to Sysdig Secure. Select Integrations \u0026gt; Environments \u0026gt; Azure and click Add Azure Account on the top right corner. Connect your Azure Tenant or Single Subscription. This enables CSPM and lets you onboard Vulnerability Management and CDR after completing. Onboarding Multiple Subscriptions?\nIf you intend to onboard multiple subscriptions, do not perform multiple Single Subscription installations.\nInstead, select Tenant and use the Include/Exclude options to target specific Management Groups or Subscription IDs. See Selective Cloud Account Onboarding for details.\nWhy? Single Subscription onboarding requires the Directory Reader role (a global Tenant-level permission). If you attempt to onboard multiple single subscriptions, new subscriptions can overwrite prior ones and cause the installation to fail due to conflicting global permission assignments.\nTenant Multi-Subscription Enter your: Tenant ID: The ID of the tenant you want to onboard. Subscription ID: The ID of the subscription where the Sysdig resources will be created. Specify Management Groups: For onboarding the entire Tenant: Enter Root Management Group ID. For a subset: Enter Management Group IDs in a comma-separated list. Generate and apply the Terraform code: Create a main.tf file. Copy the snippet provided into the file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. Within an hour after deployment, your accounts will appear on the Cloud Accounts page.\nSingle Subscription Enter your: Tenant ID: The ID of the tenant which contains the subscription you want to onboard. Subscription ID: The ID of the subscription you want to onboard. Generate and apply the Terraform code: Create a main.tf file. Copy the snippet provided into the file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. Within an hour after deployment, your accounts will appear on the Cloud Accounts page.\nCheck the Connection StatusWithin 5 minutes, after you apply Terraform, your accounts will appear on the Sysdig Cloud Accounts page. You can add more features after this initial connection by following instructions to Add New Features.\nYou can verify your CSPM configuration by checking the connection status.\nIn Sysdig Secure, select Integrations \u0026gt; Environments \u0026gt; Azure.\nThe Status column shows the overall connection status:\nConnected Error Unknown Select the desired account to review the individual services in the detail drawer.\nThe health status for CSPM configuration is given below:\nCSPM Status Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Error ❌ Authentication errors. For example: Invalid account IDInvalid client secretInvalid access credentialsAccess token errors Deny policy created by the user is preventing Sysdig from collecting resourcesThe scan takes too long and eventually times out.Unknown error ","url":"https://docs.sysdig.com/en/sysdig-secure/connect-azure/"},{"id":378,"title":"Azure Active Directory (SAML On-Prem)","content":"PrerequisitesAdministrator privileges on Sysdig and Azure.\nConfigure the Sysdig Application in Azure AD Log in to the Azure AD portal.\nSelect Azure Active Directory, then click Enterprise Applications.\nThe Enterprise applications - All application screen is displayed.\nClick New Application.\nOn the Add an Application screen, select Non-gallery application.\nGive your application a name, and click Add at the bottom of the page.\nOn the menu, select Single sign-on.\nChoose SAML as the sign-on method.\nEdit the Basic SAML Configuration as follows:\nIn the configuration page, click the edit icon.\nSpecify the following:\nIdentifier (Entity ID): Uniquely identifies the Sysdig application. Azure AD sends the identifier to the Sysdig application as the audience parameter of the SAML token. Sysdig validates this as part of the SSO process.\nFor example, the identifier for Sysdig Monitor for the EU region is https://eu1.app.sysdig.com.\nSee SaaS Regions and IP Ranges for the complete list of entity IDs for different regions.\nReply URL: Specifies where Sysdig expects to receive the SAML token.\nFor example, the identifier for Sysdig Monitor for the EU region is https://eu1.app.sysdig.com/api/saml/auth.\nSee SaaS Regions and IP Ranges for the complete list of reply URLs for different regions.\nRelay State: Specifies to the application where to redirect the user after authentication is completed. Typically the value is a valid URL for Sysdig. For on-prem installations, the customer number is always 1.\nThe format is:\n#/\u0026amp;customer=1234 Sign on URL: It is the sign-in page for the Sysdig application that will perform the service provider-initiated SSO. Leave it blank if you want to perform identity-provider-initiated SSO.\nFor more information on configuration parameters, see Configure SAML-based single sign-on to non-gallery applications.\nSysdig-Specific Steps for Active Directory Configuration Under SAML Signing Certificate, copy the App Federation Metadata URL.\nLog in to your Sysdig instance as an admin.\nFor on-prem deployments, log in as the super admin.\nNavigate to Settings \u0026gt; Authentication, and select SAML under Connection Settings.\nEnter the following:\nMetadata: Enter the App Federation Metadata URL you copied.\nEmail Parameter: Set the value to emailaddress.\nAzure AD claims are:\nsaml = AD givenname = user.givenname surname = user.surname emailaddress = user.mail name = user.userprincipalname Unique User Identifier = user.userprincipalname In the Sysdig application, you need to set the email to emailaddress which is what Azure AD sends to Sysdig in the SAML assertion. Alternatively, Azure AD can be modified to send another attribute.\nClick Save.\nSelect SAML from the Enable Single Sign On drop-down.\nCreate a User in Azure Active Directory Domain Log in to the Azure AD portal.\nClick Azure Active Directory, and note down the domain name.\nSelect Azure Active Directory, then Users.\nThe Users - All Users screen is displayed.\nSelect New Users .\nYou can either create a new user or invite an existing AD.\nEnter name, username, and other details, then click Create.\nIn the Profile page, add the Email and Alternate Email parameters. The values can match\nAssign the User to the Sysdig Application Navigate to the Sysdig application.\nClick Users and Group, then click the Add user button.\nSelect the Users and Groups checkbox, then choose the newly created user to add to the application.\nClick Select, then Assign at the bottom of the screen.\nEnable Authentication Settings in the Sysdig InstanceEnsure that Flag to enable/disable create user on login is enabled. Typically this setting is enabled by default.\nIf you are using both Sysdig Monitor and Secure, ensure that the user accounts are created on both the products. A user that is created only on one Sysdig application will not be able to log in to another by using SAML SSO.\nif you are on Sysdig Platform versions 2.4.1 or prior, contact Sysdig Support to help with user creation.\n(Optional) Configure Sysdig as a New ApplicationIf Azure Active Directory does not allow you to create Sysdig as a Non- Gallery application, perform the following:\nIn Azure AD, click Enterprise Applications \u0026gt; New Application.\nSelect Application you\u0026rsquo;re developing.\nYou will be taken to the app registration page:\nSelect New Registration:\nProvide a name for the application you are registering.\nEnter the redirect URI.\nFor example, the redirect URI for Sysdig Monitor for the EU region is https://eu1.app.sysdig.com/api/saml/auth. See SaaS Regions and IP Ranges for the redirect URLs for other regions.\nClick Register to complete the registration.\nIn the Overview tab click Add an Application ID URI:\nClick Add a scope.\nAdd the application ID URI as follows:\nhttps://\u0026lt;your_sysdig_url\u0026gt;:443 Replace \u0026lt;*your_sysdig_*url\u0026gt; with the URL appropriate to your application and region. See SaaS Regions and IP Ranges for more information.\nIn the Overview tab, click Endpoints, and copy the Federation Metadata URL.\nLog in to Sysdig, navigate to SAML Authentication screen, and enter the Federation Metadata URL.\nYou will still need to ensure that the user creation on the login option is enabled.\nSave the settings.\n","url":"https://docs.sysdig.com/en/administration/onprem-saml-active-directory/"},{"id":379,"title":"Integrate Sysdig with Checkmarx","content":"There are two different integrations with Checkmarx:\nRuntime Insights (In-use packages) Cloud Insights (Exposure and attack-path) Runtime Insights IntegrationIn this use case, Sysdig enriches Checkmarx image scan results so that Checkmarx users can prioritize vulnerabilities related to packages that are in-use when they are running in a cluster.\nPrerequisites Have administrator rights to your Sysdig Secure SaaS account and have the Sysdig Agent installed in the clusters you want to integrate. Have a Checkmarx account with the necessary permissions to enable the integration. Risk Spotlight in the backend for your Sysdig account. Contact Sysdig Support to explicitly enable it. IntegrationEnsure that your Sysdig Agents are properly configured in the clusters where the workloads are running, that is the same container images you are analyzing with Checkmarx.\nGenerate a Token for the Integration Select Integrations \u0026gt; Third Party | Risk Spotlight Integration.\nThe Spotlight Integration page appears with a list of existing tokens and their expiry dates.\nClick +Add Token.\nSpecify the attributes and click Create Token.\nName: Choose a name that indicates the integration with which the token is associated. Expiration: Select an expiration date: 1/3/6 months or 1 year. Copy the new token as it is displayed in the list.\nStore the token in a safe place; it will not be visible or recoverable again.\nContinue with the Checkmarx Runtime Usage integration guide.\nTo Renew a token at any time, click the Renew button, reset the expiry, and confirm.\nTo delete a token, click the X beside the token name and confirm. This action will sever the integration between Sysdig and the 3rd-party tool.\nCheck Integration in CheckmarxSysdig runtime insights information enriches Checkmarx images and findings, streamlining the prioritization process for Checkmarx users. Note that you have to scan the same images using Checkmarx SCA resolver.\nCloud Insights IntegrationIn this use case, Sysdig enriches Checkmarx Cloud Insights images with posture details like the public exposure, helping to draw the attack path analysis.\nPrerequisites Have administrator rights to your Sysdig Secure SaaS account and have the Sysdig Agent installed in the clusters you want to integrate. Have a Checkmarx account with the proper permissions to enable the integration. A sample script from the Sysdig Support. Deploy and maintain an integration script. The script is delivered as a Lambda function that you can customize. IntegrationEnsure that your Sysdig Agents are properly configured in the clusters where the workloads are running. It is the same container images you are analyzing with Checkmarx.\nGenerate a Token for the Integration Select Settings \u0026gt; User Profile \u0026gt; Sysdig Secure API or create a service account and copy its token.\nMake sure that the user or the service account have the right scope and permissions.\nDeploy and configure the script that will request Sysdig data to feed Checkmarx Cloud Insights.\nThe deployment instructions and required env-vars are documented together with the script files.\nContinue with the Checkmarx Cloud Insights integration guide.\nCheck Integration in CheckmarxSysdig exposure and deployment topology information enriches Checkmarx attack path and cloud insights.\n","url":"https://docs.sysdig.com/en/sysdig-secure/appsec-integrations-checkmarx/"},{"id":380,"title":"Connect Azure Account in Sysdig Monitor","content":"Access Cloud Accounts Log in to Sysdig Monitor as an administrator.\nIn the left-hand sidebar, select Integration \u0026gt; Cloud Accounts.\nThe Cloud Accounts page appears.\nConnect an Azure AccountIn Azure Log in to the Microsoft Azure.\nSelect Active Directory and register your application with the Active Directory.\nClick New registration.\nSpecify a unique name and select a type.\nClick Add a certificate or secret and create the client credentials and secret.\nCopy the value of the secret because you will not be able to retrieve the key later.\nThe key value (value of client secret) is required to sign in as the application.\nNavigate to Support Subscription and select Access control (IAM).\nClick Grant access to this resource to assign an appropriate role to this account.\nIn the Add role assignment page, select the Monitoring Reader role.\nThis role will allow your application to read monitoring data (resources, metric descriptors, metrics).\nClick Next to move to the Members tab.\nSelect Assign access to \u0026gt; User, group, or service principal and then select your application.\nClick Review + assign to save the changes.\nEnsure that you have the following before you configuring an Azure account in Sysdig:\nFrom the App registration page, ensure that you copy the following:\nTenant ID Application (client) ID Value of the Client Secret From the Subscription page, copy the Subscription ID. In the Sysdig Monitor UI On the Cloud Accounts page, click Add Account.\nChoose Azure.\nThe Connect Azure Account wizard appears.\nEnter the details you copied from the Azure App registration and Subscription pages:\nTenant ID Client ID Client Secret Subscription ID Complete the installation and click Confirm.\nMonitor Azure Resource QuotasYou can monitor Azure Resource Quotas through the Sysdig API. To enable pulling Azure Resource Quotas into Sysdig Monitor, configure the API endpoint with the following command:\ncurl -X POST https://${sysdigUrl}/ui/customerSettings/${customerId}/azureIntegration/quota/enable -H \u0026#34;Authorization: Bearer ${token}\u0026#34; Where:\n${sysdigUrl} : The URL you use to access Sysdig Monitor, such as https://us2.app.sysdig.com/ for US West.. This varies by region. See SaaS Regions and IP Ranges. ${customerId} : Your unique Sysdig Monitor customer ID. Find it in Settings \u0026gt; Authentication \u0026gt; Customer ID. ${token}: Your Sysdig Monitor API token. Find it in Settings \u0026gt; User Profile \u0026gt; Sysdig Monitor API Token Curl is used here as an example; you may use any HTTP API tool that you wish to configure this feature.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/connect-azure-account/"},{"id":381,"title":"Consul","content":" It’s easy! Sysdig automatically detects metrics from this app based on standard default configurations.\nThis page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nConsul ConfigurationConsul is ready to expose metrics without any special configuration.\nSysdig Agent ConfigurationReview how to edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml ``uses the following code to connect with Consul and collect basic metrics.\napp_checks: - name: consul pattern: comm: consul conf: url: \u0026#34;http://localhost:8500\u0026#34; catalog_checks: yes With the dragent.default.yaml file, the below set of metrics are available in the Sysdig Monitor UI:\nMetrics name consul.catalog.nodes_critical consul.catalog.nodes_passing consul.catalog.nodes_up consul.catalog.nodes_warning consul.catalog.total_nodes consul.catalog.services_critical consul.catalog.services_passing consul.catalog.services_up consul.catalog.services_warning consul.peers Additional metrics and event can be collected by adding configuration in dragent.yaml file. The ACL token must be provided if enabled. See the following examples.\nRemember! Never edit dragent.default.yaml ``directly; always edit only dragent.yaml.\nExample 1: Enable Leader Change Eventself_leader_check An enabled node will watch for itself to become the leader and will emit an event when that happens. It can be enabled on all nodes.\napp_checks: - name: consul pattern: comm: consul conf: url: \u0026#34;http://localhost:8500\u0026#34; catalog_checks: yes self_leader_check: yes logs_enabled: true Example 2: Enable Latency MetricsIf the network_latency_checks flag is enabled, then the Consul network coordinates will be retrieved and the latency calculated for each node and between data centers.\napp_checks: - name: consul pattern: comm: consul conf: url: \u0026#34;http://localhost:8500\u0026#34; catalog_checks: yes network_latency_checks: yes logs_enabled: true With the above changes, you can see the following additional metrics:\nMetrics name consul.net.node.latency.min consul.net.node.latency.p25 consul.net.node.latency.median consul.net.node.latency.p75 consul.net.node.latency.p90 consul.net.node.latency.p95 consul.net.node.latency.p99 consul.net.node.latency.max Example 3: Enable ACL TokenWhen the ACL Systemis enabled in Consul, the ACL Agent Token must be added in dragent.yaml in order to collect metrics.\nFollow Consul\u0026rsquo;s official documentation to Configure ACL, Bootstrap ACL and Create Agent Token.\napp_checks: - name: consul pattern: comm: consul conf: url: \u0026#34;http://localhost:8500\u0026#34; acl_token: \u0026#34;xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\u0026#34; #Add agent token catalog_checks: yes logs_enabled: true Example 4: Collect Metrics from Non-Leader NodeRequired: Agent 9.6.0+\nWith agent 9.6.0, you can use the configuration option single_node_install (Optional. Default: false). Set this option to true and the app check will be performed on non-leader nodes of Consul.\napp_checks: - name: consul pattern: comm: consul conf: url: \u0026#34;http://localhost:8500\u0026#34; catalog_checks: yes single_node_install: true StatsD MetricsIn addition to the metrics from the Sysdig app-check, there are many other metrics that Consul can send using StatsD. Those metrics will be automatically collected by the Sysdig agent\u0026rsquo;s StatsD integration if Consul is configured to send them.\nAdd statsd_address under telemetry to the Consul config file. The default config file location is /consul/config/local.json\n{ ... \u0026#34;telemetry\u0026#34;: { \u0026#34;statsd_address\u0026#34;: \u0026#34;127.0.0.1:8125\u0026#34; } ... } See Telemetry Metrics for more details.\nMetrics AvailableSee Consul Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/consul/"},{"id":382,"title":"Containers","content":"sysdig_container_count Prometheus ID sysdig_container_count Legacy ID container.count Metric Type gauge Unit number Description The count of the number of containers. Additional Notes This metric is perfect for dashboards and alerts. In particular, you can create alerts that notify you when you have too many (or too few) containers of a certain type in a certain group or node - try segmenting by container.image, .id or .name. See also: host.count. sysdig_container_cpu_cgroup_used_percent Prometheus ID sysdig_container_cpu_cgroup_used_percent Legacy ID cpu.cgroup.used.percent Metric Type gauge Unit percent Description The percentage of a container\u0026rsquo;s cgroup limit that is actually used. This is the minimum usage for the underlying cgroup limits: cpuset.limit and quota.limit. Additional Notes sysdig_container_cpu_cores_cgroup_limit Prometheus ID sysdig_container_cpu_cores_cgroup_limit Legacy ID cpu.cores.cgroup.limit Metric Type gauge Unit number Description The number of CPU cores assigned to a container. This is the minimum of the cgroup limits: cpuset.limit and quota.limit. Additional Notes sysdig_container_cpu_cores_quota_limit Prometheus ID sysdig_container_cpu_cores_quota_limit Legacy ID cpu.cores.quota.limit Metric Type gauge Unit number Description The number of CPU cores assigned to a container. Technically, the container\u0026rsquo;s cgroup quota and period. This is a way of creating a CPU limit for a container. Additional Notes sysdig_container_cpu_cores_used Prometheus ID sysdig_container_cpu_cores_used Legacy ID cpu.cores.used Metric Type gauge Unit number Description The CPU core usage of each container is obtained from cgroups, and is equal to the number of cores used by the container. For example, if a container uses two of an available four cores, the value of sysdig_container_cpu_cores_used will be two. Additional Notes sysdig_container_cpu_cores_used_percent Prometheus ID sysdig_container_cpu_cores_used_percent Legacy ID cpu.cores.used.percent Metric Type gauge Unit percent Description The CPU core usage percent for each container is obtained from cgroups, and is equal to the number of cores multiplied by 100. For example, if a container uses three cores, the value of sysdig_container_cpu_cores_used_percent would be 300%. Additional Notes sysdig_container_cpu_quota_used_percent Prometheus ID sysdig_container_cpu_quota_used_percent Legacy ID cpu.quota.used.percent Metric Type gauge Unit percent Description The percentage of a container\u0026rsquo;s CPU Quota that is actually used. CPU Quotas are a common way of creating a CPU limit for a container. CPU Quotas are based on a percentage of time - a container can only spend its quota of time on CPU cycles across a given time period (default period is 100ms). Note that, unlike CPU Shares, CPU Quota is a hard limit to the amount of CPU the container can use - so this metric, CPU Quota %, should not exceed 100%. Additional Notes This metric uses the container limit to define the used quota percentage. If the limit is not specified in the container (for example, if resources are not set in the Kubernetes Pod level) this metric is not generated. sysdig_container_cpu_shares_count Prometheus ID sysdig_container_cpu_shares_count Legacy ID cpu.shares.count Metric Type gauge Unit number Description The number of CPU shares assigned to a container (technically, the container\u0026rsquo;s cgroup) - this is a common way of creating a CPU limit for a container. CPU Shares represent a relative weight used by the kernel to distribute CPU cycles across different containers. The default value for a container is 1024. Each container receives its own allocation of CPU cycles, according to the ratio of it\u0026rsquo;s share count vs to the total number of shares claimed by all containers. For example, if you have three containers, each with 1024 shares, then each will recieve 1/3 of the CPU cycles. Note that this is not a hard limit: a container can consume more than its allocation, if the CPU has cycles that aren’t being consumed by the container they were originally allocated to. Additional Notes sysdig_container_cpu_shares_used_percent Prometheus ID sysdig_container_cpu_shares_used_percent Legacy ID cpu.shares.used.percent Metric Type gauge Unit percent Description The percentage of a container\u0026rsquo;s allocated CPU shares that are actually used. CPU Shares are a common way of creating a CPU limit for a container. CPU Shares represent a relative weight used by the kernel to distribute CPU cycles across different containers. The default value for a container is 1024. Each container receives its own allocation of CPU cycles, according to the ratio of it\u0026rsquo;s share count vs to the total number of shares claimed by all containers. For example, if you have three containers, each with 1024 shares, then each will recieve 1/3 of the CPU cycles. Note that this is not a hard limit: a container can consume more than its allocation, if the CPU has cycles that aren’t being consumed by the container they were originally allocated to - so this metric, CPU Shares %, can actually exceed 100%. Additional Notes sysdig_container_cpu_used_percent Prometheus ID sysdig_container_cpu_used_percent Legacy ID cpu.used.percent Metric Type gauge Unit percent Description The CPU usage for each container is obtained from cgroups, and normalized by dividing by the number of cores to determine an overall percentage. For example, if the environment contains six cores on a host, and the container or processes are assigned two cores, Sysdig will report CPU usage of 2/6 * 100% = 33.33%. This metric is calculated differently for hosts and processes. Additional Notes sysdig_container_fd_used_percent Prometheus ID sysdig_container_fd_used_percent Legacy ID fd.used.percent Metric Type gauge Unit percent Description The percentage of used file descriptors out of the maximum available. Additional Notes Usually, when a process reaches its FD limit it will stop operating properly and possibly crash. As a consequence, this is a metric you want to monitor carefully, or even better use for alerts. sysdig_container_file_error_open_count Prometheus ID sysdig_container_file_error_open_count Legacy ID file.error.open.count Metric Type counter Unit number Description The number of errors in opening files. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_file_error_total_count Prometheus ID sysdig_container_file_error_total_count Legacy ID file.error.total.count Metric Type counter Unit number Description The number of error caused by file access. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_file_in_bytes Prometheus ID sysdig_container_file_in_bytes Legacy ID file.bytes.in Metric Type counter Unit data Description The amount of bytes read from file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_file_in_iops Prometheus ID sysdig_container_file_in_iops Legacy ID file.iops.in Metric Type counter Unit number Description The number of file read operations per second. Additional Notes This is calculated by measuring the actual number of read and write requests made by a process. Therefore, it can differ from what other tools show, which is usually based on interpolating this value from the number of bytes read and written to the file system. sysdig_container_file_in_time Prometheus ID sysdig_container_file_in_time Legacy ID file.time.in Metric Type counter Unit time Description The time spent in file reading. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_file_open_count Prometheus ID sysdig_container_file_open_count Legacy ID file.open.count Metric Type counter Unit number Description The number of time the file has been opened. Additional Notes sysdig_container_file_out_bytes Prometheus ID sysdig_container_file_out_bytes Legacy ID file.bytes.out Metric Type counter Unit data Description The number of of bytes written to file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_file_out_iops Prometheus ID sysdig_container_file_out_iops Legacy ID file.iops.out Metric Type counter Unit number Description The Number of file write operations per second. Additional Notes This is calculated by measuring the actual number of read and write requests made by a process. Therefore, it can differ from what other tools show, which is usually based on interpolating this value from the number of bytes read and written to the file system. sysdig_container_file_out_time Prometheus ID sysdig_container_file_out_time Legacy ID file.time.out Metric Type counter Unit time Description The time spent in file writing. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_file_total_bytes Prometheus ID sysdig_container_file_total_bytes Legacy ID file.bytes.total Metric Type counter Unit data Description The number of bytes read from and written to file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_file_total_iops Prometheus ID sysdig_container_file_total_iops Legacy ID file.iops.total Metric Type counter Unit number Description The number of read and write file operations per second. Additional Notes This is calculated by measuring the actual number of read and write requests made by a process. Therefore, it can differ from what other tools show, which is usually based on interpolating this value from the number of bytes read and written to the file system. sysdig_container_file_total_time Prometheus ID sysdig_container_file_total_time Legacy ID file.time.total Metric Type counter Unit time Description The time spent in file I/O. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_fs_free_bytes Prometheus ID sysdig_container_fs_free_bytes Legacy ID fs.bytes.free Metric Type gauge Unit data Description The available space in the filesystem. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_fs_free_percent Prometheus ID sysdig_container_fs_free_percent Legacy ID fs.free.percent Metric Type gauge Unit percent Description The percentage of free space in the filesystem. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_fs_inodes_total_count Prometheus ID sysdig_container_fs_inodes_total_count Legacy ID fs.inodes.total.count Metric Type gauge Unit number Description The total number of inodes in the filesystem. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_fs_inodes_used_count Prometheus ID sysdig_container_fs_inodes_used_count Legacy ID fs.inodes.used.count Metric Type gauge Unit number Description The number of inodes used in the filesystem. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_fs_inodes_used_percent Prometheus ID sysdig_container_fs_inodes_used_percent Legacy ID fs.inodes.used.percent Metric Type gauge Unit percent Description The percentage of inodes usage in the filesystem. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_fs_largest_used_percent Prometheus ID sysdig_container_fs_largest_used_percent Legacy ID fs.largest.used.percent Metric Type gauge Unit percent Description The percentage of the largest filesystem in use. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_fs_root_used_percent Prometheus ID sysdig_container_fs_root_used_percent Legacy ID fs.root.used.percent Metric Type gauge Unit percent Description The percentage of the root filesystem in use in the container. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_fs_rw_used_bytes Prometheus ID sysdig_container_fs_rw_used_bytes Legacy ID Metric Type counter Unit data Description This metric helps identify how much disk space each container is using, which is useful for troubleshooting disk usage issues at the container level. Additional Notes sysdig_container_fs_total_bytes Prometheus ID sysdig_container_fs_total_bytes Legacy ID fs.bytes.total Metric Type gauge Unit data Description The size of container filesystem. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_fs_used_bytes Prometheus ID sysdig_container_fs_used_bytes Legacy ID fs.bytes.used Metric Type gauge Unit data Description The used space in the container filesystem. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_fs_used_percent Prometheus ID sysdig_container_fs_used_percent Legacy ID fs.used.percent Metric Type gauge Unit percent Description The percentage of the sum of all filesystems in use in the container. Additional Notes Container Filesystem metrics report data on filesystems mounted to containers. These are the most useful metrics for stateful containers which have dedicated file storage mounted. Use these metrics with appropriate scoping. Care should be taken when aggregating filesystem metrics to ensure that there is no “double counting” of filesystems that are mounted to multiple containers. Additionally, the metrics from overlay type file systems are generally not reported, so these metrics typically will not show the actual space consumed by a container. sysdig_container_info Prometheus ID sysdig_container_info Legacy ID info Metric Type gauge Unit number Description The info metrics will always have the value of 1. Additional Notes sysdig_container_memory_limit_bytes Prometheus ID sysdig_container_memory_limit_bytes Legacy ID memory.limit.bytes Metric Type gauge Unit data Description The memory limit in bytes assigned to a container. Additional Notes sysdig_container_memory_limit_used_percent Prometheus ID sysdig_container_memory_limit_used_percent Legacy ID memory.limit.used.percent Metric Type gauge Unit percent Description The percentage of memory limit used by a container. Additional Notes sysdig_container_memory_used_bytes Prometheus ID sysdig_container_memory_used_bytes Legacy ID memory.bytes.used Metric Type gauge Unit data Description The amount of physical memory currently in use. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_memory_used_percent Prometheus ID sysdig_container_memory_used_percent Legacy ID memory.used.percent Metric Type gauge Unit percent Description The percentage of physical memory in use. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_memory_virtual_bytes Prometheus ID sysdig_container_memory_virtual_bytes Legacy ID memory.bytes.virtual Metric Type gauge Unit data Description The virtual memory size of the process, in bytes. This value is obtained from Sysdig events. Additional Notes sysdig_container_net_connection_in_count Prometheus ID sysdig_container_net_connection_in_count Legacy ID net.connection.count.in Metric Type counter Unit number Description The number of currently established client (inbound) connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_container_net_connection_out_count Prometheus ID sysdig_container_net_connection_out_count Legacy ID net.connection.count.out Metric Type counter Unit number Description The number of currently established server (outbound) connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_container_net_connection_total_count Prometheus ID sysdig_container_net_connection_total_count Legacy ID net.connection.count.total Metric Type counter Unit number Description The number of currently established connections. This value may exceed the sum of the inbound and outbound metrics since it represents client and server inter-host connections as well as internal only connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_container_net_error_count Prometheus ID sysdig_container_net_error_count Legacy ID net.error.count Metric Type counter Unit number Description The number of errors on network-related system calls performed by containers. This includes syscalls acting on ipv4 and ipv6 socket file descriptors, such as recv and send. It also includes socket family syscalls, such as accept, connect and bind. Additional Notes By default, this metric shows the total value for the selected scope. For example, if the scope is defined as a group of machines, the metric value will be the total value for the whole group. Select Segment By in the UI to see the metric by host, process, container, and so on. sysdig_container_net_http_error_count Prometheus ID sysdig_container_net_http_error_count Legacy ID net.http.error.count Metric Type counter Unit number Description The number of failed HTTP requests as counted from 4xx/5xx status codes. Additional Notes sysdig_container_net_http_request_count Prometheus ID sysdig_container_net_http_request_count Legacy ID net.http.request.count Metric Type counter Unit number Description The count of HTTP requests. Additional Notes sysdig_container_net_http_request_time Prometheus ID sysdig_container_net_http_request_time Legacy ID net.http.request.time Metric Type gauge Unit time Description The average time taken for HTTP requests, expressed in nanoseconds. Additional Notes sysdig_container_net_http_statuscode_error_count Prometheus ID sysdig_container_net_http_statuscode_error_count Legacy ID net.http.statuscode.error.count Metric Type counter Unit number Description The number of HTTP error codes returned. Additional Notes sysdig_container_net_http_statuscode_request_count Prometheus ID sysdig_container_net_http_statuscode_request_count Legacy ID net.http.statuscode.request.count Metric Type counter Unit number Description The number of HTTP status codes requests. Additional Notes sysdig_container_net_http_url_error_count Prometheus ID sysdig_container_net_http_url_error_count Legacy ID net.http.url.error.count Metric Type counter Unit number Description Additional Notes sysdig_container_net_http_url_request_count Prometheus ID sysdig_container_net_http_url_request_count Legacy ID net.http.url.request.count Metric Type counter Unit number Description The number of HTTP URLs requests. Additional Notes sysdig_container_net_http_url_request_time Prometheus ID sysdig_container_net_http_url_request_time Legacy ID net.http.url.request.time Metric Type counter Unit time Description The time taken for requesting HTTP URLs. Additional Notes sysdig_container_net_in_bytes Prometheus ID sysdig_container_net_in_bytes Legacy ID net.bytes.in Metric Type counter Unit data Description The number of inbound network bytes. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_net_mongodb_error_count Prometheus ID sysdig_container_net_mongodb_error_count Legacy ID net.mongodb.error.count Metric Type counter Unit number Description The number of Failed MongoDB requests. Additional Notes sysdig_container_net_mongodb_request_count Prometheus ID sysdig_container_net_mongodb_request_count Legacy ID net.mongodb.request.count Metric Type counter Unit number Description The total number of MongoDB requests. Additional Notes sysdig_container_net_out_bytes Prometheus ID sysdig_container_net_out_bytes Legacy ID net.bytes.out Metric Type counter Unit data Description The number of outbound network bytes. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_net_request_count Prometheus ID sysdig_container_net_request_count Legacy ID net.request.count Metric Type counter Unit number Description The total number of network requests. Note, this value may exceed the sum of inbound and outbound requests, because this count includes requests over internal connections. Additional Notes sysdig_container_net_request_in_count Prometheus ID sysdig_container_net_request_in_count Legacy ID net.request.count.in Metric Type counter Unit number Description The number of inbound network requests. Additional Notes sysdig_container_net_request_in_time Prometheus ID sysdig_container_net_request_in_time Legacy ID net.request.time.in Metric Type counter Unit time Description The average time to serve an inbound request. Additional Notes sysdig_container_net_request_out_count Prometheus ID sysdig_container_net_request_out_count Legacy ID net.request.count.out Metric Type counter Unit number Description The number of outbound network requests. Additional Notes sysdig_container_net_request_out_time Prometheus ID sysdig_container_net_request_out_time Legacy ID net.request.time.out Metric Type counter Unit time Description The average time spent waiting for an outbound request. Additional Notes sysdig_container_net_request_time Prometheus ID sysdig_container_net_request_time Legacy ID net.request.time Metric Type counter Unit time Description The average time to serve a network request. Additional Notes sysdig_container_net_server_connection_in_count Prometheus ID sysdig_container_net_server_connection_in_count Legacy ID net.server.connection.count.in Metric Type counter Unit number Description Additional Notes sysdig_container_net_server_in_bytes Prometheus ID sysdig_container_net_server_in_bytes Legacy ID net.server.bytes.in Metric Type counter Unit data Description Additional Notes sysdig_container_net_server_out_bytes Prometheus ID sysdig_container_net_server_out_bytes Legacy ID net.server.bytes.out Metric Type counter Unit data Description Additional Notes sysdig_container_net_server_total_bytes Prometheus ID sysdig_container_net_server_total_bytes Legacy ID net.server.bytes.total Metric Type counter Unit data Description Additional Notes sysdig_container_net_sql_error_count Prometheus ID sysdig_container_net_sql_error_count Legacy ID net.sql.error.count Metric Type counter Unit number Description The number of failed SQL requests. Additional Notes sysdig_container_net_sql_query_error_count Prometheus ID sysdig_container_net_sql_query_error_count Legacy ID net.sql.query.error.count Metric Type counter Unit number Description Additional Notes sysdig_container_net_sql_query_request_count Prometheus ID sysdig_container_net_sql_query_request_count Legacy ID net.sql.query.request.count Metric Type counter Unit number Description Additional Notes sysdig_container_net_sql_query_request_time Prometheus ID sysdig_container_net_sql_query_request_time Legacy ID net.sql.query.request.time Metric Type counter Unit time Description Additional Notes sysdig_container_net_sql_querytype_error_count Prometheus ID sysdig_container_net_sql_querytype_error_count Legacy ID net.sql.querytype.error.count Metric Type counter Unit number Description Additional Notes sysdig_container_net_sql_querytype_request_count Prometheus ID sysdig_container_net_sql_querytype_request_count Legacy ID net.sql.querytype.request.count Metric Type counter Unit number Description Additional Notes sysdig_container_net_sql_querytype_request_time Prometheus ID sysdig_container_net_sql_querytype_request_time Legacy ID net.sql.querytype.request.time Metric Type counter Unit time Description Additional Notes sysdig_container_net_sql_request_count Prometheus ID sysdig_container_net_sql_request_count Legacy ID net.sql.request.count Metric Type counter Unit number Description The number of SQL requests. Additional Notes sysdig_container_net_sql_request_time Prometheus ID sysdig_container_net_sql_request_time Legacy ID net.sql.request.time Metric Type counter Unit time Description The average time to complete an SQL request. Additional Notes sysdig_container_net_sql_table_error_count Prometheus ID sysdig_container_net_sql_table_error_count Legacy ID net.sql.table.error.count Metric Type counter Unit number Description The total number of SQL errors returned. Additional Notes sysdig_container_net_sql_table_request_count Prometheus ID sysdig_container_net_sql_table_request_count Legacy ID net.sql.table.request.count Metric Type counter Unit number Description The total number of SQL table requests. Additional Notes sysdig_container_net_sql_table_request_time Prometheus ID sysdig_container_net_sql_table_request_time Legacy ID net.sql.table.request.time Metric Type counter Unit time Description The average time to serve an SQL table request. Additional Notes sysdig_container_net_tcp_queue_len Prometheus ID sysdig_container_net_tcp_queue_len Legacy ID net.tcp.queue.len Metric Type counter Unit number Description The length of the TCP request queue. Additional Notes sysdig_container_net_total_bytes Prometheus ID sysdig_container_net_total_bytes Legacy ID net.bytes.total Metric Type counter Unit data Description The total number of network bytes, including inbound and outbound connections. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_proc_count Prometheus ID sysdig_container_proc_count Legacy ID proc.count Metric Type counter Unit number Description The number of processes on host or container. Additional Notes sysdig_container_swap_limit_bytes Prometheus ID sysdig_container_swap_limit_bytes Legacy ID swap.limit.bytes Metric Type gauge Unit data Description The swap limit in bytes assigned to a container. Additional Notes sysdig_container_swap_limit_used_percent Prometheus ID sysdig_container_swap_limit_used_percent Legacy ID swap.limit.used.percent Metric Type gauge Unit percent Description The percentage of swap limit used by the container. Additional Notes sysdig_container_syscall_count Prometheus ID sysdig_container_syscall_count Legacy ID syscall.count Metric Type gauge Unit number Description The total number of syscalls seen. Additional Notes Syscalls are resource intensive. This metric tracks how many have been made by a given process or container sysdig_container_syscall_error_count Prometheus ID sysdig_container_syscall_error_count Legacy ID host.error.count Metric Type counter Unit number Description The number of system call errors. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_container_thread_count Prometheus ID sysdig_container_thread_count Legacy ID thread.count Metric Type counter Unit number Description The number of threads running in a container. Additional Notes sysdig_container_timeseries_count_appcheck Prometheus ID sysdig_container_timeseries_count_appcheck Legacy ID metricCount.appCheck Metric Type gauge Unit number Description The number of appcheck custom metrics. Additional Notes sysdig_container_timeseries_count_jmx Prometheus ID sysdig_container_timeseries_count_jmx Legacy ID metricCount.jmx Metric Type gauge Unit number Description The number of JMX custom metrics. Additional Notes sysdig_container_timeseries_count_prometheus Prometheus ID sysdig_container_timeseries_count_prometheus Legacy ID metricCount.prometheus Metric Type gauge Unit number Description The number of Prometheus custom metrics. Additional Notes sysdig_container_timeseries_count_statsd Prometheus ID sysdig_container_timeseries_count_statsd Legacy ID metricCount.statsd Metric Type gauge Unit number Description The number of StatsD custom metrics. Additional Notes sysdig_container_up Prometheus ID sysdig_container_up Legacy ID uptime Metric Type gauge Unit number Description The percentage of time the selected entity was down during the visualized time sample. Additional Notes The metric reflects the state of the container. ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/container/"},{"id":383,"title":"Custom Events","content":"Custom Event visibility is restricted to the same team from which the custom event was sent.\nThe Sysdig Monitor Slackbot named Sysdigbot allows you to post Custom Events directly to the Sysdig Cloud through Slack messages.\nUse CasesCustom events can give visibility in the following use cases.\nCI/CD pipelines can include build information in custom events. When visualized using the event overlay, users can understand important metrics before and after a deploy. Terraform can be configured to post a custom event upon running terraform apply, allowing you to trace infrastructure changes alongside metrics. Custom Events can be included in tasks or jobs in order to understand when and where a failure has occurred. Custom Events can be included in a systemd unit file to track how often a service has restarted. Use a custom controller or an operator in Kubernetes to listen for certain kubernetes events and send a custom event to Sysdig Monitor Create a Custom EventSend Custom Events with PythonThe SDCClient can be used to send arbitrary custom events to Sysdig Monitor. This client acts as a wrapper around the Sysdig Monitor Rest API, exposing most of the REST API functions through the Python interface.\nfrom sdcclient import SdMonitorClient # Replace sdc_url with region URL sdclient = SdMonitorClient(token=\u0026#34;\u0026lt;sysdig_api_token\u0026gt;\u0026#34;, sdc_url=\u0026#34;https://app.sysdigcloud.com\u0026#34;) # Send custom event print(sdcclient.post_event(\u0026#39;sample_custom_event\u0026#39;)) # Send custom event with description, severity, scope, and tags print(sdclient.post_event(name=\u0026#39;Payment Service Restart\u0026#39;, description=\u0026#34;Payment Service has been restarted\u0026#34;, severity=\u0026#34;LOW\u0026#34;, tags={\u0026#34;service\u0026#34;:\u0026#34;payment\u0026#34;}, event_filter=\u0026#39;component = \u0026#34;frontend\u0026#34; and application = \u0026#34;loadbalancer\u0026#34;\u0026#39;)) Post a Custom Event for each CI/CD deploy with curlAlternatively, users can post custom events directly with the Sysdig Monitor API using a curl request.\n#!/bin/bash SDC_ACCESS_TOKEN=\u0026#39;626abc7-YOUR-TOKEN-HERE-3a3ghj432\u0026#39; ENDPOINT=\u0026#39;app.sysdigcloud.com\u0026#39; curl -X POST -s https://$ENDPOINT/api/v2/events \\ -H \u0026#39;Content-Type: application/json; charset=UTF-8\u0026#39; \\ -H \u0026#39;Accept: application/json, text/javascript, */*; q=0.01\u0026#39; -H \u0026#34;Authorization: Bearer ${SDC_ACCESS_TOKEN}\u0026#34; \\ --data-binary \u0026#39;{ \u0026#34;event\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Jenkins - start wordpress deploy\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;deploy\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;host.hostName = \\\u0026#34;ip-10-1-1-1\\\u0026#34; and build = \\\u0026#34;89\\\u0026#34;\u0026#34;, \u0026#34;scopeLabels\u0026#34;: {}, \u0026#34;severity\u0026#34;: \u0026#34;MEDIUM\u0026#34;, \u0026#34;source\u0026#34;: \u0026#34;jenkins\u0026#34;, \u0026#34;tags\u0026#34;: { \u0026#34;source\u0026#34;: \u0026#34;jenkins\u0026#34; } } }\u0026#39; See also Enable/Disable Event Data.\nSend a Custom Event when running Terraform ApplyUse custom events to track the creation of resources in Terraform. The creation of this elastic IP address will post a custom event to Sysdig Monitor that includes the dynamic public IP address.\nresource \u0026#34;aws_eip\u0026#34; \u0026#34;my_elastic_ip_address\u0026#34; { vpc = true provisioner \u0026#34;local-exec\u0026#34; { command = \u0026lt;\u0026lt;EOF curl -X POST -s https://$ENDPOINT/api/v2/events \\ -H \u0026#39;Content-Type: application/json; charset=UTF-8\u0026#39; \\ -H \u0026#39;Accept: application/json, text/javascript, */*; q=0.01\u0026#39; -H \u0026#34;Authorization: Bearer $SDC_ACCESS_TOKEN\u0026#34; \\ --data-binary \u0026#39;{ \u0026#34;event\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;elastic IP address provisioned with Terraform\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;elastic_ip:${self.public_ip} provisioned\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;aws_account = \\\u0026#34;1234-5678-9012\\\u0026#34; and region = \\\u0026#34;us-east-1\\\u0026#34;\u0026#34;, \u0026#34;scopeLabels\u0026#34;: {}, \u0026#34;severity\u0026#34;: \u0026#34;MEDIUM\u0026#34;, \u0026#34;source\u0026#34;: \u0026#34;terraform\u0026#34;, \u0026#34;tags\u0026#34;: { \u0026#34;source\u0026#34;: \u0026#34;terraform\u0026#34; } } }\u0026#39; EOF environment = { ENDPOINT = \u0026#34;app.sysdigcloud.com\u0026#34; SDC_ACCESS_TOKEN= \u0026#34;626abc7-YOUR-TOKEN-HERE-3a3ghj432\u0026#34; } } } Embed Custom Events into SystemD to monitor when a service restartsSystemD unit files can post a custom event to Sysdig Monitor whenever a service restarts.\n[Unit] Description=Program Foo After=network.target [Service] ExecStart=/path/to/programfoo Restart=always RestartSec=3 ExecStartPost=/bin/bash -c \u0026#39;curl -X POST -s https://app.sysdigcloud.com/api/v2/events \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer 626abc7-YOUR-TOKEN-HERE-3a3ghj432\u0026#34; \\ --data-binary \u0026#39;{ \u0026#34;event\u0026#34;: { \u0026#34;name\u0026#34;: \u0026#34;Program Foo was Restarted\u0026#34; } }\u0026#39; \u0026#39; [Install] WantedBy=multi-user.target ","url":"https://docs.sysdig.com/en/sysdig-monitor/custom-events/"},{"id":384,"title":"Dashboard Manager","content":"You can also create, manage and organize the dashboards using Dashboard Manager if you have the sufficient permissions to do so.\nAccess Dashboard Manager Log in to Sysdig Monitor.\nFrom the left navigation, select Dashboards \u0026gt; Dashboard Manager.\nThe Dashboard Manager appears.\nUse Dashboard ManagerYou can use the Dashboard Manager for the following:\nView all the dashboards that you have created, marked as favorite, and that your teams have shared with you. Access the list of Dashboards from the Library available to you. Create and Manage existing Dashboards. Perform bulk operations on Dashboards. In Dashboard Manager, dashboards are presented in a table.\nThe table has four tabs:\nAll Dashboards: Here, you can find every dashboard for which you have visibility. Visibility may be restricted by your RBAC role and zone. My Dashboards: Here, you find dashboards created by you. Shared by My Team: Here, you can find dashboards that have been shared with your team. Dashboard Library: Here, you can find templates from the dashboard library. The dashboard tables are organized into columns:\nFavorite: Select the start to add the dashboard to My Favorites, where it can be accessed quickly from the left navigation pane. Name: The dashboard name. Visibility: The visibility of the dashboard. Dashboards can be private, shared with a team, and over publicly accessible via a url. Hover over the icon in this column to see visibility details. Popularity: This bar indicates the popularity of the dashboard within your team. Search DashboardsYou can search dashboards by dashboard name, panel name, dashboard description, and metric name. When you perform a search, the Matched by column will appear to determine which criteria were matched.\nThe search bar uses fuzzy search. This means you may find a dashboard even when the search term is not an exact match. To find a match, our search checks:\nThe name of the dashboard. The name of metrics used in the dashboard panels. Dashboard Search ResultsNavigating to a dashboard after search reveals which panels match the search.\nIf you open a dashboard and search again, you can match by the name of labels on the aforementioned metrics.\nFilter DashboardsYou can filter dashboards by groups and authors.\nEvery dashboard starts in the default group.\nGroup a DashboardTo change a dashboard\u0026rsquo;s group:\nLog in to Sysdig Secure.\nFrom the left navigation, select Dashboards \u0026gt; Dashboard Manager.\nFind a dashboard for which you have edit permission. For example, a dashboard you created.\nSelect the three-dot menu icon from the right side of the dashboard listing.\nSelect Move Dashboard to Group or go to Dashboard Settings and find the Group drop-down.\nSelect the desired group from the drop-down.\nSelect Save.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/dashboard-manager/"},{"id":385,"title":"Dockerfile Gate and Triggers Deep Dive","content":"There are implications regarding the availability and interpretation of data from different sources. Therefore, let us examine the input data for the gate and its impact on the triggers and parameters used.\nReview Docker documentation for more information on Dockerfiles themselves.\nEnd of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nThe \u0026ldquo;Dockerfile\u0026rdquo;The data that this gate operates on can come from two different sources:\nThe actual Dockerfile used to build an image, as provided by the user at the time of running sdc-cli image add \u0026lt;img ref\u0026gt; --dockerfile \u0026lt;filename\u0026gt;; or the corresponding API call to: POST /images?dockerfile=\nThe history from layers as encoded in the image itself (see docker history\u0026lt;img\u0026gt;for this output)\nAll images have data from history available, but data from the actual Dockerfile is only available when a user provides it. This also means that any images analyzed by automated alerts or the image analyzer will not have an actual Dockerfile.\nDifferences between Dockerfile and Docker HistoryActual Dockerfile\nFROM line is preserved, so the parent tag of the image is easily available\nInstruction checks are all against instructions created during the build for that exact image, not any parent images\nNote: When the actual_dockerfile_only parameter is set to true, all instructions from the parent image are ignored in policy processing. This may have some unexpected consequences depending on how your images are structured and layered (e.g. golden base images that establish common patterns of volumes, labels, healthchecks).\nCOPY/ADD instructions will maintain the actual values used\nMultistage-builds in that specific dockerfile will be visible with multiple FROM lines in the output\nDocker history data (with no Dockerfile provided)\nThis is a best-effort option and can catch some things, but not all.\nFROM line is not accurate, and will nearly always default to FROM scratch\nInstructions are processed from all layers in the image\nCOPY and ADD instructions are transformed into SHAs rather than the actual file path/name used at build-time\nMulti-stage builds are not tracked with multiple FROM lines, only the copy operations between the phases\nUsing the actual_dockerfile_only Parameter to Avoid Checking HistoryThe actual file vs history impacts the semantics of the Dockerfile gate\u0026rsquo;s triggers. To allow explicit control of the differences, most triggers in this gate includes a parameter: actual_dockerfile_onlythat if set to true or false will ensure the trigger check is only done on the source of data specified.\nIf actual_dockerfile_only = true, then the trigger will evaluate only if an actual Dockerfile is available for the image and will skip evaluation if not.\nIf actual_dockerfile_only is false or omitted, then the trigger will run on the actual Dockerfile if available, or the history data if the Dockerfile was not provided.\nUnderstanding the FROM LineIn the actual Dockerfile, the FROM instruction is preserved and available as used to build the image. However, in the history data, the FROM line will always be the very first FROM instruction used (to build the image and all of its dependent images). In this case, the value in the history will be omitted and the scanning engine will automatically infer a FROM-scratch line, which is logically inserted for this gate if the history does not contain an explicit FROM entry.\nThe files below show how this would play out.\nFor example, using the docker.io/jenkins/jenkins image:\nIMAGE CREATED CREATED BY SIZE COMMENT sha256:3b9c9666a66e53473c05a3c69eb2cb888a8268f76935eecc7530653cddc28981 11 hours ago /bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh 8.79kB \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh 3.96kB \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ENTRYPOINT [\u0026#34;/sbin/tini\u0026#34; \u0026#34;--\u0026#34; \u0026#34;/usr/local/bin/jenkins.sh\u0026#34;] 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) COPY file:dc942ca949bb159f81bbc954773b3491e433d2d3e3ef90bac80ecf48a313c9c9 in /bin/tini 529B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) COPY file:a8f986413b77bf4d88562b9d3a0dce98ab6e75403192aa4d4153fb41f450843d in /usr/local/bin/jenkins.sh 1.45kB \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) COPY file:55594d9d2aed007553a6743a43039b1a48b30527f8fb991ad93e1fd5b1298f60 in /usr/local/bin/jenkins-support 6.12kB \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) USER jenkins 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ENV COPY_REFERENCE_FILE_LOG=/var/jenkins_home/copy_reference_file.log 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) EXPOSE 50000 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) EXPOSE 8080 0B \u0026lt;missing\u0026gt; 11 hours ago |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c chown -R ${user} \u0026#34;$JENKINS_HOME\u0026#34; /usr/share/jenkins/ref 328B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ENV JENKINS_UC=https://updates.jenkins.io 0B \u0026lt;missing\u0026gt; 11 hours ago |9 JENKINS_SHA=e026221efcec9528498019b6c1581cca70fe9c3f6b10303777d85c6699bca0e4 JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war \u0026amp;\u0026amp; echo \u0026#34;${JENKINS_SHA} /usr/share/jenkins/jenkins.war\u0026#34; | sha256sum -c - 76MB \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/2.161/jenkins-war-2.161.war 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ENV JENKINS_VERSION=2.161 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG JENKINS_VERSION 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) COPY file:c84b91c835048a52bb864c1f4662607c56befe3c4b1520b0ea94633103a4554f in /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy 328B \u0026lt;missing\u0026gt; 11 hours ago |7 TINI_VERSION=v0.16.1 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini \u0026amp;\u0026amp; curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc \u0026amp;\u0026amp; gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg \u0026amp;\u0026amp; gpg --verify /sbin/tini.asc \u0026amp;\u0026amp; rm -rf /sbin/tini.asc /root/.gnupg \u0026amp;\u0026amp; chmod +x /sbin/tini 866kB \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) COPY file:653491cb486e752a4c2b4b407a46ec75646a54eabb597634b25c7c2b82a31424 in /var/jenkins_home/tini_pub.gpg 7.15kB \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG TINI_VERSION=v0.16.1 0B \u0026lt;missing\u0026gt; 11 hours ago |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p /usr/share/jenkins/ref/init.groovy.d 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) VOLUME [/var/jenkins_home] 0B \u0026lt;missing\u0026gt; 11 hours ago |6 agent_port=50000 gid=1000 group=jenkins http_port=8080 uid=1000 user=jenkins /bin/sh -c mkdir -p $JENKINS_HOME \u0026amp;\u0026amp; chown ${uid}:${gid} $JENKINS_HOME \u0026amp;\u0026amp; groupadd -g ${gid} ${group} \u0026amp;\u0026amp; useradd -d \u0026#34;$JENKINS_HOME\u0026#34; -u ${uid} -g ${gid} -m -s /bin/bash ${user} 328kB \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ENV JENKINS_SLAVE_AGENT_PORT=50000 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ENV JENKINS_HOME=/var/jenkins_home 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG JENKINS_HOME=/var/jenkins_home 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG agent_port=50000 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG http_port=8080 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG gid=1000 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG uid=1000 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG group=jenkins 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c #(nop) ARG user=jenkins 0B \u0026lt;missing\u0026gt; 11 hours ago /bin/sh -c apt-get update \u0026amp;\u0026amp; apt-get install -y git curl \u0026amp;\u0026amp; rm -rf /var/lib/apt/lists/* 0B \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c set -ex; if [ ! -d /usr/share/man/man1 ]; then mkdir -p /usr/share/man/man1; fi; apt-get update; apt-get install -y --no-install-recommends openjdk-8-jdk=\u0026#34;$JAVA_DEBIAN_VERSION\u0026#34; ; rm -rf /var/lib/apt/lists/*; [ \u0026#34;$(readlink -f \u0026#34;$JAVA_HOME\u0026#34;)\u0026#34; = \u0026#34;$(docker-java-home)\u0026#34; ]; update-alternatives --get-selections | awk -v home=\u0026#34;$(readlink -f \u0026#34;$JAVA_HOME\u0026#34;)\u0026#34; \u0026#39;index($3, home) == 1 { $2 = \u0026#34;manual\u0026#34;; print | \u0026#34;update-alternatives --set-selections\u0026#34; }\u0026#39;; update-alternatives --query java | grep -q \u0026#39;Status: manual\u0026#39; 348MB \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c #(nop) ENV JAVA_DEBIAN_VERSION=8u181-b13-2~deb9u1 0B \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c #(nop) ENV JAVA_VERSION=8u181 0B \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c #(nop) ENV JAVA_HOME=/docker-java-home 0B \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c ln -svT \u0026#34;/usr/lib/jvm/java-8-openjdk-$(dpkg --print-architecture)\u0026#34; /docker-java-home 33B \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c { echo \u0026#39;#!/bin/sh\u0026#39;; echo \u0026#39;set -e\u0026#39;; echo; echo \u0026#39;dirname \u0026#34;$(dirname \u0026#34;$(readlink -f \u0026#34;$(which javac || which java)\u0026#34;)\u0026#34;)\u0026#34;\u0026#39;; } \u0026gt; /usr/local/bin/docker-java-home \u0026amp;\u0026amp; chmod +x /usr/local/bin/docker-java-home 87B \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c #(nop) ENV LANG=C.UTF-8 0B \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c apt-get update \u0026amp;\u0026amp; apt-get install -y --no-install-recommends bzip2 unzip xz-utils \u0026amp;\u0026amp; rm -rf /var/lib/apt/lists/* 2.21MB \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c apt-get update \u0026amp;\u0026amp; apt-get install -y --no-install-recommends bzr git mercurial openssh-client subversion procps \u0026amp;\u0026amp; rm -rf /var/lib/apt/lists/* 142MB \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c set -ex; if ! command -v gpg \u0026gt; /dev/null; then apt-get update; apt-get install -y --no-install-recommends gnupg dirmngr ; rm -rf /var/lib/apt/lists/*; fi 7.81MB \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c apt-get update \u0026amp;\u0026amp; apt-get install -y --no-install-recommends ca-certificates curl netbase wget \u0026amp;\u0026amp; rm -rf /var/lib/apt/lists/* 23.2MB \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c #(nop) CMD [\u0026#34;bash\u0026#34;] 0B \u0026lt;missing\u0026gt; 3 weeks ago /bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in / 101MB Where the actual dockerfile for that image is:\nFROM openjdk:8-jdk-stretch RUN apt-get update \u0026amp;\u0026amp; apt-get install -y git curl \u0026amp;\u0026amp; rm -rf /var/lib/apt/lists/* ARG user=jenkins ARG group=jenkins ARG uid=1000 ARG gid=1000 ARG http_port=8080 ARG agent_port=50000 ARG JENKINS_HOME=/var/jenkins_home ENV JENKINS_HOME $JENKINS_HOME ENV JENKINS_SLAVE_AGENT_PORT ${agent_port} # Jenkins is run with user `jenkins`, uid = 1000 # If you bind mount a volume from the host or a data container, # ensure you use the same uid RUN mkdir -p $JENKINS_HOME \\ \u0026amp;\u0026amp; chown ${uid}:${gid} $JENKINS_HOME \\ \u0026amp;\u0026amp; groupadd -g ${gid} ${group} \\ \u0026amp;\u0026amp; useradd -d \u0026#34;$JENKINS_HOME\u0026#34; -u ${uid} -g ${gid} -m -s /bin/bash ${user} # Jenkins home directory is a volume, so configuration and build history # can be persisted and survive image upgrades VOLUME $JENKINS_HOME # `/usr/share/jenkins/ref/` contains all reference configuration we want # to set on a fresh new installation. Use it to bundle additional plugins # or config file with your custom jenkins Docker image. RUN mkdir -p /usr/share/jenkins/ref/init.groovy.d # Use tini as subreaper in Docker container to adopt zombie processes ARG TINI_VERSION=v0.16.1 COPY tini_pub.gpg ${JENKINS_HOME}/tini_pub.gpg RUN curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini \\ \u0026amp;\u0026amp; curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc \\ \u0026amp;\u0026amp; gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg \\ \u0026amp;\u0026amp; gpg --verify /sbin/tini.asc \\ \u0026amp;\u0026amp; rm -rf /sbin/tini.asc /root/.gnupg \\ \u0026amp;\u0026amp; chmod +x /sbin/tini COPY init.groovy /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy # jenkins version being bundled in this docker image ARG JENKINS_VERSION ENV JENKINS_VERSION ${JENKINS_VERSION:-2.121.1} # jenkins.war checksum, download will be validated using it ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919 # Can be used to customize where jenkins.war get downloaded from ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/${JENKINS_VERSION}/jenkins-war-${JENKINS_VERSION}.war # could use ADD but this one does not check Last-Modified header neither does it allow to control checksum # see https://github.com/docker/docker/issues/8331 RUN curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war \\ \u0026amp;\u0026amp; echo \u0026#34;${JENKINS_SHA} /usr/share/jenkins/jenkins.war\u0026#34; | sha256sum -c - ENV JENKINS_UC https://updates.jenkins.io ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals RUN chown -R ${user} \u0026#34;$JENKINS_HOME\u0026#34; /usr/share/jenkins/ref # for main web interface: EXPOSE ${http_port} # will be used by attached slave agents: EXPOSE ${agent_port} ENV COPY_REFERENCE_FILE_LOG $JENKINS_HOME/copy_reference_file.log USER ${user} COPY jenkins-support /usr/local/bin/jenkins-support COPY jenkins.sh /usr/local/bin/jenkins.sh COPY tini-shim.sh /bin/tini ENTRYPOINT [\u0026#34;/sbin/tini\u0026#34;, \u0026#34;--\u0026#34;, \u0026#34;/usr/local/bin/jenkins.sh\u0026#34;] # from a derived Dockerfile, can use `RUN plugins.sh active.txt` to setup /usr/share/jenkins/ref/plugins from a support bundle COPY plugins.sh /usr/local/bin/plugins.sh COPY install-plugins.sh /usr/local/bin/install-plugins.sh Where the actual Dockerfile for that image is:\nFROM openjdk:8-jdk-stretch RUN apt-get update \u0026amp;\u0026amp; apt-get install -y git curl \u0026amp;\u0026amp; rm -rf /var/lib/apt/lists/* ARG user=jenkins ARG group=jenkins ARG uid=1000 ARG gid=1000 ARG http_port=8080 ARG agent_port=50000 ARG JENKINS_HOME=/var/jenkins_home ENV JENKINS_HOME $JENKINS_HOME ENV JENKINS_SLAVE_AGENT_PORT ${agent_port} # Jenkins is run with user `jenkins`, uid = 1000 # If you bind mount a volume from the host or a data container, # ensure you use the same uid RUN mkdir -p $JENKINS_HOME \\ \u0026amp;\u0026amp; chown ${uid}:${gid} $JENKINS_HOME \\ \u0026amp;\u0026amp; groupadd -g ${gid} ${group} \\ \u0026amp;\u0026amp; useradd -d \u0026#34;$JENKINS_HOME\u0026#34; -u ${uid} -g ${gid} -m -s /bin/bash ${user} # Jenkins home directory is a volume, so configuration and build history # can be persisted and survive image upgrades VOLUME $JENKINS_HOME # `/usr/share/jenkins/ref/` contains all reference configuration we want # to set on a fresh new installation. Use it to bundle additional plugins # or config file with your custom jenkins Docker image. RUN mkdir -p /usr/share/jenkins/ref/init.groovy.d # Use tini as subreaper in Docker container to adopt zombie processes ARG TINI_VERSION=v0.16.1 COPY tini_pub.gpg ${JENKINS_HOME}/tini_pub.gpg RUN curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture) -o /sbin/tini \\ \u0026amp;\u0026amp; curl -fsSL https://github.com/krallin/tini/releases/download/${TINI_VERSION}/tini-static-$(dpkg --print-architecture).asc -o /sbin/tini.asc \\ \u0026amp;\u0026amp; gpg --no-tty --import ${JENKINS_HOME}/tini_pub.gpg \\ \u0026amp;\u0026amp; gpg --verify /sbin/tini.asc \\ \u0026amp;\u0026amp; rm -rf /sbin/tini.asc /root/.gnupg \\ \u0026amp;\u0026amp; chmod +x /sbin/tini COPY init.groovy /usr/share/jenkins/ref/init.groovy.d/tcp-slave-agent-port.groovy # jenkins version being bundled in this docker image ARG JENKINS_VERSION ENV JENKINS_VERSION ${JENKINS_VERSION:-2.121.1} # jenkins.war checksum, download will be validated using it ARG JENKINS_SHA=5bb075b81a3929ceada4e960049e37df5f15a1e3cfc9dc24d749858e70b48919 # Can be used to customize where jenkins.war get downloaded from ARG JENKINS_URL=https://repo.jenkins-ci.org/public/org/jenkins-ci/main/jenkins-war/${JENKINS_VERSION}/jenkins-war-${JENKINS_VERSION}.war # could use ADD but this one does not check Last-Modified header neither does it allow to control checksum # see https://github.com/docker/docker/issues/8331 RUN curl -fsSL ${JENKINS_URL} -o /usr/share/jenkins/jenkins.war \\ \u0026amp;\u0026amp; echo \u0026#34;${JENKINS_SHA} /usr/share/jenkins/jenkins.war\u0026#34; | sha256sum -c - ENV JENKINS_UC https://updates.jenkins.io ENV JENKINS_UC_EXPERIMENTAL=https://updates.jenkins.io/experimental ENV JENKINS_INCREMENTALS_REPO_MIRROR=https://repo.jenkins-ci.org/incrementals RUN chown -R ${user} \u0026#34;$JENKINS_HOME\u0026#34; /usr/share/jenkins/ref # for main web interface: EXPOSE ${http_port} # will be used by attached slave agents: EXPOSE ${agent_port} ENV COPY_REFERENCE_FILE_LOG $JENKINS_HOME/copy_reference_file.log USER ${user} COPY jenkins-support /usr/local/bin/jenkins-support COPY jenkins.sh /usr/local/bin/jenkins.sh COPY tini-shim.sh /bin/tini ENTRYPOINT [\u0026#34;/sbin/tini\u0026#34;, \u0026#34;--\u0026#34;, \u0026#34;/usr/local/bin/jenkins.sh\u0026#34;] # from a derived Dockerfile, can use `RUN plugins.sh active.txt` to setup /usr/share/jenkins/ref/plugins from a support bundle COPY plugins.sh /usr/local/bin/plugins.sh COPY install-plugins.sh /usr/local/bin/install-plugins.sh The scanning engine will detect the history/\u0026ldquo;dockerfile\u0026rdquo; as follows:\n[ { \u0026#34;Size\u0026#34; : 45323792, \u0026#34;Tags\u0026#34; : [], \u0026#34;Comment\u0026#34; : \u0026#34;\u0026#34;, \u0026#34;Id\u0026#34; : \u0026#34;sha256:cd8eada9c7bb496eb685fc6d2198c33db7cb05daf0fde42e4cf5bf0127cbdf38\u0026#34;, \u0026#34;Created\u0026#34; : \u0026#34;2018-12-28T23:29:37.981962131Z\u0026#34;, \u0026#34;CreatedBy\u0026#34; : \u0026#34;/bin/sh -c #(nop) ADD file:da71baf0d22cb2ede91c5e3ff959607e47459a9d7bda220a62a3da362b0e59ea in / \u0026#34; }, { \u0026#34;Size\u0026#34; : 0, \u0026#34;Tags\u0026#34; : [], \u0026#34;Comment\u0026#34; : \u0026#34;\u0026#34;, \u0026#34;Id\u0026#34; : \u0026#34;\u0026lt;missing\u0026gt;\u0026#34;, \u0026#34;Created\u0026#34; : \u0026#34;2018-12-28T23:29:38.226681736Z\u0026#34;, \u0026#34;CreatedBy\u0026#34; : \u0026#34;/bin/sh -c #(nop) CMD [\\\u0026#34;bash\\\u0026#34;]\u0026#34; }, { \u0026#34;Size\u0026#34; : 10780911, \u0026#34;Comment\u0026#34; : \u0026#34;\u0026#34;, \u0026#34;Tags\u0026#34; : [], \u0026#34;CreatedBy\u0026#34; : \u0026#34;/bin/sh -c apt-get update \u0026amp;\u0026amp; apt-get install -y --no-install-recommends \\t\\tca-certificates \\t\\tcurl \\t\\tnetbase \\t\\twget \\t\u0026amp;\u0026amp; rm -rf /var/lib/apt/lists/*\u0026#34;, \u0026#34;Created\u0026#34; : \u0026#34;2018-12-29T00:04:28.920875483Z\u0026#34;, \u0026#34;Id\u0026#34; : \u0026#34;sha256:c2677faec825930a8844845f55454ee0495ceb5bea9fc904d5b3125de863dc1d\u0026#34; }, { \u0026#34;Comment\u0026#34; : \u0026#34;\u0026#34;, \u0026#34;Tags\u0026#34; : [], \u0026#34;Size\u0026#34; : 4340024, \u0026#34;CreatedBy\u0026#34; : \u0026#34;/bin/sh -c set -ex; \\tif ! command -v gpg \u0026gt; /dev/null; then \\t\\tapt-get update; \\t\\tapt-get install -y --no-install-recommends \\t\\t\\tgnupg \\t\\t\\tdirmngr \\t\\t; \\t\\trm -rf /var/lib/apt/lists/*; \\tfi\u0026#34;, \u0026#34;Created\u0026#34; : \u0026#34;2018-12-29T00:04:34.642152001Z\u0026#34;, \u0026#34;Id\u0026#34; : \u0026#34;sha256:fcce419a96b1219a265bf7a933d66b585a6f8d73448533f3833c73ad49fb5e88\u0026#34; }, { \u0026#34;Size\u0026#34; : 50062697, \u0026#34;Tags\u0026#34; : [], \u0026#34;Comment\u0026#34; : \u0026#34;\u0026#34;, \u0026#34;Id\u0026#34; : \u0026#34;sha256:045b51e26e750443c84216071a1367a7aae0b76245800629dc04934628b4b1ea\u0026#34;, \u0026#34;CreatedBy\u0026#34; : \u0026#34;/bin/sh -c apt-get update \u0026amp;\u0026amp; apt-get install -y --no-install-recommends \\t\\tbzr \\t\\tgit \\t\\tmercurial \\t\\topenssh-client \\t\\tsubversion \\t\\t\\t\\tprocps \\t\u0026amp;\u0026amp; rm -rf /var/lib/apt/lists/*\u0026#34;, \u0026#34;Created\u0026#34; : \u0026#34;2018-12-29T00:04:59.676112605Z\u0026#34; }, ... \u0026lt;truncated for brevity\u0026gt; ... { \u0026#34;Tags\u0026#34; : [], \u0026#34;Comment\u0026#34; : \u0026#34;\u0026#34;, \u0026#34;Size\u0026#34; : 0, \u0026#34;Id\u0026#34; : \u0026#34;\u0026lt;missing\u0026gt;\u0026#34;, \u0026#34;CreatedBy\u0026#34; : \u0026#34;/bin/sh -c #(nop) ENTRYPOINT [\\\u0026#34;/sbin/tini\\\u0026#34; \\\u0026#34;--\\\u0026#34; \\\u0026#34;/usr/local/bin/jenkins.sh\\\u0026#34;]\u0026#34;, \u0026#34;Created\u0026#34; : \u0026#34;2019-01-21T08:56:30.737221895Z\u0026#34; }, { \u0026#34;Size\u0026#34; : 1549, \u0026#34;Tags\u0026#34; : [], \u0026#34;Comment\u0026#34; : \u0026#34;\u0026#34;, \u0026#34;Id\u0026#34; : \u0026#34;sha256:283cd3aba8691a3b9d22d923de66243b105758e74de7d9469fe55a6a58aeee30\u0026#34;, \u0026#34;Created\u0026#34; : \u0026#34;2019-01-21T08:56:32.015667468Z\u0026#34;, \u0026#34;CreatedBy\u0026#34; : \u0026#34;/bin/sh -c #(nop) COPY file:f97999fac8a63cf8b635a54ea84a2bc95ae3da4d81ab55267c92b28b502d8812 in /usr/local/bin/plugins.sh \u0026#34; }, { \u0026#34;Comment\u0026#34; : \u0026#34;\u0026#34;, \u0026#34;Tags\u0026#34; : [], \u0026#34;Size\u0026#34; : 3079, \u0026#34;Created\u0026#34; : \u0026#34;2019-01-21T08:56:33.158854485Z\u0026#34;, \u0026#34;CreatedBy\u0026#34; : \u0026#34;/bin/sh -c #(nop) COPY file:3a15c25533fd87983edc33758f62af7b543ccc3ce9dd570e473eb0702f5f298e in /usr/local/bin/install-plugins.sh \u0026#34;, \u0026#34;Id\u0026#34; : \u0026#34;sha256:b0ce8ab5a5a7da5d762f25af970f4423b98437a8318cb9852c3f21354cbf914f\u0026#34; } ] TriggersThis section provides details on four triggers.\nTrigger: instructionThis trigger evaluates instructions found in the \u0026ldquo;dockerfile\u0026rdquo;.\nParameters\nactual_dockerfile_only (optional).\ninstruction: The dockerfile instruction to check against. One of:\nADD\nARG\nCOPY\nCMD\nENTRYPOINT\nENV\nEXPOSE\nFROM\nHEALTHCHECK\nLABEL\nMAINTAINER\nONBUILD\nUSER\nRUN\nSHELL\nSTOPSIGNAL\nVOLUME\nWORKDIR\ncheck: The comparison/evaluation to perform. One of: =, != , exists, not_exists, like, not_like, in, not_in\nvalue (optional): A string value to compare against, if applicable\nExamplesEnsure an image has a HEALTHCHECK defined in the image. Warn if not found\n{ \u0026#34;gate\u0026#34;: \u0026#34;dockerfile\u0026#34;, \u0026#34;trigger\u0026#34;: \u0026#34;instruction\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;warn\u0026#34;, \u0026#34;parameters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;instruction\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;HEALTHCHECK\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;check\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;not_exists\u0026#34; } ] } Check for AWS environment variables set\n{ \u0026#34;gate\u0026#34;: \u0026#34;dockerfile\u0026#34;, \u0026#34;trigger\u0026#34;: \u0026#34;instruction\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;stop\u0026#34;, \u0026#34;parameters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;instruction\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;ENV\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;check\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;like\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;value\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;AWS_.*KEY\u0026#34; } ] } Trigger: effective_userThis trigger processes all USER directives in the Dockerfile or history to determine which user will be used to run the container by default (assuming no user is set explicitly at runtime). The detected value is then subject to a whitelist or blacklist filter depending on the configured parameters. Typically, this is used for blacklisting the root user.\nParameters\nactual_dockerfile_only (optional)\nusers: A string with a comma-delimited list of username to check for\ntype: The type of check to perform. One of: blacklist or whitelist. This determines how the value of the users parameter is interpreted.\nExamplesBlacklist root user\n{ \u0026#34;gate\u0026#34;: \u0026#34;dockerfile\u0026#34;, \u0026#34;trigger\u0026#34;: \u0026#34;effective_user\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;stop\u0026#34;, \u0026#34;parameters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;users\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;root\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;blacklist\u0026#34; } ] } Blacklist root user but only if set in actual Dockerfile, not inherited from parent image\n{ \u0026#34;gate\u0026#34;: \u0026#34;dockerfile\u0026#34;, \u0026#34;trigger\u0026#34;: \u0026#34;effective_user\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;stop\u0026#34;, \u0026#34;parameters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;users\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;root\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;blacklist\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;actual_dockerfile_only\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;true\u0026#34; } ] } Warn if the user is not either \u0026ldquo;nginx\u0026rdquo; or \u0026ldquo;jenkins\u0026rdquo;\n{ \u0026#34;gate\u0026#34;: \u0026#34;dockerfile\u0026#34;, \u0026#34;trigger\u0026#34;: \u0026#34;effective_user\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;warn\u0026#34;, \u0026#34;parameters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;users\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;nginx,jenkins\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;whitelist\u0026#34; } ] } Trigger: exposed_portsThis trigger allows checks on the way the image was added, firing if the Dockerfile was not explicitly provided at analysis time. This is useful in identifying and qualifying other trigger matches.\nParameters\nactual_dockerfile_only (optional)\nports: String of comma-delimited port numbers to be checked\ntype: The type of check to perform. One of: blacklist or whitelist. This determines how the value of the users parameter is interpreted.\nExamplesAllow only ports 80 and 443. Trigger will fire on any port defined to be exposed that is not 80 or 443\n{ \u0026#34;gate\u0026#34;: \u0026#34;dockerfile\u0026#34;, \u0026#34;trigger\u0026#34;: \u0026#34;exposed_ports\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;warn\u0026#34;, \u0026#34;parameters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;ports\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;80,443\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;whitelist\u0026#34; } ] } Blacklist ports 21 (ftp), 22 (ssh), and 53 (dns) . Trigger will fire a match on ports 21, 22, 53 if found in EXPOSE directives\n{ \u0026#34;gate\u0026#34;: \u0026#34;dockerfile\u0026#34;, \u0026#34;trigger\u0026#34;: \u0026#34;exposed_ports\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;warn\u0026#34;, \u0026#34;parameters\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;ports\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;21,22,53\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;type\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;blacklist\u0026#34; } ] } Trigger: no_dockerfile_providedThis trigger allows checks on the way the image was added, firing if the Dockerfile was not explicitly provided at analysis time. This is useful in identifying and qualifying other trigger matches.\nParameters\nNone\nExamplesRaise a warning if no Dockerfile was provided at analysis time\n{ \u0026#34;gate\u0026#34;: \u0026#34;dockerfile\u0026#34;, \u0026#34;trigger\u0026#34;: \u0026#34;no_dockerfile_provided\u0026#34;, \u0026#34;action\u0026#34;: \u0026#34;warn\u0026#34;, \u0026#34;parameters\u0026#34;: [] } ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/manage-scanning-policies/dockerfile-gate-and-triggers-deep-dive/"},{"id":386,"title":"Elastic Cloud Compute (EC2)","content":"aws.ec2.CPUCreditBalanceThe CPU credit balance of an instance, based on what has accrued since it started. For more information, refer to the Elastic Compute Cloud metric definition table.\nMetadata Description Metric Type Gauge Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.ec2.CPUCreditUsageThe CPU credit usage by the instance. For more information, refer to the Elastic Compute Cloud metric definition documentation.\nMetadata Description Metric Type Gauge Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.ec2.CPUUtilizationThe percentage of allocated EC2 compute units currently in use on the instance. For more information, refer to the Elastic Compute Cloud metric definition documentation.\nThis metric identifies the processing power required to run an application upon a selected instance.\nMetadata Description Metric Type Gauge Value Type % Segment By CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.ec2.DiskReadBytesThe total bytes read from all ephemeral disks available to the instance. This metric is used to determine the volume of the data the application reads from the disk and can be used to determine the speed of the application.\nThe number reported is the number of bytes received during a specified period. For a basic (five-minute) monitoring, divide this number by 300 to find Bytes/second. For a detailed (one-minute) monitoring, divide it by 60.\nFor more information, refer to the Elastic Compute Cloud metric definition documentation.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.ec2.DiskReadOpsTotal completed read operations from all ephemeral disks available to the instance in a specified period of time. For more information, refer to the Elastic Compute Cloud metric definition documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.ec2.DiskWriteBytesIt is the total bytes written to all ephemeral disks available to the instance. This metric is used to determine the volume of the data the application writes to the disk and can be used to determine the speed of the application.\nThe number reported is the number of bytes received during a specified period. For a basic (five-minute) monitoring, divide this number by 300 to find Bytes/second. For a detailed (one-minute) monitoring, divide it by 60.\nFor more information, refer to the Elastic Compute Cloud metric definition documentation.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.ec2.DiskWriteOpsThe completed write operations to all ephemeral disks available to the instance in a specified period of time. If your instance uses Amazon EBS volumes, see Amazon EBS Metrics. For more information, refer to the Elastic Compute Cloud metric definition documentation.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.ec2.NetworkInThe number of bytes received on all network interfaces by the instance. For more information, refer to the Elastic Compute Cloud metric definition documentation.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.ec2.NetworkOutThe number of bytes sent out on all network interfaces by the instance. For more information, refer to the Elastic Compute Cloud metric definition documentation.\nThis metric identifies the volume of outgoing network traffic to an application on a single instance.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/sysdig-monitor/aws-metrics-legacy/elastic-cloud-compute-ec2/"},{"id":387,"title":"Event Alerts","content":"Event Alerts support multiple segmentation labels. An alert is generated for each segment.\nDefining an Event AlertTo define an Event Alert:\nLog in to Sysdig Monitor.\nSelect Alerts.\nThe Alert list appears.\nSelect New Alert \u0026gt; Event.\nThe Alerts Editor opens.\nDefine your alert. For advice, see Guidelines.\nTo save your alert, click Save.\nGuidelinesWhen you define an Event Alert:\nSpecify a meaningful filter text to count the number of related events.\nSet a severity level for your alert. The order of priority of High, Medium, Low and Info are reflected in the Alert list.\nYou can use severity as a criterion when creating events and alerts. For example, you can receive a notification when there are more than 10 high severity events. Filter by one or more Event Sources to be considered by the alert. Predefined options are included for infrastructure event sources, such as kubernetes, docker, and containerd, but you can freely specify other values to match custom event sources. You can also view custom tags on the Event overlay.\nConfigure Thresholds for the total number of events within a specified time range that will trigger the alert rule.\nSet a meaningful name and description to help recipients easily identify the alert.\nConfigure ScopeFilter the environment on which this alert will apply. Use advanced operators to include, exclude, or pattern-match groups, tags, and entities. You can also create alerts directly from Explore and Dashboards to automatically populate this scope.\nIn this example, failing to schedule a pod in a default namespace triggers an alert.\nFrequency of Alert Rule EvaluationThe Alert Editor automatically displays the time window that works best with your alert rule. Every data point in the alert preview corresponds with an evaluation of an alert rule.\nThe frequency at which an alert rule is evaluated depends on the Count Over Last specified in its query:\nCount Over Last Frequency of Alert Rule Evaluation up to 2h 1m up to 1d 10m up to 14d 1h up to 60d 1d 60d+ Not Supported For example:\nIf you set up an alert query with a Count Over Last of 40 minutes, the rule evaluates every 1 minutes If you set up a query with a Count Over Last of 4 hours, the alert evaluates every 10 minutes. To view time series data older than the recommended window, click Explore Historical Data in the top right corner of Alert Editor. This will populate a PromQL Query in the Explore module with your current settings.\nNotifications for when an alert is unresolved cannot be sent more frequently than the alert rule’s evaluation interval and must be a multiple of this interval. For example, if an alert rule is evaluated every 10 minutes, re-notifications can only occur at multiples of the evaluation frequency, such as 20 minutes, 30 minutes, and so forth.\nConfigure TriggerDefine the threshold and time window for assessing the alert condition. Single alert fires an alert for your entire scope, while multiple alert fires if any or every segment breach the threshold at once.\nIf the number of events triggered in the monitored entity is greater than 5 for the last 10 minutes, recipients will be notified through the selected channel.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/event-alerts/"},{"id":388,"title":"Explore","content":"Grouping controls how entities are organized in Explore. Grouping is fully customizable by logical layers, such as containers, Kubernetes clusters, and services.\nMetrics ExplorerSysdig Monitor automatically discovers your stack and presents pre-built views in Metric Explorer. Use Metrics Explorer for advanced metric exploration.\nBy leveraging the core functionalities (grouping, scope tree, metrics, and graphing) of Explore and interactive metric and label filtering, Metrics Explorer provides you the ability to:\nDiscover and explore metrics available for a given scope and build infrastructure views quickly.\nGraph multiple metrics simultaneously for correlation. For example, CPU usage vs CPU limits.\nView ungrouped queries by default, showing the individual time series for a metric.\nView metrics that are logically categorized with a metric namespace prefix.\nView metrics at high resolution. For example, a 1-hour view now shows data at 10-second resolution instead of 1 minute.\nThe out-of-the-box groupings, coupled with the ability for you to define your own, offer an intuitive and context-aware way to drill-down metrics. For example:\nClusters \u0026amp; Namespaces will build a tree with: Cluster Name \u0026gt; Namespace \u0026gt; Deployment \u0026gt; Pod Name \u0026gt; Container Image\nHosts \u0026amp; Containers will build a tree with: Hostname \u0026gt; Container ID\nNodes will build a tree with: Cluster Name \u0026gt; Node Name \u0026gt; Pod Name \u0026gt; Container ID\nPromQL Query ExplorerUse the PromQL Query Explorer to build and run your PromQL queries. It\u0026rsquo;s the perfect starting point for investigations if you are familiar with PromQL.\nBy leveraging the power provided by the PromQL language, PromQL Query Explorer offers the following:\nCraft complex PromQL queries. For users, this translates into an enhanced Prometheus-like query experience. Query metrics leveraging all PromQL functions and operators. Write up to 5 distinct queries and visualize them as a time chart. Explore PromQL labels and values in a table-like view. Identify common PromQL labels across queries, which is useful for aggregations if you choose to combine several metrics in a single query. PromQL LibraryTo ease the learning curve of PromQL, Sysdig provides a set of curated examples, called PromQL Library. It helps users perform complex queries against metrics with one click and get insight into their infrastructure problems which was not previously possible with Sysdig querying. For example, identify containers \u0026gt; 90% limit and counting pods per namespace.\nYou have the following categories currently in the PromQL Library:\nKubernetes Infrastructure Troubleshooting PromQL 101 ","url":"https://docs.sysdig.com/en/sysdig-monitor/explore/"},{"id":389,"title":"Forwarding to Elasticsearch","content":"Prerequisites Event forwards originate from region-specific IPs. For the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle event forwarding.\nYou must have an instance of Elasticsearch running and permissions to access it.\nDatastreams are currently not supported. Make sure to configure your Elasticsearch index template with the “datastream” option set to off. That way, data will be stored on indices.\nConfigure Standard Integration Log in to Sysdig Secure as Admin and navigate to Integrations \u0026gt; Add Integrations.\nSearch and choose Elasticsearch.\nConfigure the required options:\nIntegration Name: Define an integration name.\nEndpoint: Enter the specific Elasticsearch instance where the data will be saved. For ES Cloud and ES Cloud Enterprise, the endpoint can be found under the Deployments page: Index Name: Enter the name of the index under which the data will be stored. See What is an Elasticsearch Index? for details.\nAuthentication: Choose a method to authenticate API calls. Basic authentication uses the most common format of username:password. The given user must have write privileges in Elasticsearch; you can query the available users.\nSecret: If you selected Basic authentication: specify the username:password of a user with write privileges.\nLabels and fields format: Choose Original format or Key value pairs. See Labels and Fields Format\nData to Send: Select from the drop-down the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled.\nAllow insecure connections: Check the box if you wish to skip certificate validations when using HTTPS. You may wish to do this if you use self-signed certificates.\nToggle the Enabled switch as necessary. You will need to Test Integration with the button below before enabling the integration.\nClick Save.\nLabels and Fields FormatThere are two formatting options for Elasticsearch event forwarding.\nOriginal format sends events in the format shown in Event Forwarding. This format is not compatible with dynamic mapping.\nKey value pairs sends events labels and content.field objects, such as {\u0026quot;foo\u0026quot;: \u0026quot;bar\u0026quot;, ...}, as arrays of objects: [{\u0026quot;key\u0026quot;: \u0026quot;foo\u0026quot;, \u0026quot;value\u0026quot;: \u0026quot;value\u0026quot;}, ...]. This format is compatible with dynamic mapping.\nKey value pairs is recommended for Runtime Policy Events or Activity Audit. If you prefer using Original format for these types of events, we recommend you disable dynamic mapping in Elasticsearch.\nTimestamp MappingTo handle timestamps directly in Elasticsearch, you might want to map them to the appropriate field type. Timestamps have nanosecond resolution in Sysdig and they are available both in epoch timestamp and in RFC 3339 format.\nThe best approach is to use the date_nanos field type and define an explicit mapping in your Elasticsearch instance.\nYou will need to perform a PUT /\u0026lt;index\u0026gt;/_mapping API call with the index into which you are storing data, using the following payload:\n{ \u0026#34;properties\u0026#34;: { \u0026#34;timestampRFC3339Nano\u0026#34;: { \u0026#34;type\u0026#34;: \u0026#34;date_nanos\u0026#34;, \u0026#34;format\u0026#34;: \u0026#34;strict_date_optional_time_nanos\u0026#34; } } } If you use the Kibana interface, you can do it there instead.\nConfigure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description ELASTIC endpoint yes string Elasticsearch instance endpoint URL ELASTIC indexName yes string Name of the index to store the data in ELASTIC insecure no bool false Doesn’t verify TLS certificate ELASTIC auth no string BASIC_AUTH,BEARER_TOKEN Authentication method to use. Secret is required if this is specified ELASTIC secret no string Encoded basic authentication or bearer token value ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forward-to-elasticsearch/"},{"id":390,"title":"GCP","content":"Cloud Security Posture Management (CSPM)Connecting your GCP environment will set up a Service Account between you and Sysdig, enabling Cloud Security Posture Management (CSPM) which:\nMonitors and detects misconfigurations in your cloud resources. Ensures your cloud environment complies with industry standards and regulations. Provides a comprehensive inventory of all cloud assets, helping you maintain visibility and control over your environment. Basic CIEM (Cloud Infrastructure Entitlement Management) analysis is included as a standard functionality within CSPM, without requiring log ingestion. To avail yourself of advanced CIEM, install log ingestion.\nReview GCP Roles and PermissionsService AccountsThere are two security principals in the onboarding process:\nInstaller: The primary security principal, either a User or a Service Account. This security principal will be used to perform the onboarding. Sysdig does not have access to this security principal. Sysdig: A Service Account (robot user) created during onboarding with specific, less permissive roles. Sysdig will be given access to this service account. GCP RolesGCP IAM has a single control plane that applies to either at the organization or project level:\nGCP Roles: Applied to the entire organization or project. Prerequisites Sysdig Secure SaaS with Admin permissions Terraform version 1.5.0 and later GCP CLI installed. See How to install the GCP CLI. Access to a User with the permissions required to install. For Permissions Required to Install, see Base GCP Integration - Cloud Security Posture Management (CSPM). Supported GCP RegionsSysdig supports agentless scanning in the following GCP regions:\nRegion Display Name asia-east1 Taiwan asia-east2 Hong Kong asia-northeast1 Tokyo asia-northeast2 Osaka asia-northeast3 Seoul asia-south1 Mumbai asia-south2 Delhi asia-southeast1 Singapore asia-southeast2 Jakarta australia-southeast1 Sydney australia-southeast2 Melbourne europe-central2 Warsaw europe-north1 Finland europe-southwest1 Madrid europe-west1 Belgium europe-west2 London europe-west3 Frankfurt europe-west4 Netherlands europe-west6 Zurich europe-west8 Milan europe-west9 Paris europe-west10 Berlin europe-west12 Turin me-central1 Doha me-central2 Dammam me-west1 Tel Aviv northamerica-northeast1 Montreal northamerica-northeast2 Toronto southamerica-east1 São Paulo southamerica-west1 Santiago us-central1 Iowa us-east1 South Carolina us-east4 Northern Virginia us-east5 Columbus us-south1 Dallas us-west1 Oregon us-west2 Los Angeles us-west3 Salt Lake City us-west4 Las Vegas Need support for a region not listed? Contact your Sysdig representative to request additional region coverage.\nPrepare Your Environment1. Configure Installation PermissionsIf you install manually or on your local machine, install as a user. If you are automating the installation, such as using Terraform Cloud, install as a service account.\nYou can:\nUse an existing user or service account that meets the permissions requirements Create a new user or service account and set up permissions Add permissions to an existing user or service account Provide User with Appropriate RolesEnsure your user has the correct roles and permissions in GCP to perform the onboarding.\nSingle ProjectTo check or assign roles:\nLog in to the Google Cloud Console as either a user or a service account, ensuring you have the correct project active. Navigate to IAM \u0026amp; Admin \u0026gt; IAM. In VIEW BY PRINCIPALS, find your User/service account. Ensure that all the roles listed in Permissions Required to Install are present. If any roles are missing, select your user/service account, and grant the roles using the Grant Access button. You may need to work with your administrator to be granted the correct roles. Organization Certain roles are required at the organization level. Certain roles are required on a single project in which you will deploy shared resources. Ensure you have the correct roles assigned at the correct scope.\nFor roles required on a single project, follow the instructions for a single project above.\nFor roles that are required at the organization level:\nLog in to the Google Cloud Console as either a user or a service account. Ensure the organization is selected in the project selector in the top bar. If you do not see your organization there, you may need to work with your administrator. In VIEW BY PRINCIPALS, find your User/Super Administrator. Ensure that all the roles listed in Permissions Required to Install are present. If any roles are missing, select your user/service account, and grant the roles using the Grant Access button. You may need to work with your administrator to be granted the correct roles. Enable Required APIsEnable the APIs at the project level. For organization onboarding, this refers to the project you selected during the onboarding process.\nTo do so manually:\nClick each of the API links in the table below.\nSelect the appropriate project and click Enable.\nAPI Name API ID Features Usage Identity and Access Management (IAM) API iam.googleapis.com All Features Used to access and collect IAM resources for CSPM and CIEM evaluations. IAM Service Account Credentials API iamcredentials.googleapis.com All Features Used to generate OAuth 2.0 access tokens. Security Token Service API sts.googleapis.com All Features Used to exchange short-lived access tokens when interacting with Google Cloud resources. Cloud Resource Manager API cloudresourcemanager.googleapis.com CSPM/CIEM Used to gather resources such as organizations, projects, and IAM access control policy bindings for CSPM and CIEM evaluations. Cloud Identity API cloudidentity.googleapis.com CSPM/CIEM Used to look up Google Group resource details. Admin SDK API admin.googleapis.com CSPM/CIEM Used to list users and their details, including information about the users who belong to Google Groups. Cloud Asset API cloudasset.googleapis.com CSPM/CIEM Used to obtain a comprehensive inventory of Google Cloud resources for CSPM and CIEM evaluations Compute Engine API compute.googleapis.com Vulnerability Management/CSPM Used by Vulnerability Management and CSPM to gather firewalls for network exposure analysis Pub Sub API pubsub.googleapis.com CDR Used by CDR to receive all events w.r.t organization / project Cloud Monitoring API monitoring.googleapis.com CDR/CIEM Used to collect metrics for CDR and CIEM evaluations. Check API EnablementTo confirm that the required APIs were enabled:\nEnable the serviceusage.googleapis.com Service API.\nThis is required to execute the following command.\nExecute: gcloud services list --enabled\nInclude all the services listed above.\n2. Authenticate and Configure TerraformA common way to do this is:\nEnsure you are logged in to the correct Project.\nLog in using the GCP CLI:\ngcloud auth application-default login A web page to select your user account appears. Log in as the user you configured in Step 1.\nConfirm you are logged in as the correct user, by running:\ngcloud auth list For alternative ways to authenticate Terraform, see the Terraform documentation: Google Provider Configuration Reference.\n3. Collect your GCP Organization Domain name and Project IDOrganization Domain Name Sign in to the GCP portal. Browse to Select a Resource \u0026gt; All. Search for your Organization name in the overlay. Copy the Organization Domain Name. You can paste this value into a text document or other location. Project ID Sign in to the GCP portal. Browse to Select a Resource \u0026gt; All. Search the project in the list, and note the Project ID shown in the second column. If no projects appear, or you don\u0026rsquo;t see the right one, you may need to switch organizations to show the projects. To easily copy the Project ID, select the project name to display more details. Select the Copy to clipboard icon shown next to the Project ID. You can paste this value into a text document or another location. Install GCP Using the Wizard Log in to Sysdig Secure. Select Integrations \u0026gt; Environments \u0026gt; GCP and click Add GCP Account on the top right corner. Connect your GCP Organization or Project. This enables CSPM and lets you onboard Vulnerability Management and CDR after completing. Organization Multi-Project Enter your: Project ID: The ID of the project where the Sysdig resources will be created. Specify Management Groups: For onboarding the entire Organization: Enter Organization Domain Name. Generate and apply the Terraform code: Create a main.tf file. Copy the snippet provided into the file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. Within an hour after deployment, your accounts will appear on the Cloud Accounts page.\nSingle Project Enter your: Project ID: The ID of the project you want to onboard. Generate and apply the Terraform code: Create a main.tf file. Copy the snippet provided into the file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. Within an hour after deployment, your accounts will appear on the Cloud Accounts page.\nConfigure Domain-Wide DelegationWhat is Domain-Wide-Delegation?In GCP, domain-wide delegation (DWD) refers to a feature in Google Workspace (formerly G Suite). It allows a Google Workspace super admin to delegate authority to a service account to access user data on behalf of users within the domain. Once set up, Sysdig uses a service account that can impersonate users by specifying the subject parameter in its authentication request, setting it to the email address of the Google Workspace user it wishes to impersonate.\nReview domain-wide delegation permissions before you configure DWD.\nDomain-wide delegation entails:\nService Account Access: It allows a service account to impersonate a Google Workspace user and gain access to the Google data the user has access to, assuming they have provisioned the necessary Authorization scopes to the Service Account. No User Consent Required: With DWD, individual user consent is not required. Once the super admin sets up the delegation, the service account can access the specified data of any user in the domain without additional authorization prompts. OAuth 2.0 Scopes: When setting up DWD, the super admin specifies which OAuth 2.0 scopes the service account is granted. For instance, they might grant access to the Directory API to allow the service account to read group member data. Security: Because DWD grants broad access, it\u0026rsquo;s essential to handle it with care. Ensure that you keep the service account\u0026rsquo;s private key (used for authentication) secure. Where is Domain-Wide Delegation Used?Sysdig\u0026rsquo;s CIEM analysis requires DWD to provide:\nUser and Group Insights derived from Google Workspace and Cloud Identity If DWD is enabled, then Unused Permission Criticality, Excessive Permissions, and Members are displayed on the Identity and Access Groups page. Enhanced Monitoring and Reporting for MFA usage, user logins, admin console changes, and third-party application access Asset management to gain insights into Roles, Service Accounts, and their associated keys The onboarding wizard prompts you to perform domain-wide delegation. If you skip this step, you will be prompted again from the Identity and Access (CIEM) page of the Sysdig Secure UI.\nEnable Domain-Wide Delegation in GCPAuthorize Service Account Scopes Log in to the Google Admin Console with Super Administrator privileges and select Security \u0026gt; Access and data control \u0026gt; API controls.\nClick Manage Domain Wide Delegation.\nClick Add New.\nSwitch to the Google Cloud Console to collect your service account\u0026rsquo;s OAuth 2 Client ID:\nNavigate to the Project specified during the initial onboarding step.\nSelect Service Account and search for the newly created Sysdig service account with the format: sysdig-posture-xxxxxx@\u0026lt;project_id\u0026gt;.iam.gserviceaccount.com.\nClick the Service Account link to display the OAuth 2 Client ID and copy it.\nReturn to the Google Admin Console from Step 3. (Security \u0026gt; Access and data control \u0026gt; API controls \u0026gt; Manage Domain Wide Delegation \u0026gt; Add New ).\nIn the panel, enter:\nClient ID: Paste the OAuth 2 Client ID you copied.\nOAuth Scopes: Add the OAuth scopes below in a comma-delimited list.\nhttps://www.googleapis.com/auth/cloud-identity.groups.readonly, https://www.googleapis.com/auth/admin.directory.user.readonly, https://www.googleapis.com/auth/admin.directory.group.readonly, https://www.googleapis.com/auth/admin.directory.group.member.readonly, https://www.googleapis.com/auth/cloud-platform.read-only, https://www.googleapis.com/auth/logging.read, https://www.googleapis.com/auth/admin.reports.audit.readonly, https://www.googleapis.com/auth/admin.reports.usage.readonly, Click Authorize. Create a Custom Admin Role and Grant PrivilegesWhile still in the Google Admin Console, go to Account \u0026gt; Admin Roles.\nClick Create new role.\nEnter the following values:\nName: Enter an appropriate name, such as Secure Posture Management Read-Only Admin Role.\nDescription: Optional\nClick Continue. The Select Privileges page appears.\nConfigure the Select Privileges as follows:\nIn Admin Console Privileges, at the top of the page, enable:\nOrganization Units - Read Users - Read Scroll down to Admin API Privileges and enable:\nGroups - Read Click Continue. Confirm the 5 privileges.\nClick Create Role. The Admin Roles screen appears.\nClick Assign Service Accounts.\nEnter the Sysdig service account name from step 4 and click Add.\n(Format: sysdig-secure-a1b2@your-project-id.iam.gserviceaccount.com)\nA confirmation screen appears; click Assign Role.\nCheck the Connection StatusWithin 10 minutes, after you apply Terraform, your accounts will appear on the Sysdig Cloud Accounts page. You can add more features after this initial connection by following instructions to Add New Features.\nYou can verify your CSPM configuration by checking the connection status.\nIn Sysdig Secure, select Integrations \u0026gt; Environments \u0026gt; GCP.\nThe Status column shows the overall connection status:\nConnected Error Unknown Select the desired account to review the individual services in the detail drawer.\nThe health status for CSPM configuration is given below:\nCSPM Status Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Error ❌ Authentication errors. For example: Invalid account IDInvalid client secretInvalid access credentialsAccess token errors Deny policy created by the user is preventing Sysdig from collecting resourcesThe scan takes too long and eventually times out.Unknown error ","url":"https://docs.sysdig.com/en/sysdig-secure/connect-gcp/"},{"id":391,"title":"Integrate with GitHub Action","content":"Prerequisites Use the SECURE_SECURE_TOKEN environment variable to define the secret containing the API Token and make it available in the pipeline. This is not applicable to the standalone mode.\nUse the SYSDIG_SECURE_URL environment variable to define the Sysdig Secure endpoint and make it available in the pipeline. This is not applicable to the standalone mode.\nThe container image to be scanned\nConfiguration Parameters Parameters Description cli-scanner-url The URL to the sysdig-cli-scanner binary download. The action will detect the operating system and architecture. The version of the CLI Scanner is set to 1.8.1 by default. Use cli-scanner-version to set a different version. mode The mode in which the scan should run. Supported options are vm and iac. The default is vm. cli-scanner-version The custom sysdig-cli-scanner version to download. It is set to 1.8.1 by default. You can specify a different version. Note: If you are using iac mode, minimum required version is 1.9.0. For VM mode, the Action has only been tested with 1.8.x versions and it is not guaranteed that it will work as expected with other versions. registry-user The registry username that is required for authentication when pulling the image to scan. registry-password The password associated with your registry-user. This is the password required for authentication when pulling the image to scan. stop-on-failed-policy-eval Terminate the scanning operation if the policy evaluation is failed. stop-on-processing-error Terminate the scanning operation if the sysdig-cli-scanner terminates the execution with errors. severity-at-least Filtering option to only report vulnerabilities with at least the specified severity. Supported options are critical, high, medium, low, negligible, and any. The default value any performs no filtering. For example, if severity-at-least is set to medium, only Medium, High or Critical vulnerabilities will be reported. group-by-package Enable grouping the vulnerabilities by package in the SARIF report. This option helps manage security on a per-package basis and allows for consolidating the number of findings. standalone Specify the directory for the vulnerabilities database to use while scanning. Useful when running in standalone mode. skip-upload Skips uploading scanning results to Sysdig Secure. skip-summary Skips generating scanning summary. use-policies Specify VM Policies to evaluate, in addition to policies that match the image scope. override-pullstring Custom PullString to give the image when scanning and uploading. Useful when building images in a pipeline with temporary names. The custom PullString will be used to identify the scanned image in Sysdig Secure. image-tag The tag of the image to analyze in the scanning operation. sysdig-secure-token The API token for Sysdig scanning authentication. Required if not in standalone mode. sysdig-secure-url The Sysdig Secure endpoint URL. Defaults to https://secure.sysdig.com. See SaaS Regions and IP Ranges for more details on endpoints and regions. sysdig-skip-tls Skip TLS verification when calling Sysdig Secure endpoints. recursive Recursively scan all folders within the folder specified in the iacScanPath. minimum-severity The minimum severity to fail when scanning in IaC mode iac-scan-path The path to the IaC files to scan. Use CasesGenerate SARIF ReportTo generate a SARIF report that you can later use to upload by using the codeql-action/upload-sarif action:\nAssign an ID to the Sysdig scan Action operation, as follows:\n... - name: Scan image id: scan uses: sysdiglabs/scan-action@v6 with: ... Add an option to upload the SARIF report by providing the path in the sarif_file parameter:\n... - name: Upload SARIF file if: success() || failure() uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ${{ github.workspace }}/sarif.json The if: success() || failure() option makes sure that the SARIF report is uploaded even if the scan fails and interrupts the workflow.\nBuild and Scan an Image Locally and Upload the SARIF Report ... - name: Build the Docker image run: docker build . --file Dockerfile --tag sysdiglabs/dummy-vuln-app:latest - name: Scan image id: scan uses: sysdiglabs/scan-action@v6 with: image-tag: sysdiglabs/dummy-vuln-app:latest sysdig-secure-token: ${{ secrets.SYSDIG_SECURE_TOKEN }} - name: Upload SARIF file if: success() || failure() uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ${{ github.workspace }}/sarif.json Pull and Scan an Image from a Registry ... - name: Scan image uses: sysdiglabs/scan-action@v6 with: image-tag: \u0026#34;sysdiglabs/dummy-vuln-app:latest\u0026#34; sysdig-secure-token: ${{ secrets.SYSDIG_SECURE_TOKEN }} Run an IaC Scanning Operation ... - name: Scan infrastructure uses: sysdiglabs/scan-action@v6 with: sysdig-secure-token: ${{ secrets.SYSDIG_SECURE_TOKEN }} cli-scanner-version: 1.9.0 mode: iac iac-scan-path: ./terraform Terminate a Scanning OperationTo terminate a scanning operation when policy evaluation fails or the scanner fails to run:\n... - name: Scan image uses: sysdiglabs/scan-action@v6 with: image-tag: \u0026#34;sysdiglabs/dummy-vuln-app:latest\u0026#34; sysdig-secure-token: ${{ secrets.SYSDIG_SECURE_TOKEN }} stop-on-failed-policy-eval: true stop-on-processing-error: true Example Workflowname: Scan Image on: workflow_dispatch: jobs: remote-scan-from-registry: runs-on: ubuntu-latest steps: # This step checks out a copy of your repository. - name: Check out repository uses: actions/checkout@v4 - name: Scan dummy-vuln-app from registry id: scan uses: sysdiglabs/scan-action@v6 with: # Tag of the image to analyse image-tag: sysdiglabs/dummy-vuln-app:latest # API token for Sysdig Scanning auth sysdig-secure-token: ${{ secrets.SECURE_API_TOKEN }} stop-on-failed-policy-eval: true stop-on-processing-error: true - name: Upload SARIF file if: success() || failure() # Upload results regardless previous step fails uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ${{ github.workspace }}/sarif.json scan-from-registry: runs-on: ubuntu-latest steps: # This step checks out a copy of your repository. - name: Check out repository uses: actions/checkout@v4 - name: Scan dummy-vuln-app from registry id: scan uses: ./ with: # Tag of the image to analyse image-tag: sysdiglabs/dummy-vuln-app:latest # API token for Sysdig Scanning auth sysdig-secure-token: ${{ secrets.SECURE_API_TOKEN }} stop-on-failed-policy-eval: true stop-on-processing-error: true - name: Upload SARIF file if: success() || failure() # Upload results regardless previous step fails uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ${{ github.workspace }}/sarif.json filtered-scan-from-registry: runs-on: ubuntu-latest steps: # This step checks out a copy of your repository. - name: Check out repository uses: actions/checkout@v4 - name: Scan dummy-vuln-app from registry id: scan uses: ./ with: # Tag of the image to analyse image-tag: sysdiglabs/dummy-vuln-app:latest # API token for Sysdig Scanning auth sysdig-secure-token: ${{ secrets.SECURE_API_TOKEN }} stop-on-failed-policy-eval: true stop-on-processing-error: true severity-at-least: high group-by-package: true - name: Upload SARIF file if: success() || failure() # Upload results regardless previous step fails uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ${{ github.workspace }}/sarif.json standalone-scan-from-registry: runs-on: ubuntu-latest steps: # This step checks out a copy of your repository. - name: Check out repository uses: actions/checkout@v4 - name: Donate MainDB from scan id: donnor-scan uses: ./ with: # Tag of the image to analyse image-tag: sysdiglabs/dummy-vuln-app:latest # API token for Sysdig Scanning auth sysdig-secure-token: ${{ secrets.SECURE_API_TOKEN }} stop-on-failed-policy-eval: false stop-on-processing-error: true skip-summary: true - name: Scan dummy-vuln-app from registry id: scan uses: ./ with: # Tag of the image to analyse image-tag: sysdiglabs/dummy-vuln-app:latest # API token for Sysdig Scanning auth #sysdig-secure-token: ${{ secrets.SECURE_API_TOKEN }} stop-on-failed-policy-eval: true stop-on-processing-error: true standalone: true - name: Upload SARIF file if: success() || failure() # Upload results regardless previous step fails uses: github/codeql-action/upload-sarif@v3 with: sarif_file: ${{ github.workspace }}/sarif.json The All workflow section on the Actions tab shows the result of the scan job as follows:\n","url":"https://docs.sysdig.com/en/sysdig-secure/github-action-integration/"},{"id":392,"title":"IaC Supportablility Matrix","content":"Sysdig IaC scanning supports the following Infrastructure as Code frameworks and file types.\nSupported Frameworks Resource Source type Terraform Terraform providers for AWS, Azure, GCP, and Kubernetes OpenTofu OpenTofu providers for AWS, Azure, GCP, and Kubernetes AWS Cloud Formation Template (CFT) Terraform AWS provider Azure Azure Resource Manager (ARM) Terraform Azure provider GCP Terraform Google Cloud Provider Kubernetes Workloads YAML manifests Kustomize folders Helm Charts Terraform Kubernetes provider OpenTofu SupportSysdig Secure provides first-class support for OpenTofu.\nAutomatic Discovery: The scanner automatically detects and evaluates .tofu and .tofu.json files in your repositories or local directories. Policy Compatibility: Policies defined for Terraform are automatically applied to OpenTofu files without requiring modification or duplication. Inventory: In the Sysdig Secure UI, resources managed by OpenTofu can be filtered using the Source Type filter OpenTofu. Terragrunt is currently not supported for IaC scanning.\n","url":"https://docs.sysdig.com/en/sysdig-secure/iac-suppportability-matrix/"},{"id":393,"title":"Integrations for Sysdig Secure","content":"Sysdig Secure provides three types of integrations:\nEnvironments: Environment integrations cover your core infrastructure: Cloud accounts, Hosts and Clusters. These integrations allow Sysdig to secure your environment. Third-Party Integrations: Third-Party Integrations allow you to connect Sysdig into other ecosystem tools to build out advanced workflows. Plugins: Plugins are tools and solutions maintained by Sysdig that are used directly in external systems such as GitHub, Jenkins, Splunk and more. Environments Cloud Accounts: Connect your Cloud Accounts to Sysdig for Cloud Security Posture Management (CSPM), compliance monitoring, threat detection, and vulnerability assessment in your cloud resources. Managed Kubernetes: Review and add managed Kubernetes clusters detected in the connected cloud accounts. Sysdig Agents: Deploy the Sysdig Host \u0026amp; Cluster Shield for runtime threat detection, security posture management (KSPM), workload vulnerability scanning, and compliance monitoring. Cloud Hosts: View details about the connected hosts, VPCs, and Resource Groups discovered with agentless vulnerability scanning. Third-Party Integrations Event Forwarding: Forward Sysdig security events, audit logs, and compliance findings to a range of external tools such as Splunk, Elasticsearch, and Syslog. Events and Logs: Ingests event logs into Sysdig Secure to correlate user identity and access information with observed activity within cloud and container environments, enhancing threat detection and incident investigation. Git Integrations: Scan container images for vulnerabilities directly within GitHub, Bitbucket, GitLab, or Azure DevOps, providing feedback early in the development cycle. Notification Channels: Get real-time Sysdig alert notifications delivered to a wide range of systems. Sysdig Monitor notification channels must be configured separately and are accessed from the Monitor UI. Risk Spotlight Integration: Risk Spotlight integrations allow Third-Party solution to enrich vulnerability information using the runtime findings provided by Sysdig. Ticketing Integrations: Automatically create Jira issues from Sysdig findings (security events, vulnerabilities, compliance violations) to track remediation within your existing project management workflows. Software Composition Analysis (SCA): Connect findings from your SCA tools, such as Semgrep and Snyk, with runtime vulnerability data discovered by Sysdig Secure. ","url":"https://docs.sysdig.com/en/sysdig-secure/integrations-for-sysdig-secure/"},{"id":394,"title":"Configure Keycloak for OIDC","content":"PrerequisitesSysdig Review OpenID Connect (SaaS). Keycloak Identify your environment and ensure that you meet the prerequisites. Ensure that you have administrative privileges. Configure OpenID Provider for KeycloakThe instructions below covers basic Keycloak configuration. You may need to adjust the operations based on the specifics of your environment.\nLog in to your Keycloak Administrative Console and create the following:\nrealm: A realm in Keycloak is equivalent to a tenant. Create one for your Sysdig application.\nUsers: Create users who can access the realm.\nClient: Create a client for your Sysdig application and take note of the client ID.\nClient type: Choose OpenID Connect.\nClient ID: For example, SysdigMonitor. You will use this value for the OpenID Configuration tab in the Sysdig Authentication(SSO) Settings.\nClient authorization: Toggle this setting to On.\nAuthentication flow: Select Standard flow. This option enables standard OpenID Connect redirect based authentication with authorization code.\nLogin Settings: Specify the following:\nValid redirect URL: Specify your Sysdig application redirect URL.\nSee SaaS Region and IP Ranges and identify the correct Redirect URL associated with your Sysdig application and region. For example, domain URLs of Monitor and Secure for US East are:\nSysdig Monitor: https://app.sysdigcloud.com/api/oauth/openid/auth\nSysdig Secure: https://secure.sysdig.com/api/oauth/openid/secureAuth\nOpen the Credentials tab. Copy the Secret associated with your client.\nYou will need it in the OpenID settings.\nParameters Required for Sysdig ConfigurationCopy the following for the OpenID configuration parameters in the Sysdig authentication settings.\nClient ID: Copy the value from the Settings tab on your Sysdig Client page. Client Secrets: Copy the Client Secret from the Credentials tab. Issuer URL: The Issuer URL will consist of https://KEYCLOAK_SERVER_ADDRESS/auth/realms/REALM_NAME, where KEYCLOAK_SERVER_ADDRESS and REALM_NAME are derived from the environment where you created the configuration. You will enter it in the OpenID settings. Configure Sysdig SettingsTo enable Keycloak OpenID functionality on the Sysdig application, you need the following:\nConfiguration Description Client ID Specify the value you have copied from the Settings tab on your Sysdig Client page. Client Secret Specify the value you have copied from the Client Secret on the Credentials tab. Issuer URL The issuer URL will have the following format: https://KEYCLOAK_SERVER_ADDRESS/auth/realms/REALM_NAME\nwhere KEYCLOAK_SERVER_ADDRESS and REALM_NAME are derived from the environment where you created the configuration. See Enable OpenID in Settings to learn how to complete your configuration.\n","url":"https://docs.sysdig.com/en/administration/saas-keycloak-openid/"},{"id":395,"title":"Keycloak (OpenID On-Prem)","content":"PrerequisitesSysdig Review OpenID Connect (On-Prem). Keycloak Identify your environment and ensure that you meet the prerequisites. Ensure that you have administrative privileges. Configure OpenID Provider for Keycloak Log in to your Keycloak Administrative Console and create the following:\nrealm: A realm in Keycloak is equivalent to a tenant. Create one for your Sysdig application.\nUsers: Create users who can access the realm.\nClient: Create a client for your Sysdig application and take note of the client ID.\nClient type: Choose OpenID Connect.\nClient ID: For example, SysdigMonitor. You will use this value for the OpenID Configuration tab in the Sysdig Authentication(SSO) Settings.\nClient authorization: Toggle this setting to On.\nAuthentication flow: Select Standard flow. This option enables standard OpenID Connect redirect based authentication with authorization code.\nLogin Settings: Specify the following:\nValid redirect URL: enter one of the following values, replacing HOSTNAME with the hostname through which your users access the Sysdig application and PORT with the TCP port number, which is typically 443:\nSysdig Monitor: https://HOSTNAME:PORT/api/oauth/openid/auth\nSysdig Secure: https://HOSTNAME:PORT/api/oauth/openid/secureAuth\nOpen the Credentials tab. Copy the Secret associated with your client.\nYou will need it while completing the configuration in the Sysdig platform.\nParameters Required for Sysdig ConfigurationCopy the following for the OpenID configuration parameters in the Sysdig authentication settings.\nClient ID: Copy the value from the Settings tab on your Sysdig Client page. Client Secrets: Copy the Client Secret from the Credentials tab. Issuer URL: The Issuer URL will consist of https://KEYCLOAK_SERVER_ADDRESS/auth/realms/REALM_NAME, where KEYCLOAK_SERVER_ADDRESS and REALM_NAME are derived from the environment where you created the configuration. You will enter it in the OpenID settings. Configure Sysdig SettingsTo enable Keycloak OpenID functionality on the Sysdig application, you need the following:\nConfiguration Description Client ID Specify the value you have copied from the Settings tab on your Sysdig Client page. Client Secret Specify the value you have copied from the Client Secret on the Credentials tab. Issuer URL The issuer URL will have the following format: https://KEYCLOAK_SERVER_ADDRESS/auth/realms/REALM_NAME\nwhere KEYCLOAK_SERVER_ADDRESS and REALM_NAME are derived from the environment where you created the configuration. See OpenID Connect (On-Prem) to complete the configuration in the Sysdig platform.\n","url":"https://docs.sysdig.com/en/administration/onprem-openid-keycloak/"},{"id":396,"title":"KSPM","content":" KSPM now supports on-premises environments starting from version 7.4.\nKubernetes Platforms Kubernetes (Vanilla) Amazon Elastic Kubernetes Service (EKS) Google Kubernetes Engine (GKE) Azure Kubernetes Service (AKS) RedHat OpenShift IBM Kubernetes Service (IKS) Linux Distributions Ubuntu Debian RHEL Fedora CoreOS CPU Architecturesx86_64\nNetwork RequirementsMake sure to allow traffic on port 12000 for communication within the cluster.\nNext StepsInstall on a Kubernetes cluster\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-reqs-kspm/"},{"id":397,"title":"Kubernetes Audit Logging","content":"This integration lets you audit:\nCreation and destruction of pods, services, deployments, daemon sets, and more.\nCreating, updating, and removing configmaps or secrets\nAttempts to subscribe to changes to any endpoint\nPrerequisite Enable the feature Kubernetes Audit Log Threat Detection via the Helm chart, or a platform-specific installation procedure. To enable this feature, ensure features.k8sAuditDetections is set to true (default value). Enable Kubernetes Audit on RKETo enable Kubernetes Audit log on Rancher Kubernetes Engine (RKE), you must set services.kube-api.audit_log.enabled: to true.\nView Results in the UIWhen Kubernetes audit logging is enabled, default audit policies are active and policy violations are visible in following locations:\nEvents Feed\nIn the Sysdig Secure UI, select Events, and check for one of the Kubernetes Audit Policy names, such as Sysdig K8s Notable Events.\nActivity Audit\nIn the Sysdig Secure UI, select Investigate \u0026gt; Activity Audit and filter for Kubernetes.\nManage Relevant Policies and RulesReview Kubernetes Audit Policies Log in to Sysdig Secure and select Policies \u0026gt; Threat Detection \u0026gt; Runtime Policies.\nOpen the Select policy type dropdown and choose Kubernetes Audit.\nThe default managed policies and any additional custom policies are displayed.\nYou can:\nEnable/disable existing policies Create a custom Kubernetes audit policy For more information, see Create policies. Review Default Audit Logging RulesThe Kubernetes audit logging rules can be viewed in the Sysdig Policies Rules Editor, found in the Policies module. To view the audit rules:\nLog in to Sysdig Secure and select Policies \u0026gt; Rules \u0026gt; Rules Editor.\nOpen the drop-down for the default rules, and select k8s_audit_rules.yaml.\nModify Default Audit Logging RulesIf you don\u0026rsquo;t want to detect some resources within your Kubernetes cluster, you can create your custom rules.\nTo achieve this, you can change the k8sAuditDetectionsRules variable in the values.yaml file. For example, if you want to filter out secrets from the admission controller you can use the following rules:\n- apiGroups: - \u0026#34;\u0026#34; apiVersions: [ \u0026#34;*\u0026#34; ] operations: [ \u0026#34;*\u0026#34; ] resources: - bindings - componentstatuses - configmaps - endpoints - events - limitranges - namespaces - nodes - persistentvolumeclaims - persistentvolumes - pods/* - podtemplates - replicationcontrollers - resourcequotas - serviceaccounts - services scope: \u0026#34;*\u0026#34; - apiGroups: - apps - autoscaling - batch - networking.k8s.io - rbac.authorization.k8s.io - extensions apiVersions: [ \u0026#34;*\u0026#34; ] operations: [ \u0026#34;*\u0026#34; ] resources: [ \u0026#34;*/*\u0026#34; ] scope: \u0026#34;*\u0026#34; See Install Kubernetes Audit Logging for more information on using the helm chart to apply the changes.\n","url":"https://docs.sysdig.com/en/sysdig-secure/kubernetes-audit-logging/"},{"id":398,"title":"Metric Labels","content":"_sysdig_datasource Prometheus ID _sysdig_datasource Legacy ID _sysdig_datasource OSS KSM ID - Category Sysdig Description Indicates the ingestion data source for the metric. Additional Notes agent_id Prometheus ID agent_id Legacy ID agent.id OSS KSM ID - Category Agent Description Unique agent id which sent the metric timeseries from the host Additional Notes agent_mode Prometheus ID agent_mode Legacy ID agent.mode OSS KSM ID - Category Agent Description Additional Notes agent_version Prometheus ID agent_version Legacy ID agent.version OSS KSM ID - Category Agent Description The Sysdig\u0026rsquo;s agent installed version Additional Notes cloud_provider_account_id Prometheus ID cloud_provider_account_id Legacy ID cloudProvider.account.id OSS KSM ID - Category Cloud Provider Description The account number related to your AWS account - useful when you have multiple AWS accounts linked with Sysdig Monitor. Additional Notes cloud_provider_availability_zone Prometheus ID cloud_provider_availability_zone Legacy ID cloudProvider.availabilityZone OSS KSM ID - Category Cloud Provider Description The AWS Availability Zone where the entity or entities are located. Each Availability zone is an isolated subsection of an AWS region (see cloudProvider.region). Additional Notes cloud_provider_host_ip_private Prometheus ID cloud_provider_host_ip_private Legacy ID cloudProvider.host.ip.private OSS KSM ID - Category Cloud Provider Description The private IP address allocated by the cloud provider for the instance. This address can be used for communication between instances in the same network. Additional Notes cloud_provider_host_ip_public Prometheus ID cloud_provider_host_ip_public Legacy ID cloudProvider.host.ip.public OSS KSM ID - Category Cloud Provider Description Public IP addresses of the selected host. Additional Notes cloud_provider_host_name Prometheus ID cloud_provider_host_name Legacy ID cloudProvider.host.name OSS KSM ID - Category Cloud Provider Description The name of the host as reported by the cloud provider (e.g. AWS). Additional Notes cloud_provider_id Prometheus ID cloud_provider_id Legacy ID cloudProvider.id OSS KSM ID - Category Cloud Provider Description ID number as assigned and reported by the cloud provider. Additional Notes cloud_provider_instance_type Prometheus ID cloud_provider_instance_type Legacy ID cloudProvider.instance.type OSS KSM ID - Category Cloud Provider Description The type of AWS instance. Additional Notes This metric is extremely useful to segment instances and compare their resource usage and saturation. You can use it as a grouping criteria for the explore table to quickly explore AWS usage on a per-instance-type basis. You can also use it to compare things like CPU usage, number of requests or network utilization for different instance types. cloud_provider_name Prometheus ID cloud_provider_name Legacy ID cloudProvider.name OSS KSM ID - Category Cloud Provider Description Name of the cloud service provider (AWS, etc.). Additional Notes cloud_provider_region Prometheus ID cloud_provider_region Legacy ID cloudProvider.region OSS KSM ID - Category Cloud Provider Description The AWS region where the host (or group of hosts) is located. Additional Notes Use this grouping criteria in conjunction with the host.count metric to easily create a report on how many instances you have in each region. cloud_provider_resource_endpoint Prometheus ID cloud_provider_resource_endpoint Legacy ID cloudProvider.resource.endPoint OSS KSM ID - Category Cloud Provider Description DNS name for which the resource can be accessed. Additional Notes cloud_provider_resource_name Prometheus ID cloud_provider_resource_name Legacy ID cloudProvider.resource.name OSS KSM ID - Category Cloud Provider Description The AWS service name (e.g. EC2, RDS, ELB). Additional Notes cloud_provider_resource_type Prometheus ID cloud_provider_resource_type Legacy ID cloudProvider.resource.type OSS KSM ID - Category Cloud Provider Description The service type (e.g. INSTANCE, LOAD_BALANCER, DATABASE). Additional Notes cloud_provider_security_groups Prometheus ID cloud_provider_security_groups Legacy ID cloudProvider.securityGroups OSS KSM ID - Category Cloud Provider Description Security Groups Name. Additional Notes cloud_provider_status Prometheus ID cloud_provider_status Legacy ID cloudProvider.status OSS KSM ID - Category Cloud Provider Description Resource status. Additional Notes container_full_id Prometheus ID container_full_id Legacy ID container.full.id OSS KSM ID - Category Container Description The full UID of the running container as retrieved from the container runtime. Additional Notes container_id Prometheus ID container_id Legacy ID container.id OSS KSM ID - Category Container Description The short ID of the running container via truncating the full ID. In case of Docker, this is a 12 digit hex number. Additional Notes container_image Prometheus ID container_image Legacy ID container.image OSS KSM ID - Category Container Description The name of the image used to run the container. Additional Notes container_image_digest Prometheus ID container_image_digest Legacy ID container.image.digest OSS KSM ID - Category Container Description The digest of the image used to run the container. Additional Notes container_image_id Prometheus ID container_image_id Legacy ID container.image.id OSS KSM ID - Category Container Description The ID of the image used to run the container. Additional Notes container_image_repo Prometheus ID container_image_repo Legacy ID container.image.repo OSS KSM ID - Category Container Description The repo where the image used to run the container was retrieved from. Empty if image wasn\u0026rsquo;t retrieved from a remote repository. Additional Notes container_image_tag Prometheus ID container_image_tag Legacy ID container.image.tag OSS KSM ID - Category Container Description The tag of the image used to run the container. Additional Notes container_label_io_kubernetes_container_name Prometheus ID container_label_io_kubernetes_container_name Legacy ID container.label.io.kubernetes.container.name OSS KSM ID - Category Container Description Label set on the container in the container runtime when running in a Kubernetes environment. This label will match the container name set in the Kubernetes manifest for the Pod. Additional Notes container_label_io_kubernetes_pod_name Prometheus ID container_label_io_kubernetes_pod_name Legacy ID container.label.io.kubernetes.pod.name OSS KSM ID - Category Container Description Label set on the container in the container runtime when running in a Kubernetes environment. This label will match the Pod name set in the Kubernetes manifest for the Pod. Additional Notes container_label_io_kubernetes_pod_namespace Prometheus ID container_label_io_kubernetes_pod_namespace Legacy ID container.label.io.kubernetes.pod.namespace OSS KSM ID - Category Container Description Label set on the container in the container runtime when running in a Kubernetes environment. This label will match the Pod namespace set in the Kubernetes manifest for the Pod. Additional Notes container_label_io_prometheus_path Prometheus ID container_label_io_prometheus_path Legacy ID container.label.io.prometheus.path OSS KSM ID - Category Container Description Additional Notes container_label_io_prometheus_port Prometheus ID container_label_io_prometheus_port Legacy ID container.label.io.prometheus.port OSS KSM ID - Category Container Description Additional Notes container_label_io_prometheus_scrape Prometheus ID container_label_io_prometheus_scrape Legacy ID container.label.io.prometheus.scrape OSS KSM ID - Category Container Description Additional Notes container_name Prometheus ID container_name Legacy ID container.name OSS KSM ID - Category Container Description The name of a running container. Additional Notes container_type Prometheus ID container_type Legacy ID container.type OSS KSM ID - Category Container Description Additional Notes cpu_core Prometheus ID cpu_core Legacy ID cpu.core OSS KSM ID - Category Host Description CPU core number Additional Notes ecs_cluster_name Prometheus ID ecs_cluster_name Legacy ID ecs.clusterName OSS KSM ID - Category ECS Description Amazon ECS cluster name Additional Notes ecs_service_name Prometheus ID ecs_service_name Legacy ID ecs.serviceName OSS KSM ID - Category ECS Description Amazon ECS service name Additional Notes ecs_task_family_name Prometheus ID ecs_task_family_name Legacy ID ecs.taskFamilyName OSS KSM ID - Category ECS Description Amazon ECS task family name Additional Notes file_mount Prometheus ID file_mount Legacy ID file.mount OSS KSM ID - Category File Stats Description File stats mount path Additional Notes file_name Prometheus ID file_name Legacy ID file.name OSS KSM ID - Category File Stats Description File stats file name including its path Additional Notes fs_device Prometheus ID fs_device Legacy ID fs.device OSS KSM ID - Category File System Description File system device name Additional Notes fs_mount_dir Prometheus ID fs_mount_dir Legacy ID fs.mountDir OSS KSM ID - Category File System Description File system mounted dir Additional Notes fs_type Prometheus ID fs_type Legacy ID fs.type OSS KSM ID - Category File System Description File system type (e.g. EXT, NTFS) Additional Notes host_domain Prometheus ID host_domain Legacy ID host.domain OSS KSM ID - Category Host Description The domain name for external websites. Additional Notes This label has been deprecated. host_hostname Prometheus ID host_hostname Legacy ID host.hostName OSS KSM ID - Category Host Description Host name as defined in the /etc/hostname file. Additional Notes host_instance_id Prometheus ID host_instance_id Legacy ID host.instanceId OSS KSM ID - Category Host Description Additional Notes host_ip_private Prometheus ID host_ip_private Legacy ID host.ip.private OSS KSM ID - Category Host Description Private machine IP address. Additional Notes host_ip_public Prometheus ID host_ip_public Legacy ID host.ip.public OSS KSM ID - Category Host Description Public machine IP address. Additional Notes host_mac Prometheus ID host_mac Legacy ID host.mac OSS KSM ID - Category Host Description Media Access Control address of the host. Additional Notes kube_cluster_id Prometheus ID kube_cluster_id Legacy ID kubernetes.cluster.id OSS KSM ID id Category Kubernetes Description Uniquely identifying ID for a cluster Additional Notes As there is no concept of a cluster ID in Kubernetes, this label is populated with the UID of the \u0026ldquo;default\u0026rdquo; namespace in the cluster kube_cluster_name Prometheus ID kube_cluster_name Legacy ID kubernetes.cluster.name OSS KSM ID cluster Category Kubernetes Description User-defined name for the cluster Additional Notes The cluster name is set by the user via the \u0026ldquo;k8s_cluster_name\u0026rdquo; configuration parameter in the Agent or by adding an Agent tag with a key called \u0026ldquo;cluster\u0026rdquo;. If the user doesn\u0026rsquo;t set it, this label will not exist. concurrency_policy Prometheus ID concurrency_policy Legacy ID kubernetes.cronjob.concurrencyPolicy OSS KSM ID - Category Kubernetes Description Specifies how to treat concurrent executions created by this Cron Job. Value can be \u0026ldquo;Allow\u0026rdquo;, \u0026ldquo;Forbid\u0026rdquo;, or \u0026ldquo;Replace\u0026rdquo; Additional Notes kube_cronjob_name Prometheus ID kube_cronjob_name Legacy ID kubernetes.cronjob.name OSS KSM ID cronjob Category Kubernetes Description Name of the Cron Job as retrieved from the API server. Additional Notes schedule Prometheus ID schedule Legacy ID kubernetes.cronjob.schedule OSS KSM ID - Category Kubernetes Description The scheduled time in which the Cron Job will run. Will be a Cron format string. Additional Notes kube_daemonset_name Prometheus ID kube_daemonset_name Legacy ID kubernetes.daemonSet.name OSS KSM ID daemonset Category Kubernetes Description Name of the DaemonSet as retrieved from the API server. Additional Notes kube_daemonset_uid Prometheus ID kube_daemonset_uid Legacy ID kubernetes.daemonSet.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the DaemonSet as retrieved from the API server. Additional Notes kube_deployment_name Prometheus ID kube_deployment_name Legacy ID kubernetes.deployment.name OSS KSM ID deployment Category Kubernetes Description Name of the Deployment as retrieved from the API server. Additional Notes kube_deployment_uid Prometheus ID kube_deployment_uid Legacy ID kubernetes.deployment.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the Deployment as retrieved from the API server. Additional Notes kube_hpa_name Prometheus ID kube_hpa_name Legacy ID kubernetes.hpa.name OSS KSM ID hpa Category Kubernetes Description Name of the HPA as retrieved from the API server. Additional Notes kube_hpa_uid Prometheus ID kube_hpa_uid Legacy ID kubernetes.hpa.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the HPA as retrieved from the API server. Additional Notes kube_job_name Prometheus ID kube_job_name Legacy ID kubernetes.job.name OSS KSM ID job_name Category Kubernetes Description Name of the Job as retrieved from the API server. Additional Notes kube_job_owner_is_controller Prometheus ID kube_job_owner_is_controller Legacy ID kubernetes.job.owner.isController OSS KSM ID owner_is_controller Category Kubernetes Description Designates whether the Job is created by a higher-level controller object Additional Notes kube_job_owner_kind Prometheus ID kube_job_owner_kind Legacy ID kubernetes.job.owner.kind OSS KSM ID owner_kind Category Kubernetes Description The workload resource type of the object that created the Job if owned by a higher-level controller object Additional Notes kube_job_owner_name Prometheus ID kube_job_owner_name Legacy ID kubernetes.job.owner.name OSS KSM ID owner_name Category Kubernetes Description The name of the object that created the Job if owned by a higher-level controller object Additional Notes kube_job_uid Prometheus ID kube_job_uid Legacy ID kubernetes.job.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the Job as retrieved from the API server. Additional Notes kube_namespace_name Prometheus ID kube_namespace_name Legacy ID kubernetes.namespace.name OSS KSM ID namespace Category Kubernetes Description Name of the Namespace as retrieved from the API server. Additional Notes kube_namespace_uid Prometheus ID kube_namespace_uid Legacy ID kubernetes.namespace.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the Namespace as retrieved from the API server. Additional Notes kube_node_condition Prometheus ID kube_node_condition Legacy ID kubernetes.node.condition OSS KSM ID condition Category Kubernetes Description Describes the status of the Node. Can be Ready, DiskPressure, OutOfDisk, MemoryPressure, or Unschedulable. Additional Notes kube_node_name Prometheus ID kube_node_name Legacy ID kubernetes.node.name OSS KSM ID node Category Kubernetes Description Name of the Node as retrieved from the API server. Additional Notes kube_node_resource Prometheus ID kube_node_resource Legacy ID kubernetes.node.resource OSS KSM ID resource Category Kubernetes Description Indicates the capacity or allocatable limit for the different resources of a node Additional Notes kube_node_status Prometheus ID kube_node_status Legacy ID kubernetes.node.status OSS KSM ID status Category Kubernetes Description Used in combination with the kube_node_condition label to indicate the boolean value of that label Additional Notes kube_node_uid Prometheus ID kube_node_uid Legacy ID kubernetes.node.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the Node as retrieved from the API server. Additional Notes kube_node_unit Prometheus ID kube_node_unit Legacy ID kubernetes.node.unit OSS KSM ID unit Category Kubernetes Description Used in combination with the kube_node_resource label to indicate the unit of that label Additional Notes name Prometheus ID name Legacy ID kubernetes.persistentvolume.claim.ref.name OSS KSM ID - Category Kubernetes Description Name of the Persistent Volume\u0026rsquo;s claimRef as retrieved from the API server. Additional Notes claim_namespace Prometheus ID claim_namespace Legacy ID kubernetes.persistentvolume.claim.ref.namespace OSS KSM ID - Category Kubernetes Description Namespace of the Persistent Volume\u0026rsquo;s claimRef as retrieved from the API server. Additional Notes kube_persistentvolume_name Prometheus ID kube_persistentvolume_name Legacy ID kubernetes.persistentvolume.name OSS KSM ID persistentvolume Category Kubernetes Description Name of the Persistent Volume as retrieved from the API server. Additional Notes kube_persistentvolume_uid Prometheus ID kube_persistentvolume_uid Legacy ID kubernetes.persistentvolume.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the Persistent Volume as retrieved from the API server. Additional Notes access_mode Prometheus ID access_mode Legacy ID kubernetes.persistentvolumeclaim.accessMode OSS KSM ID - Category Kubernetes Description Access mode of the PVC as retrieved from the API server. Additional Notes status Prometheus ID status Legacy ID kubernetes.persistentvolumeclaim.condition.status OSS KSM ID - Category Kubernetes Description Used in combination with the type label to indicate the boolean value of that label Additional Notes type Prometheus ID type Legacy ID kubernetes.persistentvolumeclaim.condition.type OSS KSM ID - Category Kubernetes Description The type of the condition that the PVC is in Additional Notes kube_persistentvolumeclaim_name Prometheus ID kube_persistentvolumeclaim_name Legacy ID kubernetes.persistentvolumeclaim.name OSS KSM ID persistentvolumeclaim Category Kubernetes Description Name of the PVC as retrieved from the API server. Additional Notes phase Prometheus ID phase Legacy ID kubernetes.persistentvolumeclaim.phase OSS KSM ID - Category Kubernetes Description The phase that the PVC is in. Will be Available, Bound, Released, or Failed. Additional Notes kube_persistentvolumeclaim_uid Prometheus ID kube_persistentvolumeclaim_uid Legacy ID kubernetes.persistentvolumeclaim.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the PVC as retrieved from the API server. Additional Notes kube_pod_condition Prometheus ID kube_pod_condition Legacy ID kubernetes.pod.condition OSS KSM ID condition Category Kubernetes Description The condition that the Pod is in. Will be PodScheduled, ContainersReady, Initialized, or Ready Additional Notes kube_pod_container_full_id Prometheus ID kube_pod_container_full_id Legacy ID kubernetes.pod.container.full.id OSS KSM ID container_full_id Category Kubernetes Description The full UID of the container in the Pod Additional Notes kube_pod_container_id Prometheus ID kube_pod_container_id Legacy ID kubernetes.pod.container.id OSS KSM ID container_id Category Kubernetes Description A short ID from truncating the full UID of the container in the Pod Additional Notes kube_pod_container_name Prometheus ID kube_pod_container_name Legacy ID kubernetes.pod.container.name OSS KSM ID container Category Kubernetes Description The name of the container in the Pod Additional Notes kube_pod_container_reason Prometheus ID kube_pod_container_reason Legacy ID kubernetes.pod.container.reason OSS KSM ID reason Category Kubernetes Description The reason that the container is in the state that it is in. Additional Notes kube_pod_internal_ip Prometheus ID kube_pod_internal_ip Legacy ID kubernetes.pod.internalIp OSS KSM ID internal_ip Category Kubernetes Description The IP address associated with the Pod Additional Notes kube_pod_name Prometheus ID kube_pod_name Legacy ID kubernetes.pod.name OSS KSM ID pod Category Kubernetes Description Name of the Pod as retrieved from the API server. Additional Notes kube_pod_node Prometheus ID kube_pod_node Legacy ID kubernetes.pod.node OSS KSM ID node Category Kubernetes Description The Node on which the Pod is running. Additional Notes kube_pod_owner_is_controller Prometheus ID kube_pod_owner_is_controller Legacy ID kubernetes.pod.owner.isController OSS KSM ID owner_is_controller Category Kubernetes Description Designates whether the Pod is created by a higher-level controller object Additional Notes kube_pod_owner_kind Prometheus ID kube_pod_owner_kind Legacy ID kubernetes.pod.owner.kind OSS KSM ID owner_kind Category Kubernetes Description The workload resource type of the object that created the Pod if owned by a higher-level controller object Additional Notes kube_pod_owner_name Prometheus ID kube_pod_owner_name Legacy ID kubernetes.pod.owner.name OSS KSM ID owner_name Category Kubernetes Description The name of the object that created the Pod if owned by a higher-level controller object Additional Notes kube_pod_persistentvolumeclaim Prometheus ID kube_pod_persistentvolumeclaim Legacy ID kubernetes.pod.persistentvolumeclaim OSS KSM ID persistentvolumeclaim Category Kubernetes Description The name of the PVC associated with the Pod Additional Notes kube_pod_phase Prometheus ID kube_pod_phase Legacy ID kubernetes.pod.phase OSS KSM ID phase Category Kubernetes Description The phase that the Pod is in. Can be Pending, Running, Succeeded, Failed, or Unknown. Additional Notes kube_pod_pod_ip Prometheus ID kube_pod_pod_ip Legacy ID kubernetes.pod.pod.ip OSS KSM ID pod_ip Category Kubernetes Description The IP address associated with the Pod Additional Notes kube_pod_reason Prometheus ID kube_pod_reason Legacy ID kubernetes.pod.reason OSS KSM ID reason Category Kubernetes Description The reason the Pod is in the phase that it is in. Additional Notes kube_pod_resource Prometheus ID kube_pod_resource Legacy ID kubernetes.pod.resource OSS KSM ID resource Category Kubernetes Description The Pod\u0026rsquo;s resource limits and requests. Individual labels are created for memory limits, memory requests, CPU limits, and CPU requests Additional Notes kube_pod_uid Prometheus ID kube_pod_uid Legacy ID kubernetes.pod.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the Pod as retrieved from the API server. Additional Notes kube_pod_unit Prometheus ID kube_pod_unit Legacy ID kubernetes.pod.unit OSS KSM ID unit Category Kubernetes Description Used in combination with the kube_pod_resource label to indicate the unit of the resource limit or request Additional Notes kube_pod_volume Prometheus ID kube_pod_volume Legacy ID kubernetes.pod.volume OSS KSM ID volume Category Kubernetes Description Name of the volume associated with the Pod. Additional Notes kube_replicaset_name Prometheus ID kube_replicaset_name Legacy ID kubernetes.replicaSet.name OSS KSM ID replicaset Category Kubernetes Description Name of the ReplicaSet as retrieved from the API server. Additional Notes kube_replicaset_owner_is_controller Prometheus ID kube_replicaset_owner_is_controller Legacy ID kubernetes.replicaSet.owner.isController OSS KSM ID owner_is_controller Category Kubernetes Description Designates whether the ReplicaSet is created by a higher-level controller object Additional Notes kube_replicaset_owner_kind Prometheus ID kube_replicaset_owner_kind Legacy ID kubernetes.replicaSet.owner.kind OSS KSM ID owner_kind Category Kubernetes Description The workload resource type of the object that created the ReplicaSet if owned by a higher-level controller object Additional Notes kube_replicaset_owner_name Prometheus ID kube_replicaset_owner_name Legacy ID kubernetes.replicaSet.owner.name OSS KSM ID owner_name Category Kubernetes Description The name of the object that created the ReplicaSet if owned by a higher-level controller object Additional Notes kube_replicaset_uid Prometheus ID kube_replicaset_uid Legacy ID kubernetes.replicaSet.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the ReplicaSet as retrieved from the API server. Additional Notes kube_replicationcontroller_name Prometheus ID kube_replicationcontroller_name Legacy ID kubernetes.replicationController.name OSS KSM ID replicationcontroller Category Kubernetes Description Name of the Replication Controller as retrieved from the API server. Additional Notes kube_replicationcontroller_owner_is_controller Prometheus ID kube_replicationcontroller_owner_is_controller Legacy ID kubernetes.replicationController.owner.isController OSS KSM ID owner_is_controller Category Kubernetes Description Designates whether the Replication Controller is created by a higher-level controller object Additional Notes kube_replicationcontroller_owner_kind Prometheus ID kube_replicationcontroller_owner_kind Legacy ID kubernetes.replicationController.owner.kind OSS KSM ID owner_kind Category Kubernetes Description The workload resource type of the object that created the Replication Controller if owned by a higher-level controller object Additional Notes kube_replicationcontroller_owner_name Prometheus ID kube_replicationcontroller_owner_name Legacy ID kubernetes.replicationController.owner.name OSS KSM ID owner_name Category Kubernetes Description The name of the object that created the Replication Controller if owned by a higher-level controller object Additional Notes kube_replicationcontroller_uid Prometheus ID kube_replicationcontroller_uid Legacy ID kubernetes.replicationController.uid OSS KSM ID _uid Category Kubernetes Description Unique ID of the Replication Controller as retrieved from the API server. Additional Notes kube_resourcequota_name Prometheus ID kube_resourcequota_name Legacy ID kubernetes.resourcequota.name OSS KSM ID resourcequota Category Kubernetes Description Name of the Resource Quota as retrieved from the API server. Additional Notes kube_resourcequota_namespace Prometheus ID kube_resourcequota_namespace Legacy ID kubernetes.resourcequota.namespace OSS KSM ID namespace Category Kubernetes Description Namespace in which the Resource Quota is being enforced Additional Notes kube_resourcequota_resource Prometheus ID kube_resourcequota_resource Legacy ID kubernetes.resourcequota.resource OSS KSM ID resource Category Kubernetes Description The resource and the amount of it in which the Resource Quota is being enforced Additional Notes kube_resourcequota_resourcequota Prometheus ID kube_resourcequota_resourcequota Legacy ID kubernetes.resourcequota.resourcequota OSS KSM ID resourcequota Category Kubernetes Description Name of the Resource Quota as retrieved from the API server. Additional Notes kube_resourcequota_type Prometheus ID kube_resourcequota_type Legacy ID kubernetes.resourcequota.type OSS KSM ID type Category Kubernetes Description Used in combination with kube_resourcequota_resource to designate whether the amount is Used or is the Hard limit Additional Notes kube_resourcequota_uid Prometheus ID kube_resourcequota_uid Legacy ID kubernetes.resourcequota.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the Resource Quota as retrieved from the API server. Additional Notes kube_service_cluster_ip Prometheus ID kube_service_cluster_ip Legacy ID kubernetes.service.clusterIp OSS KSM ID cluster_ip Category Kubernetes Description The IP address associated with the Service Additional Notes kube_service_name Prometheus ID kube_service_name Legacy ID kubernetes.service.name OSS KSM ID service Category Kubernetes Description Name of the Service as retrieved from the API server. Additional Notes kube_service_service_ip Prometheus ID kube_service_service_ip Legacy ID kubernetes.service.service.ip OSS KSM ID service_ip Category Kubernetes Description The IP address associated with the Service Additional Notes kube_service_uid Prometheus ID kube_service_uid Legacy ID kubernetes.service.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the Service as retrieved from the API server. Additional Notes kube_statefulset_name Prometheus ID kube_statefulset_name Legacy ID kubernetes.statefulSet.name OSS KSM ID statefulset Category Kubernetes Description Name of the StatefulSet as retrieved from the API server. Additional Notes kube_statefulset_uid Prometheus ID kube_statefulset_uid Legacy ID kubernetes.statefulSet.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the StatefulSet as retrieved from the API server. Additional Notes kube_storageclass_name Prometheus ID kube_storageclass_name Legacy ID kubernetes.storageclass.name OSS KSM ID storageclass Category Kubernetes Description Name of the Storage Class as retrieved from the API server. Additional Notes provisioner Prometheus ID provisioner Legacy ID kubernetes.storageclass.provisioner OSS KSM ID - Category Kubernetes Description The Provisioner of the Storage Class as retrieved from the API server. Additional Notes reclaim_policy Prometheus ID reclaim_policy Legacy ID kubernetes.storageclass.reclaimPolicy OSS KSM ID - Category Kubernetes Description The reclaim policy for the Storage Class as retrieved from the API server. Additional Notes kube_storageclass_uid Prometheus ID kube_storageclass_uid Legacy ID kubernetes.storageclass.uid OSS KSM ID uid Category Kubernetes Description Unique ID of the Storage Class as retrieved from the API server. Additional Notes volume_binding_mode Prometheus ID volume_binding_mode Legacy ID kubernetes.storageclass.volumeBindingMode OSS KSM ID - Category Kubernetes Description The volume binding mode for the Storage Class as retrieved from the API server. Additional Notes kube_workload_name Prometheus ID kube_workload_name Legacy ID kubernetes.workload.name OSS KSM ID workload_name Category Kubernetes Description The name of the Kubernetes workload resource object Additional Notes kube_workload_type Prometheus ID kube_workload_type Legacy ID kubernetes.workload.type OSS KSM ID workload_type Category Kubernetes Description The type of the Kubernetes workload resource i.e. Deployment, DaemonSet, Job, etc. Additional Notes marathon_app_id Prometheus ID marathon_app_id Legacy ID marathon.app.id OSS KSM ID - Category Marathon Description Additional Notes marathon_app_name Prometheus ID marathon_app_name Legacy ID marathon.app.name OSS KSM ID - Category Marathon Description Additional Notes marathon_group_id Prometheus ID marathon_group_id Legacy ID marathon.group.id OSS KSM ID - Category Marathon Description Additional Notes marathon_group_name Prometheus ID marathon_group_name Legacy ID marathon.group.name OSS KSM ID - Category Marathon Description Additional Notes mesos_cluster_id Prometheus ID mesos_cluster_id Legacy ID mesos.cluster.id OSS KSM ID - Category Mesos Description Additional Notes mesos_cluster_name Prometheus ID mesos_cluster_name Legacy ID mesos.cluster.name OSS KSM ID - Category Mesos Description Additional Notes mesos_framework_id Prometheus ID mesos_framework_id Legacy ID mesos.framework.id OSS KSM ID - Category Mesos Description Additional Notes mesos_framework_name Prometheus ID mesos_framework_name Legacy ID mesos.framework.name OSS KSM ID - Category Mesos Description Additional Notes mesos_slave_id Prometheus ID mesos_slave_id Legacy ID mesos.slave.id OSS KSM ID - Category Mesos Description Additional Notes mesos_slave_name Prometheus ID mesos_slave_name Legacy ID mesos.slave.name OSS KSM ID - Category Mesos Description Additional Notes mesos_task_id Prometheus ID mesos_task_id Legacy ID mesos.task.id OSS KSM ID - Category Mesos Description Additional Notes mesos_task_name Prometheus ID mesos_task_name Legacy ID mesos.task.name OSS KSM ID - Category Mesos Description Additional Notes net_client_ip Prometheus ID net_client_ip Legacy ID net.client.ip OSS KSM ID - Category Network Description Client IP address. Additional Notes net_http_method Prometheus ID net_http_method Legacy ID net.http.method OSS KSM ID - Category Network Description HTTP request method. Additional Notes net_http_statuscode Prometheus ID net_http_statuscode Legacy ID net.http.statusCode OSS KSM ID - Category Network Description HTTP response status code. Additional Notes net_http_url Prometheus ID net_http_url Legacy ID net.http.url OSS KSM ID - Category Network Description URL from an HTTP request. Additional Notes net_local_endpoint Prometheus ID net_local_endpoint Legacy ID net.local.endpoint OSS KSM ID - Category Network Description IP address of a local endpoint. Additional Notes net_local_service Prometheus ID net_local_service Legacy ID net.local.service OSS KSM ID - Category Network Description Port number of a local service. Additional Notes net_mongodb_collection Prometheus ID net_mongodb_collection Legacy ID net.mongodb.collection OSS KSM ID - Category Network Description MongoDB collection. Additional Notes net_mongodb_operation Prometheus ID net_mongodb_operation Legacy ID net.mongodb.operation OSS KSM ID - Category Network Description MongoDB operation. Additional Notes net_protocol Prometheus ID net_protocol Legacy ID net.protocol OSS KSM ID - Category Network Description The network protocol of a request (e.g. HTTP, MySQL). Additional Notes net_remote_endpoint Prometheus ID net_remote_endpoint Legacy ID net.remote.endpoint OSS KSM ID - Category Network Description IP address of a remote node. Additional Notes net_remote_service Prometheus ID net_remote_service Legacy ID net.remote.service OSS KSM ID - Category Network Description Service (port number) of a remote node. Additional Notes net_server_ip Prometheus ID net_server_ip Legacy ID net.server.ip OSS KSM ID - Category Network Description Server IP address. Additional Notes net_server_port Prometheus ID net_server_port Legacy ID net.server.port OSS KSM ID - Category Network Description TCP/UDP Server Port number. Additional Notes net_sql_query Prometheus ID net_sql_query Legacy ID net.sql.query OSS KSM ID - Category Network Description The full SQL query. Additional Notes net_sql_querytype Prometheus ID net_sql_querytype Legacy ID net.sql.query.type OSS KSM ID - Category Network Description SQL query type (SELECT, INSERT, DELETE, etc.). Additional Notes net_sql_table Prometheus ID net_sql_table Legacy ID net.sql.table OSS KSM ID - Category Network Description SQL query table name. Additional Notes program_name Prometheus ID program_name Legacy ID proc.client.name OSS KSM ID - Category Program Description Name of the Client process. Additional Notes program_cmd_line Prometheus ID program_cmd_line Legacy ID proc.commandLine OSS KSM ID - Category Program Description Command line used to start the process. Additional Notes program_name Prometheus ID program_name Legacy ID proc.name OSS KSM ID - Category Program Description Name of the process. Additional Notes program_name Prometheus ID program_name Legacy ID proc.server.name OSS KSM ID - Category Program Description Name of the server process. Additional Notes swarm_cluster_id Prometheus ID swarm_cluster_id Legacy ID swarm.cluster.id OSS KSM ID - Category Swarm Description Additional Notes swarm_cluster_name Prometheus ID swarm_cluster_name Legacy ID swarm.cluster.name OSS KSM ID - Category Swarm Description Additional Notes swarm_manager_reachability Prometheus ID swarm_manager_reachability Legacy ID swarm.manager.reachability OSS KSM ID - Category Swarm Description Additional Notes swarm_node_availability Prometheus ID swarm_node_availability Legacy ID swarm.node.availability OSS KSM ID - Category Swarm Description Additional Notes swarm_node_id Prometheus ID swarm_node_id Legacy ID swarm.node.id OSS KSM ID - Category Swarm Description Additional Notes swarm_node_ip_address Prometheus ID swarm_node_ip_address Legacy ID swarm.node.ip_address OSS KSM ID - Category Swarm Description Additional Notes swarm_node_name Prometheus ID swarm_node_name Legacy ID swarm.node.name OSS KSM ID - Category Swarm Description Additional Notes swarm_node_role Prometheus ID swarm_node_role Legacy ID swarm.node.role OSS KSM ID - Category Swarm Description Additional Notes swarm_node_state Prometheus ID swarm_node_state Legacy ID swarm.node.state OSS KSM ID - Category Swarm Description Additional Notes swarm_node_version Prometheus ID swarm_node_version Legacy ID swarm.node.version OSS KSM ID - Category Swarm Description Additional Notes swarm_service_id Prometheus ID swarm_service_id Legacy ID swarm.service.id OSS KSM ID - Category Swarm Description Additional Notes swarm_service_name Prometheus ID swarm_service_name Legacy ID swarm.service.name OSS KSM ID - Category Swarm Description Additional Notes swarm_task_container_id Prometheus ID swarm_task_container_id Legacy ID swarm.task.container_id OSS KSM ID - Category Swarm Description Additional Notes swarm_task_id Prometheus ID swarm_task_id Legacy ID swarm.task.id OSS KSM ID - Category Swarm Description Additional Notes swarm_task_name Prometheus ID swarm_task_name Legacy ID swarm.task.name OSS KSM ID - Category Swarm Description Additional Notes swarm_task_node_id Prometheus ID swarm_task_node_id Legacy ID swarm.task.node_id OSS KSM ID - Category Swarm Description Additional Notes swarm_task_service_id Prometheus ID swarm_task_service_id Legacy ID swarm.task.service_id OSS KSM ID - Category Swarm Description Additional Notes swarm_task_state Prometheus ID swarm_task_state Legacy ID swarm.task.state OSS KSM ID - Category Swarm Description Additional Notes ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/labels/"},{"id":399,"title":"Compliance Legacy Versions","content":" This version is retired for SaaS users from March 15, 2023. Benchmark results can be viewed in the new compliance module.\nThe deprecation notice does not apply to on-prem users.\nIn Jan. 2022, Sysdig Secure has unified and simplified the Compliance interface.\nFrom a single page, you can now:\nScope all types of reports\nScope across both host and cloud* platforms (workload*, Kubernetes, AWS, GCP, etc.)\nSelect any or all compliance frameworks (CIS AWS, CIS Azure, NIST, HIPAA, etc.)\nFine-tune selections by compliance framework version\nCreate/Enable/Disable reports\nSchedule a new report task for any of the available frameworks or platforms Enable/disable existing tasks Review all scheduled tasks and the resulting reports\nAt-a-glance summary of compliance status across the entire environment\nClick-down from the summary to review pass/fail/remediation details\nBenchmark tasks are now treated as just another compliance task, within the same interface\nNo need to configure or reference the Legacy Benchmarks module once unified compliance is switched on *Terminology note: Compliance standards are scoped to different platforms depending on the specific security rules they include. Broadly, these are divided into:\nWorkload types: Including any Falco rules for kernel system calls, Falco rules for Kubernetes audit logs, host benchmarks, and security features that affect hosts, containers, and kubernetes clusters\nCloud type: Falco rules for CloudTrail and Cloud Custodian rules on AWS, or for GCP, Azure, and other cloud providers as they are added.\nEnable Unified Compliance UIPrerequisites Agent version \u0026gt;= 12.0.4\nIf necessary, install or upgrade your agent to the appropriate version.\nNode analyzer installed\nWhen these two prerequisites are met, the UI for unified compliance will be automatically deployed.\nNOTE: If you are upgrading from an earlier version of Sysdig Secure, your existing compliance and benchmark records will be migrated to the new version and retained on the same schedule as before.\nUse Compliance ReportsAccess the Compliance ModuleClick the Posture icon in the left-hand navigation and select either All Platforms or an individual platform under Compliance.\nSchedule New Task Click +Schedule New from the top-right corner of a Compliance landing page, or choose Posture \u0026gt; New Report from the nav bar.\nChoose the desired framework from the list presented and click Schedule.\n(Note that if a framework already has a scheduled task, you can view that report from here as well.)\nConfigure the report details:\nReport Name: Assign a name to the scheduled task Framework: Auto-filled from the selection you made, or choose a different framework Version: Select from the drop-down as needed Platform: Only applicable options will appear in the drop-down menu, based on the framework chosen Scope: Select Entire Infrastructure or an appropriate subscope from the drop-down menu Schedule: Choose Daily, Weekly, or Monthly and the time at which the task should be run and the report generated. Click Schedule Report. At the designated schedule, the task will run and the report will be displayed on the Compliance landing page.\nReview a Report Navigate to the Compliance list from the Posture menu.\nSelect a report from the list to view the Report details. The top section of the page presents the compliance report summary, with the Pass|Fail summary data.\nReport Date: The most current report is displayed; select a different date/time from the drop-down to see an earlier version.\nExpand relevant details: For example, click any Failing Controls in the summary at the top of the page and then expand to review the resources that are failing and find the suggested fixes.\nFrameworks and Controls Implemented At this time, Charmed Kubernetes is not supported.\nAWS Foundational Security Best Practices v1 (FSBP) ComplianceThe AWS Foundational Security Best Practices standard is a set of controls that detect when your deployed accounts and resources deviate from security best practices. The standard allows you to continuously evaluate all of your AWS accounts and workloads to quickly identify areas of deviation from best practices. It provides actionable and prescriptive guidance on how to improve and maintain your organization\u0026rsquo;s security posture. The controls include best practices from across multiple AWS services.\nFor AWS protection, Sysdig Secure will check the following sections: AutoScaling.1, CloudTrail.1, Config.1, EC2.6, CloudTrail.2, DMS.1, EC2.1, EC2.2, EC2.3, ES.1, IAM.1, IAM.2, IAM.4, IAM.5, IAM.6, IAM.7, Lambda.2, GuardDuty.1\nAWS Well Architected Framework ComplianceThe AWS Well Architected Framework helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for a variety of applications and workloads. Built around six pillars—operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability—AWS Well-Architected provides a consistent approach for customers and partners to evaluate architectures and implement scalable designs.\nFor workload protection, Sysdig Secure will check the following sections: OPS 4, OPS 5, OPS 6, OPS 7, OPS 8, SEC 1, SEC 5, SEC 6, SEC 7, REL 2, REL 4, REL 5, REL 6, REL 10, PERF 5, PERF 6, PERF 7\nFor AWS protection, Sysdig Secure will check the following sectionsOPS 6, SEC 1, SEC 2, SEC 3, SEC 8, SEC 9, REL 2, REL 9, REL 10\nFedRAMP ComplianceFedRAMP is a government-wide program that promotes the adoption of secure cloud services across the federal government by providing a standardized approach to security and risk assessment for cloud technologies and federal agencies. FedRAMP empowers agencies to use modern cloud technologies, with an emphasis on security and protection of federal information.\nFor workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-6(1), AC-6(2), AC-6(3), AU-2, AU-6, AU-10, AU-12, CM-3(6), CM-7, CM-7(1), SA-10, SC-8, SC-8(1), SI-3, SI-4(4)\nFor AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AU-8, SC-8(1)\nFor Google Cloud protection, Sysdig Secure will check the following sections: AC-6(1), AC-6(2), AC-6(3), AU-9(2), AU-12(1), CM-3(1), SC-7(4)\nFor Azure protection, Sysdig Secure will check the following sections: AC-2, AU-8\nGDPR ComplianceThe General Data Protection Regulation 2016/679 (GDPR) is a regulation for data protection and privacy in the European Union (EU) and the European Economic Area (EEA). It also addresses the transfer of personal data outside the EU and EEA areas.\nFor workload protection, Sysdig Secure will check the following sections: 5.1, 5.2, 24.1, 24.2, 24.3, 25.1, 25.2, 25.3, 32.1, 32.2, 40.2\nFor AWS protection, Sysdig Secure will check the following sections: 5.1, 5.2, 24.1, 24.2, 24.3, 25.1, 25.2, 25.3, 30.1, 30.2, 30.3, 30.4, 30.5, 32.1, 32.2, 40.2\nFor Google Cloud protection, Sysdig Secure will check the following sections: 25.1, 25.2, 25.3, 32.1, 32.2\nFor Azure protection, Sysdig Secure will check the following sections: 25.1, 25.2, 25.3, 32.1, 32.2\nHIPAA ComplianceThe Health Insurance Portability and Accountability Act (HIPAA) sets the standard for protecting sensitive patient data. Companies dealing with Protected Health Information (PHI) must have and comply with physical, network, and technology security measures to maintain HIPAA compliance. Any entity providing health care treatment, payment, and operations, as weel as any entity who has access to patient information and provides support for treatment, payment, or operations must comply with HIPAA requirements. Other organizations such as subcontractors and any other related business partners must also comply.\nFor workload protection, Sysdig Secure will check the following sections: 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(4)(i), 164.308(a)(4)(ii)(A), 164.308(a)(4)(ii)(B), 164.308(a)(4)(ii)(C), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.310(a)(2)(iii), 164.310(b), 164.312(a)(1), 164.312(a)(2)(i), 164.312(a)(2)(ii), 164.312(a)(2)(iv), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(d), 164.312(e)(2)(i), 164.312(e)(2)(ii)\nFor AWS protection, Sysdig Secure will check the following sections: 164.308(a)(1)(ii)(D), 164.308(a)(3)(i), 164.308(a)(3)(ii)(A), 164.308(a)(3)(ii)(B), 164.308(a)(4)(i), 164.308(a)(4)(ii)(A), 164.308(a)(4)(ii)(B), 164.308(a)(4)(ii)(C), 164.308(a)(5)(ii)(B), 164.308(a)(5)(ii)(C), 164.308(a)(8), 164.310(b), 164.312(a)(1), 164.312(a)(2)(i), 164.312(a)(2)(ii), 164.312(b), 164.312(c)(1), 164.312(c)(2), 164.312(e)(2)(i)\nFor Google Cloud protection, Sysdig Secure will check the following sections: 164.310(b), 164.312(b), 164.312(d)\nHITRUST CSF v9.4.2 ComplianceThe HITRUST Common Security Framework (CSF) provides the structure, transparency, guidance, and cross-references to authoritative sources organizations globally need to be certain of their data protection compliance. It leverages nationally and internationally accepted security and privacy-related regulations, standards, and frameworks–including ISO, NIST, PCI, HIPAA, and GDPR–to ensure a comprehensive set of security and privacy controls and continually incorporates additional authoritative sources. The HITRUST CSF standardizes these requirements, providing clarity and consistency and reducing the burden of compliance.\nFor workload protection, Sysdig Secure will check the following sections: 01.b, 01.c, 01.i, 01,j, 01.k, 01.l, 01.m, 01.n, 01.o, 01.p, 01.q, 01.s, 01.v, 01.w, 01.x, 01.y, 03.d, 05.i, 06.h, 06.i, 06.j, 09.b, 09.i, 09.j, 09.k, 09.m, 09.n, 09.s, 09.v, 09.w, 09.x, 09.y, 09.z, 09.aa, 09.ab, 09.ac, 09.ad, 09.ae, 10.c, 10.d, 10.g, 10.h, 10.j, 10.k, 10.m, 11.a, 11.b\nFor AWS protection, Sysdig Secure will check the following sections: 01.c, 01.i, 01.p, 01.s, 01.v, 01.x, 01.y, 05.i, 06.i, 09.m, 09.v, 09.x, 09.ac, 09.af, 10.j, 11.b\nFor Google Cloud protection, Sysdig Secure will check the following sections: 01.c, 01,j, 01.n, 01.q, 01.y, 05.i, 06.d, 06.j, 09.m, 09.s, 10.g, 10.k\nFor Azure protection, Sysdig Secure will check the following sections: 01.x, 09.m, 09.ac, 09.af, 11.b\nISO 27001:2013 ComplianceThe ISO/IEC 27001:2013 is an international standard on how to manage information security. It details requirements for establishing, implementing, maintaining and continually improving an information security management system (ISMS).\nFor workload protection, Sysdig Secure will check the following sections: A.6.1.2, A.8.1.1, A.8.1.2, A.8.1.3, A.9.1.2, A.9.2.3, A.9.4.1, A.9.4.4, A.10.1.1, A.12.1.2, A.12.4.1, A.12.5.1, A.12.6.1, A.12.6.2, A.13.1.1, A.13.1.2, A.13.1.3, A.14.1.2, A.14.2.2, A.14.2.4, A.18.1.3, A.18.1.5\nFor AWS protection, Sysdig Secure will check the following sections: A.6.1.2, A.9.1.1, A.9.1.2, A.9.2.3, A.9.2.5, A.9.4.2, A.9.4.3, A.10.1.1, A.10.1.2, A.12.1.2, A.13.1.1, A.14.1.2, A.18.1.3, A.18.1.5\nFor Google Cloud protection, Sysdig Secure will check the following sections: A.6.1.2, A.9.1.2, A.9.2.3, A.10.1.2, A.18.1.3, A.18.1.5\nFor Azure protection, Sysdig Secure will check the following sections: A.9.1.2, A.9.4.2, A.10.1.1, A.13.1.1, A.14.1.2, A.18.1.3, A.18.1.5\nNIST 800-53 rev4 and rev5 ComplianceThe National Institute of Standards and Technology (NIST) Special Publication 800-53 revision 4 describes the full range of controls required to pass a NIST 800-53 audit.\nFor workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-3, AC-4, AC-4(17), AC-6, AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(6), AC-6(9), AC-6(10), AC-14, AC-17, AC-17(1), AC-17(3), AC-17(4), AU-2, AU-6, AU-6(8), AU-10, AU-12, CA-9, CM-3, CM-3(6), CM-5, CM-7, CM-7(1), CM-7(4), IA-3, SA-10, SA-15(10), SC-2, SC-4, SC-7, SC-7(3), SC-7(10), SC-8, SC-8(1), SC-12(3), SC-17, SC-39, SI-3, SI-3(1), SI-3(2), SI-4, SI-4(2), SI-4(4), SI-4(11), SI-4(13), SI-4(18), SI-4(20), SI-4(22), SI-4(23), SI-4(24), SI-7, SI-7(3), SI-7(9), SI-7(11), SI-7(12), SI-7(13), SI-7(14), SI-7(15)\nFor AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-4, AC-6, AC-6(9), AU-6(8), AU-8, CA-7, CM-6, SC-8(1), SI-4, SI-12\nFor Google Cloud protection, Sysdig Secure will check the following sections: AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(9), AC-6(10), AC-17(1), AC-17(2), AC-17(3), AU-6(8), AU-9(2), AU-12(1), CM-3(1), IA-2(12), SC-7(3), SC-7(4), SC-7(5), SC-7(8), SC-7(21), SC-12(1)\nFor Azure protection, Sysdig Secure will check the following sections: AC-2, AU-8, SI-4\nSpecial Publication 800-53 revision 5 was published in September 2020 and includes some modifications. For 12 months both revisions will be valid, and revision 4 will be deprecated in September 2021.\nFor workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-3, AC-4, AC-4(17), AC-6, AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(6), AC-6(9), AC-6(10), AC-14, AC-17, AC-17(1), AC-17(3), AC-17(4), AC-17(10), AU-2, AU-6, AU-6(8), AU-10, AU-12, CA-3(6), CA-7(4), CA-7(5), CA-9, CM-3, CM-3(6), CM-3(7), CM-3(8), CM-4, CM-4(2), CM-5, CM-5(1), CM-7, CM-7(1), CM-7(4), CM-7(6), CM-7(7), CM-7(8), CM-8, CM-11(3), IA-3, MA-3(5), MA-3(6), PM-5(1), RA-3(4), RA-10, SA-10, SA-15(10), SA-23, SC-2, SC-4, SC-7, SC-7(3), SC-7(10), SC-7(25), SC-7(26), SC-7(27), SC-7(28), SC-7(29), SC-8, SC-8(1), SC-12(3), SC-17, SC-39, SC-50, SI-3, SI-4, SI-4(2), SI-4(4), SI-4(11), SI-4(13), SI-4(18), SI-4(20), SI-4(22), SI-4(23), SI-4(24), SI-4(25), SI-7, SI-7(3), SI-7(9), SI-7(12), SI-7(15)\nFor AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-4, AC-6, AC-6(9), AU-6(8), AU-8, SC-8(1), SI-4\nFor Google Cloud protection, Sysdig Secure will check the following sections: AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(9), AC-6(10), AC-17(1), AC-17(2), AC-17(3), AU-6(8), AU-9(2), AU-12(1), CM-3(1), IA-2(12), SC-7(3), SC-7(4), SC-7(5), SC-7(8), SC-7(21), SC-12(1)\nFor Azure protection, Sysdig Secure will check the following sections: AC-2, AU-8, SI-4\nNIST 800-82 rev2 ComplianceThe National Institute of Standards and Technology (NIST) Special Publication 800-82 revision 2 provides guidance on how to secure Industrial Control Systems (ICS), including Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), and other control system configurations such as Programmable Logic Controllers (PLC), while addressing their unique performance, reliability, and safety requirements.\nFor workload protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-2(12), AC-3, AC-4, AC-6, AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(9), AC-6(10), AC-17, AC-17(1), AC-17(3), AC-17(4), AU-2, AU-6, AU-10, AU-12, CA-9, CM-3, CM-5, CM-7, CM-7(1), IA-3, SA-10, SC-2, SC-4, SC-7, SC-7(3), SC-8, SC-8(1), SC-17, SC-39, SI-3, SI-3(1), SI-3(2), SI-4, SI-4(2), SI-4(4), SI-7, SI-7(14)\nFor AWS protection, Sysdig Secure will check the following sections: AC-2, AC-2(4), AC-4, AC-6, AC-6(9), AU-8, SC-8(1), SI-4.\nFor Google Cloud protection, Sysdig Secure will check the following sections: AC-6(1), AC-6(2), AC-6(3), AC-6(5), AC-6(9), AC-6(10), AC-17(1), AC-17(2), AC-17(3), AU-9(2), AU-12(1), CM-3(1), IA-2(12), SC-7(3), SC-7(4), SC-7(5), SC-7(8), SC-7(21), SC-12(1)\nFor Azure protection, Sysdig Secure will check the following sections: AC-2, AU-8, SI-4\nNIST 800-171 rev2 ComplianceThe National Institute of Standards and Technology (NIST) Special Publication 800-171 revision 2 provides agencies with recommended security requirements for protecting the confidentiality of Controlled Unclassified Information (CUI) when the information is resident in nonfederal systems and organizations.\nFor workload protection, Sysdig Secure will check the following sections:3.1.1, 3.1.2, 3.1.3, 3.1.5, 3.1.6, 3.1.7, 3.1.12, 3.1.13, 3.1.14, 3.1.15, 3.1.16, 3.1.17, 3.1.20, 3.3.1, 3.3.2, 3.3.5, 3.3.8, 3.3.9, 3.4.3, 3.4.5, 3.4.6, 3.4.7, 3.4.9, 3.5.1, 3.5.2, 3.11.2, 3.12.1, 3.13.1, 3.13.2, 3.13.3, 3.13.4, 3.13.5, 3.13.6, 3.13.8, 3.14.1, 3.14.2, 3.14.3, 3.14.4, 3.14.5, 3.14.6, 3.14.7\nFor AWS protection, Sysdig Secure will check the following sections:3.1.1, 3.1.2, 3.1.3, 3.3.1, 3.3.2, 3.3.7, 3.5.7, 3.5.8, 3.14.6, 3.14.7\nFor Azure protection, Sysdig Secure will check the following sections: 3.1.1, 3.1.2, 3.3.7, 3.14.6, 3.14.7\nNIST 800-190 ComplianceThe National Institute of Standards and Technology (NIST) Special Publication 800-190 explains the potential security concerns associated with the use of containers and provides recommendations for addressing these concerns.\nFor workload protection, Sysdig Secure will check the following sections: 3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.2.1, 3.2.2, 3.3.1, 3.3.2, 3.3.3, 3.3.4, 3.3.5, 3.4.1, 3.4.2, 3.4.3, 3.4.4, 3.4.5, 3.5.2, 3.5.5\nPCI DSS v3.2.1The PCI Data Security Standard (DSS) Quick Reference describes the full range of controls required to pass a PCI 3.2 audit. In this release, Sysdig Secure will check the following subset:\nFor workload protection: 1.1.2, 1.1.3, 1.1.5, 1.1.6.b, 2.2, 2.2.a, 2.2.1, 2.2.2, 2.4, 2.6, 4.1, 6.1, 6.2, 6.4.2, 6.5.1, 6.5.6, 6.5.8, 7.2.3, 10.1, 10.2, 10.2.1, 10.2.5, 10.2.7, 10.5.5, 11.5.1\nFor AWS protection, Sysdig Secure will check the following sections: 2.2, 2.2.2, 10.1, 10.2.1, 10.2.2, 10.2.5, 10.2.6, 10.2.7, 10.5.5, 11.4\nFor Google Cloud protection, Sysdig Secure will check the following sections: 1.1.5, 7.1.2, 10.1, 10.2, 10.3\nFor Azure protection, Sysdig Secure will check the following sections: 2.2.2\nSOC2The American Institute of CPAs (AICPA) describes the full range of controls required to pass a SOC 2 audit.\nFor workload protection, Sysdig Secure will check the following sections: CC3.2, CC5.1, CC5.2, CC6.1, CC6.2, CC6.6, CC6.8, CC7.1, CC7.2, CC7.5, CC8.1, CC9.1\nFor AWS protection, Sysdig Secure will check the following sections: CC3.2, CC5.2, CC6.2, CC6.6, CC7.1, CC7.2\nFor Google Cloud protection, Sysdig Secure will check the following sections: CC5.2, CC6.1, CC6.2, CC6.6, CC7.1, CC8.1\nFor Azure protection, Sysdig Secure will check the following sections: CC5.2, CC6.1, CC6.6, CC7.2, CC8.1\nHistory of Compliance Components Compliance/Actionable Compliance: Offered for early review on May 31, 2022, now GA and called \u0026ldquo;Compliance\u0026rdquo;\nCompliance (Unified): Since Jan. 26, 2022 in SaaS. Retired for SaaS users and still used by On-Premises installations.\nCompliance (Legacy): Deprecated\nBenchmarks (Legacy) and Benchmarks (v1): Deprecated\nMigration GuideFor users migrating to the new Compliance module, released January, 2023:\nStarting January 17th, SaaS customers that connect new data sources for Sysdig cloud accounts or Sysdig agents will automatically have the new Compliance module (previously known as “Actionable Compliance”) enabled. Resources of the connected data sources will be evaluated according to CSPM/Risk and Compliance policies that are applied on zones. Results are displayed about 5-10 minutes after connection, varying by the scale of the resources.\nIf you were using Unified Compliance:\nFor Existing Kubernetes clusters: ensure that your applied helm charts are updated according to the KSPM Components guide. For Existing GCP cloud accounts, enable the Cloud Asset API. The new Compliance module will be auto-enabled on your existing Cloud accounts by January 26th. Currently, the CSPM Compliance module is not available for On-premises and IBM Cloud users who can continue using Unified Compliance.\n","url":"https://docs.sysdig.com/en/sysdig-secure/compliance-legacy/"},{"id":400,"title":"Manage Console Logging for Agent Components","content":"By controlling logging at the fine-grained component level, you can avoid excessive logging from certain components in draios.log or enable extra logging from specific components for troubleshooting.\nComponents can also have an optional feature level logging that can provide a way to control the logging for a particular feature in Sysdig Agent.\nConfigure LoggingTo set feature-level or component-level logging:\nDetermine the agent component you want to set the log level:\nTo do so,\nLook at the console output.\nIf you\u0026rsquo;re using an orchestrator like Kubernetes, the log viewer facility, such as the kubectl log command, shows the console log output.\nCopy the component name.\nThe format of the log entry is:\n\u0026lt;timestamp\u0026gt;, \u0026lt;\u0026lt;pid\u0026gt;.\u0026lt;tid\u0026gt;\u0026gt;, \u0026lt;log level\u0026gt;, [feature]:\u0026lt;component\u0026gt;[pid]:[line]: \u0026lt;message\u0026gt; For example, the given snippet from a sample log file shows log messages from promscrape feature, sdjagent, mountedfs_reader, watchdog_runnable, protobuf_file_emitter, connection_manager, and dragent.\n2020-09-07 17:56:01.173, 27979.28018, Information, sdjagent[27980]: Java classpath: /opt/draios/share/sdjagent.jar 2020-09-07 17:56:01.173, 27979.28018, Information, mountedfs_reader: Starting mounted_fs_reader with pid 27984 2020-09-07 17:56:01.174, 27979.28019, Information, watchdog_runnable:105: connection_manager starting 2020-09-07 17:56:01.174, 27979.28019, Information, protobuf_file_emitter:64: Will save protobufs for all message types 2020-09-07 17:56:01.174, 27979.28019, Information, connection_manager:282: Initiating connection to collector 2020-09-07 17:56:01.175, 27979.27979, Information, dragent:1243: Created Sysdig inspector 2020-09-07 18:52:40.065, 27979.27980, Debug, promscrape:prom_emitter:72: Sent 927 Prometheus metrics of 7297 total 2020-09-07 18:52:41.129, 27979.27981, Information, promscrape:prom_stats:45: Prometheus timeseries statistics, 5 endpoints To set feature-level logging:\nOpen /opt/draios/etc/dragent.yaml.\nEdit the dragent.yaml file and add the desired feature:\nIn this example, you are setting the global level to notice and promscrape feature level to info.\nlog: console_priority: notice console_priority_by_component: - \u0026#34;promscrape: info\u0026#34; The log levels specified for feature override global settings.\nTo set component-level logging:\nOpen /opt/draios/etc/dragent.yaml.\nEdit the dragent.yaml file and add the desired feature:\nIn this example, you are setting the global level to notice and promscrape feature level to info, sdjagent, mountedfs_reader component log level to debug, watchdog_runnable component log level to warning and promscrape:prom_emitter component log level to debug.\nlog: console_priority: notice console_priority_by_component: - \u0026#34;promscrape: info\u0026#34; - \u0026#34;promscrape:prom_emitter: debug\u0026#34; - \u0026#34;watchdog_runnable: warning\u0026#34; - \u0026#34;sdjagent: debug\u0026#34; - \u0026#34;mountedfs_reader: debug\u0026#34; The log levels specified for feature override global settings. The log levels specified for component override feature and global settings.\nRestart the agent.\nFor example, if you have installed the agent as a service, then run:\n$ service dragent restart Agent Components analyzer: The logs from this component provide information about events and metrics as they come into the system. These logs assist in basic troubleshooting of event flow.\nconnection_manager: This component logs details about the agent\u0026rsquo;s connection to the Sysdig backend. These logs help diagnose and troubleshoot connectivity issues.\nsecurity_mgr: These logs describe the security processing steps the agent is taking. Having these logs assists in understanding what the security side of the agent is doing.\ninfrastructure_state: This component interacts with the orchestration runtime to provide a view of the infrastructure. The logs from this component help troubleshoot orchestration issues and communication with the API server.\nprocfs_parser: The agent uses the procfs parser to gather information about the state of the system. These logs provide insight into the functioning of the agent.\ndragent: These logs provide data about the core functionality of the agent.\nprocess_emitter: This component is used to provide data regarding processes running on a host.\nk8s_parser: The k8s_parser is used as part of the communication with the Kubernetes API server. These logs help debug communication issues.\nnetsec: These logs provide data about the functioning of the netsec component, which provides topology and endpoint security functionality.\nprotocol_handler: This component logs information about the protobufs the agent sends to the Sysdig backend.\nk8s_deleg: Kubernetes uses the concept of delegated nodes to help reduce cluster load and manage distributed systems. These logs help with troubleshooting issues within the Kubernetes distributed environment.\npromscrape: Promscrape allows the agent to send prometheus data as custom metrics.\ncm_socket: The cm_socket is the low-level networking code used by the connection_manager. These logs work together with the logs from the connection_manager to show the behavior of the network connection between the agent and the backend.\nsecure_audit: Audit is a feature of Sysdig Secure which provides information on system activity such as file and network behavior. These logs help understand the behavior of that feature.\nmemdumper: The memdumper is used to perform back-in-time captures, and logs from this component help troubleshoot any problems which might occur with back-in-time captures.\n","url":"https://docs.sysdig.com/en/sysdig-secure/manage-console-logging-classic-agent/"},{"id":401,"title":"Manage Custom Roles","content":"PrerequisitesCustom roles are supported in:\nSysdig SaaS Sysdig On-Prem version 6.0 or later. Understand Custom RolesCustom roles let you grant granular access to users based on a selected set of permissions. If the default user and team roles don\u0026rsquo;t meet your organization\u0026rsquo;s needs, you can create your own custom roles.\nCustom roles let you:\nSelect the permissions you want users to have based on their access to resources. Restrict access of users to only the necessary resources. Assign roles to users and teams, like built-in Sysdig roles. Custom roles follow principles similar to role-based access control (RBAC) systems.\nBenefits of Using Custom RolesCustom roles allow you to:\nGive access to a specific set of predefined dashboards, while restricting users from modifying or sharing the dashboards, or viewing any additional data.\nCreate service accounts for Sysdig Secure that are not tied to a particular user, for use in automating your Continuous Integration and Continuous Deployment (CI/CD) pipeline.\nGive a custom set of permissions to the CI/CD account. Give permission to create these accounts to a certain set of users. Identify the owner of a particular image so the security issue can be assigned to the team who owns the issue.\nCreate a team role that can invite users but not manage the team.\nCreate a Custom Role Log in to Sysdig Monitor or Sysdig Secure as administrator.\nSelect Settings \u0026gt; Access \u0026amp; Secrets \u0026gt; Roles.\nClick New Role. The New Role page is displayed.\nSpecify the following:\nRole Name: A unique name to identify the role you create. Role Description: A short explanation of the role that you have created. Product: Choose whether the role is for Secure, Monitor, or both. Select the features and do one of the following:\nFrom the drop-down, select one of the following: No Access, Read Only, Full Access, or Custom. Click Customize to grant granular permissions to a sub-set of features. This is an alternative to clicking Custom from the drop-down. See Custom Roles and Privileges for a detailed outline of the options. Click Save to create the role.\nAssign a Custom Role to TeamsYou can set up a custom role as the default user role for teams. To do so:\nLog in to Sysdig Monitor or Sysdig Secure as administrator and select Admin.\nSelect Teams.\nDo one of the following:\nSelect the relevant team from the list of teams. Click Add Team. From the Default User Role drop-down, select one of the custom role you have created.\nComplete creating or editing the team as described in Manage Teams and Roles.\nClick Save.\nCustom Roles and PrivilegesWhen creating a custom role, you can select Customize to grant granular permissions for each product feature. The following table details the options:\nSysdig Monitor Category Item Permission Description Overview/Insights Overview/Insights Read Access Overview/Advisor Dashboards Dashboard Read Access dashboards in scope of a team Edit Modify dashboards in scope of a team Dashboard Metrics Data Read N/A Explore/Metrics Agent Console View Use Agent Console commands Agent Console - Agent Status Read Use Agent Console commands which access agent status Agent Console - Configuration View Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Diagnostics Read Use Agent Console commands which access internal diagnostics of the agent Agent Console - Network Calls Exec Use Agent Console commands which make network calls to remote pods and endpoints Agent Console - Sensitive Configuration View Use Agent Console commands to view the configuration of the agent which does contain sensitive information like passwords. There are currently no commands that implement this permission Explore Read Metric querying with Explore Edit N/A LiveLogs View Access LiveLogs feature Shared Groupings with Team Toggle Share metrics grouping with the team Alerts Alert Events Read Access the events generated by triggered alerts in scope of a team Edit Acknowledge an event triggered by an alert in the events feed in scope of a team Alerts Read Access the alerts in scope of a team Edit Modify alerts in scope of a team Events Custom Events Read Access the infrastructure \u0026amp; other events created by Sysdig Agent or Sysdig API Edit Acknowledge the infrastructure and other events created by Sysdig Agent or Sysdig API Captures / Investigate Captures View View captures in the UI Read Access captures Edit Modify captures Settings API Access Token View View your API token Read Access users API token in scope of a team Edit Reset users API token in scope of a team AWS Settings Read Access Amazon Web Service (AWS) settings Agent Installation Read Get agent access key (required for agent installation) Alert Downtimes Read List alert downtimes for the customer Global Notification Channels Read Access global notification channels Notification Channels Read Access notification channels in scope of a team Edit Modify notification channels in scope of a team Service Accounts Read Access service accounts in scope of a team Edit Modify service accounts in scope of a team Subscriptions Read Access customer subscription details Sysdig Storage Read View Sysdig storage configuration Team Agent Console Access Toggle Read See the agent console access settings for a team Edit Toggle access to agent console for a team Team Captures Access Toggle Read See the capture settings for a team Edit Toggle access to captures for a team Team Membership Read Access team members Edit Modify team members Team Membership Roles Edit Modify team members role Teams Manage Modify team settings without the ability to modify team membership for users Users Read Access existing users data Create Invite new users Users List Read See the list of users for a customer Integrations Custom Integrations Read Access custom integrations in spotlight Edit Modify custom integrations in spotlight Infrastructure Read View discovered infrastructure Integrations Read View discovered workload integrations Monitoring Integrations Validate Change monitoring integration status to Pending Metrics Edit Change monitoring integration type or status Providers Read N/A Spotlight Read Access spotlight Data Access Settings Datastream Read Access data stream configuration Groupings Read Access default and custom groupings Edit Create and edit custom groupings Metadata Read N/A Metrics Data Read Access metrics data Metrics Descriptors Read Access metrics descriptors PromQL Metadata Read Access Prometheus metrics and labels Sysdig Secure Category Item Permission Description Risks Access to risk feature Write Ability to create custom risk rules. Read Ability to read Risks. Inventory / Search Access to sysql api Api Ability to access sysql api. Access to graph search View Ability to access graph search. Export Ability to export data from graph search. Access to inventory View Ability to access inventory. Export Ability to export data from inventory. Vulnerability Management CLI Execution Exec Ability to run the CLI Scanner. Policy Write Create and edit policies. Read View policy details. Registry Credentials Write Ability to add and modify registry credentials. Read Ability to list registry credentials. Registry Scanner Exec Ability to run the Registry Scanner Reporting Write Create, modify, and delete reports. Read View and download scan reports. Risk Acceptance Write Create, modify, and remove exceptions. Read View exceptions. Scan Now Exec Ability to instantly scan by using Scan Now. Scan Results Read View scan results on the Pipeline, Runtime, and Registry UI as well as list and get results from the public API. Retrieve SBOM results from the SBOM API. Scanning (Legacy) Image Import Edit Import scanning images Scanning Write Modify scanning alerts and registry credentials Read Access scan results Exec Execute backend scanning Scanning Alerts Read Access scanning alerts Edit Modify scanning alerts Scanning Image Results Read List scanning images Create Create scanning events Scanning Policies Read Access security policies Edit Modify security policies Scanning Policy Assignments Read Access policy mappings Edit Create and modify policy mappings Scanning Registry Credentials Read List container registries Edit Create and modify container registries configuration Scanning Runtime Edit Query runtime containers API (API only, not enforced in UI) Scanning Scheduled Reports Read View and download existing reports Edit Create and modify reports Scanning Trusted Images Read Access the trusted images list Edit Modify the trusted images list Scanning Untrusted Images Read Access the untrusted images list Edit Modify the untrusted images list Scanning Vulnerability Exceptions Read Access vulnerability exceptions Edit Edit vulnerability exceptions Posture Compliance Read Access Compliance Results Open PR Edit Create Pull request from posture remediation panel Risk Acceptance Read Access Posture Risk Acceptance management page Edit Accept posture findings, revoke and edit acceptances Legacy Benchmark Tasks Read Access scheduled legacy Compliance tasks Edit Create and modify scheduled legacy Compliance tasks Legacy Benchmarks Read Access legacy Compliance results Legacy Compliance Read Access Legacy Compliance tasks and reports Policies Image profiling Write Write image profiles Read View existing image profiles Exec Execute image profiling Policy Advisor Write Create Pod Security Policy (PSP) advisor simulation Read Read PSP advisor simulations Exec Execute PSP advisor simulation Posture Controls Read View posture controls Edit Create and modify posture controls Posture Policies Read View posture policies Edit Create and modify posture policies Runtime Policies Read Access policies Edit Modify policies Zones Read View Zones that are assigned to current team Edit Modify Zones Network Security Network Security Read Access Kubernetes Network Security policy advisor Integrations Providers Read N/A Settings API Access Token View View your API token Read Access users API token in scope of a team Edit Reset users API token in scope of a team AWS Settings Read Access AWS settings Agent Installation Read Get agent access key (required for agent installation) Cloud Accounts Read Access cloud accounts Edit Edit cloud accounts Events Forwarder Read Access event forwarding configuration Global Notification Channels Read Access global notification channels Notification Channels Read Access notification channels in scope of a team Edit Modify notification channels in scope of a team Service Accounts Read Access service accounts in scope of a team Edit Modify service accounts in scope of a team Subscriptions Read Access customer subscription details Sysdig Secure Settings Edit Modify Sysdig Secure configuration Sysdig Storage Read View Sysdig storage configuration Team Agent Console Access Toggle Read See the agent console access settings for a team Edit Toggle access to agent console for a team Team Captures Access Toggle Read See the capture settings for a team Edit Toggle access to captures for a team Team Membership Read Access team members Edit Modify team members Teams Manage Modify team settings without the ability to modify team membership for users Users Read Access existing users data Create Invite new users Users List Read See the list of users for a customer Captures / Investigate Activity Audit Commands Read Access activity audit commands Captures View View captures in the UI Read Access captures Edit Modify captures Containment Response Actions Read View Containment Response Actions executions, their outcomes and the artifacts produced Exec Execute Containment Response Actions Data Gathering Response Actions Read View Data Gathering Response Actions executions, their outcomes and the artifacts produced Exec Execute Data Gathering Response Actions Rapid Response Exec Use rapid response Data Access Settings Groupings Read Access default and custom groupings Metrics Data Read Access metrics data Metrics Descriptors Read Access metrics descriptors Events Policy Events Read Access policy events ","url":"https://docs.sysdig.com/en/administration/roles-administration/"},{"id":402,"title":"Mapping LDAP Users to Sysdig Teams","content":"LDAP support in the Sysdig on-premises platform allows user authentication via credentials stored in your own directory server. Once LDAP authentication is configured, the optional mapping feature can be used to map groups of users from your directory to Sysdig teams.\nHow It WorksAfter basic LDAP integration, records in the Sysdig user database are automatically created when users successfully authenticate via LDAP the first time. Then, a Sysdig Admin could add/remove them from Sysdig teams and change their roles in those teams.\nTo eliminate this manual workflow, LDAP mapping provides a policy-driven, automated way to use relevant information from your directory to affect the lifecycle of such users/teams. This is achieved by creating LDAP-mapping rules that identify groups of users in your directory and port them to Sysdig\u0026rsquo;s database, specifying teams in which they should be members and their roles in those teams. LDAP-mapping rules trigger the automatic creation of such users and teams in the Sysdig platform database, and ongoing synchronization ensures the Sysdig platform database always reflects the current state of your directory, such as when users are deleted from your directory or are no longer members of a group.\nProcess Overview Configure Basic LDAP.\nNote that in the process, you modify env.sh with token and authentication credentials.\nDownload Helper Scripts.\nConfigure settings_mapping_simple.json.\nDeploy mapping_config.sh file (various options).\nPrerequisitesConfigure Basic LDAP Have \u0026ldquo;super\u0026rdquo; admin credentials available.\nSee Find the Super Admin Credentials and API Token.\nConfigure basic LDAP integration and ensure users can log in successfully via LDAP.\nThe script-based option is usually employed. The steps include modifying the env.sh to add your environment URL and authorization token.\nDownload Helper ScriptsScripts and sample files are found in GitHub:\nSample .json to modify: settings_mapping_simple.json\nHelper script: mapping_config.sh\nConfigure settings_mapping_simple.jsonNote that if you only want to create users via LDAP and map them to Sysdig teams, use the settings_mapping_simple.json.\nIf you want to map users and also enable log on through SAML single-sign-on, use the settings_mapping_hybrid.json.\nStructure of settings_mapping_simple.json{ \u0026#34;ldapTeamMapping\u0026#34;: [ { \u0026#34;ldapFilterSettings\u0026#34;: { \u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Viewers,CN=Users,DC=example,DC=local)(sAMAccountName=*))\u0026#34;, \u0026#34;searchBase\u0026#34;: \u0026#34;cn=Users\u0026#34; }, \u0026#34;teams\u0026#34;: [ \u0026#34;Viewers\u0026#34; ], \u0026#34;teamRole\u0026#34;: \u0026#34;ROLE_TEAM_READ\u0026#34;, \u0026#34;usernameAttribute\u0026#34;: \u0026#34;sAMAccountName\u0026#34; }, { \u0026#34;ldapFilterSettings\u0026#34;: { \u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Editors,CN=Users,DC=example,DC=local)(sAMAccountName=*))\u0026#34;, \u0026#34;searchBase\u0026#34;: \u0026#34;cn=Users\u0026#34; }, \u0026#34;teams\u0026#34;: [ \u0026#34;Editors1\u0026#34;, \u0026#34;Editors2\u0026#34; ], \u0026#34;teamRole\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34;, \u0026#34;usernameAttribute\u0026#34;: \u0026#34;sAMAccountName\u0026#34; }, { \u0026#34;ldapFilterSettings\u0026#34;: { \u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(givenName=Mary))\u0026#34;, \u0026#34;searchBase\u0026#34;: \u0026#34;cn=Users\u0026#34; }, \u0026#34;teams\u0026#34;: [ \u0026#34;Mixed\u0026#34; ], \u0026#34;teamRole\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34;, \u0026#34;usernameAttribute\u0026#34;: \u0026#34;sAMAccountName\u0026#34; }, { \u0026#34;ldapFilterSettings\u0026#34;: { \u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(sAMAccountName=jdoe))\u0026#34;, \u0026#34;searchBase\u0026#34;: \u0026#34;cn=Users\u0026#34; }, \u0026#34;teams\u0026#34;: [ \u0026#34;Mixed\u0026#34; ], \u0026#34;teamRole\u0026#34;: \u0026#34;ROLE_TEAM_READ\u0026#34;, \u0026#34;usernameAttribute\u0026#34;: \u0026#34;sAMAccountName\u0026#34; } ], \u0026#34;teamDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;Mixed\u0026#34;, \u0026#34;products\u0026#34;: [\u0026#34;SDC\u0026#34;], \u0026#34;show\u0026#34;: \u0026#34;host\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;Viewers\u0026#34;, \u0026#34;products\u0026#34;: [\u0026#34;SDC\u0026#34;], \u0026#34;show\u0026#34;: \u0026#34;host\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;Editors1\u0026#34;, \u0026#34;products\u0026#34;: [\u0026#34;SDC\u0026#34;], \u0026#34;show\u0026#34;: \u0026#34;host\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;Editors2\u0026#34;, \u0026#34;products\u0026#34;: [\u0026#34;SDC\u0026#34;], \u0026#34;theme\u0026#34;: \u0026#34;#FF5C49\u0026#34;, \u0026#34;show\u0026#34;: \u0026#34;container\u0026#34;, \u0026#34;filter\u0026#34;: \u0026#34;container.image contains \\\u0026#34;mysql\\\u0026#34;\u0026#34;, \u0026#34;canUseSysdigCapture\u0026#34;: false, \u0026#34;canUseCustomEvents\u0026#34;: false, \u0026#34;canUseAwsMetrics\u0026#34;: false, \u0026#34;entryPoint\u0026#34;: { \u0026#34;module\u0026#34;: \u0026#34;Dashboards\u0026#34; } } ], \u0026#34;dryRun\u0026#34;: true } ldapTeamMapping ParametersEach of the options in the first table is Required.\nldapTeamMapping Parameters Setting\nDescription\nldapFilterSettings\nSpecifies which users in the directory would be targets of this mapping rule. Includes two elements:\n- searchFilter (required): the Sysdig platform will use to identify the users that apply to this mapping rule.\n- searchBase (optional): the distinguished name for the point in the LDAP tree below which all search queries for this group of users will begin.\nExample:\n\u0026quot;searchFilter\u0026quot;: \u0026quot;(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Editors,CN=Users,DC=example,DC=local)(sAMAccountName=*))\u0026quot;, \u0026quot;searchBase\u0026quot;: \u0026quot;cn=Users\u0026quot; teams\nA list of names of Sysdig teams.\nThe group of mapped users found via the searchFilter will be made members of all these teams. The named team will be auto-created the first time synchronization is performed for a mapping rule that references it.\nExample:\n\u0026quot;teams\u0026quot;: [ \u0026quot;Web Devs\u0026quot;, \u0026quot;DBAs\u0026quot; } teamRole\nDefines the Roles that will be assigned to users who are mapped to the Sysdig teams defined in this rule.\nSee options: Integrating Users and Teams via API\nExample:\n\u0026quot;teamRole\u0026quot;: \u0026quot;ROLE_TEAM_EDIT\u0026quot; usernameAttribute\nThe LDAP attribute containing the username for users that may be auto-created in the Sysdig database as a result of this rule.\nIf LDAP authentication is enabled, shorter non-email-based usernames (such as typically found in the sAMAccountName attribute of Active Directory) may be used.\nEmail-based usernames (such as mail in Active Directory) are also supported.\nNOTE: If using LDAP/SAML Hybrid Authentication, you should use an email-based attribute for this setting to ensure successful matching against email-based usernames authenticated via SAML.\nldapTeamMapping Parameters\nThe Settings below define when and how synchronization is performed between your directory and the Sysdig database:\nLDAP Sync Process Settings Setting\nRequired\nDescription\ndryRun\nNo\nOptions: true false\nIf set to true, the configuration will be applied, but any subsequent sync will perform the LDAP query and update the report/log without actually performing the changes.\nIf not specified in the config, dryRun is set to false.\nThe sample mapping configurations set it to true to help you avoid mistakes while getting acquainted with configuring LDAP mappings. A good workflow would be\n- set dryRun to true when iterating new config changes,\n- check the sync report to see if it achieves the desired state,\n- apply the config again with dryRun set to false to trigger the actual changes to users/teams in the Sysdig database during the next sync.\nmaxAllowedMappedUsers\nNo\nOptions: A number 0 - 1000. Default = 100.\nIf specified, any sync that would result in greater than this number of LDAP-mapped users in the Sysdig database will be treated as a dry run. This is to protect against unintended creation of excess user counts as a result of syntax errors in filters. If not specified, will always be set to 100.\nsyncIntervalMinutes\nNo\nDefault value: 10 minutes\nSet to 0 to disable sync completely\nDefines how often the Sysdig platform will perform the queries defined in the mapping rules against your directory to ensure all user/team settings in the Sysdig database are current with recent updates to your directory.\nsyncTimeoutSeconds\nNo\nDefault value: 120 seconds\nThe maximum number of seconds to permit each LDAP synchronization operation to run. If the running time of a sync exceeds this amount, the backend log of the Sysdig platform will record an exception and all changes from the attempted sync will be rolled back.\nteamDefinitions Yes\nAn array that defines additional configurations for each Team referenced in the set of rules in the ldapTeamMapping array.\nAt minimum, this array must reference each Team by name in an element of the array, along with a Scope By setting (set to either \"host\" or \"container\") for that Team. Example:\n\u0026quot;teamDefinitions\u0026quot;: [ { \u0026quot;name\u0026quot;: \u0026quot;Mixed\u0026quot;, \u0026quot;show\u0026quot;: \u0026quot;host\u0026quot; } ] See table below for full list of options.\nLDAP Sync Process Settings\nteamDefinitions Settings Setting\nMeaning\nDescription\nid\nID of the team\nA number, automatically generated. User cannot set.\nname\nName of the team\nSysdig team name to be used (self-defined)\nshow\nThe scope to be shown\nOptions:\n\"host\" or \"container\"\n\"container\" if the team is based on scope of labels from containers, \"host\" if the team is based on scope of labels from hosts\nproducts\nSysdig Monitor or Sysdig Secure\nOptions:\n[\"SDC\"] for Monitor\n[\"SDS\"] for Secure\nNote that even though this field is an array, you CANNOT assign something like [\"SDC\", \"SDS\"]. If you want to sync both Monitor and Secure teams; you need to set them up separately\ntheme\nColor of the team\nOptional, as per https://htmlcolorcodes.com/\ndefaultTeamRole\nDefault role when adding user to the team\nAvailable with Sysdig Platform v 3.5.0\nSee options: Integrating Users and Teams via API\nExample:\n\u0026quot;defaultTeamRole\u0026quot;: \u0026quot;ROLE_TEAM_EDIT\u0026quot; canUseSysdigCapture\nTeam members allowed to take captures\nBoolean value\ncanUseCustomEvents\nTeam members receive infrastructure events\nSysdig Monitor only\ncanUseAwsMetrics\nTeam members can access AWS Cloudwatch metrics\nSysdig Monitor only\nentryPoint\nEntry point for team members\nCorresponds to UI element\nteamDefinitions Settings\nOptions for Applying mapping_config.shApply the LDAP configuration settings the JSON file using the mapping.config.sh.\nFor example:\nmapping_config.sh -s settings_mapping_simple.json The following sections provide examples for applying settings, forcing synchronization, deleting settings, and reporting status using mapping_config.sh.\nmapping_config.sh Option Summary Option\nDescription\nno option defined\nWill print the current configuration\n-s (with json filename)\nApply new settings\n-f\nForce a sync\n-r\nReport current state\n-d\nDelete settings\nUse with caution!\nmapping_config.sh Option Summary\nPrint Current ConfigurationOnce set, invoking mapping_config.sh with no options will print the current configuration. If you haven\u0026rsquo;t yet configured any mapping rules, the config shown will start out empty:\n# ./mapping_config.sh { \u0026#34;ldapSyncSettings\u0026#34;: { \u0026#34;dryRun\u0026#34;: false, \u0026#34;ldapTeamMapping\u0026#34;: [], \u0026#34;maxAllowedMappedUsers\u0026#34;: 100, \u0026#34;syncIntervalMinutes\u0026#34;: 10, \u0026#34;syncTimeoutSeconds\u0026#34;: 120, \u0026#34;teamDefinitions\u0026#34;: [], \u0026#34;version\u0026#34;: 1 } } Apply New Settings -sTo apply new mapping settings, invoke mapping_config.sh with the -soption and specify the filename containing the JSON config. If successful, the applied configuration will be echoed back by the API.\n# ./mapping_config -s settings_mapping_simple.json{\u0026#34;ldapSyncSettings\u0026#34;:{\u0026#34;version\u0026#34;:2,\u0026#34;ldapTeamMapping\u0026#34;:[{\u0026#34;ldapFilterSettings\u0026#34;:{\u0026#34;searchBase\u0026#34;:\u0026#34;cn=Users\u0026#34;,\u0026#34;searchFilter\u0026#34;:\u0026#34;(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Viewers,CN=Users,DC=example,DC=local)(sAMAccountName=*))\u0026#34;},\u0026#34;teams\u0026#34;:[\u0026#34;Viewers\u0026#34;],\u0026#34;teamRole\u0026#34;:\u0026#34;ROLE_TEAM_READ\u0026#34;,\u0026#34;usernameAttribute\u0026#34;:\u0026#34;sAMAccountName\u0026#34;},{\u0026#34;ldapFilterSettings\u0026#34;:{\u0026#34;searchBase\u0026#34;:\u0026#34;cn=Users\u0026#34;,\u0026#34;searchFilter\u0026#34;:\u0026#34;(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Editors,CN=Users,DC=example,DC=local)(sAMAccountName=*))\u0026#34;},\u0026#34;teams\u0026#34;:[\u0026#34;Editors1\u0026#34;,\u0026#34;Editors2\u0026#34;],\u0026#34;teamRole\u0026#34;:\u0026#34;ROLE_TEAM_EDIT\u0026#34;,\u0026#34;usernameAttribute\u0026#34;:\u0026#34;sAMAccountName\u0026#34;},{\u0026#34;ldapFilterSettings\u0026#34;:{\u0026#34;searchBase\u0026#34;:\u0026#34;cn=Users\u0026#34;,\u0026#34;searchFilter\u0026#34;:\u0026#34;(\u0026amp;(objectClass=organizationalPerson)(givenName=Mary))\u0026#34;},\u0026#34;teams\u0026#34;:[\u0026#34;Mixed\u0026#34;],\u0026#34;teamRole\u0026#34;:\u0026#34;ROLE_TEAM_EDIT\u0026#34;,\u0026#34;usernameAttribute\u0026#34;:\u0026#34;sAMAccountName\u0026#34;},{\u0026#34;ldapFilterSettings\u0026#34;:{\u0026#34;searchBase\u0026#34;:\u0026#34;cn=Users\u0026#34;,\u0026#34;searchFilter\u0026#34;:\u0026#34;(\u0026amp;(objectClass=organizationalPerson)(sAMAccountName=jdoe))\u0026#34;},\u0026#34;teams\u0026#34;:[\u0026#34;Mixed\u0026#34;],\u0026#34;teamRole\u0026#34;:\u0026#34;ROLE_TEAM_READ\u0026#34;,\u0026#34;usernameAttribute\u0026#34;:\u0026#34;sAMAccountName\u0026#34;}],\u0026#34;teamDefinitions\u0026#34;:[{\u0026#34;version\u0026#34;:0,\u0026#34;customerId\u0026#34;:0,\u0026#34;immutable\u0026#34;:false,\u0026#34;name\u0026#34;:\u0026#34;Mixed\u0026#34;,\u0026#34;show\u0026#34;:\u0026#34;host\u0026#34;,\u0026#34;origin\u0026#34;:\u0026#34;SYSDIG\u0026#34;,\u0026#34;products\u0026#34;:[\u0026#34;SDC\u0026#34;],\u0026#34;entryPoint\u0026#34;:{\u0026#34;module\u0026#34;:\u0026#34;Explore\u0026#34;},\u0026#34;properties\u0026#34;:{},\u0026#34;dateCreated\u0026#34;:1537312025306,\u0026#34;canUseSysdigCapture\u0026#34;:true,\u0026#34;canUseCustomEvents\u0026#34;:true,\u0026#34;canUseAwsMetrics\u0026#34;:true,\u0026#34;default\u0026#34;:false,\u0026#34;userRoles\u0026#34;:[]},{\u0026#34;version\u0026#34;:0,\u0026#34;customerId\u0026#34;:0,\u0026#34;immutable\u0026#34;:false,\u0026#34;name\u0026#34;:\u0026#34;Viewers\u0026#34;,\u0026#34;show\u0026#34;:\u0026#34;host\u0026#34;,\u0026#34;origin\u0026#34;:\u0026#34;SYSDIG\u0026#34;,\u0026#34;products\u0026#34;:[\u0026#34;SDC\u0026#34;],\u0026#34;entryPoint\u0026#34;:{\u0026#34;module\u0026#34;:\u0026#34;Explore\u0026#34;},\u0026#34;properties\u0026#34;:{},\u0026#34;dateCreated\u0026#34;:1537312025306,\u0026#34;canUseSysdigCapture\u0026#34;:true,\u0026#34;canUseCustomEvents\u0026#34;:true,\u0026#34;canUseAwsMetrics\u0026#34;:true,\u0026#34;default\u0026#34;:false,\u0026#34;userRoles\u0026#34;:[]},{\u0026#34;version\u0026#34;:0,\u0026#34;customerId\u0026#34;:0,\u0026#34;immutable\u0026#34;:false,\u0026#34;name\u0026#34;:\u0026#34;Editors1\u0026#34;,\u0026#34;show\u0026#34;:\u0026#34;host\u0026#34;,\u0026#34;origin\u0026#34;:\u0026#34;SYSDIG\u0026#34;,\u0026#34;products\u0026#34;:[\u0026#34;SDC\u0026#34;],\u0026#34;entryPoint\u0026#34;:{\u0026#34;module\u0026#34;:\u0026#34;Explore\u0026#34;},\u0026#34;properties\u0026#34;:{},\u0026#34;dateCreated\u0026#34;:1537312025306,\u0026#34;canUseSysdigCapture\u0026#34;:true,\u0026#34;canUseCustomEvents\u0026#34;:true,\u0026#34;canUseAwsMetrics\u0026#34;:true,\u0026#34;default\u0026#34;:false,\u0026#34;userRoles\u0026#34;:[]},{\u0026#34;version\u0026#34;:0,\u0026#34;customerId\u0026#34;:0,\u0026#34;immutable\u0026#34;:false,\u0026#34;filter\u0026#34;:\u0026#34;container.image contains \\\u0026#34;mysql\\\u0026#34;\u0026#34;,\u0026#34;name\u0026#34;:\u0026#34;Editors2\u0026#34;,\u0026#34;theme\u0026#34;:\u0026#34;#FF5C49\u0026#34;,\u0026#34;show\u0026#34;:\u0026#34;container\u0026#34;,\u0026#34;origin\u0026#34;:\u0026#34;SYSDIG\u0026#34;,\u0026#34;products\u0026#34;:[\u0026#34;SDC\u0026#34;],\u0026#34;entryPoint\u0026#34;:{\u0026#34;module\u0026#34;:\u0026#34;Dashboards\u0026#34;},\u0026#34;properties\u0026#34;:{},\u0026#34;dateCreated\u0026#34;:1537312025307,\u0026#34;canUseSysdigCapture\u0026#34;:false,\u0026#34;canUseCustomEvents\u0026#34;:false,\u0026#34;canUseAwsMetrics\u0026#34;:false,\u0026#34;default\u0026#34;:false,\u0026#34;userRoles\u0026#34;:[]}],\u0026#34;syncIntervalMinutes\u0026#34;:10,\u0026#34;dryRun\u0026#34;:true,\u0026#34;maxAllowedMappedUsers\u0026#34;:100,\u0026#34;syncTimeoutSeconds\u0026#34;:120}} Force a Sync -fTo force an immediate sync operation to apply the mapping roles, invoke the -foption, which performs a PUT on the /api/admin/ldap/syncLdapendpoint:\n# ./mapping_config.sh -f Forcing sync To apply a new setting and force an immediate synchronization, combine the two functions:\n# ./mapping_config.sh -s settings_mapping_simple.json -f {\u0026#34;ldapSyncSettings\u0026#34;: ... }} Forcing sync Report Current State -rTo see the mapped users/teams state and changes/problems from the most recent sync operation, view the report using the -roption, which performs a GET on the /api/admin/ldap/syncReport endpoint.\nThis same report information is in the system log for every sync operation.\n(Note that the Warning in this report is discussed in the Error Messages section below.)\n# ./mapping_config.sh -r { \u0026#34;ldapSyncReport\u0026#34;: { \u0026#34;changesApplied\u0026#34;: true, \u0026#34;conflictingTeamNames\u0026#34;: [], \u0026#34;duration\u0026#34;: 368, \u0026#34;lastSyncEnd\u0026#34;: 1537312224878, \u0026#34;lastSyncEndReadable\u0026#34;: \u0026#34;9/18/18 11:10 PM\u0026#34;, \u0026#34;lastSyncStart\u0026#34;: 1537312224510, \u0026#34;teamsMapped\u0026#34;: [ \u0026#34;Mixed\u0026#34;, \u0026#34;Editors1\u0026#34;, \u0026#34;Viewers\u0026#34;, \u0026#34;Editors2\u0026#34; ], \u0026#34;teamsToRemove\u0026#34;: [], \u0026#34;teamsToSave\u0026#34;: [ \u0026#34;Mixed\u0026#34;, \u0026#34;Editors1\u0026#34;, \u0026#34;Viewers\u0026#34;, \u0026#34;Editors2\u0026#34; ], \u0026#34;unmappedUser\u0026#34;: {}, \u0026#34;usersMappings\u0026#34;: [ { \u0026#34;teams\u0026#34;: { \u0026#34;Mixed\u0026#34;: \u0026#34;ROLE_TEAM_READ\u0026#34;, \u0026#34;Viewers\u0026#34;: \u0026#34;ROLE_TEAM_READ\u0026#34; }, \u0026#34;username\u0026#34;: \u0026#34;jdoe@example.local\u0026#34; }, { \u0026#34;teams\u0026#34;: { \u0026#34;Mixed\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34;, \u0026#34;Viewers\u0026#34;: \u0026#34;ROLE_TEAM_READ\u0026#34; }, \u0026#34;username\u0026#34;: \u0026#34;mpeterson@example.local\u0026#34; }, { \u0026#34;teams\u0026#34;: { \u0026#34;Editors1\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34;, \u0026#34;Editors2\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34;, \u0026#34;Mixed\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34; }, \u0026#34;username\u0026#34;: \u0026#34;msmith@example.local\u0026#34; } ], \u0026#34;version\u0026#34;: 5, \u0026#34;warnings\u0026#34;: [ \u0026#34;LDAP mapping LdapMapping(ldapFilterSettings=LdapFilterSettings(searchBase=cn=Users, searchFilter=(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Editors,CN=Users,DC=example,DC=local)(sAMAccountName=*)), groupSearchBase=null, groupSearchFilter=null, groupMembershipFilter=null), teams=[Editors1, Editors2], teamRole=ROLE_TEAM_EDIT, usernameAttribute=mail) matched 2 entities that has no requested username attribute\u0026#34; ] } } Delete Settings -dTo delete all LDAP mapping settings, invoke the -doption, optionally adding the -f option to force an immediate sync.\nUse with caution! This will trigger the deletion of all mapped teams and removal of mapped users from those teams.\n# /mapping_config.sh -d {\u0026#34;ldapSyncSettings\u0026#34;:{\u0026#34;version\u0026#34;:31,\u0026#34;ldapTeamMapping\u0026#34;:[],\u0026#34;syncIntervalMinutes\u0026#34;:10,\u0026#34;dryRun\u0026#34;:false,\u0026#34;maxAllowedMappedUsers\u0026#34;:100}} # ./mapping_config.sh -d -f {\u0026#34;ldapSyncSettings\u0026#34;:{\u0026#34;version\u0026#34;:4,\u0026#34;ldapTeamMapping\u0026#34;:[],\u0026#34;teamDefinitions\u0026#34;:[],\u0026#34;syncIntervalMinutes\u0026#34;:10,\u0026#34;dryRun\u0026#34;:false,\u0026#34;maxAllowedMappedUsers\u0026#34;:100,\u0026#34;syncTimeoutSeconds\u0026#34;:120}} Forcing sync Sample Use CasesThe sample settings_mapping_simple.json illustrates some common use cases.\nConsider a minimal Active Directory with the following users:\nsAMAccount Distinguished Name msmith CN=Mary Smith,CN=Users,DC=example,DC=local mpeterson CN=Mary Peterson,CN=Users,DC=example,DC=local jdoe CN=John Doe,CN=Users,DC=example,DC=local Presume the groups Sysdig Viewersand Sysdig Editors are defined in the Active Directory with the listed memberships:\nMapping Users to TeamsThe first mapping rule shows a simple 1-to-1 mapping of all the users in the Sysdig Viewers group in our directory to a Sysdig team called Viewers in which these users will have Read-only permission.\n{ \u0026#34;ldapFilterSettings\u0026#34;: { \u0026#34;searchBase\u0026#34;: \u0026#34;cn=Users\u0026#34;, \u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Viewers,CN=Users,DC=example,DC=local)(sAMAccountName=*))\u0026#34; }, \u0026#34;teamRole\u0026#34;: \u0026#34;ROLE_TEAM_READ\u0026#34;, \u0026#34;teams\u0026#34;: [ \u0026#34;Viewers\u0026#34; ], \u0026#34;usernameAttribute\u0026#34;: \u0026#34;sAMAccountName\u0026#34; } Mapping Users in a Group to Multiple TeamsThe second mapping rule illustrates how to map the Sysdig Editors group of users to more than one Sysdig team (Editors1 and Editors2), granting Read/Write access in both teams.\n{ \u0026#34;ldapFilterSettings\u0026#34;: { \u0026#34;searchBase\u0026#34;: \u0026#34;cn=Users\u0026#34;, \u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Editors,CN=Users,DC=example,DC=local)(sAMAccountName=*))\u0026#34; }, \u0026#34;teamRole\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34;, \u0026#34;teams\u0026#34;: [ \u0026#34;Editors1\u0026#34;, \u0026#34;Editors2\u0026#34; ], \u0026#34;usernameAttribute\u0026#34;: \u0026#34;sAMAccountName\u0026#34; } Complex Mapping ExampleThe third and fourth rules illustrate the flexibility of how groups are handled by the Sysdig LDAP Mapping feature.\nThe third rule shows how users targeted by a mapping rule can ultimately be anything specified by a searchFilter. In this contrived example, we\u0026rsquo;ve targeted all users with the first name \u0026ldquo;Mary\u0026rdquo; and mapped them to a Sysdig team called \u0026ldquo;Mixed\u0026rdquo; where they will have Read/Write permissions.\nThe fourth rule builds on the third, showing how to combine multiple rules to target different groups of users from the directory and potentially assign them different permissions in the same Sysdig team. Here we target our single \u0026ldquo;John Doe\u0026rdquo; user and also map him to the \u0026ldquo;Mixed\u0026rdquo; team, but with Read-Only access.\n{ \u0026#34;ldapFilterSettings\u0026#34;: { \u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(givenName=Mary))\u0026#34;, \u0026#34;searchBase\u0026#34;: \u0026#34;cn=Users\u0026#34; }, \u0026#34;teams\u0026#34;: [ \u0026#34;Mixed\u0026#34; ], \u0026#34;teamRole\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34;, \u0026#34;usernameAttribute\u0026#34;: \u0026#34;sAMAccountName\u0026#34; }, { \u0026#34;ldapFilterSettings\u0026#34;: { \u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(sAMAccountName=jdoe))\u0026#34;, \u0026#34;searchBase\u0026#34;: \u0026#34;cn=Users\u0026#34; }, \u0026#34;teams\u0026#34;: [ \u0026#34;Mixed\u0026#34; ], \u0026#34;teamRole\u0026#34;: \u0026#34;ROLE_TEAM_READ\u0026#34;, \u0026#34;usernameAttribute\u0026#34;: \u0026#34;sAMAccountName\u0026#34; } Search UsersYou can search users by both username and email alias attributes in the search option given in the Settings \u0026gt; Users page.\nMapping BehaviorsAs the examples show, the LDAP mapping configuration is flexible and powerful. However, misconfigurations (such as mistakes in filter syntax) may trigger the unintentional creation/deletion of excess user and/or team data. It is recommended to use the dryRun option extensively, particularly when first becoming familiar with the feature. The following notes about the constraints and side-effects of LDAP mapping should also be considered.\nDuring sync, if a user name from the directory matches on a mapping rule and does not yet exist in the Sysdig user database, it will be auto-created in the Sysdig database at that time. These will start out as non-Admin users, but could be promoted to Admin by a Sysdig Admin once their record has been auto-created.\nAs with other Sysdig teams, all Sysdig Admin users will automatically be members of all LDAP-mapped teams.\nDuring sync, if a mapped team specified in a rule and teamDefinitions array does not yet exist in the Sysdig database, it will be auto-created in the Sysdig database at that time. If a sync results in the creation of a team that has the same name as a non-mapped team that already exists (one that was created previously by a Sysdig Admin), the mapped team will not be created and no mapping of users to that team will be performed. This will also be noted in the system log.\nIf an LDAP-mapped user is no longer a match in a particular LDAP-mapped team, they will be removed from that team. Any team-specific data attached to that user (for example, Dashboards) will not be deleted.\nDashboards that were Shared by that user within the team will remain visible to other team members.\nPersonal Dashboards for that user will effectively be hidden, though if the user is mapped to the team again, they will be visible to that user again.\nAn LDAP-mapped user that no longer is a match on their last remaining LDAP-mapped team will be moved to the Default Team. This is to ensure against accidental deletion of the user\u0026rsquo;s data in the event of configuration mistakes. If desired, a Sysdig Admin can perform a final delete of the user record through the UI or API, which would result in the deletion of all data attached to that user in all teams.\nIf a user is mapped to the same team via multiple rules, and the teamRole settings differ between the rules, the most generous setting will apply (i.e. ROLE_TEAM_EDIT).\nMembership of LDAP-mapped teams is controlled exclusively via mapping rules. The Sysdig web UI will prevent membership changes in such teams.\nThe searchFilter entries in LDAP mapping rules are independent from the base LDAP loginFilter that is used for authentication. It is therefore possible for LDAP mapping rules to trigger creation of Sysdig user records for users that may not yet be able to login to the Sysdig platform.\nNo changes made within the Sysdig database will result in any modifications to the directory being queried via LDAP (sync is a \u0026ldquo;one-way\u0026rdquo; operation from directory to the Sysdig database).\nSee General LDAP Tipsfor more guidance to assist with debugging or perfecting your LDAP configuration.\nError MessagesConsider the following LDAP mapping excerpt:\n{ \u0026#34;ldapFilterSettings\u0026#34;: { \u0026#34;searchBase\u0026#34;: \u0026#34;cn=Users\u0026#34;, \u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Editors,CN=Users,DC=example,DC=local)(sAMAccountName=*))\u0026#34; }, \u0026#34;teamRole\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34;, \u0026#34;teams\u0026#34;: [ \u0026#34;Editors1\u0026#34;, \u0026#34;Editors2\u0026#34; ], \u0026#34;usernameAttribute\u0026#34;: \u0026#34;mail\u0026#34; } In the Report section above, there was a warning:\n\u0026#34;warnings\u0026#34;: [ \u0026#34;LDAP mapping LdapMapping(ldapFilterSettings=LdapFilterSettings(searchBase=cn=Users, searchFilter=(\u0026amp;(objectClass=organizationalPerson)(memberOf=CN=Sysdig Editors,CN=Users,DC=example,DC=local)(sAMAccountName=*)), groupSearchBase=null, groupSearchFilter=null, groupMembershipFilter=null), teams=[Editors1, Editors2], teamRole=ROLE_TEAM_EDIT, usernameAttribute=mail) matched 2 entities that has no requested username attribute\u0026#34; ] This was because two of the user records that matched our searchFilter (that is, they were members of the \u0026ldquo;Sysdig Editors\u0026rdquo; group in Active Directory) each had an empty mail attribute in AD. The LDAP Mapping configuration would have ordinarily resulted in the creation of these user records in the Sysdig platform user database, but since the usernameAttribute setting pointed the Sysdig platform at these empty mail values, the error message alerts us to this fact.\nIf these sort of empty attributes are typical for your AD environment, the error message can be ignored.\nSimilarly, if such attributes were not unique (multiple Mapped users were found to have the same email address), the error message would be:\n\u0026#34;warnings\u0026#34;: [ \u0026#34;Duplicate username founds. They will be ignored in mapping: [duplicates@example.local]\u0026#34; ] ","url":"https://docs.sysdig.com/en/administration/mapping-ldap-onprem-users-to-sysdig-teams/"},{"id":403,"title":"Metric Limits","content":"The Sysdig agent metric limit is different from the entitlement limit imposed on custom time series. Your time series entitlement could be lower than agent metric limits. For more information, see Time Series Billing.\nView Metric LimitsThe metric limits are automatically defined by Sysdig backend components based on your plan, agent version, and backend configuration. Metric limits are set per-category, and when aggregated the per-category limits define your overall metric limit per agent. Metric limits are global per account and the same limit will apply to each agent within a Sysdig account.\nTo view per-category metric limits for your account, along with the current usage per host for each metric type:\nLog in to Sysdig Monitor.\nSelect Dashboards \u0026gt; Dashboard Library.\nSelect the Sysdig Agent Health \u0026amp; Status dashboard template.\nHere, you can view the metric limits and current time series consumption for each agent.\nMetrics Description statsd_dragent_metricCount_limit_appCheck The maximum number of unique appCheck timeseries that are allowed in an individual sample from the agent per node. statsd_dragent_metricCount_limit_statsd The maximum number of unique statsd timeseries that are allowed in an individual sample from the agent per node. statsd_dragent_metricCount_limit_jmx The maximum number of unique JMX timeseries that are allowed in an individual sample from the agent per node. statsd_dragent_metricCount_limit_prometheus The maximum number of unique Prometheus timeseries that are allowed in an individual sample from the agent per node. To adjust metric limits for any category, Contact Sysdig Support.\nLearn More Subscription Configure Agent Modes ","url":"https://docs.sysdig.com/en/sysdig-monitor/agent-configuration-for-monitor/metric-limits/"},{"id":404,"title":"Metrics Not Available in Essentials Mode","content":" Sysdig ID Prometheus ID Segmented By net.bytes.in sysdig_host_net_in_bytessysdig_container_net_in_bytessysdig_program_net_in_bytes net.connection.server, net.connection.direction, net.connection.l4proto , and net.connection.client labels net.bytes.out sysdig_host_net_out_bytessysdig_container_net_out_bytessysdig_program_net_out_bytes net.connection.count.total sysdig_host_net_connection_total_countsysdig_container_net_connection_total_countsysdig_program_net_connection_total_countsysdig_connection_net_connection_total_count net.connection.count.in sysdig_host_net_connection_in_countsysdig_container_net_connection_in_countsysdig_program_net_connection_in_countsysdig_connection_net_connection_in_count net.connection.count.out sysdig_host_net_connection_out_countsysdig_container_net_connection_out_countsysdig_program_net_connection_out_countsysdig_connection_net_connection_out_count net.request.count sysdig_host_net_request_countsysdig_container_net_request_countsysdig_program_net_request_count net.request.count.in sysdig_host_net_request_in_countsysdig_container_net_request_in_countsysdig_program_net_request_in_countsysdig_connection_net_request_in_count net.request.count.out sysdig_host_net_request_out_countsysdig_container_net_request_out_countsysdig_program_net_request_out_countsysdig_connection_net_request_out_count net.request.time sysdig_host_net_request_timesysdig_container_net_request_timesysdig_program_net_request_time net.request.time.in sysdig_host_net_time_in_countsysdig_container_net_time_in_countsysdig_program_net_time_out_countsysdig_connection_net_time_in_count net.request.time.out sysdig_host_net_time_out_countsysdig_container_net_time_out_countsysdig_program_net_time_out_countsysdig_connection_net_time_out_count net.bytes.total sysdig_host_net_total_bytessysdig_container_net_total_bytessysdig_program_net_total_bytessysdig_connection_net_total_bytes net.mongodb.collection all net.mongodb.error.count sysdig_host_net_mongodb_error_countsysdig_container_net_mongodb_error_count net.mongodb.operation net.mongodb.request.count sysdig_host_net_mongodb_request_countsysdig_container_net_mongodb_request_count net.mongodb.request.time sysdig_host_net_mongodb_request_timesysdig_container_net_mongodb_request_time net.sql.query all net.sql.error.count sysdig_host_net_sql_error_countsysdig_container_net_sql_error_count net.sql.query.type net.sql.request.count sysdig_host_net_sql_request_countsysdig_container_net_sql_request_count net.sql.request.time sysdig_host_net_sql_request_timesysdig_container_net_sql_request_time net.sql.table net.sql.query all net.sql.table net.http.method net.http.request.count sysdig_host_net_http_request_countsysdig_container_net_http_request_count net.http.request.time sysdig_host_net_http_request_timesysdig_container_net_http_request_time net.http.statusCode net.http.url ","url":"https://docs.sysdig.com/en/docs/administration/configure-agent-modes/metrics-not-available-in-essentials-mode/"},{"id":405,"title":"Metrics Usage","content":"With Metrics Usage, you can:\nGet a comprehensive view of time series Cardinality and time series ingestion distribution across your infrastructure.\nThis information, coupled with the ability to search for a metric within your entire infrastructure or within a scope, lets you quickly access the time series information you need when you need it.\nObtain the time series count for each metric and an overview of the time series ingested in the last 20 minutes.\nThis functionality equips you with valuable data regarding metric influx and soon, usage.\nDownload per-metric time series count as a CSV or JSON file.\nThis provides a tangible, offline reference point that can be helpful in trend identification and reporting.\nDiscover which dashboards and alerts are using a given metric.\nTo access Metrics Usage, select Explore \u0026gt; Metrics Usage in the Sysdig Monitor UI.\nSearch for MetricsOn the Metrics Usage tab, open the infrastructure filtering menu and select the infrastructure object you want to search. You can simultaneously use all the filtering mechanisms to drill down to find what you are looking for.\nCriteria Preview Search a Metric\nOn the Search field, enter the full (such as container_cpu_usage_seconds_total) or partial (such as container_cpu) metric name. The metric list and panels will instantly be updated to show the metrics that match your search criteria. Search by Source\nSelect one or more sources from the All sources drop-down to filter metrics coming from different sources (agent, prometheus_remote_write, azure, gcp, aws). Search by Jobs\nSelect one or more jobs from the All jobs drop-down to filter all the metrics scraped by that job. For a list of Agent jobs, see Supported Monitoring Integrations. View Metrics DetailsSelect any metric from the Metrics Usage list to access additional information and actions in the slider window. The details and actions available will vary from metric to metric.\nThe slider has four tabs:\nOverviewIn the Overview tab, you find:\nJob: Name of the job used to collect this metric. Source: The source of this metric, such as agent, prometheus_remote_write, or aws. Type: Specifies if the metric is counter or gauge. See Metric Types. Unit: The unit of the metric, such as number, relativeTime and Kilobyte. Description: A short description of the metric. Manage Integrations: If the metric originates from a Sysdig Monitoring Integration, this link lets you view and manage the integration. Disable Metric: If the metric is a custom_metric reported by a Monitoring Integration, you manually disable the integration, to stop associated metrics from being reported. To re-enable the metric, see Monitoring Integrations. Cardinality: The number of time series associated with a single metric. Cardinality is shown across periods of five minutes, twenty minutes, and two hours. Open in Metrics Explorer: Takes you to Metrics Explorer, where you can further explore this metric in the context of others. Open in PromQL Query: Takes you to PromQL Query Explorer, where you can craft complex PromQL queries. LabelsThe Labels tab features the Label Usage panel. This panel takes account of the active grouping and scope, and enables you to have a deeper understanding of which labels are part of a selected metric and the metric\u0026rsquo;s estimated cardinality.\nLabels are listed in descending order of their estimated count. Hover over a label to reveal three actions:\nLabel Values Preview: A preview of label values. Open in Metrics Explorer: Takes you to Metrics Explorer where you can further explore this metric and label combination over time. Open in PromQL Query: Takes you to PromQL Query where you can further explore this metric and label combination over time. DashboardsThe Dashboards tab enables you to explore which dashboards are using the selected metric. Results are presented in four categories:\nDashboards in current Team: The dashboards that are currently accessible and visible to the current team. Dashboard Library: The read-only dashboards available in the Library. Dashboards in other Teams: The dashboards that are created by other teams but are not shared with the current team. Other dashboards: The dashboards that are created privately by other users or created by the teams that you are not a part of. AlertsThe Alerts tab enables you to explore which alerts are using the selected metric. Results are presented in three categories:\nAlerts in current Team: The alerts that are currently accessible and visible to the current active team. Alerts in other Teams: The alerts created by other teams. Other alerts: The alerts created by the teams that you are not a part of. Export Metrics Usage DataTo export metrics usage data to CSV or JSON format for further processing:\nLog in to Monitor, and select Explore \u0026gt; Metrics Usage.\nClick Export all results at the bottom of the Metrics Usage table.\nA wizard will appear.\nSelect your preferred Format; JSON or CSV, and a File name.\nClick Export.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/metrics-usage/"},{"id":406,"title":"SaaS: Sysdig Monitor Release Notes","content":"May 4, 2026Alert AutomationsYou can now create automated workflows that run when an alert fires, using conditional logic to route notifications to the right channels. For more information, see Alert Automations.\nApril 01, 2026Sysdig Sage for Monitor (Controlled Availability)Sysdig Sage is now available in Sysdig Monitor. Sysdig Sage is an AI-powered assistant that helps you troubleshoot Kubernetes issues and explore metrics using multi-step conversations in plain language. You can use Sysdig Sage to investigate incidents, translate natural language into PromQL queries, and explore cluster health and resource utilization.\nTo get started, create a custom role with Sysdig Sage access and assign it to the relevant teams. For more information, see Sysdig Sage for Monitor.\nApril 3, 2026Export EventsYou can now export the Events feed as a CSV file directly from the Sysdig Monitor Events page. The export reflects all active filters, severity selections, and the selected time range. For more information, see Export Events.\nMarch 25, 2026Notifications on Event Limits CleanupYou\u0026rsquo;ll receive a notification when an Events Limit Cleanup job is triggered. It is important to note that no changes are made to the data retention, only a message is added that gives you insight into this existing action. For more information, see Cleanup Event Data and Data Retention.\nMarch 3, 2026Be Notified in Local Time Instead of UTCYou can now configure notifications to display timestamps in local time instead of UTC. This setting applies globally to all notifications sent from the system.\nFor more information, see Time zone settings.\nUTF-8 Support for Alert Names in Email NotificationsThe email notification channel now supports UTF-8 characters in alert names. This allows you to use non-latin characters in alert names without formatting or delivery issues.\nFebruary 11, 2026Alert Template Variable AutocompleteAutocomplete is now available when entering variables in the template editor. To see available variables, type {{ in the template editor. For more information, see Supported Variables.\nFebruary 5, 2026Email Alerts for Notification Channel FailuresYou can now configure who receives email notifications when a notification channel fails. For more information, see Notification Channel Failure Alerts.\nNovember 25, 2025Dashboard Enhancements Dashboard Section Grouping: You can now group panels into sections, making large dashboards easier to organize and manage.\nCustomizable Table Column Headers: The Table panel now lets you relabel column headers and reorder columns to match your preferred layout.\nPersistent Query View Selection: The panel editor now remembers your preferred query mode (Form or PromQL) and automatically loads it the next time you open the panel.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-monitor-release-notes/"},{"id":407,"title":"OpenID Connect (SaaS)","content":"PrerequisitesThis topic is specific to cloud-based (SaaS) Sysdig environments. To configure an On-Premises Sysdig environment, see OpenID Connect (On-Prem).\nIf you want to set up OpenID for both Sysdig Monitor and Sysdig Secure, you need to complete the setup process twice. Setting up OpenID on one will not automatically set it up on the other.\nTo configure OpenID Single Sign-On (SSO), you need:\nAn Administrator role. Customer Name, and External ID: See Find Your Customer ID, Name, and External ID. OverviewUsing OpenID with SysdigThe Sysdig platform ordinarily maintains its own user database to hold a username and password hash. OpenID instead allows for redirection to your organization\u0026rsquo;s IdP to validate user credentials and other policies necessary to grant access to Sysdig applications. Upon successful authentication via OpenID, a corresponding user record in the Sysdig platform\u0026rsquo;s user database is automatically created, though the password that was sent to the IdP is never seen nor stored by the Sysdig platform.\nEnable OpenID1. Know which IdP your company uses and will be configuringThese are the OpenID Providers for which Sysdig has performed detailed interoperability testing and confirmed how to integrate using their standard docs. If your OpenID Provider is not listed (including ones that do not support OpenID Connect Discovery), it may still work with the Sysdig platform. Contact Sysdig Support for help.\nOkta (OpenID) Google Cloud Authentication (OpenID) OneLogin (OpenID) Keycloak (OpenID) Azure (OpenID) 2. Decide the login flow you want users to experienceContact Sysdig for the Company Name associated with your account.\nSysdig SaaS URL - On the main Sysdig login page select the OpenID button and enter your company name.\nDirect URL - Access the URL directly from a browser:\nMonitor: \u0026lt;Monitor Region URL\u0026gt;/api/oauth/openid/COMPANY_NAME Secure: \u0026lt;Secure Region URL\u0026gt;/api/oauth/openid/COMPANY_NAME?product=SDS Replace the \u0026lt;Monitor Region URL\u0026gt; and \u0026lt;Secure Region URL\u0026gt; with a valid URL from SaaS Regions and IP Ranges.\nIdP-Initiated Login - Log in from an IdP interface.\nThe individual IdP integration pages describe how to add Sysdig to the IdP interface. You will need your Company Name on hand.\n3. Configure your IdP and collect the resulting configuration attributesCollect the metadata URL (or XML) and test it. If you intend to configure IdP-initiated login flow, you need the configure the Redirect URI. See Redirect URI.\n4. Configure Sysdig Log in to Sysdig Monitor or Sysdig Secure and configure authentication. Log in to Sysdig Monitor Settings (as super admin) and enter the necessary configuration information in the UI. Save and Enable OpenID as your SSO. Log in to Sysdig Monitor Settings (as super admin) and enter the necessary configuration information in the UI. Save and Enable OpenID as your SSO. Repeat the process for the other Sysdig product, if you are using both Monitor and Secure. Enter a separate redirect URI in your IdP for each product; otherwise, the integration processes are the same. Configure IdP in SysdigChoose Your IdPSelect the appropriate IdP link below, and follow the instructions:\nOkta (OpenID) Google Cloud Authentication (OpenID) OneLogin (OpenID) Keycloak (OpenID) Azure (OpenID) To enable baseline OpenID Connect functionality:\nCreate a New OpenID SSO Integration Log in to Sysdig Monitor or Sysdig Secure as administrator.\nSelect Settings from the User Profile button in the left navigation.\nSelect Authentication (SSO).\nIn the SSO Integrations section, select New Integration.\nSelect type OpenID and click Add.\nEnter the relevant parameters in the configuration:\nConnection Setting Description Integration Name You must provide an integration name if you have more than one SSO integration of the same type. Client ID The unique ID provided by your IdP. Client Secret The secret provided by your IdP. Issuer URL The URL provided by your IdP. For example: https://YOUR-ONELOGIN-DOMAIN.onelogin.com/oidc\u0026lt;/. Use the entire domain path for OpenID Connect, including any trailing /. Create User on login Enable to allow creating users on login. Otherwise only existing users can login. Default: Enabled. Metadata Discovery IdP supports Metadata Discovery. Default: Enabled. Disable username and password login Prevent users from logging in using username and password (require IdP login). Toggle Enable OpenID single logout Flag to enable single logout. See Configure OpenID Single Logout. Use External ID Require customer specific External ID in Redirect URI. See Use External ID in Redirect URI Group Mapping Use Group Mapping. See Group Mappings Group Attribute Name For use with Group Mapping. See Group Mappings Additional Scopes The additional scopes required for logging in. The mandatory scopes are openid, profile, and email. You do not need to enter these as additional scopes, only any additional scopes beyond these three. Select Save.\nOkta, OneLogin, and Keycloak support metadata auto-discovery; so these settings should be sufficient for these IdPs.\nEnable or Disable a SSO IntegrationMake sure at least one integration is enabled to be able to use it for logging users in.\nFind the integration that you want to control.\nSelect the toggle on the left side of the integration and slide it to the right to enable or left to disable.\nIf you want to manage multiple integration, repeat the process\nEdit an Existing SSO Integration Log in to Sysdig Monitor or Sysdig Secure as administrator.\nSelect Settings from the User Profile button in the left navigation.\nSelect Authentication (SSO).\nSelect the pen icon on the right hand side of the window to edit the existing integration\n(Optional) Enter OpenID Additional SettingsIn some cases, an OpenID IdP may not support metadata auto-discovery, and additional configuration settings must be entered manually.\nIn this case:\nIn the OpenID tab, toggle the Metadata Discovery button to off to display additional entries on the page.\nEnter the relevant parameters derived from your IdP and click Save.\nConnection Setting Description Issuer URL Required. Case-sensitive URL that uniquely identifies the OpenID Provider. Authorization Endpoint Required. Authorization request endpoint. Token Endpoint Required. Token exchange endpoint. JSON Web Key Set Endpoint Required. The endpoint that contains key credentials for token signature verification. End session endpoint Optional. The URL at the IdP to which a Relying Party (RP) can perform a redirect to request that the end user be logged out at the IdP. This option is required if the single-logout toggle is enabled. Token Auth Method Authentication method. Supported values: client_secret_basic or client_secret_post (case insensitive). Issuer URL value is often the same, but can be different for providers that have a separate general domain and user-specific domain.\nFor example, general domain: https://openid-connect.onelogin.com/oidc, user-specific domain: https://sysdig-phil-dev.onelogin.com/oidc\nThe URL provided by your IdP. For example, https://YOUR-ONELOGIN-DOMAIN.onelogin.com/oidc. Ensure that you use the entire domain path for OpenID Connect, including any trailing slash (/).\nRedirect URIIdentify the correct Redirect URI associated with your Sysdig application and region.\nRegion App Sign-In Redirect URIs us Monitor https://app.sysdigcloud.com/api/oauth/openid/auth us Secure https://secure.sysdig.com/api/oauth/openid/secureAuth us2 Monitor https://us2.app.sysdig.com/api/oauth/openid/auth us2 Secure https://us2.app.sysdig.com/api/oauth/openid/secureAuth us4 Monitor https://app.us4.sysdig.com/api/oauth/openid/auth us4 Secure https://app.us4.sysdig.com/api/oauth/openid/secureAuth au1 Monitor https://app.au1.sysdig.com/api/oauth/openid/auth au1 Secure https://app.au1.sysdig.com/api/oauth/openid/secureAuth eu1 Monitor https://eu1.app.sysdig.com/api/oauth/openid/auth eu1 Secure https://eu1.app.sysdig.com/api/oauth/openid/secureAuth me2 Monitor https://app.me2.sysdig.com/api/oauth/openid/auth me2 Secure https://app.me2.sysdig.com/api/oauth/openid/secureAuth For more information on regions, see SaaS Regions and IP Ranges.\nUse External ID in Redirect URITo improve security, Sysdig introduced the option to enable customer-specific (unique, generated), External ID. The ID is automatically generated for each customer and you cannot modify it. External ID is in UUID format - xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.\nWhen the option to use External ID is enabled, the External ID must appended to the Redirect URI. The format is as follows: \u0026lt;REDIRECT_URI\u0026gt;/\u0026lt;EXTERNAL_ID\u0026gt;. Replace \u0026lt;REDIRECT_URI\u0026gt; with actual Redirect URI and \u0026lt;EXTERNAL_ID\u0026gt; with actual External ID.\nSee Main Authentication Settings to retrieve your External ID.\nThe use of External ID is going to be required after July 1st 2024. After this date it won’t be possible to disable the toggle and the toggle will be removed from the UI. It is recommended to switch your IdP to Redirect URI with External ID in your settings as soon as possible.\nConfigure OpenID Single LogoutWith Single Logout (SLO), users only need to sign out of one service provider, and all the active sessions will be terminated without any additional effort. This is vastly convenient from a usability perspective.\nSLO ProcessSysdig requests that the IdP logs the end user out by redirecting the user\u0026rsquo;s User Agent to the IdP\u0026rsquo;s Logout Endpoint. The IdP’s endpoint can be retrieved via the end_session_endpoint element of the IdP\u0026rsquo;s Discovery response (metadata). After a logout has been performed, the User Agent associated with the user will be redirected to the Sysdig login page.\nConfigure IdPConfigure Sign-out redirect URIs:\nUS East\nMonitor: app.sysdigcloud.com?follow_redirect=false Secure: secure.sysdig.com?follow_redirect=false Other regions\nhttps://\u0026lt;region\u0026gt;.app.sysdig.com?follow_redirect=false\nReplace \u0026lt;region\u0026gt; with the region where your Sysdig application is hosted.\nConfigure Sysdig Log in to Sysdig Monitor or Sysdig Secure as an administrator.\nFor on-prem deployments, log in as the super admin.\nNavigate to Settings \u0026gt; Authentication (SSO), and click the OpenID row under SSO Configuration.\nEnter the OpenID configuration.\nEnsure that Enable OpenID single logout is toggled on.\nClick Save Settings.\nSelect OpenID and click Set Authentication.\nLogin ExperienceAs noted in the enablement workflow above, you can offer users three ways to log in with an OpenID configuration:\nSysdig SaaS URLUsers can begin at the Sysdig SaaS URL and click the OpenID button.\nSee SaaS Regions and IP Ranges and identify the correct SaaS URL associated with your Sysdig application and region. For example, the URLs of Monitor and Secure for US East are:\nMonitor: https://app.sysdigcloud.com\nSecure: https://secure.sysdig.com\nFor other regions, the format is https://\u0026lt;region\u0026gt;.app.sysdig.com. Replace \u0026lt;region\u0026gt; with the region where your Sysdig application is hosted. For example, for Sysdig Monitor in the EU, you use https://eu1.app.sysdig.com.\nThey will be prompted to enter a Company Name, so the Sysdig platform can redirect the browser to your IdP for authentication.\nDirect URLYou can provide an alternative URL to avoid the user having to enter a company name, in the format:\nMonitor: https://app.sysdigcloud.com/api/oauth/openid/\u0026lt;COMPANY_NAME\u0026gt;\nSecure: https://secure.sysdig.com/api/oauth/openid/\u0026lt;COMPANY_NAME\u0026gt;?product=SDS\nIf multiple integrations are used or you specified the integration name, this parameter must be included as well:\nMonitor: https://app.sysdigcloud.com/api/oauth/openid/\u0026lt;COMPANY_NAME\u0026gt;?integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\nSecure: https://secure.sysdig.com/api/oauth/openid/\u0026lt;COMPANY_NAME\u0026gt;?product=SDS\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;\nIdP-Initiated LoginYou can configure an IdP-initiated login flow when configuring your IdP. The users then select the Sysdig application from your IdP\u0026rsquo;s app directory and do not need to browse directly to a Sysdig application URL.\nSee User and Team Administration for information on creating users.\n","url":"https://docs.sysdig.com/en/administration/openid-connect-saas/"},{"id":408,"title":"OpenID Connect (On-Prem)","content":" These instructions are specific to On-Premises Deployments of the Sysdig platform. If you are using the cloud-based (SaaS) Sysdig platform, refer to OpenID Connect (SaaS) instead.\nOverviewSummary of OpenID Functionality in SysdigThe Sysdig platform ordinarily maintains its own user database to hold a username and password hash. OpenID instead allows for redirection to your organization\u0026rsquo;s IdP to validate username/password and other policies necessary to grant access to Sysdig application(s). Upon successful authentication via OpenID, a corresponding user record in the Sysdig platform\u0026rsquo;s user database is automatically created, though the password that was sent to the IdP is never seen nor stored by the Sysdig platform.\nBasic Enablement Workflow Step\nOptions\nNotes\n1. Know which IdP your company uses and will be configuring.\nOkta\nOneLogin\nKeyCloak\nAzure (OpenID On-Prem)\nThese are the OpenID Providers for which Sysdig has performed detailed interoperability testing and confirmed how to integrate using their standard docs. If your OpenID Provider is not listed (including ones that do not support OpenID Connect Discovery), it may still work with the Sysdig platform. Contact Sysdig Support for help.\n2. Decide the login flow you want users to experience: 3 options\nClick OpenID button\nFrom https://HOSTNAME/ or https://HOSTNAME/secure\nType/bookmark a URL in browser\nMonitor: https://\u0026lt;HOSTNAME\u0026gt;/api/oauth/openid\nSecure: https://\u0026lt;HOSTNAME\u0026gt;:\u0026lt;PORT\u0026gt;/api/oauth/openid/secureAuth\nReplace \u0026lt;HOSTNAME\u0026gt; and \u0026lt;PORT\u0026gt; with that which specific to your deployment.\nLog in from an IdP interface\nThe individual IdP integration pages describe how to add Sysdig to the IdP interface.\nYou will need the following:\nYour Sysdig customer number and Customer Name.\nRedirect URLs:\nhttps://\u0026lt;hostname\u0026gt;/api/oauth/openid/auth\nhttps://\u0026lt;hostname\u0026gt;:\u0026lt;port\u0026gt;/api/oauth/openid/secureAuth\nReplace \u0026lt;hostname\u0026gt; with the hostname of your deployment.\n3. Perform the configuration steps in your IdP interface and collect the resulting config attributes.\nCollect metadata URL (or XML) and test it.\nIf you intend to configure IDP-initiated login flow find your Customer Name. Contact Sysdig if you do not know the customer name corresponding to your account.\n4a. Log in to Sysdig Monitor and configure authentication.\n4b. Log in to Sysdig Secure and configure authentication.\nLog in to Sysdig Monitor Settings (as super admin) and enter the necessary configuration information in the UI. Save and Enable OpenID as your SSO.\nLog in to Sysdig Secure Settings (as super admin) and enter the necessary configuration information in the UI. Save and Enable OpenID as your SSO.\nAdministrator StepsConfigure IdPSelect the appropriate IdP link below, and follow the instructions:\nOkta (OpenID On-Prem)\nOneLogin (OpenID On-Prem)\nKeycloak (OpenID On-Prem)\nAzure (OpenID On-Prem)\nUI-Based: Configure OpenID in SettingsAt this time, the Authorization UI is available only for Sysdig Monitor.\nTo enable baseline OpenID functionality:\nEnter OpenID Basic Connection Settings Log in to Sysdig Monitor or Sysdig Secure as administrator and select Settings.\nSelect Authentication.\nSelect the OpenID tab.\nEnter the relevant parameters (see table below) and click Save.\nConnection Setting Description Client ID ID provided by your IdP Client Secret Secret provided by your IdP Issuer URL URL provided by your IdP. Example:https://YOUR-ONELOGIN-DOMAIN.onelogin.com/oidc\nURL provided by your IdP. Example:https://YOUR-ONELOGIN-DOMAIN.onelogin.com/oidc\nNOTE: be sure to use the entire domain path for oidc, including any trailing / Okta, OneLogin, and Keycloak support metadata auto-discovery, so these settings should be sufficient for those IdPs.\n(Optional) Enter OpenID Additional SettingsIn some cases, an OpenID IdP may not support metadata auto-discovery, and additional configuration settings must be entered manually.\nIn this case:\nOn the OpenID tab, toggle the Metadata Discovery button to OFF to display additional entries on the page.\nEnter the relevant parameters derived from your IdP (see table below) and click Save.\nConnection Setting\nDescription\nBase Issuer\nRequired. Often the same Issuer URL, but can be different for providers that have a separate general domain and user-specific domain\n(for example, general domain: https://openid-connect.onelogin.com/oidc, user-specific domain: https://sysdig-phil-dev.onelogin.com/oidc)f\nAuthorization Endpoint\nRequired. Authorization request endpoint\nToken Endpoint\nRequired. Token exchange endpoint\nJSON Web Key Set Endpoint\nRequired. Endpoint that contains key credentials for token signature verification\nToken Auth Method\nAuthentication method.\nSupported values:\nclient_secret_basic ,\nclient_secret_post . (case insensitive)\n(Optional) Inactive Session Expiration\nSpecify the period of time a user can be inactive before the authenticated session will be suspended. See Configure Customized Session Expiration.\nSelect OpenID for SSO Select OpenID from the Enabled Single Sign-On dropdown.\nClick Save Authentication.\nScript-Based: Configure OpenID Using ScriptsThe configuration of the OpenID Connect feature can be viewed, updated, and deleted by the \u0026ldquo;super\u0026rdquo; Admin. An oidc_config.sh helper script is available in the SSO folder at sysdig-cloud-scripts repository to assist in completing this configuration. Invoking the script with no options will display help text.\n# ./oidc_config.sh Must specify the Sysdig App whose OpenID Connect configuration will be viewed/set Usage: ./oidc_config.sh [OPTIONS] Affect OpenID Connect login settings for your Sysdig software platform installation To use the helper script, modify env.sh to set the required values for API_TOKEN of the \u0026ldquo;super\u0026rdquo; Admin user and the URL for accessing the Sysdig platform API (which is the same URL that your users access for the Sysdig Monitor application).\nDepending if the API_TOKEN has been obtained from the Sysdig Monitor or Sysdig Secure application UI, the settings will be applied to the consequent product.\nInitially no OpenID settings are set. A initial run of the script would confirm that:\n# ./oidc_config.sh No openid settings are set Run for further info: ./oidc_config.sh -h Add the -s option to set the OpenID Connect configuration for a particular Sysdig application. When setting the config, you\u0026rsquo;ll use additional options to provide the config details you saved in the earlier OpenID Provider configuration step.\nConfig Detail Option Issuer URL -u Client ID -i Client Secret -e If the configuration is successfully posted to the Sysdig platform, the new configuration will be echoed back.\nAn example of creating the two separate OpenID Connect configurations for both Monitor and Secure, each using Okta as an OpenID Provider:\n# ./oidc_config.sh -s -u https://dev-824158.oktapreview.com -i 0oafpykpv7JMS4gMe0h7 -e ZctTGJMNJmuseEJHJGhvnb0pniZvz9Gf6RStxhHn { \u0026#34;authenticationSettings\u0026#34;: { \u0026#34;id\u0026#34;: 1, \u0026#34;version\u0026#34;: 1, \u0026#34;createdOn\u0026#34;: 1547541009000, \u0026#34;type\u0026#34;: \u0026#34;openid\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;SYSTEM\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;issuer\u0026#34;: \u0026#34;https://dev-824158.oktapreview.com\u0026#34;, \u0026#34;clientId\u0026#34;: \u0026#34;your-client-ID\u0026#34;, \u0026#34;clientSecret\u0026#34;: \u0026#34;your-client-secret\u0026#34;, \u0026#34;metadataDiscovery\u0026#34;: true } } } Once you\u0026rsquo;ve completed this configuration, clicking the OpenID button at the login screen of the appropriate Sysdig application(s) should redirect to your OpenID Provider for authentication.\nIf you wish to delete your OpenID Connect configuration, invoke the -d option. If successful, the disabled configuration will be printed.\n./oidc_config.sh -d { \u0026#34;authenticationSettings\u0026#34;: { \u0026#34;id\u0026#34;: 1, \u0026#34;version\u0026#34;: 1, \u0026#34;createdOn\u0026#34;: 1547541009000, \u0026#34;type\u0026#34;: \u0026#34;openid\u0026#34;, \u0026#34;scope\u0026#34;: \u0026#34;SYSTEM\u0026#34;, \u0026#34;settings\u0026#34;: { \u0026#34;issuer\u0026#34;: \u0026#34;https://dev-824158.oktapreview.com\u0026#34;, \u0026#34;clientId\u0026#34;: \u0026#34;your-client-id\u0026#34;, \u0026#34;clientSecret\u0026#34;: \u0026#34;Your-client-secret\u0026#34;, \u0026#34;metadataDiscovery\u0026#34;: true } } } User ExperienceAs noted in the Basic Workflow above, you can offer users three ways to log in with a OpenID configuration:\nThey can begin at the Sysdig URL and click the OpenID button.\nMonitor: https://HOSTNAME/ or Secure: https://HOSTNAME/secure.\nThey will be prompted to enter a Company Name, so the Sysdig platform can redirect the browser to your IdP for authentication.\n=\nYou can provide an alternative URL to avoid the user having to enter a company name, in the format:\nMonitor: https://HOSTNAME/api/oauth/openid Secure: https://HOSTNAME/api/oauth/openid?product=SDS You can configure an IdP-initiated login flow when configuring your IdP. The users then select the Sysdig application from your IDP\u0026rsquo;s app directory and do not browse directly to a Sysdig application URL at all.\nSee also User and Team Administration for information on creating users.\n","url":"https://docs.sysdig.com/en/administration/onprem-openid-connect/"},{"id":409,"title":"Posture Admission Policies","content":"Posture Policies and ChecksAdmission Controller supports multiple use cases across deploy-time security, compliance, and audit. Use the following guidelines as general examples to enable policies and enforce your best practices in your Kubernetes runtime.\nCreate and Assign PoliciesTo enable posture policies for Admission Controller enforcement, follow these steps:\nLog in to Sysdig Secure and navigate to Policies \u0026gt; Posture Policies.\nLocate the posture policy you want to enforce at admission. If none of the out-of-the-box (OOTB) policies meet your needs, create a custom policy by clicking New Policy and defining the necessary controls.\nYou can also review and create Posture policies via API.\nFor an existing or newly created policy, click the three-dots menu next to the policy and select Edit.\nLocate the Assigned Zones section.\nIn the Select Zones\u0026hellip; drop-down, choose the Zone(s) where you want the policy enforced during admission.\nIf the desired Zone does not exist, create it first in the Integrations \u0026gt; Zones page.\nFor each assigned Zone, select the Admission Controller Action:\nNone: Policy is not enforced during admission. Warn: Violations generate alerts but workloads are admitted. Reject: Workloads violating the policy are blocked at deployment. Click Save to apply changes. Use Cases and ExamplesThe following are a few examples of how you can use the Admission Controller to enforce your organizational best-practices.\nRejecting Privileged ContainersPrivileged containers pose significant security risks by granting processes extended host-level permissions. To block their deployment:\nUse the Built-in Posture Control Container running as privileged (or create a custom control that checks for securityContext.privileged: true).\nCreate a custom policy and include this control in one of its requirements.\nAssign this policy to the relevant Zone(s) with the Admission Controller Action set to Reject.\nDeploy a test workload with privileged: true in its security context to verify blocking.\nOnly Allow Deployment from Specific RegistriesTo restrict workload images to trusted registries:\nCreate a custom posture control that validates the container image registry domain against an allowed list (e.g., only images from mycompany.registry.com). package sysdig import future.keywords.if import future.keywords.in default risky := false risky if { some container in input.spec.template.spec.containers not startswith(container.image, \u0026#34;mycompany.registry.com\u0026#34;) } Bundle this control into a posture policy.\nAssign the policy to your Zone(s) with enforcement set to Warn or Reject.\nVerify by attempting deployment of an image from an unapproved registry and confirming it is blocked or logged.\nRequire specific Linux CapabilitiesLimiting Linux capabilities reduces the attack surface by restricting what privileged operations containers can perform.\nUse the Built-in Posture Control Container with Forbidden Capabilities.\nAssign this policy to the relevant Zone(s) with the Admission Controller Action set to Reject.\nDeploy a test workload with privileged: true in its security context to verify blocking.\n","url":"https://docs.sysdig.com/en/sysdig-secure/admission-controller/posture/"},{"id":410,"title":"Posture Controls","content":" Understand precisely what is or will be evaluated Review the logic behind each control and suggested remediation steps Tune your compliance results for personalized evaluation parameters Customize evaluation parameters to fit your specific needs Address misconfigurations across Kubernetes, containers, and cloud environments Sysdig Posture Controls are built on the Open Policy Agent (OPA) engine, using OPA\u0026rsquo;s policy language, Rego.\nPrerequisitesThis feature requires the Compliance component.\nNavigate Posture Controls List To see the Posture Controls list, select Policies \u0026gt; Posture Controls.\nSelect a specific control to open details in the right panel.\nSearch and Filter the ListFind specific controls through search and several filter options:\nSearch: Enter any word or part of a word in the name, description, or author to find matching controls. Severity: Filter controls by their severity level; High, Medium, or Low. Select Type: From the drop-down, choose a control type such as Cluster, Host, Identity, or Resource. Select Target: From the drop-down, select the specific platforms, distributions, and supported versions against which a control evaluates resources. Online cloud platforms, such as Azure Kubernetes Service (AKS), Amazon Web Services (AWS), and Google Cloud Platform (GCP), do not have versioning but always resolve to the latest version. Add multiple parameters to create more specific filter expressions.\nReview a ControlTo review a control in Posture Controls:\nSelect a specific control.\nThe control detail panel appears.\nReview basic attributes. At the top of the panel you can see:\nThe title of the control.\nThe severity: High, Medium, or Low.\nThe type: Cluster, Host, Identity, or Resource.\nThe author: For example, Sysdig, for out-of-the-box controls\nA brief description.\nThe policies to which the control is linked.\nHover over the policy names to get full details, such as the exact requirement number for the particular compliance standard, and to navigate to that requirement in the policy details page.\nReview the bottom panel. Here, you can see the following tabs:\nCode: Use the provided code snippets.\nThe code provides visibility into the precise objects that are evaluated and how the evaluation rules are structured. The display includes Inputs (where applicable) and the evaluation code written in Rego.\nYou can copy and download the code as a .json file.\nRemediation Playbook: Review the suggested steps to resolve failing controls. Where applicable, you must enter inputs in the remediation code provided.\nParameters: You can Customize the control parameters. See Customize Posture Controls.\nCustomize Posture ControlYou can customize controls by adjusting values within predefined parameters.\nConfigure SeverityBy default, Sysdig assigns an opinionated severity level to the posture controls it delivers.\nTo edit the Severity assignment:\nSelect a specific control and select the Parameters tab.\nClick Customize.\nChoose the Severity level, and click Save.\nA success message appears. The Compliance results will be updated during the next evaluation.\nYou can duplicate a control and assign two different severities if necessary.\nConfigure Evaluation Parameters Select a specific control and select the Parameters tab.\nClick Customize.\nCustomize an evaluation parameter.\nClick Save. Customize LabelsYou can add or delete custom labels on controls that originally contained labels:\nSelect a control that contains labels and open the Parameters tab.\nClick Customize.\nEnter a label in key:value or key format, such as env:prod or owner.\nClick Return.\nIf you want to add another label, insert a comma and the next label and click Return again.\nClick Save when your list is complete.\nThe labels appear as Custom Values in the Parameters tab.\nTo include custom labels in the Remediation Playbook YAML, you must download the sample code and enter the created labels manually.\nCustom ControlsIn the context of cloud security posture management (CSPM), custom controls are policies or rules that give security teams the flexibility to create and enforce policies. You can use them to manage posture, tailor compliance measures, and detect misconfigurations across infrastructures like Kubernetes, containers, and the cloud.\nYou can duplicate and edit any control. For example, you can create a new custom control that checks for a specific label.\nGuidelines You cannot link a user-duplicated control to an out-of-the-box policy. You can use a control from one policy in another custom policy with different parameter values. Even a change in severity level constitutes a different use case. You can delete or edit a duplicated (custom) control. Establish naming conventions to easily search for custom controls in the Control List.\nDuplicate a Control Select Policies \u0026gt; Posture Controls and browse or search for a specific control.\nFor example, if a control contains labels, the default Control Name includes the word Label. Search label to find these controls and duplicate them if desired.\nClick the three-dot menu and select Duplicate.\nEdit the following as desired and click Save:\nName: You can enter any name that is not used by another control. By default, Sysdig uses the format Original Control Name (copy). For example, Examine Audit policies (Copy).\nDescription: Optionally, enter a meaningful description about the control.\nSeverity: Select a severity for your custom control.\nIf the original control contained configurable evaluation parameters, you can customize them.\nSee Configure Evaluation Parameters.\nYou can now link the new custom control to a requirement in your custom policies.\nEdit or Delete Custom Controls Select a custom control from the Control List.\nTip: Look for the Author to identify custom controls. If the author is not Sysdig, then the control is custom.\nSelect the three-dot menu in the detail panel.\nSelect Edit.\nChange the Control Details, such as Name, Description, and Severity, as needed.\nClick Save.\nThe changed details will be applied to any custom policy where the control is used after the next evaluation.\nTo delete a custom control:\nSelect a custom control from the list.\nSelect the three-dot menu icon.\nSelect Delete.\nAfter the warning, confirm Yes, Delete.\nThe Compliance and Posture results of evaluations made from this control and any accepted risks for the control are deleted upon the next evaluation.\nCreate a Custom Control with RegoSysdig Secure\u0026rsquo;s Terraform provider lets you define, manage, and deploy custom controls as part of your infrastructure automation. This ensures your security policies are version-controlled, easily maintainable, and consistent across environments.\nPrerequisites Ensure you have both Terraform and Go installed in your environment:\nTerraform version \u0026gt;0.12.x.\nCheck your version with the command terraform version. Go version higher than the one specified in go.mod.\nCheck your version with the command go version.\nSet up $GOPATH as per the instructions in Go Wiki.\nTerraform Provider for Sysdig: To install and configure the provider, see Create Custom Controls with Terraform.\nYour Sysdig API token and Agent Access keys.\nReplace these values in the Terraform code snippet below: Click to expand terraform { required_providers { sysdig = { source = \u0026#34;local/sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt; 1.0.0\u0026#34; } } } provider \u0026#34;sysdig\u0026#34; { sysdig_secure_url=\u0026#34;https://secure.sysdig.com\u0026#34; sysdig_secure_api_token = \u0026#34;XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX\u0026#34; extra_headers = { \u0026#34;Proxy-Authorization\u0026#34;: \u0026#34;Basic XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX\u0026#34; } } Terraform Resource for Custom ControlsSysdig Secure’s Terraform Provider uses the sysdig_secure_posture_control resource to define custom controls. Resource attributes include:\nname: The name of the custom control. description: A detailed explanation of what the control does. resource_kind: The type of resource to which the control applies. For example, AWS S3 buckets or Kubernetes pods. When creating new controls, the resource_kind value must be written in lowercase. For example, resource_kind = \u0026quot;ibm_user-management_user\u0026quot;. severity: The severity level that defines the control’s importance, such as High, Medium or Low. rego: The Rego policy code that defines the control logic. remediation_details: Instructions for remediating any issues identified by the control. Next, we’ll create a custom Sysdig Secure custom control using Rego and Terraform.\nS3 Bucket Without VersioningS3 bucket versioning is important for several reasons, such as data protection, recovery, and management. In this scenario, we’ll create a custom control to ensure object versioning is enabled for your Amazon S3 buckets to preserve and recover overwritten and deleted objects:\nDownload and unzip the git file from the GitHub repository `terraform-provider-sysdig.\nInside the terraform-provider-sysdig-master folder, create a new Terraform file.\nCopy this code snippet and paste it in your file. The Rego code is embedded within the Terraform script:\nClick to expand resource \u0026#34;sysdig_secure_posture_control\u0026#34; \u0026#34;s3_bucket_without_versioning\u0026#34; { name = \u0026#34;S3 Bucket without versioning\u0026#34; description = \u0026#34;Ensure that S3 object versioning is enabled for your Amazon S3 buckets to protect and recover overwritten and deleted S3 objects.\u0026#34; resource_kind = \u0026#34;AWS_S3_BUCKET\u0026#34; severity = \u0026#34;High\u0026#34; rego = \u0026lt;\u0026lt;-EOF package sysdig import future.keywords.if import future.keywords.in default risky := false # Control fails if no versioning configuration is found risky if { count(input.Versioning) == 0 } # Control fails if versioning is not enabled risky if { some version in input.Versioning lower(version.Status) != \u0026#34;enabled\u0026#34; } EOF remediation_details = \u0026lt;\u0026lt;-EOF ## Remediation Impact Enabling versioning for S3 buckets helps preserve and recover previous versions of objects. It allows recovery of deleted or overwritten data, and helps ensure data protection. Archiving previous versions to Amazon S3 Glacier is also possible for long-term, low-cost storage. \u0026lt;code\u0026gt;## Remediate Using Command Line\u0026lt;/code\u0026gt; Run the following command to enable versioning for the selected bucket: aws s3api put-bucket-versioning --bucket \u0026lt;bucket-name\u0026gt; --versioning-configuration Status=Enabled ``` Repeat this command for other buckets in your AWS environment. EOF\n} ```\nFrom your terminal, initialize the Terraform environment. If the prerequisites are properly configured, you’ll see a message similar to the following snapshot:\nTo deploy this Terraform script as a custom control in Sysdig Secure, run terraform apply from your terminal.\nTerraform generates an execution plan describing what it will do to deploy the code, and then executes it to build the described infrastructure or configuration.\nThe prompt will pause for user input. At this stage, type yes and continue.\nThe custom control S3 Bucket without versioning appears in the Posture Controls library and is ready to be used in custom policies.\nTo verify it, log in to Sysdig Secure, select Policies \u0026gt; Posture Controls, and search S3 Bucket without versioning.\nApply Your Custom ControlNow, you can assign the new custom control to a new or existing Sysdig Secure Posture Policy based on your enterprise needs. The following example was created using these steps:\nNavigate to Policies \u0026gt; Posture Policies.\nSelect New Policy.\nConfigure the policy:\nDuplicate from: None, start from scratch.\nName: Custom Controls_S3 Bucket without versioning.\nDescription: Add a description.\nClick Save.\nThe policy detail page appears.\nSelect Publish.\nSysdig will prompt you to edit the policy. Alternatively, you can find the policy from the Posture Policies list, and select Edit from the three-dot menu icon.\nIn the Policy Details tab, select Add Zones, and choose the infrastructure scope across which the new control must apply.\nIn the Requirements \u0026amp; Controls, link your custom control to evaluate the posture compliance of your defined infrastructure.\nTo roll back, delete the resource definitions from your Terraform file and reapply. This updates the Posture Controls library and detaches the defined controls from the policies.\nSysdig API EndpointThe Sysdig API Endpoint enables you to query and fetch values for Terraform attributes, such as resource_kind. The REST APIs enable you to programmatically access and manage Sysdig Monitor and Sysdig Secure. You can use this to streamline your development workflows.\nThe Sysdig API endpoint has several category headers, such as Compliance, Cloud Organizations, and CSPM, along with details like the query parameters. For example, to fetch cloud resources, query with the GET request and define parameters such as providerType, resourceKind, and filter. The API endpoint also builds your custom queries in multiple formats, such as Go, Curl, Node, Java, and Python.\nThe following example shows you how to use Curl to query the API endpoint using a GET request, and then fetch values for the Terraform attribute resource_kind:\nExport the Sysdig API token in your environment. To export it in Windows, see Best Practices for API Key Safety. From the left panel, select CSPM, scroll down, and select Get Resource Kinds. Alternatively, use the link Get Resource Kinds. Switch to the Curl tab and copy the GET request. Open up a terminal window and paste the GET request. Provide your Sysdig API token for $SYSDIG_SECURE_API_TOKEN. The JSON output provides a list of all legitimate resource kinds available to query within the Sysdig Secure platform.\nIf we look back at our Terraform script, we had defined resource_kind as AWS_S3_Bucket.\nOn the Sysdig API endpoint, click Get Resource Example.\nChoose Curl, copy the GET request, and paste it in your terminal.\nThe new request fetches all the values associated with AWS_S3_Bucket.\nCopy and save the results.\nYou will need it for the next section to verify the Rego code.\nThe Rego PlaygroundThe Rego Playground is an online interactive environment that lets you write, test, and debug Rego policies in a sandboxed, browser-based interface. It’s ideal for those looking to explore policy-based control across various systems.\nThe following example shows you how to use the platform to evaluate the Rego code logic previously defined in your Terraform script. The JSON outputs from the last example are required as input variables.\nCopy the following code snippet and paste it in the editor section. If needed click Format to align the code:\nClick to expand package sysdig import future.keywords.if import future.keywords.in default risky := false # Control fails if no versioning configuration is found risky if { count(input.Versioning) == 0 } # Control fails if versioning is not enabled risky if { some version in input.Versioning lower(version.Status) != \u0026#34;enabled\u0026#34; } Add the previously saved JSON output in the INPUT window\nThe Versioning.Status field is defined at the bottom of the JSON output. It’s currently set to string.\nClick Evaluate to test the Rego script\nIn the OUTPUT window, the value of risky is set to true. So, the AWS S3 Bucket will be tagged as a risk if the version status is not enabled in your cloud accounts.\nModify the Status field to enabled.\nEvaluate the script again and notice that riskychanges to false in the OUTPUT window. This validates the Rego logic.\nUse the link here to run the sample.\nBest Practices for Implementing Custom Controls Start with high-impact controls: Prioritize custom controls that address significant security risks, such as blocking privileged containers or ensuring S3 versioning. Use Terraform for automation: Terraform makes it easy to manage custom controls as code, ensuring consistency across environments and allowing you to automate the deployment and updates of controls. Test controls in a staging environment: Always test your custom controls in a non-production environment to ensure that they work as expected and do not generate false positives. Continuously review and update controls: As your infrastructure evolves, regularly review and update your custom controls to reflect new security challenges and compliance requirements. Customizable Default ControlsThe following controls are customizable and have evaluation parameters that could be configured to personalize posture controls for specific use cases:\nAWS API Gateway - Gateway with VPC_LINK connection type API Gateway - REST API Gateway Stage with unencrypted cache API Gateway - Rest API Gateway Stage without required tag API Gateway - Rest API Gateway without required tag API Gateway - Stage without required ACL AutoScaling - App-Tier Auto Scaling Group with associated Elastic Load Balancer AutoScaling - Auto Scaling Group Cooldown Period CloudFront - Use CloudFront Content Distribution Network ECR - Restricted User Access ElastiCache - Valid Node Type ElastiCache - Latest MemCached Engine Version ElastiCache - Latest Redis Engine Version' ElastiCache - Latest Instance Generation ElastiCache - Appropriate Cluster Cache Nodes Count ElastiCache - Expiration of Lease for Reserved Cache Node ElastiCache - Recent Acquisitions of Reserved Cache Nodes IAM - Appropriate Access Key Rotation IAM - Appropriate Password Minimum Length IAM - Appropriate Password Reuse IAM - No Unused Passwords IAM - No Unused Access Keys IAM - Unused Root Account Lambda - Function Uses Supported Runtime Lambda - Lambda Cross Account Access Networking - Defined Compliant destination-cidr-block in Routing Tables Resource Contains Required Labels SNS - Appropriate Subscribers SNS - Cross Account Access S3 - Enabled Encryption At Rest GCP GCR - Restricted User Access Project - Corporate Credentials Azure ACR - Restricted User Access AppService - Enabled Java Autoupdate AppService - Required Latest PHP Version AppService - Required Latest Python Version AppService - Required Latest TLS Version Compute - Installed Endpoint Protection Logging - Appropriate Diagnostic Setting Networking - Appropriate Flow Retention Setting PostgreSQL - Appropriate Log Retention Setting SQL Server - Appropriate Auditing Retention Kubernetes ACR - Approved Registries API Server - Access to Pod Spec (OCP4) API Server - Defined audit-log-maxage API Server - Defined audit-log-maxbackup API Server - Defined audit-log-maxsize API Server - Owner of Pod Spec (OCP4) Approved Registries Container Contains Required Labels Container with Forbidden Capabilities GCR - Approved Registries Kubelet - Appropriate event-qps Level ","url":"https://docs.sysdig.com/en/sysdig-secure/posture_controls/"},{"id":411,"title":"Posture Host Analyzer (Non-Kubernetes)","content":" Posture Host Analyzer now supports on-premises environments starting from version 7.4.\nPrerequisites Retrieve your access key to use for ACCESS_KEY. Retrieve your Sysdig Secure endpoint by region to use for API_ENDPOINT. Docker installed. Any Linux distribution. Supported CPU Architectures: x86_64 CIS BenchmarksWe provide specific CIS benchmarks for the following Linux distributions:\nBottlerocket Distribution Independent Linux Red Hat Enterprise Linux (RHEL) 8 Red Hat Enterprise Linux 9 Rocky Linux 9 Ubuntu 20.04 LTS Ubuntu 22.04 LTS For other Linux distributions, we provide Distribution Independent Linux CIS benchmarks.\nInstall Posture AnalyzerRun the following command to deploy the non-Kubernetes Posture Analyzer on a host as a container:\nsudo docker run -d [-e TAGS=\u0026lt;TAGS\u0026gt;] -v /:/host:ro -v /tmp:/host/tmp --privileged --network host --pid host --env ACCESS_KEY=\u0026#34;xxx\u0026#34; --env API_ENDPOINT=secure.sysdig.com quay.io/sysdig/kspm-analyzer:latest Replace XXX with your agent access key, and \u0026lt;sysdig-secure-endpoint\u0026gt; with the URL for your Sysdig Secure endpoint by region.\nIf proxy is used, pass the proxy settings by using the following flags:\n-e HTTPS_PROXY=squid.yourdomain.com:PORT -e HTTP_PROXY=squid.yourdomain.com:PORT\nOptionsZonesTo apply posture with specific zones, the agent and the Kubernetes Security Posture Management (KSPM) components must be in the stand-alone Docker host. Include the kspm-analyzer container as part of the node-analyzer pod while installing to add standalone Docker hosts in the Host list/ Zones.\nNote that Inventory is based on Cloud Security Posture Management (CSPM)resources.\nAdd Agent TagsOptionally, to add agent tags, use the environment variable -e TAGS=\u0026lt;your_agent_tags\u0026gt;.\nReplace \u0026lt;your_agent_tags\u0026gt; with the tags you wish to add. For example:\n-e TAGS=myApp.Env:Production,host.name:MyHost ResultsOnce the container is running, the analyzer will begin scanning your host for compliance violations and providing security recommendations. To view the results in UI, log in to Sysdig Secure, and go to Attack Surface \u0026gt; Compliance Findings\nResults will be shown within a few minutes of installation and scans are refreshed every 24 hours.\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-posture-host-analyzer/"},{"id":412,"title":"Privacy Settings","content":" Opting-out of Data Analytics may prevent the usage of certain features, such as Okta ML, and the “Chat with Us” button in the left navigation bar.\nReview Privacy SettingsTo review and modify your privacy settings:\nFrom the user menu, navigate to Settings \u0026gt; Privacy Settings.\nToggle the sliders for the options listed below. Administrators can change data settings globally, while individual users can adjust the data being sent from their accounts.\nGlobal User SettingsSign in as an administrator to access these settings. You can enable sending Usage Data and Crash Reporting from all users back to Sysdig.\nYou can individually override this by opting out.\nIndividual User SettingsNon-admin users can access these settings. If administrators have opted in through the global settings, individuals may opt out of sharing their own data using this option. You can enable or disable the sending of Usage Data and Crash Reporting.\nDisabling Usage Data may hinder the Chat with Us button from reaching Customer Success. See Sysdig Support.\nCustomer Data Analytics (Secure Only)Sign in as an administrator to enable and disable the transfer of Data Analytics.\nNote that this data is used for Machine Learning (ML) policies, such as Okta ML, AWS ML, and Workload ML. Opting out will prevent the usage of such policies.\nThis option is only available in Sysdig Secure.\nSysdig Sage Message CollectionSysdig may use Sysdig Sage messages and conversation data. Use the Sysdig Sage Messages toggle to enable or disable this collection on your account.\nHard Opt-Out OptionContact Sysdig Support to opt out of data sharing in a way that can\u0026rsquo;t be overridden even by admins, if needed to comply with particular enterprise security standards.\nIf you are logged in to Sysdig Monitor as an administrator, you can see two pairs of sliders. The first pair are your individual user settings, and the second are the global settings.\n","url":"https://docs.sysdig.com/en/administration/privacy-settings/"},{"id":413,"title":"Response History","content":"The Response History page provides a centralized audit trail of all response action executions across your environment. Use it to track what actions were taken, when, by whom, and on which resources, without navigating individual events.\nTo access it, select Detection \u0026amp; Response \u0026gt; Respond \u0026gt; Response History.\nPrerequisitesTo view the Response History, you need a role with the Response Actions READ permission. This is included by default in the Admin, Advanced User, and Team Manager roles. See Role management.\nFilter Response ActionsUse the filter bar at the top of the page to narrow the list of executions. The following filters are available:\nFilter Description Action Name Filter by action type, grouped by Containment and Data Gathering categories. Execution Time Filter by the date when the action was executed. Triggered By Filter by the user who manually triggered the action or the automation that triggered it. Account ID Filter by cloud account ID. Host Filter by host name. Cluster Filter by Kubernetes cluster name. Status Filter by execution status, such as Ok or Error. Review Execution DetailsThe Response History table displays the following columns:\nColumn Description Execution Time The timestamp when the action was executed. Results are sorted by most recent first. Action The name of the response action, such as Kill Container or Isolate Network. Status The execution status: Ok or Error. Hover over an Error status to see the failure reason. Resource The target resource, such as a cluster name, host, or cloud account. Triggered By The user who triggered the action manually, or the name of the automation that triggered it. Click a row to open the detail panel, which contains:\nMetadata: The action description, type (Containment or Data Gathering), execution status, timestamp, and who triggered it. If the action was triggered by an automation, the automation name is clickable and navigates to its details. Inputs: The parameters used for the action, such as Cluster, Namespace, Workload Type, Workload Name, Host, AWS Region, or other context-specific fields. Outputs: The data produced by the action, such as a Network Policy Name, Quarantined File Path, or Snapshot IDs. This section only appears when the action produces output. Revert a Response ActionFor reversible actions, a revert button appears at the top of the detail panel. For example:\nIsolate Network: Shows a Delete Network Policy button. Pause Container: Shows an Unpause Container button. IAM Quarantine: Shows an IAM Unquarantine button. Make Private Cloud Resource: Shows an Undo Make Private button. You cannot revert actions that ended in error.\nFor the full list of actions and their reverse actions, see Response Actions.\nDownload Action ArtifactsFor data-gathering actions that produce downloadable files, a Download File button appears at the top of the detail panel. This applies to:\nGet Logs: Downloads collected Kubernetes logs. Fetch Cloud Logs: Downloads collected CloudTrail logs. File Acquire: Downloads the captured file. The download button is only available when the action completed successfully.\n","url":"https://docs.sysdig.com/en/sysdig-secure/response-history/"},{"id":414,"title":"Retrieve Secrets from Secrets Manager","content":"Pull the Agent Access Key Secret from the AWS Secrets ManagerThe following example shows you how to pull an agent access key secret from the AWS Secrets Manager using a reference within your workload agent task definition.\nIf you retrieve a secret using the following method, ensure you do not have an environment variable of the same name (for example, SYSDIG_ACCESS_KEY) set. The deployment will fail due to duplicated environment variable names.\n\u0026#34;containerDefinitions\u0026#34;: [ { ... \u0026#34;secrets\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;SYSDIG_ACCESS_KEY\u0026#34;, \u0026#34;valueFrom\u0026#34;: \u0026#34;\u0026lt;my-secrets-arn\u0026gt;\u0026#34; } ], ... } ] Since your task is executed using an ECS execution role, ensure that your role has permission to pull the secret. Add a policy to your role, similar to the following policy:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;secretsmanager:GetSecretValue\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;\u0026lt;my-secrets-arn\u0026gt;\u0026#34; } ] } When your task starts, it will retrieve the necessary secret and use it in your definition as required.\n","url":"https://docs.sysdig.com/en/sysdig-secure/fargate-fetching-secrets/"},{"id":415,"title":"Risk Exceptions","content":"Risk Exceptions are scoped, documented, and time-bound to ensure they are reviewed regularly.\nCreate a Risk Exception Log in to Sysdig Secure and navigate to Attack Surface \u0026gt; Risks. Select a Risk Definition, then select a Risk Finding. Click Create Exception. The Create Exception window appears. Complete the following fields: Exception Name: Enter a descriptive name to identify the exception. Exception Scope: Defines what the exception applies to. Risk Definition is prefilled based on the selected risk. Resource Attributes specify the affected resource scope. Reason: Select the reason for creating the exception: Risk Owned Risk Transferred Risk Avoided Risk Mitigated Risk Not Relevant Custom Expires In: Define how long the exception remains active. Expiration Date: Set the date when the exception expires. After the expiration date, the risk is evaluated again. Click Save Exception. The exception is applied to the selected Risk Finding and is visible in the Exceptions tab of the Risk Details panel.\nReview and Manage Risk ExceptionsTo review or manage existing Risk Exceptions:\nOpen a Risk Finding. Select the Exceptions tab. From the exception details, you can:\nEdit the Reason or Expiration date Revoke the exception to include the risk in evaluation again Risk Exceptions apply only to the Risks workspace. This workflow replaces Accepted Risk for Risks but does not change terminology in other Sysdig modules.\nView Risk Exceptions The Attack Surface \u0026gt; Exceptions page provides a centralized view of all risk exceptions created in the Risks workspace. Use this page to review active exceptions, track expiration dates, and understand why specific risks are excluded from evaluation.\nTo access this page:\nLog in to Sysdig Secure. Navigate to Attack Surface \u0026gt; Exceptions. Select the Risks tab. The table displays the following information:\nException Name: The name assigned when the exception was created. Anchor Resource: The primary resource associated with the exception. If the exception is not tied to a specific anchor resource, this value is shown as N/A. Creation Date: The date and time when the exception was created. Expiration Date: The date when the exception expires. After expiration, the associated risk is evaluated again. Reason: The reason selected when the exception was created. Created / Updated By: The user who created the exception or last modified it. Filter Risk ExceptionsUse the filters at the top of the page to narrow the results:\nReason: Filter exceptions by the selected reason. Status: View only active exceptions. Reset: Clear all applied filters. Risk Exceptions for VulnerabilitiesPrerequisitesReview Understanding Risk Exceptions for Vulnerabilities for a full overview of how this feature is used for vulnerability findings, including:\nEnablement prerequisites Types of risk assessed How to use in Pipeline and Runtime scan results Use the Attack Surface \u0026gt; Exceptions \u0026gt; Vulnerabilities panel to review exceptions that are expired or close to expiry and manage them.\nUsage Log in to Sysdig Secure.\nLog in to Sysdig Secure and do one of the following:\nSelect Attack Surface \u0026gt; Exceptions \u0026gt; Vulnerabilities.\nSelect Vulnerabilities \u0026gt; Exception.\nAny vulnerabilities that were added as an exception are displayed (in the order of acceptance date).\nFilter results by:\nSearch: Free text search on relevant terms such as the image name, package name, and CVE ID. Entity: You can filter by Vulnerabilities, Image name, Host name, and Policy Rule. Reason: Filter by Risk Avoided, Risk Owned, Risk Transferred, Risk Avoided, Risk Mitigated, Risk Not Relevant, or Custom. Expired: Filter by expired Risks that were accepted. You can sort the table by expiration or acceptance date, ascending or descending. Active: Shows all the active Risks that are accepted. You can sort the table by expiration or acceptance date, ascending or descending. Accepted/Updated by: Displays the username of the individual user who accepted or most recently updated the risk. You can also determine who accepted the risk in the scan result. Select an entry to open its detail panel to:\nRevoke an acceptance Edit the Reason and Expiration details of an accepted Risk. Note: When an exception expires, it no longer excludes the vulnerability from the vulnerability count.\n","url":"https://docs.sysdig.com/en/sysdig-secure/risk-exceptions/"},{"id":416,"title":"Run CLI Scanner in IaC Mode","content":"PrerequisitesTo include sysdig-cli-scanner in your IaC pipeline, run the sysdig-cli-scanner command.\nMake sure the sysdig-cli-scanner binary is available as part of worker or runner where the pipeline is executing.\nDefine a secret containing the API Token and make it available in the pipeline using a SECURE_API_TOKEN environment variable.\nEnsure that you have the necessary Role-Based Access Control (RBAC) permissions:\nPosture -\u0026gt; CLI IaC Scanning: Exec Policies -\u0026gt; Posture Policies: Read ParametersBasic usage of the sysdig-cli-scanner:\nsysdig-cli-scanner --iac [OPTIONS] \u0026lt;PathsToScan\u0026gt;\nMandatory Parameters Option Description --iac The first parameter of sysdig-cli-scanner must be --iac to enable the IaC scanning functionality. SECURE_API_TOKEN Provide the API token as environment variable SECURE_API_TOKEN . You can retrieve this from Settings \u0026gt; User Profile in Sysdig Secure. --apiurl=\u0026lt;endpoint\u0026gt; Sysdig Secure Endpoint. In SaaS, this value is region-dependent and is auto-completed on the Get Started page in the UI. Usagesysdig-cli-scanner --iac [OPTIONS] \u0026lt;PathsToScan\u0026gt; Replace \u0026lt;PathsToScan\u0026gt; with the path to the directory containing the source code to scan. It can be an absolute or a relative path.\nIf is omitted, the path defaults to current directory, ./ .\nFor example:\nSECURE_API_TOKEN=\u0026lt;your-api-token\u0026gt; ./sysdig-cli-scanner --iac -r -f H --apiurl \u0026lt;sysdig-api-url\u0026gt; /home/user/a-git-repository /home/user/another-git-repository Additional ParametersTo display a list of all available command line parameters:\n-h, --help Show this help message Example output:\nUsage: sysdig-cli-scanner --iac [OPTIONS] \u0026lt;PathsToScan\u0026gt; Common Options: -a, --apiurl string Secure API base URL --console-log Force logs to console, mutually exclusive with --logfile -o, --logfile string File destination for logs, mutually exclusive with --console-log -l, --loglevel string Log level [trace|debug|info|warn|err|fatal|panic|disabled] (default \u0026#34;info\u0026#34;) --output-json string Output path of the scan result report in json format -s, --skiptlsverify Skip TLS certificate verification Help Options: -h, --help Show this help message IaC Scan Options: --list-unsupported-resources Toggle output of detailed list of unsupported resources -r, --recursive Scan folders for manifests recursively -f, --severity-threshold string The minimum severity that will fail a scan [low|l|medium|m|high|h|never|n] (default \u0026#34;h\u0026#34;) --version Show the version and exit Exit codes: 0: Scan evaluation \u0026#34;pass\u0026#34; 1: Scan evaluation \u0026#34;fail\u0026#34; 2: Invalid parameters 3: Internal error CLI Scanner Exit CodesAccess the container exit codes with -h\nThe codes are:\n0 : Scan success. No findings or all findings are below the fail threshold\n1 :Scan failed. One or more findings are equal or above the fail threshold.\n2 : Incorrect parameters. Implies no API token is given.\n3 : Other execution errors.\nSample Result in TerminalYou can view scan results in the terminal window :\n$ sysdig-cli-scanner --iac -r -f H --apiurl=https://us2.app.sysdig.com /home/user/a-git-repository /home/user/another-git-repository Summary —------ Detected 1 modules/manifests in 1 folders 2 resources scrapped 3 unsupported resources (use –list-unsupported-resources for details) Findings: 🔴 13 High 🟠 17 Medium 🟡 18 Low Errors ------ - /.github/workflows/approve-test-run.yaml: Object \u0026#39;Kind\u0026#39; is missing in \u0026#39;{\u0026#34;jobs\u0026#34;:{\u0026#34;approve-test-run\u0026#34;:{\u0026#34;if\u0026#34;:\u0026#34;${{ github.event.issue.pull_request }}\u0026#34;,\u0026#34;permissions\u0026#34;:{\u0026#34;pull-requests\u0026#34;:\u0026#34;write\u0026#34;},\u0026#34;runs-on\u0026#34;:\u0026#34;ubuntu-latest\u0026#34;,\u0026#34;steps\u0026#34;:[{\u0026#34;name\u0026#34;:\u0026#34;Slash Command Dispatch\u0026#34;,\u0026#34;uses\u0026#34;:\u0026#34;peter-evans/slash-command-dispatch@v3\u0026#34;,\u0026#34;with\u0026#34;:{\u0026#34;commands\u0026#34;:\u0026#34;approve-test-run\u0026#34;,\u0026#34;issue-type\u0026#34;:\u0026#34;pull-request\u0026#34;,\u0026#34;permission\u0026#34;:\u0026#34;write\u0026#34;,\u0026#34;reaction-token\u0026#34;:\u0026#34;${{ secrets.GITHUB_TOKEN }}\u0026#34;,\u0026#34;token\u0026#34;:\u0026#34;${{ secrets.TOOLS_JENKINS_ADMIN_ACCESS_GITHUB_TOKEN }}\u0026#34;}}]}},\u0026#34;name\u0026#34;:\u0026#34;Approve Test Run\u0026#34;,\u0026#34;true\u0026#34;:{\u0026#34;issue_comment\u0026#34;:{\u0026#34;types\u0026#34;:[\u0026#34;created\u0026#34;]}}}\u0026#39;. ... - \u0026lt;Path\u0026gt; - \u0026lt;Details\u0026gt; Details —------ Container permitting root | 🟡 Low | 2 Occurrences +-------------------------------------------+------------+--------------------------------------------------------+--------------------------------------+ | RESOURCE | KIND | RESOURCE LOCATION | SOURCE | +-------------------------------------------+------------+--------------------------------------------------------+--------------------------------------+ | release-name-harbor-scanner-sysdig-secure | Deployment | runAsNonRoot in container harbor-scanner-sysdig-secure | /charts/harbor-scanner-sysdig-secure | | release-name-sysdig-stackdriver-bridge | Deployment | runAsNonRoot in container stackdriver-webhook-bridge | /charts/sysdig-stackdriver-bridge | +-------------------------------------------+------------+--------------------------------------------------------+--------------------------------------+ Workload container default RunAsGroup root | 🟠 Medium | 2 Occurrences +-------------------------------------------+------------+----------------------------------------------------+--------------------------------------+ | RESOURCE | KIND | RESOURCE LOCATION | SOURCE | +-------------------------------------------+------------+----------------------------------------------------+--------------------------------------+ | release-name-harbor-scanner-sysdig-secure | Deployment | `runAsGroup` in workload | /charts/harbor-scanner-sysdig-secure | | release-name-sysdig-stackdriver-bridge | Deployment | `runAsGroup` in workload | /charts/sysdig-stackdriver-bridge | +-------------------------------------------+------------+----------------------------------------------------+--------------------------------------+ Workload without ServiceAccount | 🔴 High | 1 Occurrences +----------------------------------------+------------+----------------------------------------------------+-----------------------------------+ | RESOURCE | KIND | RESOURCE LOCATION | SOURCE | +----------------------------------------+------------+----------------------------------------------------+-----------------------------------+ | release-name-sysdig-stackdriver-bridge | Deployment | `serviceAccountName` in workload | /charts/sysdig-stackdriver-bridge | +----------------------------------------+------------+----------------------------------------------------+-----------------------------------+ ... IaC Scan SUCCESS at 2024-01-04 13:19:37.702567 -0500 EST m=+0.100174543 OK: scan complete Scan errorsErrors that are not critical are the errors that are collected during the scan and are present in our existing scan summary model, defined per resource. They shouldn\u0026rsquo;t fail the scan execution or alter the Exit Code. Therefore, Exit Code will remain 0 or 1 in the presence of non-critical errors.\nThe non-critical errors are displayed in the output and as part of the JSON.\nIntegrationsVulnerability PoliciesPolicies allow you to define a set of rules that will evaluate each scan result. After the evaluation, each policy will pass or fail. A policy failure or non-compliance happens if the scan result doesn’t meet all the rules in a policy.\nYou can configure the CI/CD policies as Always apply. If a policy has the Always apply flag, it will be evaluated on every scanned image even if you don’t specify it explicitly.\nSpecifying PoliciesFor CI/CD and manual image scans, you can instruct the sysdig-cli-scanner tool to evaluate specific policies by using the --policies=policy-name-1,policy-name-2 flag or the short version, -p policy-name-1,policy-name-2. This flag accepts a comma-separated list of policy IDs, allowing you to specify one or more policies for evaluation. This flexibility is useful when policy names are lengthy or contain special characters.\nIf a specified policy does not exist, the Policy service will display the following error and halt execution.\nERROR: Policy \u0026quot;policy-name-6\u0026quot; does not exist. Please check and try again.\nConfiguration File OptionsYou can specify a configuration file with -c config-file-name or --config-file=config-file-name. This defaults to $HOME/.sysdig/cli_config.yaml.\nGrouping OptionsThe CLI scanner supports grouping results by policy or resource.\nPolicy grouping: --group-by=policy or -g policy Resource grouping (default): --group-by=resource or -g resource Guidelines All keys in the cli_config.yaml file are case-insensitive, as determined by the underlying libraries. Values set in cli_config.yaml have the lowest priority; if the same setting is specified via an environment variable or CLI flag, those will override the configuration file. You can configure all CLI flags and environment variables for IaC mode within this file. Fields like help are included for completeness, even though they may not be commonly used here. The secureapitoken can now be added directly in cli_config.yaml; previously, it was only configurable as an environment variable. Sample YAML Fileiac: apiurl: https://secure-site.sysdig.com console-log: true help: false list-unsupported-resources: true logfile: \u0026#34;\u0026#34; loglevel: debug output-json: \u0026#34;\u0026#34; policy: - All Posture Findings recursive: true secureapitoken: *** severity-threshold: l skiptlsverify: false version: false If you save this file as sample-configuration.yaml file, you can enter the following command:\nsysdig-cli-scanner --iac -p \u0026#34;All Posture Findings\u0026#34; --group-by resource sample-configuration.yaml For information on using Posture Policies, see Create Custom Controls with Terraform.\nJenkinsYou can integrate the Sysdig CLI Scanner as a Jenkins step. Once imported from the URL, you can add it to your project.\nCreate the Project or use an existing one:\nChose Sysdig Secure Code Scan as the build step:\nConfigure the operation:\nOption Description Sysdig Secure Engine URL The Sysdig Secure endpoint. In SaaS, this value is region-dependent and is auto-completed on the Get Started page in the UI. SECURE_API_TOKEN Provide your API token. You can retrieve this from Settings \u0026gt; User Profile in Sysdig Secure. Path The path to the directory containing the source code to scan. It can be an absolute or a relative path. Configure the Advanced parameters:\nOption Description List Unsupported Resources Toggle output of detailed list of unsupported resources. Recursive Scan folders for manifests recursively. Choose Severity Threshold The minimum severity that will fail a scan: Low | Medium | High | Never. The default is High. Version The CLI Scanner version to use. The default is latest. Run your Project:\nOnce you run the Project, the generated output will be identical to the output produced when running the CLI Scanner as a standalone application.\n","url":"https://docs.sysdig.com/en/sysdig-secure/cli-scanner-iac-mode/"},{"id":417,"title":"Run CLI Scanner in VM Mode","content":"The tool scans the images before runtime and display the results in the terminal or on the Attack Surface \u0026gt; Vuln Pipeline Findings page in Sysdig Secure. You can also create additional pipeline scanning policies and rules.\nThe sysdig-cli-scanner has a rate limit of 120 container images per minute.\nPrerequisites Ensure that you have the role-based access control (RBAC) CLI execution permission to use the CLI VM Scanner. See Detailed Role Permissions. Integrate in your CI/CD PipelinesThe sysdig-cli-scanner can be included as a step in your CI/CD pipelines, such as Jenkins and GitHub actions simply by running the sysdig-cli-scanner command as part of your pipeline.\nMake sure that the sysdig-cli-scanner binary is available as part of the worker or runner where the pipeline is executing. If you are running an ephemeral environment in the pipeline, include the download and set executable steps in your pipeline to download the tool on every execution. Define a secret containing the API-Token and make it available in the pipeline (i.e. via a SECURE_API_TOKEN environment variable). Include a step in your pipeline to run the sysdig-cli-scanner after building the container image, and providing the image name as parameter. For example: ./sysdig-cli-scanner --apiurl \u0026lt;sysdig-api-url\u0026gt; ${IMAGE_NAME} See some examples on how to use it on different CI/CD pipelines:\nAWS CodeBuild Azure Pipelines GitHub GitLab Jenkins Integrating Vulnerability PoliciesPolicies allow you to define a set of rules that will evaluate each scan result. After the evaluation, each policy will pass or fail. A policy failure or non-compliance happens if the scan result doesn\u0026rsquo;t meet all the rules in a policy.\nFor CI/CD and manual image scans, you can tell the sysdig-cli-scanner tool to explicitly evaluate one or more policies using the --policy= policy1,policy2,... flag and provide a comma-separated list of policy names. These will evaluate on top of policies that match the image scope.\nCI/CD policies can be configured as Always apply. If a policy has the Always apply flag, it will be evaluated on every scanned image even if you don\u0026rsquo;t specify it explicitly.\nLearn more about Vulnerability Management policies, the available rules, and how to define policies in Vulnerability Policies.\nParametersBasic usage of the sysdig-cli-scanner:\nsysdig-cli-scanner [OPTIONS] \u0026lt;ImageName\u0026gt;\nRequired Option Description SECURE_API_TOKEN Provide the API token as environment variable SECURE_API_TOKEN . You can retrieve this from Settings \u0026gt; User Profile in Sysdig Secure. --apiurl=\u0026lt;endpoint\u0026gt; Sysdig Secure Endpoint. In SaaS, this value is region-dependent and is auto-completed on the Get Started page in the UI. ImageName The image that you want to scan. For example mongo-express:0.54.0. The Sysdig CLI scanner will try to find a local image in Docker, ContainerD or other container runtimes, or try to pull if from the remote registry. Once the scan is complete, you will see the results directly in the console, and they will be available in the Pipeline section of the UI. Registry CredentialsRegistry credentials can be supplied via the following environment variables\nOption Description REGISTRY_USER Provide the registry username as environment variable REGISTRY_USER. REGISTRY_PASSWORD Provide the registry password as environment variable REGISTRY_PASSWORD. Example\nREGISTRY_USER=\u0026lt;YOUR_REGISTRY_USERNAME\u0026gt; REGISTRY_PASSWORD=\u0026lt;YOUR_REGISTRY_PASSWORD\u0026gt; SECURE_API_TOKEN=\u0026lt;YOUR_API_TOKEN\u0026gt; ./sysdig-cli-scanner --apiurl https://secure.sysdig.com ${REPO_NAME}/${IMAGE_NAME} Display Image Layers Option Description --separate-by-image Show detailed layer information separating packages by base image, mutually exclusive with --separate-by-layer. --separate-by-layer Show detailed layer information separating packages by layer, mutually exclusive with \u0026ndash;separate-by-image`. Additional Parameters Flag Short Flag Description --apiurl= -a The Secure API base URL. --cachepath= -p The Cache path. --clearcache -c Clear the cache before to run. The default is false. --console-log Force logs to console, mutually exclusive with --logfile --dbpath= -d Database directory absolute path. PLEASE NOTE THAT FILES IN THIS DIRECTORY COULD BE WIPED OUT. Defaults to {executablePath}/main.db --detailed-policies-eval Show a detailed view of the policies evaluation. --fips Use standard FIPS cryptographic library. --full-vulns-table Show the entire list of packages found. --help -h Show full help message; see below for details. --iac Execute IaC scan. Use --iac -h for help about IaC commands. --json-scan-result= DEPRECATED. Use --output=json-file=\u0026lt;destination\u0026gt; --output-schema=v1beta3. The output file of the JSON scan result in the designated format. --logfile= -o File destination for logs; mutually exclusive with --console-log --loglevel= -l Log level selection. Options are: info (default), debug --no-cache Do not use any cache throughout the scan; other cache-related parameters will be ignored. The default is false. --offline-analyzer [standalone mode] The analyzer does not perform backend calls. The default is false. --output= The output format. Specify one of the following: [json,json-file=\u0026lt;destination_path\u0026gt;,csv,csv-file=\u0026lt;destination_path\u0026gt;] --output-json= DEPRECATED. Use --output=json-file=\u0026lt;destination\u0026gt; --output-schema=legacy. The output path of the scan result report in JSON format --output-schema= Schema of the output file. For json/json-file: legacy, v1beta2, v1beta3, v1. For csv/csv-file: v1, v2. Must be used in conjunction with \u0026ndash;output=\u0026lt;json,json-file,csv,csv-file\u0026gt;\u0026quot; default:\u0026ldquo;v1\u0026rdquo;. For example, --output=json-file=~/en/cliscan.json --output-schema=v1 --override-pullstring= Specify a custom image name that will be displayed on the Sysdig UI. --platform= Specify the platform for selecting the image. --policy= Identify policies to apply, on top of policies that match the image scope. --separate-by-image Show detailed layer information separating packages by base image, mutually exclusive with --separate-by-layer --separate-by-layer Show detailed layer information separating packages by layer, mutually exclusive with --separate-by-image --skip-get-database [standalone mode] Do not download database even if obsolete or corrupted (default: false) --skiptlsverify -s DEPRECATED (use --api-skiptlsverify and --registry-skiptlsverify for more granular control) Skip TLS certificate verification when interacting with Sysdig Backend and pulling images (default: false) --api-skiptlsverify Skip TLS certificate verification when interacting with Sysdig Backend (default: false) --registry-skiptlsverify Skip TLS certificate verification when pulling images from container registries (default: false) --registry-insecure Allow pulling images from registries over HTTP (default: false) --skipupload -u [standalone mode] Do not upload the scan results (default: false) --standalone -n Do not depend on Sysdig backend for execution, avoiding the need of specifying --apiurl and SECURE_API_TOKEN. Implies activating all flags marked with [standalone mode] (default: false) --version Show the version and exit Example Help Output Usage: sysdig-cli-scanner [OPTIONS] [ImageName] Application Options: --iac Execute IaC scan. Use --iac -h for help about IaC commands -a, --apiurl= Secure API base URL -n, --standalone Do not depend on Sysdig backend for execution, avoiding the need of specifying --apiurl and SECURE_API_TOKEN. Implies activating all flags marked with [standalone mode] (default: false) --no-cache Do not use any cache throughout the scan; other cache-related parameters will be ignored (default: false) --offline-analyzer [standalone mode] The analyzer does not perform backend calls (default: false) --override-pullstring= Specify a custom image name that will be displayed on the Sysdig UI --platform= Specify the platform for selecting the image. --output-json= DEPRECATED (use --output=json-file=\u0026lt;destination\u0026gt; --output-schema=legacy): Output path of the scan result report in json format. Not to be used in conjunction with other format flags (--json-scan-result, --output) --json-scan-result= DEPRECATED (use --output=json-file=\u0026lt;destination\u0026gt; --output-schema=v1beta3): Output file of the json scan result in the new format in technical preview (breaking changes are possible). Not to be used in conjunction with other format flags (--output-json, --output and --output-schema) --output= Output format. One of (json,json-file=\u0026lt;destination\u0026gt;,csv,csv-file=\u0026lt;destination\u0026gt;) --output-schema= Schema of the output file. For json/json-file: legacy, v1beta2, v1beta3, v1. For csv/csv-file: only v1. Must be used in conjunction with --output=\u0026lt;json,json-file,csv,csv-file\u0026gt; (default: v1) --policy= Identifier of policy to apply -d, --dbpath= Database directory absolute path. PLEASE NOTE THAT FILES IN THIS DIRECTORY COULD BE WIPED OUT. Defaults to {executablePath}/main.db -p, --cachepath= Cache path -c, --clearcache Clear the cache before to run (default: false) -l, --loglevel= Log level (default: info) -o, --logfile= File destination for logs, mutually exclusive with --console-log --console-log Force logs to console, mutually exclusive with --logfile -s, --skiptlsverify Skip TLS certificate verification (default: false) -u, --skipupload [standalone mode] Do not upload the scan results (default: false) --skip-get-database [standalone mode] Do not download DB even if obsolete or corrupted (default: false) --full-vulns-table Show the entire list of packages found --detailed-policies-eval Show a detailed view of the policies evaluation --version Show the version and exit --separate-by-image Show detailed layer information separating packages by base image, mutually exclusive with --separate-by-layer --separate-by-layer Show detailed layer information separating packages by layer, mutually exclusive with --separate-by-image Help Options: -h, --help Show this help message Arguments: ImageName: Image name Exit Codes: 0: Scan evaluation \u0026#34;pass\u0026#34; 1: Scan evaluation \u0026#34;fail\u0026#34; 2: Invalid parameters 3: Internal error CLI Scanner Exit CodesAccess the container exit codes with -h\nThe codes are:\nError Code Description 0 Image passed policy evaluation 1 Image failed policy evaluation 2 Incorrect parameters. For example, no API token provided. 3 Other execution errors Use the exit code, for example, to decide whether to abort the CI/CD pipeline.\nImage SourcesThe Sysdig CLI scanner can load images from different sources. By default, it will try to automatically find the provided image name from all supported sources, in the order specified by the following list. However, you can explicitly select the image source by using the corresponding prefix for the image name:\nPrefix Name Description docker:// Docker Daemon Load the image from the Docker daemon (honoring the DOCKER_HOST environment variable or other Docker configuration files). podman:// Podman Load the image from the Podman daemon. file:// Docker Archive (tar) or OCI folder Load the image from a .tar file saved as a Docker image archive (Docker save command) or from an OCI folder. containerd:// Containerd Load the image from the Containerd daemon, which manages container lifecycles on the host. crio:// CRI-O Load the image from the Containers Storage location (used by CRI-O for Kubernetes environments). pull:// Docker Registry Force pulling the image from a remote repository, ignoring local images with the same name. i.e. pull the image from remote registry even if it is locally available:\n./sysdig-cli-scanner -a https://secure.sysdig.com pull://nginx:latest Override Platform SettingYou can use the --platform parameter to scan a specific platform for a given image.\nWhen the platform is not specified and the scanner has to pull the image from remote, the following behavior occurs:\nIf the pull string belongs to a manifest list, the scanner picks the first platform in the manifest list. If the pull string belongs to a single manifest, the scanner directly scans it. When a platform is defined with the parameter, the scanner uses only the specified platform:\nIf the image exists only locally, the scanner checks whether a matching platform-specific version is available:\nIf a matching image exists, it is scanned If no matching image exists, an error is returned If the image is not available locally, the scanner attempts to pull it from a remote registry:\nFor Manifest Lists (Image Index), it retrieves the image corresponding to the specified platform. If no match is found, an error is returned. For Manifest V2 images, the scanner pulls the image only if it matches the requested platform. Otherwise, an error is returned. If the image exists both locally and remotely, the scanner follows a structured approach. It first checks if the specified platform exists locally.\nIf a match found, the image is scanned. If no local match exists, the scanner attempts to pull the correct platform image from the registry. If no matching image is found remotely either, an error is returned. Specify a Platform Version for ScanningScan ppc64leWhen scanning a multiarch build like docker.io/library/golang:1.24.0 the CLI scanner will pick the first platform available in the manifest. In this case, amd64.\nTo scan a different platform, for example ppc64le, run the scanner as follows:\n$ SECURE_API_TOKEN=\u0026lt;YOUR_API_TOKEN\u0026gt; ./sysdig-cli-scanner --apiurl https://secure.sysdig.com --platform=linux/ppc64le quay.io/prometheus/node-exporter:latest Scan amd64In the below example, the CLI scanner will pick the first Windows version available in the manifest for scanning.\n$ SECURE_API_TOKEN=\u0026lt;YOUR_API_TOKEN\u0026gt; ./sysdig-cli-scanner --apiurl https://secure.sysdig.com --platform=windows/amd64 golang:latest To scan AMD, run the following:\n$ SECURE_API_TOKEN=\u0026lt;YOUR_API_TOKEN\u0026gt; ./sysdig-cli-scanner --apiurl https://secure.sysdig.com --platform=linux/amd64 golang:latest Sample Result in TerminalIt is possible to view scan results in the terminal window (see below)\n$ SECURE_API_TOKEN=\u0026lt;YOUR_API_TOKEN\u0026gt; ./sysdig-cli-scanner --apiurl https://secure.sysdig.com redis Type: dockerImage ImageID: sha256:7614ae9453d1d87e740a2056257a6de7135c84037c367e1fffa92ae922784631 Digest: redis@sha256:db485f2e245b5b3329fdc7eff4eb00f913e09d8feb9ca720788059fdc2ed8339 BaseOS: debian 11.2 PullString: pull:*//redis* 66 vulnerabilities found 8 Critical (0 fixable) 2 High (0 fixable) 4 Medium (0 fixable) 5 Low (0 fixable) 47 Negligible (0 fixable) POLICIES EVALUATION Policy: Sysdig Best Practices FAILED (9 failures)` You can use --full-vulns-table or --detailed-policies-eval flags to include further details in the output.\nFor a more user-friendly scan result, find the image in the UI.\nScan Logs for TroubleshootingThe sysdig-cli-scanner automatically writes a log file on every execution. You can change the output path using -o or --logfile flags. For troubleshooting purposes, you can change the log level by setting --loglevel=debug. This will increase the verbosity of the log messages to the debug level.\nNext StepsReview the scan results in the Attack Surface \u0026gt; Vuln Pipeline Findings.\n","url":"https://docs.sysdig.com/en/sysdig-secure/cli-scanner-vm-mode/"},{"id":418,"title":"Runtime","content":" This document applies only to the Vulnerability Management engine, released April 20, 2022. See Which Scanning Engine to Use for more information.\nRuntime ScanningAlthough shifting vulnerability management to the earliest phases, such as integrating with CI/CD, is essential, runtime vulnerability management remains important because:\nRuntime vulnerability management provides an additional layer of defense to your environments. New vulnerabilities are discovered every day; new discoveries need to be checked against your running images. You need to find vulnerabilities quickly. The In Use spotlight lets you hone in on the most important vulnerabilities in your running images, so you can efficiently prioritize and act. Sysdig runtime scanner:\nAutomatically observes and reports on all the Runtime workloads, keeping a close-to-real time view of images and workloads executing on the different Kubernetes scopes of your infrastructure. Performs periodic scans based on the latest vulnerabilities feed databases. Automatically matches newly reported vulnerabilities to your runtime workloads without requiring any additional interaction. Image Sourcing: Registry vs. Local Scanning Note: The following image sourcing options apply specifically to Kubernetes workload scanning. Host and non-orchestrated container scanning use different mechanisms.\nWhen identifying vulnerabilities in runtime workloads, Sysdig needs to extract the Software Bill of Materials (SBOM) from the container images. Sysdig supports two methods for sourcing these images:\nRegistry-based Scanning (Default): The Cluster Shield identifies running workloads and pulls the corresponding container images directly from your configured container registries to perform the scan. Local Scanning: The Host Shield accesses the container runtime (e.g., containerd, Docker) directly on the Kubernetes node to build the SBOM locally. The image never leaves the node, making this ideal for air-gapped, restricted environments, or when avoiding egress costs. For instructions on enabling node-based image extraction, see Local Scanning.\nUnderstand Runtime Workload and LabelsRuntime entities are associated using the concept of a workload, defined by:\nA unique Image ID\nA set of labels describing the runtime context (Kubernetes in this case)\nWorkload labels are ordered: cluster \u0026gt; namespace \u0026gt; type \u0026gt; container\nKubernetes cluster name, such as demo-kube-eks Kubernetes namespace name, such as `example-voting-app Kubernetes workload type, such as deployment or daemonset Kubernetes container name, such as sysdiglabs or example-voting-app-result:metrics-3 Several replicas of the same deployment are considered the same workload, and are represented by a single entry on the table. This is because the images are identical and the runtime context is the same.\nAn identical image deployed on two different Kubernetes clusters, however, will be considered two different workloads. This is because the runtime context is different.\nRuntime PoliciesPolicies let you define a set of rules that will evaluate each workload. Policies either pass or fail the evaluation. A policy failure or non-compliance happens when the scan result doesn\u0026rsquo;t meet all the rules in a policy.\nSysdig scans runtime workloads every fifteen minutes. Due to this, some short-lived workloads may not be captured, and will therefore not appear in Runtime results.\nRuntime policies contain a runtime scope filter, so it only applies workloads in that scope, or Entire infrastructure, which will apply globally.\nIf you have enabled host scanning, then you can assign runtime policies to container image workloads, hosts, or the entire infrastructure.\nTo learn more about Vulnerability Management policies, the available rules, and how to define policies, see Vulnerability Policies\nReview Runtime Scan Results Navigate to Attack Surface \u0026gt; Vuln Runtime Findings.\nBy default, the entire infrastructure results are shown.\nResults are ranked by:\nNumber of actual exploits Severity of vulnerabilities Number of vulnerabilities Find and remediate the priority issues discovered, by:\nRecommendations\nChecking what\u0026rsquo;s In Use\nSee Understanding the In Use Column for details.\nDrilling down to image details\nFiltering results\nAccepting risks/ revoking acceptances\nDrill into Scan Result DetailsSelect a workload from the Runtime results list to see a runtime workload in detail.\nOverview TabFocuses on the recommendations, preview into total number of vulnerabilities, and passed and failed policies, policy evaluation, and fixable packages in the selected image.\nClickable cells lead into the Vulnerabilities list.\nVulnerabilities TabLists the image layers and actionable instructions as well as provides the expanded filters and a clickable list of CVEs that open the full CVE details, including source data and fix information. Click on the row associated with a layer to view CVEs associated with that particular layer.\nRecommendations TabShows image hierarchy, surfaces image layers, identify vulnerability issues in packages contained in each layer, and provides actionable instructions to fix the issues.\nPackage TabOrganized by package view, with expanded filters and clickable CVE cells. Click on the row associated with a layer to view packages associated with that particular layer.\nPolicies TabShows CVEs organized by the policy+rule that failed. Use the toggle to show or hide policies+rules that passed. Click CVE names for the details.\nFilter and Sort Scanning Results Filter by Zones: View the scanning results in one or more selected Zones. Image-based zone filters are not supported on the Runtime page. This is by design - filtering on image pullstrings is often unreliable in runtime environments. Only non-image-based zone filters will apply to Runtime results. Filter by workload labels: View scanning results in selected workloads and optionally save constructed filters as Favorite or Default from the three-dot menu on the filter bar.\nHover over the workload labels and click = or =! to add them to the filter bar to refine by cluster, namespace, or type.\nFilter by asset type: View scanning results in a specific host, workload, or container.\nSee Asset Types Defined.\nFilter by evaluation: View results that are Passed, Failed, or have No Policy.\nRegistry Scanning result pages do not support filtering based on No Policy.\nIn Use : View the results that have been evaluated for risk first.\nRisk Acceptance: Filter out accepted risks to help you focus on active, unresolved issues. Select one of the following options:\nAll Risks: See all the risks. Risks Accepted : View only accepted risks. Risks Not Accepted: Hide all the accepted risks. Use further-refined filters within the image detail tabs. For example, CVE Name; Severity (\u0026gt;=); CVSS Score (\u0026gt;=); Has Fix; Exploitable.\nRuntime Risk AcceptanceThe ability to accept risk establishes the baseline for accepted level of risk and provides relevant status, clear ownership, and consistent process for addressing each vulnerability identified in your runtime environment.\nIf the minimum enablement requirements are not met, the Accept Risk button and panel will show in your interface, but will not activate. A created Acceptance would appear in Pending status for 20 minutes, then disappear as if you had never created it.\nReview Understanding Accept Risk and the Prerequisites.\nDefine an Accepted RiskThe process for risk acceptance is the same for Runtime and Pipeline.\nFailed CVE Navigate to Attack Surface \u0026gt; Vuln Runtime Findings.\nDo one of the following:\nSelect a failed asset from the list and choose the Vulnerabilities panel, then click on a vulnerability to open the detail panel.\nSelect a failed asset from the list and choose the Policies panel. Select the a failed rule to open the detail panel and select the CVE.\nClick Accept Risk and continue to Complete the Risk Acceptance Definition.\nFailed Rule Navigate to Attack Surface \u0026gt; Vuln Runtime Findings.\nSelect a failed asset from the list and choose the Policies panel.\nSelect the a failed rule to open the detail panel.\nClick Accept Rule as a Risk and continue to Complete the Risk Acceptance Definition.\nFailed Host or ImageYou can accept risk for an entire host or image, based on the image name or host name. Consider the following while accepting risk of a host or image:\nYou are not accepting the vulnerabilities and finding rules within the asset as individual risks, but just the asset as a whole. Any future CVE or failing rule will be accepted too. The ImageID or digests are not taken into account. The context of the acceptance is based on the host or the image name. Navigate to Attack Surface \u0026gt; Vuln Runtime Findings and select a failed asset.\nChoose the Policies panel and select the Accept Image as a Risk or Accept Host as a Risk button.\nContinue with Complete the Risk Acceptance Definition.\nComplete the Risk Acceptance DefinitionBased on your risk acceptance for asset type, you are presented with the Risk Acceptance definition dialog. Specify the risk acceptance details and click Accept.\nContext: Specify the scope and stage:\nWhere: Define the scope, that is, the cases to which the Accept will apply. Based on the asset type you chose, the configuration parameters differ. Asset Type Description Vulnerability Global: Every time this vulnerability is found, regardless of the asset or the package and also regardless of the phase (Pipeline, Runtime), the selected vulnerability will always be accepted.Package: You are accepting only the combination of this CVE and a particular package. There are two sub-options: any version or a particular version. For example, rpm 4.14.4 or rpm Image: You have four options: This particular imageThis specific image from all registries and repositories All versions of this image Image name contains a specific value Note that the context can affect multiple assets with a single configuration. For example, accepting one CVE globally would affect the policy evaluation of all the different images in which that vulnerability is found. Image You have four options: This particular imageThis specific image from all registries and repositories All versions of this image Image name contains a specific value Host You have two options: This particular host Host name contains a specific value Rule Depending on the asset type you choose, you will have two options: Global Host or Image\nFor each option, you can further narrow down the scope.\nStage: Specify the context in which you are accepting the risk of the selected rule. You can select either Runtime or Pipeline. Reason: Specify the reason for accepting the risk.\nRisk Avoided Risk Owned Risk Transferred Risk Avoided Risk Mitigated Risk Not Relevant Custom Optionally, you can enter additional details in the text box given.\nExpires In: Specify the duration. You can also set custom days starting from a specific date, or mark it as never expires.\nAccepts should be exceptional choices; normally they should not mask a security risk forever When the Accept expires, the vulnerability or asset reappears in the violations count, potentially causing an evaluation to fail again. An acknowledgment message is displayed, and a greyed-out Shield icon shows the Accept is in Pending status.\nManage AcceptsAccept ValidityThe creation, editing, or revocation of an Accept does not take effect immediately. The change is in Pending status with the grey shield icon until the next runtime scan is:\nAutomatically triggered Within 20 minutes No additional changes can made to the Accept configuration while it is pending.\nNote: This differs in Pipeline. See the Pipeline page for details.\nLimits\nThere is a limit of 1000 Accept Risk items (per customer account)\nThis is the number of configurations created, not the number of impacted assets/CVEs. For example, a global CVE Accept impacting 30 images counts as 1 Accept Risk item. Both CVE accepts and Asset accepts count towards that total. Review AcceptsWhen no longer pending, the Accept Risk shield is not greyed out and appears in the list of assets. You can also filter by Accept Risk to see all assets where an Accept has been applied.\nClick into the asset to see more, and hover over the shield icon to see all the Accept Risk configuration details.\nAccepted Risk on a CVE will be shown in the:\nList of CVEs in the Vulnerabilities panel List of Policy violations under the Policies panel Policy evaluation card, showing the number of overridden violations Passing EvaluationsA policy will pass if:\nAll the rules inside the policy pass, or All the violations to a policy have been voided by a matching accept A host or image will pass if:\nAll the policies attached to the asset pass, or\nThe asset itself is accepted\nIn this example, the policies are failing but the asset has been accepted, indicated by the shield icon beside the [PASSED] global evaluation.\nEdit an AcceptTo edit an existing risk, click on the pencil icon in the Accept details.\nYou can edit the\nReason Description Expiration To change the affected resource or the context, you must create a new Accept configuration, and delete the old one if no longer valid.\n","url":"https://docs.sysdig.com/en/sysdig-secure/vm-runtime/"},{"id":419,"title":"Scan Running Images","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nAuto-Scan with the Image AnalyzerWhat is the Image Analyzer?The (node) image analyzer (NIA) provides the capability to scan images as soon as they start running on hosts where the analyzer is installed. It is typically installed alongside the Sysdig agentcontainer.\nOn container start-up, the analyzer scans all pre-existing running images present in the node. Additionally, it will scan any new image that enters a running state in the node. It will scan each image once, then forward the results to the Sysdig Secure scanning backend. Image metadata and the full scan report is then available in the Sysdig Secure UI.\nThe analyzer performs the image analysis directly on the local host. This poses several benefits:\nAutomation: Every image executed on your environments will be automatically scanned and checked against the vulnerability databases and configured scanning policies, without requiring any manual intervention\nPrivacy: Using local analysis, only image metadata is sent to the Sysdig backend, as opposed to pulling the entire image to be evaluated with backend scanning, which provides improved privacy\nImproved registry security: Since the Sysdig backend will not pull the image from a registry, there is no need to configure registry credentials on the Sysdig-side, nor open up the registry endpoints to be accessed over public networks\nIf the node image analyzer is installed, there is no longer any need to manually trigger running image scans.\nInstalling the Image Analyzer If you have run the single line agent install with the --image-analyzer flag, then this component is already running in your infrastructure.\nThe feature is available for Kubernetes environments in Sysdig Secure SaaS and in On-Premises version 3.5.1+.\nOtherwise, the Image Analyzer is now deployed as a part of the Node Analyzer: Multi-Feature Installation.\nManually Scan an ImageIf the node image analyzer is not installed, then when a new image is added to a running environment it may need to be scanned manually. This can be done from either the Runtime tab, or the Scan Results tab.\nFrom the Runtime TabTo manually scan an image from the Runtime tab:\nFrom the Scanning module, choose the Runtime tab.\nSort by Unscanned and select an image from the list of unscanned images.\nClick Scan Now if the option is displayed. You may be prompted to install the Image Analyzer if the digest could not be detected.\nFrom the Image Results Tab From the Scanning module, choose the Image Results tab.\nClick Scan Image.\nDefine the path to the image, and click Scan.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/scan-running-images/"},{"id":420,"title":"Supply Chain Admission Policies","content":"Create and Assign PoliciesTo create and assign Supply Chain Policies for evaluation with the Sysdig Admission Controller, see Supply Chain Policies.\nWhen creating a Supply Chain Policy, validate the rules and scopes in a lower-tier or non-production environment before deployment.\nTesting policies beforehand helps prevent workload disruptions in production environments.\nSupply Chain EventsYou can observe Supply Chain Admission Control events in two locations within the Sysdig Secure platform:\nThe command-line interface (CLI) where the action was performed. The Events Feed. For use cases, see Use Cases and Examples.\nUse Cases and ExamplesThe following examples demonstrate how you can use the Sysdig Admission Controller to enforce organizational best practices through Supply Chain Policies.\nValidate Image Signatures for Workloads Outside the kube-system NamespaceUsing the Sysdig Image Signature Validation policy, you can deny the use of unsigned or unverified container images outside system namespaces such as kube-system, where Kubernetes deploys its core components. To validate image signatures for all other namespaces, do the following:\nIn the Sysdig Secure UI, go to Policies \u0026gt; Supply Chain Policies and create a Sysdig Image Signature Validation policy with the following configuration:\nName: Block Unsigned Images in Non System Namespace\nProvide an optional description. Validation Method: Choose the method that matches your signing model, and enter the required details. Scope: Under the Scopes section, select kubernetes.namespace.name. Operator: Set to not in. Value: Enter kube-system or any other namespace used for Kubernetes core functionality. Action: Select Reject Image. Save the policy and test it by deploying a non-compliant workload. Observe the failures in both the CLI output during kubectl execution and in the Events Feed.\nCLI Examplekubectl create deployment webapp-example --image=httpd:latest -n kube-system -f httpd-server.yaml error: failed to create deployment: admission webhook \u0026#34;vac.secure.sysdig.com\u0026#34; denied the request: Error from server: error when creating \u0026#34;httpd-server.yaml\u0026#34;: admission webhook \u0026#34;vac.secure.sysdig.com\u0026#34; denied the request: [Supply Chain Engine] Failed checks for container httpd-server. Failing policies: [Block Unsigned Images in Non System Namespace] Violations: x failed to verify log inclusion: not enough verified log entries from transparency log: 0 \u0026lt; 1 Events Feed Example ","url":"https://docs.sysdig.com/en/sysdig-secure/admission-controller/supply_chain/"},{"id":421,"title":"Sysdig Agents (Monitor)","content":" Select Integrations \u0026gt; Data Sources \u0026gt; Sysdig Agents to view the page.\nReview the EnvironmentOn the Sysdig Agents page, you can:\nIdentify where agents are installed: by node, cluster name, and cloud account ID. Locate the nodes detected from previously installed agents on hosts and from connected cloud accounts. View the agent versions detected in your environment. Check agent connection status and age. Narrow the view by searching or filtering on node name, cluster name, account ID, agent version, or agent status. View your total connected agent count over time. Access a link to quickly add an agent or troubleshoot disconnected nodes. Understand Agent Status Status Description Notes Never Connected Cloud Accounts only. Detects nodes in a managed cluster in a cloud account connected to Sysdig, where an agent has not been deployed Hover over the status to link to the Helm-based agent install instructions. Out of date Deprecated agent version. Agent support is provided for the last three minor version releases. Hover over the status for information on upgrading the agent. Almost out of date On the next agent release, this agent will be deprecated. Agent support is provided for the last three minor version releases. Hover over the status for information on upgrading the agent. Disconnected A Sysdig agent on a registered Kubernetes node lost connection to Sysdig. Hover over the status for information on how to troubleshoot an agent installation Up to date Your agent version is up to date. Connected The agent is connected. This status includes agents that are Up to date, Almost out of date and Out of date. Add an AgentTo add an agent:\nOn the Sysdig Agents page, click Add Agent.\nSelect your environment and continue with on-screen instructions:\nKubernetes Cluster Linux Docker Agent Console To open Agent Console:\nOn the Sysdig Agents page, locate the agent you want to explore. Select the three-dot menu on the right-hand side of the view. Click Agent Console. For more information about Agent Console see Using the Agent Console.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/sysdig-agent/"},{"id":422,"title":"Troubleshoot AWS Agentless Connections","content":"Check for Service Control PoliciesAWS Service control policies (SCPs) can commonly hinder Sysdig\u0026rsquo;s operations by denying required permissions, even if they are correctly granted at the Role level. SCPs are created at the Organization level, and may be automatically created if using services such as AWS Control Tower.\nTo check for SCPs that may impact Sysdig Integrations:\nLog into the Management Account of your AWS organization, and locate the affected account in the organization tree. Click the account, and open the Policies tab. Under Applied policies, check each policy and confirm that it does not deny any of the following actions: sts:AssumeRole from the Sysdig Trusted Identity\n(If using CSPM) Any permissions defined in the AWS SecurityAudit managed policy\n(If using Threat Detection for EventBridge - Terraform module v2.0/before June 5th, 2025 release) events:PutEvents on Sysdig EventBridge Bus.\n(If you set up Log Ingestion with S3) s3:Get* on CloudTrail’s target S3 bucket.\nCheck Terraform Provider and Module VersionEnsure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; AWS. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/aws//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;5.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/aws//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;5.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } Check for Resource Control PoliciesTo check for Resource Control Policies (RCP) that might impact Sysdig Integrations:\nLog into the Management Account of your AWS organization, and locate the affected account in the organization tree. Click the account, and open the Policies tab. Under Applied policies, check each policy and confirm that it does not deny any of the following actions: sts:AssumeRole from the Sysdig Trusted Identity.\nTo execute sts:AssumeRole, modify the RCP to exclude the correct Sysdig role ARN.\nContact Sysdig to get the ARN, update the aws:PrincipalArn condition accordingly.\n(If using CSPM) Any permissions defined in the AWS SecurityAudit managed policy\nTroubleshoot CSPM IAM Role: Ensure the affected account contains an IAM Role with: A TrustRelationship policy that allows sts:AssumeRole from Sysdig\u0026rsquo;s Trusted Identity. The AWS SecurityAudit managed policy attached. SCPs: If the account is part of an AWS Organization, ensure there are no SCPs that overwrite these permissions. Troubleshoot Threat DetectionFollow these pointers to troubleshoot Threat Detection via EventBridge or S3.\nTroubleshoot Threat Detection for EventBridge EventBridge Rule: Ensure the affected account contains an EventBridge Rule with the name beginning with a sysdig-secure-events prefix.\nThe rule target should be:\nAn API Destination sending data to Sysdig. This is applicable to the setups after the June 5th, 2025 release (event-bridge module v3 on Terraform). An account using a role with the same name as the rule, and has a Trust Relationship allowing Sysdig to assume it. This is applicable for setups prior to the June 5th, 2025 release (event-bridge module v2 on Terraform). The EventBridge resources are regional. They must exist in each region from which you would like capture events.\nCloudTrail Trail: In order for CloudTrail events to be correctly routed to EventBridge, a CloudTrail trail must exist. Ensure there is an active Trail in the affected account, or an active organizational Trail if the affected account is part of an AWS Organization.\nSCPs: If the account is part of an AWS Organization, ensure there are no service control policies (SCPs) that restrict sts:AssumeRole or events:PutEvents for these resources.\nEvents flowing: Check that Events are flowing through the EventBridge Rule:\nNavigate to the EventBridge Rules console and locate the Rule created by Sysdig.\nSelect this Rule, and navigate to the Monitoring tab. Check the Invocations and FailedInvocations graphs.\nIf all graphs show no data, this indicates no events matching Sysdig\u0026rsquo;s filter have occurred. Ensure an active CloudTrail Trail exists, and that activity is occurring in the region of the EventBridge Rule.\nIf RetryInvocationAttempts is greater than 0, you should check if the Invocations reached the API destinations default quota of 300/s. In this case, your cloud logs delivery will be delayed. If the event rate is consistently higher than the limit, the delay will continue to increase. If the delay reaches 24 hours, AWS drops the logs. To address this, check how to increase the limit in Raise the API Destinations Rate Limit.\nIf there is activity in the Invocations graph, and the FailedInvocations graph is non-zero, you can use the following steps to investigate the failures:\nFailed Invocations:\nIn this account, create a temporary SQS Queue that will be used as a Dead Letter Queue for the EventBridge Target. Navigate to the Rule and under the Target tab, click Edit. Expand the Additional settings section and select the second option for the Dead-letter queue (Select an Amazon SQS queue in the current AWS account to use as the dead-letter queue). Select the SQS Queue created in step 1, and save the configuration. Now that failed events will be captured in the DLQ, ensure that some activity occurs in the account. If the account sees high usage, events may already be occurring, however if the account is relatively unused, you man need to manually trigger some events. A simple option is to create or delete an S3 bucket. Navigate to the SQS Queue console and locate your temporary Queue. In the top right corner, click Send and receive messages. Under Receive messages, click Poll for messages. Select a message and view the Attributes tab. Details of the failed invocation will be available. Troubleshoot Threat Detection for S3 CloudTrail Trail: A CloudTrail trail must exist in order for CloudTrail events to be correctly routed to S3. Ensure there is an active Trail in the affected account, or an active organizational trail if the affected account is part of an AWS Organization.\nThe trail must have SNS enabled and the target SNS topic needs to have a HTTP subscription pointing to Sysdig. If the trail has Key Management Service (KMS) encryption configured, ensure that the Sysdig role has the permission to perform the kms:Decrypt action Permissions: Ensure the s3:Get* and s3:List* permissions are present on CloudTrail\u0026rsquo;s target S3 bucket.\nSCPs: If the account is part of an AWS Organization, ensure there are no service control policies (SCPs) that restrict sts:AssumeRole for these resources.\nRole: To test if the provisioned role can access files in the bucket, impersonate the role and use an API client to GET one of the files. For details on role impersonation, see Methods to assume a role.\n403 Errors: If you get permission denied errors, see Troubleshoot 403 Errors\nTroubleshoot Offboarding AWS Accounts, Organizational Units, and Organizations Using TerraformProblem: Terraform destroy fails for organization deployment if Host Scanning or Workload Scanning, or Threat Detection is using S3.\nSolution\nRun the following command to offboard AWS:\nterraform destroy -target module.onboarding.sysdig_secure_organization.aws_organization ","url":"https://docs.sysdig.com/en/sysdig-secure/aws-troubleshoot/"},{"id":423,"title":"Troubleshoot Azure Connections","content":"Insufficient Permissions on SubscriptionThis error might occur if your current Azure authentication session does not have the required permissions to create resources in the specified subscription.\nSolution: Ensure you are authenticated to Azure using a Non-Guest user with the Contributor or Owner role on the target subscription.\nError: Error Creating/Updating Lighthouse Definition \u0026#34;dd9be15b-0ee9-7daf-b942-5e173dae13fb\u0026#34; (Scope \u0026#34;/subscriptions/***\u0026#34;): managedservices.RegistrationDefinitionsClient#CreateOrUpdate: Failure sending request: StatusCode=0 -- Original Error: Code=\u0026#34;InsufficientPrivilegesForManagedServiceResource\u0026#34; Message=\u0026#34;The requested user doesn\u0026#39;t have sufficient privileges to perform the operation.\u0026#34; with module.cloudvision_example_existing_resource_group.module.cloud_bench.module.trust_relationship[\u0026#34;***\u0026#34;].azurerm_lighthouse_definition.lighthouse_definition, on ../../../modules/services/cloud-bench/trust_relationship/main.tf line 28, in resource \u0026#34;azurerm_lighthouse_definition\u0026#34; \u0026#34;lighthouse_definition\u0026#34;: 28: resource \u0026#34;azurerm_lighthouse_definition\u0026#34; \u0026#34;lighthouse_definition\u0026#34; { Insufficient Permissions on TenantUser Access AdministratorThe following error might occur if the User Access Administrator role was assigned on child management group levels only:\n│ Error: reading Management Group (Display Name \u0026#34;Tenant Root Group\u0026#34;): Management Group (Display Name \u0026#34;Tenant Root Group\u0026#34;) was not found │ │ with module.vm-workload-scanning.data.azurerm_management_group.root_management_group[0], │ on .terraform/modules/vm-workload-scanning/modules/vm-workload-scanning/organizational.tf line 4, in data \u0026#34;azurerm_management_group\u0026#34; \u0026#34;root_management_group\u0026#34;: │ 4: data \u0026#34;azurerm_management_group\u0026#34; \u0026#34;root_management_group\u0026#34; { To address this, assign Reader role to the Installer security principal on root management group level with the following command template:\naz role assignment create --assignee ”\u0026lt;SP_ID\u0026gt;” --role \u0026#34;Reader\u0026#34; --scope \u0026#34;\u0026lt;ROOT_MANAGEMENT_GROUP_ID\u0026gt;\u0026#34; Fill in the values SP_ID, and ROOT_MANAGEMENT_GROUP_ID. For example:\naz role assignment create --assignee \u0026#34;a686e05a-191d-48ba-a74e-6daf9445ef71\u0026#34; --role \u0026#34;Reader\u0026#34; --scope \u0026#34;/providers/Microsoft.Management/managementGroups/d1aed736-5b36-41ff-9d78-c8181a3435bb\u0026#34; The Reader role is required to list all management groups by using this terraform code.\nPermission to Modify Diagnostic SettingsThese errors might occur if you attempt to modify diagnostic settings without the appropriate permission:\n│ Error: checking for presence of existing Diagnostic Setting (Diagnostic Setting Name: \u0026#34;sysdig-entra-diagnostic-settings-de20e4f3\u0026#34;): unexpected status 403 (403 Forbidden) with error: AuthorizationFailed: The client \u0026#39;67848d30-0bc5-4c3d-b92e-da2c6cc3671e\u0026#39; with object id \u0026#39;67848d30-0bc5-4c3d-b92e-da2c6cc3671e\u0026#39; does not have authorization to perform action \u0026#39;Microsoft.AADIAM/diagnosticSettings/read\u0026#39; over scope \u0026#39;/providers/Microsoft.AADIAM/diagnosticSettings/sysdig-entra-diagnostic-settings-de20e4f3\u0026#39; or the scope is invalid. If access was recently granted, please refresh your credentials. │ │ with module.event-hub.azurerm_monitor_aad_diagnostic_setting.sysdig_entra_diagnostic_setting[0], │ on .terraform/modules/event-hub/modules/integrations/event-hub/main.tf line 139, in resource \u0026#34;azurerm_monitor_aad_diagnostic_setting\u0026#34; \u0026#34;sysdig_entra_diagnostic_setting\u0026#34;: │ 139: resource \u0026#34;azurerm_monitor_aad_diagnostic_setting\u0026#34; \u0026#34;sysdig_entra_diagnostic_setting\u0026#34; { │ │ Error: creating Monitor Diagnostics Setting \u0026#34;sysdig-diagnostic-settings-158dd88c\u0026#34; for Resource \u0026#34;/subscriptions/77016a5a-e464-4730-a8db-39cb1b562bfd\u0026#34;: unexpected status 403 (403 Forbidden) with error: AuthorizationFailed: The client \u0026#39;67848d30-0bc5-4c3d-b92e-da2c6cc3671e\u0026#39; with object id \u0026#39;67848d30-0bc5-4c3d-b92e-da2c6cc3671e\u0026#39; does not have authorization to perform action \u0026#39;Microsoft.Insights/diagnosticSettings/write\u0026#39; over scope \u0026#39;/subscriptions/77016a5a-e464-4730-a8db-39cb1b562bfd/providers/Microsoft.Insights/diagnosticSettings/sysdig-diagnostic-settings-158dd88c\u0026#39; or the scope is invalid. If access was recently granted, please refresh your credentials. │ │ with module.event-hub.azurerm_monitor_diagnostic_setting.sysdig_org_diagnostic_setting[3], │ on .terraform/modules/event-hub/modules/integrations/event-hub/organizational.tf line 32, in resource \u0026#34;azurerm_monitor_diagnostic_setting\u0026#34; \u0026#34;sysdig_org_diagnostic_setting\u0026#34;: │ 32: resource \u0026#34;azurerm_monitor_diagnostic_setting\u0026#34; \u0026#34;sysdig_org_diagnostic_setting\u0026#34; { │ To remedy this, Assign the Contributor Permission.\nCheck Terraform Provider and Module VersionEnsure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; Azure. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/azurerm//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;3.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/azurerm//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;3.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } Conflicting ResourcesThis error might occur if the specified Azure Subscription has already been onboarded to Sysdig\nSolution: You can import the resource into Terraform using the terraform import command. This will bring the resource under management in the current Terraform workspace.\nError: A resource with the ID \u0026#34;/subscriptions/***/resourceGroups/sfc-resourcegroup\u0026#34; already exists - to be managed via Terraform this resource needs to be imported into the State. For details, see the resource documentation for `azurerm_resource_group`. with module.cloudvision_example_existing_resource_group.module.infrastructure_eventhub.azurerm_resource_group.rg[0], on ../../../modules/infrastructure/eventhub/main.tf line 6, in resource \u0026#34;azurerm_resource_group\u0026#34; \u0026#34;rg\u0026#34;: 6: resource \u0026#34;azurerm_resource_group\u0026#34; \u0026#34;rg\u0026#34; { Missing Microsoft.ManagedServices Namespace RegistrationThis error occurs if the specified Azure Subscription is not registered in the Microsoft.ManagedServices namespace.\n│ Error: creating Scoped Registration Assignment (Scope: \u0026#34;/subscriptions/65574bab-1b53-4fa5-a082-e4d158aad670\u0026#34; │ Registration Assignment: \u0026#34;da52bf86-4451-8704-f46a-50f427698202\u0026#34;): performing CreateOrUpdate: unexpected status 409 (409 Conflict) with error: MissingSubscriptionRegistration: The managed services resource provider not allowed to access the subscription \u0026#39;65574bab-1b53-4fa5-a082-e4d158aad670\u0026#39;. The subscription must be registered to use namespace \u0026#39;Microsoft.ManagedServices\u0026#39;. Please see https://aka.ms/rp-not-register-error for details on how to register subscriptions. │ │ with module.agentless-scanning.azurerm_lighthouse_assignment.lighthouse_assignment_for_tenant[\u0026#34;65574bab-1b53-4fa5-a082-e4d158aad670\u0026#34;], │ on .terraform/modules/agentless-scanning/modules/agentless-scanning/organizational.tf line 33, in resource \u0026#34;azurerm_lighthouse_assignment\u0026#34; \u0026#34;lighthouse_assignment_for_tenant\u0026#34;: │ 33: resource \u0026#34;azurerm_lighthouse_assignment\u0026#34; \u0026#34;lighthouse_assignment_for_tenant\u0026#34; { Solution:\nUse this Bash script to enable Microsoft Managed Services (Lighthouse) in each Azure subscriptions your account has access to:\nfor sub in $(az account list --query \u0026#34;[].id\u0026#34; -o tsv); do echo \u0026#34;Registering MMS in $sub\u0026#34; az provider register --namespace Microsoft.ManagedServices --subscription \u0026#34;$sub\u0026#34; done Lighthouse requires Microsoft.ManagedServices provider to access the subscriptions.\nYou can register a Resource Provider by following the Microsoft Documentation.\nMissing Cloud LogsIf validation is successful, but events are not flowing after setting up log ingestion:\nIn the Secure UI, open Integrations \u0026gt; Environments \u0026gt; Azure and select the Subscription of your interest. On the panel on the right hand side, you can find the Event Hub name in the details of the Identity and Access Management or the Cloud Detection and Response sections. Using the Azure portal or the azurerm CLI, confirm the Event Hub is in place and check its metrics. If they are healthy, there should be no errors (Server Errors/User Errors), and there should be messages flowing, unless the subscription is silent. If the subscription is silent, check the presence of Diagnostic settings on Azure. Each connected subscription should have Diagnostic Settings pointing to the target EventHub, as well as Entra ID, in case of Tenant setups. Offboard Azure Subscriptions, Groups, and Tenants Using TerraformProblem: Cannot Use Terraform Destroy to OffboardAzure Service Principals are created at the Tenant level. Therefore, onboarded subscriptions share and use an existing service principal that is linked to the Sysdig application in the same tenant.\nOnce created, this service principal cannot be deleted via the Terraform module. This safeguards against unintended deletes if the service principal is in use.\nAs a result, trying to offboard using Terraform destroy results in the following: Error: Instance cannot be destroyed.\nSolutionTo resolve this problem, remove the service_principal resource from your Terraform state, so that Terraform will no longer control it.\nterraform state list terraform state rm module.\u0026lt;module-name\u0026gt;.azuread_service_principal.\u0026lt;sysdig-sp-resource-name\u0026gt; terraform destroy Problem: Terraform Fails to Destroy Organization Deployment with Enabled Security FeaturesTerraform fails to destroy an organization deployment when Host Scanning, Workload Scanning, or CDR is enabled, likely due to dependencies on active security configurations.\nSolutionTo resolve this, first manually offboard Azure. If the problem still persists, run the following terraform destroy command:\nterraform destroy -target module.onboarding.sysdig_secure_organization.azure_organization ","url":"https://docs.sysdig.com/en/sysdig-secure/azure-troubleshoot/"},{"id":424,"title":"Users","content":" Deprecation Notice Upcoming Changes to Sysdig Product Line\nThe legacy Identity pages are now deprecated and will be phased out over a transition period. During this time, both the legacy and new experiences will remain available. We encourage you to start using the new Identity Overview and Findings pages to become familiar with the updated experience.\nFilter and Sort AccountsUse the sortable columns to organize and filter user accounts for assessing identity risks. You can sort user accounts based on the following criteria:\nUnused Permission CriticalityUnused Permission Criticality focuses on unused permissions, while Permission Criticality looks at all permissions. Unused Permission Criticality is designed to help you achieve Least Permissive access.\nValues: Critical, High, Medium, Low\nRiskThis is a calculation of risk based on all permissions. See Understanding Risk Scoring for more information.\nValues: Critical, High, Medium, Low\n% of Unused PermissionsThis shows the number of unused permissions per total permissions for the user, shown as a percentage graph.\nWhen remediating, immediately target the users with the greatest exposure and refine them according to the suggestions.\nHighest AccessHighest Access offers a quick way to filter by Access Category. It shows this identity entity’s highest level of access according to all of its permissions. For more information, see Understand Highest Access.\nValues:\nAdmin: Admin access granted Write: Write access granted Read: Read access granted Empty Access: No permissions are granted at all FindingsA finding in Cloud Infrastructure Entitlement Management (CIEM) indicates poor security hygiene, either due to misconfiguration or inadequate identity security practices. The findings on User pages include:\nNo MFA Admin AWS-Specific\nAccess Key Not Rotated Multiple Access Keys Active Root User Inactive GCP-Specific\nEditor Role Applied Owner Role Applied Available Filters Search: Free text search on terms in the resource name Unused Permission Criticality: By severity Cloud Accounts: Account name or account number by cloud provider. For example, AWS Access Categories: Admin, Write, Read, or Empty Access Policy Types: AWS-Managed, Customer, Inline Findings: See Findings Next StepsTo reduce the entitlements for a particular user, click on the user name to open the detail drawer and subtabs.\nOptimize AWS User Entitlements Optimize GCP User Entitlements Optimize Azure User Entitlements ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/identity/users/"},{"id":425,"title":"Vulnerability Admission Policies","content":"Create and Assign PoliciesTo create and assign Vulnerability Policies with the Sysdig Admission Controller, you can follow the guidelines documented in the Vulnerability Management Policies documentation.\nWhen creating a Vulnerability Admission Policy, ensure you are validating the rules and scopes in a lower environments before implementing. Do this to prevent workload disruptions in your production environments.\nVulnerability Management EventsYou can observe Vulnerability Admission Control events in two places within the Sysdig Secure Platform.\nThe command line interface. (CLI) where the Action was performed. The Events Feed. For examples of each, see Use Cases and Examples.\nReject and Scan ActionsWhen using the Reject and Scan action, the Admission Controller performs scans on a best-effort basis. Results appear with the associated Rejection and subsequent events the Events Feed after some time.\nWe recommend you scan your images in your CI/CD Pipelines and Registries before they are deployed.\nUse Cases and ExamplesThe following are a few examples of Admission Controller use cases and guidance on how you can use the Sysdig Admission Controller to enforce your organizational best-practices.\nReject Images with Critical Vulnerabilities with Exploits AvailableBy using the Severities and Threats Rule type defined in the Vulnerability, Image Configuration and Content, you can define the following rule to ensure no Critical Vulnerabilities with Exploit Criteria reach your runtime environments:\nCreate a Rule Bundle with the following Vulnerability, Image Configuration and Content enabled: Severities and Threats With Severity Greater than or Equals Critical Exploitability Metrics Public Exploit Available Create a Vulnerability Management Policy and attach the previously created Rule Bundle. Set the Admission Control Stage with the scope set to All Infrastructure Set the Policy Action to Reject Once saved you can test the Policy Action by deploying a known bad workload and observing the failures in the CLI during kubectl execution and Events Feed\nCLIkubectl create deployment httpd --image=httpd:2.4.50 error: failed to create deployment: admission webhook \u0026#34;vac.secure.sysdig.com\u0026#34; denied the request: [VM Engine] Failed checks for container httpd. Failing policies: [Sysdig Admission Control - Examples] Violations: x Fixable x Public Exploit available x Severity greater than or equal critical Events Feed Reject Unknown Images and Implement Deploy-Time Image Scanning (Unscanned Images)By implementing the Reject and Scan functionality on Unknown Images, you can prevent unknown Third Party images from entering your cluster or Images that may not have been scanned in a previous stage such as CLI or Pipeline.\nSimilar to above, implement a Policy with a pre-defined Rule Bundle and when selecting the Admission Control stage set the following in your Admission Controller Stage:\nUnknown Image Actions: Reject and Scan This will allow you on-top of your already defined Rule Bundles, prevent Unknown Images from entering your clusters.\nYou can view these events in the CLI during kubectl execution or in the Events Feed.\nCLIkubectl create deployment httpd --image=httpd:2.4.50 error: failed to create deployment: admission webhook \u0026#34;vac.secure.sysdig.com\u0026#34; denied the request: [VM Engine] Failed checks for container httpd, image is not known. Failing policies: [Sysdig Admission Control - Examples] Events Feed Scans performed by the Admission Controller are performed on a Best Effort basis and will appear in the Event after some time. It is always recommended to pre-scan your images in your CI/CD Pipelines and Registries before they are deployed.\nEnforce specific Image Labels for Image OwnershipBy using the Image Configuration Rule type defined in the Vulnerability, Image Configuration and Content you can define the following rule to ensure your development teams are appropriately tagging their images before they reach your runtime environments.\nCreate a Rule Bundle with the following Vulnerability, Image Configuration and Content enabled Image Label Label org.opencontainers.image.authors does not exist and value does not contain @example.com Create and add this Rule to a Vulnerability Management Policy Set the Admission Control Stage with the scope set to All Infrastructure Set the Policy Action to Reject. Save your changes. To test the Policy Action, deploy a known bad workload and observe the failures in the CLI or the Events Feed during kubectl execution. CLI kubectl create deployment httpd --image=httpd:2.4.50 error: failed to create deployment: admission webhook \u0026#34;vac.secure.sysdig.com\u0026#34; denied the request: [VM Engine] Failed checks for container httpd. Failing policies: [OCI Best Practices - Image Configuration, Sysdig Admission Control - Examples] Violations: x Fixable x Public Exploit available x Severity greater than or equal critical x Value @example.com not found in label org.opencontainers.image.authors Events Feed ","url":"https://docs.sysdig.com/en/sysdig-secure/admission-controller/vulnerabilities/"},{"id":426,"title":"(Legacy) Filtering Prometheus Metrics","content":" Ensure that the Prometheus scraping is enabled in the dragent.yaml file.\nprometheus: enabled: true On agent v9.8.0 and above, enable the feature by setting the\nuse_promscrape parameter to true in the dragent.yaml. See Enable Filtering at Ingestion.\nEdit the configuration in the prometheus.yaml file. See Edit Prometheus Configuration File.\nSysdig-specific configuration is found in the prometheus.yaml file.\nEnable Filtering at IngestionOn agent v9.8.0, in order for target filtering to work, the use_promscrape parameter in the dragent.yaml must be set to true. For more information on configuration, see Configuring Sysdig Agent.\nuse_promscrape: true On agent v10.0, use_promscrape is enabled by default. Implies, promscrape is used for scraping Prometheus metrics.\nFiltering configuration is optional. The absence of prometheus.yaml will not change the existing behavior of the agent.\nEdit Prometheus Configuration FileAbout the Prometheus Configuration FileThe prometheus.yaml file contains mostly the filtering/relabeling configuration in a list of key-value pairs, representing target process attributes.\nYou replace keys and values with the desired tags corresponding to your environment.\nIn this file, you will configure the following:\nDefault scrape interval (optional).\nFor example:\nscrape_interval: 10s\nOf the labeling parameters that Prometheus offers, Sysdig supports only metric_relabel_configs. The relabel_config parameter is not supported.\nZero or more process-specific filtering configurations (optional).\nSee Kubernetes Environments and Docker Environments\nThe filtering configuration includes:\nFiltering rules\nFor example:\n- source_labels: [container_label_io_kubernetes_pod_name]\nLimit on number of scraped samples (optional)\nFor example:\nsample_limit: 2000\nDefault filtering configuration (optional). The filtering configuration includes:\nFiltering rules\nFor example:\n- source_labels: [car]\nLimit on number of scraped samples (optional)\nFor example:\nsample_limit: 2000\nThe prometheus.yaml file is installed alongside dragent.yaml. For the most part, the syntax of prometheus.yaml complies with the standard Prometheus configuration. Default ConfigurationA configuration with empty key-value pairs is considered a default configuration. The default configuration will be applied to all the processes to be scraped that don\u0026rsquo;t have a matching filtering configuration. In Sample Prometheus Configuration File, the job_name: 'default' section represents the default configuration.\nKubernetes EnvironmentsIf the agent runs in Kubernetes environments (Open Source/OpenShift/GKE), include the following Kubernetes objects as key-value pairs. See Agent Installation on Kubernetes for details on agent installation.\nFor example:\nsysdig_sd_configs: - tags: namespace: backend deployment: my-api In addition to the aforementioned tags, any of these object types can be matched against:\ndaemonset: my_daemon deployment: my_deployment hpa: my_hpa namespace: my_namespace node: my_node pod: my_pode replicaset: my_replica replicationcontroller: my_controller resourcequota: my_quota service: my_service stateful: my_statefulset For Kubernetes/OpenShift/GKE deployments, prometheus.yaml shares the same ConfigMap with dragent.yaml.\nDocker EnvironmentsIn Docker environments, include attributes such as container, host, port, and more. For example:\nsysdig_sd_configs: - tags: host: my-host port: 8080 For Docker-based deployments, prometheus.yaml can be mounted from the host.\nSample Prometheus Configuration Fileglobal: scrape_interval: 20s scrape_configs: - job_name: \u0026#39;default\u0026#39; sysdig_sd_configs: # default config relabel_configs: - job_name: \u0026#39;my-app-job\u0026#39; sample_limit: 2000 sysdig_sd_configs: # apply this filtering config only to my-app - tags: namespace: backend deployment: my-app metric_relabel_configs: # Drop all metrics starting with http_ - source_labels: [__name__] regex: \u0026#34;http_(.+)\u0026#34; action: drop metric_relabel_configs: # Drop all metrics for which the city label equals atlantis - source_labels: [city] regex: \u0026#34;atlantis\u0026#34; action: drop ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycollect-prometheus-metrics/filtering-prometheus-metrics/"},{"id":427,"title":"ADFS (SAML On-Prem)","content":"PrerequisitesReview SAML (On-Prem) before you begin.\nThese instructions assume you already have a working, Internet-accessible ADFS (Active Directory Federation Service) server.\nFor Service-Provider-Initiated Login Flow Right-click to Service \u0026gt; Edit Federation Service Properties. Note the hostname in the Federation Service Identifier, as this will be used in the metadata URL that you paste in the Metadata entry on the SAML Configuration page in the Sysdig authentication settings. Specifically, the metadata URL will be of the format https://HOSTNAME/FederationMetadata/2007-06/FederationMetadata.xml. Also, so that the Sysdig platform can access this URL directly, this host must resolve in DNS and have a valid (not self-signed) SSL/TLS certificate.\nAdd a Relying Party Trust configuration for the Sysdig application.\nRight-click to Relying Party Trusts \u0026gt; Add Relying Party Trust and click Start to begin the wizard.\nIn the Select Data Source step, click the button to Enter data about the relying party manually, then click Next\nEnter a Display name of your choosing (e.g. \u0026ldquo;Sysdig Monitor\u0026rdquo; or \u0026ldquo;Sysdig Secure\u0026rdquo;), then click Next\nClick Next to accept the default option to use AD FS profile\nClick Next to skip the selection of an optional token encryption certificate (Sysdig does not support this option)\nCheck the box to Enable support for the SAML 2.0 Web SSO protocol, then enter one of the following values for Relying party SAML 2.0 SSO service URL:\nIf configuring Sysdig Monitor in the US East, enter: https://\u0026lt;hostname\u0026gt;/api/saml/auth\nIf configuring Sysdig Secure in the US East, enter: https://\u0026lt;hostname\u0026gt;/api/saml/secureAuth\nReplace \u0026lt;hostname\u0026gt; with the unique hostname associated with your on-prem deployment. For other regions, the format is https://\u0026lt;region\u0026gt;.\u0026lt;hostname\u0026gt;/api/saml/auth and https://\u0026lt;region\u0026gt;.\u0026lt;hostname\u0026gt;/api/saml/secureAuth.\nThen click Next.\nFor the Relying party trust identifier, enter one of the following values:\nIf configuring Sysdig Monitor in the US East, enter: https://\u0026lt;hostname\u0026gt;\nIf configuring Sysdig Secure in the US East, enter: https://\u0026lt;hostname\u0026gt;/secure/\nReplace \u0026lt;hostname\u0026gt; with the unique hostname associated with your on-prem deployment. For other regions, the format is https://\u0026lt;region\u0026gt;.\u0026lt;hostname\u0026gt;/api/saml/auth and https://\u0026lt;region\u0026gt;.\u0026lt;hostname\u0026gt;/api/saml/secureAuth.\nThen click Add, then click Next\nClick Next to skip configuration of multi-factor authentication\nChoose a policy for whether users will be permitted to login to the Sysdig application. The default to Permit all users to access the relying party will typically be acceptable. Click Next.\nReview the summary and click Next to complete the configuration of the Relying Party Trust\nThe next step will involve adding Claim Rules, so you can leave the box checked to Open the Edit Claim Rules dialog and click the Close button to be brought immediately into the Claim Rules editor\nEnsure that the SamlResponseSignature option matches the Sysdig authentication configuration.\nUse the Set-AdfsRelyingPartyTrust/Get-AdfsRelyingPartyTrust cmdlets via PowerShell to configure SamlResponseSignature .\n-SamlResponseSignature Specifies the response signatures that the relying party expects. The acceptable values for this parameter are: AssertionOnly MessageAndAssertion MessageOnly For more information, see Set-AdfsRelyingPartyTrust.\nNavigate to Settings \u0026gt; Authentication on the Sysdig app and check the Sysdig authentication setting maps to the SamlResponseSignature :\nFor MessageAndAssertion, enable both the options.\nNext, use the Claim Rules to ensure that login data is sent as needed to the Sysdig platform. A user\u0026rsquo;s login to the Sysdig platform is based on an email address, and a default ADFS configuration would not send the email address as required. The following configuration ensures the correct field from Active Directory is delivered in the claim.\nIf not already in the Claim Rules editor from the previous step, navigate to it by right-clicking on the Relying Party Trust that was just created and selecting Edit Claim Rules\nClick Add Rule. At the following screen, accept the default rule template to Send LDAP Attributes as Claims and click Next.\nEnter a name for the rule, select Active Directory as the Attribute store, then use the pull-down selectors to pick E-Mail Address as both the LDAP Attribute and Outgoing Claim Type, then similarly make pull-down selections for Given Name and Surname. Once these selections are made, click Finish.\nNow click Add Rule again, this time selecting the template for Transform an incoming claim\nEnter a name for the rule, then use the pull-downs to select an Incoming claim type of E-Mail Address, an Outgoing claim type of Name ID, and an Outgoing name ID format of Email, then click Finish.\n(Optional) If you want the user\u0026rsquo;s First Name and Last Name to be included in the records created in the Sysdig platform database when new users successfully login via SAML for the first time, additional Transform rules must also be created. Only the email-based username is strictly required and we already created a rule for this, so this step is optional.\nIf you wish to do this, click Add Rule and once again select the template for Transform an incoming claim. Enter a name for the rule, then use the pull-down to select an Incoming claim type of Given Name, and for the Outgoing claim type, directly type first name into the field. After clicking Finish, click Add Rule and create a similar rule to transform the Incoming claim type of Surname to the Outgoing claim type of last name.\nHaving clicked Finish after creating your last rule, you will see all rules now in the editor. Click Ok, and your ADFS configuration for your Sysdig application is complete.\nFor IdP-Initiated Login Flow (Optional)(Optional) The steps above represent a Service-Provider-Initiated SAML configuration. If you would prefer an IdP-initiated SAML configuration, this is also possible with ADFS, but requires the additional steps described below.\nThe Sysdig platform requires a specific setting of RelayState in order to accept IdP-initiated login flows. On the ADFS versions tested, we\u0026rsquo;ve found this use of RelayState is disabled by default, and a Microsoft article describes the topic in detail. To enable it, as described in a Microsoft forum thread, on your ADFS host, edit %systemroot%\\ADFS\\Microsoft.IdentityServer.Servicehost.exe.config and add \u0026lt;useRelayStateForIdpInitiatedSignOn enabled=\u0026quot;true\u0026quot; /\u0026gt; to the \u0026lt;microsoft.identityserver.web\u0026gt; section. Once the modification is saved, restart ADFS services for the change to take effect.\nYou will need to retrieve your Sysdig customer number as described in the Find Your Customer Number article.\nYou will then need to generate an IdP-initiated login URL.\nIn addition to having the correct settings, it must be properly URL encoded. To ease this configuration, use this ADFS RelayState Generator tool. When launched, enter the values below, then hit the Generate URL button.\nFor the IDP URL String, enter https://YOUR_ADFS_SERVER/adfs/ls/idpinitiatedsignon.aspx\nFor the Relying Party Identifier, enter one of the following values if you are in the US East region:\nIf configuring Sysdig Monitor, enter https://\u0026lt;hostname\u0026gt;.\nIf configuring Sysdig Secure, enter https://\u0026lt;hostname\u0026gt;/secure/\nReplace \u0026lt;hostname\u0026gt; with the unique hostname associated with your on-prem deployment.\nFor other regions, the format is https://\u0026lt;region\u0026gt;.\u0026lt;hostname\u0026gt; for Sysdig Monitor and https://\u0026lt;region\u0026gt;.\u0026lt;hostname\u0026gt;/secure/ for Sysdig Secure. Replace \u0026lt;region\u0026gt; with the region where your Sysdig application is hosted.\nSee SaaS Regions and IP Ranges for more information on regions.\nFor the Relay State/Target App, enter #/\u0026amp;customer=CUSTOMER-ID-NUMBER, substituting the CUSTOMER-ID-NUMBER you retrieved in the previous step\nThis Results URL will be used in the metadata URL that you paste in the Metadata entry in the SAML connection settings.\nUse the Results URL from the tool to test your IdP-initiated login. Note that per this Microsoft forum thread, it is apparently not possible to configure ADFS to use such a URL when your users select the application from the pull-down menu at https://YOUR_ADFS_SERVER/adfs/ls/idpinitiatedsignon.aspx. However, you may embed the URL into a custom portal or bookmarks list.\nNow you can test login using an Active Directory user that has an Email address configured.\nTest Metadata (Optional)To ensure the metadata URL you copy at the end of the IDP configuration procedure is correct, you can test it by directly accessing it via your browser.\nWhen accessing the URL, your browser should immediately download an XML file that begins similarly to the example shown below. No entry of credentials or other security measures should be required to successfully download it. If this is not the case, revisit the IDP configuration steps.\n\u0026lt;?xml version= \u0026quot;1.0\u0026quot; ?\u0026gt; \u0026lt;EntityDescriptor xmlns= \u0026quot;urn:oasis:names:tc:SAML:2.0:metadata\u0026quot; entityID= \u0026quot;https://app.onelogin.com/saml/metadata/680358\u0026quot; \u0026gt; `\u0026lt;IDPSSODescriptor xmlns:ds=` `\u0026quot;http://www.w3.org/2000/09/xmldsig#\u0026quot; ` `protocolSupportEnumeration=` `\u0026quot;urn:oasis:names:tc:SAML:2.0:protocol\u0026quot;` `\u0026gt;names:tc:SAML:` `2.0` `:metadata` `\u0026quot; entityID=\u0026quot;` ` https://app.onelogin.com/saml/metadata/ ` `680358` `\u0026quot;\u0026gt;` ... ","url":"https://docs.sysdig.com/en/administration/onprem-adfs-saml/"},{"id":428,"title":"Manage Serverless Agent Logs","content":" Workload logs remain with whatever log setup you have on your task container.\nInstrumentation logs, namely the logs associated with the Workload Agent, are stored in a separate log group created by the serverless instrumentation stack:\n\u0026lt;stack_name\u0026gt;-SysdigLogGroup-\u0026lt;uid\u0026gt;\nCurrently, the log group name for instrumentation cannot be edited.\nYou can configure the instrumentation logs by using the environment variables described below.\nSet Global Log LevelThe environment variable SYSDIG_LOGGING sets the global instrumentation log level.\nIt defaults to info.\nAvailable options are: silent | fatal | critical | error | warning | info | debug | trace.\nConfigure the Logging MechanismAs of serverless agent version 4.0.0, you can fine-tune the Workload Agent as described in Manage Agent Log Levels as follows:\nPrevent excessive logging from certain components Enable extra logging from specific components for troubleshooting Use the environment variable SYSDIG_EXTRA_CONF to do so.\nThe following example shows the configuration string sets the global log level to info and the log level of the security_mgr component to warning.\nSYSDIG_EXTRA_CONF=\u0026#34;log: { console_priority: info, console_priority_by_component: [ \u0026#39;security_mgr: warning\u0026#39; ] }\u0026#34; Log ForwardingBy default, the instrumentation logs are wrapped as JSON objects and forwarded to the \u0026lt;stack_name\u0026gt;-SysdigLogGroup-\u0026lt;uid\u0026gt; log group.\nConfigure log forwarding using the following environment variables:\nEnvironment Variable Default Description SYSDIG_ENABLE_LOG_FORWARD true Enables and disables the log forwarding. Set to false to disable the log forwarding. SYSDIG_LOG_FORWARD_FORMAT json Defines the format of the instrumentation log events. Set to text to get logs in plaintext. Disable Log ForwardingUse the following configuration to disable the log forwarding. If you do so, the Workload Agent logs will be stored along with the workload logs.\nSYSDIG_ENABLE_LOG_FORWARD=\u0026#34;false\u0026#34; Note that when log forwarding is disabled, the log forwarding format switches to text automatically.\nForward Logs in Text FormatTo forward instrumentation logs to text format, use the following configuration string:\nSYSDIG_LOG_FORWARD_FORMAT=\u0026#34;text\u0026#34; You can also configure the log Workload Agent to forward logs to a different TCP endpoint by using the following environment variables:\nEnvironment Variable Default Description SYSDIG_LOG_LISTEN_PORT 32000 The port of the log listener. SYSDIG_LOG_FORWARD_ADDR localhost:32000 The TCP endpoint the logwriter of the Workload Agent listens. SYSDIG_BUFFER_SIZE 1024 The size in bytes of the rx buffer of the TCP listener. Default 1024. SYSDIG_DEADLINE_SECONDS 3 Connection deadline. You can increase it, if clients take longer to connect. ","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-ecs-agent-logs/"},{"id":429,"title":"Apache","content":" This integration is enabled by default.\nVersions supported: 2.4\nThis integration uses a sidecar exporter that is available in UBI or scratch base image.\nThis integration has 11 metrics.\nTimeseries generated: 100 timeseries\nList of Alerts Alert Description Format [Apache] No Instance Up No instances up Prometheus [Apache] Up Time Less Than One Hour Instance with UpTime less than one hour Prometheus [Apache] Time Since Last OK Request More Than One Hour Time since last OK request higher than one hour Prometheus [Apache] High Error Rate High error rate Prometheus [Apache] High Rate Of Busy Workers In Instance Low workers in open_slot state Prometheus List of DashboardsApache App OverviewThe dashboard provides information on the status of the Apache resources. List of Metrics Metric name apache_accesses_total apache_connections apache_cpuload apache_duration_ms_total apache_http_last_request_seconds apache_http_response_codes_total apache_scoreboard apache_sent_kilobytes_total apache_up apache_uptime_seconds_total apache_workers PrerequisitesCreate Grok ConfigurationYou need to add the Grok configuration in order to parse Apache logs and get metrics from them.\nInstall It Directly In Your Clusterhelm install -n Your-Application-Namespace apache-exporter --repo https://sysdiglabs.github.io/integrations-charts --set configmap=true Download and ApplyYou can download the file and execute the next command\nkubectl -n Your-Application-Namespace apply -f grok-configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: grok-config data: config.yml: | global: config_version: 3 input: type: file path: /tmp/logs/accesss.log fail_on_missing_logfile: false readall: true imports: - type: grok_patterns dir: ./patterns metrics: - type: counter name: apache_http_response_codes_total help: HTTP requests to Apache match: \u0026#39;%{COMMONAPACHELOG}\u0026#39; labels: code: \u0026#39;{{.response}}\u0026#39; method: \u0026#39;{{.verb}}\u0026#39; - type: gauge name: apache_http_response_bytes_total help: Size of HTTP responses match: \u0026#39;%{COMMONAPACHELOG}\u0026#39; value: \u0026#39;{{.bytes}}\u0026#39; cumulative: true labels: code: \u0026#39;{{.response}}\u0026#39; method: \u0026#39;{{.verb}}\u0026#39; - type: gauge name: apache_http_last_request_seconds help: Timestamp of the last HTTP request match: \u0026#39;%{COMMONAPACHELOG}\u0026#39; value: \u0026#39;{{timestamp \u0026#34;02/Jan/2006:15:04:05 -0700\u0026#34; .timestamp}}\u0026#39; labels: code: \u0026#39;{{.response}}\u0026#39; method: \u0026#39;{{.verb}}\u0026#39; server: protocol: http Check Apache ConfigurationApache provides metrics in its own format via its ServerStatus module. To enable this module, include (or uncomment) the following line in your apache configuration file:\nLoadModule status_module modules/mod_status.so \u0026lt;Location \u0026#34;/server-status\u0026#34;\u0026gt; SetHandler server-status \u0026lt;/Location\u0026gt; To configure Apache server to produce common logs, include (or uncomment) the following in your Apache configuration file:\n\u0026lt;IfModule log_config_module\u0026gt; LogFormat \u0026#34;%h %l %u %t \\\u0026#34;%r\\\u0026#34; %\u0026gt;s %b \\\u0026#34;%{Referer}i\\\u0026#34; \\\u0026#34;%{User-Agent}i\\\u0026#34;\u0026#34; combined CustomLog /usr/local/apache2/logs/accesss.log common \u0026lt;/IfModule\u0026gt; InstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/apache-exporter\nAgent ConfigurationThe default agent jobs for this integration are as follows:\n- job_name: apache-exporter-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;apache\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__address__,__meta_kubernetes_pod_container_port_number] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:9117 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: apache-grok-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;apache\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__address__,__meta_kubernetes_pod_container_port_number] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:9144 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/apache/"},{"id":430,"title":"Monitor Alert Automation","content":"Alert Automations let you define automated workflows that run when an alert fires in Sysdig Monitor. Automations are linked directly to individual alerts from within the alert configuration — the automation itself does not define which alerts activate it. You can use branching conditions to route notifications to the right channels based on alert properties such as type, severity, or group, helping you reduce noise and focus on what matters.\nAutomations are scoped by Team. You can only view and manage automations that belong to the team you are currently logged into.\nAn example workflow:\nCreate an automation with a condition: if severity is High, send a PagerDuty notification to the on-call team. For all other severities (FALSE branch), send an email summary to a monitoring distribution list. Link the automation to one or more alerts from within the Alert Editor. Create an AutomationTo create a new automation:\nLog in to Sysdig Monitor.\nSelect Alerts from the left navigation bar.\nSelect Automations from the sub-menu.\nThe Automations page appears, showing all existing automations with their name, status, last execution time, and last modified date.\nSelect New Automation in the top-right corner.\nThe automation editor opens. The Alert Occurrence node at the top of the flow represents the entry point — it is activated when an alert that is linked to this automation fires. Proceed to Configure an Automation.\nIntegrate Automations with AlertsAutomations are activated by alerts that are explicitly linked to them. To link an alert to an automation, open the alert in the Alert Editor and select the automation from the Automations field in the Notifications section. An alert can be linked to multiple automations, and a single automation can be linked to multiple alerts.\nConfigure an AutomationYou can build automations visually through logic chains of conditions and actions.\nFiltersFilters let you limit a condition node to a specific subset of alert events.\nThe following suggested filters are available:\nAlert Type: The type of alert, such as threshold, prometheus, event, group_outlier, change, or downtime. Severity: The alert severity level: high, medium, low, or info. Threshold: The name of the alert rule. Group: The group the alert belongs to. In addition to these, you can filter on any of the Labels (50+) available in your environment, including agent tags and Kubernetes labels such as agent.tag.region, kubernetes.namespace.name, and others.\nYou can combine multiple filters within a single node using AND logic.\nActionsSelect the + icon below any node to add an action. The Select an Action modal provides the following options:\nConditionAdd a Condition node to branch the automation flow based on alert properties. A condition evaluates to either TRUE or FALSE, and you can attach different subsequent actions to each outcome.\nConfigure a condition using the same filter options available on the trigger. For example:\nAlert Type in threshold AND Severity in high NotificationsSend notifications to any of the following channels when the automation runs:\nSlack: Send a message to a configured Slack channel. MS Teams: Send a message to a Microsoft Teams channel. Email: Send an email to a configured email notification channel. Webhook: Send a payload to a configured webhook URL. PagerDuty: Trigger or resolve an incident in PagerDuty. SNS: Publish a message to an Amazon SNS topic. Google Chat: Send a message to a Google Chat space. OpsGenie: Create or close an alert in OpsGenie. Prometheus Alert Manager: Forward the alert to a Prometheus Alertmanager instance. Team Email: Send an email to a Sysdig team\u0026rsquo;s email address. Victor Ops: Send an alert to a VictorOps (Splunk On-Call) channel. To use any notification action, you must first set up the corresponding notification channel. See Set Up Notification Channels.\nOther Custom Webhook: Send a customized HTTP request to any endpoint, independent of a pre-configured notification channel. Enable or Disable an AutomationUse the Enabled toggle in the top-right corner of the editor to activate or deactivate an automation. Disabled automations will not run even when a linked alert fires.\nSave an AutomationSelect Save in the top-right corner to save your automation. You cannot save an automation with an incomplete configuration, for example, if a notification action has not been linked to a notification channel.\nReview ExecutionsEach time an automation is triggered, Sysdig logs the execution so you can monitor and debug your automation flows.\nTo review executions:\nLog in to Sysdig Monitor.\nSelect Alerts \u0026gt; Automations.\nSelect an existing automation.\nSelect the Executions tab.\nThe executions log shows the history of all times the automation was triggered, including:\nTime: The timestamp of the execution. Status: Whether the execution Succeeded or Failed. Failing Nodes: The nodes that failed, if any. You can filter the list by All, Succeeded, or Failed.\nSelect an execution to inspect its details.\nThe execution detail view shows:\nExecution Context: The status and result (True or False) of each node, along with the variable values that were evaluated at the time of execution. Configuration: The automation configuration as it was at the time of execution. You can also select Download JSON to export the full execution context for further analysis.\nNodes that executed successfully are highlighted in green in the flow diagram. Failed nodes are highlighted in red.\nEach execution record is a snapshot. If you later modify the automation, previous executions continue to display the automation flow as it was when they ran, so you can debug them against the configuration that was actually in effect at the time.\nDelete an AutomationTo delete an automation:\nLog in to Sysdig Monitor.\nSelect Alerts \u0026gt; Automations.\nThe Automations page appears.\nOn the right side of an automation listing, select the three-dot menu icon.\nSelect Delete, and confirm the deletion.\nDeleting an automation does not remove it from any alerts it was linked to. You must manually remove the automation from each linked alert in the Alert Editor before you can save further changes to those alerts.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/alerts/automations/"},{"id":431,"title":"AWS Elastic Registry Scanner","content":"AWS ECR Single Account Use the single account AWS Elastic Container Registry (ECR) installation to target one registry per installation. To onboard an entire organization containing several member accounts, check the AWS ECR Organizational setup\nEnsure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes.\nUse one of the following installation methods based on where the Kubernetes cluster is located:\nSame AWS AccountIf Elastic Kubernetes Service (EKS) and the registry are in the same account, launch the installation in that account with an AWS EKS. No specific credential setup is required, since EKS already grants AmazonEC2ContainerRegistryReadOnly policy to the default nodes-eks-node-group-* role.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=ecr \\ --set config.registryURL=\u0026lt;AWS_REGISTRY_URL\u0026gt; \\ --set config.aws.region=\u0026lt;AWS_REGION\u0026gt; \u0026lt;AWS_REGION\u0026gt;: Registry AWS region \u0026lt;AWS_REGISTRY_URL\u0026gt;: Registry URL, such as 123456789012.dkr.ecr.us-east-1.amazonaws.com. Different Account or Kubernetes Not in AWSCredentials are required in this case:\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=ecr \\ --set config.registryURL=\u0026lt;AWS_REGISTRY_URL\u0026gt; \\ --set config.aws.region=\u0026lt;AWS_REGION\u0026gt; \\ --set config.aws.accessKeyId=\u0026lt;AWS_ACCESS_KEY_ID\u0026gt; \\ --set config.aws.secretAccessKey=\u0026lt;AWS_SECRET_ACCESS_KEY\u0026gt; \u0026lt;AWS_REGION\u0026gt;: Registry AWS region\n\u0026lt;AWS_REGISTRY_URL\u0026gt;: Registry URL, such as 123456789012.dkr.ecr.us-east-1.amazonaws.com.\n\u0026lt;AWS_ACCESS_KEY_ID\u0026gt;, \u0026lt;AWS_SECRET_ACCESS_KEY\u0026gt; from an AWS user with the following permissions for the given registry to be scanned:\necr:GetAuthorizationToken ecr:BatchCheckLayerAvailability ecr:GetDownloadUrlForLayer ecr:GetRepositoryPolicy ecr:DescribeRepositories ecr:ListImages ecr:DescribeImages ecr:BatchGetImage ecr:GetLifecyclePolicy ecr:GetLifecyclePolicyPreview ecr:ListTagsForResource ecr:DescribeImageScanFindings Limitations The scanner for single-account will target a single registry; in other words, the registry of one region. To scan several regions, either use the AWS Organizational scanner or set up one scanner per region. If the AWS Kubernetes cluster and the registry are in different accounts but under the same organization, use the AWS Organizational setup and allow listing a specific account. AWS ECR OrganizationalAWS organizational accounts have a management account with multiple member accounts and multiple registries or regions. This option allows scanning of all registries on any member account or the region of an AWS Organization. The Kubernetes cluster that the registry will scan may be inside or outside of AWS.\nProcess OverviewYou will:\nSet up roles and permissions in the AWS console to be used for registry scanning. Optionally, validate the setup with a Sysdig test script Optionally, add a configuration to the Helm chart to limit the member accounts that will be checked for scanning. Install with the Helm chart in one of two ways: Option 1: Access Key/Secret Key With an AWS Identity Access Management (IAM) user security credentials, aimed for quick testing or a more simple setup. Option 2: Service Account With AWS Kubernetes Service Account, aimed for a more productive scenario. Set Up Permissions in AWSIn the AWS console, set up authentication roles to allow discoverability.\nYou will:\nCreate one role in the management account (ORGANIZATION_MANAGEMENT_ROLE_ARN). A recommended step is to create a role name to be assigned to every targeted member account (ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME). Otherwise, the default AWS member role name OrganizationAccountAccessRole will be used, which includes admin privileges. Tip: To narrow the list of member accounts that will be checked during scanning, you can set the aws.AllowListMemberAccountIDs attribute option in the Registry Scanner Helm chart. This eliminates noisy error messages. Optionally, validate the setup using Sysdig\u0026rsquo;s test script. Create Roles Management role: ORGANIZATION_MANAGEMENT_ROLE_ARN will be assumed and used to discover member accounts. Member role name: ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME will be assumed on the member accounts to discover and scan their registries. Providing Credentials to the Registry ScannerThe registry scanner requires three types of credentials to discover and read Amazon Elastic Container Registry (ECR) images from all member accounts and all regions within an AWS organization.\nKubernetes Job/Pod AWS CredentialsYou need to provide either an Access Key/Secret Key or a service account that has the necessary permissions.\nAccess Key/Secret Key\nIf you choose to provide an Access Key/Secret Key, use the \u0026lt;AWS_ACCESS_KEY_ID\u0026gt;, \u0026lt;AWS_SECRET_ACCESS_KEY\u0026gt; format. Then, you need to set the policy permissions required to allow these credentials to impersonate the ORGANIZATION_MANAGEMENT_ROLE_ARN.\nUse the following policy to allow the impersonation:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;AllowAssumeManagementRole\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;\u0026lt;ORGANIZATION_MANAGEMENT_ROLE_ARN\u0026gt;\u0026#34; } ] } Service Account\nFor Amazon Elastic Kubernetes Service (EKS) clusters on AWS, you can configure the necessary permissions at the service account level.\nImportant points:\nCreate an IAM OpenID Connect (OIDC) provider for your EKS cluster. Note: If you deployed the cluster with the EKS Terraform module, it was created automatically (check oidc_provider output).\nIn the role associated with the service account (SERVICE_ACCOUNT_IAM_ROLE_ARN), create a policy to enable assuming the role of the management account.\n{ \u0026#34;Statement\u0026#34;: [ { \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;\u0026lt;ORGANIZATION_MANAGEMENT_ROLE_ARN\u0026gt;\u0026#34;, \u0026#34;Sid\u0026#34;: \u0026#34;\u0026#34; } ], \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34; } In the role associated with the service account (SERVICE_ACCOUNT_IAM_ROLE_ARN), configure a trust relationship to allow the service account in Kubernetes to assume the role.\nDefault SERVICE_ACCOUNT_NAME will be registry-scanner, derived from the helm installation release name. { \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: { \u0026#34;Federated\u0026#34;: \u0026#34;arn:aws:iam::\u0026lt;MANAGEMENT_ACCOUNT\u0026gt;:oidc-provider/\u0026lt;OIDC_PROVIDER\u0026gt;\u0026#34; }, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRoleWithWebIdentity\u0026#34;, \u0026#34;Condition\u0026#34;: { \u0026#34;StringEquals\u0026#34;: { \u0026#34;\u0026lt;OIDC_PROVIDER_URL\u0026gt;:sub\u0026#34;: \u0026#34;system:serviceaccount:\u0026lt;NAMESPACE\u0026gt;:\u0026lt;SERVICE_ACCOUNT_NAME\u0026gt;\u0026#34;, \u0026#34;\u0026lt;OIDC_PROVIDER_URL\u0026gt;:aud\u0026#34;: \u0026#34;sts.amazonaws.com\u0026#34; } } } ] } Save the role \u0026lt;SERVICE_ACCOUNT_IAM_ROLE_ARN\u0026gt; value associated with the Kubernetes service-account and use it during the installation.\nCredentials for the Management RoleProvide credentials for the \u0026lt;ORGANIZATION_MANAGEMENT_ROLE_ARN\u0026gt; to discover registries for all member accounts and all regions. You must assign policy permissions and trust relationships to this role.\nAssign Policy Permissions\nAssign one of the following policy permissions to the management role:\nAWSOrganizationsReadOnlyAccess: AWS managed policy which Provides read-only access to AWS Organizations.\nInline policy to allow the management role to assume member account roles:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;AllowManagementRoleToAssumeMember\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;arn:aws:iam::*:role/\u0026lt;ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME\u0026gt;\u0026#34; } ] } Assign the Trust Relationship\nYou must assign the trust relationship to allow this role to be assumed by the principal of the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY / service account configured in the previous step.\nAccess Key/Secret Key { \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: { \u0026#34;AWS\u0026#34;: \u0026#34;\u0026lt;AWS_ACCESS_USER_ARN\u0026gt;\u0026#34; }, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34; } ] } Service Account\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: { \u0026#34;AWS\u0026#34;: \u0026#34;\u0026lt;SERVICE_ACCOUNT_IAM_ROLE_ARN\u0026gt;\u0026#34; }, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34; } ] } Credentials for the Member Role NameYou need to provide credentials for the \u0026lt;ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME\u0026gt; that is available in all scoped member accounts of the organization with access to discover and read registries within. This role will be assumed by the ORGANIZATION_MANAGEMENT_ROLE_ARN to impersonate each member account.\nBy default, the scanner uses the AWS-created administration role OrganizationAccountAccessRole. Using this role will work fine; however, if you need it, you can create a lower-permission role.\n(Optional) Least-Privilege-Access Permissions\nCreate a role in all accounts and assign the following least-privilege-access permissions to it.\nThe permissions must be assigned to all roles in all accounts that will be scanned.\nAmazonEC2ContainerRegistryReadOnly: AWS managed policy that Provides read-only access to Amazon EC2 Container Registry repositories. Assign the following least-privilege-access permissions to the member role name:\nCustom permissions to allow region discovery:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;CustomPolicyAllowDescribeRegions\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;EC2:DescribeRegions\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } ] } The member role must be assumable by the ORGANIZATION_MANAGEMENT_ROLE_ARN, so you must assign the following trust relationship to the new role:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: { \u0026#34;AWS\u0026#34;: \u0026#34;\u0026lt;ORGANIZATION_MANAGEMENT_ROLE_ARN\u0026gt;\u0026#34; }, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34; } ] } Also, the ORGANIZATION_MANAGEMENT_ROLE_ARN must be configured to allow assuming the ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME you just created in all accounts. You must assign the following policy permission to the management role, which will allow it to assume the member role in all accounts:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;AllowManagementRoleToAssumeMember\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;sts:AssumeRole\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;arn:aws:iam::*:role/\u0026lt;ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME\u0026gt;\u0026#34; } ] } Optionally, if you want to test the role with the validation script of the next section you will need to add the following permissions:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;CustomPolicyAllowDescribeRegions\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: \u0026#34;iam:SimulatePrincipalPolicy\u0026#34;, \u0026#34;Resource\u0026#34;: \u0026#34;*\u0026#34; } ] } (Optional) Validate Setup with Test ScriptSysdig provides the test script aws-org-test-credentials.sh to check the created roles and permissions, along with validating the discoverables registries throughout the organization.\nLaunch the script from a shell. Use the AWS authentication credentials for the member account where the Registry Scanner will be deployed.\nNote: If you\u0026rsquo;re running it with some other credentials from the member account, remember that a trust relationship must exist with the Management Account Role. See Assign the Trust Relationship under Credentials for the Management Role.\n./aws-org-test-credentials.sh \u0026lt;ORGANIZATION_MANAGEMENT_ROLE_ARN\u0026gt; \u0026lt;ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME\u0026gt; Sample output:\n\u0026gt; using *** as member accountID \u0026gt; Organization accountID: *** with discovered member account IDs *** ------------------------- \u0026gt; Starting registry discovery and permission checkup \u0026gt; Account *** Checking AWS registry permissions Discovering registries ... ------------------------- \u0026gt; Discovered Registries ***.dkr.ecr.eu-central-1.amazonaws.com ***.dkr.ecr.eu-west-1.amazonaws.com ... Install with Helm ChartUse one of the following installation options depending on the credential format used:\nAccess Key/Secret KeySuitable for testing or if your Kubernetes cluster is outside AWS.\n\u0026lt;AWS_ACCESS_KEY_ID\u0026gt;, \u0026lt;AWS_SECRET_ACCESS_KEY\u0026gt; from the AWS user\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=ecr \\ --set config.aws.accessKeyId=\u0026lt;AWS_ACCESS_KEY_ID\u0026gt; \\ --set config.aws.secretAccessKey=\u0026lt;AWS_SECRET_ACCESS_KEY\u0026gt; \\ --set config.aws.managementAccountRoleARN=\u0026lt;ORGANIZATION_MANAGEMENT_ROLE_ARN\u0026gt; \\ --set config.aws.memberAccountsRoleName=\u0026lt;ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME\u0026gt; Service AccountIf you\u0026rsquo;re using AWS Elastic Kubernetes Service (EKS), you must assign an IAM role (SERVICE_ACCOUNT_IAM_ROLE_ARN) to a Service Account, with which the scanner will run.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=ecr \\ --set serviceAccount.annotations.eks\\\\.amazonaws\\\\.com/role-arn=\u0026lt;SERVICE_ACCOUNT_IAM_ROLE_ARN\u0026gt; \\ --set config.aws.managementAccountRoleARN=\u0026lt;ORGANIZATION_MANAGEMENT_ROLE_ARN\u0026gt; \\ --set config.aws.memberAccountsRoleName=\u0026lt;ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME\u0026gt; Additional Helm ConfigurationLimit Registry Accounts to ScanOptionally, limit the scoped registry accounts using the allowListMemberAccountIDs Helm chart attribute. This approach is preferred for initial testing, when the ORGANIZATION_MEMBER_ACCOUNTS_ROLE_NAME may be provisioned only on select accounts and having the scanner check the rest of the member accounts in the organization would generate noisy error messages.\nSet the attributes:\n--set config.aws.allowListMemberAccountIDs[0]=\u0026#39;\u0026lt;ORG_MEMBER_ACCOUNT_ID_1\u0026gt;\u0026#39; \\ --set config.aws.allowListMemberAccountIDs[1]=\u0026#39;\u0026lt;ORG_MEMBER_ACCOUNT_ID_2\u0026gt;\u0026#39; \\ Limitations The scanner for AWS Organizational accounts does not support ECRs hosted in the management account, as per AWS Guidelines best practices for management accounts Public registries are not supported. AWS GovCloudTo install the registry Scanner in GovCloud Accounts (both single and organizational), follow the same instructions as above and make sure to specify the AWS GovCloud region with --set config.aws.region=\u0026quot;us-gov-west-1\u0026quot; and to set the right AWS GobCloud ARN format.\n","url":"https://docs.sysdig.com/en/sysdig-secure/aws-elastic-container-registry/"},{"id":432,"title":"AWS Lambda Metrics","content":" This integration can be enabled via the Integrate AWS Lambda Telemetry API.\nThis integration has 4 metrics.\nList of Alerts Alert Description Format [AWS Lambda Metrics] High Function Error Rate High Function Error Rate. Prometheus [AWS Lambda Metrics] Function Timeout Function reached timeout limit. Prometheus List of DashboardsAWS Lambda MetricsThe dashboard provides information on the AWS Lambda integration. List of Metrics Metric name aws_lambda_duration aws_lambda_errors aws_lambda_invocations aws_lambda_postruntime_extensions_duration Monitoring and Troubleshooting AWS Lambda MetricsAWS Lambda service is one of the main services AWS provides for serverless computing. The factors that contribute to high costs are function duration and execution errors. The users should be aware that lengthy or repeated execution increases the cost. This document describes important metrics and queries that you can use to monitor and troubleshoot AWS Lambda.\nUse the label function_name if you want to filter by name of the function.\nInvocationsIf you want to monitor the number of invocations you can use the metric aws_lambda_invocations.\nThe following query gives you the top highest functions invocations:\ntopk(10,sum_over_time(aws_lambda_invocations{function_name!=\u0026#34;\u0026#34;}[5m])) ErrorsThe following query gives you the top 10 highest errors functions:\ntopk(10,sum_over_time(aws_lambda_errors{function_name!=\u0026#34;\u0026#34;}[5m])) DurationThe duration of a serverless function is the main aspect that contributes to its cost. Use the following query to get the top 10 function duration:\ntopk(10,max_over_time(aws_lambda_duration{function_name!=\u0026#34;\u0026#34;}[5m])) You have to take into acccount lambda functions have a timeout of 15 minutes. Use the following alert query you can be aware about that possible issue.\nmax_over_time (aws_lambda_duration{function_name!=\u0026#34;\u0026#34;} [5m]) \u0026gt; 840000 Therefore, if your serverless environment has functions that do not take too much time, use the Duration Dashboards to monitor the average and maximum time of your function executions. This information gives you enough data to manage the correct behavior of your Lambda functions.\ntopk(10,max_over_time(aws_lambda_duration{function_name!=\u0026#34;\u0026#34;}[5m])) The other context to be aware of is that functions could take more time than required and could reach the timeout limit for Lambda functions. You can track this with a specific alert and a dashboard that shows the maximum duration.\nPostRuntime Extend DurationThe function postruntime extend duration might not be as important as the function duration. However, if the postruntime extend duration is higher than usual, you should analyze your environment and function resources, since it represents the duration of the Lambda function control and management, not the computing function time itself. Therefore, if the duration average and maximum begin to increase, you should analyze your functions and Lambda services.\nThe following query gives you the top 10 highest postruntime extensions duration functions:\ntopk(10,sum_over_time(aws_lambda_postruntime_extensions_duration[5m])) ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-lambda-metrics/"},{"id":433,"title":"AWS MetricsStream ALB","content":" This integration can be enabled via the Connect an AWS Account page.\nThis integration has 17 metrics.\nList of Alerts Alert Description Format [AWS ALB] High 4XX Errors From Load Balancer High 4XX Errors From Load Balancer. Prometheus [AWS ALB] High 5XX Errors From Load Balancer High 5XX Errors From Load Balancer. Prometheus [AWS ALB] High 4XX Errors From Target Group High 4XX Errors From Target Group. Prometheus [AWS ALB] High 5XX Errors From Target Group High 5XX Errors From Target Group. Prometheus [AWS ALB] Unhealthy Host In TargetGroup Unhealthy Host In TargetGroup. Prometheus [AWS ALB] TLS Negotiation Errors TLS Negotiation Errors. Prometheus [AWS ALB] Rejected Connections In Load Balancer Rejected Connections In Load Balancer. Prometheus [AWS ALB] High Response Time In Target Group High Response Time In Target Group. Prometheus List of DashboardsAWS ALBThe dashboard provides information on AWS ALB integration. List of Metrics Metric name aws_application_elb_active_connection_count aws_application_elb_client_tls_negotiation_error_count aws_application_elb_consumed_lc_us aws_application_elb_healthy_host_count aws_application_elb_http_code_elb_3xx_count aws_application_elb_http_code_elb_4xx_count aws_application_elb_http_code_elb_5xx_count aws_application_elb_http_code_target_2xx_count aws_application_elb_http_code_target_3xx_count aws_application_elb_http_code_target_4xx_count aws_application_elb_http_code_target_5xx_count aws_application_elb_processed_bytes aws_application_elb_rejected_connection_count aws_application_elb_request_count aws_application_elb_rule_evaluations aws_application_elb_target_response_time aws_application_elb_un_healthy_host_count ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-metricsstream-alb/"},{"id":434,"title":"AWS MetricsStream CloudFront","content":" This integration can be enabled via the Connect an AWS Account page.\nThis integration has 18 metrics.\nIf you don’t turn on the additional metrics in AWS CloudFront, the following panels won’t display any data: Cache hit rate, Origin latency, and Error rate by status code.\nList of Alerts Alert Description Format [AWS CloudFront] High 4XX Error Rate 4XX Error Rate is high. Prometheus [AWS CloudFront] High 5XX Error Rate 5XX Error Rate is high. Prometheus [AWS CloudFront] High Origin Latency Origin Latency is high. To get this metric, you must first turn on \u0026lsquo;additional metrics\u0026rsquo; in AWS CloudFront. Prometheus [AWS CloudFront] Low Cache Hit Rate Cache hit rate is low. To get this metric, you must first turn on \u0026lsquo;additional metrics\u0026rsquo; in AWS CloudFront. Prometheus [AWS CloudFront] High Function Validation Error Rate Function Validation Error Rate is high. Validation errors occur when the function runs successfully but returns invalid data (an invalid event object). Prometheus [AWS CloudFront] High Function Execution Error Rate Function Execution Error Rate is high. Execution errors occur when the function fails to complete successfully. Prometheus [AWS CloudFront] Throttling Function Functions can be throttled after compilation errors, high number of requests per second, and exceeding the maximum allowed execution time. Prometheus List of DashboardsAWS CloudFrontThe dashboard provides information on the AWS CloudFront integration. List of Metrics Metric name aws_cloud_front_401error_rate aws_cloud_front_403error_rate aws_cloud_front_404error_rate aws_cloud_front_4xx_error_rate aws_cloud_front_502error_rate aws_cloud_front_503error_rate aws_cloud_front_504error_rate aws_cloud_front_5xx_error_rate aws_cloud_front_bytes_downloaded aws_cloud_front_bytes_uploaded aws_cloud_front_cache_hit_rate aws_cloud_front_function_compute_utilization aws_cloud_front_function_execution_errors aws_cloud_front_function_invocations aws_cloud_front_function_throttles aws_cloud_front_function_validation_errors aws_cloud_front_origin_latency aws_cloud_front_requests ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-metricsstream-cloudfront/"},{"id":435,"title":"AWS MetricsStream EBS","content":" This integration can be enabled via the Connect an AWS Account page.\nThis integration has 10 metrics.\nList of Alerts Alert Description Format [AWS EBS] Low Volume Performance Low Volume Performance. Used with Provisioned IOPS SSD volumes only. This alert is not supported with Multi-Attach enabled volumes. Prometheus [AWS EBS] Zero Volume Burst Balance Zero Volume Burst Balance. Used with General Purpose SSD (gp2), Throughput Optimized HDD (st1), and Cold HDD (sc1) attached volumes only. Prometheus List of DashboardsAWS EBSThe dashboard provides information on the AWS EBS integration. List of Metrics Metric name aws_ebs_burst_balance aws_ebs_volume_idle_time aws_ebs_volume_queue_length aws_ebs_volume_read_bytes aws_ebs_volume_read_ops aws_ebs_volume_throughput_percentage aws_ebs_volume_total_read_time aws_ebs_volume_total_write_time aws_ebs_volume_write_bytes aws_ebs_volume_write_ops ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-metricsstream-ebs/"},{"id":436,"title":"AWS MetricsStream ELB","content":" This integration can be enabled via the Connect an AWS Account page.\nThis integration has 12 metrics.\nList of Alerts Alert Description Format [AWS ELB] High 4XX Errors From Load Balancer High 4XX Errors From Load Balancer. Prometheus [AWS ELB] High 5XX Errors From Load Balancer High 5XX Errors From Load Balancer. Prometheus [AWS ELB] High 4XX Errors From Backend High 4XX Errors From Backend. Prometheus [AWS ELB] High 5XX Errors From Backend High 5XX Errors From Backend. Prometheus [AWS ELB] Unhealthy Host In Load Balancer Unhealthy Host In Load Balancer. Prometheus [AWS ELB] Queue Spillover Rejections Queue Spillover Rejections. Prometheus [AWS ELB] High Latency In Load Balancer High Latency In Load Balancer. Prometheus List of DashboardsAWS ELBThe dashboard provides information on the AWS ELB integration. List of Metrics Metric name aws_elb_healthy_host_count aws_elb_http_code_backend_2xx_count aws_elb_http_code_backend_3xx_count aws_elb_http_code_backend_4xx_count aws_elb_http_code_backend_5xx_count aws_elb_http_code_elb_4xx_count aws_elb_http_code_elb_5xx_count aws_elb_latency aws_elb_request_count aws_elb_spillover_count aws_elb_surge_queue_length aws_elb_un_healthy_host_count ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-metricsstream-elb/"},{"id":437,"title":"AWS MetricsStream Fargate","content":" This integration can be enabled via the Connect an AWS Account page.\nThis integration has 9 metrics.\nThis integration requires ‘CloudWatch Container Insights’ to be enabled in the AWS ECS account settings.\nList of Alerts Alert Description Format [AWS Fargate] High Cpu Utilization Rate High Cpu Utilization Rate. Prometheus [AWS Fargate] High Memory Utilization Rate High Memory Utilization Rate. Prometheus [AWS Fargate] Recurring Pending Tasks Recurring Pending Tasks. Prometheus List of DashboardsAWS ECS/FargateThe dashboard provides information on the AWS ECS/Fargate integration. List of Metrics Metric name aws_ecs_container_insights_cpu_reserved aws_ecs_container_insights_cpu_utilized aws_ecs_container_insights_desired_task_count aws_ecs_container_insights_memory_reserved aws_ecs_container_insights_memory_utilized aws_ecs_container_insights_pending_task_count aws_ecs_container_insights_running_task_count aws_ecs_container_insights_storage_read_bytes aws_ecs_container_insights_storage_write_bytes ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-metricsstream-fargate/"},{"id":438,"title":"AWS MetricsStream Lambda","content":" This integration can be enabled via the Connect an AWS Account page.\nThis integration has 13 metrics.\nList of Alerts Alert Description Format [AWS Lambda] High Function Error Rate High Function Error Rate. Prometheus [AWS Lambda] Throttling Function Throttling Function. Prometheus [AWS Lambda] Destination Delivery Failures Destination Delivery Failures. Prometheus [AWS Lambda] Dead-Letter Errors Dead-Letter Errors. Prometheus [AWS Lambda] High Iterator Age High Iterator Age. Only for \u0026rsquo;event source mappings\u0026rsquo; that read from streams Prometheus List of DashboardsAWS LambdaThe dashboard provides information on the AWS Lambda integration. List of Metrics Metric name aws_lambda_concurrent_executions aws_lambda_dead_letter_errors aws_lambda_destination_delivery_failures aws_lambda_duration aws_lambda_errors aws_lambda_invocations aws_lambda_iterator_age aws_lambda_provisioned_concurrency_executions aws_lambda_provisioned_concurrency_invocations aws_lambda_provisioned_concurrency_spillover_invocations aws_lambda_provisioned_concurrency_utilization_average aws_lambda_throttles aws_lambda_unreserved_concurrent_executions ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-metricsstream-lambda/"},{"id":439,"title":"AWS MetricsStream RDS","content":" This integration can be enabled via the Connect an AWS Account page.\nThis integration has 15 metrics.\nList of Alerts Alert Description Format [AWS RDS] Long CPU Throttling Long CPU Throttling. Prometheus [AWS RDS] Low Free Memory Low Free Memory. Prometheus [AWS RDS] Low Free Disk Low Free Disk. Prometheus [AWS RDS] Disk Full In 48H [AWS RDS] Disk Full In 48H. Prometheus [AWS RDS] Disk Full In 12H [AWS RDS] Disk Full In 12H. Prometheus [AWS RDS] High Read Latency [AWS RDS] High Read Latency. Prometheus [AWS RDS] High Write Latency [AWS RDS] High Write Latency. Prometheus [AWS RDS] High Disk Queue [AWS RDS] High Disk Queue. Alert only available for PostgreSQL instances. Prometheus List of DashboardsAWS RDSThe dashboard provides information on the AWS RDS integration. List of Metrics Metric name aws_rds_cpu_utilization aws_rds_database_connections aws_rds_disk_queue_depth aws_rds_free_local_storage aws_rds_free_storage_space aws_rds_freeable_memory aws_rds_network_receive_throughput aws_rds_network_transmit_throughput aws_rds_read_iops aws_rds_read_latency aws_rds_read_throughput aws_rds_swap_usage aws_rds_write_iops aws_rds_write_latency aws_rds_write_throughput ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-metricsstream-rds/"},{"id":440,"title":"AWS MetricsStream S3","content":" This integration can be enabled via the Connect an AWS Account page.\nThis integration has 6 metrics.\nList of Alerts Alert Description Format [AWS S3] High 4XX Error Rate High 4XX Error Rate. Prometheus [AWS S3] High 5XX Error Rate High 5XX Error Rate. Prometheus [AWS S3] High First Byte Latency High First Byte Latency. Prometheus List of DashboardsAWS S3The dashboard provides information on the AWS S3 integration. List of Metrics Metric name aws_s3_4xx_errors aws_s3_5xx_errors aws_s3_bytes_downloaded aws_s3_bytes_uploaded aws_s3_first_byte_latency aws_s3_total_request_latency ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-metricsstream-s3/"},{"id":441,"title":"AWS MetricsStream SQS","content":" This integration can be enabled via the Connect an AWS Account page.\nThis integration has 9 metrics.\nList of Alerts Alert Description Format [AWS SQS] High Number Of Messages In Queue High Number Of Messages In Queue Prometheus [AWS SQS] High Latency In Queue High Latency In Queue Prometheus [AWS SQS] Recurring Empty Receives Recurring Empty Receives Prometheus [AWS SQS] Message Received In Queue Message Received In Queue. Useful for example in \u0026lsquo;Dead-Letter\u0026rsquo; queues. Prometheus List of DashboardsAWS SQSThe dashboard provides information on the AWS SQS integration. List of Metrics Metric name aws_sqs_approximate_age_of_oldest_message aws_sqs_approximate_number_of_messages_delayed aws_sqs_approximate_number_of_messages_not_visible aws_sqs_approximate_number_of_messages_visible aws_sqs_number_of_empty_receives aws_sqs_number_of_messages_deleted aws_sqs_number_of_messages_received aws_sqs_number_of_messages_sent aws_sqs_sent_message_size ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/aws-metricsstream-sqs/"},{"id":442,"title":"AWS ML Policy","content":"Key FeaturesThis policy:\nExtends machine learning to AWS cloud accounts to monitor whether AWS console logins follow irregular patterns and notify users about suspicious activity\nQuickly detects AWS log-ons from odd locations or different areas of the globe, as well as from unexpected browsers or OSes.\nEnables advanced machine learning detection capabilities based on CloudTrail logs\nAllows users to understand why an event is considered anomalous compared to the expected behavior. Specifically, the policy provides the following info:\nDescription: What the Anomaly is about\nInfluential Factors: Variables contributing most to anomaly\nConfidence Level: Probability measure of detection accuracy\nThe AWS ML policy is available by default in the main policies menu for all Sysdig Secure SaaS users.\nEvent notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nConfigure AWS ML Custom PolicyIn the Sysdig Secure UI:\nSelect Policies \u0026gt; Runtime Policies.\nClick +Add Policy (at the top right of the page).\nSelect AWS ML policy type.\nConfigure the policy:\nBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description or keep the default one.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info.\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance.\nNote: There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nDetectAnomalous Console Login: Toggle on or off and select the confidence level at which the policy should be triggered: Default, Higher, or Highest.\nDefault: This is the value at which the model is tested by Sysdig\u0026rsquo;s Threat Research Team. Higher and Highest: The higher the value chosen, the lower the chance of false positives, but the higher the chance of false negatives (i.e. missed anomalous behaviors). ActionsNotify: Select a notification channel from the drop-down list for sending notifications of events to appropriate personnel.\nSee also: Set Up Notification Channels.\n","url":"https://docs.sysdig.com/en/sysdig-secure/aws_ml_policy/"},{"id":443,"title":"Configure Azure Active Directory for OIDC","content":"Enabling Azure OpenID Connect for single sign-on to Sysdig applications include configuration on the Microsoft Azure Active Directory as well as on the Sysdig application.\nPrerequisitesEnsure you have administrator privileges on Sysdig and Azure AD.\nConfigure Sysdig Application in Azure AD Log in to the Azure AD portal.\nSearch for Azure Active Directory and do one of the following:\nSelect your Active Directory service\nCreate a new one.\nClick App registration \u0026gt; New registration.\nIn the Register an application page, specify the following:\nName: Display name to identify your Sysdig application. For example, \u0026lsquo;Sysdig Secure\u0026rsquo;.\nSupported account types: For Sysdig SaaS, choose Accounts in this organizational directory only (Default Directory only -Single tenant). All user and guest accounts created in your active directory can use Sysdig application and API.\nRedirect URI: Authenticated Sysdig users are redirected to this URI.\nSee SaaS Regions and IP Ranges and identify the correct domain URL associated with your Sysdig application and region. For example, domain URLs of Monitor and Secure for US East are:\nFor Sysdig Secure: https://secure.sysdig.com/api/oauth/openid/secureAuth\nFor Sysdig Monitor: https://app.sysdigcloud.com/api/oauth/openid/auth\nFor other regions, the format is: https://\u0026lt;region\u0026gt;.app.sysdig.com\nReplace \u0026lt;region\u0026gt; with the region where your Sysdig application is hosted. For example, for Sysdig Monitor you use https://eu1.app.sysdig.com/api/oauth/openid/auth.\nFor on-prem installations, the redirect URI will be deployment-specific.\nYou can add only a single redirect URI on this page. Use the Authentication page associated with your application to add additional redirect URIs.\nClick Register.\nAdd additional redirect URIs.\nSelect your application from App registration.\nClick Authentication from the left navigation.\nAdd the redirect URIs corresponding to Monitor and Secure.\nCreate a Secret for the Sysdig application.\nThis is a string that the Sysdig application uses to prove its identity when requesting a token.\nClick Certificates \u0026amp; secrets.\nUnder Client Secrets, click New client secret.\nEnter a description that identifies the secret and choose an expiration period.\nClick Add.\nCopy the client secret. You will need the client secret when you configure OpenID Connect SSO in the Sysdig Authentication(SSO) settings.\nCopy the Client ID and OpenID Connect endpoints corresponding to the application that you have created.\nSelect your application from App registration.\nCopy the Application (client) ID.\nYou will need the client ID while configuring OpenID Connect SSO on the Sysdig application.\nClick Endpoints.\nCopy the OpenID Connect metadata document and open it in a browser.\nCopy the OpenID Connect URI (Issuer URI).\nFor example, https://login.microsoftonline.com/5a4b56fc-dceb-4a64-94ff-21e08e5892f5/v2.0\nConfigure Sysdig SettingsTo enable Azure OpenID functionality on the Sysdig application, you need the following:\nClient ID\nClient Secret\nIssuer URL.\nSee Enable OpenID in Settings to learn how to complete your configuration.\n","url":"https://docs.sysdig.com/en/administration/saas-azure-openid/"},{"id":444,"title":"Azure (OpenID On-Prem)","content":"To enable Azure OpenID Connect for single sign-on to Sysdig applications, perform configuration through Microsoft Entra ID and the Sysdig UI.\nPrerequisitesAdministrator privileges on Sysdig and Azure Active Directory (AD).\nConfiguring Sysdig Application in Azure AD Log in to the Azure AD portal.\nSelect your Azure Active Directory service or create a new one.\nClick App registration \u0026gt; New registration.\nIn the Register an application page, specify the following:\nName: Display name to identify your Sysdig application. For example, Sysdig Secure.\nSupported account types: Choose an account type that is appropriate for your deployment. If you choose single-tenant, all user and guest accounts created in your active directory can use Sysdig application and API. If you choose multi-tenant, all users with a work or school account from Microsoft can use Sysdig application and API.\nRedirect URI: Authenticated Sysdig users are redirected to this URI.\nFor Login redirect URIs, enter one of the following values, replacing HOSTNAME with the hostname through which your users access the Sysdig applications and PORT with the TCP port number, typically 443:\nFor Sysdig Monitor: https://HOSTNAME:PORT/api/oauth/openid/auth\nFor Sysdig Secure: https://HOSTNAME:PORT/api/oauth/openid/secureAuth\nYou can add only a single redirect URL on this page. Use the Authentication page associated with your application to add additional redirect URIs.\nClick Register.\nAdd additional redirect URIs.\nSelect your application from App registration.\nClick Authentication from the left navigation.\nAdd the redirect URIs corresponding to Monitor and Secure.\nCreate a Secret for the Sysdig application.\nIt is a string that the Sysdig application uses to prove its identity when requesting a token.\nClick Certificates \u0026amp; secrets.\nUnder Client Secrets, click New client secret.\nEnter a description that identifies the secret and choose an expiration period.\nClick Add.\nCopy the client secret. You will need the client secret while configuring OpenID Connect SSO on the Sysdig application.\nCopy the Client ID and OpenID Connect endpoints corresponding to the application that you have created.\nSelect your application from App registration.\nCopy the Application (client) ID.\nYou will need the client ID while configuring OpenID Connect SSO on the Sysdig application.\nClick Endpoints.\nCopy the OpenID Connect metadata document and open it in a browser.\nCopy the OpenID Connect URI (Issuer URI).\nFor example, https://login.microsoftonline.com/5a4b56fc-dceb-4a64-94ff-21e08e5892f5/v2.0\nConfigure Sysdig SettingsTo enable Azure OpenID functionality on the Sysdig application, you need the following:\nClient ID\nClient Secret\nIssuer URL.\nSee OpenID Connect (On-Prem) to learn how to complete your configuration.\n","url":"https://docs.sysdig.com/en/administration/onprem-openid-azure/"},{"id":445,"title":"Azure API Management","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 4 metrics.\nList of Alerts Alert Description Format [Azure API Management] API Management Service Running Out Of Capacity The API Management Service is reaching its maximum capacity. Prometheus [Azure API Management] High Overall Request Latency The Request latency is high. Prometheus [Azure API Management] High Backend Request Latency The Backend Request latency is high. Prometheus [Azure API Management] High 4XX Overall Error Rate The 4XX Overall Error rate is high. Prometheus [Azure API Management] High 5XX Overall Error Rate The 4XX Overall Error rate is high. Prometheus [Azure API Management] High 4XX Backend Error Rate The 4XX Backend Error rate is high. Prometheus [Azure API Management] High 5XX Backend Error Rate The 5XX Backend Error rate is high. Prometheus [Azure API Management] High 4XX Gateway Error Rate The 4XX Gateway Error rate is high. Prometheus [Azure API Management] High 5XX Gateway Error Rate The 5XX Gateway Error rate is high. Prometheus List of DashboardsAzure API ManagementThe dashboard provides information on the Azure API Management integration. List of Metrics Metric name azure_apimanagement_service_backend_duration_avg azure_apimanagement_service_capacity_avg azure_apimanagement_service_duration_avg azure_apimanagement_service_requests_sum Monitoring and Troubleshooting Azure FilesThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure API Management.\nStatusUse the following query to get the percentage of utilization of the API Management service:\nazure_apimanagement_service_capacity_avg LatencyUse the following query to get the overall duration of Gateway requests:\nazure_apimanagement_service_duration_avg Use the following query to get the duration of Backend requests:\nazure_apimanagement_service_backend_duration_avg RequestsSuccessful RequestsUse the following queries to get the requests with 2XX and 3XX status codes:\nazure_apimanagement_service_requests_sum{gatewayresponsecodecategory=\u0026#34;2xx\u0026#34;} azure_apimanagement_service_requests_sum{gatewayresponsecodecategory=\u0026#34;3xx\u0026#34;} A StatusCode of 0 in the backendresponsecode label indicates that the response was returned at the Gateway level, for example from the cache. This means the request has never reached the Backend.\nError RequestsUse the following queries to get the requests with 4XX and 5XX status codes:\nazure_apimanagement_service_requests_sum{gatewayresponsecodecategory=\u0026#34;4xx\u0026#34;} azure_apimanagement_service_requests_sum{gatewayresponsecodecategory=\u0026#34;5xx\u0026#34;} A StatusCode of 0 in the backendresponsecode label indicates that the error was thrown at the Gateway level, for example, a request without the authentication token in the header. This means the request has never reached the Backend.\nError RatesTotal Error RatesUse the following query to get the overall error rates for 4XX status codes:\nsum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum{gatewayresponsecodecategory=\u0026#34;4xx\u0026#34;}) / sum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum) Use the following query to get the overall error rates for 5XX status codes:\nsum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum{gatewayresponsecodecategory=\u0026#34;5xx\u0026#34;}) / sum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum) Gateway Error RatesUse the following query to get the Gateway error rates for 4XX status codes:\nsum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum{gatewayresponsecodecategory=\u0026#34;4xx\u0026#34;, backendresponsecodecategory=\u0026#34;None\u0026#34;}) / sum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum) Use the following query to get the Gateway error rates for 5XX status codes:\nsum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum{gatewayresponsecodecategory=\u0026#34;5xx\u0026#34;, backendresponsecodecategory=\u0026#34;None\u0026#34;}) / sum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum) Backend Error RatesUse the following query to get the Backend error rates for 4XX status codes:\nsum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum{backendresponsecodecategory=\u0026#34;4xx\u0026#34;}) / sum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum) Use the following query to get the Backend error rates for 5XX status codes:\nsum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum{backendresponsecodecategory=\u0026#34;5xx\u0026#34;}) / sum by(hostname,location,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_apimanagement_service_requests_sum) ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-api-management/"},{"id":446,"title":"Azure Blob Storage","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 5 metrics.\nList of DashboardsAzure Blob StorageThe dashboard provides information on the Azure Blob Storage integration. List of Metrics Metric name azure_storage_storageaccounts_blobservices_blob_capacity_avg azure_storage_storageaccounts_blobservices_blob_count_avg azure_storage_storageaccounts_blobservices_blob_provisioned_size_avg azure_storage_storageaccounts_blobservices_container_count_avg azure_storage_storageaccounts_blobservices_index_capacity_avg Monitoring and Troubleshooting Azure Blob StorageThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Blob Storage.\nThe metrics covered in this document are applicable only to Azure Blob Storage. Sysdig offers a different integration for Azure Storage Accounts.\nMost of the metrics return a value of 0 when it should be a null (not applicable) value. That\u0026rsquo;s why we recommend filtering them out with the PromQL expression metric_name \u0026gt; 0.\nBlob CapacityUse the following query to get the amount of storage used by the storage account\u0026rsquo;s Blob service in bytes.\nazure_storage_storageaccounts_blobservices_blob_capacity_avg \u0026gt; 0 Blob CountUse the following query to get the number of blob objects stored in the storage account:\nazure_storage_storageaccounts_blobservices_blob_count_avg \u0026gt; 0 Blob Provisioned SizeUse the following query to get the amount of storage provisioned in the storage account\u0026rsquo;s Blob service in bytes. This metric is applicable to premium storage accounts only:\nazure_storage_storageaccounts_blobservices_blob_provisioned_size_avg \u0026gt; 0 Container CountUse the following query to get the number of containers in the storage account:\nazure_storage_storageaccounts_blobservices_container_count_avg Index CapacityUse the following query to get the amount of storage used by Azure Data Lake Storage Gen2 hierarchical index:\nazure_storage_storageaccounts_blobservices_index_capacity_avg \u0026gt; 0 ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-blob-storage/"},{"id":447,"title":"Azure Cluster Autoscaler","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 4 metrics.\nList of Alerts Alert Description Format [Azure Cluster AutoScaler] Safe Autoscale not working Cluster Safe Autoscale not working. Prometheus [Azure Cluster AutoScaler] Unneeded nodes Unneeded nodes. Prometheus [Azure Cluster AutoScaler] Scale down is in cooldown Scale down is in cooldown. Prometheus List of DashboardsAzure Cluster AutoscalerThe dashboard provides information on the Azure Cluster Autoscaler for AKS. List of Metrics Metric name azure_containerservice_managedclusters_cluster_autoscaler_cluster_safe_to_autoscale_avg azure_containerservice_managedclusters_cluster_autoscaler_scale_down_in_cooldown_avg azure_containerservice_managedclusters_cluster_autoscaler_unneeded_nodes_count_avg azure_containerservice_managedclusters_cluster_autoscaler_unschedulable_pods_count_avg Monitoring and Troubleshooting Azure Cluster AutoscalerThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Cluster Autoscaler.\nCluster AutoscalerSafe AutoscaleUse the following query to check if the Safe Autoscaler is currently running. If it is not running, your cluster won\u0026rsquo;t be able to autoscale:\nazure_containerservice_managedclusters_cluster_autoscaler_cluster_safe_to_autoscale_avg != 1 A return value other than 1 indicates a problem.\nUnneeded NodesUse the following query to get the number of unneeded nodes in the AKS cluster. These nodes will be deleted by Cluster Autoscaler as soon as all pods are evicted:\nazure_containerservice_managedclusters_cluster_autoscaler_unneeded_nodes_count_avg Scale down cooldownUse the following query to get the state of scale down:\nazure_containerservice_managedclusters_cluster_autoscaler_scale_down_in_cooldown_avg A return value other than 0 indicates that the AKS cluster won\u0026rsquo;t be able to autoscale.\nUnschedulable podsThe Cluster Autoscaler component can watch for pods in your cluster that can\u0026rsquo;t be scheduled because of resource constraints. The following query returns the number of unschedulable pods:\nazure_containerservice_managedclusters_cluster_autoscaler_unschedulable_pods_count_avg A return value other than 0 indicates that the AKS cluster can\u0026rsquo;t schedule pods and the autoscaler will scale more nodes.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-cluster-autoscaler/"},{"id":448,"title":"Azure Container Registry","content":" Ensure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes.\nAuthentication Using Registry TokenTo run the scanner in Azure Container Registry (ACR) using a registry token, you must have a token with _repositories_admin scope map to read the full registry.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=acr \\ --set config.registryURL=\u0026lt;ACR_REGISTRY_URL\u0026gt; \\ --set config.registryUser=\u0026lt;ACR_TOKEN_NAME\u0026gt; \\ --set config.registryPassword=\u0026lt;ACR_TOKEN_PASSWORD\u0026gt; \u0026lt;ACR_REGISTRY_URL\u0026gt;: The Azure registry URL For example, testregistryscanner.azurecr.io \u0026lt;ACR_TOKEN_NAME\u0026gt;: The Azure registry token name \u0026lt;ACR_TOKEN_PASSWORD\u0026gt;: The Azure registry token password LimitationsThe registry token must use the _repositories_admin scope map. For more information, see the Azure ACR documentation.\nAuthentication by Service PrincipalTo run the scanner in Azure Container Registry (ACR) using Service Principal, follow the Azure ACR instructions to create Service Principal with acrpull role and scoped to your registry.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=acr \\ --set config.registryURL=\u0026lt;ACR_REGISTRY_URL\u0026gt; \\ --set config.registryUser=\u0026lt;SP_ID\u0026gt; \\ --set config.registryPassword=\u0026lt;SP_PASSWORD\u0026gt; \u0026lt;ACR_REGISTRY_URL\u0026gt;: The Azure registry URL. For example, testregistryscanner.azurecr.io \u0026lt;SP_ID\u0026gt;: The Azure Service Principal ID. \u0026lt;SP_PASSWORD\u0026gt;: The Azure Service Principal password. ","url":"https://docs.sysdig.com/en/sysdig-secure/azure-container-registry/"},{"id":449,"title":"Azure Files","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 7 metrics.\nList of Alerts Alert Description Format [Azure Files] Running Out of Capacity Azure Files is running out of space. Prometheus List of DashboardsAzure FilesThe dashboard provides information on the Azure Files integration. List of Metrics Metric name azure_storage_storageaccounts_fileservices_file_capacity_avg azure_storage_storageaccounts_fileservices_file_count_avg azure_storage_storageaccounts_fileservices_file_share_capacity_quota_avg azure_storage_storageaccounts_fileservices_file_share_count_avg azure_storage_storageaccounts_fileservices_file_share_provisioned_iops_avg azure_storage_storageaccounts_fileservices_file_share_snapshot_count_avg azure_storage_storageaccounts_fileservices_file_share_snapshot_size_avg Monitoring and Troubleshooting Azure FilesThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Files.\nThe metrics covered in this document are applicable only to Azure Files. Sysdig offers a different integration for Azure Storage Accounts.\nMost of the metrics return a value of 0 when it should be a null (not applicable) value. That\u0026rsquo;s why we recommend filtering them out with the PromQL expression metric_name \u0026gt; 0.\nFile CapacityUse the following query to get the amount of File storage used by the storage account:\nazure_storage_storageaccounts_fileservices_file_capacity_avg \u0026gt; 0 File CountUse the following query to get the number of files in the storage account:\nazure_storage_storageaccounts_fileservices_file_count_avg \u0026gt; 0 File Share Capacity QuotaUse the following query to get the upper limit on the amount of storage that can be used by Azure Files Service in bytes:\nazure_storage_storageaccounts_fileservices_file_share_capacity_quota_avg \u0026gt; 0 File Share CountUse the number of file shares in the storage account:\nazure_storage_storageaccounts_fileservices_file_share_count_avg File Share Snapshot CountUse the following query to get the number of snapshots present on the share in storage account\u0026rsquo;s Files Service:\nazure_storage_storageaccounts_fileservices_file_share_snapshot_count_avg \u0026gt; 0 File Share Snapshot CountUse the following query to get the amount of storage used by the snapshots in storage account\u0026rsquo;s File service in bytes:\nazure_storage_storageaccounts_fileservices_file_share_snapshot_size_avg \u0026gt; 0 ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-files/"},{"id":450,"title":"Azure Kubernetes Service","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 16 metrics.\nList of Alerts Alert Description Format [Azure Kubernetes Service] Cluster Node not ready Kubernetes Cluster Node not ready. Prometheus [Azure Kubernetes Service] Cluster node memory rss usage Kubernetes Cluster node high memory rss usage. Prometheus [Azure Kubernetes Service] Cluster node memory working set usage Kubernetes Cluster node high memory working set usage. Prometheus [Azure Kubernetes Service] Cluster node disk usage Kubernetes Cluster node high disk usage. Prometheus [Azure Kubernetes Service] Pod in failed phase Kubernetes Cluster pod is in failed phase. Prometheus List of DashboardsAzure Kubernetes ServiceThe dashboard provides information on the Azure Azure Kubernetes Service (AKS). List of Metrics Metric name azure_containerservice_managedclusters_apiserver_current_inflight_requests_avg azure_containerservice_managedclusters_kube_node_status_allocatable_cpu_cores_avg azure_containerservice_managedclusters_kube_node_status_allocatable_memory_bytes_avg azure_containerservice_managedclusters_kube_node_status_condition_avg azure_containerservice_managedclusters_kube_pod_status_phase_avg azure_containerservice_managedclusters_kube_pod_status_ready_avg azure_containerservice_managedclusters_node_cpu_usage_millicores_avg azure_containerservice_managedclusters_node_cpu_usage_percentage_avg azure_containerservice_managedclusters_node_disk_usage_bytes_avg azure_containerservice_managedclusters_node_disk_usage_percentage_avg azure_containerservice_managedclusters_node_memory_rss_bytes_avg azure_containerservice_managedclusters_node_memory_rss_percentage_avg azure_containerservice_managedclusters_node_memory_working_set_bytes_avg azure_containerservice_managedclusters_node_memory_working_set_percentage_avg azure_containerservice_managedclusters_node_network_in_bytes_avg azure_containerservice_managedclusters_node_network_out_bytes_avg Monitoring and Troubleshooting Azure Kubernetes ServiceThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Kubernetes Service.\nCluster StateNodes not readyUse the following query to check if there are nodes with NotReady state:\nazure_containerservice_managedclusters_kube_node_status_condition_avg{condition=\u0026#34;Ready\u0026#34;, status2=\u0026#34;NotReady\u0026#34;} A return value other than 0 indicates a problem in the cluster.\nCPU coresUse the following query to get the number of cores on your cluster:\nazure_containerservice_managedclusters_kube_node_status_allocatable_cpu_cores_avg Memory AvailableUse the following query to get the available memory:\nazure_containerservice_managedclusters_kube_node_status_allocatable_memory_bytes_avg A low value can indicate memory pressure, a new node should be created manually or by the autoscaler.\nCluster nodesCPU usageUse the following query to get the CPU percentage usage:\nazure_containerservice_managedclusters_node_cpu_usage_percentage_avg A return value greater than 95 indicates CPU pressure in a node.\nMemory RSSMemory RSS is the amount of anonymous and swap cache memory.\nUse the following query to get the CPU percentage usage:\nazure_containerservice_managedclusters_node_memory_rss_percentage_avg Memory working setThe memory working set includes the amount of kernel memory, dirty memory, and recently accessed memory.\nUse the following query to get the CPU percentage usage:\nazure_containerservice_managedclusters_node_memory_working_set_percentage_avg A return value greater than 95 indicates memory pressure in a node.\nDisk usageUse the following query to get the disk usage:\nazure_containerservice_managedclusters_node_disk_usage_percentage_avg A high value return indicates that a disk is running low space.\nNetwork InUse the following query to get network bandwidth in:\nazure_containerservice_managedclusters_node_network_in_bytes_avg Network OutUse the following query to get network bandwidth out:\nazure_containerservice_managedclusters_node_network_out_bytes_avg API Inflight RequestsUse the following query to get the API requests:\nazure_containerservice_managedclusters_apiserver_current_inflight_requests_avg ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-kubernetes-service/"},{"id":451,"title":"Azure Queue Storage","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 3 metrics.\nList of DashboardsAzure Queue StorageThe dashboard provides information on the Azure Queue Storage integration. List of Metrics Metric name azure_storage_storageaccounts_queueservices_queue_capacity_avg azure_storage_storageaccounts_queueservices_queue_count_avg azure_storage_storageaccounts_queueservices_queue_message_count_avg Monitoring and Troubleshooting Azure Queue StorageThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Queue Storage.\nThe metrics covered in this document are applicable only to Azure Queue Storage. Sysdig offers a different integration for Azure Storage Accounts.\nQueue CapacityUse the following query to get the amount of Queue storage used by the storage account:\nazure_storage_storageaccounts_queueservices_queue_capacity_avg Queue CountUse the following query to get the number of queues in the storage account:\nazure_storage_storageaccounts_queueservices_queue_count_avg Queue Message CountUse the following query to get the number of unexpired queue messages in the storage account:\nazure_storage_storageaccounts_queueservices_queue_message_count_avg ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-queue-storage/"},{"id":452,"title":"Azure SQL","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 23 metrics.\nList of Alerts Alert Description Format [Azure SQL] High SQL Server Process Memory The SQL Server Process Memory usage is reaching the limit. Prometheus [Azure SQL] High App Memory The App Memory usage is reaching the limit. Applies to serverless databases. Prometheus [Azure SQL] High Amount of Sessions The number of sessions is reaching the limit. Prometheus [Azure SQL] High Amount of Workers The number of workers is reaching the limit. Prometheus [Azure SQL] Disk Full in 48h The disk will be full in 48h. Not applicable to data warehouses or hyperscale databases. Prometheus [Azure SQL] Disk Full in 12h The disk will be full in 12h. Not applicable to data warehouses or hyperscale databases. Prometheus [Azure SQL] High Connection Error Rate The Connection Error rate is high. Prometheus [Azure SQL] Database Deadlocks Database Deadlocks detected. Not applicable to data warehouses. Prometheus [Azure SQL] Blocked by Firewall Blocked by firewall detected Prometheus List of DashboardsAzure SQLThe dashboard provides information on the Azure SQL integration. List of Metrics Metric name azure_sql_servers_databases_allocated_data_storage_avg azure_sql_servers_databases_app_cpu_billed_sum azure_sql_servers_databases_app_cpu_percent_avg azure_sql_servers_databases_app_memory_percent_avg azure_sql_servers_databases_blocked_by_firewall_count azure_sql_servers_databases_connection_failed_user_error_count azure_sql_servers_databases_connection_successful_count azure_sql_servers_databases_cpu_limit_avg azure_sql_servers_databases_cpu_percent_avg azure_sql_servers_databases_cpu_used_avg azure_sql_servers_databases_deadlock_count azure_sql_servers_databases_log_write_percent_avg azure_sql_servers_databases_physical_data_read_percent_avg azure_sql_servers_databases_sessions_count_avg azure_sql_servers_databases_sessions_percent_avg azure_sql_servers_databases_sqlserver_process_core_percent_avg azure_sql_servers_databases_sqlserver_process_memory_percent_avg azure_sql_servers_databases_storage_avg azure_sql_servers_databases_storage_percent_avg azure_sql_servers_databases_tempdb_data_size_avg azure_sql_servers_databases_tempdb_log_size_avg azure_sql_servers_databases_workers_percent_avg azure_sql_servers_databases_xtp_storage_percent_avg Monitoring and Troubleshooting Azure SQLThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure SQL.\nDatabase CPU, Memory and StorageCPUUse the following query to get the percentage of CPU used by the database:\nazure_sql_servers_databases_cpu_percent_avg For vCore-based databases, there are also metrics for CPU cores used and limit:\nazure_sql_servers_databases_cpu_used_avg azure_sql_servers_databases_cpu_limit_avg StorageUse the following query to get the allocated data storage. This query is not applicable to data warehouses:\nazure_sql_servers_databases_cpu_percent_avg Use the following query to get the data space used (not applicable to data warehouses):\nazure_sql_servers_databases_storage_avg Use the following query to get the percentage of data space used. This query is not applicable to data warehouses or hyperscale databases:\nazure_sql_servers_databases_storage_percent_avg Serverless DatabasesUse the following query to get the app CPU billed:\nazure_sql_servers_databases_app_cpu_billed_sum Use the following query to get the app CPU percentage:\nazure_sql_servers_databases_app_cpu_percent_avg Use the following query to get the app memory percentage:\nazure_sql_servers_databases_app_memory_percent_avg IO, tempdb and In-Memory OLTPIOUse the following query to get the percentage of write IO:\nazure_sql_servers_databases_log_write_percent_avg Use the following query to get the percentage of read IO:\nazure_sql_servers_databases_physical_data_read_percent_avg TempdbUse the following query to get the space used in tempdb data files in kilobytes. This query is not applicable to data warehouses:\nazure_sql_servers_databases_tempdb_data_size_avg Use the following query to get the space used in tempdb transaction log file in kilobytes. This query is not applicable to data warehouses:\nazure_sql_servers_databases_tempdb_log_size_avg In-Memory OLTPUse the following query to get the In-Memory OLTP storage percent (not applicable to data warehouses):\nazure_sql_servers_databases_xtp_storage_percent_avg SQL ServerResourcesUse the following query to get the CPU usage as a percentage of the SQL DB process. This query is not applicable to data warehouses:\nazure_sql_servers_databases_sqlserver_process_core_percent_avg Use the following query to get the Memory usage as a percentage of the SQL DB process. This query is not applicable to data warehouses:\nazure_sql_servers_databases_sqlserver_process_memory_percent_avg WorkersUse the following query to get the workers percentage. This query is not applicable to data warehouses:\nazure_sql_servers_databases_workers_percent_avg NetworkSessionsUse the following query to get the sessions percentage:\nazure_sql_servers_databases_sessions_percent_avg Use the following query to get the number of active sessions. This query is not applicable to Synapse DW analytics:\nazure_sql_servers_databases_sessions_count_avg ConnectionsUse the following query to get the successful connections:\nazure_sql_servers_databases_connection_successful_count Use the following query to get the failed connections:\nazure_sql_servers_databases_connection_failed_user_error_count To calculate the connection error rate percentage, use this expression:\nazure_sql_servers_databases_connection_failed_user_error_count / on (cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id) ( azure_sql_servers_databases_connection_failed_user_error_count + on (cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id) azure_sql_servers_databases_connection_successful_count ) * 100 Deadlocks and Blocked by FirewallUse the following query to get the database deadlocks:\nazure_sql_servers_databases_deadlock_count Use the following query to get the blocked by firewall count:\nazure_sql_servers_databases_blocked_by_firewall_count ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-sql/"},{"id":453,"title":"Azure Storage Accounts","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 7 metrics.\nList of Alerts Alert Description Format [Azure Storage Accounts] No Availability The percentage of availability for the storage service or the specified API operation. All unexpected errors result in reduced availability for the storage service or the specified API operation. Prometheus [Azure Storage Accounts] High Authentication Errors Rate Azure Storage Account Authentication Errors rate is high. Prometheus [Azure Storage Accounts] High Other Client Errors Rate Azure Storage Account Other Client Errors rate is high. Prometheus [Azure Storage Accounts] High Success E2E Latency The average end-to-end latency of successful requests made to a storage service or the specified API operation is high. This value includes the required processing time within Azure Storage to read the request, send the response, and receive acknowledgment of the response. Prometheus [Azure Storage Accounts] High Success Server Latency The average time used to process a successful request by Azure Storage is high. This value does not include the network latency specified in SuccessE2ELatency. Prometheus List of DashboardsAzure Storage AccountsThe dashboard provides information on the Azure Storage Accounts integration. List of Metrics Metric name azure_storage_storageaccounts_availability_avg azure_storage_storageaccounts_egress azure_storage_storageaccounts_ingress azure_storage_storageaccounts_success_e2e_latency_avg azure_storage_storageaccounts_success_server_latency_avg azure_storage_storageaccounts_transactions_sum azure_storage_storageaccounts_used_capacity_avg Monitoring and Troubleshooting Azure Storage AccountsThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Storage Accounts.\nThe metrics covered in this document are general to Azure Storage Accounts. Sysdig offers different integrations for Azure Blob Storage, Azure Files, Azure Queue Storage and Azure Table Storage.\nStatusAvailabilityUse the following query to get the availability of the storage account:\nazure_storage_storageaccounts_availability_avg Used CapacityUse the following query to get the amount of storage used by the storage account. For standard storage accounts, it\u0026rsquo;s the sum of capacity used by blob, table, file, and queue. For premium storage accounts and Blob storage accounts, it is the same as BlobCapacity or FileCapacity:\nazure_storage_storageaccounts_used_capacity_avg TransactionsSuccessful TransactionsUse the following query to get the number of successful requests made to a storage account:\nazure_storage_storageaccounts_transactions_sum{responsetype=\u0026#34;Success\u0026#34;} Authentication ErrorsUse the following query to get the number of requests made to a storage account with authentication errors:\nazure_storage_storageaccounts_transactions_sum{responsetype=\u0026#34;AuthenticationError\u0026#34;} Use the following expression to calculate the error rate:\nsum by (transactiontype,authentication,apiname,geotype,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_storage_storageaccounts_transactions_sum{responsetype=\u0026#34;AuthenticationError\u0026#34;}) / sum by (transactiontype,authentication,apiname,geotype,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_storage_storageaccounts_transactions_sum) Other Client ErrorsUse the following query to get the number of requests made to a storage account with other client errors:\nazure_storage_storageaccounts_transactions_sum{responsetype=\u0026#34;ClientOtherError\u0026#34;} Use the following expression to calculate the error rate:\nsum by (transactiontype,authentication,apiname,geotype,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_storage_storageaccounts_transactions_sum{responsetype=\u0026#34;ClientOtherError\u0026#34;}) / sum by (transactiontype,authentication,apiname,geotype,cloud_provider_resource_name,resource_group,cloud_provider_region_name,cloud_provider_account_id)(azure_storage_storageaccounts_transactions_sum) NetworkIngressUse the following query to get the amount of ingress data, in bytes. This number includes ingress from an external client into Azure Storage as well as ingress within Azure:\nsum_over_time(azure_storage_storageaccounts_ingress[$__interval]) EgressUse the following query to get the amount of egress data. This number includes egress to external client from Azure Storage as well as egress within Azure. As a result, this number does not reflect billable egress:\nsum_over_time(azure_storage_storageaccounts_egress[$__interval]) Success E2E LatencyUse the following query to get the average end-to-end latency of successful requests made to a storage account, in milliseconds. This value includes the required processing time within Azure Storage to read the request, send the response, and receive acknowledgment of the response:\nazure_storage_storageaccounts_success_e2e_latency_avg Success Server LatencyUse the following query to get the average time used to process a successful request by Azure Storage, in milliseconds. This value does not include the network latency specified in SuccessE2ELatency:\nazure_storage_storageaccounts_success_server_latency_avg ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-storage-accounts/"},{"id":454,"title":"Azure Synapse Analytics","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 9 metrics.\nList of Alerts Alert Description Format [Azure Synapse Analytics] High Login Error Rate Too many unsuccessful login attempts to the built-in SQL. Prometheus [Azure Synapse Analytics] Requests Ended High Error Rate Too many failed SQL requests. Prometheus [Azure Synapse Analytics] Activities Ended High Error Rate Too many activities returned failed results. Prometheus [Azure Synapse Analytics] Failed Link Table High Error Rate Too many failed link table events. Prometheus List of DashboardsAzure Synapse AnalyticsThe dashboard provides information on the Azure Synapse Analytics integration. List of Metrics Metric name azure_synapse_workspaces_builtin_sql_pool_data_processed_bytes_sum azure_synapse_workspaces_builtin_sql_pool_login_attempts azure_synapse_workspaces_builtin_sql_pool_requests_ended azure_synapse_workspaces_integration_activity_runs_ended_count azure_synapse_workspaces_integration_link_connection_events_sum azure_synapse_workspaces_integration_link_processed_changed_rows_sum azure_synapse_workspaces_integration_link_processed_data_volume_sum azure_synapse_workspaces_integration_link_processing_latency_in_seconds_avg azure_synapse_workspaces_integration_link_table_events_sum Monitoring and Troubleshooting Azure Synapse AnalyticsThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Synapse Analytics.\nBuilt-in SQL PoolLogin attemptsUse the following query to check the number of unsuccessful login attempts in the SQL built-in pool in the last 10 minutes:\nsum (sum_over_time(azure_synapse_workspaces_builtin_sql_pool_login_attempts{result=\u0026#34;Failed\u0026#34;}[10m])) by (cloud_provider_account_id,cloud_provider_region_name,resource_group,cloud_provider_resource_name,result) A return value other than 0 indicates that some service is trying to access to SQL with incorrect credentials.\nData processedUse the following query to get the number of bytes processed by SQL built-in pool:\nazure_synapse_workspaces_builtin_sql_pool_data_processed_bytes_sum Requests ended with errorUse the following query to check the number of error requests in the SQL built-in pool:\nsum (sum_over_time(azure_synapse_workspaces_builtin_sql_pool_requests_ended{result=\u0026#34;Failed\u0026#34;}[10m])) by (cloud_provider_account_id,cloud_provider_region_name,resource_group,cloud_provider_resource_name,result) Synapse activitiesActivities runs endedUse the following query to get the number of activities in failed result:\nazure_synapse_workspaces_integration_activity_runs_ended_count{result=\u0026#34;Failed\u0026#34;} Synapse LinkLink table eventsUse the following query to get the number of link table events:\nsum(azure_synapse_workspaces_integration_link_table_events_sum) by (cloud_provider_region_name, resource_group, cloud_provider_resource_name, linkconnectionname, eventtype, tablename) Link connection eventsUse the following query to get the number of link connection events:\nsum(azure_synapse_workspaces_integration_link_connection_events_sum) by (cloud_provider_region_name, resource_group, cloud_provider_resource_name, linkconnectionname, eventtype) Link processed data volumeUse the following query to get the link bytes processed:\nazure_synapse_workspaces_integration_link_processed_data_volume_sum Link changed rowsUse the following query to get the number of rows changed:\nazure_synapse_workspaces_integration_link_processed_changed_rows_sum Link latencyUse the following query to get the link latency in seconds:\nazure_synapse_workspaces_integration_link_processing_latency_in_seconds_avg ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-synapse-analytics/"},{"id":455,"title":"Azure Table Storage","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 3 metrics.\nList of DashboardsAzure Table StorageThe dashboard provides information on the Azure Table Storage integration. List of Metrics Metric name azure_storage_storageaccounts_tableservices_table_capacity_avg azure_storage_storageaccounts_tableservices_table_count_avg azure_storage_storageaccounts_tableservices_table_entity_count_avg Monitoring and Troubleshooting Azure Table StorageThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Table Storage.\nThe metrics covered in this document are applicable only to Azure Table Storage. Sysdig offers a different integration for Azure Storage Accounts.\nTable CapacityUse the following query to get the amount of Table storage used by the storage account:\nazure_storage_storageaccounts_tableservices_table_capacity_avg Table CountUse the following query to get the number of tables in the storage account:\nazure_storage_storageaccounts_tableservices_table_count_avg Table Entity CountUse the following query to get the number of table entities in the storage account:\nazure_storage_storageaccounts_tableservices_table_entity_count_avg ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-table-storage/"},{"id":456,"title":"Azure Virtual Machine Scale Sets","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 24 metrics.\nList of Alerts Alert Description Format [Azure Virtual Machine Scale Sets] VM Not Available VM Not Available. Prometheus [Azure Virtual Machine Scale Sets] CPU Usage is High The CPU usage of the VM is high. Prometheus [Azure Virtual Machine Scale Sets] Low Available Memory The Available Memory of the VM is low. Prometheus [Azure Virtual Machine Scale Sets] OS Disk Queue Is High The OS Disk queue depth is high. It doesn\u0026rsquo;t include Data Disks. Prometheus [Azure Virtual Machine Scale Sets] Data Disk Queue Is High The Data Disk queue depth is high. It doesn\u0026rsquo;t include OS Disks. Prometheus [Azure Virtual Machine Scale Sets] Premium OS Disk Read Cache Miss Is High The Premium OS Disk read cache miss is high. It doesn\u0026rsquo;t include Premium Data Disks. Prometheus [Azure Virtual Machine Scale Sets] Premium Data Disk Read Cache Miss Is High The Premium Data Disk read cache miss is high. It doesn\u0026rsquo;t include Premium OS Disks. Prometheus [Azure Virtual Machine Scale Sets] VM Cached IOPS Consumed Are High The VM cached IOPS consumed are high. Prometheus [Azure Virtual Machine Scale Sets] VM Uncached IOPS Consumed Are High The VM uncached IOPS consumed are high. Prometheus [Azure Virtual Machine Scale Sets] Low CPU Credits Remaining There are not many CPU credits remaining. Only available on B-series burstable VMs. Prometheus [Azure Virtual Machine Scale Sets] High OS Disk Used Burst Bandwidth Credits The percentage of OS Disk used burst bandwidth (bytes per second) credits is near 100%. It doesn\u0026rsquo;t include Data Disks or non-burstable OS Disks. Prometheus [Azure Virtual Machine Scale Sets] High OS Disk Used Burst IO Credits The percentage of OS Disk used burst IO credits is near 100%. It doesn\u0026rsquo;t include Data Disks or non-burstable OS Disks. Prometheus [Azure Virtual Machine Scale Sets] High Data Disk Used Burst Bandwidth Credits The percentage of Data Disk used burst bandwidth (bytes per second) credits is near 100%. It doesn\u0026rsquo;t include OS Disks or non-burstable Data Disks. Prometheus [Azure Virtual Machine Scale Sets] High Data Disk Used Burst IO Credits The percentage of Data Disk used burst IO credits is near 100%. It doesn\u0026rsquo;t include OS Disks or non-burstable Data Disks. Prometheus List of DashboardsAzure Virtual Machine Scale SetsThe dashboard provides information on the Azure Virtual Machine Scale Sets integration. List of Metrics Metric name azure_compute_virtualmachinescalesets_available_memory_bytes azure_compute_virtualmachinescalesets_cpu_credits_remaining azure_compute_virtualmachinescalesets_data_disk_queue_depth azure_compute_virtualmachinescalesets_data_disk_read_bytes_sec azure_compute_virtualmachinescalesets_data_disk_read_operations_sec azure_compute_virtualmachinescalesets_data_disk_used_burst_bps_credits_percentage azure_compute_virtualmachinescalesets_data_disk_used_burst_io_credits_percentage azure_compute_virtualmachinescalesets_data_disk_write_bytes_sec azure_compute_virtualmachinescalesets_data_disk_write_operations_sec azure_compute_virtualmachinescalesets_network_in_total azure_compute_virtualmachinescalesets_network_out_total azure_compute_virtualmachinescalesets_os_disk_queue_depth azure_compute_virtualmachinescalesets_os_disk_read_bytes_sec azure_compute_virtualmachinescalesets_os_disk_read_operations_sec azure_compute_virtualmachinescalesets_os_disk_used_burst_bps_credits_percentage azure_compute_virtualmachinescalesets_os_disk_used_burst_io_credits_percentage azure_compute_virtualmachinescalesets_os_disk_write_bytes_sec azure_compute_virtualmachinescalesets_os_disk_write_operations_sec azure_compute_virtualmachinescalesets_percentage_cpu azure_compute_virtualmachinescalesets_premium_data_disk_cache_read_miss azure_compute_virtualmachinescalesets_premium_os_disk_cache_read_miss azure_compute_virtualmachinescalesets_vm_availability_metric_avg azure_compute_virtualmachinescalesets_vm_cached_iops_consumed_percentage azure_compute_virtualmachinescalesets_vm_uncached_iops_consumed_percentage Monitoring and Troubleshooting Azure Virtual Machine Scale SetsThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Virtual Machine Scale Sets.\nThe metrics covered in this document are applicable only to Azure Virtual Machine Scale Sets. Sysdig offers a different integration for Azure Virtual Machines.\nResourcesVM Status and ResourcesUse the following query to check if the VMs are available. This metric is currently available to only a small set of users.\nazure_compute_virtualmachinescalesets_vm_availability_metric_avg != 1 A return value other than 1 indicates a problem.\nPercentage CPU UsedUse the following query to get the percentage of CPU used by the VMs:\nazure_compute_virtualmachinescalesets_percentage_cpu Available MemoryUse the following query to get the available memory of the VMs (in bytes):\nazure_compute_virtualmachinescalesets_available_memory_bytes Unfortunately, no metric is available for used memory or maximum memory. Therefore, you cannot calculate the percentage of available memory.\nHaving 100MB left in a VM with 500MB max and having 100MB left in a VM with 2000MB max are totally different memory calculations.\nNetworkNetwork Bytes InThe following query returns the number of bytes received on all the network interfaces by the Virtual Machine (the incoming traffic):\nsum_over_time(azure_compute_virtualmachinescalesets_network_in_total[$__interval]) Network Bytes OutThe following query returns the number of bytes out on all the network interfaces by the Virtual Machine (the outgoing traffic):\nsum_over_time(azure_compute_virtualmachinescalesets_network_out_total[$__interval]) DisksThe Virtual Machines have an \u0026lsquo;OS\u0026rsquo; disk, but they can also have attached Data Disks. The Data Disks have a Logical Unit Number (LUN) which specifies the slot in which the data drive appears when mounted. The valid LUN values are 0 through 15. The \u0026rsquo;lun\u0026rsquo; label available in the data disk metrics is useful to differentiate which metric comes from which data disk.\nOS Disk Byte RateUse the following query to get the amount of read and write bytes per second in the OS disk:\nazure_compute_virtualmachinescalesets_os_disk_read_bytes_sec azure_compute_virtualmachinescalesets_os_disk_write_bytes_sec OS Disk IOPSUse the following query to get the amount of read and write bytes per second for IOPS:\nazure_compute_virtualmachinescalesets_os_disk_read_operations_sec azure_compute_virtualmachinescalesets_os_disk_write_operations_sec OS Disk QueueUse the following query to get the amount of read and write bytes per second for queue depth:\nazure_compute_virtualmachinescalesets_os_disk_queue_depth Data Disk Byte RateIn a similar fashion, use the following query to get the read and write bytes per second in the data disk:\nazure_compute_virtualmachinescalesets_data_disk_read_bytes_sec azure_compute_virtualmachinescalesets_data_disk_write_bytes_sec Data Disk IOPSse the following query to get the read and write bytes per second in the data disk for IOPS:\nazure_compute_virtualmachinescalesets_data_disk_read_operations_sec azure_compute_virtualmachinescalesets_data_disk_write_operations_sec Data Disk Queuese the following query to get the read and write bytes per second for queue depth:\nazure_compute_virtualmachinescalesets_data_disk_queue_depth Premium Disks CachePremium disks (both OS and data disks) have metrics for their read cache miss and hit, which return a percentage between 0 and 100. Ideally the hit percentage should be 100%, and the miss percentage should be 0%.\nUse the following query to get the values in OS disk:\nazure_compute_virtualmachinescalesets_premium_os_disk_cache_read_miss azure_compute_virtualmachinescalesets_premium_os_disk_cache_read_hit Use the following to get the values in the data disks:\nazure_compute_virtualmachinescalesets_premium_data_disk_cache_read_miss azure_compute_virtualmachinescalesets_premium_data_disk_cache_read_hit VM Cached and Uncached IOPS ConsumedUse the following query to get the cached and uncached VM IOPS consumed:\nazure_compute_virtualmachinescalesets_vm_cached_iops_consumed_percentage azure_compute_virtualmachinescalesets_vm_uncached_iops_consumed_percentage A value near 100% indicates a bottleneck. This occurs when the VM machine IOPS reaches its limit. In that case, the bottleneck issue can be fixed by increasing the size of the VM. Before fixing it you should check the IOPS of the attached disks. If their IOPS are also at 100%, the bottleneck is in the disks.\nCreditsCPU CreditsThe following metric, only available on B-series burstable VMs, returns the remaining CPU credits available to burst:\nazure_compute_virtualmachinescalesets_cpu_credits_remaining Disk CreditsOS Disk Used Burst Bandwidth and IO CreditsUse the following query to get the percentage of used burst bps (bytes per second) credits for the OS disk:\nazure_compute_virtualmachinescalesets_os_disk_used_burst_bps_credits_percentage Use the following query to get the percentage of used burst IO credits for the OS disk:\nazure_compute_virtualmachinescalesets_os_disk_used_burst_io_credits_percentage Data Disk Used Burst Bandwidth and IO CreditsUse the following query to get the percentage of used burst bps (bytes per second) credits for the data disks:\nazure_compute_virtualmachinescalesets_data_disk_used_burst_bps_credits_percentage Use the following query to get the percentage of used burst IO credits in the data disks:\nazure_compute_virtualmachinescalesets_data_disk_used_burst_io_credits_percentage ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-virtual-machine-scale-sets/"},{"id":457,"title":"Azure Virtual Machines","content":" This integration can be enabled via the Connect an Azure Account page.\nThis integration has 24 metrics.\nList of Alerts Alert Description Format [Azure Virtual Machines] VM Not Available VM Not Available. Prometheus [Azure Virtual Machines] CPU Usage is High The CPU usage of the VM is high. Prometheus [Azure Virtual Machines] Low Available Memory The Available Memory of the VM is low. Prometheus [Azure Virtual Machines] OS Disk Queue Is High The OS Disk queue depth is high. It doesn\u0026rsquo;t include Data Disks. Prometheus [Azure Virtual Machines] Data Disk Queue Is High The Data Disk queue depth is high. It doesn\u0026rsquo;t include OS Disks. Prometheus [Azure Virtual Machines] Premium OS Disk Read Cache Miss Is High The Premium OS Disk read cache miss is high. It doesn\u0026rsquo;t include Premium Data Disks. Prometheus [Azure Virtual Machines] Premium Data Disk Read Cache Miss Is High The Premium Data Disk read cache miss is high. It doesn\u0026rsquo;t include Premium OS Disks. Prometheus [Azure Virtual Machines] VM Cached IOPS Consumed Are High The VM cached IOPS consumed are high. Prometheus [Azure Virtual Machines] VM Uncached IOPS Consumed Are High The VM uncached IOPS consumed are high. Prometheus [Azure Virtual Machines] Low CPU Credits Remaining There are not many CPU credits remaining. Only available on B-series burstable VMs. Prometheus [Azure Virtual Machines] High OS Disk Used Burst Bandwidth Credits The percentage of OS Disk used burst bandwidth (bytes per second) credits is near 100%. It doesn\u0026rsquo;t include Data Disks or non-burstable OS Disks. Prometheus [Azure Virtual Machines] High OS Disk Used Burst IO Credits The percentage of OS Disk used burst IO credits is near 100%. It doesn\u0026rsquo;t include Data Disks or non-burstable OS Disks. Prometheus [Azure Virtual Machines] High Data Disk Used Burst Bandwidth Credits The percentage of Data Disk used burst bandwidth (bytes per second) credits is near 100%. It doesn\u0026rsquo;t include OS Disks or non-burstable Data Disks. Prometheus [Azure Virtual Machines] High Data Disk Used Burst IO Credits The percentage of Data Disk used burst IO credits is near 100%. It doesn\u0026rsquo;t include OS Disks or non-burstable Data Disks. Prometheus List of DashboardsAzure Virtual MachinesThe dashboard provides information on the Azure Virtual Machines integration. List of Metrics Metric name azure_compute_virtualmachines_available_memory_bytes azure_compute_virtualmachines_cpu_credits_remaining azure_compute_virtualmachines_data_disk_queue_depth azure_compute_virtualmachines_data_disk_read_bytes_sec azure_compute_virtualmachines_data_disk_read_operations_sec azure_compute_virtualmachines_data_disk_used_burst_bps_credits_percentage azure_compute_virtualmachines_data_disk_used_burst_io_credits_percentage azure_compute_virtualmachines_data_disk_write_bytes_sec azure_compute_virtualmachines_data_disk_write_operations_sec azure_compute_virtualmachines_network_in_total azure_compute_virtualmachines_network_out_total azure_compute_virtualmachines_os_disk_queue_depth azure_compute_virtualmachines_os_disk_read_bytes_sec azure_compute_virtualmachines_os_disk_read_operations_sec azure_compute_virtualmachines_os_disk_used_burst_bps_credits_percentage azure_compute_virtualmachines_os_disk_used_burst_io_credits_percentage azure_compute_virtualmachines_os_disk_write_bytes_sec azure_compute_virtualmachines_os_disk_write_operations_sec azure_compute_virtualmachines_percentage_cpu azure_compute_virtualmachines_premium_data_disk_cache_read_miss azure_compute_virtualmachines_premium_os_disk_cache_read_miss azure_compute_virtualmachines_vm_availability_metric_avg azure_compute_virtualmachines_vm_cached_iops_consumed_percentage azure_compute_virtualmachines_vm_uncached_iops_consumed_percentage Monitoring and Troubleshooting Azure Virtual MachinesThis document describes important metrics and queries that you can use to monitor and troubleshoot Azure Virtual Machines.\nThe metrics covered in this document are applicable only to Azure Virtual Machines. Sysdig offers a different integration for Azure Virtual Machine Scale Sets.\nResourcesVM Status and ResourcesUse the following query to check if the VMs are available. This metric is currently available to only a small set of users.\nazure_compute_virtualmachines_vm_availability_metric_avg != 1 A return value other than 1 indicates a problem.\nPercentage CPU UsedUse the following query to get the percentage of CPU used by the VMs:\nazure_compute_virtualmachines_percentage_cpu Available MemoryUse the following query to get the available memory of the VMs (in bytes):\nazure_compute_virtualmachines_available_memory_bytes Unfortunately, no metric is available for used memory or maximum memory. Therefore, you cannot calculate the percentage of available memory.\nHaving 100MB left in a VM with 500MB max and having 100MB left in a VM with 2000MB max are totally different memory calculations.\nNetworkNetwork Bytes InThe following query returns the number of bytes received on all the network interfaces by the Virtual Machine (the incoming traffic):\nazure_compute_virtualmachines_network_in_total Network Bytes OutThe following query returns the number of bytes out on all the network interfaces by the Virtual Machine (the outgoing traffic):\nazure_compute_virtualmachines_network_out_total DisksThe Virtual Machines have an \u0026lsquo;OS\u0026rsquo; disk, but they can also have attached Data Disks. The Data Disks have a Logical Unit Number (LUN) which specifies the slot in which the data drive appears when mounted. The valid LUN values are 0 through 15. The \u0026rsquo;lun\u0026rsquo; label available in the data disk metrics is useful to differentiate which metric comes from which data disk.\nOS Disk Byte RateUse the following query to get the amount of read and write bytes per second in the OS disk:\nazure_compute_virtualmachines_os_disk_read_bytes_sec azure_compute_virtualmachines_os_disk_write_bytes_sec OS Disk IOPSUse the following query to get the amount of read and write bytes per second for IOPS:\nazure_compute_virtualmachines_os_disk_read_operations_sec azure_compute_virtualmachines_os_disk_write_operations_sec OS Disk QueueUse the following query to get the amount of read and write bytes per second for queue depth:\nazure_compute_virtualmachines_os_disk_queue_depth Data Disk Byte RateIn a similar fashion, use the following query to get the read and write bytes per second in the data disk:\nazure_compute_virtualmachines_data_disk_read_bytes_sec azure_compute_virtualmachines_data_disk_write_bytes_sec Data Disk IOPSse the following query to get the read and write bytes per second in the data disk for IOPS:\nazure_compute_virtualmachines_data_disk_read_operations_sec azure_compute_virtualmachines_data_disk_write_operations_sec Data Disk Queuese the following query to get the read and write bytes per second for queue depth:\nazure_compute_virtualmachines_data_disk_queue_depth Premium Disks CachePremium disks (both OS and data disks) have metrics for their read cache miss and hit, which return a percentage between 0 and 100. Ideally the hit percentage should be 100%, and the miss percentage should be 0%.\nUse the following query to get the values in OS disk:\nazure_compute_virtualmachines_premium_os_disk_cache_read_miss azure_compute_virtualmachines_premium_os_disk_cache_read_hit Use the following to get the values in the data disks:\nazure_compute_virtualmachines_premium_data_disk_cache_read_miss azure_compute_virtualmachines_premium_data_disk_cache_read_hit VM Cached and Uncached IOPS ConsumedUse the following query to get the cached and uncached VM IOPS consumed:\nazure_compute_virtualmachines_vm_cached_iops_consumed_percentage azure_compute_virtualmachines_vm_uncached_iops_consumed_percentage A value near 100% indicates a bottleneck. This occurs when the VM machine IOPS reaches its limit. In that case, the bottleneck issue can be fixed by increasing the size of the VM. Before fixing it you should check the IOPS of the attached disks. If their IOPS are also at 100%, the bottleneck is in the disks.\nCreditsCPU CreditsThe following metric, only available on B-series burstable VMs, returns the remaining CPU credits available to burst:\nazure_compute_virtualmachines_cpu_credits_remaining Disk CreditsOS Disk Used Burst Bandwidth and IO CreditsUse the following query to get the percentage of used burst bps (bytes per second) credits for the OS disk:\nazure_compute_virtualmachines_os_disk_used_burst_bps_credits_percentage Use the following query to get the percentage of used burst IO credits for the OS disk:\nazure_compute_virtualmachines_os_disk_used_burst_io_credits_percentage Data Disk Used Burst Bandwidth and IO CreditsUse the following query to get the percentage of used burst bps (bytes per second) credits for the data disks:\nazure_compute_virtualmachines_data_disk_used_burst_bps_credits_percentage Use the following query to get the percentage of used burst IO credits in the data disks:\nazure_compute_virtualmachines_data_disk_used_burst_io_credits_percentage ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/azure-virtual-machines/"},{"id":458,"title":"Calico","content":" This integration is disabled by default. Please refer to Enable and Disable Integrations to enable it in your account.\nVersions supported: 3.23.3\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 22 metrics.\nTimeseries generated: 838 Timeseries\nList of Alerts Alert Description Format [Calico-Node] Dataplane Updates Are Failing and Retrying The update actions for dataplane are failing and retrying several times Prometheus [Calico-Node] IP Set Command Failures Encountered a number of ipset command failures Prometheus [Calico-Node] IP Tables Restore Failures Encountered a number of iptable restore failures Prometheus [Calico-Node] IP Tables Save Failures Encountered a number of iptable restore failures Prometheus [Calico-Node] Errors While Logging Encountered a number of errors while logging Prometheus [Calico-Node] Latency Increase in Datastore OnUpdate Call The duration of datastore OnUpdate calls are increasing Prometheus [Calico-Node] Latency Increase in Dataplane Update Increased response time for dataplane updates Prometheus [Calico-Node] Latency Increase in Acquire Iptables Lock Increased response time for dataplane updates Prometheus [Calico-Node] Latency Increase While Listing All the Interfaces during a Resync Increased response time for interface listing during a resync Prometheus [Calico-Node] Latency Increase in Interface Resync Increased response time for interface resync Prometheus [Calico-Node] Fork/Exec Child Processes Results in High Latency Increased response time for Fork/Exec child processes Prometheus List of DashboardsCalicoThe dashboard provides information on the Calico integration. List of Metrics Metric name felix_calc_graph_update_time_seconds felix_cluster_num_hosts felix_cluster_num_policies felix_cluster_num_profiles felix_exec_time_micros felix_int_dataplane_addr_msg_batch_size felix_int_dataplane_apply_time_seconds felix_int_dataplane_failures felix_int_dataplane_iface_msg_batch_size felix_int_dataplane_msg_batch_size felix_ipset_calls felix_ipset_errors felix_ipset_lines_executed felix_iptables_lines_executed felix_iptables_lock_acquire_secs felix_iptables_restore_calls felix_iptables_restore_errors felix_iptables_save_calls felix_iptables_save_errors felix_log_errors felix_route_table_list_seconds felix_route_table_per_iface_sync_seconds PrerequisitesVerify Calico-Node PodsOnce you configure calico on your cluster, you should see the calico-node pods deployed in your nodes. The calico-node daemonset deploys one pod per node. If deployment takes too long, verify your nodes\u0026rsquo; labels. Describe your nodes and check if the projectcalico.org/ds-ready=true label exists. If this label is missing, add it to your nodes using the following command:\nkubectl label nodes \u0026lt;node-name\u0026gt; projectcalico.org/ds-ready=true Enable Calico Prometheus MetricsCalico can expose Prometheus metrics natively, however, this is an option that is not always enabled.\nYou can use the following command to turn Prometheus metrics on:\nkubectl patch felixconfiguration default --type merge --patch \u0026#39;{\u0026#34;spec\u0026#34;:{\u0026#34;prometheusMetricsEnabled\u0026#34;: true}}\u0026#39; You should see and output like below:\nfelixconfiguration.projectcalico.org/default patched InstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting CalicoHere are some interesting metrics and queries to monitor and troubleshoot Calico.\nAbout the Calico UserHostsA host endpoint resource (HostEndpoint) represents one or more real or virtual interfaces attached to a host that is running Calico. It enforces Calico policy on the traffic that is entering or leaving the host’s default network namespace through those interfaces.\nA host endpoint with interfaceName: * represents all of a host’s real or virtual interfaces.\nA host endpoint for one specific real interface is configured by interfaceName: , for example interfaceName: eth0, or by leaving interfaceName empty and including one of the interface’s IPs in expectedIPs.\nEach host endpoint may include a set of labels and list of profiles that Calico will use to apply policy to the interface.\nProfilesProfiles provide a way to group multiple endpoints so that they inherit a shared set of labels. For historic reasons, Profiles can also include policy rules, but that feature is deprecated in favor of the much more flexible NetworkPolicy and GlobalNetworkPolicy resources.\nEach Calico endpoint or host endpoint can be assigned to zero or more profiles.\nPoliciesIf you are new to Kubernetes, start with “Kubernetes policy” and learn the basics of enforcing policy for pod traffic. The good news is, Kubernetes and Calico policies are very similar and work alongside each other – so managing both types is easy.\nKubernetes network policy lets developers secure access to and from their applications using the same simple language they use to deploy them. Developers can focus on their applications without understanding low-level networking concepts. Enabling developers to easily secure their applications using network policies supports a shift left DevOps environment.\nErrorsDataplane Updates Failures and RetriesDataplane is base of work for Calico. It has three different types of Dataplanes (Linux eBPF, Standard Linux and Windows HNS). Dataplane is responsible for main important parts in Calico: base networking, network policy and IP address management capabilities. So be aware of possible errors in dataplane is keystone for Calico monitoring.\nrate(felix_int_dataplane_failures[5m]) Ipset Command FailuresIP sets are stored collections of IP addresses, network ranges, MAC addresses, port numbers, and network interface names. The iptables tool can leverage IP sets for more efficient rule matching.\nFor example, let’s say you want to drop traffic that originates from one of several IP address ranges that you know to be malicious. Instead of configuring rules for each range in iptables directly, you can create an IP set and then reference that set in an iptables rule. This makes your rule sets dynamic and therefore easier to configure; whenever you need to add or swap out network identifiers that are handled by the firewall, you simply change the IP set.\nFor that reason we need to monitor failures fot his kind of command in calico.\nrate(felix_ipset_errors[5m]) Iptables Save Failures and Iptables Restore FailuresThe actual iptables rules are created and customized on the command line with the command iptables for IPv4 and ip6tables for IPv6.\nThese can be saved in a file with the command iptables-save for IPv4.\nDebian/Ubuntu: iptables-save \u0026gt; /etc/iptables/rules.v4 RHEL/CentOS: iptables-save \u0026gt; /etc/sysconfig/iptables These files can be loaded again with the command iptables-restore for IPv4.\nDebian/Ubuntu: iptables-restore \u0026lt; /etc/iptables/rules.v4 RHEL/CentOS: iptables-restore \u0026lt; /etc/sysconfig/iptables This is basically the main purpose of calico, so monitor failures of the features is very important.\nrate(felix_iptables_save_errors[5m]) rate(felix_iptables_restore_errors[5m]) LatencyMost usefull way to inform about latency is show some alert with quantiles.\nCalico metrics does not provides buckets, it summarizes all that info with specific labels. For Latency metrics Calico provides quantile labels 0.5, 0.9 and 0.99.\nLatency in Datastore OnUpdate Call# Latency on dataplane update felix_calc_graph_update_time_seconds{quantile=\u0026#34;0.99\u0026#34;} # Latency on acquire iptables lock felix_int_dataplane_apply_time_seconds{quantile=\u0026#34;0.99\u0026#34;} # Latency to list all the interfaces during a resync felix_iptables_lock_acquire_secs{quantile=\u0026#34;0.99\u0026#34;} SaturationThe way to monitor saturation in Calico is batch size. Here we can analyze three kinds of batches and also analyze them by quantiles.\n# Number of messages processed in each batch felix_int_dataplane_msg_batch_size{quantile=\u0026#34;0.99\u0026#34;} # Interface state messages processed in each batch felix_int_dataplane_iface_msg_batch_size{quantile=\u0026#34;0.99\u0026#34;} # Interface address messages processed in each batch felix_int_dataplane_addr_msg_batch_size{quantile=\u0026#34;0.99\u0026#34;} TrafficOne of the four golden signals we have to monitor to is traffic, in this case for calico, we need to monitor the most core network requests. Ipset and Iptables commands are the lowest level interaction in calico, in order to create that traffic Calico needs to create, destroy and update any policy network.\n# Number of ipset commands executed. rate(felix_ipset_calls[5m]) # Number of ipset operations executed. rate(felix_ipset_lines_executed[5m]) # Number of iptables rule updates executed. rate(felix_iptables_lines_executed[5m]) # Number of iptables-restore calls. rate(felix_iptables_restore_calls[5m]) # Number of iptables-save calls. rate(felix_iptables_save_calls[$__interval]) Agent ConfigurationThe default agent jobs for this integration are as follows:\n- job_name: \u0026#39;calico-node-default\u0026#39; kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (calico-node);(.{0}$) replacement: calico target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;calico\u0026#34; - action: replace source_labels: [__address__] regex: ([^:]+)(?::\\d+)? replacement: $1:9091 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (felix_calc_graph_update_time_seconds|felix_cluster_num_hosts|felix_cluster_num_policies|felix_cluster_num_profiles|felix_exec_time_micros|felix_int_dataplane_addr_msg_batch_size|felix_int_dataplane_apply_time_seconds|felix_int_dataplane_failures|felix_int_dataplane_iface_msg_batch_size|felix_int_dataplane_msg_batch_size|felix_ipset_calls|felix_ipset_errors|felix_ipset_lines_executed|felix_iptables_lines_executed|felix_iptables_lock_acquire_secs|felix_iptables_restore_calls|felix_iptables_restore_errors|felix_iptables_save_calls|felix_iptables_save_errors|felix_log_errors|felix_route_table_list_seconds|felix_route_table_per_iface_sync_seconds) action: keep - job_name: \u0026#39;calico-controller-default\u0026#39; kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace separator: ; source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (calico-kube-controllers);(.{0}$) replacement: calico-controller target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;calico-controller\u0026#34; - action: replace source_labels: [__address__] regex: ([^:]+)(?::\\d+)? replacement: $1:9094 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/calico/"},{"id":459,"title":"Cassandra","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v3.x\nThis integration uses a sidecar exporter that is available in UBI or scratch base image.\nThis integration has 30 metrics.\nTimeseries generated: The JMX-Exporter generates ~850 timeseries (the number of keyspaces and tables).\nList of Alerts Alert Description Format [Cassandra] Compaction Task Pending There are many Cassandra compaction tasks pending. Prometheus [Cassandra] Commitlog Pending Tasks There are many Cassandra Commitlog tasks pending. Prometheus [Cassandra] Compaction Executor Blocked Tasks There are many Cassandra compaction executor blocked tasks. Prometheus [Cassandra] Flush Writer Blocked Tasks There are many Cassandra flush writer blocked tasks. Prometheus [Cassandra] Storage Exceptions There are storage exceptions in Cassandra node. Prometheus [Cassandra] High Tombstones Scanned There is a high number of tombstones scanned. Prometheus [Cassandra] JVM Heap Memory High JVM Heap Memory. Prometheus List of DashboardsCassandraThe dashboard provides information on the status of Cassandra. List of Metrics Metric name cassandra_bufferpool_misses_total cassandra_bufferpool_size_total cassandra_client_connected_clients cassandra_client_request_read_latency cassandra_client_request_read_timeouts cassandra_client_request_read_unavailables cassandra_client_request_write_latency cassandra_client_request_write_timeouts cassandra_client_request_write_unavailables cassandra_commitlog_completed_tasks cassandra_commitlog_pending_tasks cassandra_commitlog_total_size cassandra_compaction_compacted_bytes_total cassandra_compaction_completed_tasks cassandra_compaction_pending_tasks cassandra_cql_prepared_statements_executed_total cassandra_cql_regular_statements_executed_total cassandra_dropped_messages_mutation cassandra_dropped_messages_read cassandra_jvm_gc_collection_count cassandra_jvm_gc_duration_seconds cassandra_jvm_memory_usage_max_bytes cassandra_jvm_memory_usage_used_bytes cassandra_storage_internal_exceptions_total cassandra_storage_load_bytes_total cassandra_table_read_requests_per_second cassandra_table_tombstoned_scanned cassandra_table_total_disk_space_used cassandra_table_write_requests_per_second cassandra_threadpool_blocked_tasks_total PrerequisitesCreate ConfigMap for the JMX-ExporterThe JMX-Exporter requires a ConfigMap with the Cassandra JXM configurations, which can be easily installed using a simple command. The following example is for a Cassandra cluster which exposes the jmx port 7199 and it\u0026rsquo;s deployed in the \u0026lsquo;cassandra\u0026rsquo; namespace (modify the jmx port and the namespace as per your needs):\nhelm repo add promcat-charts https://sysdiglabs.github.io/integrations-charts helm repo update helm -n cassandra install cassandra-jmx-exporter promcat-charts/jmx-exporter --set jmx_port=7199 --set integrationType=cassandra --set onlyCreateJMXConfigMap=true InstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/jmx-exporter\nMonitoring and Troubleshooting CassandraHere are some interesting metrics and queries to monitor and troubleshoot Cassandra.\nGeneral StatsNode DownLet\u0026rsquo;s get the number of expected of nodes, and the actual number of nodes up and running. If the number is not the same, then there might a problem.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(kube_workload_status_desired) - sum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(kube_workload_status_ready) \u0026gt; 0 Dropped MessagesDropped Messages MutationIf there are dropped mutation messages then we probably have write/read failures due to timeouts.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_dropped_messages_mutation) Dropped Messages Readsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_dropped_messages_read) Buffer PoolBuffer Pool SizeThis buffer is allocated as off-heap in addition to the memory allocated for heap. Memory is allocated when needed. Check if miss rate is high.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_bufferpool_size_total) Buffer Pool Missessum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_bufferpool_misses_total) CQL StatementsCQL Prepared StatementsUse prepared statements (query with bound variables) as they are more secure and can be cached.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(rate(cassandra_cql_prepared_statements_executed_total[$__interval])) CQL Regular StatementsThis value should be as low as possible if you are looking for good performance.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(rate(cassandra_cql_regular_statements_executed_total[$__interval])) Connected ClientsThe number of current client connections in each node.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_client_connected_clients) Client Request LatencyWrite Latency95th percentile client request write latency.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_client_request_write_latency{quantile=\u0026#34;0.95\u0026#34;}) Read Latency95th percentile client request read latency.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_client_request_read_latency{quantile=\u0026#34;0.95\u0026#34;}) Unavailable ExceptionsNumber of exceptions encountered in regular reads / writes. This number should be near 0 in a healthy cluster.\nRead Unavailable Exceptionssum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(rate(cassandra_client_request_read_unavailables[$__interval])) Write Unavailable Exceptionssum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(rate(cassandra_client_request_write_unavailables[$__interval])) Write Unavailable ExceptionsWrite / read request timeouts in Cassandra nodes. If there are timeouts, check for:\n1.- \u0026lsquo;read_request_timeout_in_ms\u0026rsquo; value in cassandra.yaml in case it is too low. 2.- Check tombstones that can degrade performance. You can find tombstones query below\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name,keyspace,table)(cassandra_table_tombstoned_scanned) Client Request Read Timeoutsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(rate(cassandra_client_request_read_timeouts[$__interval])) Client Request Write Timeoutsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(rate(cassandra_write_request_read_timeouts[$__interval])) Threadpool Blocked TasksCompaction Blocked TasksPending compactions that are blocked. This metric could deviate from \u0026ldquo;pending compactions\u0026rdquo; which includes an estimate of tasks that these pending tasks might create after completion.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(rate(cassandra_threadpool_blocked_tasks_total{pool=\u0026#34;CompactionExecutor\u0026#34;}[$__interval])) Flush Writer Blocked TasksThe writer flush defines the number of parallel writes on disk. This value should be near 0. Check your \u0026ldquo;memtable_flush_writers\u0026rdquo; value to match with your number of cores if you are using SSD disks.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(rate(cassandra_threadpool_blocked_tasks_total{pool=\u0026#34;MemtableFlushWriter\u0026#34;}[$__interval])) CompactionsPending CompactionsCompactions that are queued. This value should be as low as possible. If it reaches more than 50 you can start having CPU and Memory pressure.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_compaction_pending_tasks) Total Size CompactedCassandra triggers minor compactions automatically so the compacted size should be low unless you trigger a major compaction across the node.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(rate(cassandra_compaction_compacted_bytes_total[$__interval])) Commit LogCommit Log Pending TasksThis value should be under 15-20 for performance purposes.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_commitlog_pending_tasks) StorageStorage ExceptionsLook carefully at this value as any storage error over 0 is critical for Cassandra.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_storage_internal_exceptions_total) JVM and GCJVM Heap UsageIf you want to tune your Heap memory you can use this query.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_jvm_memory_usage_used_bytes{area=\u0026#34;Heap\u0026#34;}) If you want to know the maximum heap memory you can use this query.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_jvm_memory_usage_max_bytes{area=\u0026#34;Heap\u0026#34;}) JVM NonHeap UsageUse this query for NonHeap memory.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_jvm_memory_usage_used_bytes{area=\u0026#34;NonHeap\u0026#34;}) GC InfoIf there is memory pressure the max GC duration will start increasing.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_jvm_gc_duration_seconds) Keyspaces and TablesKeyspace SizeThis query gives you information of all keyspaces.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(cassandra_table_total_disk_space_used) Table SizeThis query gives you information of all tables.\nTable Highest Increase SizeVery useful to know what tables are growing too fast.\ntopk(10,sum by (kube_cluster_name,kube_namespace_name, kube_workload_name,keyspace,table)(delta(cassandra_table_total_disk_space_used[$__interval]))) Tombstones ScannedCassandra does not delete data from disk at once. Instead, it writes a tombstone with a value that indicates the data has been deleted.\nA high value (more than 1000) can cause GC pauses, latency and read failures. Sometimes you need to issue a manual compaction from nodetool.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name,keyspace,table)(cassandra_table_tombstoned_scanned) Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: \u0026#39;cassandra-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (cassandra-exporter);(.{0}$) replacement: cassandra target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;cassandra\u0026#34; - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (cassandra_bufferpool_misses_total|cassandra_bufferpool_size_total|cassandra_client_connected_clients|cassandra_client_request_read_latency|cassandra_client_request_read_timeouts|cassandra_client_request_read_unavailables|cassandra_client_request_write_latency|cassandra_client_request_write_timeouts|cassandra_client_request_write_unavailables|cassandra_commitlog_completed_tasks|cassandra_commitlog_pending_tasks|cassandra_commitlog_total_size|cassandra_compaction_compacted_bytes_total|cassandra_compaction_completed_tasks|cassandra_compaction_pending_tasks|cassandra_cql_prepared_statements_executed_total|cassandra_cql_regular_statements_executed_total|cassandra_dropped_messages_mutation|cassandra_dropped_messages_read|cassandra_jvm_gc_collection_count|cassandra_jvm_gc_duration_seconds|cassandra_jvm_memory_usage_max_bytes|cassandra_jvm_memory_usage_used_bytes|cassandra_storage_internal_exceptions_total|cassandra_storage_load_bytes_total|cassandra_table_read_requests_per_second|cassandra_table_tombstoned_scanned|cassandra_table_total_disk_space_used|cassandra_table_write_requests_per_second|cassandra_threadpool_blocked_tasks_total) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/cassandra/"},{"id":460,"title":"Ceph","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v15.2.12\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 24 metrics.\nTimeseries generated: 600 timeseries\nList of Alerts Alert Description Format [Ceph] Ceph Manager is absent Ceph Manager has disappeared from Prometheus target discovery. Prometheus [Ceph] Ceph Manager is missing replicas Ceph Manager is missing replicas. Prometheus [Ceph] Ceph quorum at risk Storage cluster quorum is low. Contact Support. Prometheus [Ceph] High number of leader changes Ceph Monitor has seen a lot of leader changes per minute recently. Prometheus List of DashboardsCephThe dashboard provides information on the status, capacity, latency and throughput of Ceph. List of Metrics Metric name ceph_cluster_total_bytes ceph_cluster_total_used_bytes ceph_health_status ceph_mgr_status ceph_mon_metadata ceph_mon_num_elections ceph_mon_quorum_status ceph_osd_apply_latency_ms ceph_osd_commit_latency_ms ceph_osd_in ceph_osd_metadata ceph_osd_numpg ceph_osd_op_r ceph_osd_op_r_latency_count ceph_osd_op_r_latency_sum ceph_osd_op_r_out_bytes ceph_osd_op_w ceph_osd_op_w_in_bytes ceph_osd_op_w_latency_count ceph_osd_op_w_latency_sum ceph_osd_recovery_bytes ceph_osd_recovery_ops ceph_osd_up ceph_pool_max_avail PrerequisitesEnable Prometheus ModuleCeph instruments Prometheus metrics and annotates the manager pod with Prometheus annotations.\nMake sure that the Prometheus module is activated in the Ceph cluster by running the following command:\nceph mgr module enable prometheus InstallationInstalling an exporter is not required for this integration.\nRelated Blog Posts Monitoring Ceph with Prometheus Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: ceph-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_prometheus_io_port regex: mgr;9283 - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/ceph/"},{"id":461,"title":"Configure Default Integrations","content":" It’s only for PromScrape V2.\nEach Monitoring Integration holds a specific job that scrapes its metrics and sends them to Sysdig Monitor. To optimize metrics scraping for building dashboards and alerts in Sysdig Monitor, Sysdig offers default jobs for these integrations. Periodically, the Sysdig agent connects with Sysdig Monitor retrieves the default jobs, and makes the Monitoring Integrations available for use. See the list of the available integrations and corresponding jobs.\nYou can find all the jobs in the /opt/draios/etc/promscrape.yaml file in the sysdig-agent container in your cluster.\nTwo types of integrations are found:\nEnabled by default: Upon installing the Sysdig Agent, the integration starts sending metrics to the Sysdig backend. Out of the box: An integration that requires no exporter or extra configuration to retrieve metrics from the application. The application is already orchestrated. Supported Monitoring Integrations Integration Out of the Box Enabled by default Job name in config file Apache ✔ apache-exporter-default, apache-grok-default Calico ✔ calico-node-default, calico-controller-default Cassandra ✔ cassandra-default Ceph ✔ ✔ ceph-default Consul ✔ ✔ consul-server-default, consul-envoy-default Elasticsearch ✔ elasticsearch-default Fluentd ✔ ✔ fluentd-default, openshift-fluentd-default HAProxy Ingress ✔ ✔ haproxy-default HAProxy Ingress OpenShift ✔ ✔ haproxy-router Harbor ✔ ✔ harbor-exporter-default, harbor-core-default, harbor-registry-default, harbor-jobservice-default IBM Kubernetes API Server ✔ iks-apiservers-default Istio ✔ ✔ istiod Kubernetes API server ✔ kubernetes-apiservers-default K8s cAdvisor ✔ ✔ k8s-cadvisor-default K8s cAdvisor full ✔ k8s-cadvisor-full Kubernetes controller manager ✔ ✔ kube-controller-manager-default Kubernetes CoreDNS ✔ ✔ kube-dns-default Kubernetes etcd ✔ ✔ etcd-default, etcd-legacy-default Kubernetes kubelet ✔ k8s-kubelet-default Kubernetes kube-proxy ✔ kubernetes-kube-proxy-default Kubernetes PVC ✔ k8s-pvc-default Kubernetes Scheduler ✔ ✔ kube-scheduler-default Kubernetes storage ✔ k8s-storage-default Kafka ✔ kafka-exporter-default, kafka-jmx-default KEDA ✔ ✔ keda-default Knative ✔ ✔ knative-operator-default, knative-serving-controller-default, knative-serving-autoscaler-default, knative-serving-activator-default, knative-serving-webhook-default, knative-eventing-broker-filter-default, knative-eventing-broker-ingress-default, knative-eventing-controller-default, knative-eventing-imc-controller-default, knative-eventing-imc-dispatcher-default, knative-eventing-apiserver-source-default Memcached ✔ memcached-default MongoDB ✔ mongodb-default MySQL ✔ mysql-default NGINX ✔ nginx-default NGINX Ingress ✔ ✔ nginx-ingress-default NTP ✔ ntp-default OPA ✔ ✔ opa-default OpenShift API-Server ✔ openshift-apiserver-default OpenShift Controller Manager ✔ ✔ openshift-controller-manager-default OpenShift CoreDNS ✔ ✔ openshift-dns-default OpenShift Etcd ✔ openshift-etcd-default OpenShift Scheduler ✔ ✔ openshift-scheduler-default OpenShift State Metrics ✔ ✔ openshift-state-metrics OracleDB ✔ oracledb-exporter-default PHP-FPM ✔ php-fpm-default Portworx ✔ ✔ portworx-default, portworx-openshift-default PostgreSQL ✔ postgres-default Prometheus Default Job ✔ ✔ k8s-pods RabbitMQ ✔ ✔ rabbitmq-default Rancher RKE API Server ✔ rancher-rke-api-server-default Rancher RKE Controller Manager ✔ rancher-rke-controller-manager-default Rancher RKE CoreDNS ✔ rancher-rke-coredns-default Rancher RKE Kube Proxy ✔ rancher-rke-kube-proxy-default Rancher RKE Scheduler ✔ rancher-rke-scheduler-default Rancher RKE2 API Server ✔ rancher-rke2-api-server-default Rancher RKE2 Controller Manager ✔ rancher-rke2-controller-manager-default Rancher RKE2 CoreDNS ✔ rancher-rke2-coredns-default Rancher RKE2 Etcd ✔ rancher-rke2-etcd-default Rancher RKE2 Kube Proxy ✔ rancher-rke2-kube-proxy-default Rancher RKE2 Scheduler ✔ rancher-rke2-scheduler-default Redis ✔ redis-default Redis Enterprise ✔ ✔ redis-enterprise-default Sysdig Admission Controller ✔ ✔ sysdig-admission-controller-default Enable and Disable IntegrationsSome integrations are disabled by default due to the potential high cardinality of their metrics. To enable or disable integrations, follow the below steps:\nSteps Preview Navigate to the Monitoring Integrations page (Integrations \u0026gt; Monitoring Integrations). Select any integration (eg. Kubernetes API server), and click on Manage this integration. Select whether this integration is enabled or disabled, and click on Confirm. If the Manage This integration button is not available, please contact Support.\nCustomize a Default JobThe default jobs offered by Sysdig for integrations are optimized to scrape the metrics for building dashboards and alerts in Sysdig Monitor. Instead of processing all the metrics available, you can determine which metrics to include or exclude for your requirements. To do so, you can overwrite the default configuration in the prometheus.yaml file. The prometheus.yaml file is located in the sysdig-agent ConfigMap in the sysdig-agent namespace.\nYou can overwrite the default job for a specific integration by adding a new job to the prometheus.yaml file with the same name as the default job that you want to replace. For example, if you want to create a new job for the Apache integration, create a new job with the name apache-default. The jobs defined by the user has precedence over the default ones.\nSee Supported Monitoring Integrations for the complete list of integrations and corresponding job names.\nUse Sysdig Annotations in ExportersSysdig provides a set of Helm charts that helps you configure the exporters for the integrations. For more information on installing Monitor Integrations, see the Monitoring Integrations option in Sysdig Monitor. Additionally, the Helm charts are publicly available in the Sysdig Helm repository.\nIf exporters are already installed in your cluster, you can use the standard Prometheus annotations and the Sysdig agent will automatically scrape them.\nFor example, if you use the annotation given below, the incoming metrics will have the information about the pod that generates the metrics.\nspec: template: metadata: annotations: prometheus.io/path: /metrics prometheus.io/port: \u0026#39;9100\u0026#39; prometheus.io/scrape: \u0026#39;true\u0026#39; If you use an exporter, the incoming metrics will be associated with the exporter pod, not the application pod. To change this behavior, you can use the Sysdig-provided annotations and configure the exporter on the agent.\nAnnotate the ExporterUse the following annotations to configure the exporter:\nspec: template: metadata: annotations: promcat.sysdig.com/port: \u0026#39;9187\u0026#39; promcat.sysdig.com/target_ns: my-namespace promcat.sysdig.com/target_workload_type: deployment promcat.sysdig.com/target_workload_name: my-workload promcat.sysdig.com/integration_type: my-integration port: The port to scrape for metrics on the exporter. target_ns: The namespace of the workload corresponding to the application (not the exporter). target_workload_type: The type of the workload of the application (not the exporter). The possible values are deployment, statefulset, and daemonset. target_workload_name: The name of the workload corresponding to the application (not the exporter). integration_type: The type of the integration. The job created in the Sysdig agent use this value to find the exporter. Configure a New JobEdit the prometheus.yaml file to configure a new job in Sysdig agent. The file is located in the sysdig-agent ConfigMap in the sysdig-agent namespace.\nYou can use the following example template:\n- job_name: my-integration tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#39;my-integration\u0026#39; # Use here the integration type that you defined in your annotations - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_ns] target_label: kube_namespace_name - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_type] target_label: kube_workload_type - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_name] target_label: kube_workload_name - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name Exclude a Deployment from Being ScrapedIf you want the agent to exclude a deployment from being scraped, use the following annotation:\nspec: template: metadata: annotations: promcat.sysdig.com/omit: \u0026#39;true\u0026#39; Learn More Install Sysdig Agent Configure Monitoring Integrations Application Integrations Collect Prometheus Metrics Custom Integrations Troubleshoot Monitoring Integrations ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/monitoring-integrations/configure-default-integrations/"},{"id":462,"title":"Connect GCP Account in Sysdig Monitor","content":"Onboard a GCP AccountYou can connect a GCP account by using one of the following:\nManual Installation: Manual installation is supported only for a single GCP Project. You can automatically connect to your project by providing associated the service account key.\nTerraform: Terraform-based installation instructions are supported for the following type of GCP accounts:\nSingle GCP project Organization The default code provided on the Connect a GCP project screen of Sysdig Monitor is pre-populated with your Monitor API token and will help you connect your GCP account with Sysdig.\nAccess Cloud Accounts Log in to Sysdig Monitor as an Admin.\nIn the left-hand sidebar, select Integration \u0026gt; Cloud Accounts.\nThe Cloud Accounts page is displayed.\nConnect a GCP AccountIn GCP Log in to the GCP.\nCreate an Owner role.\nIf you are choosing manual installation, ensure that the following are created for your project:\nService Account\nService Account keys in JSON format.\nStore the keys for manual installation.\nIf you are choosing Terraform installation, skip this step as the script will create them for you.\nIn the Sysdig Monitor UI On the Cloud Accounts page, click Add Account.\nChoose GCP.\nThe Connect a GCP Project is displayed.\nSelect one of the following:\nOrganization: Select this option to simultaneously add multiple GCP accounts. Single: Select this option to add a single GCP account. Continue with the Installation methods.\nTerraform Installation Manual Installation Terraform Installation Ensure the prerequisites are met:\nOwner role is created in GCP. GCP Service APIs are enabled. Terraform v1.3.1 or above is installed. Google Cloud SDK is installed. Specify the Region of your GCP project.\nDo not confuse Region with the GCP location or zone. See Identifying a region or zone for more information.\nThe variable, region, in the Terraform script will be automatically replaced with this entry.\nSpecify the Parent Folder ID.\nThe parent directory of the GCP project that the integration is created for. If you leave it blank, integration will be created for every project under the organization. The PARENT_FOLDER_ID variable in the Terraform script will be automatically replaced with this entry.\nCopy the terraform snippet from the screen and save it to main.tf.\nterraform { required_version = \u0026#34;\u0026gt;= 0.12\u0026#34; required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; } } } provider \u0026#34;google\u0026#34; { project = \u0026#34;__PROJECT_ID__\u0026#34; region = \u0026#34;us-west1\u0026#34; } provider \u0026#34;sysdig\u0026#34; { sysdig_monitor_url = \u0026#34;https://app-staging.sysdigcloud.com\u0026#34; sysdig_monitor_api_token = \u0026#34;__API_TOKEN__\u0026#34; } module \u0026#34;sysdig_monitor_cloud_account\u0026#34; { source = \u0026#34;github.com/sysdiglabs/terraform-gcp-monitor-for-cloud/single-project\u0026#34; gcp_project_id = \u0026#34;__PROJECT_ID__\u0026#34; } Replace the following variables fields in the script:\nPROJECT_ID: Your GCP Project ID. API_TOKEN: Sysdig API Token. Run terraform init \u0026amp;\u0026amp; terraform apply.\nThe Terraform scripts will perform the following steps and enable GCP metrics for Sysdig to collect:\nCreate a new Service Account for the specified projects in GCP Add the monitoring.viewer role to the Service Account Generate a Service Account key for the Service Account Create a new customers_providers_key record with credentials in the Sysdig backend. Manual InstallationTo connect to a single project in your GCP account, you provide the service account key in JSON file.\nOn the Connect a GCP Project screen, click Manual Installation.\nUpload the service account key associated with your project.\nClick Confirm.\nIf the connection is successful, the Account Connected message is displayed on the screen.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/cloud-accounts/connect-gcp-account/"},{"id":463,"title":"Consul","content":" This integration is enabled by default.\nVersions supported: \u0026gt; 1.11.1\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 65 metrics.\nTimeseries generated: 1800 timeseries\nList of Alerts Alert Description Format [Consul] KV Store update time anomaly KV Store update time anomaly Prometheus [Consul] Transaction time anomaly Transaction time anomaly Prometheus [Consul] Raft transactions count anomaly Raft transactions count anomaly Prometheus [Consul] Raft commit time anomaly Raft commit time anomaly Prometheus [Consul] Leader time to contact followers too high Leader time to contact followers too high Prometheus [Consul] Flapping leadership Flapping leadership Prometheus [Consul] Too many elections Too many elections Prometheus [Consul] Server cluster unhealthy Server cluster unhealthy Prometheus [Consul] Zero failure tolerance Zero failure tolerance Prometheus [Consul] Client RPC requests anomaly Consul client RPC requests anomaly Prometheus [Consul] Client RPC requests rate limit exceeded Consul client RPC requests rate limit exceeded Prometheus [Consul] Client RPC requests failed Consul client RPC requests failed Prometheus [Consul] License Expiry Consul License Expiry Prometheus [Consul] Garbage Collection pause high Consul Garbage Collection pause high Prometheus [Consul] Garbage Collection pause too high Consul Garbage Collection pause too high Prometheus [Consul] Raft restore duration too high Consul Raft restore duration too high Prometheus [Consul] RPC requests error rate is high Consul RPC requests error rate is high Prometheus [Consul] Cache hit rate is low Consul Cache hit rate is low Prometheus [Consul] High 4xx RequestError Rate High 4xx RequestError Rate Prometheus [Consul] High Request Latency Envoy High Request Latency Prometheus [Consul] High Response Latency Envoy High Response Latency Prometheus [Consul] Certificate close to expire Certificate close to expire Prometheus List of DashboardsConsulThe dashboard provides information on the status and latency of Consul. Consul EnvoyThe dashboard provides information on the Consul Envoy proxies. List of Metrics Metric name consul_autopilot_failure_tolerance consul_autopilot_healthy consul_client_rpc consul_client_rpc_exceeded consul_client_rpc_failed consul_consul_cache_bypass consul_consul_cache_entries_count consul_consul_cache_evict_expired consul_consul_cache_fetch_error consul_consul_cache_fetch_success consul_kvs_apply_sum consul_raft_apply consul_raft_commitTime_sum consul_raft_fsm_lastRestoreDuration consul_raft_leader_lastContact consul_raft_leader_oldestLogAge consul_raft_rpc_installSnapshot consul_raft_state_candidate consul_raft_state_leader consul_rpc_cross_dc consul_rpc_queries_blocking consul_rpc_query consul_rpc_request consul_rpc_request_error consul_runtime_gc_pause_ns consul_runtime_gc_pause_ns_sum consul_system_licenseExpiration consul_txn_apply_sum envoy_cluster_membership_change envoy_cluster_membership_healthy envoy_cluster_membership_total envoy_cluster_upstream_cx_active envoy_cluster_upstream_cx_connect_ms_bucket envoy_cluster_upstream_rq_active envoy_cluster_upstream_rq_pending_active envoy_cluster_upstream_rq_time_bucket envoy_cluster_upstream_rq_xx envoy_server_days_until_first_cert_expiring go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds PrerequisitesEnable Prometheus Metrics and Disable Hostname in MetricsAs seen in Consul documentation pages Helm Global Metrics and Prometheus Retention Time, to make Consul expose an endpoint for scraping metrics, you need to enable a few global.metrics configurations. You also need to enable the telemetry.disable_hostname \u0026ldquo;extra configurations\u0026rdquo; in the Consul Server and Client, so the metrics don\u0026rsquo;t contain the name of the instances.\nIf you install Consul with Helm, you need to use the following flags:\n--set \u0026#39;global.metrics.enabled=true\u0026#39; --set \u0026#39;global.metrics.enableAgentMetrics=true\u0026#39; --set \u0026#39;server.extraConfig=\u0026#34;{\u0026#34;telemetry\u0026#34;: {\u0026#34;disable_hostname\u0026#34;: true}}\u0026#34;\u0026#39; --set \u0026#39;client.extraConfig=\u0026#34;{\u0026#34;telemetry\u0026#34;: {\u0026#34;disable_hostname\u0026#34;: true}}\u0026#34;\u0026#39; InstallationInstalling an exporter is not required for this integration.\nRelated Blog Posts Monitor and troubleshoot Consul with Prometheus Agent ConfigurationThe default agent jobs for this integration are as follows:\n- job_name: \u0026#39;consul-server-default\u0026#39; metrics_path: \u0026#39;/v1/agent/metrics\u0026#39; params: format: [\u0026#39;prometheus\u0026#39;] tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] regex: true - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (consul);(.{0}$) replacement: consul target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;consul\u0026#34; - action: keep source_labels: [__address__] regex: (.*:8500) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;consul-envoy-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] regex: true - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (envoy-sidecar);(.{0}$) replacement: consul target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;consul\u0026#34; - action: replace source_labels: [__address__] regex: (.+?)(\\\\:\\\\d)? replacement: $1:20200 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (envoy_cluster_upstream_cx_active|envoy_cluster_upstream_rq_active|envoy_cluster_upstream_rq_pending_active|envoy_cluster_membership_total|envoy_cluster_membership_healthy|envoy_cluster_membership_change|envoy_cluster_upstream_rq_xx|envoy_cluster_upstream_cx_connect_ms_bucket|envoy_server_days_until_first_cert_expiring|envoy_cluster_upstream_rq_time_bucket) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/consul/"},{"id":464,"title":"Cost Advisor","content":" You can use Cost Advisor to:\nAccess a unified view of multi-cloud costs across AWS, GCP, and Azure. Review Kubernetes cost allocation by team and business unit. Apply recommendations to reduce wasted resources and improve efficiency. Cost monitoring ensures you are not leaving money on the table. Tracking drives accountability and decreases the risk of spending escalations. Use Cost Advisor to optimize and reduce your infrastructure, cloud, and metric costs.\nConceptsWhen using Cost Advisor, you can see a breakdown of multiple sources of cost.\nCPU \u0026amp; Memory Cost AllocationCost Allocation is applicable to workloads and their associated namespaces, and displays the current allocated costs depending on resource requirements. Note that it is different from infrastructure costs, as workload cost allocation is calculated independently and can be considered a “logical cost”.\nAs workloads can exceed their configured requests (ie. it’s overcommitted using more than the number of requests, but less than resource limits) cost allocation is currently calculated daily by evaluating requests and usage, and taking whichever is greater for the given time period.\nGiven below is an example of cost allocation for a workload. It has requests set to 5 CPU cores and 16GB memory running on an t3.medium with a CPU cost of $0.02/hour and memory cost of $0.003/hour (on-demand pricing).\nDay Calculation Cost Day 1 Requested CPU: 5 CPUs ($0.10/hr) Actual CPU Usage: 2 CPUs ($0.04/hr) Requested Memory: 16GB ($0.048/hr)\nActual Memory Usage: 6GB ($0.018/hr)\nRequests are greater than the usage; therefore, actual usage is ignored. Sysdig considers requests for calculating the cost.\nCPU cost: $2.40 Memory cost: $1.15\nDaily Cost: $3.55 Day 2 Requested CPU: 5 CPUs ($0.10/hr) Actual CPU Usage: 12 CPUs ($0.24/hr) Requested Memory: 16GB ($0.048/hr)\nActual Memory Usage: 6GB ($0.018/hr)\nMemory requests are greater than the usage; however the actual CPU usage is higher than the requests. In this case, Sysdig considers actual CPU usage and memory requests.\nCPU cost: $5.76 Memory cost: $1.15\nDaily Cost: $6.91 Day 3 Requested CPU: 5 CPUs ($0.10/hr) Actual CPU Usage: 12 CPUs ($0.024/hr) Requested Memory: 16GB ($0.048/hr)\nActual Memory Usage: 25GB ($0.075/hr)\nBoth the actual memory and CPU usage are higher than the requests (overcommitted). Here, Sysdig considers the actual CPU and memory usage. CPU cost: $5.76 Memory cost: $1.80\nDaily Cost: $7.56 GPUGPU costs reflect the expense of GPU devices running workloads on GPU-enabled nodes. Like CPU and memory, Cost Advisor evaluates GPU requests against actual usage so you can right-size your infrastructure.\nNVIDIAPrerequisites: GPU metrics require you to deploy the NVIDIA GPU Operator and DCGM Exporter on your cluster. Without these, GPU usage data is unavailable and won\u0026rsquo;t be reflected in your cost allocation.\nCost allocation: This is calculated from the number of GPUs requested by each workload, multiplied by the per-GPU price from your Billing Profile. As with CPU and memory, if actual GPU usage exceeds requests, the higher value is used for cost allocation.\nSysdig Monitor currently supports only NVIDIA GPUs, but we are working on expanding support.\nStorage CostsStorage costs consider the cost of persistent volumes (PV) and associated claims in use by workloads. Within the Storage tab you will find all PVs for a given cluster and see which workload is claiming it, as well as the capacity, usage, cost per GB, and total monthly cost. Storage cost data is fed by integrations with cloud providers, for example when using EBS volumes in AWS, Sysdig will refer to EBS pricing.\nStorage costs consider persistent volumes; Sysdig Monitor does not currently display costs of host disks not associated with a PV.\nPractical tips for optimizing storage costs:\nThe Storage tab will display actual usage against a claim. This helps you understand if a volume can be resized. Unused volumes will be listed in the Storage tab. Sysdig reviews your storage infrastructure to identify any PVs that remain unattached or unmounted to pods. Consider repurposing any unused volumes for new or existing applications if suitable. Before proceeding with volume deletion, it is crucial to back up any data stored on these volumes, ensuring it is no longer required for ongoing operations. Network CostsNetwork costs display the associated costs by Kubernetes services configured to use a load balancer. Integration with cloud providers will feed the cost data of load balancers in use.\nNetwork costs display cost of load balancers. Sysdig Monitor does not currently display costs associated with network throughput/traffic.\nIdle CostsIdle costs are applicable when viewing a cluster and quantify how much compute capacity (CPU and memory) is not being used/requested by workloads. This allows platform teams to gauge whether a cluster is a candidate for rightsizing, for example removing excess compute capacity or reshaping the instance types used.\nCluster Management CostsIf you are running a managed Kubernetes service, such as EKS, GKE, AKS, Sysdig Monitor will display the associated management costs that cloud providers charge.\nEfficiency MetricsCPU AllocationThe average usage of CPU against requests over the last 10 minutes. No requests configured will show zero. For example:\nCPU Requests = sum workload CPU usage over the last 10 minutes/sum workload CPU requests\nMemory AllocationThe average usage of memory against requests over the last 10 minutes. No requests configured will show zero. For example:\nMemory Requests = sum workload memory usage over the last 10 minutes/sum workload memory requests\nNote that for CPU requests, memory requests, and resource efficiency, the calculation is made the individual workload level. This means when looking at a namespace, these values are an aggregate of all workloads within the same space.\nCost SavingsCosts help teams optimize costs by recommending changes to their infrastructure.\nWorkload RightsizingFor workloads running on your clusters, Cost Advisor evaluates the usage against requests. For oversized workloads (usage is less than requests) you can use Cost Advisor to:\nQuantify cost savings if you were to rightsize requests. View a recommendation on what values to rightsize workloads to. Evaluate Golden Signals: These are Service Level Indicators (SLIs) that measure key metrics such as latency, requests, traffic, and errors, derived from syscall and ebpf data. Container rightsizing methodology Rightsizing recommendations in the Overview tab are always based on average usage over 1 day, which provides a standard baseline for evaluation.\nCost Advisor helps you understand a workload\u0026rsquo;s resource needs by analyzing CPU and memory usage over time and comparing it to the workload\u0026rsquo;s configured CPU and memory requests. Cost Advisor provides recommendations to adjust these requests, ensuring they better match observed usage. By default, recommendations are based on the average resource usage of all unique containers within a workload over the past day and are provided for each container individually.\nThe Improve Efficiency drawer will present options to customize the algorithm and time window for generating the rightsizing recommendations:\nAvg: Refers to the average value of CPU or memory usage over a given time period. P95: Refers to the 95th percentile of CPU or memory usage over a given time period. It will recommend a value that ignores the highest 5% of usage, excluding peaks and spikes. Max: Represents the highest level of usage that the CPU or memory reached during that period. Consider a conservative approach (Max / P95) for the production of HA environments, and a more aggressive approach (Avg) for staging or test environments. The conservative approach may result in higher expenses compared to the aggressive approach. Prioritizing stability and risk mitigation, the conservative approach ensures reliable performance but may incur increased costs.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/cost-advisor/"},{"id":465,"title":"Couchbase","content":"The Sysdig agent automatically collects all bucket and node metrics. You can also edit the configuration to collect query metrics.\nThis page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nCouchbase SetupCouchbase will automatically expose all metrics. You do not need to configure anything on the Couchbase instance.\nSysdig Agent ConfigurationReview how to edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with Couchbase and collect all bucket and node metrics.\napp_checks: - name: couchbase pattern: comm: beam.smp arg: couchbase port: 8091 conf: server: http://localhost:8091 If authentication is enabled, you need to edit dragent.yaml file to connect with Couchbase. See Example 1.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1: AuthenticationReplace \u0026lt;username\u0026gt; and \u0026lt;password\u0026gt; with appropriate values and update the dragent.yaml file.\napp_checks: - name: couchbase pattern: comm: beam.smp arg: couchbase port: 8091 conf: server: http://localhost:8091 user: \u0026lt;username\u0026gt; password: \u0026lt;password\u0026gt; # The following block is optional and required only if the \u0026#39;path\u0026#39; and # \u0026#39;port\u0026#39; need to be set to non-default values specified here cbstats: port: 11210 path: /opt/couchbase/bin/cbstats Example 2: Query StatsAdditionally, you can configure query_monitoring_url to get query monitoring stats. This is available from Couchbase version 4.5. See Query Monitoring for more detail.\napp_checks: - name: couchbase pattern: comm: beam.smp arg: couchbase port: 8091 conf: server: http://localhost:8091 query_monitoring_url: http://localhost:8093 Metrics AvailableSee Couchbase Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/couchbase/"},{"id":466,"title":"Couchbase Metrics","content":"See Application Integrations for more information.\ncouchbase.by_bucket.avg_bg_wait_timeThe average background wait time.\ncouchbase.by_bucket.avg_disk_commit_timeThe average disk commit time.\ncouchbase.by_bucket.avg_disk_update_timeThe average disk update time.\ncouchbase.by_bucket.bg_wait_totalThe total background wait time.\ncouchbase.by_bucket.bytes_readThe number of bytes read.\ncouchbase.by_bucket.bytes_writtenThe number of bytes written.\ncouchbase.by_bucket.cas_badvalThe number of compare and swap bad values.\ncouchbase.by_bucket.cas_hitsThe number of compare and swap hits.\ncouchbase.by_bucket.cas_missesThe number of compare and swap misses.\ncouchbase.by_bucket.cmd_getThe number of compare and swap gets.\ncouchbase.by_bucket.cmd_setThe number of compare and swap sets.\ncouchbase.by_bucket.couch_docs_actual_disk_sizeThe size of the couchbase docs on disk.\ncouchbase.by_bucket.couch_docs_data_sizeThe data size of the couchbase docs.\ncouchbase.by_bucket.couch_docs_disk_sizeCouch docs total size in bytes.\ncouchbase.by_bucket.couch_docs_fragmentationThe percentage of couchbase docs fragmentation.\ncouchbase.by_bucket.couch_spatial_data_sizeThe size of object data for spatial views.\ncouchbase.by_bucket.couch_spatial_disk_sizeThe amount of disk space occupied by spatial views.\ncouchbase.by_bucket.couch_spatial_opsSpatial operations.\ncouchbase.by_bucket.couch_total_disk_sizeThe total disk size for couchbase.\ncouchbase.by_bucket.couch_views_data_sizeThe size of object data for views.\ncouchbase.by_bucket.couch_views_disk_sizeThe amount of disk space occupied by views.\ncouchbase.by_bucket.couch_views_fragmentationThe view fragmentation.\ncouchbase.by_bucket.couch_views_opsView operations.\ncouchbase.by_bucket.cpu_idle_msCPU idle milliseconds.\ncouchbase.by_bucket.cpu_utilization_rateCPU utilization percentage.\ncouchbase.by_bucket.curr_connectionsCurrent bucket connections.\ncouchbase.by_bucket.curr_itemsNumber of active items in memory.\ncouchbase.by_bucket.curr_items_totTotal number of items.\ncouchbase.by_bucket.decr_hitsDecrement hits.\ncouchbase.by_bucket.decr_missesDecrement misses.\ncouchbase.by_bucket.delete_hitsDelete hits.\ncouchbase.by_bucket.delete_missesDelete misses.\ncouchbase.by_bucket.disk_commit_countDisk commits.\ncouchbase.by_bucket.disk_update_countDisk updates.\ncouchbase.by_bucket.disk_write_queueDisk write queue depth.\ncouchbase.by_bucket.ep_bg_fetchedDisk reads per second.\ncouchbase.by_bucket.ep_cache_miss_rateCache miss rate.\ncouchbase.by_bucket.ep_cache_miss_ratioCache miss ratio.\ncouchbase.by_bucket.ep_dcp_2i_backoffNumber of backoffs for indexes DCP connections.\ncouchbase.by_bucket.ep_dcp_2i_countNumber of indexes DCP connections.\ncouchbase.by_bucket.ep_dcp_2i_items_remainingNumber of indexes items remaining to be sent.\ncouchbase.by_bucket.ep_dcp_2i_items_sentNumber of indexes items sent.\ncouchbase.by_bucket.ep_dcp_2i_producer_countNumber of indexes producers\ncouchbase.by_bucket.ep_dcp_2i_total_bytesNumber bytes per second being sent for indexes DCP connections.\ncouchbase.by_bucket.ep_dcp_fts_backoffNumber of backoffs for fts DCP connections.\ncouchbase.by_bucket.ep_dcp_fts_countNumber of fts DCP connections.\ncouchbase.by_bucket.ep_dcp_fts_items_remainingNumber of fts items remaining to be sent.\ncouchbase.by_bucket.ep_dcp_fts_items_sentNumber of fts items sent.\ncouchbase.by_bucket.ep_dcp_fts_producer_countNumber of fts producers.\ncouchbase.by_bucket.ep_dcp_fts_total_bytesNumber bytes per second being sent for fts DCP connections.\ncouchbase.by_bucket.ep_dcp_other_backoffNumber of backoffs for other DCP connections.\ncouchbase.by_bucket.ep_dcp_other_countNumber of other DCP connections.\ncouchbase.by_bucket.ep_dcp_other_items_remainingNumber of other items remaining to be sent.\ncouchbase.by_bucket.ep_dcp_other_items_sentNumber of other items sent.\ncouchbase.by_bucket.ep_dcp_other_producer_countNumber of other producers.\ncouchbase.by_bucket.ep_dcp_other_total_bytesNumber bytes per second being sent for other DCP connections.\ncouchbase.by_bucket.ep_dcp_replica_backoffNumber of backoffs for replica DCP connections.\ncouchbase.by_bucket.ep_dcp_replica_countNumber of replica DCP connections.\ncouchbase.by_bucket.ep_dcp_replica_items_remainingNumber of replica items remaining to be sent.\ncouchbase.by_bucket.ep_dcp_replica_items_sentNumber of replica items sent.\ncouchbase.by_bucket.ep_dcp_replica_producer_countNumber of replica producers.\ncouchbase.by_bucket.ep_dcp_replica_total_bytesNumber bytes per second being sent for replica DCP connections.\ncouchbase.by_bucket.ep_dcp_views_backoffNumber of backoffs for views DCP connections.\ncouchbase.by_bucket.ep_dcp_views_countNumber of views DCP connections.\ncouchbase.by_bucket.ep_dcp_views_items_remainingNumber of views items remaining to be sent.\ncouchbase.by_bucket.ep_dcp_views_items_sentNumber of views items sent.\ncouchbase.by_bucket.ep_dcp_views_producer_countNumber of views producers.\ncouchbase.by_bucket.ep_dcp_views_total_bytesNumber bytes per second being sent for views DCP connections.\ncouchbase.by_bucket.ep_dcp_xdcr_backoffNumber of backoffs for xdcr DCP connections.\ncouchbase.by_bucket.ep_dcp_xdcr_countNumber of xdcr DCP connections.\ncouchbase.by_bucket.ep_dcp_xdcr_items_remainingNumber of xdcr items remaining to be sent.\ncouchbase.by_bucket.ep_dcp_xdcr_items_sentNumber of xdcr items sent.\ncouchbase.by_bucket.ep_dcp_xdcr_producer_countNumber of xdcr producers.\ncouchbase.by_bucket.ep_dcp_xdcr_total_bytesNumber bytes per second being sent for xdcr DCP connections.\ncouchbase.by_bucket.ep_diskqueue_drainTotal Drained items on disk queue.\ncouchbase.by_bucket.ep_diskqueue_fillTotal enqueued items on disk queue.\ncouchbase.by_bucket.ep_diskqueue_itemsTotal number of items waiting to be written to disk.\ncouchbase.by_bucket.ep_flusher_todoNumber of items currently being written.\ncouchbase.by_bucket.ep_item_commit_failedNumber of times a transaction failed to commit due to storage errors.\ncouchbase.by_bucket.ep_kv_sizeTotal amount of user data cached in RAM in this bucket.\ncouchbase.by_bucket.ep_max_sizeThe maximum amount of memory this bucket can use.\ncouchbase.by_bucket.ep_mem_high_watMemory usage high water mark for auto-evictions.\ncouchbase.by_bucket.ep_mem_low_watMemory usage low water mark for auto-evictions.\ncouchbase.by_bucket.ep_meta_data_memoryTotal amount of item metadata consuming RAM in this bucket.\ncouchbase.by_bucket.ep_num_non_residentNumber of non-resident items.\ncouchbase.by_bucket.ep_num_ops_del_metaNumber of delete operations per second for this bucket as the target for XDCR.\ncouchbase.by_bucket.ep_num_ops_del_ret_metaNumber of delRetMeta operations per second for this bucket as the target for XDCR.\ncouchbase.by_bucket.ep_num_ops_get_metaNumber of read operations per second for this bucket as the target for XDCR.\ncouchbase.by_bucket.ep_num_ops_set_metaNumber of set operations per second for this bucket as the target for XDCR.\ncouchbase.by_bucket.ep_num_ops_set_ret_metaNumber of setRetMeta operations per second for this bucket as the target for XDCR.\ncouchbase.by_bucket.ep_num_value_ejectsNumber of times item values got ejected from memory to disk.\\\ncouchbase.by_bucket.ep_oom_errorsNumber of times unrecoverable OOMs happened while processing operations.\ncouchbase.by_bucket.ep_ops_createCreate operations.\ncouchbase.by_bucket.ep_ops_updateUpdate operations.\ncouchbase.by_bucket.ep_overheadExtra memory used by transient data like persistence queues or checkpoints.\ncouchbase.by_bucket.ep_queue_sizeNumber of items queued for storage.\ncouchbase.by_bucket.ep_resident_items_rateNumber of resident items.\ncouchbase.by_bucket.ep_tap_replica_queue_drainTotal drained items in the replica queue.\ncouchbase.by_bucket.ep_tap_total_queue_drainTotal drained items in the queue.\ncouchbase.by_bucket.ep_tap_total_queue_fillTotal enqueued items in the queue.\ncouchbase.by_bucket.ep_tap_total_total_backlog_sizeNumber of remaining items for replication.\ncouchbase.by_bucket.ep_tmp_oom_errorsNumber of times recoverable OOMs happened while processing operations.\ncouchbase.by_bucket.ep_vb_totalTotal number of vBuckets for this bucket.\ncouchbase.by_bucket.evictionsNumber of evictions\ncouchbase.by_bucket.get_hitsNumber of get hits\ncouchbase.by_bucket.get_missesNumber of get misses.\ncouchbase.by_bucket.hibernated_requestsNumber of streaming requests now idle.\ncouchbase.by_bucket.hibernated_wakedRate of streaming request wakeups.\ncouchbase.by_bucket.hit_ratioHit ratio.\ncouchbase.by_bucket.incr_hitsNumber of increment hits.\ncouchbase.by_bucket.incr_missesNumber of increment misses.\ncouchbase.by_bucket.mem_actual_freeFree memory.\ncouchbase.by_bucket.mem_actual_usedUsed memory.\ncouchbase.by_bucket.mem_freeFree memory.\ncouchbase.by_bucket.mem_totalTotal available memory.\ncouchbase.by_bucket.mem_used (deprecated)Engine\u0026rsquo;s total memory usage.\ncouchbase.by_bucket.mem_used_sysSystem memory usage.\ncouchbase.by_bucket.missesTotal number of misses.\ncouchbase.by_bucket.opsTotal number of operations.\ncouchbase.by_bucket.page_faultsNumber of page faults.\ncouchbase.by_bucket.replication_docs_rep_queuecouchbase.by_bucket.replication_meta_latency_aggrcouchbase.by_bucket.rest_requestsNumber of HTTP requests.\ncouchbase.by_bucket.swap_totalTotal amount of swap available.\ncouchbase.by_bucket.swap_usedAmount of swap used.\ncouchbase.by_bucket.vb_active_ejectNumber of items per second being ejected to disk from active vBuckets.\ncouchbase.by_bucket.vb_active_itm_memoryAmount of active user data cached in RAM in this bucket.\ncouchbase.by_bucket.vb_active_meta_data_memoryAmount of active item metadata consuming RAM in this bucket.\ncouchbase.by_bucket.vb_active_numNumber of active items.\ncouchbase.by_bucket.vb_active_num_non_residentNumber of non resident vBuckets in the active state for this bucket.\ncouchbase.by_bucket.vb_active_ops_createNew items per second being inserted into active vBuckets in this bucket.\ncouchbase.by_bucket.vb_active_ops_updateNumber of items updated on active vBucket per second for this bucket.\ncouchbase.by_bucket.vb_active_queue_ageSum of disk queue item age in milliseconds.\ncouchbase.by_bucket.vb_active_queue_drainTotal drained items in the queue.\ncouchbase.by_bucket.vb_active_queue_fillNumber of active items per second being put on the active item disk queue.\ncouchbase.by_bucket.vb_active_queue_sizeNumber of active items in the queue.\ncouchbase.by_bucket.vb_active_resident_items_ratioNumber of resident items.\ncouchbase.by_bucket.vb_avg_active_queue_ageAverage age in seconds of active items in the active item queue.\ncouchbase.by_bucket.vb_avg_pending_queue_ageAverage age in seconds of pending items in the pending item queue.\ncouchbase.by_bucket.vb_avg_replica_queue_ageAverage age in seconds of replica items in the replica item queue.\ncouchbase.by_bucket.vb_avg_total_queue_ageAverage age of items in the queue.\ncouchbase.by_bucket.vb_pending_curr_itemsNumber of items in pending vBuckets.\ncouchbase.by_bucket.vb_pending_ejectNumber of items per second being ejected to disk from pending vBuckets.\ncouchbase.by_bucket.vb_pending_itm_memoryAmount of pending user data cached in RAM in this bucket.\ncouchbase.by_bucket.vb_pending_meta_data_memoryAmount of pending item metadata consuming RAM in this bucket.\ncouchbase.by_bucket.vb_pending_numNumber of pending items.\ncouchbase.by_bucket.vb_pending_num_non_residentNumber of non resident vBuckets in the pending state for this bucket.\ncouchbase.by_bucket.vb_pending_ops_createNumber of pending create operations.\ncouchbase.by_bucket.vb_pending_ops_updateNumber of items updated on pending vBucket per second for this bucket.\ncouchbase.by_bucket.vb_pending_queue_ageSum of disk pending queue item age in milliseconds.\ncouchbase.by_bucket.vb_pending_queue_drainTotal drained pending items in the queue.\ncouchbase.by_bucket.vb_pending_queue_fillTotal enqueued pending items on disk queue.\ncouchbase.by_bucket.vb_pending_queue_sizeNumber of pending items in the queue.\ncouchbase.by_bucket.vb_pending_resident_items_ratioNumber of resident pending items.\ncouchbase.by_bucket.vb_replica_curr_itemsNumber of in memory items.\ncouchbase.by_bucket.vb_replica_ejectNumber of items per second being ejected to disk from replica vBuckets.\ncouchbase.by_bucket.vb_replica_itm_memoryAmount of replica user data cached in RAM in this bucket.\ncouchbase.by_bucket.vb_replica_meta_data_memoryTotal metadata memory.\ncouchbase.by_bucket.vb_replica_numNumber of replica vBuckets.\ncouchbase.by_bucket.vb_replica_num_non_residentNumber of non resident vBuckets in the replica state for this bucket.\ncouchbase.by_bucket.vb_replica_ops_createNumber of replica create operations.\ncouchbase.by_bucket.vb_replica_ops_updateNumber of items updated on replica vBucket per second for this bucket.\ncouchbase.by_bucket.vb_replica_queue_ageSum of disk replica queue item age in milliseconds.\ncouchbase.by_bucket.vb_replica_queue_drainTotal drained replica items in the queue.\ncouchbase.by_bucket.vb_replica_queue_fillTotal enqueued replica items on disk queue.\ncouchbase.by_bucket.vb_replica_queue_sizeReplica items in disk queue.\ncouchbase.by_bucket.vb_replica_resident_items_ratioNumber of resident replica items.\ncouchbase.by_bucket.vb_total_queue_ageSum of disk queue item age in milliseconds.\ncouchbase.by_bucket.xdc_opsNumber of cross-data center replication operations.\ncouchbase.by_node.couch_docs_actual_disk_sizeCouch docs total size on disk in bytes.\ncouchbase.by_node.couch_docs_data_sizeCouch docs data size in bytes.\ncouchbase.by_node.couch_views_actual_disk_sizeCouch views total size on disk in bytes.\ncouchbase.by_node.couch_views_data_sizeCouch views data size on disk in bytes.\ncouchbase.by_node.curr_itemsNumber of active items in memory.\ncouchbase.by_node.curr_items_totTotal number of items.\ncouchbase.by_node.vb_replica_curr_itemsNumber of in memory items.\ncouchbase.hdd.freeFree hard disk space.\ncouchbase.hdd.quota_totalHard disk quota.\ncouchbase.hdd.totalTotal hard disk space.\ncouchbase.hdd.usedUsed hard disk space.\ncouchbase.hdd.used_by_dataHard disk used for data.\ncouchbase.query.corescouchbase.query.cpu_sys_percentcouchbase.query.cpu_user_percentcouchbase.query.gc_numcouchbase.query.gc_pause_percentcouchbase.query.gc_pause_timecouchbase.query.memory_systemcouchbase.query.memory_totalcouchbase.query.memory_usagecouchbase.query.request_active_countcouchbase.query.request_completed_countcouchbase.query.request_per_sec_15mincouchbase.query.request_per_sec_1mincouchbase.query.request_per_sec_5mincouchbase.query.request_prepared_percentcouchbase.query.request_time_80percentilecouchbase.query.request_time_95percentilecouchbase.query.request_time_99percentilecouchbase.query.request_time_meancouchbase.query.request_time_mediancouchbase.query.total_threadscouchbase.ram.quota_totalRAM quota.\ncouchbase.ram.totalThe total RAM available.\ncouchbase.ram.usedThe amount of RAM in use.\ncouchbase.ram.used_by_dataThe amount of RAM used for data.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/couchbase-metrics/"},{"id":467,"title":"Elastic Container Service (ECS)","content":"ecs.clusterNameThe name of the cluster. For more information, refer to the AWS CloudFormation documentation.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A ecs.serviceNameThe name of the Elastic Container Service (Amazon ECS) service. For more information, refer to the AWS CloudFormation documentation.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A ecs.taskFamilyNameThe name of the task definition family. For more information, refer to the AWS CloudFormation documentation.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A ","url":"https://docs.sysdig.com/en/sysdig-monitor/aws-metrics-legacy/elastic-container-service-ecs/"},{"id":468,"title":"Elasticsearch","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v6.8\nThis integration uses a standalone exporter that is available in UBI or scratch base image.\nThis integration has 28 metrics.\nTimeseries generated: 400 timeseries\nList of Alerts Alert Description Format [Elasticsearch] Heap Usage Too High The heap usage is over 90% Prometheus [Elasticsearch] Heap Usage Warning The heap usage is over 80% Prometheus [Elasticsearch] Disk Space Low Disk available less than 20% Prometheus [Elasticsearch] Disk Out Of Space Disk available less than 10% Prometheus [Elasticsearch] Cluster Red Cluster in Red status Prometheus [Elasticsearch] Cluster Yellow Cluster in Yellow status Prometheus [Elasticsearch] Relocation Shards Relocating shards for too long Prometheus [Elasticsearch] Initializing Shards Initializing shards takes too long Prometheus [Elasticsearch] Unassigned Shards Unassigned shards for long time Prometheus [Elasticsearch] Pending Tasks Elasticsearch has a high number of pending tasks Prometheus [Elasticsearch] No New Documents Elasticsearch has no new documents for a period of time Prometheus List of DashboardsElasticSearch ClusterThe dashboard provides information on the status of the ElasticSearch cluster health and its usage of resources. ElasticSearch InfraThe dashboard provides information on the usage of CPU, memory, disk and networking of ElasticSearch. List of Metrics Metric name elasticsearch_cluster_health_active_primary_shards elasticsearch_cluster_health_active_shards elasticsearch_cluster_health_initializing_shards elasticsearch_cluster_health_number_of_data_nodes elasticsearch_cluster_health_number_of_nodes elasticsearch_cluster_health_number_of_pending_tasks elasticsearch_cluster_health_relocating_shards elasticsearch_cluster_health_status elasticsearch_cluster_health_unassigned_shards elasticsearch_filesystem_data_available_bytes elasticsearch_filesystem_data_size_bytes elasticsearch_indices_docs elasticsearch_indices_indexing_index_time_seconds_total elasticsearch_indices_indexing_index_total elasticsearch_indices_merges_total_time_seconds_total elasticsearch_indices_search_query_time_seconds elasticsearch_indices_store_throttle_time_seconds_total elasticsearch_jvm_gc_collection_seconds_count elasticsearch_jvm_gc_collection_seconds_sum elasticsearch_jvm_memory_committed_bytes elasticsearch_jvm_memory_max_bytes elasticsearch_jvm_memory_used_bytes elasticsearch_os_load1 elasticsearch_os_load15 elasticsearch_os_load5 elasticsearch_process_cpu_percent elasticsearch_transport_rx_size_bytes_total elasticsearch_transport_tx_size_bytes_total PrerequisitesCreate the SecretsKeep in mind:\nIf your ElasticSearch cluster is using basic authentication, you have to create the secret that contains the user and password. The secrets need to be created in the same namespace where the exporter will be deployed. Use the same user name and password that you used for the api. You can change the name of the secret. If you do this, you will need to select it in the next steps of the integration. Create the Secret for the username and password with Basic Auth optionkubectl -n Your-Exporter-Namespace create secret generic elastic-user-pass-secret \\ --from-literal=username=\u0026#39;\u0026lt;your-username\u0026gt;\u0026#39; --from-literal=password=\u0026#39;\u0026lt;your-password\u0026gt;\u0026#39; Create the Secret for the TLS CertsIf you are using HTTPS with custom certificates, follow the instructions given below.\nkubectl create -n Your-Application-Namespace secret generic elastic-tls-secret \\ --from-file=root-ca.crt=/path/to/tls/ca-cert \\ --from-file=root-ca.key=/path/to/tls/ca-key \\ --from-file=root-ca.pem=/path/to/tls/ca-pem InstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/elasticsearch-exporter\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: elasticsearch-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;elasticsearch\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_ns] target_label: kube_namespace_name - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_type] target_label: kube_workload_type - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_name] target_label: kube_workload_name - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (elasticsearch_cluster_health_active_primary_shards|elasticsearch_cluster_health_active_shards|elasticsearch_cluster_health_initializing_shards|elasticsearch_cluster_health_number_of_data_nodes|elasticsearch_cluster_health_number_of_nodes|elasticsearch_cluster_health_number_of_pending_tasks|elasticsearch_cluster_health_relocating_shards|elasticsearch_cluster_health_status|elasticsearch_cluster_health_unassigned_shards|elasticsearch_filesystem_data_available_bytes|elasticsearch_filesystem_data_size_bytes|elasticsearch_indices_docs|elasticsearch_indices_indexing_index_time_seconds_total|elasticsearch_indices_indexing_index_total|elasticsearch_indices_merges_total_time_seconds_total|elasticsearch_indices_search_query_time_seconds|elasticsearch_indices_store_throttle_time_seconds_total|elasticsearch_jvm_gc_collection_seconds_count|elasticsearch_jvm_gc_collection_seconds_sum|elasticsearch_jvm_memory_committed_bytes|elasticsearch_jvm_memory_max_bytes|elasticsearch_jvm_memory_pool_peak_used_bytes|elasticsearch_jvm_memory_used_bytes|elasticsearch_os_load1|elasticsearch_os_load15|elasticsearch_os_load5|elasticsearch_process_cpu_percent|elasticsearch_transport_rx_size_bytes_total|elasticsearch_transport_tx_size_bytes_total) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/elasticsearch/"},{"id":469,"title":"Using Extended Label Set","content":"With this, you can troubleshoot a problem or building Dashboards and Alerts without the need to write complex queries. Sysdig automatically enriches your metrics with Kubernetes and application context without the need to instrument additional labels in your environment. This reduces operational complexity and cost—the enrichment takes place in Sysdig metric ingestion pipeline after time series have been sent to the backend.\nCalculate Memory Usage by Deployment in a ClusterUsing the vector matching operation, you could run the following query and calculate the memory usage by deployment in a cluster:\nsum by(cluster,namespace,owner_name) ((sysdig_container_memory_used_bytes * on(container_id) group_left(pod,namespace,cluster) kube_pod_container_info) * on(pod,namespace,cluster) group_left(owner_name) kube_pod_owner{owner_kind=\u0026#34;Deployment\u0026#34;,owner_name=~\u0026#34;.+\u0026#34;,cluster=~\u0026#34;.+\u0026#34;,namespace=~\u0026#34;.+\u0026#34;}) To get the result, you need to write a query to perform a join (vector match) of various metrics, usually in the following order:\nGrab a metric you need that is defined on a container level. For example, a Prometheus metric or some of the Sysdig provided metrics, such as sysdig_container_memory_used_byte.\nPerform a vector match on container ID with the metric kube_pod_container_info to get the pod metadata.\nPerform a vector match on the pod, namespace, and cluster with the kube_pod_owner metric.\nIn the case of Sysdig\u0026rsquo;s extended label set for PromQL, all the metrics inherit the metadata, so that necessary container, host, and Kubernetes metadata are set on all the metrics. This simplifies the query so you can build and run it quickly.\nLikewise, the above query can be simplified as follows:\nsum by (kube_cluster_name,kube_namespace_name,kube_deployment_name)(sysdig_container_memory_used_bytes{kube_cluster_name!=\u0026#34;\u0026#34;,kube_namespace_name!=\u0026#34;\u0026#34;,kube_deployment_name!=\u0026#34;\u0026#34;}) The advantages of using a simplified query are:\nComplex vector matching operations (the group_left and group_right operators) are no longer required. All the labels are already available on each of the metrics, and therefore, any filtering can be performed directly on the metric itself.\nThe metrics now will have a huge amount of labels. You can use PromQL Query Explorer to work with this rich metadata.\nThe metadata is distinguishable from user-defined labels. For example, Kubernetes metadata labels start with kube_. For instance, cluster is replaced with kube_cluster_name.\nExamples for Simplifying QueriesGiven below are some of the examples of using the extended label set to simplify complex query operations.\nMemory Usage in a Kubernetes ClusterQuery with core label set:\navg by (agent_tag_cluster) ((sysdig_host_memory_used_bytes/sysdig_host_memory_total_bytes) * on(host,agent_tag_cluster) sysdig_host_info{agent_tag_cluster=~\u0026#34;.+\u0026#34;}) * 100 Query with the extended label set:\navg by (agent_tag_cluster) (sysdig_host_memory_used_bytes/sysdig_host_memory_total_bytes) * 100 CPU Usage in ContainersQuery with the core label set:\nsum by (cluster,namespace)(sysdig_container_cpu_cores_used * on (container_id) group_left(cluster,pod,namespace) kube_pod_container_info{cluster=~\u0026#34;.+\u0026#34;}) Simplified query with the extended label set:\nsum by (kube_cluster_name,kube_namespace_name) (sysdig_container_cpu_cores_used{kube_cluster_name=~\u0026#34;.+\u0026#34;}) Memory Usage in DaemonsetQuery with the core label set:\nsum by(cluster,namespace,owner_name) (sum by(pod) (label_replace(sysdig_container_memory_used_bytes * on(container_id,host_mac) group_left(label_io_kubernetes_pod_namespace,label_io_kubernetes_pod_name,label_io_kubernetes_container_name) sysdig_container_info{label_io_kubernetes_pod_namespace=~\u0026#34;.*\u0026#34;,cluster=~\u0026#34;.*\u0026#34;},\u0026#34;pod\u0026#34;,\u0026#34;$1\u0026#34;,\u0026#34;label_io_kubernetes_pod_name\u0026#34;,\u0026#34;(.*)\u0026#34;)) * on(pod) group_right sum by(cluster,namespace,owner_name,pod) (kube_pod_owner{owner_kind=~\u0026#34;DaemonSet\u0026#34;,owner_name=~\u0026#34;.*\u0026#34;,cluster=~\u0026#34;.*\u0026#34;,namespace=~\u0026#34;.*\u0026#34;})) Simplified query with the extended label set:\nsum by(kube_cluster_name,kube_namespace_name,kube_daemonset_name) (sysdig_container_memory_used_bytes{kube_daemonset_name=~\u0026#34;.*\u0026#34;,kube_cluster_name=~\u0026#34;.*\u0026#34;,kube_namespace_name=~\u0026#34;.*\u0026#34;}) Pod Restarts in a Kubernetes ClusterQuery with the core label set:\nsum by(cluster,namespace,owner_name) (changes(kube_pod_status_ready{condition=\u0026#34;true\u0026#34;,cluster=~$cluster,namespace=~$namespace}[$__interval]) * on(cluster,namespace,pod) group_left(owner_name) kube_pod_owner{owner_kind=\u0026#34;Deployment\u0026#34;,owner_name=~\u0026#34;.+\u0026#34;,cluster=~$cluster,namespace=~$namespace}) Simplified query with the extended label set:\nsum by (kube_cluster_name,kube_namespace_name,kube_deployment_name) (changes(kube_pod_status_ready{condition=\u0026#34;true\u0026#34;,kube_cluster_name=~$cluster,kube_namespace_name=~$namespace,kube_deployment_name=~\u0026#34;.+\u0026#34;}[$__interval])) Containers per ImageQuery with the core label set:\ncount by (owner_name,image,cluster,namespace) ((sysdig_container_info{cluster=~$cluster,namespace=~$namespace}) * on(pod,namespace,cluster) group_left(owner_name) max by (pod,namespace,cluster,owner_name)(kube_pod_owner{owner_kind=\u0026#34;Deployment\u0026#34;,owner_name=~\u0026#34;.+\u0026#34;})) Simplified query with the extended label set:\ncount by (kube_deployment_name,image,kube_cluster_name,kube_namespace_name) (sysdig_container_info{kube_deployment_name=~\u0026#34;.+\u0026#34;,kube_cluster_name=~$cluster,kube_namespace_name=~$namespace}) Average TCP Queue per NodeQuery with the core label set:\navg by (agent_tag_cluster,host)( sysdig_host_net_tcp_queue_len * on (host_mac) group_left(agent_tag_cluster,host) sysdig_host_info{agent_tag_cluster=~$cluster,host=~\u0026#34;.+\u0026#34;}) Simplified query with the extended label set:\navg by (agent_tag_cluster,host_hostname) (sysdig_host_net_tcp_queue_len{agent_tag_cluster =~ $cluster}) ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/use-promql/using-extended-label-set/"},{"id":470,"title":"File","content":" sysdig_fs_* metrics are based on mounted filesystems for both hosts and containers, and are generated for each filesystem. sysdig_host_fs_* and sysdig_container_fs_* are nothing but sum aggregates of mounted filesystems on host and container respectively. File systems in containers are filtered out based on !(“tmpfs\u0026quot;.equals(device) || mountDir.startsWith(\u0026quot;/sys/fs/cgroup\u0026quot;) || mountDir.startsWith(\u0026quot;/proc/\u0026quot;) || mountDir.contains(\u0026quot;/secrets\u0026quot;) || mountDir.startsWith(\u0026quot;/etc\u0026quot;) || device.startsWith(\u0026quot;overlay”)). However, they seem to be included in the aggregated sysdig_container_fs_* metrics. sysdig_fs_* metrics have the same name for both host and container file systems and therefore use a filter to view individual types. To view only host filesystems, apply the {container_id = ‘’} filter. To view only the file systems mounted to containers, apply the {container_id !=‘’ condition. sysdig_container_fs_nfs_op_count Prometheus ID sysdig_container_fs_nfs_op_count Legacy ID Metric Type counter Unit number Description Total number of requests sent by the client for this operation. Additional Notes sysdig_container_fs_nfs_op_request_count Prometheus ID sysdig_container_fs_nfs_op_request_count Legacy ID Metric Type counter Unit number Description Total number of requests sent by the client for this operation. Additional Notes sysdig_container_fs_nfs_op_sent_bytes Prometheus ID sysdig_container_fs_nfs_op_sent_bytes Legacy ID Metric Type counter Unit - Description Total bytes sent for this operation type. Additional Notes sysdig_container_fs_nfs_op_recv_bytes Prometheus ID sysdig_container_fs_nfs_op_recv_bytes Legacy ID Metric Type counter Unit - Description Total bytes received for this operation type. Additional Notes sysdig_container_fs_nfs_op_queue_time_us Prometheus ID sysdig_container_fs_nfs_op_queue_time_us Legacy ID Metric Type counter Unit - Description Total time spent by instances of this op type in backlog, in microseconds. Additional Notes sysdig_container_fs_nfs_op_round_trip_time_us Prometheus ID sysdig_container_fs_nfs_op_round_trip_time_us Legacy ID Metric Type counter Unit - Description Total round trip time across all invocations of this op, in microseconds. Additional Notes sysdig_container_fs_nfs_op_total_client_time_us Prometheus ID sysdig_container_fs_nfs_op_total_client_time_us Legacy ID Metric Type counter Unit - Description Total execution time for all invocations of this op, in microseconds. Additional Notes sysdig_host_filesystem_readonly Prometheus ID sysdig_host_filesystem_readonly Legacy ID Metric Type gauge Unit number Description Indicates whether the filesystem is mounted as read-only. A value of 1 means read-only; 0 means read-write. sysdig_host_fs_nfs_op_count Prometheus ID sysdig_host_fs_nfs_op_count Legacy ID Metric Type counter Unit number Description Total number of requests sent by the client for this operation. Additional Notes sysdig_host_fs_nfs_op_request_count Prometheus ID sysdig_host_fs_nfs_op_request_count Legacy ID Metric Type counter Unit number Description Total number of requests sent by the client for this operation. Additional Notes sysdig_host_fs_nfs_op_sent_bytes Prometheus ID sysdig_host_fs_nfs_op_sent_bytes Legacy ID Metric Type counter Unit number Description Total bytes sent for this operation type. Additional Notes sysdig_host_fs_nfs_op_recv_bytes Prometheus ID sysdig_host_fs_nfs_op_recv_bytes Legacy ID Metric Type counter Unit number Description Total bytes received for this operation type. Additional Notes sysdig_host_fs_nfs_op_queue_time_us: Prometheus ID sysdig_host_fs_nfs_op_queue_time_us: Legacy ID Metric Type counter Unit number Description Total time spent by instances of this op type in backlog, in microseconds. Additional Notes sysdig_host_fs_nfs_op_round_trip_time_us Prometheus ID sysdig_host_fs_nfs_op_round_trip_time_us Legacy ID Metric Type counter Unit number Description Total round trip time across all invocations of this op, in microseconds. Additional Notes sysdig_host_fs_nfs_op_total_client_time_us Prometheus ID sysdig_host_fs_nfs_op_total_client_time_us Legacy ID Metric Type counter Unit number Description Total execution time for all invocations of this op, in microseconds Additional Notes sysdig_filestats_host_file_error_total_count Prometheus ID sysdig_filestats_host_file_error_total_count Legacy ID file.error.total.count Metric Type counter Unit number Description Number of error caused by file access. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_filestats_host_file_in_bytes Prometheus ID sysdig_filestats_host_file_in_bytes Legacy ID file.bytes.in Metric Type counter Unit data Description Amount of bytes read from file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_filestats_host_file_open_count Prometheus ID sysdig_filestats_host_file_open_count Legacy ID file.open.count Metric Type counter Unit number Description When segmenting by file name, the metric represents the rate of open events for a particular file With other segmentations, it represents the number of all files currently open in a particular context (host, container, process, etc.). Additional Notes sysdig_filestats_host_file_out_bytes Prometheus ID sysdig_filestats_host_file_out_bytes Legacy ID file.bytes.out Metric Type counter Unit data Description Amount of bytes written to file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_filestats_host_file_total_bytes Prometheus ID sysdig_filestats_host_file_total_bytes Legacy ID file.bytes.total Metric Type counter Unit data Description Amount of bytes read from and written to file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_filestats_host_file_total_time Prometheus ID sysdig_filestats_host_file_total_time Legacy ID file.time.total Metric Type counter Unit time Description Time spent in file I/O. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_fs_file_total_time Prometheus ID sysdig_fs_file_total_time Legacy ID Metric Type counter Unit - Description The time taken to complete all I/O on the filesystem mount, in nanoseconds. Additional Notes sysdig_fs_file_open_count Prometheus ID sysdig_fs_file_open_count Legacy ID Metric Type counter Unit number Description The number of opened file descriptors in the filesystem mount. Additional Notes sysdig_fs_file_error_total_count Prometheus ID sysdig_fs_file_error_total_count Legacy ID Metric Type counter Unit number Description The total number of errors when using the filesystem mount Additional Notes sysdig_fs_file_total_bytes Prometheus ID sysdig_fs_file_total_bytes Legacy ID Metric Type counter Unit - Description The total number of bytes read and written on the filesystem mount Additional Notes sysdig_fs_file_in_bytes Prometheus ID sysdig_fs_file_in_bytes Legacy ID Metric Type counter Unit - Description The total number of bytes read from the filesystem mount. Additional Notes sysdig_fs_file_out_bytes Prometheus ID sysdig_fs_file_out_bytes Legacy ID Metric Type counter Unit - Description The total number of bytes written to the filesystem mount. Additional Notes sysdig_fs_free_bytes Prometheus ID sysdig_fs_free_bytes Legacy ID fs.bytes.free Metric Type gauge Unit data Description Filesystem available space. Additional Notes sysdig_fs_free_percent Prometheus ID sysdig_fs_free_percent Legacy ID fs.free.percent Metric Type gauge Unit percent Description Percentage of filesystem free space. Additional Notes sysdig_fs_inodes_total_count Prometheus ID sysdig_fs_inodes_total_count Legacy ID fs.inodes.total.count Metric Type gauge Unit number Description Additional Notes sysdig_fs_inodes_used_count Prometheus ID sysdig_fs_inodes_used_count Legacy ID fs.inodes.used.count Metric Type gauge Unit number Description Additional Notes sysdig_fs_inodes_used_percent Prometheus ID sysdig_fs_inodes_used_percent Legacy ID fs.inodes.used.percent Metric Type gauge Unit percent Description Additional Notes sysdig_fs_total_bytes Prometheus ID sysdig_fs_total_bytes Legacy ID fs.bytes.total Metric Type gauge Unit data Description Filesystem size. Additional Notes sysdig_fs_used_bytes Prometheus ID sysdig_fs_used_bytes Legacy ID fs.bytes.used Metric Type gauge Unit data Description Filesystem used space. Additional Notes sysdig_fs_used_percent Prometheus ID sysdig_fs_used_percent Legacy ID fs.used.percent Metric Type gauge Unit percent Description Percentage of the sum of all filesystems in use. Additional Notes ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/file/"},{"id":471,"title":"Find the Super Admin Credentials and API Token","content":" The Sysdig Monitor web interface does not currently provide a way to identify the super user. If you are trying to use the API to make a configuration change and it fails due to insufficient privileges, you can use the API to locate the super user.\nFind Super Admin CredentialsTwo approaches:\n1. Access the API endpoint to list users directly via curl and parse the JSON output to locate the user with \u0026ldquo;ROLE_ADMIN\u0026rdquo; listed in the \u0026ldquo;roles\u0026rdquo; section.\n# curl -k \\ -H \u0026#39;Authorization: Bearer xxxxxxxx-yyyy-zzzz-aaaa-bbbbbbbbbbbb\u0026#39; \\ https://\u0026lt;your-sysdig-monitor-hostname\u0026gt;/api/users \\ | python -m json.tool Output:\n{ \u0026#34;users\u0026#34;: [ { .... \u0026#34;roles\u0026#34;: [ \u0026#34;ROLE_ADMIN\u0026#34;, \u0026#34;ROLE_CUSTOMER\u0026#34;, \u0026#34;ROLE_USER\u0026#34; ], \u0026#34;username\u0026#34;: \u0026#34;your-super-admin@example.com\u0026#34; }, ... ] } 2. Use this example Python script that leverages the Sysdig Monitor API.\nexport SDC_SSL_VERIFY=\u0026#34;false\u0026#34; export SDC_URL=\u0026#34;https://\u0026lt;your-sysdig-monitor-hostname\u0026gt;\u0026#34; # python list_admins.py xxxxxxxx-yyyy-zzzz-aaaa-bbbbbbbbbbbb Output:\nAdmin users ----------- your-super-admin@example.com regular-admin@example.com Super Admins ------------ your-super-admin@example.com Find Sysdig API TokenAs with any user, you can then obtain the API token by logging in as the \u0026ldquo;super\u0026rdquo; admin to the Sysdig UI.\nWhen using the Sysdig API with custom scripts or applications, an API security token (specific to each team) must be supplied.\nLog in to Sysdig Monitor or Sysdig Secure and select Settings.\nSelect User Profile. The Sysdig Monitor or Sysdig Secure API token is displayed (depending on which interface and team you logged in to).\nYou can view and copy the token for use, or click the Reset Token button to generate a new one.\nWhen reset, the previous token issued will immediately become invalid and you will need to make appropriate changes to your programs or scripts.\n","url":"https://docs.sysdig.com/en/administration/onprem-find-superadmin-credentials-api-token/"},{"id":472,"title":"Fluentd","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v1.12.4\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 12 metrics.\nTimeseries generated: 640 timeseries\nList of Alerts Alert Description Format [Fluentd] No Input From Container No Input From Container. This alert does not work in OpenShift. Prometheus [Fluentd] High Error Ratio High Error Ratio. Prometheus [Fluentd] High Retry Ratio High Retry Ratio. Prometheus [Fluentd] High Retry Wait High Retry Wait. Prometheus [Fluentd] Low Buffer Available Space Low Buffer Available Space. Prometheus [Fluentd] Buffer Queue Length Increasing Buffer Queue Length Increasing. Prometheus [Fluentd] Buffer Total Bytes Increasing Buffer Total Bytes Increasing. Prometheus [Fluentd] High Slow Flush Ratio High Slow Flush Ratio. Prometheus [Fluentd] No Output Records From Plugin No Output Records From Plugin. Prometheus List of DashboardsFluentdThe dashboard provides information on the status of Fluentd. List of Metrics Metric name fluentd_input_status_num_records_total fluentd_output_status_buffer_available_space_ratio fluentd_output_status_buffer_queue_length fluentd_output_status_buffer_total_bytes fluentd_output_status_emit_count fluentd_output_status_emit_records fluentd_output_status_flush_time_count fluentd_output_status_num_errors fluentd_output_status_retry_count fluentd_output_status_retry_wait fluentd_output_status_rollback_count fluentd_output_status_slow_flush_count PrerequisitesOpenShiftIf you have installed Fluentd using the OpenShift Logging Operator, no further action is required to enable monitoring.\nKubernetesEnable Prometheus MetricsFor Fluentd to expose Prometheus metrics, enable the following plugins:\n\u0026lsquo;prometheus\u0026rsquo; input plugin \u0026lsquo;prometheus_monitor\u0026rsquo; input plugin \u0026lsquo;prometheus_output_monitor\u0026rsquo; input plugin As seen in the official plugin documentation, you can enable them with the following configurations:\n\u0026lt;source\u0026gt; @type prometheus @id in_prometheus bind \u0026#34;0.0.0.0\u0026#34; port 24231 metrics_path \u0026#34;/metrics\u0026#34; \u0026lt;/source\u0026gt; \u0026lt;source\u0026gt; @type prometheus_monitor @id in_prometheus_monitor \u0026lt;/source\u0026gt; \u0026lt;source\u0026gt; @type prometheus_output_monitor @id in_prometheus_output_monitor \u0026lt;/source\u0026gt; If you are deploying Fluentd using the official Helm chart, it already has these plugins enabled by default in its configuration, so no additional actions are needed.\nInstallationInstalling an exporter is not required for this integration.\nRelated Blog Posts How to monitor and troubleshoot Fluentd with Prometheus Agent ConfigurationThe default agent jobs for this integration are as follows:\n- job_name: \u0026#39;fluentd-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (fluentd);(.{0}$) replacement: fluentd target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;fluentd\u0026#34; - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - action: replace source_labels: - __name__ - tag regex: fluentd_input_status_num_records_total;kubernetes.var.log.containers.([a-zA-Z0-9 \\d\\.-]+)_([a-zA-Z0-9 \\d\\.-]+)_([a-zA-Z0-9 \\d\\.-]+)-[a-zA-Z0-9]+.log target_label: input_pod replacement: $1 - action: replace source_labels: - __name__ - tag regex: fluentd_input_status_num_records_total;kubernetes.var.log.containers.([a-zA-Z0-9 \\d\\.-]+)_([a-zA-Z0-9 \\d\\.-]+)_([a-zA-Z0-9 \\d\\.-]+)-[a-zA-Z0-9]+.log target_label: input_namespace replacement: $2 - action: replace source_labels: - __name__ - tag regex: fluentd_input_status_num_records_total;kubernetes.var.log.containers.([a-zA-Z0-9 \\d\\.-]+)_([a-zA-Z0-9 \\d\\.-]+)_([a-zA-Z0-9 \\d\\.-]+)-[a-zA-Z0-9]+.log target_label: input_container replacement: $3 - job_name: openshift-fluentd-default scheme: https bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (collector);(.{0}$) replacement: collector target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;collector\u0026#34; - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (fluentd_output_status_buffer_available_space_ratio|fluentd_output_status_buffer_queue_length|fluentd_output_status_buffer_total_bytes|fluentd_output_status_emit_count|fluentd_output_status_emit_records|fluentd_output_status_flush_time_count|fluentd_output_status_num_errors|fluentd_output_status_retry_count|fluentd_output_status_retry_wait|fluentd_output_status_rollback_count|fluentd_output_status_slow_flush_count) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/fluentd/"},{"id":473,"title":"GCP Cloud MySQL","content":" You can enable this integration using the Connect a GCP Account option on the Monitor UI.\nThis integration has 33 metrics.\nList of Alerts Alert Description Format [GCP Cloud MySQL] Database Down The MySQL database is down. Prometheus [GCP Cloud MySQL] No High Availability The MySQL database doesn\u0026rsquo;t have \u0026lsquo;High Availability\u0026rsquo; enabled, or there are no available instances in other zones for automatic failover. The service will be down when the instance undergoes maintenance or has any other issues. Prometheus [GCP Cloud MySQL] High CPU Usage The CPU usage is reaching the limit. Prometheus [GCP Cloud MySQL] High Memory Usage The memory usage is reaching the limit. Prometheus [GCP Cloud MySQL] Disk Full in 48h The disk will be full in 48 hours. Prometheus [GCP Cloud MySQL] Disk Full in 12h The disk will be full in 12 hours. Prometheus [GCP Cloud MySQL] Replica Lag The MySQL replica is lagging behind its primary instance. This issue is only applicable to replicas. Prometheus [GCP Cloud MySQL] Network Lag The time taken from primary binary log to IO thread on replica is high. This issue is only applicable to replicas. Prometheus [GCP Cloud MySQL] Slave SQL Thread Not Running The MySQL Slave SQL thread is not running. This is only applicable to replicas. Prometheus [GCP Cloud MySQL] Slave IO Thread Not Running The MySQL Slave IO thread is not running. This issue is only applicable to replicas. Prometheus [GCP Cloud MySQL] High Buffer Pool Dirty Pages Ratio The buffer pool dirty pages ratio is high. Prometheus List of DashboardsGCP Cloud MySQLThe dashboard provides information on the GCP Cloud MySQL integration. List of Metrics Metric name gcp_cloudsql_database_database_auto_failover_request_count gcp_cloudsql_database_database_available_for_failover gcp_cloudsql_database_database_cpu_utilization gcp_cloudsql_database_database_disk_bytes_used_by_data_type gcp_cloudsql_database_database_disk_read_ops_count gcp_cloudsql_database_database_disk_utilization gcp_cloudsql_database_database_disk_write_ops_count gcp_cloudsql_database_database_instance_state gcp_cloudsql_database_database_memory_utilization gcp_cloudsql_database_database_mysql_innodb_buffer_pool_pages_dirty gcp_cloudsql_database_database_mysql_innodb_buffer_pool_pages_free gcp_cloudsql_database_database_mysql_innodb_buffer_pool_pages_total gcp_cloudsql_database_database_mysql_innodb_data_fsyncs gcp_cloudsql_database_database_mysql_innodb_os_log_fsyncs gcp_cloudsql_database_database_mysql_innodb_pages_read gcp_cloudsql_database_database_mysql_innodb_pages_written gcp_cloudsql_database_database_mysql_queries gcp_cloudsql_database_database_mysql_questions gcp_cloudsql_database_database_mysql_received_bytes_count gcp_cloudsql_database_database_mysql_replication_last_io_errno gcp_cloudsql_database_database_mysql_replication_last_sql_errno gcp_cloudsql_database_database_mysql_replication_seconds_behind_master gcp_cloudsql_database_database_mysql_replication_slave_io_running_state gcp_cloudsql_database_database_mysql_replication_slave_sql_running_state gcp_cloudsql_database_database_mysql_sent_bytes_count gcp_cloudsql_database_database_network_connections gcp_cloudsql_database_database_network_received_bytes_count gcp_cloudsql_database_database_network_sent_bytes_count gcp_cloudsql_database_database_replication_network_lag gcp_cloudsql_database_database_replication_replica_lag gcp_cloudsql_database_database_replication_state gcp_cloudsql_database_database_up gcp_cloudsql_database_database_uptime Monitoring and Troubleshooting GCP Cloud MySQLThis document describes important metrics and queries that you can use to monitor and troubleshoot GCP Cloud MySQL.\nMost of the metrics covered in this document are applicable to all the GCP Cloud SQL integrations (MySQL, PostgreSQL, SQL Server). There is a separate section for MySQL metrics.\nThe GCP metrics of type DELTA, which typically have the suffix _count in their name (but not always), return the cumulative value of 1 minute. They need to be divided by 60 to get the value per second.\nStatus and ReplicationStatusUse the following query to get the status of the database. A value of 1 means UP, and a value of 0 means DOWN.\ngcp_cloudsql_database_database_up Use the following query to get the current serving state of the Cloud SQL instance. The state is stored inside the label state.\ngcp_cloudsql_database_database_instance_state \u0026gt; 0 The state can be one of the following:\nRUNNING: The instance is expected to be running. If an instance experiences unplanned (non-maintenance) downtime, the state will still be RUNNING, but the Database UP metric will report 0. SUSPENDED: The instance is not available, for example, due to problems with billing. RUNNABLE: The instance has been stopped by the owner. It is not currently running but is ready to be restarted. PENDING_CREATE: The instance is being created. MAINTENANCE: The instance is down for maintenance. FAILED: The instance creation failed. UNKNOWN_STATE: The state of the instance is unknown. ReplicationFailoverThe following query returns a value \u0026gt; 0 if the failover operation is available on the instance.\ngcp_cloudsql_database_database_available_for_failover Use the following query to get the number of instance auto-failover requests per second.\ngcp_cloudsql_database_database_auto_failover_request_count / 60 StateUse the following query to get the current serving state of replication. The state is stored inside the label state. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_replication_state \u0026gt; 0 The state can be one of the following:\nRUNNING: Replication is active and running. STOPPED: Replication is inactive and stopped. ERROR: An error has occurred and replication is stopped. SYNCING: The replication is syncing. UNSYNCED: The replication is unsynced. Replica and Network LagUse the following query to get the approximate number of seconds the read replica is behind its primary instance. This is only applicable to replicas.\ngcp_cloudsql_database_database_replication_replica_lag The following query indicates time taken from primary binary log to IO thread on replica. This is only applicable to replicas.\ngcp_cloudsql_database_database_replication_network_lag CPU, Memory and StorageCPUUse the following query to get the current CPU utilization represented as a percentage of the reserved CPU that is currently in use. The return values are typically numbers between 0 and 1 (but might exceed 1).\ngcp_cloudsql_database_database_cpu_utilization MemoryUse the following query to get the percentage of the memory quota that is currently in use. The return values are numbers between 0 and 1.\ngcp_cloudsql_database_database_memory_utilization DiskUse the following query to get the percentage of the disk quota that is currently in use. The return values are numbers between 0 and 1.\ngcp_cloudsql_database_database_disk_utilization Use the following query to get the disk usage per data type. The data type is stored inside the label data_type. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_disk_bytes_used_by_data_type Use the following queries to get the disk read and write IO operations per second.\ngcp_cloudsql_database_database_disk_read_ops_count / 60 gcp_cloudsql_database_database_disk_write_ops_count / 60 NetworkUse the following query to get the number of connections to databases on the Cloud SQL instance. This is only applicable to MySQL and SQL Servers.\ngcp_cloudsql_database_database_network_connections Use the following queries to get the bytes received and sent through the network per second.\ngcp_cloudsql_database_database_network_received_bytes_count / 60 gcp_cloudsql_database_database_network_sent_bytes_count / 60 MySQL StatsInnoDBPagesUse the following query to get the number of InnoDB pages read per second.\ngcp_cloudsql_database_database_mysql_innodb_pages_read / 60 Use the following query to get the number of InnoDB pages written per second.\ngcp_cloudsql_database_database_mysql_innodb_pages_written / 60 Fsync() CallsUse the following query to get the number of InnoDB fsync() calls per second.\ngcp_cloudsql_database_database_mysql_innodb_data_fsyncs / 60 Use the following query to get the number of InnoDB fsync() calls to the log file per second.\ngcp_cloudsql_database_database_mysql_innodb_os_log_fsyncs / 60 Buffer Pool PagesUse the following query to get the number of unflushed pages in the InnoDB buffer pool.\ngcp_cloudsql_database_database_mysql_innodb_buffer_pool_pages_dirty Use the following query to get the number of unused pages in the InnoDB buffer pool.\ngcp_cloudsql_database_database_mysql_innodb_buffer_pool_pages_free Using the metric for the total number of pages, you can calculate the buffer pool dirty pages ratio.\ngcp_cloudsql_database_database_mysql_innodb_buffer_pool_pages_dirty / gcp_cloudsql_database_database_mysql_innodb_buffer_pool_pages_total Queries and NetworkUse the following query to get the number of statements executed by the server sent by the client per second.\ngcp_cloudsql_database_database_mysql_questions / 60 Use the following query to get the number of statements executed by the server per second.\ngcp_cloudsql_database_database_mysql_queries / 60 Use the following queries to get the bytes received and sent by MySQL process per second.\ngcp_cloudsql_database_database_mysql_received_bytes_count / 60 gcp_cloudsql_database_database_mysql_sent_bytes_count / 60 ReplicationLagUse the following query to get the approximate number of seconds the read replica is lagging behind its primary instance.\ngcp_cloudsql_database_database_mysql_replication_seconds_behind_master Threads StateThe following query returns a value that indicates whether the SQL thread for executing events in the relay log is running. The possible values inside the state label are Yes and No.\ngcp_cloudsql_database_database_mysql_replication_slave_sql_running_state \u0026gt; 0 The following query returns a value that indicates whether the I/O thread for reading the primary binary log is running. The possible values inside the state label are Yes, No and Connecting.\ngcp_cloudsql_database_database_mysql_replication_slave_io_running_state \u0026gt; 0 Error NumbersUse the following query to get the error number of the most recent error that caused the SQL thread to stop.\ngcp_cloudsql_database_database_mysql_replication_last_sql_errno Use the following query to get the error number of the most recent error that caused the I/O thread to stop.\ngcp_cloudsql_database_database_mysql_replication_last_io_errno ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/gcp-cloud-mysql/"},{"id":474,"title":"GCP Cloud PostgreSQL","content":" You can enable this integration using the Connect a GCP Account option on the Monitor UI.\nThis integration has 32 metrics.\nList of Alerts Alert Description Format [GCP Cloud PostgreSQL] Database Down The PostgreSQL database is down. Prometheus [GCP Cloud PostgreSQL] No High Availability The PostgreSQL database doesn\u0026rsquo;t have \u0026lsquo;High Availability\u0026rsquo; enabled, or there are no available instances in other zones for automatic failover. The service will be down when the instance undergoes maintenance or has any other issues. Prometheus [GCP Cloud PostgreSQL] High CPU Usage The CPU usage is reaching the limit. Prometheus [GCP Cloud PostgreSQL] High Memory Usage The memory usage is reaching the limit. Prometheus [GCP Cloud PostgreSQL] Disk Full in 48h The disk will be full in 48 hours. Prometheus [GCP Cloud PostgreSQL] Disk Full in 12h The disk will be full in 12 hours. Prometheus [GCP Cloud PostgreSQL] Replica Lag The PostgreSQL replica is lagging behind its primary instance. This issue is only applicable to replicas. Prometheus [GCP Cloud PostgreSQL] Network Lag The time taken from primary binary log to IO thread on replica is high. This issue is only applicable to replicas. Prometheus [GCP Cloud PostgreSQL] Low Cache Hit Rate The cache hit rate is low. Prometheus [GCP Cloud PostgreSQL] DeadLocks In Database Deadlocks detected in database. Prometheus [GCP Cloud PostgreSQL] High Transaction ID Usage The transaction ID usage is reaching the limit. Prometheus List of DashboardsGCP Cloud PostgreSQLThe dashboard provides information on the GCP Cloud PostgreSQL integration. List of Metrics Metric name gcp_cloudsql_database_database_auto_failover_request_count gcp_cloudsql_database_database_available_for_failover gcp_cloudsql_database_database_cpu_utilization gcp_cloudsql_database_database_disk_bytes_used_by_data_type gcp_cloudsql_database_database_disk_read_ops_count gcp_cloudsql_database_database_disk_utilization gcp_cloudsql_database_database_disk_write_ops_count gcp_cloudsql_database_database_instance_state gcp_cloudsql_database_database_memory_utilization gcp_cloudsql_database_database_network_received_bytes_count gcp_cloudsql_database_database_network_sent_bytes_count gcp_cloudsql_database_database_postgresql_blocks_read_count gcp_cloudsql_database_database_postgresql_deadlock_count gcp_cloudsql_database_database_postgresql_num_backends gcp_cloudsql_database_database_postgresql_num_backends_by_application gcp_cloudsql_database_database_postgresql_num_backends_by_state gcp_cloudsql_database_database_postgresql_replication_replica_byte_lag gcp_cloudsql_database_database_postgresql_temp_bytes_written_count gcp_cloudsql_database_database_postgresql_temp_files_written_count gcp_cloudsql_database_database_postgresql_transaction_count gcp_cloudsql_database_database_postgresql_transaction_id_count gcp_cloudsql_database_database_postgresql_transaction_id_utilization gcp_cloudsql_database_database_postgresql_tuple_size gcp_cloudsql_database_database_postgresql_tuples_fetched_count gcp_cloudsql_database_database_postgresql_tuples_processed_count gcp_cloudsql_database_database_postgresql_tuples_returned_count gcp_cloudsql_database_database_postgresql_vacuum_oldest_transaction_age gcp_cloudsql_database_database_replication_network_lag gcp_cloudsql_database_database_replication_replica_lag gcp_cloudsql_database_database_replication_state gcp_cloudsql_database_database_up gcp_cloudsql_database_database_uptime Monitoring and Troubleshooting GCP Cloud PostgreSQLThis document describes important metrics and queries that you can use to monitor and troubleshoot GCP Cloud PostgreSQL.\nMost of the metrics covered in this document are applicable to all the GCP Cloud SQL integrations (MySQL, PostgreSQL, SQL Server). There is a separate section for MySQL metrics.\nThe GCP metrics of type DELTA, which typically have the suffix _count in their name (but not always), return the cumulative value of 1 minute. They need to be divided by 60 to get the value per second.\nStatus and ReplicationStatusUse the following query to get the status of the database. A value of 1 means UP, and a value of 0 means DOWN.\ngcp_cloudsql_database_database_up Use the following query to get the current serving state of the Cloud SQL instance. The state is stored inside the label state.\ngcp_cloudsql_database_database_instance_state \u0026gt; 0 The state can be one of the following:\nRUNNING: The instance is expected to be running. If an instance experiences unplanned (non-maintenance) downtime, the state will still be RUNNING, but the Database UP metric will report 0. SUSPENDED: The instance is not available, for example, due to problems with billing. RUNNABLE: The instance has been stopped by the owner. It is not currently running but is ready to be restarted. PENDING_CREATE: The instance is being created. MAINTENANCE: The instance is down for maintenance. FAILED: The instance creation failed. UNKNOWN_STATE: The state of the instance is unknown. ReplicationFailoverThe following query returns a value \u0026gt; 0 if the failover operation is available on the instance.\ngcp_cloudsql_database_database_available_for_failover Use the following query to get the number of instance auto-failover requests per second.\ngcp_cloudsql_database_database_auto_failover_request_count / 60 StateUse the following query to get the current serving state of replication. The state is stored inside the label state. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_replication_state \u0026gt; 0 The state can be one of the following:\nRUNNING: Replication is active and running. STOPPED: Replication is inactive and stopped. ERROR: An error has occurred and replication is stopped. SYNCING: The replication is syncing. UNSYNCED: The replication is unsynced. Replica and Network LagUse the following query to get the approximate number of seconds the read replica is behind its primary instance. This is only applicable to replicas.\ngcp_cloudsql_database_database_replication_replica_lag The following query indicates time taken from primary binary log to IO thread on replica. This is only applicable to replicas.\ngcp_cloudsql_database_database_replication_network_lag CPU, Memory and StorageCPUUse the following query to get the current CPU utilization represented as a percentage of the reserved CPU that is currently in use. The return values are typically numbers between 0 and 1 (but might exceed 1).\ngcp_cloudsql_database_database_cpu_utilization MemoryUse the following query to get the percentage of the memory quota that is currently in use. The return values are numbers between 0 and 1.\ngcp_cloudsql_database_database_memory_utilization DiskUse the following query to get the percentage of the disk quota that is currently in use. The return values are numbers between 0 and 1.\ngcp_cloudsql_database_database_disk_utilization Use the following query to get the disk usage per data type. The data type is stored inside the label data_type. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_disk_bytes_used_by_data_type Use the following queries to get the disk read and write IO operations per second.\ngcp_cloudsql_database_database_disk_read_ops_count / 60 gcp_cloudsql_database_database_disk_write_ops_count / 60 NetworkUse the following queries to get the bytes received and sent through the network per second.\ngcp_cloudsql_database_database_network_received_bytes_count / 60 gcp_cloudsql_database_database_network_sent_bytes_count / 60 PostgreSQL StatsBackendsUse the following query to get the number of connections to the Cloud SQL PostgreSQL instance.\ngcp_cloudsql_database_database_postgresql_num_backends Use the following query to get the number of connections to the Cloud SQL PostgreSQL instance, grouped by its state. The possible values inside the state label are idle, active, idle_in_transaction, idle_in_transaction_aborted, disabled or fastpath_function_call. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_postgresql_num_backends_by_state Use the following query to get the number of connections to the Cloud SQL PostgreSQL instance, grouped by applications. The application is stored inside the label application.\ngcp_cloudsql_database_database_postgresql_num_backends_by_application TransactionsUse the following query to get the number of transactions per second. The transaction type is stored inside the label transaction_type.\ngcp_cloudsql_database_database_postgresql_transaction_count / 60 Use the following query to get the number of transaction IDs per second. The possible values inside the action label are assigned or frozen. assigned indicates the number of transaction IDs assigned and consumed by the instance, whereas frozen indicates the count of transaction IDs replenished by the VACUUM\u0026rsquo;s freeze operation.\ngcp_cloudsql_database_database_postgresql_transaction_id_count / 60 Use the following query to get the current utilization represented as a percentage of transaction IDs consumed by the Cloud SQL PostgreSQL instance. Values are numbers between 0 and 1.\ngcp_cloudsql_database_database_postgresql_transaction_id_utilization Use the following query to get the age of the oldest transaction yet to be vacuumed in the Cloud SQL PostgreSQL instance. The metric is measured as the number of transactions that have happened since the oldest transaction. The possible values of the oldest_transaction_type label are running, prepared, replication_slot and replica.\ngcp_cloudsql_database_database_postgresql_vacuum_oldest_transaction_age TuplesUse the following query to get the number of tuples (rows) in the database. The possible values inside the tuple_state label are live or dead. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_postgresql_tuple_size Use the following query to get the number of tuples(rows) processed per second for a given database for operations like insert, update, or delete. The operation type is stored inside the label operation_type. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_postgresql_tuples_processed_count / 60 Use the following query to get the total number of rows fetched per second as a result of queries per database in the PostgreSQL instance.\ngcp_cloudsql_database_database_postgresql_tuples_fetched_count / 60 Use the following query to get the total number of rows scanned per second while processing the queries per database in the PostgreSQL instance.\ngcp_cloudsql_database_database_postgresql_tuples_returned_count / 60 Disk Read, Deadlocks and ReplicationDisk ReadUse the following query to get the number of disk blocks read by this database per second. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_postgresql_blocks_read_count{source=\u0026#34;disk\u0026#34;} / 60 Use the following query to get the number of reads from buffer cache by this database per second. According to the GCP documentation, this metric is in BETA launch stage.\ngcp_cloudsql_database_database_postgresql_blocks_read_count{source=\u0026#34;buffer_cache\u0026#34;} / 60 Using the two previous metrics, calculate the hit cache ratio with the following query.\ngcp_cloudsql_database_database_postgresql_blocks_read_count{source=\u0026#34;buffer_cache\u0026#34;} / (gcp_cloudsql_database_database_postgresql_blocks_read_count{source=\u0026#34;buffer_cache\u0026#34;} + ignoring(source) gcp_cloudsql_database_database_postgresql_blocks_read_count{source=\u0026#34;disk\u0026#34;}) Use the following query to get the total amount of data in bytes written per second to temporary files by the queries per database.\ngcp_cloudsql_database_database_postgresql_temp_bytes_written_count / 60 Use the following query to get the total number of temporary files used per second for writing data while performing algorithms such as join and sort.\ngcp_cloudsql_database_database_postgresql_temp_files_written_count / 60 DeadlocksUse the following query to get the number of deadlocks detected per second for this database. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_postgresql_deadlock_count / 60 ReplicationUse the following query to get the Replication lag in bytes. Reported from the master per replica. The possible values of the replica_lag_type label are replay_location, flush_location, write_location, and sent_location.\ngcp_cloudsql_database_database_postgresql_replication_replica_byte_lag ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/gcp-cloud-postgresql/"},{"id":475,"title":"GCP Cloud SQL Server","content":" You can enable this integration using the Connect a GCP Account option on the Monitor UI.\nThis integration has 19 metrics.\nList of Alerts Alert Description Format [GCP Cloud SQL Server] Database Down The SQL Server database is down. Prometheus [GCP Cloud SQL Server] No High Availability The SQL Server database doesn\u0026rsquo;t have \u0026lsquo;High Availability\u0026rsquo; enabled, or there are no available instances in other zones for automatic failover. The service will be down when the instance undergoes maintenance or has any other issues. Prometheus [GCP Cloud SQL Server] High CPU Usage The CPU usage is reaching the limit. Prometheus [GCP Cloud SQL Server] High Memory Usage The memory usage is reaching the limit. Prometheus [GCP Cloud SQL Server] Disk Full in 48h The disk will be full in 48 hours. Prometheus [GCP Cloud SQL Server] Disk Full in 12h The disk will be full in 12 hours. Prometheus [GCP Cloud SQL Server] Replica Lag The SQL Server replica is lagging behind its primary instance. This issue is only applicable to replicas. Prometheus [GCP Cloud SQL Server] Network Lag The time taken from primary binary log to IO thread on replica is high. This issue is only applicable to replicas. Prometheus List of DashboardsGCP Cloud SQL ServerThe dashboard provides information on the GCP Cloud SQL Server integration. List of Metrics Metric name gcp_cloudsql_database_database_auto_failover_request_count gcp_cloudsql_database_database_available_for_failover gcp_cloudsql_database_database_cpu_utilization gcp_cloudsql_database_database_disk_bytes_used_by_data_type gcp_cloudsql_database_database_disk_read_ops_count gcp_cloudsql_database_database_disk_utilization gcp_cloudsql_database_database_disk_write_ops_count gcp_cloudsql_database_database_instance_state gcp_cloudsql_database_database_memory_utilization gcp_cloudsql_database_database_network_connections gcp_cloudsql_database_database_network_received_bytes_count gcp_cloudsql_database_database_network_sent_bytes_count gcp_cloudsql_database_database_replication_network_lag gcp_cloudsql_database_database_replication_replica_lag gcp_cloudsql_database_database_replication_state gcp_cloudsql_database_database_sqlserver_audits_size gcp_cloudsql_database_database_sqlserver_audits_upload_count gcp_cloudsql_database_database_up gcp_cloudsql_database_database_uptime Monitoring and Troubleshooting GCP Cloud SQL ServerThis document describes important metrics and queries that you can use to monitor and troubleshoot GCP Cloud SQL Server.\nMost of the metrics covered in this document are applicable to all the GCP Cloud SQL integrations (MySQL, PostgreSQL, SQL Server). There is a separate section for MySQL metrics.\nThe GCP metrics of type DELTA, which typically have the suffix _count in their name (but not always), return the cumulative value of 1 minute. They need to be divided by 60 to get the value per second.\nStatus and ReplicationStatusUse the following query to get the status of the database. A value of 1 means UP, and a value of 0 means DOWN.\ngcp_cloudsql_database_database_up Use the following query to get the current serving state of the Cloud SQL instance. The state is stored inside the label state.\ngcp_cloudsql_database_database_instance_state \u0026gt; 0 The state can be one of the following:\nRUNNING: The instance is expected to be running. If an instance experiences unplanned (non-maintenance) downtime, the state will still be RUNNING, but the Database UP metric will report 0. SUSPENDED: The instance is not available, for example, due to problems with billing. RUNNABLE: The instance has been stopped by the owner. It is not currently running but is ready to be restarted. PENDING_CREATE: The instance is being created. MAINTENANCE: The instance is down for maintenance. FAILED: The instance creation failed. UNKNOWN_STATE: The state of the instance is unknown. ReplicationFailoverThe following query returns a value \u0026gt; 0 if the failover operation is available on the instance.\ngcp_cloudsql_database_database_available_for_failover Use the following query to get the number of instance auto-failover requests per second.\ngcp_cloudsql_database_database_auto_failover_request_count / 60 StateUse the following query to get the current serving state of replication. The state is stored inside the label state. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_replication_state \u0026gt; 0 The state can be one of the following:\nRUNNING: Replication is active and running. STOPPED: Replication is inactive and stopped. ERROR: An error has occurred and replication is stopped. SYNCING: The replication is syncing. UNSYNCED: The replication is unsynced. Replica and Network LagUse the following query to get the approximate number of seconds the read replica is behind its primary instance. This is only applicable to replicas.\ngcp_cloudsql_database_database_replication_replica_lag The following query indicates time taken from primary binary log to IO thread on replica. This is only applicable to replicas.\ngcp_cloudsql_database_database_replication_network_lag CPU, Memory and StorageCPUUse the following query to get the current CPU utilization represented as a percentage of the reserved CPU that is currently in use. The return values are typically numbers between 0 and 1 (but might exceed 1).\ngcp_cloudsql_database_database_cpu_utilization MemoryUse the following query to get the percentage of the memory quota that is currently in use. The return values are numbers between 0 and 1.\ngcp_cloudsql_database_database_memory_utilization DiskUse the following query to get the percentage of the disk quota that is currently in use. The return values are numbers between 0 and 1.\ngcp_cloudsql_database_database_disk_utilization Use the following query to get the disk usage per data type. The data type is stored inside the label data_type. According to the GCP documentation, this metric is in the BETA launch stage.\ngcp_cloudsql_database_database_disk_bytes_used_by_data_type Use the following queries to get the disk read and write IO operations per second.\ngcp_cloudsql_database_database_disk_read_ops_count / 60 gcp_cloudsql_database_database_disk_write_ops_count / 60 NetworkUse the following query to get the number of connections to databases on the Cloud SQL instance. This is only applicable to MySQL and SQL Servers.\ngcp_cloudsql_database_database_network_connections Use the following queries to get the bytes received and sent through the network per second.\ngcp_cloudsql_database_database_network_received_bytes_count / 60 gcp_cloudsql_database_database_network_sent_bytes_count / 60 SQL Server StatsAuditsUse the following query to get the total number of SQLServer audit file uploads per second to a GCS bucket and whether or not an upload was successful. The upload status is stored inside the label upload_status.\ngcp_cloudsql_database_database_sqlserver_audits_upload_count / 60 The following query tracks the size in bytes of stored SQLServer audit files on an instance.\ngcp_cloudsql_database_database_sqlserver_audits_size ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/gcp-cloud-sql-server/"},{"id":476,"title":"GCP Compute Engine","content":" You can enable this integration using the Connect a GCP Account option on the Monitor UI.\nThis integration has 11 metrics.\nList of Alerts Alert Description Format [GCP Compute Engine] High CPU Usage The CPU of the GCP Compute Engine is over 95%. Prometheus [GCP Compute Engine] High Memory Usage The Memory of the GCP Compute Engine is over 95%. Prometheus [GCP Compute Engine] Disk Partition Almost Full A disk partition of the GCP Compute Engine is over 80%. Prometheus List of DashboardsGCP Compute EngineThe dashboard provides information on the GCP Compute Engine integration.\nList of Metrics Metric name gcp_gce_instance_disk_percent_used gcp_gce_instance_instance_cpu_reserved_cores gcp_gce_instance_instance_cpu_utilization gcp_gce_instance_instance_disk_read_bytes_count gcp_gce_instance_instance_disk_read_ops_count gcp_gce_instance_instance_disk_write_bytes_count gcp_gce_instance_instance_disk_write_ops_count gcp_gce_instance_instance_memory_balloon_ram_size gcp_gce_instance_instance_memory_balloon_ram_used gcp_gce_instance_instance_network_received_bytes_count gcp_gce_instance_instance_network_sent_bytes_count Monitoring and Troubleshooting GCP Cloud Compute EngineThis document describes important metrics and queries that you can use to monitor and troubleshoot GCP Cloud Compute Engine.\nThe GCP metrics of type DELTA, which typically have the suffix _count in their name (but not always), return the cumulative value of 1 minute. They need to be divided by 60 to get the value per second.\nPlease, note that you need to install the Cloud Monitoring Agent in the Compute Engine instances you need to monitor.\nCPUUse the following query to get the current CPU utilization represented as a percentage of the reserved CPU that is currently in use. The return values are typically numbers between 0 and 1 (but might exceed 1).\ngcp_gce_instance_instance_cpu_utilization MemoryUse the following query to get the percentage of the memory quota that is currently in use. The return values are numbers between 0 and 1.\ngcp_gce_instance_instance_memory_balloon_ram_used / gcp_gce_instance_instance_memory_balloon_ram_size DiskUse the following query to get the percentage of the disk quota that is currently in use. The return values are numbers between 0 and 1.\ngcp_gce_instance_disk_percent_used{state=\u0026#34;used\u0026#34;} Use the following queries to get the disk read and write IO operations per second.\ngcp_gce_instance_instance_disk_read_ops_count / 60 gcp_gce_instance_instance_disk_write_ops_count / 60 NetworkUse the following query to get the number of connections to databases on the Cloud Compute Engine instance.\ngcp_gce_instance_vm_flow_connection_count Use the following queries to get the bytes received and sent through the network per second.\ngcp_gce_instance_instance_network_received_bytes_count / 60 gcp_gce_instance_instance_network_sent_bytes_count / 60 ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/gcp-compute-engine/"},{"id":477,"title":"GCP Memorystore for Redis","content":" You can enable this integration using the Connect a GCP Account option on the Monitor UI.\nThis integration has 32 metrics.\nList of Alerts Alert Description Format [GCP Memorystore Redis] Low UpTime Uptime is less than 1 hour in a Memorystore Redis instance. Prometheus [GCP Memorystore Redis] High Memory Usage High memory usage in a redis instance. Prometheus [GCP Memorystore Redis] High Number Of Connected Clients Higher client connection count on a Memorystore Redis instance. Prometheus [GCP Memorystore Redis] Recurrent Rejected Connections The number of recurring rejected connections on a Memorystore Redis instance. Prometheus [GCP Memorystore Redis] Low Cache Hit Ratio The cache hit ratio is low in a Memorystore Redis instance. Prometheus [GCP Memorystore Redis] RDB Snapshot Error Status The last RDB Snapshot status is Error. Prometheus List of DashboardsGCP Memorystore RedisThe dashboard provides information on the GCP Memorystore for Redis integration. List of Metrics Metric name gcp_redis_instance_clients_blocked gcp_redis_instance_clients_connected gcp_redis_instance_commands_calls gcp_redis_instance_keyspace_avg_ttl gcp_redis_instance_keyspace_keys gcp_redis_instance_keyspace_keys_with_expiration gcp_redis_instance_rdb_enabled gcp_redis_instance_rdb_recovery_attempts_since_last_success gcp_redis_instance_rdb_recovery_estimated_remaining_time gcp_redis_instance_rdb_recovery_in_progress gcp_redis_instance_rdb_snapshot_in_progress gcp_redis_instance_rdb_snapshot_last_status gcp_redis_instance_rdb_snapshot_last_success_age gcp_redis_instance_rdb_snapshot_last_success_duration gcp_redis_instance_rdb_snapshot_time_until_next_run gcp_redis_instance_replication_master_repl_offset gcp_redis_instance_replication_master_slaves_lag gcp_redis_instance_replication_master_slaves_offset gcp_redis_instance_replication_offset_diff gcp_redis_instance_server_uptime gcp_redis_instance_stats_cache_hit_ratio gcp_redis_instance_stats_cpu_utilization gcp_redis_instance_stats_evicted_keys gcp_redis_instance_stats_expired_keys gcp_redis_instance_stats_keyspace_hits gcp_redis_instance_stats_keyspace_misses gcp_redis_instance_stats_memory_maxmemory gcp_redis_instance_stats_memory_usage gcp_redis_instance_stats_network_traffic gcp_redis_instance_stats_pubsub_channels gcp_redis_instance_stats_pubsub_patterns gcp_redis_instance_stats_reject_connections_count Monitoring and Troubleshooting Google Cloud Memorystore RedisThis document describes important metrics and queries that you can use to monitor and troubleshoot GCP Memorystore Redis.\nThe GCP metrics of type DELTA, which typically have the suffix _count in their name (but not always), return the cumulative value of 1 minute. They need to be divided by 60 to get the value per second.\nInstanceInstance StatusUse the following query to check if your instance was rebooted recently:\ngcp_redis_instance_server_uptime A return value less than 3600 indicates that the instance was restarted in the last hour.\nMemory UsageUse the following query to get the memory usage of your instance:\n100 * (gcp_redis_instance_stats_memory_usage / gcp_redis_instance_stats_memory_maxmemory) CPU SecondsUse the following query to get the CPU-seconds consumed by the redis server:\ngcp_redis_instance_stats_cpu_utilization / 60 Keys / CacheNumber of KeysUse the following query to get the number of keys in an instance:\ngcp_redis_instance_keyspace_keys Expired KeysUse the following query to get the number of expired keys in your instance:\ngcp_redis_instance_stats_expired_keys / 60 Evicted KeysUse the following query to get the number of evicted keys in your instance:\ngcp_redis_instance_stats_evicted_keys / 60 Cache Hit RatioUse the following query to get the cache hit ratio percentage:\ngcp_redis_instance_stats_cache_hit_ratio The returned value should be above 0.85. A ratio below 0.8 indicates that a high number of keys have expired/been evicted. Check for instance memory.\nNetwork / ConnectionsConnected ClientsUse the following query to get the number of connected clients:\ngcp_redis_instance_clients_connected Blocked ClientsUse the following query to get the number of blocked clients:\ngcp_redis_instance_clients_blocked Rejected ConnectionsUse the following query to get the number of rejected connections per second:\ngcp_redis_instance_stats_reject_connections_count / 60 A return value other than 0 means that maxclients limit has been reached. The default value of maxclients is 65000.\nReplicationPending ReplicationUse the following query to get the number of Bytes pending to be replicated:\ngcp_redis_instance_replication_offset_diff Seconds LaggingRun the following query to get the number of seconds that the replica is lagging behind the primary instance:\ngcp_redis_instance_replication_master_slaves_lag A value over 1 second indicates performance issues in the slave instances.\nPubsubPubsub channelsUse the following query to get the number of pubsub channels:\ngcp_redis_instance_stats_pubsub_channels Pubsub patternsUse the following query to get the number of pubsub patterns:\ngcp_redis_instance_stats_pubsub_patterns RDB SnapshotRDB EnabledUse the following query to get the status of the snapshot mode:\ngcp_redis_instance_rdb_enabled If the instance is in production this metric should return 1.\nSnapshot last statusUse the following query to get the status of the last snapshot:\ngcp_redis_instance_rdb_snapshot_last_status If the snapshot last status is other than 200 then there may be problems with snapshots.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/gcp-memorystore-redis/"},{"id":478,"title":"Integrate with GitLab","content":"PrerequisitesHave the following ready:\nGitLab Ultimate. A Sysdig Secure API token. See Retrieve the Sysdig API Token. The Sysdig Secure URL for your region. See SaaS regions and IP Ranges. Run in GitLabThe code below runs the Sysdig CLI Scanner, translates the output to an acceptable format, and then uploads it to GitLab.\nIn GitLab, add the following to your .gitlab-ci.yml file:\nstages: # List of stages for jobs, and their order of execution - scan - stop_on_fail # Only if you want to stop upon failed scan or scanner error container_scanning: # If your runner doesn\u0026#39;t have docker available, uncomment the following to run in a docker container and use Docker-in-docker #image: docker:20.10.16 #services: # - docker:20.10.16-dind stage: scan variables: SECURE_API_TOKEN: $SECURE_TOKEN # Your Sysdig Secure API Token SECURE_URL: https://secure.sysdig.com # Your Sysdig Secure endpoint IMAGE: nginx:1.20 # Image to scan # Optional, uncomment and provide additional parameters to the CLI scanner #EXTRA_CLI_PARAMS: --override-pullstring=myimage --console-log STOP_ON_FAIL: true # Stop on failed scan STOP_ON_SCANNER_FAIL: true # Stop on scanner error GITLAB_REPORT: gitlab-report.json # GitLab vulnerabilities report filename script: - touch $GITLAB_REPORT # Create the report file - docker run --env-file \u0026lt;(env) -v \u0026#34;$(pwd)\u0026#34;/${GITLAB_REPORT}:/gitlab-report.json --user $(id -u) --rm quay.io/sysdig/gitlab-scanner:latest $IMAGE || echo $? \u0026gt; scan_code allow_failure: true # Allow failure. It won\u0026#39;t upload the vuln report if this stage fails. # Check the following discussion for more info: https://gitlab.com/gitlab-org/gitlab/-/issues/241342 artifacts: paths: - scan_code # Scan result code for \u0026#39;stop_on_fail\u0026#39; stage. reports: container_scanning: $GITLAB_REPORT # Upload the report as an artifact stop_on_fail: stage: stop_on_fail dependencies: - container_scanning script: - exit $(cat scan_code || echo 0) # Fail if scan_code exists and contains value != 0 SECURE_API_TOKEN: Use your Sysdig Secure API token. SECURE_URL: Use your Sysdig Secure URL. Test the IntegrationTo test the integration:\nCreate a new project or repository in GitLab. Add a Dockerfile with a base image of known vulnerabilities. For examples of known vulnerabilities, see Vulhub. Follow the instructions in Run in GitLab. Make a merge request. GitLab will trigger the execution of the pipeline building the image, executing the scanner and generating the report automatically.\nIf you click on the report, you will see the following:\n","url":"https://docs.sysdig.com/en/sysdig-secure/gitlab-integration/"},{"id":479,"title":"Go","content":" This integration is disabled by default. Please refer to Enable and Disable Integrations to enable it in your account.\nThis integration has 27 metrics.\nList of Alerts Alert Description Format [Go] Slow Garbage Collector Garbage collector took too long. Prometheus [Go] Few Free File Descriptors Few free file descriptors. Prometheus List of DashboardsGo InternalsThe dashboard provides information on the Go integration. List of Metrics Metric name go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/go/"},{"id":480,"title":"Google Artifact Registry","content":"Prerequisites A Service Account within one of the projects is created.\nThe required Artifact Registry Reader role is assigned to that service account.\nA Custom Role with the resourcemanager.projects.get permission.\nThis permission allows the Service Account to list repositories on the Docker v2 _catalog endpoint.\nInstall Registry ScannerYou can set up the Registry Scanner either at the project level or the organization level.\nEnsure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes.\n$ helm repo add sysdig https://charts.sysdig.com $ helm repo update $ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=gar \\ --set config.registryURL=\u0026lt;GAR_REGISTRY_URL\u0026gt; \\ --set config.registryPassword=\u0026lt;GAR_REGISTRY_PASSWORD\u0026gt; \u0026lt;GAR_REGISTRY_PASSWORD\u0026gt;: Base64 encoded Service Account JSON access key.\nTo encode JSON key file to base64, use the following command:\n--set config.registryPassword=\u0026quot;$(cat \u0026lt;GAR_SA_FILE_NAME\u0026gt;.json | base64)\u0026quot;\n\u0026lt;GAR_REGISTRY_URL\u0026gt;: Google Artifact Registry URL.\nFor example, us-docker.pkg.dev\nCreate a Custom RoleCreate a Custom Role with the resourcemanager.projects.get permission. This permission allows the Service Account to list repositories on the Docker v2 _catalog endpoint.\nCreate a Custom Role at Project Levelgcloud iam roles create sysdig.repositorylist --project=\u0026lt;YOUR_PROJECT_ID\u0026gt; \\ --title=\u0026#34;Sysdig - Artifact Registry - List Repositories\u0026#34; \\ --description=\u0026#34;Sysdig - Artifact Registry - List Repositories on dockerv2 _catalog API endpoint\u0026#34; \\ --permissions=\u0026#34;resourcemanager.projects.get\u0026#34; --stage=GA gcloud projects add-iam-policy-binding \u0026lt;YOUR_PROJECT_ID\u0026gt; \\ --member=\u0026#39;serviceAccount:\u0026lt;SERVICE_ACCOUNT_NAME\u0026gt;@\u0026lt;YOUR_PROJECT_ID\u0026gt;.iam.gserviceaccount.com\u0026#39; \\ --role=\u0026#39;projects/\u0026lt;YOUR_PROJECT_ID\u0026gt;/roles/sysdig.repositorylist\u0026#39; Create a Custom Role at Organization Level gcloud iam roles create sysdig.repositorylist --organization=\u0026lt;YOUR_ORGANIZATION_ID\u0026gt; \\ --title=\u0026#34;Sysdig - Artifact Registry - List Repositories\u0026#34; \\ --description=\u0026#34;Sysdig - Artifact Registry - List Repositories on dockerv2 _catalog API endpoint\u0026#34; \\ --permissions=\u0026#34;resourcemanager.projects.get\u0026#34; --stage=GA gcloud projects add-iam-policy-binding \u0026lt;YOUR_ORGANIZATION_ID\u0026gt; \\ --member=\u0026#39;serviceAccount:\u0026lt;SERVICE_ACCOUNT_NAME\u0026gt;@\u0026lt;YOUR_PROJECT_ID\u0026gt;.iam.gserviceaccount.com\u0026#39; \\ --role=\u0026#39;organizations/\u0026lt;YOUR_ORGANIZATION_ID\u0026gt;/roles/sysdig.repositorylist\u0026#39; ","url":"https://docs.sysdig.com/en/sysdig-secure/google-registry/"},{"id":481,"title":"Grafana Integration","content":" Prometheus\nThe Prometheus data source comes with Grafana and is natively compatible with PromQL. Sysdig provides a Prometheus-compatible API to achieve API-only integration with Grafana.\nFor Grafana versions 6.7.0 or beyond, configure the datasource as given in Using the Prometheus API on Grafana v6.7 and Above.\nFor Grafana versions below 6.7.0, configure datasource as given in Using the Grafana API on Grafana v6.6 and Below.\nSysdig\nThe Sysdig data source relies on the Sysdig native API instead of the Prometheus API. It requires additional settings and is generally compatible with the simple \u0026ldquo;form-based\u0026rdquo; data configuration. See Sysdig Grafana datasource for more information.\nThe Sysdig option is only recommended for on-prem enviroments on version 5.x or lower.\nUsing the Prometheus API on Grafana v6.7 and AboveYou use the Sysdig Prometheus API to set up the datasource to use with Grafana. Before Grafana can consume Sysdig metrics, Grafana must authenticate itself to Sysdig. To do so, you must set up an HTTP authentication by using the Sysdig API Token because no UI support is currently available on Grafana.\nAssuming that you are not using Grafana, spin up a Grafana container as follows:\n$ docker run --rm -p 3000:3000 --name grafana grafana/grafana Login to Grafana as administrator and create a new datasource by using the following information:\nURL: https://\u0026lt;Monitor URL for Your Region\u0026gt;/prometheus\nSee SaaS Regions and IP Ranges and identify the correct URLs associated with your Sysdig application and region.\nAuthentication: Do not select any authentication mechanisms.\nAccess: Server (default)\nCustom HTTP Headers:\nHeader: Enter the word, Authorization\nValue: Enter the word, Bearer , followed by a space and \u0026lt;Your Sysdig API Token\u0026gt;\nAPI Token is available through Settings \u0026gt; User Profile \u0026gt; Sysdig Monitor API.\nUsing the Grafana API on Grafana v6.6 and BelowThe feature requires Grafana v5.3.0 or above.\nYou use the Grafana API to set up the Sysdig datasource.\nDownload and run Grafana in a container.\ndocker run --rm -p 3000:3000 --name grafana grafana/grafana Create a JSON file. cat grafana-stg-ds.json\n{ \u0026#34;name\u0026#34;: \u0026#34;Sysdig staging PromQL\u0026#34;, \u0026#34;orgId\u0026#34;: 1, \u0026#34;type\u0026#34;: \u0026#34;prometheus\u0026#34;, \u0026#34;access\u0026#34;: \u0026#34;proxy\u0026#34;, \u0026#34;url\u0026#34;: \u0026#34;https://app-staging.sysdigcloud.com/prometheus\u0026#34;, \u0026#34;basicAuth\u0026#34;: false, \u0026#34;withCredentials\u0026#34;: false, \u0026#34;isDefault\u0026#34;: false, \u0026#34;editable\u0026#34;: true, \u0026#34;jsonData\u0026#34;: { \u0026#34;httpHeaderName1\u0026#34;: \u0026#34;Authorization\u0026#34;, \u0026#34;tlsSkipVerify\u0026#34;: true }, \u0026#34;secureJsonData\u0026#34;: { \u0026#34;httpHeaderValue1\u0026#34;: \u0026#34;Bearer your-Sysdig-API-token\u0026#34; } } Get your Sysdig API Token and plug it in the JSON file above.\n\u0026#34;httpHeaderValue1\u0026#34;: \u0026#34;Bearer your_Sysdig_API_Token\u0026#34; Add the datasource to Grafana.\ncurl -u admin:admin -H \u0026#34;Content-Type: application/json\u0026#34; http://localhost:3000/api/datasources -XPOST -d @grafana-stg-ds.json Run Grafana.\nhttp://localhost:3000 Use the default credentials, admin: admin, to sign in to Grafana.\nOpen the Data Source tab under Configuration on Grafana and confirm that the one you have added is listed on the page.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/grafana-integration/"},{"id":482,"title":"Group Outlier Alerts","content":" Define a Group Outlier Alert Scope: The alert applies to the Entire Infrastructure of your team scope by default. However, you have the option to restrict the alert scope by filtering by specific labels, such as cloud_provider_region or kube_namespace_name.\nMetric: Select the metric the alert will evaluate. Group Outlier alert rules can only be configured for a single metric. For example, to identify if a web server is handling more HTTP requests compared to other web servers, you might use the http_requests_total metric and have the segmentation configured by hostname.\nGroup By Segment: Segmentation determines the specific entities being evaluated for outlier detection. Setting this field establishes a valid Group Outlier alert rule. For instance, when alerting on kube_pod_memory_usage, use a combination of segments like pod and node to precisely identify memory-intensive pods within particular nodes.\nObservation Window: Set a specific time frame for evaluating potential outliers. The chosen time frame greatly influences outlier detection results. For instance, a host might show high memory usage over the past hour but not when observed over the last 10 minutes. Selecting a longer observation window can help filter out short-lived outliers, reducing the chance of flagging transient fluctuations as outliers.\nMAD and DBSCAN AlgorithmsMedian Absolute Deviation (MAD)Median Absolute Deviation (MAD) is a robust method to detect outliers based on their deviation from the median. It calculates the median of the time series data for a user-specified observation window, and then determines how far each entity deviates from that median. Entities that deviate significantly from the median, based on a predefined threshold, are considered outliers.\nTolerance: Set the tolerance to decide the acceptable values from the median absolute deviation. The tolerance specifies how many times an entity can deviate from the MAD value before it\u0026rsquo;s considered an outlier. By configuring a higher tolerance, you\u0026rsquo;ll focus on detecting entities that exhibit a more pronounced deviation from the median.\nOutlier Persistence: The Outlier Persistence specifies the percentage of the observation window in which an entity\u0026rsquo;s reported value must fall outside the configured tolerance to be labeled as an outlier. It ensures that occasional blips aren\u0026rsquo;t mistakenly classified as outliers; only consistent deviations over the defined percentage of the observation window will trigger an alert.\nUse MAD to detect deviations in entities normally displaying consistent behavior.\nDensity-Based Spatial Clustering of Applications with Noise (DBSCAN)Density-Based Spatial Clustering of Applications with Noise (DBSCAN) is an algorithm that detects outliers by analyzing their proximity to other entities within a specified observation window. Unlike MAD, which evaluates outliers based on deviation from the median, DBSCAN identifies outliers by determining if they are isolated from neighboring time series.\nTolerance: In the context of DBSCAN, tolerance determines the proximity range within which an entity should find neighboring time series to be part of a group. DBSCAN focuses on grouping similar time series based on their closeness. By setting a larger tolerance, you allow for more inclusive groups, capturing a wider range of similar time series. Conversely, a smaller tolerance makes the grouping criteria stricter, leading to more individual time series being identified as outliers because they don\u0026rsquo;t fit closely enough with any established group. Unlike MAD, which evaluates if an entity consistently exceeds the tolerance over a specified percentage of time, DBSCAN evaluates spatial relations in a single snapshot, eliminating the need for a percentage-based criterion. Use DBSCAN to identify outliers in entities that typically exhibit similar trends or patterns.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/group-outlier-alerts/"},{"id":483,"title":"HAProxy Ingress","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v0.13\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 31 metrics.\nTimeseries generated: 150x number of ingress pods, 50x number of ingress pods x ingress resources\nList of Alerts Alert Description Format [Haproxy-Ingress] Uptime less than 1 hour This alert detects when all of the instances of the ingress controller have an uptime of less than 1 hour. Prometheus [Haproxy-Ingress] Frontend Down This alert detects when a frontend has all of its instances down for more than 10 minutes. Prometheus [Haproxy-Ingress] Backend Down This alert detects when a backend has all of its instances down for more than 10 minutes. Prometheus [Haproxy-Ingress] High Sessions Usage This alert triggers when the backend sessions overpass the 85% of the sessions capacity for 10 minutes. Prometheus [Haproxy-Ingress] High Error Rate This alert triggers when there is an error rate over 15% for over 10 minutes in a proxy. Prometheus [Haproxy-Ingress] High Request Denied Rate These alerts detect when there is a denied rate of requests over 10% for over 10 minutes in a proxy. Prometheus [Haproxy-Ingress] High Response Denied Rate These alerts detect when there is a denied rate of responses over 10% for over 10 minutes in a proxy. Prometheus [Haproxy-Ingress] High Response Rate This alert triggers when a proxy has a mean response time higher than 250ms for over 10 minutes. Prometheus List of DashboardsHAProxy Ingress OverviewThe dashboard provides information on the HAProxy Ingress Overview. HAProxy Ingress Service DetailsThe dashboard provides information on the HAProxy Ingress Service Details. List of Metrics Metric name haproxy_backend_bytes_in_total haproxy_backend_bytes_out_total haproxy_backend_client_aborts_total haproxy_backend_connect_time_average_seconds haproxy_backend_current_queue haproxy_backend_http_requests_total haproxy_backend_http_responses_total haproxy_backend_limit_sessions haproxy_backend_queue_time_average_seconds haproxy_backend_requests_denied_total haproxy_backend_response_time_average_seconds haproxy_backend_responses_denied_total haproxy_backend_sessions_total haproxy_backend_status haproxy_frontend_bytes_in_total haproxy_frontend_bytes_out_total haproxy_frontend_connections_total haproxy_frontend_denied_connections_total haproxy_frontend_denied_sessions_total haproxy_frontend_request_errors_total haproxy_frontend_requests_denied_total haproxy_frontend_responses_denied_total haproxy_frontend_status haproxy_process_active_peers haproxy_process_current_connection_rate haproxy_process_current_run_queue haproxy_process_current_session_rate haproxy_process_current_tasks haproxy_process_jobs haproxy_process_ssl_connections_total haproxy_process_start_time_seconds PrerequisitesEnable Prometheus MetricsFor HAProxy to expose Prometheus metrics, the following options must be enabled:\ncontroller.metrics.enabled = true controller.stats.enabled = true You can check all the properties in the official web page.\nIf you are deploying HAProxy using the official Helm chart, they can be enabled with the following configurations:\nhelm install haproxy-ingress haproxy-ingress/haproxy-ingress \\ --set-string \u0026#34;controller.stats.enabled = true\u0026#34; \\ --set-string \u0026#34;controller.metrics.enabled = true\u0026#34; This configuration creates the following section in haproxy.cfg file\nfrontend prometheus mode http bind :9101 http-request use-service prometheus-exporter if { path /metrics } http-request use-service lua.send-prometheus-root if { path / } http-request use-service lua.send-404 no log InstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: \u0026#39;haproxy-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (haproxy-ingress);(.{0}$) replacement: haproxy-ingress target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;haproxy-ingress\u0026#34; - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (haproxy_backend_bytes_in_total|haproxy_backend_bytes_out_total|haproxy_backend_client_aborts_total|haproxy_backend_connect_time_average_seconds|haproxy_backend_current_queue|haproxy_backend_http_requests_total|haproxy_backend_http_responses_total|haproxy_backend_limit_sessions|haproxy_backend_queue_time_average_seconds|haproxy_backend_requests_denied_total|haproxy_backend_response_time_average_seconds|haproxy_backend_responses_denied_total|haproxy_backend_sessions_total|haproxy_backend_status|haproxy_frontend_bytes_in_total|haproxy_frontend_bytes_out_total|haproxy_frontend_connections_total|haproxy_frontend_denied_connections_total|haproxy_frontend_denied_sessions_total|haproxy_frontend_request_errors_total|haproxy_frontend_requests_denied_total|haproxy_frontend_responses_denied_total|haproxy_frontend_status|haproxy_process_active_peers|haproxy_process_current_connection_rate|haproxy_process_current_run_queue|haproxy_process_current_session_rate|haproxy_process_current_tasks|haproxy_process_jobs|haproxy_process_ssl_connections_total|haproxy_process_start_time_seconds) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/haproxy-ingress/"},{"id":484,"title":"HAProxy Ingress OpenShift","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v3.11\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 28 metrics.\nTimeseries generated: The HAProxy ingress router generates ~400 time series per HAProxy router pod.\nList of Alerts Alert Description Format [OpenShift-HAProxy-Router] Router Down Router HAProxy down. No instances running. Prometheus [OpenShift-HAProxy-Router] HAProxy Down HAProxy down on a pod. Prometheus [OpenShift-HAProxy-Router] HAProxy Reload Failure HAProxy reloads are failing. New configurations will not be applied. Prometheus [OpenShift-HAProxy-Router] Percentage of routers low Less than 75% Routers are up. Prometheus [OpenShift-HAProxy-Router] Route Down This alert detects if all servers are down in a route Prometheus [OpenShift-HAProxy-Router] High Latency This alert detects high latency in at least one server of the route. Prometheus [OpenShift-HAProxy-Router] Pod Health Check Failure This alert triggers when there is a recurrent pod health check failure. Prometheus [OpenShift-HAProxy-Router] Queue not empty in route This alert triggers when a queue is not empty in a route. Prometheus [OpenShift-HAProxy-Router] High error rate in route This alert triggers when the error rate in a route is higher than 15%. Prometheus [OpenShift-HAProxy-Router] Connection errors in route This alert triggers when there are recurring connection errors in a route. Prometheus List of DashboardsOpenShift HAProxy Ingress OverviewThe dashboard provides information on the OpenShift HAProxy Ingress overview. OpenShift HAProxy Ingress Service DetailsThe dashboard provides information on the OpenShift HAProxy Ingress Service golden signals. List of Metrics Metric name haproxy_backend_http_average_connect_latency_milliseconds haproxy_backend_http_average_queue_latency_milliseconds haproxy_backend_http_average_response_latency_milliseconds haproxy_backend_up haproxy_frontend_bytes_in_total haproxy_frontend_bytes_out_total haproxy_frontend_connections_total haproxy_frontend_current_session_rate haproxy_frontend_http_responses_total haproxy_process_cpu_seconds_total haproxy_process_max_fds haproxy_process_resident_memory_bytes haproxy_process_start_time_seconds haproxy_process_virtual_memory_bytes haproxy_server_bytes_in_total haproxy_server_bytes_out_total haproxy_server_check_failures_total haproxy_server_connection_errors_total haproxy_server_connections_total haproxy_server_current_queue haproxy_server_current_sessions haproxy_server_downtime_seconds_total haproxy_server_http_average_response_latency_milliseconds haproxy_server_http_responses_total haproxy_server_up haproxy_up kube_workload_status_desired template_router_reload_failure PrerequisitesOpenShift 3.11Once the Sysdig agent is deployed, check if it is running on all nodes (compute, master, and infra):\noc get nodes oc get pods -n sysdig-agent -o wide Apply this patch in case the Agent is not running on infra/master.\noc patch namespace sysdig-agent --patch-file=\u0026#39;sysdig-agent-namespace-patch.yaml\u0026#39; sysdig-agent-namespace-patch.yaml file\napiVersion: v1 kind: Namespace metadata: annotations: openshift.io/node-selector: \u0026#34;\u0026#34; OpenShift integrates security by default. Therefore, if you want Sysdig agent to scrape HAProxy router metrics, provide it with the necessary permissions. To do so:\noc apply -f router-clusterrolebinding-sysdig-agent-oc3.yaml router-clusterrolebinding-sysdig-agent-oc3.yaml file\napiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: haproxy-route-monitoring rules: - apiGroups: - route.openshift.io resources: - routers/metrics verbs: - get --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: labels: app: sysdig-agent name: sysdig-router-monitoring roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: haproxy-route-monitoring subjects: - kind: ServiceAccount name: sysdig-agent namespace: sysdig-agent # Remember to change to the namespace where you have the Sysdig agents deployed OpenShift 4.XOpenShift integrates security by default. Therefore, if you want Sysdig agent to scrape HAProxy router metrics, provide it with the necessary permissions. To do so:\noc apply -f router-clusterrolebinding-sysdig-agent-oc4.yaml router-clusterrolebinding-sysdig-agent-oc4.yaml file\napiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: router-monitoring-sysdig-agent roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: router-monitoring subjects: - kind: ServiceAccount name: sysdig-agent namespace: sysdig-agent # Remember to change to the namespace where you have the Sysdig agents deployed InstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: \u0026#39;haproxy-router\u0026#39; scheme: https bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__address__] regex: ([^:]+)(?::\\d+)? replacement: $1:1936 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (router);(.{0}$) replacement: openshift-haproxy target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;openshift-haproxy\u0026#34; - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (haproxy_backend_http_average_connect_latency_milliseconds|haproxy_backend_http_average_queue_latency_milliseconds|haproxy_backend_http_average_response_latency_milliseconds|haproxy_backend_up|haproxy_frontend_bytes_in_total|haproxy_frontend_bytes_out_total|haproxy_frontend_connections_total|haproxy_frontend_current_session_rate|haproxy_frontend_http_responses_total|haproxy_process_cpu_seconds_total|haproxy_process_max_fds|haproxy_process_resident_memory_bytes|haproxy_process_start_time_seconds|haproxy_process_virtual_memory_bytes|haproxy_server_bytes_in_total|haproxy_server_bytes_out_total|haproxy_server_check_failures_total|haproxy_server_connection_errors_total|haproxy_server_connections_total|haproxy_server_current_queue|haproxy_server_current_sessions|haproxy_server_downtime_seconds_total|haproxy_server_http_average_response_latency_milliseconds|haproxy_server_http_responses_total|haproxy_server_up|haproxy_up|template_router_reload_failure) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/haproxy-ingress-openshift/"},{"id":485,"title":"Harbor","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v2.3\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 45 metrics.\nTimeseries generated: 800 timeseries\nList of Alerts Alert Description Format [Harbor] Harbor Core Is Down Harbor Core Is Down Prometheus [Harbor] Harbor Database Is Down Harbor Database Is Down Prometheus [Harbor] Harbor Registry Is Down Harbor Registry Is Down Prometheus [Harbor] Harbor Redis Is Down Harbor Redis Is Down Prometheus [Harbor] Harbor Trivy Is Down Harbor Trivy Is Down Prometheus [Harbor] Harbor JobService Is Down Harbor JobService Is Down Prometheus [Harbor] Project Quota Is Raising The Limit Project Quota Is Raising The Limit Prometheus [Harbor] Harbor p99 latency is higher than 10 seconds Harbor p99 latency is higher than 10 seconds Prometheus [Harbor] Harbor Error Rate is High Harbor Error Rate is High Prometheus List of DashboardsHarborThe dashboard provides information on the Harbour instance status, storage usage, projects and tasks. List of Metrics Metric name go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads harbor_artifact_pulled harbor_core_http_request_duration_seconds harbor_jobservice_task_process_time_seconds harbor_project_member_total harbor_project_quota_byte harbor_project_quota_usage_byte harbor_project_repo_total harbor_project_total harbor_quotas_size_bytes harbor_task_concurrency harbor_task_queue_latency harbor_task_queue_size harbor_up process_cpu_seconds_total process_max_fds process_open_fds registry_http_request_duration_seconds_bucket registry_http_request_size_bytes_bucket registry_http_requests_total registry_http_response_size_bytes_bucket registry_storage_action_seconds_bucket PrerequisitesEnable Prometheus MetricsAs seen in the Harbor documentation page Configure the Harbor YML File, to make Harbor expose an endpoint for scraping metrics, you need to set the \u0026lsquo;metric.enabled\u0026rsquo; configuration to \u0026rsquo;true\u0026rsquo;.\nIf you install Harbor with Helm, you need to use the following flag:\n--set \u0026#39;metrics.enabled=true\u0026#39; InstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent jobs for this integration are as follows:\n- job_name: harbor-exporter-default kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_container_port_number regex: exporter;8080 - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__address__,__meta_kubernetes_pod_container_port_number] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:8001 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: harbor-core-default kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_container_port_number regex: core;8080 - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__address__,__meta_kubernetes_pod_container_port_number] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:8001 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: harbor-registry-default kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_container_port_number regex: registry;5000 - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__address__,__meta_kubernetes_pod_container_port_number] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:8001 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: harbor-jobservice-default kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_container_port_number regex: jobservice;8080 - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__address__,__meta_kubernetes_pod_container_port_number] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:8001 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/harbor/"},{"id":486,"title":"Harbor","content":" Ensure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=harbor \\ --set config.registryURL=\u0026lt;HARBOR_REGISTRY_URL\u0026gt; \\ --set config.registryUser=\u0026lt;HARBOR_USER\u0026gt; \\ --set config.registryPassword=\u0026lt;HARBOR_PASSWORD\u0026gt; \u0026lt;HARBOR_USER\u0026gt; \\ \u0026lt;HARBOR_PASSWORD\u0026gt;: User credentials with Administrator flag activated (Project Admin role is not currently supported) \u0026lt;HARBOR_REGISTRY_URL\u0026gt;: Harbor registry URL e.g., core.harbor.domain ","url":"https://docs.sysdig.com/en/sysdig-secure/harbor/"},{"id":487,"title":"IBM Container Registry Scanner","content":" Ensure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=icr \\ --set config.registryURL=\u0026lt;ICR_REGISTRY_URL\u0026gt; \\ --set config.registryUser=iamapikey \\ --set config.registryPassword=\u0026lt;ICR_APIKEY\u0026gt; \\ --set config.registryAccountId=\u0026lt;ICR_ACCOUNT_ID\u0026gt; \u0026lt;ICR_REGISTRY_URL\u0026gt;: The ICR registry URL. For example, https://us.icr.io \u0026lt;ICR_ACCOUNT_ID\u0026gt;: The ICR account ID where the registry is located. ","url":"https://docs.sysdig.com/en/sysdig-secure/ibm-container-registry/"},{"id":488,"title":"Istio","content":" This integration is enabled by default.\nVersions supported: 1.19\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 28 metrics.\nTimeseries generated: For a ten-node cluster, the number of timeseries can vary between 1K and 10K due to the presence of high cardinality metrics. The number of workloads in your cluster, the number of Istio policies, and the Istio network rules applied determine this number.\nList of Alerts Alert Description Format [Istio-Citadel] CSR without success Some of the Certificate Signing Request (CSR) were not correctly requested Prometheus [Istio-Pilot] Inbound listener rules conflicts There are some conflict with inbound listener rules Prometheus [Istio-Pilot] Endpoint found in unready state Endpoint found in unready state Prometheus [Istio] Unstable requests for sidecar injections Sidecar injections requests are failing Prometheus [Istiod] Istiod Uptime issue Istiod UpTime is taking more time than usual Prometheus List of DashboardsIstio Control PlaneThe dashboard provides information on the Istio Control Plane, Pilot, Galley, Mixer and Citadel. List of Metrics Metric name citadel_server_csr_count citadel_server_success_cert_issuance_count galley_validation_failed galley_validation_passed istiod_uptime_seconds pilot_conflict_inbound_listener pilot_conflict_outbound_listener_http_over_current_tcp pilot_conflict_outbound_listener_tcp_over_current_http pilot_conflict_outbound_listener_tcp_over_current_tcp pilot_endpoint_not_ready pilot_services pilot_total_xds_internal_errors pilot_total_xds_rejects pilot_virt_services pilot_xds pilot_xds_cds_reject pilot_xds_config_size_bytes_bucket pilot_xds_eds_reject pilot_xds_lds_reject pilot_xds_push_context_errors pilot_xds_push_time_bucket pilot_xds_pushes pilot_xds_rds_reject pilot_xds_send_time_bucket pilot_xds_write_timeout sidecar_injection_failure_total sidecar_injection_requests_total sidecar_injection_success_total PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting IstioThis document describes resumed alarms and dashboards for Istio Service. Istio Services are based on network rules as the foundation, so all the alarms and dashboards monitor any problem related to traffic and connections from source and destination.\nAlarmsMost of the alarms associated with Istio configuration notifies problems with the Pilot or Citadel server. These servers are responsible for important Istio configuration.\nCitadel controls authentication and identity management between services, and manages certificates in every workload.\nPilot accepts the rules created for traffic behavior provided by the control plane, and converts them into configurations applied by Envoy, based on how configuration aspects are managed locally. Basically, Pilot is responsible for iptables configuration in every workload.\nCSR Without SuccessAlarms are defined to notify you of faulty Certificate Signing Requests (CSRs). In order to collect that information, the following metrics are used:\ncitadel_server_csr_count citadel_server_success_cert_issuance_count rate(citadel_server_csr_count[5m]) - rate(citadel_server_success_cert_issuance_count[5m]) \u0026gt; 0 What is CSR: A certificate signing request (CSR) is one of the first steps towards getting your own SSL/TLS certificate. Generated on the same server you plan to install the certificate on, the CSR contains information such as common name, organization, and country. The Certificate Authority (CA) will use CSR to create your certificate. CSR also contains the public key that will be included in your certificate and is signed with the corresponding private key.\nInbound Listener Rules ConflictsBecause Istio works with networking rules, and configures IP addresses, ports, sockets, and so on to send or received traffic. The term listeners refers to these configurable values. Be aware of possible errors or conflicts with these rules.\npilot_conflict_inbound_listener \u0026gt; 0 Endpoint Found in Unready StateIn order to have a stable platform, you need to verify that all endpoints in your network are perfectly working. Use the following alarm to collect that information:\npilot_endpoint_not_ready \u0026gt; 0 Unstable Requests for Sidecar InjectionsIstio configures sidecar containers in every pod, and use this sidecar as the frontend server for all the requests that goes to or from that workload. To check if this sidecar injection is properly work, use the following query:\nrate(sidecar_injection_requests_total [5m]) - rate(sidecar_injection_success_total [5m]) \u0026gt; 0 DashboardsTrafficTraffic is the first golden signal that has to be gathered. Because Istio provides traffic management itself the information it provides will be detailed. Istio has three different parts that you can monitor and specify different metrics: control plane, envoy, and service itself.\nThis example shows gathering information about Istio service traffic.\nUse the istio_requests_total with relevant labels to colloect wideband of information on different panels.\nClient Request Volume and Server Request VolumeThe istio_requests_total metric shows the total request traffic from both sides of the connection, using the reporter label.\nThe reporter label identifies the reporter of the request. It is set to destination if report is from an Istio proxy server. It will be set to source if the report is from a Istio proxy client or a gateway.\nsum (irate(istio_requests_total{reporter=\u0026#34;source\u0026#34;}[5m])) sum (irate(istio_requests_total{reporter=\u0026#34;destination\u0026#34;}[5m])) Incoming Request by Source/Destination and Response CodeThis dashboard shows the requests received by both source and destination using the reporter label. The following query segments the HTTP codes with the response_code label.\nsum(irate(istio_requests_total{reporter=\u0026#34;source\u0026#34;}[5m])) by (source_workload, source_workload_namespace, response_code) sum(irate(istio_requests_total{reporter=\u0026#34;destination\u0026#34;}[5m])) by (destination_workload, destination_workload_namespace, response_code) Client/Server Success Rate (non-5xx responses)The following query builds a dashboard to monitor all the traffic except related to the internal server errors. The reporter label is used to segment on both source and destination.\n100*(sum by (destination_service_name)(irate(istio_requests_total{reporter=\u0026#34;destination\u0026#34;,response_code!~\u0026#34;5.*\u0026#34;}[5m])) / sum by (destination_service_name)(irate(istio_requests_total{reporter=\u0026#34;destination\u0026#34;}[5m]))) 100*(sum by (destination_service_name)(irate(istio_requests_total{reporter=\u0026#34;source\u0026#34;,response_code!~\u0026#34;5.*\u0026#34;}[5m])) / sum by (destination_service_name)(irate(istio_requests_total{reporter=\u0026#34;source\u0026#34;}[5m]))) ErrorsThe errors summarized in these dashboards are related with HTTP traffic managed by Istio proxies.\n4xx Response Code by Source/DestinationThe following query builds a dashboard that reports all the bad requests. It uses the reporter label on both source and destination.\nsum by (response_code)(irate(istio_requests_total{reporter=\u0026#34;source\u0026#34;, response_code=~\u0026#34;4.*\u0026#34;}[5m])) or absent(istio_requests_total{reporter=\u0026#34;source\u0026#34;, response_code=~\u0026#34;4.*\u0026#34;}) -1 sum by (response_code)(irate(istio_requests_total{reporter=\u0026#34;destination\u0026#34;, response_code=~\u0026#34;4.*\u0026#34;}[5m])) or absent(istio_requests_total{reporter=\u0026#34;destination\u0026#34;, response_code=~\u0026#34;4.*\u0026#34;}) -1 5xx Response Code by Source/DestinationThe following query builds a dashboard to show all the internal server errors requests. The query uses the reporter label on both source and destination.\nsum by (response_code)(irate(istio_requests_total{reporter=\u0026#34;source\u0026#34;, response_code=~\u0026#34;4.*\u0026#34;}[5m])) or absent(istio_requests_total{reporter=\u0026#34;source\u0026#34;, response_code=~\u0026#34;4.*\u0026#34;}) -1 sum by (response_code)(irate(istio_requests_total{reporter=\u0026#34;destination\u0026#34;, response_code=~\u0026#34;4.*\u0026#34;}[5m])) or absent(istio_requests_total{reporter=\u0026#34;destination\u0026#34;, response_code=~\u0026#34;4.*\u0026#34;}) -1 Latency and SaturationBoth latency and saturation are reported on these dashboards because both are related to request duration and package size.\nClient/Server Request DurationThe following query builds a dashboard to show critical duration of some requests using quantiles.\nNote: quantiles can be modified.\nhistogram_quantile(0.50, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\u0026#34;source\u0026#34;}[1m])) by (le, source_service_name)) / 1000 histogram_quantile(0.50, sum(irate(istio_request_duration_milliseconds_bucket{reporter=\u0026#34;destination\u0026#34;}[1m])) by (le, destination_service_name)) / 1000 Incoming Request Size by Source/DestinationThe following query builds a dashboard to show critical size of some requests using quantiles.\nNote: quantiles can be modified.\nhistogram_quantile(0.50, sum(irate(istio_request_bytes_bucket{reporter=\u0026#34;source\u0026#34;}[5m])) by (source_workload, source_workload_namespace, le)) histogram_quantile(0.50, sum(irate(istio_request_bytes_bucket{reporter=\u0026#34;destination\u0026#34;}[5m])) by (destination_workload, destination_workload_namespace, le)) Response Size By Source/DestinationThe following query builds a dashboard to show critical size of some responses using quantiles.\nNote: quantiles can be modified.\nhistogram_quantile(0.50, sum(irate(istio_response_bytes_bucket{reporter=\u0026#34;source\u0026#34;}[5m])) by (source_workload, source_workload_namespace, le)) histogram_quantile(0.50, sum(irate(istio_response_bytes_bucket{reporter=\u0026#34;destination\u0026#34;}[5m])) by (destination_workload, destination_workload_namespace, le)) Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: \u0026#39;istiod\u0026#39; kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (discovery);(.{0}$) replacement: istiod target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;istiod\u0026#34; - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (citadel_server_csr_count|citadel_server_success_cert_issuance_count|galley_validation_failed|galley_validation_passed|istiod_uptime_seconds|pilot_conflict_inbound_listener|pilot_conflict_outbound_listener_http_over_current_tcp|pilot_conflict_outbound_listener_tcp_over_current_http|pilot_conflict_outbound_listener_tcp_over_current_tcp|pilot_endpoint_not_ready|pilot_services|pilot_total_xds_internal_errors|pilot_total_xds_rejects|pilot_virt_services|pilot_xds|pilot_xds_cds_reject|pilot_xds_config_size_bytes_bucket|pilot_xds_eds_reject|pilot_xds_lds_reject|pilot_xds_push_context_errors|pilot_xds_push_time_bucket|pilot_xds_pushes|pilot_xds_rds_reject|pilot_xds_send_time_bucket|pilot_xds_write_timeout|sidecar_injection_failure_total|sidecar_injection_requests_total|sidecar_injection_success_total|istio_build|istio_request_bytes_bucket|istio_request_duration_milliseconds_bucket|istio_requests_total|istio_response_bytes_bucket|istio_tcp_received_bytes_total|istio_tcp_sent_bytes_total|pilot_proxy_convergence_time_bucket) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/istio/"},{"id":489,"title":"Istio Envoy","content":" This integration is disabled by default. Please refer to Enable and Disable Integrations to enable it in your account.\nVersions supported: 1.19\nThis integration has 16 metrics.\nTimeseries generated: 155 timeseries per envoy\nList of Alerts Alert Description Format [Istio-Envoy] High 4xx RequestError Rate 4xx RequestError Rate is higher than 5% Prometheus [Istio-Envoy] High 5xx RequestError Rate 5xx RequestError Rate is higher than 5% Prometheus [Istio-Envoy] High Request Latency Envoy Request Latency is higher than 100ms Prometheus List of DashboardsIstio WorkloadThe dashboard provides information on the Istio Envoy proxy status. Istio ServiceThe dashboard provides information on the Istio Service, Request rates and duration for Http and TCP connections. List of Metrics Metric name citadel_server_csr_count envoy_cluster_membership_change envoy_cluster_membership_healthy envoy_cluster_membership_total envoy_cluster_upstream_cx_active envoy_cluster_upstream_cx_connect_ms_bucket envoy_cluster_upstream_rq_active envoy_cluster_upstream_rq_pending_active envoy_server_days_until_first_cert_expiring istio_build istio_request_bytes_bucket istio_request_duration_milliseconds_bucket istio_requests_total istio_response_bytes_bucket istio_tcp_received_bytes_total istio_tcp_sent_bytes_total PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/istio-envoy/"},{"id":490,"title":"Kafka","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v2.7.x\nThis integration uses a standalone exporter that is available in UBI or scratch base image.\nThis integration has 37 metrics.\nTimeseries generated: The JMX-Exporter generates ~270 timeseries and the Kafka-Exporter ~138 timeseries (the number of topics, partitions and consumers increases this number).\nList of Alerts Alert Description Format [Kafka] Broker Down There are less Kafka brokers up than expected. The \u0026lsquo;workload\u0026rsquo; label of the Kafka Deployment/Stateful set must be specified. Prometheus [Kafka] No Leader There is no ActiveController or \u0026rsquo;leader\u0026rsquo; in the Kafka cluster. Prometheus [Kafka] Too Many Leaders There is more than one ActiveController or \u0026rsquo;leader\u0026rsquo; in the Kafka cluster. Prometheus [Kafka] Offline Partitions There are one or more Offline Partitions. These partitions don’t have an active leader and are hence not writable or readable. Prometheus [Kafka] Under Replicated Partitions There are one or more Under Replicated Partitions. Prometheus [Kafka] Under In-Sync Replicated Partitions There are one or more Under In-Sync Replicated Partitions. These partitions will be unavailable to producers who use \u0026lsquo;acks=all\u0026rsquo;. Prometheus [Kafka] ConsumerGroup Lag Not Decreasing The ConsumerGroup lag is not decreasing. The Consumers might be down, failing to process the messages and continuously retrying, or their consumption rate is lower than the production rate of messages. Prometheus [Kafka] ConsumerGroup Without Members The ConsumerGroup doesn\u0026rsquo;t have any members. Prometheus [Kafka] Producer High ThrottleTime By Client-Id The Producer has reached its quota and has high throttle time. Applicable when Client-Id-only quotas are being used. Prometheus [Kafka] Producer High ThrottleTime By User The Producer has reached its quota and has high throttle time. Applicable when User-only quotas are being used. Prometheus [Kafka] Producer High ThrottleTime By User And Client-Id The Producer has reached its quota and has high throttle time. Applicable when Client-Id + User quotas are being used. Prometheus [Kafka] Consumer High ThrottleTime By Client-Id The Consumer has reached its quota and has high throttle time. Applicable when Client-Id-only quotas are being used. Prometheus [Kafka] Consumer High ThrottleTime By User The Consumer has reached its quota and has high throttle time. Applicable when User-only quotas are being used. Prometheus [Kafka] Consumer High ThrottleTime By User And Client-Id The Consumer has reached its quota and has high throttle time. Applicable when Client-Id + User quotas are being used. Prometheus List of DashboardsKafkaThe dashboard provides information on the status of Kafka. List of Metrics Metric name kafka_brokers kafka_consumergroup_current_offset kafka_consumergroup_lag kafka_consumergroup_members kafka_controller_active_controller kafka_controller_offline_partitions kafka_log_size kafka_network_consumer_request_time_milliseconds kafka_network_fetch_follower_time_milliseconds kafka_network_producer_request_time_milliseconds kafka_server_bytes_in kafka_server_bytes_out kafka_server_consumer_client_byterate kafka_server_consumer_client_throttle_time kafka_server_consumer_user_byterate kafka_server_consumer_user_client_byterate kafka_server_consumer_user_client_throttle_time kafka_server_consumer_user_throttle_time kafka_server_messages_in kafka_server_partition_leader_count kafka_server_producer_client_byterate kafka_server_producer_client_throttle_time kafka_server_producer_user_byterate kafka_server_producer_user_client_byterate kafka_server_producer_user_client_throttle_time kafka_server_producer_user_throttle_time kafka_server_under_isr_partitions kafka_server_under_replicated_partitions kafka_server_zookeeper_auth_failures kafka_server_zookeeper_disconnections kafka_server_zookeeper_expired_sessions kafka_server_zookeeper_read_only_connections kafka_server_zookeeper_sasl_authentications kafka_server_zookeeper_sync_connections kafka_topic_partition_current_offset kafka_topic_partition_oldest_offset kube_workload_status_desired PrerequisitesInstallation of the JMX-Exporter as a SidecarThe JMX-Exporter can be easily installed in two steps.\nFirst deploy the ConfigMap which contains the Kafka JMX configurations. The following example is for a Kafka cluster which exposes the jmx port 9010:\nhelm repo add promcat-charts https://sysdiglabs.github.io/integrations-charts helm repo update helm -n kafka install kafka-jmx-exporter promcat-charts/jmx-exporter --set jmx_port=9010 --set integrationType=kafka --set onlyCreateJMXConfigMap=true Then generate a patch file and apply it to your workload (your Kafka Deployment/StatefulSet/Daemonset). The following example is for a Kafka cluster which exposes the jmx port 9010, and is deployed as a StatefulSet called \u0026lsquo;kafka-cp-kafka\u0026rsquo;:\nhelm template kafka-jmx-exporter promcat-charts/jmx-exporter --set jmx_port=9010 --set integrationType=kafka --set onlyCreateSidecarPatch=true --set sysdigAnnotations=true \u0026gt; jmx-exporter-sidecar-patch.yaml kubectl -n kafka patch sts kafka-cp-kafka --patch-file jmx-exporter-sidecar-patch.yaml Create Secrets for Authentication for the Kafka-ExporterYour Kafka cluster external endpoints might be secured by using authentication for the clients that want to connect to it (TLS, SASL+SCARM, SASL+Kerberos). If you are going to make the Kafka-Exporter (which will be deployed in the next tab) use these secured external endpoints, then you\u0026rsquo;ll need to create Kubernetes Secrets in the following step. If you prefer using an internal not-secured (plaintext) endpoint for the Kafka-Exporter to connect to the Kafka cluster, then skip this step.\nIf using TLS, you\u0026rsquo;ll need to create a Secret which contains the CA, the client certificate and the client key. The names of these files must be \u0026ldquo;ca.crt\u0026rdquo;, \u0026ldquo;tls.crt\u0026rdquo; and \u0026ldquo;tls.key\u0026rdquo;. The name of the secret can be any name that you want. Example:\nkubectl create secret generic kafka-exporter-certs --from-file=./tls.key --from-file=./tls.crt --from-file=./ca.crt --dry-run=true -o yaml | kubectl apply -f - If using SASL+SCRAM, you\u0026rsquo;ll need to create a Secret which contains the \u0026ldquo;username\u0026rdquo; and \u0026ldquo;password\u0026rdquo;. Example:\necho -n \u0026#39;admin\u0026#39; \u0026gt; username echo -n \u0026#39;1f2d1e2e67df\u0026#39; \u0026gt; password kubectl create secret generic kafka-exporter-sasl-scram --from-file=username --from-file=password --dry-run=true -o yaml | kubectl apply -f - If using SASL+Kerberos, you\u0026rsquo;ll need to create a Secret which contains the \u0026ldquo;kerberos.conf\u0026rdquo;. If the \u0026lsquo;Kerberos Auth Type\u0026rsquo; is \u0026lsquo;keytabAuth\u0026rsquo;, it should also contain the \u0026ldquo;kerberos.keytab\u0026rdquo;. Example:\nkubectl create secret generic kafka-exporter-sasl-kerberos --from-file=./kerberos.conf --from-file=./kerberos.keytab --dry-run=true -o yaml | kubectl apply -f - InstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm charts for installation:\nhttps://github.com/sysdiglabs/integrations-charts/tree/main/charts/jmx-exporter https://github.com/sysdiglabs/integrations-charts/tree/main/charts/kafka-exporter Monitoring and Troubleshooting KafkaHere are some interesting metrics and queries to monitor and troubleshoot Kafka.\nBrokersBroker DownLet\u0026rsquo;s get the number of expected Brokers, and the actual number of Brokers up and running. If the number is not the same, then there might a problem.\nsum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(kube_workload_status_desired) - sum by (kube_cluster_name,kube_namespace_name, kube_workload_name)(kafka_brokers) \u0026gt; 0 LeadershipLet\u0026rsquo;s get the number of Kafka leaders. There should always be one leader. If not, a Kafka misconfiguration or a networking issue might be the problem.\nsum(kafka_controller_active_controller) \u0026lt; 1 If there are more than one leader, that might be a temporal situation while the leadership is changing. If this case doesn\u0026rsquo;t get fixed by itslef over time, a split-brain situation might be happening.\nsum(kafka_controller_active_controller) \u0026gt; 1 Offline, Under Replicated and In-Sync Under Replicated PartitionsWhen a Broker goes down, the other Brokers in the cluster will take leadership of the partitions it was leading. If several brokers go down, or just a few but the topic had a low replication factor, there will be Offline partitions. These partitions don’t have an active leader and are hence not writable or readable, which will most likely dangerous for business.\nLet\u0026rsquo;s check if there are offline partitions:\nsum(kafka_controller_offline_partitions) \u0026gt; 0 If other Brokers had replicas of those partitions, one of them will take leadership and the service won\u0026rsquo;t be down. In this situation there will be Under Replicated partitions. If there are enough Brokers where these partitions can be replicated, the situation will be fixed by itself over time. If there aren\u0026rsquo;t enough Brokers, the situation will only be fixed once the Brokers which went down come up again.\nThe following expression is used to get the under replication partitions:\nsum(kafka_server_under_replicated_partitions) \u0026gt; 0 But there is a situation when having no Offline partitons but having Under Replicated partitions might pose a real problem. That\u0026rsquo;s the case of topics with \u0026lsquo;Minimum In-Sync Replicas\u0026rsquo;, and Kafka Producers with the configuration \u0026lsquo;acks=all\u0026rsquo;.\nIf one of this topics has any partition with less replicas than its \u0026lsquo;Minimum In-Sync Replicas\u0026rsquo; configuration, and there is Producer with \u0026lsquo;acks=all\u0026rsquo;, that Producer won\u0026rsquo;t be able to produce messages into that partition, since \u0026lsquo;acks=all\u0026rsquo; means that it waits for the produced messages to be replicated in all the minimum replicas in the Kafka cluster.\nIf the Producers have any configuration different than \u0026lsquo;acks=all\u0026rsquo;, then there won\u0026rsquo;t be any problem.\nThis is how Under In-Sync Replicated partitions can be checked:\nsum(kafka_server_under_isr_partitions) \u0026gt; 0 NetworkBroker Bytes InLet\u0026rsquo;s get the amount of bytes produced into each Broker:\nsum by (kube_cluster_name, kube_namespace_name, kube_workload_name, kube_pod_name)(kafka_server_bytes_in) Broker Bytes OutNow the same, but for bytes consumed from each Broker:\nsum by (kube_cluster_name, kube_namespace_name, kube_workload_name, kube_pod_name)(kafka_server_bytes_out) Broker Messages InAnd similar, but for number of messages produced into each Broker:\nsum by (kube_cluster_name, kube_namespace_name, kube_workload_name, kube_pod_name)(kafka_server_messages_in) TopicsTopic SizeThis query returns the size of a topic in the whole Kafka cluster. It also includes the size of all replicas, so increasing the replication factor of a topic will increase the overall size across the Kafka cluster.\nsum by(kube_cluster_name, kube_namespace_name, kube_workload_name, topic)(kafka_log_size) In case of needing the size of a topic in each Broker, use the following query:\nsum by(kube_cluster_name, kube_namespace_name, kube_workload_name, kube_pod_name)(kafka_log_size) In a situation where the Broker disk space is running low, the retention of the topics can be decreased to free up some space. Let\u0026rsquo;s get the top 10 biggest topics:\ntopk(10,sum by(kube_cluster_name, kube_namespace_name, kube_workload_name, topic)(kafka_log_size)) If this \u0026ldquo;low disk space\u0026rdquo; situation happened out of the blue, there might be a problem in a topic with a Producer filling it with unwanted messages. The following query will help find which topics increased their size the most in the past few hours, which will allow to find the responsible of the sudden increase of messages. It wouldn\u0026rsquo;t be the first time an exhausted developer wanted to perform a stress test in a topic in a Staging environment, but accidentally did it in Production.\ntopk(10,sum by(kube_cluster_name, kube_namespace_name, kube_workload_name, topic)(delta(kafka_log_size[$__interval]))) Topic MessagesCalculating the number of messages inside a topic is as easy as substracting the offset of the newest message minus the offset of the oldest message:\nsum by(kube_cluster_name, kube_namespace_name, kube_workload_name, topic)(kafka_topic_partition_current_offset) - sum by(kube_cluster_name, kube_namespace_name, kube_workload_name, topic)(kafka_topic_partition_oldest_offset) But it\u0026rsquo;s very important to acknowledge that this is only true for topics with \u0026lsquo;compaction\u0026rsquo; disabled, since compacted topics might have deleted messages in the middle. To get the number of messages in a compacted topic, a new Consumer must consume all the messages in that topic to count them.\nIt\u0026rsquo;s also quite easy to calculate the rate per second of messages being produced into a topic:\nsum by(kube_cluster_name, kube_namespace_name, kube_workload_name, topic)(rate(kafka_topic_partition_current_offset[$__interval])) ConsumerGroupConsumerGroup LagLet\u0026rsquo;s check the ConsumerGroup lag of a Consumer in each partition of a topic:\nsum by(kube_cluster_name, kube_namespace_name, kube_workload_name, consumergroup, topic, partition)(kafka_consumergroup_lag) If the lag of a ConsumerGroup is constantly increasing and never decreases, it might have different causes. The Consumers of the ConsumerGroups might be down, one of them might be failing to process the messages and continuously retrying, or their consumption rate might be lower than the production rate of messages.\nA non-stop increasing lag can be detected using the following expression:\n(sum by(kube_cluster_name, kube_namespace_name, kube_workload_name, consumergroup, topic)(kafka_consumergroup_lag) \u0026gt; 0) and (sum by(kube_cluster_name, kube_namespace_name, kube_workload_name, consumergroup, topic)(delta(kafka_consumergroup_lag[2m])) \u0026gt;= 0) ConsumerGroup Consumption RateIt might be useful to get the consumption speed of the Consumers of a ConsumerGroup, to detect any issues while processing messages, like internal issues related to the messages, or external issues related to the business. For example, the Consumers might want to send the processed messages to another microservice or another database, but there might be networking issues, or the database performance might be degraded so it slows down the Consumer.\nHere you can check the consumption rate:\nsum by(kube_cluster_name, kube_namespace_name, kube_workload_name, consumergroup, topic, partition)(rate(kafka_consumergroup_current_offset[$__interval])) ConsumerGroup MembersIt might be also help to know the number of Consumers in a ConsumerGroup, in case there are less than expected:\nsum by(kube_cluster_name, kube_namespace_name, kube_workload_name, consumergroup)(kafka_consumergroup_members) QuotasKafka has the option to enforce quotas on requests to control the Broker resources used by clients (Producers and Consumers).\nQuotas can be applied to user, client-id or both groups at the same time.\nEach client can utilize this quota per Broker before it gets throttled. Throttling means that the client will need to wait some time before being able to produce or consume messages again.\nProduction/Consumption RateDepending if the client is a Consumer or a Producer, or if the quota is applied at cliend-id or user level, or both at the same time, a different metric will be used:\nkafka_server_producer_client_byterate kafka_server_producer_user_byterate kafka_server_producer_user_client_byterate kafka_server_consumer_client_byterate kafka_server_consumer_user_byterate kafka_server_consumer_user_client_byterate Let\u0026rsquo;s check for example the production rate of a Producer using both user and client-id:\nsum by(kube_cluster_name, kube_namespace_name, kube_workload_name, kube_pod_name, user, client_id)(kafka_server_producer_user_client_byterate) Production/Consumption Throttle TimeSimilar to the rate, there are throttle time for the same combinations of clients and quota groups:\nkafka_server_producer_client_throttle_time kafka_server_producer_user_throttle_time kafka_server_producer_user_client_throttle_time kafka_server_consumer_client_throttle_time kafka_server_consumer_user_throttle_time kafka_server_consumer_user_client_throttle_time Let\u0026rsquo;s see in this case if the throtte time of a Consumer using user and client-id is higher than one second, at least in one Broker:\nmax by(kube_cluster_name, kube_namespace_name, kube_workload_name, user, client_id)(kafka_server_consumer_user_client_throttle_time) \u0026gt; 1000 Agent ConfigurationThe default agent jobs for this integration are as follows:\n- job_name: \u0026#39;kafka-exporter-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (kafka-exporter);(.{0}$) replacement: kafka target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (kafka-exporter);(kafka) - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_ns] target_label: kube_namespace_name - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_type] target_label: kube_workload_type - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_name] target_label: kube_workload_name - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (kafka_brokers|kafka_consumergroup_current_offset|kafka_consumergroup_lag|kafka_consumergroup_members|kafka_topic_partition_current_offset|kafka_topic_partition_oldest_offset|kube_workload_status_desired) action: keep - job_name: \u0026#39;kafka-jmx-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (kafka-jmx-exporter);(kafka) replacement: kafka target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (kafka-jmx-exporter);(kafka) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (kafka_controller_active_controller|kafka_controller_offline_partitions|kafka_log_size|kafka_network_consumer_request_time_milliseconds|kafka_network_fetch_follower_time_milliseconds|kafka_network_producer_request_time_milliseconds|kafka_server_bytes_in|kafka_server_bytes_out|kafka_server_consumer_client_byterate|kafka_server_consumer_client_throttle_time|kafka_server_consumer_user_byterate|kafka_server_consumer_user_client_byterate|kafka_server_consumer_user_client_throttle_time|kafka_server_consumer_user_throttle_time|kafka_server_messages_in|kafka_server_partition_leader_count|kafka_server_producer_client_byterate|kafka_server_producer_client_throttle_time|kafka_server_producer_user_byterate|kafka_server_producer_user_client_byterate|kafka_server_producer_user_client_throttle_time|kafka_server_producer_user_throttle_time|kafka_server_under_isr_partitions|kafka_server_under_replicated_partitions|kafka_server_zookeeper_auth_failures|kafka_server_zookeeper_disconnections|kafka_server_zookeeper_expired_sessions|kafka_server_zookeeper_read_only_connections|kafka_server_zookeeper_sasl_authentications|kafka_server_zookeeper_sync_connections) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/kafka/"},{"id":491,"title":"KEDA","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v2.11\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 6 metrics.\nTimeseries generated: 3 metrics per Keda deployment + 1 metric per API metric timeseries\nList of Alerts Alert Description Format [Keda] Errors in Scaled Object Errors detected in scaled object Prometheus [Keda] Autoscaling Triggered Autoscaling has been triggered due to high number of events Prometheus [Keda] Insufficient Resources for Scaling Insufficient resources detected for scaling Prometheus List of DashboardsKedaThe dashboard provides information on the errors, values of the metrics generated and replicas of the scaled object. List of Metrics Metric name keda_build_info keda_metrics_adapter_scaled_object_errors keda_resource_totals keda_scaled_object_errors keda_scaler_metrics_value keda_trigger_totals PrerequisitesEnable Prometheus MetricsKeda instruments Prometheus metrics and annotates the metrics API pod with Prometheus annotations.\nMake sure that the prometheus metrics are activated. If you install Keda with Helm you need to use the following flag:\n--set prometheus.metricServer.enabled=true InstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: keda-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: - __meta_kubernetes_pod_container_name regex: (keda-operator|keda-operator-metrics-apiserver|keda-admission-webhooks) replacement: keda target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;keda\u0026#34; - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/keda/"},{"id":492,"title":"Knative","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v1.9\nThis integration has 10 metrics.\nList of DashboardsKnativeThe dashboard provides information on the errors, values of the metrics generated and replicas of the scaled object. List of Metrics Metric name autoscaler_client_latency_sum autoscaler_desired_pods autoscaler_observed_pods autoscaler_stable_request_concurrency autoscaler_workqueue_longest_running_processor_seconds_bucket controller_reconcile_count controller_reconcile_latency_bucket sysdig_container_cpu_cores_used sysdig_container_cpu_cores_used_percent sysdig_container_memory_used_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent jobs for this integration are as follows:\n- job_name: \u0026#39;knative-operator-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (knative-operator);(.{0}$) replacement: knative-operator target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (knative-operator);(knative-operator) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9090 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-serving-controller-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (controller);(.{0}$) replacement: knative-serving target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_app_kubernetes_io_name - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (knative-serving);(controller);(knative-serving) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9090 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-serving-autoscaler-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (autoscaler);(.{0}$) replacement: knative-serving target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_app_kubernetes_io_name - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (knative-serving);(autoscaler);(knative-serving) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9090 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-serving-activator-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (activator);(.{0}$) replacement: knative-serving target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_app_kubernetes_io_name - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (knative-serving);(activator);(knative-serving) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9090 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-serving-webhook-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (webhook);(.{0}$) replacement: knative-serving target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_app_kubernetes_io_name - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (knative-serving);(webhook);(knative-serving) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9090 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-eventing-broker-filter-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (filter);(.{0}$) replacement: knative-eventing target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_eventing_knative_dev_brokerRole - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (filter);(filter);(knative-eventing) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9092 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-eventing-broker-ingress-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (ingress);(.{0}$) replacement: knative-eventing target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_eventing_knative_dev_brokerRole - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (ingress);(ingress);(knative-eventing) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9092 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-eventing-controller-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (eventing-controller);(.{0}$) replacement: knative-eventing target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_app - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (eventing-controller);(eventing-controller);(knative-eventing) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9090 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-eventing-imc-controller-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (controller);(.{0}$) replacement: knative-eventing target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_app_kubernetes_io_component - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (imc-controller);(controller);(knative-eventing) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9090 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-eventing-imc-dispatcher-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (dispatcher);(.{0}$) replacement: knative-eventing target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_eventing_knative_dev_role - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (dispatcher);(dispatcher);(knative-eventing) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9090 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - job_name: \u0026#39;knative-eventing-apiserver-source-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (controller);(.{0}$) replacement: knative-eventing target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_label_eventing_knative_dev_role - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (controller);(controller);(knative-eventing) - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:9090 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/knative/"},{"id":493,"title":"Install Agent on Kubernetes","content":"If you are using Cluster Shield, see Install Cluster Shield and the shield chart documentation.\nFor information on installing Sysdig Secure see, Install Sysdig Secure in Kubernetes.\nPrerequisites Review the Installation Requirements.\nInstall the following:\nkubectl Helm v3.8 or above If you are not using the Quick Start Wizard for the installation command, collect the following:\nSysdig access key Collector address For more information on agent configuration, see Configure Sysdig Agent.\nInstallation Log in to Sysdig Monitor as an administrator.\nSelect Integrations \u0026gt; Sysdig Agent.\nClick +Add Account and select Kubernetes Cluster.\nThe Helm installation method is recommended.\nAs prompted by the screen, enter the name of your Kubernetes cluster.\nThe Wizard will auto-populate a code snippet with the cluster name, along with the autodetected Sysdig Monitor endpoint and the agent access key.\nCopy and run the Helm commands.\nThe command uses the sysdig-deploy chart to install the Sysdig Agent.\nYou can also use a values.yaml to install the agent.\nHelm values.yaml helm repo add sysdig https://charts.sysdig.com helm repo update helm install sysdig-agent --namespace sysdig-agent --create-namespace \\ --set global.sysdig.accessKey=\u0026lt;ACCESS_KEY\u0026gt; \\ --set global.sysdig.region=\u0026lt;SAAS_REGION\u0026gt; \\ --set nodeAnalyzer.enabled=false \\ --set global.clusterConfig.name=\u0026lt;CLUSTER_NAME\u0026gt; \\ sysdig/sysdig-deploy sysdig/sysdig-deploy ## create a values.yaml file with the following: global: sysdig: accessKey: \u0026lt;ACCESS_KEY\u0026gt; region: \u0026lt;SAAS_REGION\u0026gt; clusterConfig: name: \u0026lt;CLUSTER_NAME\u0026gt; nodeAnalyzer: enabled: false ## Install by running the following: helm repo add sysdig https://charts.sysdig.com helm install -n sysdig-agent sysdig sysdig/sysdig-deploy -f values.sysdig.yaml Pod Security AdmissionIf you’re enforcing PSA, add the privileged policy to the sysdig-agent namespace:\nkubectl label --overwrite ns sysdig-agent pod-security.kubernetes.io/enforce=privileged OptionsThe command above has the following options:\n--namespace sysdig-agent: Specifies that the agent should be installed in the sysdig-agent namespace.\n--set global.sysdig.accessKey=\u0026lt;ACCESS_KEY\u0026gt;: Specifies the Sysdig access key to use when connecting to the Sysdig backend. Replace \u0026lt;ACCESS_KEY\u0026gt; with your actual access key.\n--set global.sysdig.region=\u0026lt;SAAS_REGION\u0026gt;: Specifies the Sysdig region to use. Replace \u0026lt;SAAS_REGION\u0026gt; with the region where your Sysdig account is located.\nFor example, us1 for US East (Virginia), us2 for US West AWS , and au1 for AP Australia. See Regions and IP Ranges for more information.\n--set nodeAnalyzer.nodeAnalyzer.benchmarkRunner.deploy=false: Disables the Node Analyzer component. This is used by Secure users only.\n--set global.clusterConfig.name=\u0026lt;CLUSTER_NAME\u0026gt;: Specifies the name of your Kubernetes cluster. Replace \u0026lt;CLUSTER_NAME\u0026gt; with your actual Kubernetes cluster name.\nAfter running these commands, the Sysdig agent should be installed and running on your Kubernetes cluster, and starts sending data to the Sysdig backend.\nPlatform-Specific Options If you are using OpenShift, GKE Standard, OKE, or MKE, enable eBPF with the following option:\n--set agent.ebpf.enabled=true\nIf you are using GKE autopilot, enable the following option:\n--set agent.gke.autopilot=true\nAdditional OptionsFor additional configuration options, including on-premises and proxy connection, seesysdig-deploy.\nConfigure Prometheuspromscrape is the component responsible to collect Prometheus metrics from the Sysdig Agent. It is based on Prometheus and accepts the same configuration format. This file contains relabelling rules and filters to remove certain metrics or add some configurations to the collection. For example, add the following to the prometheus.yaml file:\nglobal: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: \u0026#39;prometheus\u0026#39; # config for federation honor_labels: true metrics_path: \u0026#39;/federate\u0026#39; metric_relabel_configs: - regex: \u0026#39;kubernetes_pod_name\u0026#39; action: labeldrop params: \u0026#39;match[]\u0026#39;: - \u0026#39;{sysdig=\u0026#34;true\u0026#34;}\u0026#39; sysdig_sd_configs: - tags: namespace: monitoring deployment: prometheus-server sysdig_sd_configs selects the targets obtained by Sysdig Agents to apply the rules in the job.\nFor information on setting up default integrations to collect Prometheus metrics from cloud-native applications, see Configure Default Integrations.\nFor more information on filtering rules, see Enable Prometheus Native Service Discovery .\nFor additional configuration options, including on-premises and proxy connection, see sysdig-deploy.\nAdd Additional VolumesTo pass a new ConfigMaps or secrets used for authentication, you can mount additional secrets, ConfigMaps, or volumes to Sysdig Agent. This is typically useful while authenticating Prometheus endpoints.\nFor example, you can add the following configuration to your value.yaml :\nagent: extraVolumes: volumes: - name: repo-new-cm configMap: name: my-cm optional: true - name: repo-new-secret secret: secretName: my-secret mounts: - mountPath: mount-path name: repo-new-cm - mountPath: mount-path name: repo-new-secret The same applies to the kmodule container under daemonset.kmodule. In some specific cases , such as SLES15 on Rancher, the proper ld-linux-* library is under the host /lib64 so the kernel module build fails. To handle this, add a specific volume mount /lib64 to /host/usr/lib64. For example:\nagent: daemonset: kmodule: extraVolumes: volumes: - name: lib64-vol hostPath: path: /lib64 mounts: - mountPath: /host/usr/lib64 name: lib64-vol Add Additional SecretsYou can create additional secrets to use, for example, for Prometheus basic authentication. The values are opaque-type secrets and must be in base64 encoded. For example:\nagent: extraSecrets: - name: repo-new-secret data: repo-new-key1: \u0026lt;your-password\u0026gt; repo-new-key2: \u0026lt;your-password\u0026gt; Uninstall Sysdig AgentIf the agent was installed in a Kubernetes environment, remove it by using the standard Kubernetes commands.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/classic-install-kubernetes/"},{"id":494,"title":"LDAP","content":"The configuration and functionality of LDAP has changed significantly in recent releases of the platform. Ensure that you upgrade to the newest on-prem release to take advantage of improvements. However, if you are running an older release and cannot yet upgrade, contact Sysdig Support for assistance.\nGeneral LDAP TipsTesting Configurations with LDAP SearchSmall typos in fields such as search filters can cause failures that are difficult to debug. You may want to perfect your more complex configurations before applying them via the helper scripts. This will help \u0026ldquo;divide \u0026amp; conquer\u0026rdquo; as to whether an issue is generic to LDAP syntax and/or the directory vs. a possible bug in the Sysdig platform.\nIf you have an Ubuntu Linux host at your disposal that can access your directory server via LDAP, install the ldap-utils package:\n# sudo apt install ldap-utils If accessing LDAP over SSL/TLS, edit the file /etc/ldap/ldap.conf and add the following line:\nTLS_REQCERT allow Then, copy the CA certificate (the same one that was uploaded in the Settings of the Replicated console) to a location on the host, such as /tmp/cert.pem .\nNow, you can run arbitrary queries via generic LDAP and study their success or failure. For instance, the following command-line uses some of the settings from LDAP Authentication Configuration (for Platform v. 963 - 1091) examples:\n# LDAPTLS_CACERT=/tmp/cert.pem ldapsearch -H ldaps://172.16.0.1:636 -M -b \u0026#34;DC=example,DC=local\u0026#34; -D \u0026#34;cn=Administrator,cn=Users,dc=example,dc=local\u0026#34; -w \u0026#34;myMgrPassword\u0026#34; \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(sAMAccountName=jdoe))\u0026#34; ... # John Doe, Users, example.local dn: CN=John Doe,CN=Users,DC=example,DC=local ... Excluding Classes of UsersPer this post, Active Directory admins may leverage certain queries to easily exclude certain classes of users from being able to authenticate to the Sysdig platform. For example, the following will filter out users whose accounts have been disabled in Active Directory.\n(!(userAccountControl:1.2.840.113556.1.4.803:=2)) This can be combined with other config via AND logic, such as by extending one of our searchFilter examples:\n\u0026#34;searchFilter\u0026#34;: \u0026#34;(\u0026amp;(objectClass=organizationalPerson)(sAMAccountName={0})(!(userAccountControl:1.2.840.113556.1.4.803:=2)))\u0026#34; ","url":"https://docs.sysdig.com/en/administration/onprem-ldap/"},{"id":495,"title":"LDAP/SAML Hybrid Authentication","content":"The process involves:\nEnable SAML login and disable automatic user creation via SAML.\nEnable LDAP user creation using LDAP mapping, but employ the _hybrid, rather than the _simple json configuration file.\n(Optional) Disable user creation via API.\n(Optional) Disable simple password login, to ensure SAML SSO is always used.\nEnsure SAML has been enabled in the UI as the chosen authentication method.\nEnable SAML Log In Follow the instructions for SAML (On-Prem)configuration for your IdP. Use the UI in Sysdig Platform version 3.5.0, or the script-based option for earlier versions.\nTo ensure that user records are created solely via LDAP mapping, disable user-creation-on-demand and (optionally) password authentication.\nUI-based option: Use the toggles in the UI to disable \u0026ldquo;create user on login\u0026rdquo; and \u0026ldquo;user name and password login.\u0026rdquo;\nScript-based option: Use the -n option of the saml_config.sh script, as described in the Optional: Auto-creation of user records section.\nUser experience:\nWith this configuration, if you successfully log in via SAML but do not have an existing username/email record in the Sysdig database, you will receive an error message.\nEnable LDAP User Creation using LDAP Mapping Configure the settings_mapping_hybrid.json file.\nThe only difference between the _simple and the _hybrid files is the userAttributeName value. In _hybrid, this is set to email, because SAML-derived usernames in the Sysdig platform area always based on email address.\nApply the settings using the mapping_config.sh script:\nmapping_config.sh -s settings_mapping_hybrid.json See Options for Applying mapping_config.sh.\nOptional: Disable User-Creation via APIIf you want to ensure your user records are derived only from LDAP hybrid mapping, then use the -d option with the api_user_creation.sh script, as described in the Readme.\nOptional: Disable Password LoginYou may have pre-existing records in your Sysdig platform database for users who have previously authenticated via simple email/password. If you want to prevent such logins and ensure 100% authentication via SAML, you can disable password login.\nIn this configuration, only the \u0026ldquo;super\u0026rdquo; Admin can still login via email/password.\nSee Disable Password Authentication.\nEnsure SAML is Enabled in the UIWhen all configurations are complete, log in to the Settings in the Sysdig user interface and Select SAML for SSO, if it is not already selected.\n","url":"https://docs.sysdig.com/en/administration/onprem-ldap-saml-hybrid-auth/"},{"id":496,"title":"Legacy Downtime Alert","content":" In this example, a Kubernetes cluster is monitored and the alert is segmented on both cluster and namespace. When a Kubernetes cluster in the selected availability zone goes down, notifications will be sent with necessary information on both cluster and affected namespace.\nThe lines shown in the preview chart represent the values for the segments selected to monitor. The popup is a color-coded legend to show which segment (or combination of segments if there is more than one) the lines represent. You can also deselect some segment lines to prevent them from showing in the chart. Note that there is a limit of 10 lines that Sysdig Monitor ever shows in the preview chart. For downtime alerts, segments are actually what you select for the \u0026ldquo;Select entity to monitor\u0026rdquo; option.\nDefine a Downtime AlertGuidelines Set a unique name and description: Set a meaningful name and description that help recipients easily identify the alert.\nSeverity: Set a severity level for your alert. The Priority—High, Medium, Low, and Info—are reflected in the Alert list, where you can sort by the severity of the Alert. You can use severity as a criterion when creating alerts, for example: if there are more than 10 high severity events, notify.\nSpecify multiple segments: Selecting a single segment might not always supply enough information to troubleshoot. Enrich the selected entity with related information by adding additional related segments. Enter hierarchical entities so you have the bottom-down picture of what went wrong and where. For example, specifying a Kubernetes Cluster alone does not provide the context necessary to troubleshoot. In order to narrow down the issue, add further contextual information, such as Kubernetes Namespace, Kubernetes Deployment, and so on.\nSpecify Entity Select an entity whose downtime you want to monitor for.\nIn this example, you are monitoring the unscheduled downtime of a host.\nSpecify additional segments:\nThe specified entities are segmented on and notified with the default notification template as well as on the Preview. In this example, data is segmented on Kubernetes cluster name and namespace name. When a cluster is affected, the notification will not only include the affected cluster details but also the associated namespaces.\nConfigure ScopeFilter the environment on which this alert will apply. An alert will fire when a host goes down in the availability zone, us-east-1b.\nUse in or contain operators to match multiple different possible values to apply scope.\nThe contain and not contain operators help you retrieve values if you know part of the values. For example, us retrieves values that contain strings that start with \u0026ldquo;us\u0026rdquo;, such as \u0026ldquo;us-east-1b\u0026rdquo;, \u0026ldquo;us-west-2b\u0026rdquo;, and so on.\nThe in and not in operators help you filter multiple values.\nYou can also create alerts directly from Explore and Dashboards for automatically populating this scope.\nConfigure TriggerDefine the threshold and time window for assessing the alert condition. Supported time scales are minute, hour, or day.\nIf the monitored host or Kubernetes cluster is not available or not responding for the last 10 minutes, recipients will be notified.\nYou can set any value for % and a value greater than 1 for the time window. For example, If you choose 50% instead of 100%, a notification will be triggered when the entity is down for 5 minutes in the selected time window of 10 minutes.\nUse Cases Your e-commerce website is down during the peak hours of Black Friday, Christmas, or New Year season.\nProduction servers of your data center experience a critical outage\nMySQL database is unreachable\nFile upload does not work on your marketing website.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/-legacy-alerts-editor/legacy-downtime-alert/"},{"id":497,"title":"Local Scanning","content":"What is Local Scanning?Local Scanning lets Sysdig analyze container images directly on your Kubernetes nodes, instead of relying solely on Cluster Shield to pull them from registries for runtime scanning.\nOn each node, Sysdig:\nReads container images from the container runtime (Docker, containerd, CRI-O, etc.). Builds a Software Bill of Materials (SBOM) locally. Sends SBOMs and metadata to the backend for vulnerability matching. Image layers and source code never leave your environment. This maximizes coverage in restricted, air-gapped, or complex environments while keeping images and proprietary code securely inside your own infrastructure.\nNote: Cluster Shield also extracts SBOMs inside your environment and sends only SBOMs/metadata to the backend. The key difference with Local Scanning is where the image is read from (registry vs. node runtime) and which component does the SBOM extraction.\nWhen to Use Local ScanningBoth Cluster Shield and Local Scanning generate SBOMs inside your environment and send only SBOMs and scan metadata to the Sysdig backend. Images are never uploaded to Sysdig.\nThe key difference is from where the image is read:\nCluster Shield pulls images from registries and extracts SBOMs from those registry images. Local Scanning (Host Shield) reads images directly from node runtimes and extracts SBOMs from node images. Local Scanning is particularly valuable when:\nRegistries are hard to use for runtime scanning. For example, they are private, behind firewalls, or require complex per-cluster credentials and networking. You want to reduce operational friction around configuring registry access for every cluster and every environment. You run air-gapped clusters or have embedded / locally built images (such as images built directly on nodes or stored only in internal OpenShift registries) that are not reliably available from a central registry. Network egress between clusters and registries is constrained or expensive, and you want to avoid repeatedly pulling large images just to scan them at runtime. You want stronger control over data residency, ensuring that image layers and source code never leave your infrastructure, regardless of how registries are deployed. You need robust runtime coverage for short-lived Jobs, CronJobs, and init/sidecar/ephemeral containers in environments where registry-based runtime scanning is difficult to operate reliably. Note: Local Scanning complements, but does not replace, pre-deployment scanning (Pipeline/CLI) or Admission Control. Admission Control still relies on being able to pull images from registries at admission time.\nHigh-Level ArchitectureLocal Scanning is implemented by the Host Shield and Cluster Shield working together:\nHost Shield (Node-level local image analysis): Runs on every Kubernetes node. Reads container images directly from the node\u0026rsquo;s runtime. Extracts SBOMs and reuses existing SBOMs when possible. Streams only metadata SBOMs and/or SBOM references to the backend. Cluster Shield (Kubernetes metadata \u0026amp; control plane): Connects to the Kubernetes API and collects workload metadata. Maps scan results to Pods, Deployments, DaemonSets, StatefulSets, Jobs, CronJobs, and init/sidecar/ephemeral containers. Can still perform registry-based image scans for scenarios such as Admission Control and non-runtime workloads. Sysdig Backend (Vulnerability matching \u0026amp; reporting): Matches SBOMs against vulnerability intelligence. Correlates with Kubernetes context from the Cluster Shield. Exposes unified findings in the Runtime Vulnerabilities views and APIs. The image_source setting ensures Host Shield acts as the primary runtime scanner when Local Scanning is enabled, avoiding duplicate work with the Cluster Shield.\nCoverage and LimitationsWhat Local Scanning CoversWith Local Scanning enabled, Sysdig is designed to cover:\nRunning Pods, including main application containers, sidecars, init containers, and ephemeral containers (subject to runtime/event support). Short-lived workloads (Jobs): Images are scanned locally, and results are retained for a defined period. CronJobs: Job-runs are scanned when they execute on nodes, and results are mapped back to CronJob definitions. Multiple clusters: SBOMs are reused whenever the same image digest runs in more than one cluster. What Local Scanning Does Not Cover Zero-replica workloads: Workload definitions with zero replicas (e.g., a Deployment not yet scaled up). If there are no Pods, there is no image on your nodes, and thus no local SBOM. Non-Kubernetes hosts: These are handled via standard host vulnerability scanning, not Local Scanning semantics. Admission Control: Admission decisions still rely on registry access at admission time. Local Scanning is primarily a runtime enhancement. PrerequisitesTo use Local Scanning, you need:\nA Sysdig Secure backend (SaaS or supported on-prem) with Vulnerability Management enabled. At least one Kubernetes cluster with: Host Shield deployed (via the unified shield chart). Cluster Shield deployed for full Kubernetes context (required for Local Scanning). Supported container runtimes enabled on nodes (containerd, docker, crio or podman). Network connectivity from nodes to the Sysdig backend endpoint (API and collector) for sending metadata and scan results. Enabling Local ScanningLocal Scanning is activated by configuring the shield Helm chart to use the node as the preferred image source for Kubernetes workloads.\n1. Ensure Host Shield and Host Scanner are AvailableHost Shield is installed as part of the unified shield chart. When you configure Local Scanning (see step 2), the host-scanner component is deployed and used to extract SBOMs from images on the node.\nIf you also want to enable host OS vulnerability scanning (in addition to Local Scanning), you can turn on host vulnerability management:\nfeatures: vulnerability_management: host_vulnerability_management: enabled: true Note: Enabling Local Scanning does not require you to enable full host OS scanning. Host Shield will still be used for local image analysis when image_source: node is set.\n2. Switch Workload Scanning to Use Local ImagesTell Sysdig to use the node as the image source instead of pulling from registries. Set image_source: node under the container_vulnerability_management block:\nfeatures: vulnerability_management: container_vulnerability_management: enabled: true target_workloads: kubernetes: enabled: true image_source: node # Enables Local Scanning in_use: enabled: true image_source: node: Host Shield is deployed and used to read images from node runtimes (Local Scanning). image_source: registry (Default): Cluster Shield pulls images from registries for runtime scanning. 3. (Optional) Configure Container RuntimesIn most environments, you do not need to configure runtimes manually; the chart sets defaults that work for common runtimes. If you need to manually configure or prioritize runtimes, you can adjust the internals block:\ninternals: vulnerability_management: host_scanner: container_runtimes: priority: - containerd - docker - crio Only runtimes listed under priority are enabled. Adjust the order to reflect the predominant runtime in your environment.\nVerifying Local Scanning is WorkingIn the Sysdig Secure UI Navigate to the Runtime vulnerabilities view (for example, Attack Surface \u0026gt; Vulnerability Findings \u0026gt; Vuln Runtime). Filter by asset.type = \u0026quot;workload\u0026quot; and your cluster name (e.g., kubernetes.cluster.name = \u0026quot;my-cluster\u0026quot;). You should see workloads backed by node-scanned images appearing with normal scan results. You can validate coverage for specific objects by filtering on:\nkubernetes.pod.container.name to confirm init or sidecar containers are successfully mapped. Specific Jobs/CronJobs to ensure short-lived workloads are being scanned and retained as expected. Logs and DiagnosticsFrom the Host Shield / Host Scanner pod logs, you should see:\nSBOM extraction events for containers on the node. Periodic workload updates and keepalives sent to the backend. Errors about local scanning not being available or the backend not supporting workload scanning usually indicate a configuration or version mismatch.\nTroubleshooting ChecklistIf you don\u0026rsquo;t see expected scan results for Kubernetes workloads:\nConfirm Host Shield deployment: Verify pods are running on the nodes you expect to scan, and that Host Shield is correctly installed with the shield chart. If you enabled host OS scanning, confirm host_vulnerability_management.enabled is true. Check container runtime configuration: Ensure the actual runtime used by your nodes (e.g., containerd, crio) is supported and listed in the container_runtimes.priority block if you customized it. Verify Local Scanning is enabled: Check that image_source: node is correctly applied under features.vulnerability_management.container_vulnerability_management.target_workloads.k8s. Confirm Cluster Shield is healthy: Cluster Shield is required for Local Scanning (kubernetes-metadata must be enabled). Ensure it can read the Kubernetes API and is actively sending workload metadata. Runtime views should show workloads for the relevant cluster even before scans complete. Look at workload lifecycle: Zero-replica Deployments and never-run CronJobs won\u0026rsquo;t have runtime scans until Pods are actively scheduled to nodes (or until any pre-execution CronJob scanning feature is enabled in your environment). Review logs: Check Host Shield / Host Scanner logs. Errors about \u0026ldquo;kubernetes container detection is enabled but it is not supported by the backend\u0026rdquo; or \u0026ldquo;backend does not support workload scanning\u0026rdquo; or \u0026ldquo;detected cluster name conflict: an existing Cluster Shield instance with Container Vulnerability Management enabled is already using \u0026lt;cluster_name\u0026gt;\u0026rdquo; usually indicate a version or configuration mismatch between Host Shield capabilities and the Sysdig backend. ","url":"https://docs.sysdig.com/en/sysdig-secure/local-scanning/"},{"id":498,"title":"Manage Scanning Policies","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nImage scanning policies define several scenarios, such as:\nThe build process may be stopped.\nAdministrators may be alerted to potential risks within container images.\nEach scanning policy is comprised of rules built of gates and triggers. Sysdig includes default policies that can be used to run scans as soon as registry credentials have been configured.\nUsers can create additional rules or policies from the available Scanning Policy Gates and Triggers.\nPreconfigured PoliciesSysdig provides a number of Default (read-only) baseline policies that can be used as-is or as templates on which to build.\nDefaultPolicyThis policy covers the most common image scanning cases, such as:\nchecking for high vulnerabilities that have a fix available\nchecking Dockerfile best practices (e.g., ensuring health checks in an image or disallowing exposed ports)\nvalidating that the vulnerability feed data is up-to-date.\nThis policy is a basic catch-all that cannot be deleted. If no other policy assignments are made, the Default policy is automatically used.\nDockerfile Best PracticesThis policy provides out-of-the-box rules around Dockerfile best practices, such as disallowing:\nsecrets baked in as environment variables\nroot user configuration\nexposed ports\nrun instructions that include yum upgrades.\nPreconfigured Compliance PoliciesThe remaining preconfigured default policies deal with compliance rules such as NIST 800, PCI, GDPR, HIPAA, ISO 270001:2013 and SCO2\nAudit Policy - NIST 800-190This policy maps NIST 800-190 controls to a Sysdig Secure scanning policy, such as disallowing:\nnon-official node or Ruby packages\nadd instructions in a Docker file\nthe use of base distributions outside of expected values.\nAudit Policy - PCIThis policy maps PCI (Payment Card Industry) controls to a Sysdig Secure scanning policy, such as disallowing vulnerabilities or credentials to be included in the image.\nCustomized PoliciesYou can\u0026rsquo;t edit a Default Policy - instead use the Duplicate Policy function and then customize it.\nCreate a Scanning Policy From the Image Scanning module, select Scanning Policies and click Add Policy(+).\nThe New Policy page is displayed.\nDefine a Name and an optional Descriptionfor the new policy.\nAdd a Rule:\nSelect the Gate and then the Triggerfrom the drop-down menus.\nConfigure relevant parameters. (Some triggers do not require parameters to be set.)\nThe example below uses the vulnerabilities gate with the package trigger.\nOptional: Repeat step 5 to add rules as necessary.\nClick Save.\nEdit a Policy From the Image Scanning module, select Scanning Policies.\nSelect the desired policy from the list.\nEdit the policy rules as required, and click Save Policy.\nDelete a Policy From the Image Scanning module, select Scanning Policies.\nSelect the desired policy from the list.\nClick the Delete (trash can) icon and choose Yes to confirm the change.\nGlobally Trust|UntrustYou can add images to a globally trusted or untrusted list, or put CVEs on defined Global Exceptions lists, if desired. This does not affect the policy evaluation order.\nManage Policy AssignmentsUnless you use a very simple, single-policy approach to scanning, you will probably assign particular policies to particular registries, repositories, or tags.\nUse the Policy Assignments page to do this.\nFor example:\nTo evaluate all images with a \u0026ldquo;Prod\u0026rdquo; tag with your Example Prod Image Policy, use the assignment (registry/repo/tag): */*/Prod\nTo evaluate all images from gcr.io with an Example Google Policy, use the assignment (registry/repo/tag): gcr.io/*/*\nAssign a Policy From the Image Scanning module, select Scanning Policies and choose +Policy Assignments.\nThe previously defined assignments are listed in priority order.\nClick +Add Policy Assignment.\nA new entry line appears at the top of the Assignment page. Enter the desired assignment details:\nPriority: Priority is the order of evaluation against the assigned policy. Each new assignment is auto-placed at Priority 1. Once a policy assignment is created and saved, you can change its priority order by dragging it into a new position on the list.\nRegistry: Any registry domain (e.g. quay.io). Wildcards are supported; an asterisk * specifies any registry.\nRepository: Any repository (typically = name of the image). Wildcards are supported; an asterisk * specifies any repository.\nTag: Any tag. Wildcards are supported; an asterisk * specifies any tag.\nAssigned Policy: Name of policy to use for evaluation. Select from the drop-down menu.\nClick Save.\nOptional: Reorganize the Priority order by clicking the drag handle (the four dots to the left of a line) and dragging the assignment to a different spot on the list.\nUsing PrioritiesWhen you use more than one scanning policy, the Anchore engine evaluates them in top-down order, starting from Priority 1 in the Policy Assignment list. The first policy assignment rule that matches an input image will be evaluated, and all subsequent rules ignored. Therefore, the priority order is important.\nFor example, imagine a list with two defined policy assignments:\nPriority 1 Registry = quay.io Repository = sysdig/*\nPriority 2 Registry = quay.io Repository = sysdig/myrepo\nSince the first rule uses a wild card, the evaluation applies to all repos beginning with sysdig/ and will stop before evaluating sysdig/myrepo.\nReverse the priority order to get the behavior you want.\nThere is a catch-all entry at the bottom of the Policy Assignment list that cannot be removed. It has the format :\nregistry = * repository = * tag = * assigned policy = default (You can change the assigned policy, but other fields cannot be edited.)\nThe purpose of this row is to ensure that any registries that do not fall under another policy evaluation will at least be evaluated against the system-configured DefaultPolicy.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/manage-scanning-policies/"},{"id":499,"title":"Manual Installation on OpenShift","content":" All on-premises installations and upgrades are now scheduled with and guided by Sysdig technical account managers and professional services division. See Oversight Services Now Offered for All Installs and Upgrades.\nAs of Sysdig Platform v 2.5.0, a semi-automated install option is available and is preferred. This section describes how to install the backend components of the Sysdig platform using an existing OpenShift cluster. It applies to backend versions 1929 and higher.\nIntroductionThe Sysdig platform includes both Sysdig Monitor and Sysdig Secure, which are licensed separately. All installations include Sysdig Monitor, while some of the Secure components are installed and configured as additional steps within the overall installation process. When installing the Sysdig platform on OpenShift manually, you will install each backend component with separate oc commands.\nPrerequisitesOverview Access to a running OpenShift v4 instance\nTwo items from your Sysdig purchase-confirmation email:\nYour Sysdig license key\nYour Sysdig quay.io pull secret\noctools installed on your machine and communicating with the OpenShift cluster. (Note that your oc and OpenShift versions should match to avoid errors.)\nDNS PreparationIf you want more information on OpenShift\u0026rsquo;s DNS requirements; see the OpenShift documentation.\nOption 1: DNS without Wildcard\nYou need to request two different DNS records from your DNS team: one for the Sysdig API/UI and another for the Sysdig collector. These records should point to your infrastructure nodes and are the two routes that will be exposed, i.e., sysdig.api.example.com and sysdig.collector.example.com.\nOption 2: DNS with Wildcard\nWith wildcard DNS, you do not have to make an official request from the DNS team. Your implementation team can pick any two DNS names to use for the API/UI and Collector. These will be exposed to the infrastructure nodes once the configuration is completed. (i.e. sysdig.api.example.com and sysdig.collector.example.com.)\nSSL Certificate PreparationStep 5: Set Up SSL Connectivity to the Backend discusses how to implement SSL; decide ahead of time whether you will use SSL with wildcard or without.\nSSL with Wildcard\nWith wildcard SSL, you use the same certificate for both the API and the collector.\nSSL without Wildcard\nYou need two SSL certs, one for each DNS record.\nConsider Elasticsearch Default PrivilegesBy default, the Elasticsearch container will be installed in privileged (root-access) mode. This mode is only needed so the container can reconfigure the hosts\u0026rsquo; Linux file descriptors if necessary. See Elasticsearch\u0026rsquo;s description.\nIf you prefer not to allow Elasticsearch to run with root access to the host, you will need to:\nSet your own file descriptors on all Linux hosts in the Kubernetes cluster.\nIf one host were to go down, Kubernetes could choose a different node for Elasticsearch, so each Linux host must have the file descriptors set.\nSet privileged:false in the elasticsearch-statefulset.yaml file.\nSee the step under Configure Backend Components, below, for details.\nPrepare the EnvironmentStep 1 Download and Unpack the Latest Release Download the latest release from https://github.com/draios/sysdigcloud-kubernetes/releases/latest\nUnpack the .tar ball.\nThe source link has the format: https://github.com/draios/sysdigcloud-kubernetes/archive/\u0026lt;v1234\u0026gt;.tar.gz.To unpack it, run the following commands (replacing version number as appropriate):\nwget https://github.com/draios/sysdigcloud-kubernetes/archive/\u0026lt;v1234\u0026gt;.tar.gz tar zxf \u0026lt;1234\u0026gt;.tar.gz cd sysdigcloud-kubernetes-\u0026lt;1234\u0026gt; Create a new project called sysdigcloud and copy the cloned folders into it:\noc new-project sysdigcloud Apply the correct security contexts to the namespace. (This allows you to run privileged containers in the sysdigcloud namespace)\noc adm policy add-scc-to-user anyuid -n sysdigcloud -z default oc adm policy add-scc-to-user privileged -n sysdigcloud -z default Step 2: Configure Backend ComponentsThe ConfigMap (config.yaml) is populated with information about usernames, passwords, SSL certs, and various application-specific settings.\nThe steps below give the minimum edits that should be performed in a test environment.\nIt is necessary to review and customize the entries in config.yaml before launching in a production environment.\nSee Making Configuration Changes, below, for the oc format to use for post-install edits, such as adding 3rd-party authenticators such as LDAP.\nAdd your license key:\nIn config.yaml, enter the key that was emailed to you in the following parameter:\n# Required: Sysdig Cloud license sysdigcloud.license: \u0026#34;\u0026#34; Change the super admin name and password, which are the super admin credentials for the entire system. See here for details.\nFind the settings in config.yaml here:\nsysdigcloud.default.user: test@sysdig.com # Required: Sysdig Cloud super admin user password # NOTE: Change upon first login sysdigcloud.default.user.password: test **Edit the collector endpoint and API URL:**Change the placeholder to point to the DNS names you have established for Sysdig.\nRemember that you must have defined one name for the collector and another for the API URL.\nNote: Change the collector port to 443. ```yaml collector.endpoint: \u0026lt;COLLECTOR_DNS_NAME\u0026gt; collector.port: \u0026quot;443\u0026quot; api.url: https://\u0026lt;API_DNS_NAME\u0026gt;:443 ``` Recommended: edit the file to set the JVM options for Cassandra, Elasticsearch, and API, worker, and collector as well.\n(To use the AWS implicit key, edit the JVM options as described in AWS: Integrate AWS Account and CloudWatch Metrics (Optional).)\nFor installations over 100 agents, it is recommended to allocate 8 GB of heap per JVM.\ncassandra.jvm.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; elasticsearch.jvm.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; sysdigcloud.jvm.api.options: \u0026#34;-Xms4G -Xmx8G\u0026#34; sysdigcloud.jvm.worker.options: \u0026#34;-Xms4G -Xmx8G\u0026#34; sysdigcloud.jvm.collector.options: \u0026#34;-Xms4G -Xmx8G\u0026#34; Note: If you do not wish to use SSL between the agent and the collector, use the following settings instead:\ncassandra.jvm.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; elasticsearch.jvm.options: \u0026#34;-Xms8G -Xmx8G\u0026#34; sysdigcloud.jvm.api.options: \u0026#34;-Xms8G -Xmx8G -Ddraios.agents.installParams.sslEnabled=false\u0026#34; sysdigcloud.jvm.worker.options: \u0026#34;-Xms8G -Xmx8G -Ddraios.agents.installParams.sslEnabled=false\u0026#34; sysdigcloud.jvm.collector.options: \u0026#34;-Xms8G -Xmx8G -Ddraios.agents.installParams.sslEnabled=false\u0026#34; Optional: Change ElasticSearch container setting to non-privileged.\nTo change the default setting, edit the file elasticsearch-statefulset.yaml and set privileged: false.\ncontainers: - name: elasticsearch image: quay.io/sysdig/elasticsearch:5.6.16.15 securityContext: privileged: false Deploy the configuration maps and secrets for all services by running the commands:\nFor Sysdig Monitor:\noc -n sysdigcloud apply -f sysdigcloud/config.yaml **(Sysdig Secure only) Edit and apply secrets for Anchore and the scanning component:**Edit theyaml files:\nscanning-secrets.yaml\nstringData: scanning.mysql.password: change_me anchore-secrets yaml\nstringData: anchore.admin.password: change_me anchore.db.password: change_me policy-advisor-secret.yaml\nstringData: padvisor.mysql.password: change_me Then apply the files:\noc -n sysdigcloud apply -f sysdigcloud/scanning-secrets.yaml oc -n sysdigcloud apply -f sysdigcloud/anchore-secrets.yaml oc -n sysdigcloud apply -f sysdigcloud/policy-advisor-secret.yaml Edit the API DNS name in either api-ingress.yaml or api-ingress-with-secure.yaml (if using Secure).\nThe files are located in sysdigcloud/\nspec: rules: - host: \u0026lt;API_DNS_NAME\u0026gt; ... tls: - hosts: - \u0026lt;API_DNS_NAME\u0026gt; secretName: sysdigcloud-ssl-secret Edit the collector DNS name in the file openshift-collector-router.yaml. Use the collector DNS name you created in the Prerequisites.\nThe file is located in sysdigcloud/openshift/.\nspec: host: \u0026lt;COLLECTOR_DNS_NAME\u0026gt; Step 3 (Secure-Only): Edit mysql-deployment.yamlIf using Sysdig Secure :\nEdit the MySQL deployment to uncomment the MYSQL_EXTRADB_* environment variables. This forces MySQL to create the necessary scanning database on startup.\nFile location: datastores/as_kubernetes_pods/manifests/mysql/mysql-deployment.yaml\n- name: MYSQL_EXTRADB_SCANNING_DBNAME valueFrom: configMapKeyRef: name: sysdigcloud-config key: scanning.mysql.dbname - name: MYSQL_EXTRADB_SCANNING_USER valueFrom: configMapKeyRef: name: sysdigcloud-config key: scanning.mysql.user - name: MYSQL_EXTRADB_SCANNING_PASSWORD valueFrom: secretKeyRef: name: sysdigcloud-scanning key: scanning.mysql.password The scanning service will not start unless MySQL creates the scanning database.\nStep 4: Deploy Your Quay Pull SecretA specific Quay pull secret is sent via email with your license key.\nEdit the file sysdigcloud/pull-secret.yaml and change the place holder \u0026lt;PULL_SECRET\u0026gt; with the provided pull secret.\nvi sysdigcloud/pull-secret.yaml\n--- apiVersion: v1 kind: Secret metadata: name: sysdigcloud-pull-secret data: .dockerconfigjson: \u0026lt;PULL_SECRET\u0026gt; type: kubernetes.io/dockerconfigjson Deploy the pull secret object:\noc -n sysdigcloud apply -f sysdigcloud/pull-secret.yaml Step 5: Set Up SSL Connectivity to the BackendSSL-secured communication is used between user browsers and the Sysdig API server(s), and between the Sysdig agent and the collectors.\nTo set this up, you must:\nUse an existing wildcard SSL certificate and key, or\nUse existing standard certs for API and collector, or\nCreate self-signed certificates and keys for API and collector\nIf you are not using wildcard SSL, you have to use two separate certificates, one for API URL and one for the collector.\nTo disable SSL between agent and collector:\nTo disable SSL between agent and collectors, you set a JVM option when configuring backend components (below).\nTo create self-signed certs:\nRun these commands (edit to add your API_DNS_NAMEand COLLECTOR_DNS_NAME):\nopenssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj \u0026#34;/C=US/ST=CA/L=SanFrancisco/O=ICT/CN=\u0026lt;API_DNS_NAME\u0026gt;\u0026#34; -keyout server.key -out server.crt openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 -subj \u0026#34;/C=US/ST=CA/L=SanFrancisco/O=ICT/CN=\u0026lt;COLLECTOR_DNS_NAME\u0026gt;\u0026#34; -keyout collector.key -out collector.crt To use an existing wildcard cert:\nObtain the respective server.crt and server.key files.\nTo Create Kubernetes Secrets for the CertsWith Wildcard\nUses the same certificate for both the API/UI and the collector.\nRun these commands:\noc -n sysdigcloud create secret tls sysdigcloud-ssl-secret --cert=server.crt --key=server.key oc -n sysdigcloud create secret tls sysdigcloud-ssl-secret-collector --cert=server.crt --key=server.key Without Wildcard\nUses two different certificates, one for the API/UI, and one for the collector.\nRun these commands:\noc -n sysdigcloud create secret tls sysdigcloud-ssl-secret --cert=server.crt --key=server.key oc -n sysdigcloud create secret tls sysdigcloud-ssl-secret-collector --cert=collector.crt --key=collector.key Step 6: (Optional) Use CA Certs for External SSL ConnectionsThe Sysdig platform may sometimes open connections over SSL to certain external services, including:\nLDAP over SSL\nSAML over SSL\nOpenID Connect over SSL\nHTTPS Proxies\nIf the signing authorities for the certificates presented by these services are not well-known to the Sysdig Platform (for example, if you maintain your own Certificate Authority), they are not trusted by default.\nTo allow the Sysdig platform to trust these certificates, use the command below to upload one or more PEM-format CA certificates. You must ensure you\u0026rsquo;ve uploaded all certificates in the CA approval chain to the root CA.\noc -n sysdigcloud create secret generic sysdigcloud-java-certs --from-file=certs1.crt --from-file=certs2.crt Install Components (OpenShift)Edit storageClassName ParametersYou need a storage class; step 2 shows how to create one if needed.\nEnter the storageClassName in the appropriate .yaml files (see step 3).\nVerify whether a storage class has been created, by running the command:\noc get storageclass If no storage class has been defined, create a manifest for one, and then deploy it.\nFor example, a manifest could be named sysdigcloud-storageclass.yamland contain the following contents (for a storage class using GP2 volumes in AWS):\napiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: gp2 labels: kubernetes.io/cluster-service: \u0026#34;true\u0026#34; addonmanager.kubernetes.io/mode: EnsureExists provisioner: kubernetes.io/aws-ebs parameters: type: gp2 Now run the command:\noc apply -f sysdigcloud-storageclass.yaml Using either the existing storage class name from step 1, or the storage class name defined in step 2, edit the storageClassName in the following .yaml files:\nFor Monitor:\ndatastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml datastores/as_kubernetes_pods/manifests/mysql/mysql-deployment.yaml With Secure:\ndatastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml In each file, the code snippet looks the same:\nvolumeClaimTemplates: - metadata: name: data spec: accessModes: [\u0026#34;ReadWriteOnce\u0026#34;] resources: requests: storage: 50Gi storageClassName: \u0026lt;STORAGECLASS_NAME\u0026gt; Install Datastores and Backend ComponentsFor Sysdig Monitor\nCreate the datastore statefulsets for Elasticsearch and Cassandra. Elasticsearch and Cassandra are automatically set up with --replica=3 generating full clusters.\noc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-service.yaml oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/cassandra/cassandra-statefulset.yaml oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-service.yaml oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/elasticsearch/elasticsearch-statefulset.yaml Wait for those processes to be running, then create the MySQL and Redis databases:\noc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/mysql/mysql-deployment.yaml oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/redis/redis-deployment.yaml To add Sysdig Secure: Create the PostgreSQL database:\noc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-service.yaml oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/postgres/postgres-statefulset.yaml Wait until datastore pods are in ready state, then deploy the backend deployment sets (worker, collector, and API).\nRun the command:\nkubectl -n sysdigcloud get pods Then look in the READY column to ensure all pods are ready. For example, displaying a 1/1 means 1 of 1 pods is ready.\nApply the NATS service and deployment to deliver events to Sysdig backend components:\noc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/nats-streaming/nats-streaming-deployment.yaml oc -n sysdigcloud apply -f datastores/as_kubernetes_pods/manifests/nats-streaming/nats-streaming-service.yaml Then deploy the backend deployment sets (worker, collector, and API). Pause for 60 seconds after creating the API deployment.\noc -n sysdigcloud apply -f sysdigcloud/api-deployment.yaml oc -n sysdigcloud apply -f sysdigcloud/openshift/openshift-collector-deployment.yaml oc -n sysdigcloud apply -f sysdigcloud/worker-deployment.yaml Create the service for the API and collector:\noc -n sysdigcloud apply -f sysdigcloud/api-headless-service.yaml oc -n sysdigcloud apply -f sysdigcloud/openshift/openshift-collector-service.yaml For Sysdig Secure Wait for the API, worker, and collector to come up before proceeding.\nThen create anchore-engine deployments and service (used in scanning):\noc -n sysdigcloud apply -f sysdigcloud/anchore-service.yaml oc -n sysdigcloud apply -f sysdigcloud/anchore-core-config.yaml oc -n sysdigcloud apply -f sysdigcloud/anchore-core-deployment.yaml oc -n sysdigcloud apply -f sysdigcloud/anchore-worker-config.yaml oc -n sysdigcloud apply -f sysdigcloud/anchore-worker-deployment.yaml Wait 60 seconds to ensure the core-deployment is in Running status, then deploy the rest of the Secure-related yaml files:\noc -n sysdigcloud apply -f sysdigcloud/scanning-service.yaml oc -n sysdigcloud apply -f sysdigcloud/scanning-api-deployment.yaml oc -n sysdigcloud apply -f sysdigcloud/scanning-alertmgr-service.yaml oc -n sysdigcloud apply -f sysdigcloud/scanning-alertmgr-deployment.yaml Sysdig Secure only Create services, deployments, and a janitor job for the activity audit and policy advisor features:\noc -n sysdigcloud apply -f sysdigcloud/policy-advisor-service.yaml oc -n sysdigcloud apply -f sysdigcloud/activity-audit-api-service.yaml oc -n sysdigcloud apply -f sysdigcloud/activity-audit-api-deployment.yaml oc -n sysdigcloud apply -f sysdigcloud/policy-advisor-deployment.yaml oc -n sysdigcloud apply -f sysdigcloud/activity-audit-worker-deployment.yaml oc -n sysdigcloud apply -f sysdigcloud/activity-audit-janitor-cronjob.yaml Configure Access for Connectivity to the ClusterApply the appropriate ingress yaml. (The API_DNS name was entered in step 7, in Step 2: Configure Backend Components This configures the route to the Sysdig UI.\nFor Sysdig Monitor\noc -n sysdigcloud apply -f sysdigcloud/api-ingress.yaml With Sysdig Secure:\noc -n sysdigcloud apply -f sysdigcloud/api-ingress-with-secure.yaml Configure connectivity to the collector for the agent:\noc -n sysdigcloud apply -f sysdigcloud/openshift/openshift-collector-router.yaml Apply Configuration ChangesReplace kubectl with oc for OpenShift.\nUpdate the Config MapThere are two ways to change the original installation parameters in the config map: edit or overwrite.\nTo edit the config map, run the following command:\nkubectl edit configmap/sysdigcloud-config --namespace sysdigcloud A text editor is presented with the config map to be edited. Enter parameters as needed, then save and quit.\nThen restart the config map (below).\nTo overwrite the config map that is edited on the client-side, (e.g. to keep it synced in a git repository), use the following command:\nkubectl replace -f sysdigcloud/config.yaml --namespace sysdigcloud Then restart the config map (below).\nRestart ConfigmapAfter updating the configmap, the Sysdig components must be restarted for the changed parameters to take effect. This can be done by forcing a rolling update of the deployments.\nA possible way to do so is to change something innocuous, which forces a rolling update. E.g.:\nkubectl -n sysdigcloud patch deployment [deploymnet] -p \\ \u0026#34;{\\\u0026#34;spec\\\u0026#34;:{\\\u0026#34;template\\\u0026#34;:{\\\u0026#34;metadata\\\u0026#34;:{\\\u0026#34;annotations\\\u0026#34;:{\\\u0026#34;date\\\u0026#34;:\\\u0026#34;$(date +\u0026#39;%s\u0026#39;)\\\u0026#34;}}}}}\u0026#34; Replace kubectl with oc for OpenShift.\n","url":"https://docs.sysdig.com/en/administration/onprem-manual-installation-openshift/"},{"id":500,"title":"Memcached","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v1.5\nThis integration uses a sidecar exporter that is available in UBI or scratch base image.\nThis integration has 13 metrics.\nTimeseries generated: 20 series per instance\nList of Alerts Alert Description Format [Memcached] Instance Down Instance is not reachable Prometheus [Memcached] Low UpTime Uptime of less than 1 hour in a Memcached instance Prometheus [Memcached] Connection Throttled Connection throttled because max number of requests per event process reached Prometheus [Memcached] Connections Close To The Limit 85% The mumber of connections are close to the limit Prometheus [Memcached] Connections Limit Reached Reached the number of maximum connections and caused a connection error Prometheus List of DashboardsMemcachedThe dashboard provides information on the status and performance of the Memcached instance. List of Metrics Metric name memcached_commands_total memcached_connections_listener_disabled_total memcached_connections_yielded_total memcached_current_bytes memcached_current_connections memcached_current_items memcached_items_evicted_total memcached_items_reclaimed_total memcached_items_total memcached_limit_bytes memcached_max_connections memcached_up memcached_uptime_seconds PrerequisitesNone.\nInstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/memcached-exporter\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: memcached-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;memcached\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (memcached_commands_total|memcached_connections_listener_disabled_total|memcached_connections_yielded_total|memcached_current_bytes|memcached_current_connections|memcached_current_items|memcached_items_evicted_total|memcached_items_reclaimed_total|memcached_items_total|memcached_limit_bytes|memcached_max_connections|memcached_up|memcached_uptime_seconds) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/memcached/"},{"id":501,"title":"Configure Microsoft Entra ID for SAML","content":"Prerequisites Administrator privileges on Sysdig and Microsoft Entra ID. Get the Redirect URLs for Authentication. Configure the Sysdig Application in Microsoft Entra ID Log in to the Microsoft Entra ID portal.\nSelect Enterprise Applications.\nThe Enterprise applications - All application screen is displayed.\nClick New Application.\nOn the Add an Application screen, select Non-gallery application.\nGive your application a name, and click Add at the bottom of the page.\nOn the menu, select Single sign-on.\nChoose SAML as the sign-on method.\nEdit the Basic SAML Configuration as follows:\nIn the configuration page, click the edit icon. Specify the following:\nIdentifier (Entity ID): Uniquely identifies the Sysdig application. Entra ID sends the identifier to the Sysdig application as the audience parameter of the SAML token. Sysdig validates this as part of the SSO process.\nFind the entity ID for your SaaS region in Redirect URLs for Authentication. For example, the identifier for Sysdig Monitor for the EU Central region is https://eu1.app.sysdig.com and for Sysdig Secure is https://eu1.app.sysdig.com/secure/.\nIf you are using multiple integrations, or are integrating with multiple tenants from the same Microsoft Entra ID, enable the option Unique Entity ID later when you Configure Sysdig.\nReply URL: Specifies where Sysdig expects to receive the SAML token.\nFind the appropriate URL for your SaaS region in Redirect URLs for Authentication. For example, the identifier for Sysdig Monitor for the EU region is https://eu1.app.sysdig.com/api/saml/auth and for Sysdig Secure is https://eu1.app.sysdig.com/api/saml/secureAuth.\nRelay State: Specifies to the application where to redirect the user after authentication is completed. Typically, the value is a valid URL for Sysdig. If you are configuring SSO for SaaS, change the relay state to reflect the customer number associated with your Sysdig application.\nThe format is:\n#/\u0026amp;customer=1234 If you have defined an integration name or are using multiple integrations, include the integration name in the Relay State parameter using the following format:\n\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt; This combines to result in:\n#/\u0026amp;customer=1234\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt; For more information on configuration parameters, see the Microsoft documentation page Configure SAML-based single sign-on to non-gallery applications.\nTo enable Signed Assertion and Validate Signature, select Edit on SAML Certificates. In the Signing Option drop-down, select Sign SAML response and assertion.\nSelect Save.\nConfigure SysdigTo configure Sysdig for Microsoft Entra ID, ensure you have the correct parameters to hand, then proceed to the steps below.\nParameters Description Metadata Under SAML Signing Certificate, copy the App Federation Metadata URL. Email Parameter Copy the Full claim URL, including the Name and Namespace.For example, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/email First Name Parameter (Optional) Add a new claim including the following: Name: first nameNamespace: \u0026lt;leave blank\u0026gt;Source: AttributeSource attribute: user.givennameThe previous values are case-sensitive, so use caution when entering them. Last Name Parameter (Optional) Add a new claim including the following: Name: last nameNamespace: \u0026lt;leave blank\u0026gt;Source: AttributeSource attribute: user.surnameThe previous values are case-sensitive, so use caution when entering them. Once you have the necessary parameters, proceed with configuration in the Sysdig UI:\nLog in to Sysdig Monitor or Secure.\nNavigate to Settings via the user menu icon at the bottom of the left navigation bar.\nUnder Access \u0026amp; Secrets, select Authentication (SSO).\nEdit existing or create a new SSO integration (type: SAML).\nIn Metadata Enter the App Federation Metadata URL you copied.\nIn Email Parameter Set the value to the full claim URL. Ensure that the claim fully matches the Email parameter used in Sysdig UI.\nThe rest of the fields and toggles can be left as default.\nOnly email is a required claim, however, we recommend including first and last names for these values to be included in the records created in the Sysdig database when new users successfully log in via SAML for the first time.\nIf using multiple tenants or multiple integrations from the same Microsoft Entra ID, enable Unique Entity ID option and copy the Entity ID value.\nSelect Save Settings.\nEnable the integration by selecting the option from the Enabled column in the integration\nCreate a User in Microsoft Entra ID Domain Log in to the Microsoft Microsoft Azure portal.\nClick Entra ID, and note down the domain name.\nSelect Entra ID, then Users.\nThe Users - All Users screen is displayed.\nSelect New Users .\nYou can either create a new user or invite an existing one.\nEnter name, username, and other details, then click Create.\nIn the Profile page, add the Email and Alternate Email parameters.\nThe values can match.\nAssign the User to the Sysdig Application Navigate to the Sysdig application.\nClick Users and Group, then click the Add user button.\nSelect the Users and Groups checkbox, then choose the newly created user to add to the application.\nClick Select, then Assign at the bottom of the screen.\nEnable Authentication Settings in the Sysdig InstanceEnsure the flag to enable/disable create user on login is enabled. Typically this setting is enabled by default.\nIf you are using both Sysdig Monitor and Secure, ensure that the user accounts are created on both the products. A user that is created only on one Sysdig application will not be able to log in to another through SAML SSO.\nIf you are on Sysdig Platform versions 2.4.1 or prior, contact Sysdig Support to help with user creation.\n(Optional) Configure Sysdig as a New ApplicationIf Microsoft Entra ID does not allow you to create Sysdig as a Non-Gallery application, perform the following:\nIn Entra ID, click Enterprise Applications \u0026gt; New Application.\nSelect Application you\u0026rsquo;re developing.\nYou will be taken to the app registration page:\nSelect New Registration:\nProvide a name for the application you are registering.\nEnter the redirect URI. Find the redirect URL in Redirect URLs for Authentication. For example, the redirect URI for Sysdig Monitor for the EU region is https://eu1.app.sysdig.com/api/saml/auth and for Sysdig Secure is https://eu1.app.sysdig.com/api/saml/secureAuth.\nClick Register to complete the registration.\nIn the Overview tab click Add an Application ID URI:\nClick Add a scope.\nAdd the application ID URI as follows:\nhttps://\u0026lt;your_sysdig_url\u0026gt;:443 Replace \u0026lt;your_sysdig_url\u0026gt; with the URL appropriate to your application and region. You can find the correct URL in SaaS Regions and IP Ranges.\nIn the Overview tab, click Endpoints, and copy the Federation Metadata URL.\nLog in to Sysdig, navigate to SAML Authentication screen, and enter the Federation Metadata URL.\nYou will still need to ensure that the user creation on the login option is enabled.\nSave the settings.\n","url":"https://docs.sysdig.com/en/administration/saas-entra-id-saml/"},{"id":502,"title":"Microsoft IIS","content":" This integration is disabled by default. Please refer to Enable and Disable Integrations to enable it in your account.\nThis integration has 56 metrics.\nThe metrics in this integration are scraped from the Windows Exporter in the Windows integration. To enable the IIS metrics in the Windows Exporter, add the iis collector to its config.yaml file.\nList of Alerts Alert Description Format [Microsoft IIS] Requests Temporarily Blocked Due To Bandwidth Throttling Requests have been temporarily blocked due to bandwidth throttling. Prometheus [Microsoft IIS] Requests Rejected Due To Bandwidth Throttling Requests have been temporarily rejected due to bandwidth throttling. Prometheus [Microsoft IIS] Too Many Recycles The application pool has been recycled too many times. Prometheus [Microsoft IIS] Worker Processes Crashing The worker processes have crashed too many times. Prometheus [Microsoft IIS] Worker Processes Ping Failing The Windows Process Activation Service (WAS) has failed multiple times to receive a response to ping messages sent to a worker process. Prometheus [Microsoft IIS] Worker Processes Startup Failing The Windows Process Activation Service (WAS) has failed multiple times to start a worker process. Prometheus [Microsoft IIS] Worker Processes Shutdown Failing The Windows Process Activation Service (WAS) has failed multiple times to shut down a worker process. Prometheus [Microsoft IIS] High 4XX Error Rate The percentage of 4XX errors is high. Prometheus [Microsoft IIS] High 5XX Error Rate The percentage of 5XX errors is high. Prometheus List of DashboardsMicrosoft IIS - OverviewThe dashboard provides an overview of the status and performance of the Microsoft IIS service. Microsoft IIS - Application Pools and WorkersThe dashboard provides information of the status and performance of the Microsoft IIS application pools and their workers. List of Metrics Metric name windows_iis_anonymous_users_total windows_iis_blocked_async_io_requests_total windows_iis_cgi_requests_total windows_iis_connection_attempts_all_instances_total windows_iis_current_anonymous_users windows_iis_current_application_pool_state windows_iis_current_blocked_async_io_requests windows_iis_current_cgi_requests windows_iis_current_connections windows_iis_current_isapi_extension_requests windows_iis_current_non_anonymous_users windows_iis_current_worker_processes windows_iis_files_received_total windows_iis_files_sent_total windows_iis_ipapi_extension_requests_total windows_iis_locked_errors_total windows_iis_logon_attempts_total windows_iis_non_anonymous_users_total windows_iis_not_found_errors_total windows_iis_received_bytes_total windows_iis_recent_worker_process_failures windows_iis_rejected_async_io_requests_total windows_iis_requests_total windows_iis_sent_bytes_total windows_iis_server_file_cache_hits_total windows_iis_server_file_cache_memory_bytes windows_iis_server_file_cache_queries_total windows_iis_server_metadata_cache_hits_total windows_iis_server_metadata_cache_queries_total windows_iis_server_output_cache_hits_total windows_iis_server_output_cache_memory_bytes windows_iis_server_output_cache_queries_total windows_iis_server_uri_cache_hits_total windows_iis_server_uri_cache_queries_total windows_iis_total_application_pool_recycles windows_iis_total_worker_process_failures windows_iis_total_worker_process_ping_failures windows_iis_total_worker_process_shutdown_failures windows_iis_total_worker_process_startup_failures windows_iis_worker_current_websocket_requests windows_iis_worker_file_cache_hits_total windows_iis_worker_file_cache_memory_bytes windows_iis_worker_file_cache_queries_total windows_iis_worker_metadata_cache_hits_total windows_iis_worker_metadata_cache_queries_total windows_iis_worker_output_cache_hits_total windows_iis_worker_output_cache_memory_bytes windows_iis_worker_output_queries_total windows_iis_worker_request_errors_total windows_iis_worker_requests_total windows_iis_worker_threads windows_iis_worker_uri_cache_hits_total windows_iis_worker_uri_cache_queries_total windows_iis_worker_websocket_connection_accepted_total windows_iis_worker_websocket_connection_attempts_total windows_iis_worker_websocket_connection_rejected_total PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting Microsoft IISThis document describes important metrics and queries that you can use to monitor and troubleshoot Microsoft IIS.\nServerRequestsRequests rateUse the following query to get the requests per second by each site.\nsum by (hostname, site)(rate(windows_iis_requests_total[2m])) Use the following query to get the requests per second by each site and each method.\nsum by (hostname, site, method)(rate(windows_iis_requests_total[2m])) Request ErrorsUse the following query to get the requests per second that have been made that were not satisfied by the server because the requested document was not found. These requests are usually reported as HTTP error 404.\nrate(windows_iis_not_found_errors_total[2m]) Use the following query to get the requests per second that have been made that could not be satisfied by the server because the requested document was locked. These requests are usually reported as HTTP error 423.\nrate(windows_iis_locked_errors_total[2m]) CGI, ISAPI and Async IOCGIUse the following query to get the number of CGI requests that are being processed simultaneously by the web service.\nwindows_iis_current_cgi_requests Use the following query to get the number of CGI requests per second.\nrate(windows_iis_cgi_requests_total[2m]) ISAPIUse the following query to get the number of ISAPI extension requests that are being processed simultaneously by the web service.\nwindows_iis_current_isapi_extension_requests Use the following query to get the number of ISAPI extension requests per second.\nrate(windows_iis_ipapi_extension_requests_total[2m]) Async IOUse the following query to get the number of current requests temporarily blocked due to bandwidth throttling settings.\nwindows_iis_current_blocked_async_io_requests Use the following query to get the number of requests temporarily blocked due to bandwidth throttling settings per second.\nrate(windows_iis_blocked_async_io_requests_total[2m]) Use the following query to get the number of requests rejected due to bandwidth throttling settings per second.\nrate(windows_iis_rejected_async_io_requests_total[2m]) Connections and UsersConnectionsUse the following query to get the current number of connections established with the web service.\nwindows_iis_current_connections Use the following query to get the number of connections to the web service that have been attempted per second.\nrate(windows_iis_connection_attempts_all_instances_total[2m]) Use the following query to get the number of attempts to log on to the web service that have occurred per second.\nrate(windows_iis_logon_attempts_total[2m]) UsersUse the following query to get the current number of users who currently have an anonymous request pending with the web service.\nwindows_iis_current_anonymous_users Use the following query to get the number of users who have established an anonymous request per second.\nrate(windows_iis_anonymous_users_total[2m]) Use the following query to get the current number of users who currently have a non-anonymous request pending with the web service.\nwindows_iis_current_non_anonymous_users Use the following query to get the number of users who have made non-anonymous requests to the web service per second.\nrate(windows_iis_non_anonymous_users_total[2m]) NetworkDataUse the following query to get the number of data bytes that have been sent by the web service per second.\nrate(windows_iis_sent_bytes_total[2m]) Use the following query to get the number of data bytes that have been received by the web service per second.\nrate(windows_iis_received_bytes_total[2m]) FilesUse the following query to get the number of files that have been sent by the FTP service per second.\nrate(windows_iis_files_sent_total[2m]) Use the following query to get the number of files that have been received by the FTP service per second.\nrate(windows_iis_files_received_total[2m]) Server CacheUse the following query to get the current number of bytes used by the file cache.\nwindows_iis_server_file_cache_memory_bytes Use the following query to get the percentage of successful lookups in the user-mode file cache.\n( rate(windows_iis_server_file_cache_hits_total[2m]) / rate(windows_iis_server_file_cache_queries_total[2m]) ) * 100 Use the following query to get the percentage of successful lookups in the URI cache.\n( sum by (hostname)(rate(windows_iis_server_uri_cache_hits_total[2m])) / sum by (hostname)(rate(windows_iis_server_uri_cache_queries_total[2m])) ) * 100 Use the following query to get the current number of bytes used by the output cache.\nwindows_iis_server_output_cache_memory_bytes Use the following query to get the percentage of successful lookups in the output cache.\n( rate(windows_iis_server_output_cache_hits_total[2m]) / rate(windows_iis_server_output_cache_queries_total[2m]) ) * 100 Use the following query to get the percentage of successful lookups in the metadata cache.\n( rate(windows_iis_server_metadata_cache_hits_total[2m]) / rate(windows_iis_server_metadata_cache_queries_total[2m]) ) * 100 Application Pools and WorkersApplication PoolsApplication Pools and Worker ProcessesUse the following query to get the state of the application pools.\nwindows_iis_current_application_pool_state \u0026gt; 0 The state of the application pools can be one of the following:\nUninitialized Initialized Running Disabling Disabled Shutdown Pending Delete Pending Use the following query to get the current number of worker processes that are running in the application pool.\nwindows_iis_current_worker_processes Use the following query to get the number of times that the application pool has been recycled per second.\nrate(windows_iis_total_application_pool_recycles[2m]) Worker Processes FailuresUse the following query to get the number of times that worker processes for the application pool failed during the rapid-fail protection interval.\nwindows_iis_recent_worker_process_failures Use the following query to get the number of times that worker processes have crashed per second.\nrate(windows_iis_total_worker_process_failures[2m]) Use the following query to get the number of times that the Windows Process Activation Service did not receive a response to ping messages sent to a worker process per second.\nrate(windows_iis_total_worker_process_ping_failures[2m]) Use the following query to get the number of times that the Windows Process Activation Service failed to start a worker process per second.\nrate(windows_iis_total_worker_process_startup_failures[2m]) Use the following query to get the number of times that Windows Process Activation Service failed to shut down a worker process per second.\nrate(windows_iis_total_worker_process_shutdown_failures[2m]) Worker RequestsHTTP Requests and ThreadsUse the following query to get the number of HTTP requests served by the application pool per second.\nsum by (hostname, app)(rate(windows_iis_worker_requests_total[2m])) Use the following query to get the number of HTTP requests that returned an error per second.\nsum by (hostname, app, status_code)(rate(windows_iis_worker_request_errors_total[2m])) Use the following query to get the percentage of HTTP requests that returned a 4XX error.\n( sum by (hostname, app)(rate(windows_iis_worker_request_errors_total{status_code=~\u0026#39;4..\u0026#39;}[2m])) / sum by (hostname, app)(rate(windows_iis_worker_requests_total[2m])) ) * 100 Use the following query to get the percentage of HTTP requests that returned a 4XX error.\n( sum by (hostname, app)(rate(windows_iis_worker_request_errors_total{status_code=~\u0026#39;5..\u0026#39;}[2m])) / sum by (hostname, app)(rate(windows_iis_worker_requests_total[2m])) ) * 100 Use the following query to get the number of threads actively processing requests in the the application pool.\nsum by (hostname, app, state)(windows_iis_worker_threads) Websocket RequestsUse the following query to get the number of active websocket requests in the the application pool.\nsum by (hostname, app)(windows_iis_worker_current_websocket_requests[2m]) Use the following query to get the number of accepted websocket requests in the the application pool per second.\nsum by (hostname, app)(rate(windows_iis_worker_websocket_connection_accepted_total[2m])) Use the following query to get the number of rejected websocket requests in the the application pool per second.\nsum by (hostname, app)(rate(windows_iis_worker_websocket_connection_rejected_total[2m])) Use the following query to get the percentage of websocket rejected requests.\n( sum by (hostname, app)(rate(windows_iis_worker_websocket_connection_rejected_total[2m])) / sum by (hostname, app)(rate(windows_iis_worker_websocket_connection_attempts_total[2m])) ) * 100 Worker CacheUse the following query to get the current number of bytes used by user-mode file cache.\navg by (hostname, app)(windows_iis_worker_file_cache_memory_bytes) Use the following query to get the percentage of successful lookups in the user-mode file cache.\n( avg by (hostname, app)(rate(windows_iis_worker_file_cache_hits_total[2m])) / avg by (hostname, app)(rate(windows_iis_worker_file_cache_queries_total[2m])) ) * 100 Use the following query to get the percentage of successful lookups in the user-mode URI cache.\n( avg by (hostname, app)(rate(windows_iis_worker_uri_cache_hits_total[2m])) / avg by (hostname, app)(rate(windows_iis_worker_uri_cache_queries_total[2m])) ) * 100 Use the following query to get the current number of bytes used by the output cache.\navg by (hostname, app)(windows_iis_worker_output_cache_memory_bytes) Use the following query to get the percentage of successful lookups in the output cache.\n( avg by (hostname, app)(rate(windows_iis_worker_output_cache_hits_total[2m])) / avg by (hostname, app)(rate(windows_iis_worker_output_queries_total[2m])) ) * 100 Use the following query to get the percentage of successful lookups in the user-mode metadata cache.\n( avg by (hostname, app)(rate(windows_iis_worker_metadata_cache_hits_total[2m])) / avg by (hostname, app)(rate(windows_iis_worker_metadata_cache_queries_total[2m])) ) * 100 Agent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/microsoft-iis/"},{"id":503,"title":"Microsoft SQL Server","content":" This integration is disabled by default. Please refer to Enable and Disable Integrations to enable it in your account.\nThis integration has 28 metrics.\nTimeseries generated: ~500TS per instance and ~100TS per database\nThe metrics in this integration are scraped from the Windows Exporter in the Windows integration. To enable the SQL Server metrics in the Windows Exporter, add the mssql collector to its config.yaml file.\nList of Alerts Alert Description Format [Microsoft SQL Server] Low Free Memory SQL instance running low on free memory. Prometheus [Microsoft SQL Server] High Log File Usage Log file will be full in 12h. Prometheus [Microsoft SQL Server] Low Buffer Cache Hit Ratio Buffer Cache Hit Ratio is low in the SQL instance. Prometheus [Microsoft SQL Server] Deadlocks detected Deadlocks detected in the SQL instance. Prometheus List of DashboardsMicrosoft SQL ServerThe dashboard provides information on SQL Server instances and databases. List of Metrics Metric name windows_logical_disk_free_bytes windows_logical_disk_size_bytes windows_mssql_accessmethods_full_scans windows_mssql_accessmethods_worktables_from_cache_hits windows_mssql_bufman_buffer_cache_hits windows_mssql_bufman_buffer_cache_lookups windows_mssql_databases_data_files_size_bytes windows_mssql_databases_log_cache_hits windows_mssql_databases_log_cache_lookups windows_mssql_databases_log_files_size_bytes windows_mssql_databases_log_files_used_size_bytes windows_mssql_databases_log_flushed_bytes windows_mssql_databases_transactions windows_mssql_genstats_active_temp_tables windows_mssql_genstats_logical_connections windows_mssql_genstats_logins windows_mssql_genstats_logouts windows_mssql_genstats_mars_deadlocks windows_mssql_genstats_sql_trace_io_provider_lock_waits windows_mssql_locks_deadlocks windows_mssql_locks_lock_requests windows_mssql_memmgr_connection_memory_bytes windows_mssql_memmgr_database_cache_memory_bytes windows_mssql_memmgr_free_memory_bytes windows_mssql_memmgr_lock_memory_bytes windows_mssql_memmgr_target_server_memory_bytes windows_mssql_memmgr_total_server_memory_bytes windows_mssql_transactions_tempdb_free_space_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting Microsoft SQL ServerThis document describes important metrics and queries that you can use to monitor and troubleshoot SQL Server.\nServer StatsLogin ActivityUse the following query to check the login / logout activity in the SQL Server instance:\nrate(windows_mssql_genstats_logins[5m]) Transaction activityYou can monitor transaction activity with this query:\nrate(windows_mssql_databases_transactions[5m])) by (hostname, mssql_instance)) Database StatsDatabase SizeUse the following query to check databases size:\navg(windows_mssql_databases_data_files_size_bytes) by (hostname,mssql_instance, database) Log File SizeUse the following queries to check Log File Size and Used Size:\navg(windows_mssql_databases_log_files_size_bytes) by (hostname,mssql_instance, database) avg(windows_mssql_databases_log_files_used_size_bytes) by (hostname,mssql_instance, database) Calculate the % Log File Used Size with this query:\navg(windows_mssql_databases_log_files_used_size_bytes) by (hostname,mssql_instance, database) / avg(windows_mssql_databases_log_files_size_bytes) by (hostname,mssql_instance, database) * 100 Transactions by DatabaseUse the following query to check number of transactions per second in a database:\nrate(windows_mssql_databases_transactions[5m])) by (hostname, mssql_instance, database) Log FlushesCheck the number of log flushes per second in a database:\nrate(windows_mssql_databases_log_flushed_bytes[5m])) by (hostname, mssql_instance, database) Full scansCheck the number of full scans per second in a database:\nrate(windows_mssql_accessmethods_full_scans[5m])) by (hostname, mssql_instance, database) A high number could explain high values in CPU usage. Check for queries doing full table scans.\nCache StatsBuffer Cache Hit RatioUse the following query to check the Buffer Cache Hit Ratio:\nwindows_mssql_bufman_buffer_cache_hits / windows_mssql_bufman_buffer_cache_lookups This value should be close to 98% because reading from the cache is much less expensive than reading from the disk. Check the amount of memory available in the SQL Server if you have a low value.\nLog Cache Hit RatioUse the following query to check the Log Cache Hit Ratio:\nwindows_mssql_databases_log_cache_hits / windows_mssql_databases_log_cache_lookups Access Methods Worktables Cache Hit RatioUse the following query to check the Access Methods Worktables Cache Hit Ratio:\nwindows_mssql_databases_log_cache_hits / windows_mssql_databases_log_cache_lookups Lock StatsLocks Requested By ResourceUse the following query to check the number of locks requested by resource per second:\nrate(windows_mssql_locks_lock_requests[5m]) Deadlocks by ResourceUse the following query to check the number of locks requested by resource per second:\nrate(windows_mssql_locks_deadlocks[5m]) Prevent the occurrence of SQL deadlocks. This value should be 0/s. If there are deadlocks check xml_deadlock_report in the SQL Server Management Studio and review affected queries.\nMemory StatsTotal / Target MemoryUse the following queries to check total/target memory:\nwindows_mssql_memmgr_target_server_memory_bytes windows_mssql_memmgr_total_server_memory_bytes Memory pressure might appear if total memory is close to target memory.\nFree MemoryUse the following query to check free memory:\nwindows_mssql_memmgr_free_memory_bytes Agent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/microsoft-sql-server/"},{"id":504,"title":"MongoDB","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v4.2\nThis integration uses a standalone exporter that is available in UBI or scratch base image.\nThis integration has 57 metrics.\nTimeseries generated: 500 series per instance\nList of Alerts Alert Description Format [MongoDB] Instance Down Mongo server detected down by instance Prometheus [MongoDB] Uptime less than one hour Mongo server detected down by instance Prometheus [MongoDB] Asserts detected Mongo server detected down by instance Prometheus [MongoDB] High Latency High latency in instance Prometheus [MongoDB] High Ticket Utilization Ticket usage over 75% in instance Prometheus [MongoDB] Recurrent Cursor Timeout Recurrent cursors timeout in instance Prometheus [MongoDB] Recurrent Memory Page Faults Recurrent cursors timeout in instance Prometheus List of DashboardsMongoDB Instance HealthThe dashboard provides information on the connections, cache hit rate, error rate, latency and traffic of one of the databases of the MongoDB instance. MongoDB Database DetailsThe dashboard provides information on the status, error rate and resource usage of a MongoDB instance. List of Metrics Metric name mongodb_asserts_total mongodb_connections mongodb_dbstats_collections mongodb_dbstats_dataSize mongodb_dbstats_indexSize mongodb_dbstats_indexes mongodb_dbstats_objects mongodb_extra_info_page_faults_total mongodb_instance_uptime_seconds mongodb_memory mongodb_mongod_db_collections_total mongodb_mongod_db_data_size_bytes mongodb_mongod_db_index_size_bytes mongodb_mongod_db_indexes_total mongodb_mongod_db_objects_total mongodb_mongod_global_lock_client mongodb_mongod_global_lock_current_queue mongodb_mongod_global_lock_ratio mongodb_mongod_metrics_cursor_open mongodb_mongod_metrics_cursor_timed_out_total mongodb_mongod_op_latencies_latency_total mongodb_mongod_op_latencies_ops_total mongodb_mongod_wiredtiger_cache_bytes mongodb_mongod_wiredtiger_cache_bytes_total mongodb_mongod_wiredtiger_cache_evicted_total mongodb_mongod_wiredtiger_cache_pages mongodb_mongod_wiredtiger_concurrent_transactions_out_tickets mongodb_mongod_wiredtiger_concurrent_transactions_total_tickets mongodb_network_bytes_total mongodb_network_metrics_num_requests_total mongodb_op_counters_total mongodb_ss_asserts mongodb_ss_connections mongodb_ss_extra_info_page_faults mongodb_ss_globalLock_activeClients_readers mongodb_ss_globalLock_activeClients_writers mongodb_ss_globalLock_currentQueue mongodb_ss_mem_resident mongodb_ss_mem_virtual mongodb_ss_metrics_cursor_open mongodb_ss_metrics_cursor_timedOut mongodb_ss_network_bytesIn mongodb_ss_network_bytesOut mongodb_ss_network_numRequests mongodb_ss_opLatencies_latency mongodb_ss_opLatencies_ops mongodb_ss_opcounters mongodb_ss_uptime mongodb_ss_wt_cache_bytes_currently_in_the_cache mongodb_ss_wt_cache_bytes_read_into_cache mongodb_ss_wt_cache_bytes_written_from_cache mongodb_ss_wt_cache_pages_currently_held_in_the_cache mongodb_ss_wt_cache_tracked_dirty_pages_in_the_cache mongodb_ss_wt_concurrentTransactions_out mongodb_ss_wt_concurrentTransactions_totalTickets mongodb_up sysdig_container_net_error_count PrerequisitesCreate Credentials for MongoDB ExporterIf you want to use a non-admin user for the exporter, you will have to create a user and grant the roles to be able to scrape statistics.\nIn the mongo shell:\nuse admin db.auth(\u0026#34;\u0026lt;YOUR-ADMIN-USER\u0026gt;\u0026#34;, \u0026#34;\u0026lt;YOUR-ADMIN-PASSWORD\u0026gt;\u0026#34;) db.createUser( { user: \u0026#34;\u0026lt;YOUR-EXPORTER-USER\u0026gt;\u0026#34;, pwd: \u0026#34;\u0026lt;YOUR-EXPORTER-PASSWORD\u0026gt;\u0026#34;, roles: [ { role: \u0026#34;clusterMonitor\u0026#34;, db: \u0026#34;admin\u0026#34; }, { role: \u0026#34;read\u0026#34;, db: \u0026#34;admin\u0026#34; }, { role: \u0026#34;read\u0026#34;, db: \u0026#34;local\u0026#34; } ] } ) Create Kubernetes Secret for Connection and AuthenticationTo configure authentication, do the following:\nCreate a text file with the connection string (mongodb-uri) for your MongoDB by using these examples: # Basic authentication mongodb://\u0026lt;YOUR-EXPORTER-USER\u0026gt;:\u0026lt;YOUR-EXPORTER-PASSWORD\u0026gt;@\u0026lt;YOUR-MONGODB-HOST\u0026gt;:\u0026lt;PORT\u0026gt; # TLS mongodb://\u0026lt;YOUR-EXPORTER-USER\u0026gt;:\u0026lt;YOUR-EXPORTER-PASSWORD\u0026gt;@\u0026lt;YOUR-MONGODB-HOST\u0026gt;:\u0026lt;PORT\u0026gt;/admin?tls=true\u0026amp;tlsCertificateKeyFile=/etc/mongodb/mongodb-exporter-key.pem\u0026amp;tlsAllowInvalidCertificates=true\u0026amp;tlsCAFile=/etc/mongodb/mongodb-exporter-ca.pem # SSL mongodb://\u0026lt;YOUR-EXPORTER-USER\u0026gt;:\u0026lt;YOUR-EXPORTER-PASSWORD\u0026gt;@\u0026lt;YOUR-MONGODB-HOST\u0026gt;:\u0026lt;PORT\u0026gt;/admin?ssl=true\u0026amp;sslclientcertificatekeyfile=/etc/mongodb/mongodb-exporter-key.pem\u0026amp;sslinsecure=true\u0026amp;sslcertificateauthorityfile=/etc/mongodb/mongodb-exporter-ca.pem Create the secret for the connection string: kubectl create secret -n Your-Exporter-Namespace generic Your-Mongodb-Uri-Secret-Name \\ --from-file=mongodb-uri=\u0026lt;route-to-file-with-mongodb-uri.txt\u0026gt; In case of TLS or SSL authentication, create the secret with the private key and the certificate authority (CA). If you do not have a CA file, you can use an empty file instead: kubectl create secret -n Your-Exporter-Namespace generic mongodb-exporter-auth \\ --from-file=mongodb-key=\u0026lt;route-to-your-private-key.pem\u0026gt; \\ --from-file=mongodb-ca=\u0026lt;route-to-your-ca.pem\u0026gt; InstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/mongodb-exporter\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: mongodb-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;mongodb\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_ns] target_label: kube_namespace_name - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_type] target_label: kube_workload_type - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_name] target_label: kube_workload_name - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/mongodb/"},{"id":505,"title":"MySQL","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v5.7\nThis integration uses a standalone exporter that is available in UBI or scratch base image.\nThis integration has 47 metrics.\nTimeseries generated: 1005 series per instance\nList of Alerts Alert Description Format [MySQL] Mysql Down MySQL instance is down Prometheus [MySQL] Mysql Restarted MySQL has just been restarted, less than one minute ago Prometheus [MySQL] Mysql Too many Connections (\u0026gt;80%) More than 80% of MySQL connections are in use Prometheus [MySQL] Mysql High Threads Running More than 60% of MySQL connections are in running state Prometheus [MySQL] Mysql HighOpen Files More than 80% of MySQL files open Prometheus [MySQL] Mysql Slow Queries MySQL server mysql has some new slow query Prometheus [MySQL] Mysql Innodb Log Waits MySQL innodb log writes stalling Prometheus [MySQL] Mysql Slave Io Thread Not Running MySQL Slave IO thread not running Prometheus [MySQL] Mysql Slave Sql Thread Not Running MySQL Slave SQL thread not running Prometheus [MySQL] Mysql Slave Replication Lag MySQL Slave replication lag Prometheus List of DashboardsMySQLThe dashboard provides information on the status, error rate and resource usage of a MySQL instance. List of Metrics Metric name mysql_global_status_aborted_clients mysql_global_status_aborted_connects mysql_global_status_buffer_pool_pages mysql_global_status_bytes_received mysql_global_status_bytes_sent mysql_global_status_commands_total mysql_global_status_connection_errors_total mysql_global_status_innodb_buffer_pool_read_requests mysql_global_status_innodb_buffer_pool_reads mysql_global_status_innodb_log_waits mysql_global_status_innodb_mem_adaptive_hash mysql_global_status_innodb_mem_dictionary mysql_global_status_innodb_page_size mysql_global_status_questions mysql_global_status_select_full_join mysql_global_status_select_full_range_join mysql_global_status_select_range_check mysql_global_status_select_scan mysql_global_status_slow_queries mysql_global_status_sort_merge_passes mysql_global_status_sort_range mysql_global_status_sort_rows mysql_global_status_sort_scan mysql_global_status_table_locks_immediate mysql_global_status_table_locks_waited mysql_global_status_table_open_cache_hits mysql_global_status_table_open_cache_misses mysql_global_status_threads_cached mysql_global_status_threads_connected mysql_global_status_threads_created mysql_global_status_threads_running mysql_global_status_uptime mysql_global_variables_innodb_additional_mem_pool_size mysql_global_variables_innodb_log_buffer_size mysql_global_variables_innodb_open_files mysql_global_variables_key_buffer_size mysql_global_variables_max_connections mysql_global_variables_open_files_limit mysql_global_variables_query_cache_size mysql_global_variables_thread_cache_size mysql_global_variables_tokudb_cache_size mysql_slave_status_master_server_id mysql_slave_status_seconds_behind_master mysql_slave_status_slave_io_running mysql_slave_status_slave_sql_running mysql_slave_status_sql_delay mysql_up PrerequisitesCreate Credentials for MySQL Exporter Create the user and password for the exporter in the database: CREATE USER \u0026#39;exporter\u0026#39; IDENTIFIED BY \u0026#39;YOUR-PASSWORD\u0026#39; WITH MAX_USER_CONNECTIONS 3; GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO \u0026#39;exporter\u0026#39;; Replace the user name and the password in the SQL sentence for your custom ones.\nCreate a mysql-exporter.cnf file with the credentials of the exporter: [client] user = exporter password = \u0026#34;YOUR-PASSWORD\u0026#34; host=YOUR-DB-IP In your cluster, create the secret with the mysql-exporter.cnf file. This file will be mounted in the exporter to authenticate with the database: kubectl create secret -n Your-Application-Namespace generic mysql-exporter \\ --from-file=.my.cnf=./mysql-exporter.cnf Using SSL AuthenticationIf your database requires SSL authentication, you need to create secrets with the certificates. To do so, create the secret with SSL certificates for the exporter:\nkubectl create secret -n Your-Application-Namespace generic mysql-exporter \\ --from-file=.my.cnf=./mysql-exporter.cnf --from-file=ca.pem=./certs/ca.pem \\ --from-file=client-key.pem=./certs/client-key.pem \\ --from-file=client-cert.pem=./certs/client-cert.pem In the mysql-exporter.cnf file, include the following lines to route to the certificates in the exporter:\n[client] user = exporter password = \u0026#34;YOUR-PASSWORD\u0026#34; host=YOUR-DB-IP ssl-ca=/lib/cert/ca.pem ssl-key=/lib/cert/client-key.pem ssl-cert=/lib/cert/client-cert.pem InstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/mysql-exporter\nRelated Blog Posts Top key metrics for monitoring MySQL Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: mysql-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;mysql\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_ns] target_label: kube_namespace_name - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_type] target_label: kube_workload_type - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_name] target_label: kube_workload_name - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (mysql_global_status_aborted_clients|mysql_global_status_aborted_connects|mysql_global_status_buffer_pool_pages|mysql_global_status_bytes_received|mysql_global_status_bytes_sent|mysql_global_status_commands_total|mysql_global_status_connection_errors_total|mysql_global_status_innodb_buffer_pool_read_requests|mysql_global_status_innodb_buffer_pool_reads|mysql_global_status_innodb_log_waits|mysql_global_status_innodb_mem_adaptive_hash|mysql_global_status_innodb_mem_dictionary|mysql_global_status_innodb_page_size|mysql_global_status_questions|mysql_global_status_select_full_join|mysql_global_status_select_full_range_join|mysql_global_status_select_range_check|mysql_global_status_select_scan|mysql_global_status_slow_queries|mysql_global_status_sort_merge_passes|mysql_global_status_sort_range|mysql_global_status_sort_rows|mysql_global_status_sort_scan|mysql_global_status_table_locks_immediate|mysql_global_status_table_locks_waited|mysql_global_status_table_open_cache_hits|mysql_global_status_table_open_cache_misses|mysql_global_status_threads_cached|mysql_global_status_threads_connected|mysql_global_status_threads_created|mysql_global_status_threads_running|mysql_global_status_uptime|mysql_global_variables_innodb_additional_mem_pool_size|mysql_global_variables_innodb_log_buffer_size|mysql_global_variables_innodb_open_files|mysql_global_variables_key_buffer_size|mysql_global_variables_max_connections|mysql_global_variables_open_files_limit|mysql_global_variables_query_cache_size|mysql_global_variables_thread_cache_size|mysql_global_variables_tokudb_cache_size|mysql_slave_status_master_server_id|mysql_slave_status_seconds_behind_master|mysql_slave_status_slave_io_running|mysql_slave_status_slave_sql_running|mysql_slave_status_sql_delay|mysql_up) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/mysql/"},{"id":506,"title":"Nexus","content":" Ensure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=nexus \\ --set config.registryURL=\u0026lt;NEXUS_REGISTRY_URL\u0026gt; \\ --set config.registryUser=\u0026lt;NEXUS_USER\u0026gt; \\ --set config.registryPassword=\u0026lt;NEXUS_PASSWORD\u0026gt; \u0026lt;NEXUS_USER\u0026gt; \\ \u0026lt;NEXUS_PASSWORD\u0026gt;: User credentials with nx-admin role assigned. \u0026lt;NEXUS_REGISTRY_URL\u0026gt;: Nexus registry URL for example, nexus.your.domain ","url":"https://docs.sysdig.com/en/sysdig-secure/nexus/"},{"id":507,"title":"NGINX","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v12\nThis integration uses a sidecar exporter that is available in UBI or scratch base image.\nThis integration has 12 metrics.\nTimeseries generated: 8 series per nginx container\nList of Alerts Alert Description Format [Nginx] No Intances Up No Nginx instances Up Prometheus List of DashboardsNginxThe dashboard provides information on the status of the NGINX server and Golden Signals. List of Metrics Metric name net.bytes.in net.bytes.out net.http.error.count net.http.request.count net.http.request.time nginx_connections_accepted nginx_connections_active nginx_connections_handled nginx_connections_reading nginx_connections_waiting nginx_connections_writing nginx_up PrerequisitesEnable Nginx stub_status ModuleThe exporter can be installed as a sidecar of the pod with the Nginx server. To make Nginx expose an endpoint for scraping metrics, enable the stub_status module. If your Nginx configuration is defined inside a Kubernetes ConfigMap, add the following snippet to enable the stub_status module:\nserver { listen 80; server_name localhost; location /nginx_status { stub_status on; access_log on; allow all; # REPLACE with your access policy } } This is how the ConfigMap would look after adding this snippet:\napiVersion: v1 kind: ConfigMap metadata: name: nginx-config data: nginx.conf: | server { listen 80; server_name localhost; location /nginx_status { stub_status on; access_log on; allow all; # REPLACE with your access policy } } InstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/nginx-exporter\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: nginx-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;nginx\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/nginx/"},{"id":508,"title":"NGINX Ingress","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v1.9.0\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 45 metrics.\nTimeseries generated: 1500\nThis integration specifically supports kubernetes/ingress-nginx, and not other NGINX-Ingress versions like nginxinc/kubernetes-ingress.\nList of Alerts Alert Description Format [Nginx-Ingress] High Http 4xx Error Rate Too many HTTP requests with status 4xx (\u0026gt; 5%) Prometheus [Nginx-Ingress] High Http 5xx Error Rate Too many HTTP requests with status 5xx (\u0026gt; 5%) Prometheus [Nginx-Ingress] High Latency Nginx p99 latency is higher than 10 seconds Prometheus [Nginx-Ingress] Ingress Certificate Expiry Nginx Ingress Certificate will expire in less than 14 days Prometheus List of DashboardsNginx IngressThe dashboard provides information on the error rate, resource usage, traffic and certificate expiration of the NGINX ingress. List of Metrics Metric name go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads nginx_ingress_controller_config_last_reload_successful nginx_ingress_controller_config_last_reload_successful_timestamp_seconds nginx_ingress_controller_connect_duration_seconds_count nginx_ingress_controller_connect_duration_seconds_sum nginx_ingress_controller_ingress_upstream_latency_seconds_count nginx_ingress_controller_ingress_upstream_latency_seconds_sum nginx_ingress_controller_nginx_process_connections nginx_ingress_controller_nginx_process_cpu_seconds_total nginx_ingress_controller_nginx_process_resident_memory_bytes nginx_ingress_controller_request_duration_seconds_bucket nginx_ingress_controller_request_duration_seconds_count nginx_ingress_controller_request_duration_seconds_sum nginx_ingress_controller_request_size_sum nginx_ingress_controller_requests nginx_ingress_controller_response_duration_seconds_count nginx_ingress_controller_response_duration_seconds_sum nginx_ingress_controller_response_size_sum nginx_ingress_controller_ssl_expire_time_seconds process_cpu_seconds_total process_max_fds process_open_fds PrerequisitesEnable NGINX Ingress metricsTo enable metric scraping, you should add the following line to the NGINX Ingress configuration file:\ncontroller.metrics.enabled=true This parameter should be added in the NGINX Ingress section of the values.yaml file if you\u0026rsquo;re using Helm to deploy the NGINX Ingress, or in the nginx-ingress-controller configuration file if you\u0026rsquo;re using a native Kubernetes installation.\nOnce you\u0026rsquo;ve enabled metric scraping with this parameter, the NGINX Ingress will automatically begin exposing its metrics on port 10254.\nAnother option is adding the following line to the NGINX Ingress configuration file:\ncontroller.metrics.podAnnotations.prometheus.io/scrape=true InstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: nginx-ingress-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] regex: true - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (controller|nginx-ingress-controller);(.{0}$) replacement: nginx-ingress target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;nginx-ingress\u0026#34; - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (go_build_info|go_info|nginx_ingress_controller_config_last_reload_successful|nginx_ingress_controller_config_last_reload_successful_timestamp_seconds|nginx_ingress_controller_ingress_upstream_latency_seconds_count|nginx_ingress_controller_ingress_upstream_latency_seconds_sum|nginx_ingress_controller_connect_duration_seconds_sum|nginx_ingress_controller_connect_duration_seconds_count|nginx_ingress_controller_nginx_process_connections|nginx_ingress_controller_nginx_process_cpu_seconds_total|process_max_fds|process_open_fds|nginx_ingress_controller_nginx_process_resident_memory_bytes|nginx_ingress_controller_request_duration_seconds_bucket|nginx_ingress_controller_request_duration_seconds_count|nginx_ingress_controller_request_duration_seconds_sum|nginx_ingress_controller_request_size_sum|nginx_ingress_controller_requests|nginx_ingress_controller_response_duration_seconds_count|nginx_ingress_controller_response_duration_seconds_sum|nginx_ingress_controller_response_size_sum|nginx_ingress_controller_ssl_expire_time_seconds|go_gc_duration_seconds|go_gc_duration_seconds_count|go_gc_duration_seconds_sum|go_goroutines|go_memstats_buck_hash_sys_bytes|go_memstats_gc_sys_bytes|go_memstats_heap_alloc_bytes|go_memstats_heap_idle_bytes|go_memstats_heap_inuse_bytes|go_memstats_heap_released_bytes|go_memstats_heap_sys_bytes|go_memstats_lookups_total|go_memstats_mallocs_total|go_memstats_mcache_inuse_bytes|go_memstats_mcache_sys_bytes|go_memstats_mspan_inuse_bytes|go_memstats_mspan_sys_bytes|go_memstats_next_gc_bytes|go_memstats_stack_inuse_bytes|go_memstats_stack_sys_bytes|go_memstats_sys_bytes|go_threads) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/nginx-ingress/"},{"id":509,"title":"Manage Notification Channels","content":"Supported Notification ChannelsThe tables below show which notification channel types are supported in Sysdig Secure and Sysdig Monitor, and for which use cases within each product.\nSupported Channels in Sysdig Secure Notification Channel Threat Detection Policies Vulnerability Policies Automations Reports Amazon SNS X Email X X X X Microsoft Teams X X X OpsGenie X PagerDuty X X Prometheus Alertmanager X Slack X X X X Sysdig Team Email X VictorOps X Webhook X X X Supported Channels in Sysdig Monitor Notification Channel Alerts Silence Rule Notifications Cost Advisor Reports Amazon SNS X Custom Webhook X Email X Google Chat X IBM Cloud Functions X IBM Event Notifications (IBM Only) Microsoft Teams X OpsGenie X PagerDuty X Prometheus Alertmanager X Slack X X X Sysdig Team Email X VictorOps X Webhook X Rate LimitsSysdig provides rate limiting of incoming notification requests in order to prevent overloading of the destination channels.\nRate limiting applies to all notification channels and counts notifications on a per customer, per notification channel type, per notification type basis. Hitting a limit on one channel won\u0026rsquo;t affect the limit of other channels, even if they are the same type (for example, Slack) and owned by the same customer.\nIf the number of notifications triggering exceeds the per-minute or per-hour limit, the excess notifications are discarded.\nBeyond Sysdig\u0026rsquo;s own rate limit mechanism described here, third party services may apply their own rate limit mechanism. Hitting this limit may be reflected in the notification response. For example:\nJira and Slack send a 429 error code. Email sends 421 or 450 error code. Webhook sends an HTTP 429 code. For more details, consult the documentation for the relevant third-party service.\nOn-prem userse can use standard configuration to configure limits per environment. The default limits are:\nChannel Type Per minute limit Per hour limit Any Any 1,200 20,000 Email Any 1,000 20,000 Email Monitor Alerts 1,200 72,000 Email Runtime Policy 500 1,000 Email New Findings* 500 1,000 PagerDuty Monitor Alerts 1,200 30,000 Custom Webhook Monitor Alerts 1,200 50,000 Slack Monitor Alerts 9,000 500,000 Slack Runtime Policy 500 1,000 Slack New Findings* 500 1,000 Team Email Any 1,000 20,000 Team Email Runtime Policy 500 1,000 Team Email New Findings* 500 1,000 Webhook Monitor Alerts 5,000 300,000 New Findings refers to Vulnerability Findings. Control Access to ChannelsNotification channel management can be fine-tuned by role-based access as follows:\nNotification channels can be global or limited to a particular team.\nGlobal channels can be managed by admins and can be viewed/used by other roles, while team-limited channels are available only to team members.\nTeam Manager , Advanced User, and Service Manager (Secure) roles can create/update/delete team-scoped notification channels. They can also read and use the global ones.\nStandard and View Only roles can read team-limited and global notification channels.\nAdmins can create global notification channels and migrate channels from \u0026ldquo;global\u0026rdquo; to \u0026ldquo;team-limited\u0026rdquo;, and also from one team to another.\nAdd a Notification ChannelTo add a new notification channel for alerting:\nLog in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nThe Notifications main page is displayed: Select Add Notification Channel.\nFollow the channel-specific steps to complete the configuration process.\nShare a Notification ChannelWhen you configure a notification channel as Administrator, you can choose whether the channel should be Shared With the Current Team you are logged in as, or with All Teams.\nNotification channels created by one team cannot be shared with just with one other team. To use a channel created by another team, ensure the channel is Shared With All Teams in the channel configuration.\nWhen a non-Admin user creates a notification channel, it can only be shared with their Current Team.\nNotification channels that have a team assigned cannot be converted to be shared with All Teams. Instead, you should create a new channel to be shared with All Teams.\nEdit a Notification ChannelTo edit a notification channel:\nLog in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nClick the target channel.\nMake the edits and click Save.\nTest a Notification ChannelTo test a notification channel:\nLog in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect the three dots next to a created Notification Channel and click Test Channel.\nIf a notification is not received within 10 minutes, the notification channel is not working, and the configuration should be reviewed.\nReport Unsuccessful Notification AttemptsWhen an unsuccessful notification has been attempted on a given notification channel, Sysdig Events are generated to warn you about it. At the fifth failed notification attempt, the notification channel will be disabled and a corresponding Sysdig Event will be generated. To view the list of Sysdig Events:\nLog in to Sysdig Monitor and select Events.\nOn the Events page, select Sysdig from the All Types drop-down.\nNotification Channel Failure AlertsYou can configure who receives email notifications when a notification channel fails. This setting applies to all notification channels except email.\nThe Notify when Misconfigured setting is configured per notification channel.\nConfiguration Options Do not notify: No notification is sent. Notify Admins and Team Managers: Sends an email to all Admins and Team Managers. This option is enabled by default for each notification channel. Notify Custom Email Addresses: Sends an email to a specified list of comma-separated email addresses. For more information on troubleshooting notification channels, see Troubleshoot Notification Channels.\nDisable a Notification ChannelSometimes, a notification channel has outlived its use, or must be temporarily disabled due to noise while an underlying issue is investigated.\nTo temporarily disable a notification channel:\nLog in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nIdentify a channel, and toggle the Enabled slider off.\nTo re-enable the channel, toggle the slider on.\nDelete a Notification Channel Log in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect the three-dot menu icon on the right side of a channel listing.\nSelect Delete Channel.\nTimezone SettingsWhen the system sends a notification, it includes a timestamp in the message. You can configure how this time is displayed using the Time Format setting.\nThe setting applies globally to all notifications sent from the system. The following formats are available:\nUTC (default) Local time System NotificationsSystem notifications are meant to inform you of related Sysdig actions, such as enforcing event and alert limits, including retention limits and times. For more information on various retention limits see Data Retention.\nThe following options are available:\nDo not notify: No notification is sent Notify Admins and Team Managers (default): Email notifications are sent to Admins and Team Managers Notify Notification Channel: A notification is sent to the selected notification channel. You can choose between Email, Slack, and PagerDuty notification channels. Configure an Alert Start-Up Delay (On-Premises Only)In Sysdig Monitor, alert jobs begin immediately at start-up. However, in instances where Sysdig goes down unexpectedly, or without proper shutdown/startup procedures implemented, data can be missing, triggering alert notifications.\nA start-up delay in alert jobs can be configured in on-premises environments, by setting the draios.alerts.startupDelay parameter. The parameter requires a duration value; the example below shows a duration of 10 minutes:\ndraios.alerts.startupDelay=10m This parameter can be configured for Kubernetes environments:\nFor Kubernetes environments, add the parameter to the sysdigcloud.jvm.worker.options parameter in the configmap. For more information on editing the configmap refer to the On-Premises Installation documentation.\n","url":"https://docs.sysdig.com/en/administration/set-up-notification-channels/"},{"id":510,"title":"NTP","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v2\nThis integration uses a standalone exporter that is available in UBI or scratch base image.\nThis integration has 1 metrics.\nTimeseries generated: 4 series per node\nList of Alerts Alert Description Format [Ntp] Drift is too high Drift is too high Prometheus List of DashboardsNTPThe dashboard provides information on the drift of each node. List of Metrics Metric name ntp_drift_seconds PrerequisitesNone.\nInstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/ntp-exporter\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: ntp-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;ntp\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_ns] target_label: kube_namespace_name - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_type] target_label: kube_workload_type - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_name] target_label: kube_workload_name - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [__meta_kubernetes_pod_node_name] target_label: kube_node_name - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/ntp/"},{"id":511,"title":"OPA","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v3.6\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 12 metrics.\nTimeseries generated: 150 series for each Gatekeeper\nList of Alerts Alert Description Format [Opa gatekeeper] Too much time since the last audit There was more than 120 second since the last audit Prometheus [Opa gatekeeper] Spike of violations There was more than 30 violations Prometheus List of DashboardsOPA GatekeeperThe dashboard provides information on the requests rate, latency, violations rate per constraint. List of Metrics Metric name gatekeeper_audit_duration_seconds_bucket gatekeeper_audit_last_run_time gatekeeper_constraint_template_ingestion_count gatekeeper_constraint_template_ingestion_duration_seconds_bucket gatekeeper_constraint_templates gatekeeper_constraints gatekeeper_mutation_request_count gatekeeper_mutation_request_duration_seconds_bucket gatekeeper_validation_request_count gatekeeper_validation_request_duration_seconds_bucket gatekeeper_validation_request_duration_seconds_count gatekeeper_violations PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: opa-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_label_control_plane - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (manager);(audit-controller|controller-manager);(.{0}$) replacement: opa-gatekeeper target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;opa-gatekeeper\u0026#34; - action: keep source_labels: - __meta_kubernetes_pod_container_port_name regex: \u0026#34;metrics\u0026#34; - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__address__,__meta_kubernetes_pod_container_port_name] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (certwatcher_read_certificate_errors_total|certwatcher_read_certificate_total|gatekeeper_audit_duration_seconds_bucket|gatekeeper_audit_last_run_time|gatekeeper_constraint_template_ingestion_count|gatekeeper_constraint_template_ingestion_duration_seconds_bucket|gatekeeper_constraint_templates|gatekeeper_constraints|gatekeeper_mutation_request_count|gatekeeper_mutation_request_duration_seconds_bucket|gatekeeper_validation_request_count|gatekeeper_validation_request_duration_seconds_bucket|gatekeeper_validation_request_duration_seconds_count|gatekeeper_violations) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/opa/"},{"id":512,"title":"OpenShift Container Platform Registry","content":"Prerequisites Ensure that your system meets the requirements. Ensure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes. To run the scanner in your OCP Registry, you need the user and password with admin permissions.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=ocp\\ ","url":"https://docs.sysdig.com/en/sysdig-secure/ocp-registry/"},{"id":513,"title":"OracleDB","content":" This integration is enabled by default.\nVersions supported: \u0026gt; 12.1.0.2\nThis integration uses a standalone exporter that is available in UBI or scratch base image.\nThis integration has 33 metrics.\nTimeseries generated: ~500 timeseries\nList of Alerts Alert Description Format [OracleDB] Exporter Process Down Exporter process is not serving metrics. Prometheus [OracleDB] Low UpTime The OracleDB instance has an UpTime of less than 1 hour. Prometheus [OracleDB] Low Cache Hit Rate Low cache hit rate. Prometheus [OracleDB] High Tablespace Usage High Tablespace Usage. Prometheus [OracleDB] Tablespace Full In 12h Tablespace will be full within 12 hours. Prometheus [OracleDB] Tablespace Full In 48h Tablespace will be full within 48 hours. Prometheus List of DashboardsOracle DBThe dashboard provides information on the Oracle DB integration. List of Metrics Metric name oracledb_activity_execute_count oracledb_activity_parse_count_total oracledb_activity_user_commits oracledb_activity_user_rollbacks oracledb_big_queries_p95_rows oracledb_big_queries_p99_rows oracledb_cache_hit_ratio_percentage oracledb_process_count oracledb_resource_current_utilization oracledb_resource_limit_value oracledb_sessions_value oracledb_size_dba_segments_top100_cluster_bytes oracledb_size_dba_segments_top100_table_bytes oracledb_size_dba_segments_top100_table_partition_bytes oracledb_size_user_segments_top100_table_bytes oracledb_size_user_segments_top100_table_partition_bytes oracledb_slow_queries_p95_time_usecs oracledb_slow_queries_p99_time_usecs oracledb_startup_time_seconds oracledb_tablespace_bytes oracledb_tablespace_free oracledb_tablespace_used_percent oracledb_up oracledb_wait_time_administrative oracledb_wait_time_application oracledb_wait_time_commit oracledb_wait_time_concurrency oracledb_wait_time_configuration oracledb_wait_time_network oracledb_wait_time_other oracledb_wait_time_scheduler oracledb_wait_time_system_io oracledb_wait_time_user_io PrerequisitesCreate OracleDB user and grant permissionCreate a user for monitoring in Oracle Database.\nMake sure you grant SELECT permission for the monitoring user on the following tables:\ndba_tablespace_usage_metrics dba_tablespaces v$system_wait_class v$asm_diskgroup_stat v$datafile v$sysstat v$process v$waitclassmetric v$session v$resource_limit Create Credentials for OracleDB ExporterCreate the secret with the Oracle Datasource in the namespace where the exporter will be deployed:\nkubectl create secret -n \u0026#39;EXPORTER-NAMESPACE\u0026#39; generic oracledb-exporter-secret --from-literal=datasource=\u0026#34;YOUR_CONNECTION_STRING\u0026#34; YOUR_CONNECTION_STRING should be like: oracle://user:password@hostname:1521/DB_SID\nInstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/oracledb-exporter\nMonitoring and Troubleshooting OracleDB exporterThis document describes important metrics and queries that you can use to monitor and troubleshoot OracleDB.\nOracleDB ActivityExecutionsUse the following query to determine the number of executions per second:\nrate(oracledb_activity_user_commits[5m]) CommitsUse the following query to determine the number of commits per second:\nrate(oracledb_activity_user_commits[5m]) RollbacksUse the following query to determine the number of rollbacks per second:\nrate(oracledb_activity_user_rollbacks[5m]) ProcessesUse the following query to determine the number of processes in OracleDB:\noracledb_process_count Cache Hit RatioUse the following query to determine the Hit Ratio in OracleDB:\noracledb_cache_hit_ratio_percentage OracleDB SessionsActive sessionsUse the following query to determine the number of active sessions:\nsum(oracledb_sessions_value{status=\u0026#34;ACTIVE\u0026#34;}) by (status) Inactive sessionsUse the following query to determine the number of inactive sessions:\nsum(oracledb_sessions_value{status=\u0026#34;INACTIVE\u0026#34;}) by (status) OracleDB TablesTable SizeUse the following query to determine the top 10 dba tables ordered by size:\ntopk(10,sum(oracledb_size_dba_segments_top100_table_bytes) by (segment_name, owner)) Use the following query to determine the top 10 user tables ordered by size:\ntopk(10,sum(oracledb_size_user_segments_top100_table_bytes) by (segment_name, owner)) Partition SizeUse the following query to determine the top 10 dba partitions ordered by size:\ntopk(10,sum(oracledb_size_dba_segments_top100_table_partition_bytes) by (segment_name)) Use the following query to determine the top 10 user partitions ordered by size:\ntopk(10,sum(oracledb_size_user_segments_top100_table_partition_bytes) by (segment_name)) Related Blog Posts How to monitor an Oracle database with Prometheus Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: oracledb-exporter-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;oracledb\u0026#34; - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/oracledb/"},{"id":514,"title":"PHP-FPM","content":" This integration is enabled by default.\nVersions supported: \u0026gt; 7.2\nThis integration uses a sidecar exporter that is available in UBI or scratch base image.\nThis integration has 12 metrics.\nTimeseries generated: 167 timeseries\nList of Alerts Alert Description Format [Php-Fpm] Percentage of instances low Less than 75% of instances are up Prometheus [Php-Fpm] Recently reboot Instances have been recently reboot Prometheus [Php-Fpm] Limit of child process exceeded Number of childs process have been exceeded Prometheus [Php-Fpm] Reaching limit of queue process Buffer of queue requests reaching its limit Prometheus [Php-Fpm] Too slow requests processing Requests have taking too much time to be processed Prometheus List of DashboardsPhp-fpmThe dashboard provides information on the status of Php-fpm. List of Metrics Metric name kube_workload_status_desired phpfpm_accepted_connections phpfpm_active_processes phpfpm_idle_processes phpfpm_listen_queue phpfpm_listen_queue_length phpfpm_max_children_reached phpfpm_process_requests phpfpm_slow_requests phpfpm_start_since phpfpm_total_processes phpfpm_up PrerequisitesEnable Status PathFor the exporter to generate metrics, you need to configure some parameters in PHP-FPM to expose the status path. These configuration parameters are:\npm.status_path listen Here is an example of how to configure them in Kubernetes:\napiVersion: v1 kind: ConfigMap metadata: labels: app: php-fpm name: php-fpm-config namespace: php-fpm data: www.conf: | [www] listen=127.0.0.1:9000 pm.status_path=/status apiVersion: apps/v1 kind: Deployment metadata: name: php-fpm-app namespace: php-fpm labels: app: php-fpm pod: php-app spec: selector: matchLabels: app: php-fpm replicas: 3 template: metadata: labels: app: php-fpm pod: php-app spec: containers: - image: php:7.2-fpm imagePullPolicy: Always name: php-fpm ports: - containerPort: 9000 protocol: TCP # Config-map include volumeMounts: - name: php-fpm-config mountPath: /usr/local/etc/php-fpm.d/www.conf subPath: www.conf volumes: - configMap: defaultMode: 420 name: php-fpm-config name: php-fpm-config InstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/php-fpm-exporter\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: php-fpm-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (php-fpm-exporter);(.{0}$) replacement: php-fpm target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;php-fpm\u0026#34; - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (phpfpm_accepted_connections|phpfpm_active_processes|phpfpm_idle_processes|phpfpm_listen_queue|phpfpm_listen_queue_length|phpfpm_max_active_processes|phpfpm_max_children_reached|phpfpm_max_listen_queue|phpfpm_process_last_request_cpu|phpfpm_process_last_request_memory|phpfpm_process_request_duration|phpfpm_process_requests|phpfpm_process_state|phpfpm_scrape_failures|phpfpm_slow_requests|phpfpm_start_since|phpfpm_total_processes|phpfpm_up) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/php-fpm/"},{"id":515,"title":"Portworx","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v2.9.1.1\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 76 metrics.\nTimeseries generated: 1090 timeseries\nList of Alerts Alert Description Format [Portworx] No Quorum Portworx No Quorum. Prometheus [Portworx] Node Status Not OK Portworx Node Status Not OK. Prometheus [Portworx] Offline Nodes Portworx Offline Nodes. Prometheus [Portworx] Nodes Storage Full or Down Portworx Nodes Storage Full or Down. Prometheus [Portworx] Offline Storage Nodes Portworx Offline Storage Nodes. Prometheus [Portworx] Unhealthy Node KVDB Portworx Unhealthy Node KVDB. Prometheus [Portworx] Cache read hit rate is low Portworx Cache read hit rate is low. Prometheus [Portworx] Cache write hit rate is low Portworx Cache write hit rate is low. Prometheus [Portworx] High Read Latency In Disk Portworx High Read Latency In Disk. Prometheus [Portworx] High Write Latency In Disk Portworx High Write Latency In Disk. Prometheus [Portworx] Low Cluster Capacity Portworx Low Cluster Capacity. Prometheus [Portworx] Disk Full In 48H Portworx Disk Full In 48H. Prometheus [Portworx] Disk Full In 12H Portworx Disk Full In 12H. Prometheus [Portworx] Pool Status Not Online Portworx Node Status Not Online. Prometheus [Portworx] High Write Latency In Pool Portworx High Write Latency In Pool. Prometheus [Portworx] Pool Full In 48H Portworx Pool Full In 48H. Prometheus [Portworx] Pool Full In 12H Portworx Pool Full In 12H. Prometheus [Portworx] High Write Latency In Volume Portworx High Write Latency In Volume. Prometheus [Portworx] High Read Latency In Volume Portworx High Read Latency In Volume. Prometheus [Portworx] License Expiry Portworx License Expiry. Prometheus List of DashboardsPortworx ClusterThe dashboard provides information on the status of the Portworx cluster. Portworx VolumesThe dashboard provides information on the status of the Portworx volumes. List of Metrics Metric name go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds px_cluster_disk_available_bytes px_cluster_disk_total_bytes px_cluster_status_nodes_offline px_cluster_status_nodes_online px_cluster_status_nodes_storage_down px_cluster_status_quorum px_cluster_status_size px_cluster_status_storage_nodes_decommissioned px_cluster_status_storage_nodes_offline px_cluster_status_storage_nodes_online px_disk_stats_num_reads_total px_disk_stats_num_writes_total px_disk_stats_read_bytes_total px_disk_stats_read_latency_seconds px_disk_stats_used_bytes px_disk_stats_write_latency_seconds px_disk_stats_written_bytes_total px_kvdb_health_state_node_view px_network_io_received_bytes_total px_network_io_sent_bytes_total px_node_status_license_expiry px_node_status_node_status px_pool_stats_available_bytes px_pool_stats_flushed_bytes_total px_pool_stats_num_flushes_total px_pool_stats_num_writes px_pool_stats_status px_pool_stats_total_bytes px_pool_stats_write_latency_seconds px_pool_stats_written_bytes px_px_cache_read_hits px_px_cache_read_miss px_px_cache_write_hits px_px_cache_write_miss px_volume_attached px_volume_attached_state px_volume_capacity_bytes px_volume_currhalevel px_volume_halevel px_volume_read_bytes_total px_volume_read_latency_seconds px_volume_reads_total px_volume_replication_status px_volume_state px_volume_status px_volume_usage_bytes px_volume_write_latency_seconds px_volume_writes_total px_volume_written_bytes_total PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent jobs for this integration are as follows:\n- job_name: \u0026#39;portworx-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (portworx);(.{0}$) replacement: portworx target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;portworx\u0026#34; - action: replace source_labels: [__address__] regex: ([^:]+)(?::\\d+)? replacement: $1:9001 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (px_cluster_disk_available_bytes|px_cluster_disk_total_bytes|px_cluster_status_nodes_offline|px_cluster_status_nodes_online|px_cluster_status_nodes_storage_down|px_cluster_status_quorum|px_cluster_status_size|px_cluster_status_storage_nodes_decommissioned|px_cluster_status_storage_nodes_offline|px_cluster_status_storage_nodes_online|px_disk_stats_num_reads_total|px_disk_stats_num_writes_total|px_disk_stats_read_bytes_total|px_disk_stats_read_latency_seconds|px_disk_stats_used_bytes|px_disk_stats_write_latency_seconds|px_disk_stats_written_bytes_total|px_kvdb_health_state_node_view|px_network_io_received_bytes_total|px_network_io_sent_bytes_total|px_node_status_license_expiry|px_node_status_node_status|px_pool_stats_available_bytes|px_pool_stats_flushed_bytes_total|px_pool_stats_num_flushes_total|px_pool_stats_num_writes|px_pool_stats_status|px_pool_stats_total_bytes|px_pool_stats_write_latency_seconds|px_pool_stats_written_bytes|px_px_cache_read_hits|px_px_cache_read_miss|px_px_cache_write_hits|px_px_cache_write_miss|px_volume_attached|px_volume_attached_state|px_volume_capacity_bytes|px_volume_currhalevel|px_volume_halevel|px_volume_read_bytes_total|px_volume_read_latency_seconds|px_volume_reads_total|px_volume_replication_status|px_volume_state|px_volume_status|px_volume_usage_bytes|px_volume_write_latency_seconds|px_volume_writes_total|px_volume_written_bytes_total) action: keep - job_name: \u0026#39;portworx-openshift-default\u0026#39; tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (portworx);(.{0}$) replacement: portworx target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;portworx\u0026#34; - action: replace source_labels: [__address__] regex: ([^:]+)(?::\\d+)? replacement: $1:17001 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (go_build_info|go_info|go_gc_duration_seconds|go_gc_duration_seconds_count|go_gc_duration_seconds_sum|go_goroutines|go_memstats_buck_hash_sys_bytes|go_memstats_gc_sys_bytes|go_memstats_heap_alloc_bytes|go_memstats_heap_idle_bytes|go_memstats_heap_inuse_bytes|go_memstats_heap_released_bytes|go_memstats_heap_sys_bytes|go_memstats_lookups_total|go_memstats_mallocs_total|go_memstats_mcache_inuse_bytes|go_memstats_mcache_sys_bytes|go_memstats_mspan_inuse_bytes|go_memstats_mspan_sys_bytes|go_memstats_next_gc_bytes|go_memstats_stack_inuse_bytes|go_memstats_stack_sys_bytes|go_memstats_sys_bytes|go_threads|process_cpu_seconds_total|process_max_fds|process_open_fds|px_cluster_disk_available_bytes|px_cluster_disk_total_bytes|px_cluster_status_nodes_offline|px_cluster_status_nodes_online|px_cluster_status_nodes_storage_down|px_cluster_status_quorum|px_cluster_status_size|px_cluster_status_storage_nodes_decommissioned|px_cluster_status_storage_nodes_offline|px_cluster_status_storage_nodes_online|px_disk_stats_num_reads_total|px_disk_stats_num_writes_total|px_disk_stats_read_bytes_total|px_disk_stats_read_latency_seconds|px_disk_stats_used_bytes|px_disk_stats_write_latency_seconds|px_disk_stats_written_bytes_total|px_kvdb_health_state_node_view|px_network_io_received_bytes_total|px_network_io_sent_bytes_total|px_node_status_license_expiry|px_node_status_node_status|px_pool_stats_available_bytes|px_pool_stats_flushed_bytes_total|px_pool_stats_num_flushes_total|px_pool_stats_num_writes|px_pool_stats_status|px_pool_stats_total_bytes|px_pool_stats_write_latency_seconds|px_pool_stats_written_bytes|px_px_cache_read_hits|px_px_cache_read_miss|px_px_cache_write_hits|px_px_cache_write_miss|px_volume_attached|px_volume_attached_state|px_volume_capacity_bytes|px_volume_currhalevel|px_volume_halevel|px_volume_read_bytes_total|px_volume_read_latency_seconds|px_volume_reads_total|px_volume_replication_status|px_volume_state|px_volume_status|px_volume_usage_bytes|px_volume_write_latency_seconds|px_volume_writes_total|px_volume_written_bytes_total) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/portworx/"},{"id":516,"title":"PostgreSQL","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v9.4\nThis integration uses a standalone exporter that is available in UBI or scratch base image.\nThis integration has 34 metrics.\nTimeseries generated: 250 series per instance + 25 series per database + 30 series per table\nList of Alerts Alert Description Format [PostgreSQL] Instance Down PostgreSQL instance is unavailable Prometheus [PostgreSQL] Max Write Buffer Reached Background writer stops because it reached the maximum write buffers Prometheus [PostgreSQL] High WAL Files Archive Error Rate High error rate in WAL files archiver Prometheus [PostgreSQL] Low Available Connections Low available network connections Prometheus [PostgreSQL] High Response Time High response time in at least one of the databases Prometheus [PostgreSQL] Low Cache Hit Rate Low cache hit rate Prometheus [PostgreSQL] DeadLocks In Database Deadlocks detected in database Prometheus List of DashboardsPostgreSQL Instance HealthThe dashboard provides information on the status, error rate and resource usage of a PostgreSQL instance. PostgreSQL Database DetailsThe dashboard provides information on the connections, cache hit rate, error rate, latency and traffic of one of the databases of the postgreSQL instance. List of Metrics Metric name pg_database_size_bytes pg_locks_count pg_replication_lag_seconds pg_settings_max_connections pg_settings_superuser_reserved_connections pg_stat_activity_count pg_stat_activity_max_tx_duration pg_stat_archiver_archived_count pg_stat_archiver_failed_count pg_stat_bgwriter_buffers_alloc_total pg_stat_bgwriter_buffers_backend_total pg_stat_bgwriter_buffers_checkpoint_total pg_stat_bgwriter_buffers_clean_total pg_stat_bgwriter_checkpoint_sync_time_total pg_stat_bgwriter_checkpoint_write_time_total pg_stat_bgwriter_checkpoints_req_total pg_stat_bgwriter_checkpoints_timed_total pg_stat_bgwriter_maxwritten_clean_total pg_stat_database_blk_read_time pg_stat_database_blks_hit pg_stat_database_blks_read pg_stat_database_conflicts_confl_deadlock pg_stat_database_conflicts_confl_lock pg_stat_database_deadlocks pg_stat_database_numbackends pg_stat_database_temp_bytes pg_stat_database_tup_deleted pg_stat_database_tup_fetched pg_stat_database_tup_inserted pg_stat_database_tup_returned pg_stat_database_tup_updated pg_stat_database_xact_commit pg_stat_database_xact_rollback pg_up PrerequisitesCreate Credentials for the Exporter in the DatabaseIf you want to use a no-admin user for the exporter, you will have to create the user and associated views and permissions to be able to gather the data from the tables.\nThe Postgres exporter documentation contains the following script that you can use in your database to create the exporter user:\nNote: Before running the script, be sure to set the correct password for the user in the line: ALTER USER postgres_exporter WITH PASSWORD 'password';\nCREATE OR REPLACE FUNCTION __tmp_create_user() returns void as $$ BEGIN IF NOT EXISTS ( SELECT -- SELECT list can stay empty for this FROM pg_catalog.pg_user WHERE usename = \u0026#39;postgres_exporter\u0026#39;) THEN CREATE USER postgres_exporter; END IF; END; $$ language plpgsql; SELECT __tmp_create_user(); DROP FUNCTION __tmp_create_user(); ALTER USER postgres_exporter WITH PASSWORD \u0026#39;password\u0026#39;; ALTER USER postgres_exporter SET SEARCH_PATH TO postgres_exporter,pg_catalog; -- If deploying as non-superuser (for example in AWS RDS), uncomment the GRANT -- line below and replace \u0026lt;MASTER_USER\u0026gt; with your root user. -- GRANT postgres_exporter TO \u0026lt;MASTER_USER\u0026gt;; CREATE SCHEMA IF NOT EXISTS postgres_exporter; GRANT USAGE ON SCHEMA postgres_exporter TO postgres_exporter; GRANT CONNECT ON DATABASE postgres TO postgres_exporter; CREATE OR REPLACE FUNCTION get_pg_stat_activity() RETURNS SETOF pg_stat_activity AS $$ SELECT * FROM pg_catalog.pg_stat_activity; $$ LANGUAGE sql VOLATILE SECURITY DEFINER; CREATE OR REPLACE VIEW postgres_exporter.pg_stat_activity AS SELECT * from get_pg_stat_activity(); GRANT SELECT ON postgres_exporter.pg_stat_activity TO postgres_exporter; CREATE OR REPLACE FUNCTION get_pg_stat_replication() RETURNS SETOF pg_stat_replication AS $$ SELECT * FROM pg_catalog.pg_stat_replication; $$ LANGUAGE sql VOLATILE SECURITY DEFINER; CREATE OR REPLACE VIEW postgres_exporter.pg_stat_replication AS SELECT * FROM get_pg_stat_replication(); GRANT SELECT ON postgres_exporter.pg_stat_replication TO postgres_exporter; Create a Secret with the CredentialsTo create the secret with the user and password, you have to take in mind:\nIt has to be in the same namespace where the exporter will be deployed. Use the same user name and password that you used to create the exporter user in the database in the previous step. You can change the name of the secret. If you do it, you will need to select it in the next steps of the integration. Without TLS certskubectl create -n Your-Application-Namespace secret generic postgresql-exporter \\ --from-literal=username=userName \\ --from-literal=password=password With TLS certskubectl create -n Your-Application-Namespace secret generic postgresql-exporter \\ --from-literal=username=userName \\ --from-literal=password=password \\ --from-file=sslRootCert=/path/to/tls/cert InstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/postgresql-exporter\nRelated Blog Posts Top metrics in PostgreSQL monitoring with Prometheus - Includes cheat sheet Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: postgres-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;postgresql\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_ns] target_label: kube_namespace_name - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_type] target_label: kube_workload_type - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_name] target_label: kube_workload_name - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (pg_replication_lag_seconds|pg_database_size_bytes|pg_locks_count|pg_settings_max_connections|pg_settings_superuser_reserved_connections|pg_stat_activity_count|pg_stat_activity_max_tx_duration|pg_stat_archiver_archived_count|pg_stat_archiver_failed_count|pg_stat_bgwriter_buffers_alloc_total|pg_stat_bgwriter_buffers_backend_total|pg_stat_bgwriter_buffers_checkpoint_total|pg_stat_bgwriter_buffers_clean_total|pg_stat_bgwriter_checkpoint_sync_time_total|pg_stat_bgwriter_checkpoint_write_time_total|pg_stat_bgwriter_checkpoints_req_total|pg_stat_bgwriter_checkpoints_timed_total|pg_stat_bgwriter_maxwritten_clean_total|pg_stat_database_blk_read_time|pg_stat_database_blks_hit|pg_stat_database_blks_read|pg_stat_database_conflicts_confl_deadlock|pg_stat_database_conflicts_confl_lock|pg_stat_database_deadlocks|pg_stat_database_numbackends|pg_stat_database_temp_bytes|pg_stat_database_tup_deleted|pg_stat_database_tup_fetched|pg_stat_database_tup_inserted|pg_stat_database_tup_returned|pg_stat_database_tup_updated|pg_stat_database_xact_commit|pg_stat_database_xact_rollback|pg_up) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/postgresql/"},{"id":517,"title":"Quay.io","content":" Ensure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes.\n$ helm upgrade --install registry-scanner sysdig/registry-scanner --version=1 \\ --set config.secureBaseURL=\u0026lt;SYSDIG_SECURE_URL\u0026gt; \\ --set config.secureAPIToken=\u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt; \\ --set config.registryType=quay \\ --set config.registryURL=quay.io \\ --set config.registryUser=\u0026lt;QUAY_USER\u0026gt; \\ --set config.registryPassword=\u0026lt;QUAY_PASSWORD\u0026gt; \u0026lt;QUAY_USER\u0026gt;: CLI user for Quay.io. \u0026lt;QUAY_PASSWORD\u0026gt;: CLI password for Quay.io. It must be generated through the account settings. ","url":"https://docs.sysdig.com/en/sysdig-secure/quay-scan/"},{"id":518,"title":"RabbitMQ","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v3.8\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 41 metrics.\nTimeseries generated: 730 series per instance\nList of Alerts Alert Description Format [RabbitMQ] Cluster Operator Unavailable Replicas There are kube_pod_names that are either running but not yet available or kube_pod_names that still have not been created. Prometheus [RabbitMQ] Insufficient Established Erlang Distribution Links Insuffient establised erland distribution links Prometheus [RabbitMQ] Low Disk Watermark Predicted The predicted free disk space in 24 hours from now is low Prometheus [RabbitMQ] High Connection Churn There are a high connection churn Prometheus [RabbitMQ] No MajorityOfNodesReady There are so many nodes not ready Prometheus [RabbitMQ] Persistent Volume Missing There is at least one pvc not bound Prometheus [RabbitMQ] Unroutable Messages There were unroutable message within the last 5 minutes in RabbitMQ cluster Prometheus [RabbitMQ] File Descriptors Near Limit The file descriptors are near to the limit Prometheus [RabbitMQ] Container Restarts Over the last 10 minutes a rabbitmq container was restarted Prometheus [RabbitMQ] TCP Sockets Near Limit The TCP sockets are near to the limit Prometheus List of DashboardsRabbitmq UsageThe dashboard provides information on the usage of each queues, channels and connections. Rabbitmq OverviewThe dashboard provides information on the nodes, queues and erlang of a RabbitMQ cluster. List of Metrics Metric name erlang_vm_dist_node_state kube_deployment_status_replicas_unavailable kube_kube_pod_name_container_status_restarts_total kube_persistentvolumeclaim_status_phase kube_statefulset_replicas kube_statefulset_status_replicas_ready rabbitmq_build_info rabbitmq_channel_consumers rabbitmq_channel_get_ack_total rabbitmq_channel_get_empty_total rabbitmq_channel_get_total rabbitmq_channel_messages_acked_total rabbitmq_channel_messages_confirmed_total rabbitmq_channel_messages_delivered_ack_total rabbitmq_channel_messages_delivered_total rabbitmq_channel_messages_published_total rabbitmq_channel_messages_redelivered_total rabbitmq_channel_messages_unconfirmed rabbitmq_channel_messages_unroutable_dropped_total rabbitmq_channel_messages_unroutable_returned_total rabbitmq_channels rabbitmq_channels_closed_total rabbitmq_channels_opened_total rabbitmq_connections rabbitmq_connections_closed_total rabbitmq_connections_opened_total rabbitmq_disk_space_available_bytes rabbitmq_disk_space_available_limit_bytes rabbitmq_process_max_fds rabbitmq_process_max_tcp_sockets rabbitmq_process_open_fds rabbitmq_process_open_tcp_sockets rabbitmq_process_resident_memory_bytes rabbitmq_queue_messages_published_total rabbitmq_queue_messages_ready rabbitmq_queue_messages_unacked rabbitmq_queues rabbitmq_queues_created_total rabbitmq_queues_declared_total rabbitmq_queues_deleted_total rabbitmq_resident_memory_limit_bytes PrerequisitesEnable Prometheus MetricsRabbitmq instruments Prometheus metrics and annotates the metrics API pod with Prometheus annotations.\nMake sure that Prometheus metrics are activated. If they are not, activate the plugin using this command inside of the rabbitmq container:\nrabbitmq-plugins enable rabbitmq_prometheus InstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rabbitmq-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: replace source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: (rabbitmq);(.{0}$) replacement: $1 target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;rabbitmq\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (erlang_vm_dist_node_state|rabbitmq_build_info|rabbitmq_channel_consumers|rabbitmq_channel_get_ack_total|rabbitmq_channel_get_empty_total|rabbitmq_channel_get_total|rabbitmq_channel_messages_acked_total|rabbitmq_channel_messages_confirmed_total|rabbitmq_channel_messages_delivered_ack_total|rabbitmq_channel_messages_delivered_total|rabbitmq_channel_messages_published_total|rabbitmq_channel_messages_redelivered_total|rabbitmq_channel_messages_unconfirmed|rabbitmq_channel_messages_unroutable_dropped_total|rabbitmq_channel_messages_unroutable_returned_total|rabbitmq_channels|rabbitmq_channels_closed_total|rabbitmq_channels_opened_total|rabbitmq_connections|rabbitmq_connections_closed_total|rabbitmq_connections_opened_total|rabbitmq_disk_space_available_bytes|rabbitmq_disk_space_available_limit_bytes|rabbitmq_process_max_fds|rabbitmq_process_max_tcp_sockets|rabbitmq_process_open_fds|rabbitmq_process_open_tcp_sockets|rabbitmq_process_resident_memory_bytes|rabbitmq_queue_messages_published_total|rabbitmq_queue_messages_ready|rabbitmq_queue_messages_unacked|rabbitmq_queues|rabbitmq_queues_created_total|rabbitmq_queues_declared_total|rabbitmq_queues_deleted_total|rabbitmq_resident_memory_limit_bytes) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rabbitmq/"},{"id":519,"title":"Rapid Response","content":" Rapid Response team members have access to a full shell from the Sysdig Secure UI. Responsibility for the security of this powerful feature rests with you, your enterprise, and your designated employees.\nSee also: Rapid Response.\nNote: You can also install Rapid Response on Kubernetes.\nPrerequisites Retrieve your access key to use for SYSDIG_ACCESS_KEY=\u0026lt;your-access-key\u0026gt;\nCheck your Sysdig Secure endpoint by region to use for SYSDIG_API_URL=https://\u0026lt;sysdig-url\u0026gt; (SaaS)\nThis value is custom for on-prem installations. Ensure that you have the password used to encrypt all traffic between the user and the host.\nSysdig cannot recover this password. If lost, you will not be able to start a session, nor will any session logs be recoverable.\nInstallation Run the following Docker command to mount the host directories and binaries to gain access to the host:\ndocker run --hostname $HOST_NAME -d quay.io/sysdig/rapid-response-host-component:latest --endpoint $API_ENDPOINT --access-key $ACCESS_KEY --password $PASSWORD This command will start the Rapid Response Host Component container, passing in environment variables for the hostname, Sysdig API endpoint, access key, and password.\nTo customize the container, you can create a Dockerfile that installs more scripts or command-line utilities. For example, you can add the kubectl or gcloud command-line utilities by installing them in the Dockerfile.\nSince the Alpine Linux distribution used by the Sysdig container doesn\u0026rsquo;t support bash by default, you need to install it in the Dockerfile using the apk package manager. You can also add any custom scripts or directives at this point.\nFROM quay.io/sysdig/rapid-response-host-component:latest AS base-image FROM alpine:3.13 COPY --from=base-image /usr/bin/host /usr/bin/host RUN apk update \u0026amp;\u0026amp; \\ apk add bash \u0026amp;\u0026amp; \\ rm -rf /var/cache/apk/* # add custom scripts and other directives ENTRYPOINT [\u0026#34;host\u0026#34;] Once you\u0026rsquo;ve built the custom Docker image, you can use it to start the Sysdig Rapid Response Host Component container. Make sure to set the ENTRYPOINT directive to the command that you want the container to execute when it starts up.\nAfter you install Rapid Response, configure team(s) to use it.\nConfigure Log StorageTo save session logs, you must configure Rapid Response custom storage.\nIf you are using the default storage for Capture files, configure an AWS or custom S3 bucket to store Rapid Response log files after a session. If you have already configured an S3 bucket for Captures, then Rapid Response logs are routed there automatically, into their own folder.\nFor SaaS Users with Sysdig Secure Only: Contact Sysdig Support for help to create a custom S3 bucket for rapid response logs.\nNext StepsInstall the Agent as a container\nInstall the Host Scanner as a container\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-rapid-response/"},{"id":520,"title":"Redis","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v2\nThis integration uses a standalone exporter that is available in UBI or scratch base image.\nThis integration has 34 metrics.\nTimeseries generated: 150 series per instance\nList of Alerts Alert Description Format [Redis] Low UpTime Uptime of less than 1 hour in a redis instance Prometheus [Redis] High Memory Usage High memory usage Prometheus [Redis] High Clients Usage High client connections usage Prometheus [Redis] High Response Time Response time over 250ms Prometheus [Redis] High Fragmentation Ratio High fragmentation ratio Prometheus [Redis] High Keys Eviction Ratio High keys eviction ratio Prometheus [Redis] Recurrent Rejected Connections Recurrent rejected connections Prometheus [Redis] Low Hit Ratio Low keyspace hit ratio Prometheus [Redis] Exporter Process Down Exporter process is not serving metrics Prometheus List of DashboardsRedisThe dashboard provides information on the status, error rate, latency, traffic and resource usage of a Redis instance. List of Metrics Metric name redis_blocked_clients redis_commands_duration_seconds_total redis_commands_processed_total redis_commands_total redis_config_maxclients redis_connected_clients redis_connected_slaves redis_connections_received_total redis_cpu_sys_children_seconds_total redis_cpu_sys_seconds_total redis_cpu_user_children_seconds_total redis_cpu_user_seconds_total redis_db_avg_ttl_seconds redis_db_keys redis_evicted_keys_total redis_expired_keys_total redis_keyspace_hits_total redis_keyspace_misses_total redis_mem_fragmentation_ratio redis_memory_max_bytes redis_memory_used_bytes redis_memory_used_dataset_bytes redis_memory_used_lua_bytes redis_memory_used_overhead_bytes redis_memory_used_scripts_bytes redis_net_input_bytes_total redis_net_output_bytes_total redis_pubsub_channels redis_pubsub_patterns redis_rdb_changes_since_last_save redis_rdb_last_save_timestamp_seconds redis_rejected_connections_total redis_slowlog_length redis_uptime_in_seconds PrerequisitesBasic AuthenticationFollow these steps if your Redis server requires user and password authentication\n1.- Create a user and password in your Redis instance for the exporter.\nACL SETUSER USERNAME +client +ping +info +config|get +cluster|info +slowlog +latency +memory +select +get +scan +xinfo +type +pfcount +strlen +llen +scard +zcard +hlen +xlen +eval allkeys on \u0026gt;PASSWORD Replace USERNAME and PASSWORD with yours for the Redis instance.\n2.- Create a secret with the user and password for the exporter. Keep the following in mind:\nIt has to be in the same namespace where the exporter will be deployed. Use the same user name and password that you used for the api in the previous step. You can change the name of the secret. If you do it, you will need to select it in the next steps of the integration. kubectl create secret -n Your-Application-Namespace generic redis-exporter-auth \\ --from-literal=user=USER \\ --from-literal=password=PASSWORD Replace USER and PASSWORD with yours for the Redis instance.\nInstallationAn automated wizard is present in the Monitoring Integrations in Sysdig Monitor. Expert users can also use the Helm chart for installation: https://github.com/sysdiglabs/integrations-charts/tree/main/charts/redis-exporter\nRelated Blog Posts How to monitor Redis with Prometheus Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: redis-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;redis\u0026#34; - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_ns] target_label: kube_namespace_name - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_type] target_label: kube_workload_type - action: replace source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_target_workload_name] target_label: kube_workload_name - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_promcat_sysdig_com_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/redis/"},{"id":521,"title":"Redis Enterprise","content":" This integration is enabled by default.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 31 metrics.\nTimeseries generated: 680 TS per instance\nList of Alerts Alert Description Format [RedisEnterprise] Databases Down No databases available in you cluster Prometheus [RedisEnterprise] High Memory Usage High memory usage Prometheus [RedisEnterprise] High Fragmentation Ratio High fragmentation ratio Prometheus [RedisEnterprise] High database reads misses ratio High database reads misses ratio Prometheus [RedisEnterprise] High database writes misses ratio High database writes misses ratio Prometheus List of DashboardsRedis EnterpriseThe dashboard provides information on the status, error rate, latency, traffic and resource usage of a Redis Enterprise instance. List of Metrics Metric name bdb_conns bdb_no_of_keys bdb_pubsub_channels bdb_pubsub_patterns bdb_read_hits bdb_read_misses bdb_total_req bdb_total_res bdb_up bdb_write_hits bdb_write_misses listener_acc_latency listener_total_res redis_blocked_clients redis_connected_clients redis_connected_slaves redis_evicted_keys redis_expired_keys redis_maxmemory redis_mem_fragmentation_ratio redis_process_cpu_system_seconds_total redis_process_cpu_user_seconds_total redis_total_commands_processed redis_total_connections_received redis_total_net_input_bytes redis_total_net_output_bytes redis_used_memory redis_used_memory_lua redis_used_memory_peak redis_used_memory_rss redis_used_memory_scripts PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: redis-enterprise-default scheme: https tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - action: replace source_labels: - __meta_kubernetes_pod_label_redis_io_role_master - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: 1;(.{0}$) replacement: redis target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;redis\u0026#34; - source_labels: [__address__] regex: ([^:]+)(?::\\d+)? replacement: $1:8070 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/redis-enterprise/"},{"id":522,"title":"Registry Scanning","content":"SetupPrerequisites Helm v3.8 or above\nA Kubernetes cluster managed with Helm\nThe registry scanner is installed on this cluster\nA Sysdig Secure API token\nRecommended: Set up a service account with minimal privileges, such as a Custom role\nThe Custom role will require: Vulnerability Management permissions for Sysdig Secure: Registry Scanner: exec Scan Results: read Scanning Legacy permissions: Scanning Image Results: create Network access to the target registry for the installed components\nOutbound network access to the Sysdig backend to store results\nIf you are behind a firewall, follow the outbound network rules for vulnerability scanning.\nSupported Registries AWS Elastic Container Registry (ECR) Single Registry, Organizational AWS GovCloud Elastic Container Registry (ECR) Single Registry, Organizational JFrog Artifactory SaaS, OnPrem Azure Container Registry (ACR) Single Registry IBM Container Registry (ICR) Quay.io SaaS Harbor Google Artifact Registry (GAR), Container Registry (GCR) Single Registry Nexus OpenShift Container Platform Registry Known Limitations A new registry scanner must be installed per registry (except for AWS Organization). Public registries are not supported. Images that have been scanned and reported to Sysdig are rescanned only on the designated refresh cycle. Scans are refreshed on a scheduled Helm cron job, every Saturday at 6:00 AM by default. You can adjust the schedule. Check vendor-specific limitations on the relevant subpage. Registry Scanner does not support multi-architecture images. Installation Legacy scanning engine: If you still use the legacy scanning engine and want to keep running that version, pin the Helm chart version to 0.1.39. If you deploy a later version, the current vulnerability management engine will replace the legacy installation.\nOverview Install the Registry Scanner Helm Chart:\nhelm repo add sysdig https://charts.sysdig.com helm repo update Prepare the Helm chart for your specific registry vendor. Provide:\n\u0026lt;SYSDIG_SECURE_URL\u0026gt;: Region-dependent Sysdig Secure endpoint \u0026lt;SYSDIG_SECURE_API_TOKEN\u0026gt;: See Retrieve the Sysdig API Token Launch Helm instructions and allow some time for the first scan.\nCheck results in the Sysdig Secure Vulnerabilities | Registry UI.\nUpgradePerform regular helm chart upgrade procedure:\nUpgrade the repository with helm repo update Re-launch the helm upgrade --install with the values from the previous installation. Next Steps Review the scan results in the Sysdig Secure UI. Create scanning reports. ","url":"https://docs.sysdig.com/en/sysdig-secure/install-registry-scanner/"},{"id":523,"title":"Roles","content":" Deprecation Notice Upcoming Changes to Sysdig Product Line\nThe legacy Identity pages are now deprecated and will be phased out over a transition period. During this time, both the legacy and new experiences will remain available. We encourage you to start using the new Identity Overview and Findings pages to become familiar with the updated experience.\nFilter and Sort RolesUse the sortable columns to organize and filter roles for assessing identity risks. You can sort roles based on the following criteria:\nUnused Permission CriticalityUnused Permission Criticality focuses on unused permissions, while Permission Criticality looks at all permissions. Unused Permission Criticality is designed to help you achieve Least Permissive access.\nValues: Critical, High, Medium, Low\nRiskThis is a calculation of risk based on all permissions. See Understanding Risk Scoring for more information.\nValues: Critical, High, Medium, Low\n% of Unused PermissionsThis shows the number of unused permissions used with the role, per total permissions assigned to the role, shown as a percentage graph.\nWhen remediating, immediately target the roles with the greatest exposure and refine them according to the suggestions.\nMembershipFor AWS, this reflects the number of users who can use this role.\nFor GCP, the membership number reflects the number of users, groups, and/or service accounts who are bound to this role.\nHighest AccessValues:\nAdmin: Admin access granted Write: Write access granted Read: Read access granted Empty Access: No permissions are granted at all For more information, see Understand Highest Access.\nFindingsA finding in Cloud Infrastructure Entitlement Management (CIEM) indicates poor security hygiene, either due to misconfiguration or inadequate identity security practices. The findings on Roles pages include:\nAdmin Inactive Available Filters Search: Free text search on terms in the resource name Platform: by provider, e.g. AWS Unused Permission Criticalities: By severity Cloud Accounts: Account name/number by cloud provider (e.g. AWS) Access Categories: Admin, Write, Read, or Empty Access Findings: Admin , Inactive Next Steps Optimize AWS Role Entitlements Optimize GCP Role Entitlements Optimize Azure Role Entitlements ","url":"https://docs.sysdig.com/en/sysdig-secure/roles/"},{"id":524,"title":"SaaS: Sysdig Secure Release Notes","content":" You may also want to review the update log for Falco rules used in the Policy Editor: Falco Rules Changelog. The dates shown are for the initial release of a feature. The feature may not be rolled out to all regions concurrently and availability of a feature in a particular region will depend on scheduling.\nSupported Web BrowsersSysdig supports, tests, and verifies the latest versions of Chrome and Firefox. Other browsers may also work but are not tested in the same way.\nMay 26, 2026Sysdig CLI Scanner v1.27.0Enhancements Added the Flashpoint KEV tag and Flashpoint CVSSv3 Temporal score to vulnerability output. Defect Fixes Fixed a bug where the CLI Scanner could report incorrect vulnerabilities for images based on Rocky Linux 10 Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-33414 CVE-2026-33811 CVE-2026-33814 CVE-2026-34040 CVE-2026-35206 CVE-2026-39820 CVE-2026-39836 May 22, 2026Upcoming EnhancementsThe following vulnerability feed changes are planned for release on 22 June 2026. These changes may affect reported vulnerability counts and severities in Sysdig.\nAlpine vulnerabilities without fixesSysdig will begin reporting Alpine vulnerabilities even when no fix is available. Currently, Sysdig reports Alpine vulnerabilities only when a fix has been published. After this update, Sysdig will also report vulnerabilities that do not yet have an available fix.\nIf you are using Alpine-based images or hosts, you may observe an increase in reported vulnerabilities and findings. This change reflects expanded vulnerability coverage and does not indicate an increase in risk within the environment.\nUbuntu Severity Scoring ChangesSysdig will use Ubuntu-provided CVSS v3 severity scores for Ubuntu vulnerabilities.\nCurrently, Sysdig uses Ubuntu priority ratings to determine vulnerability severity. After this update, Sysdig will instead use the Ubuntu-provided CVSS v3 severity score.\nBecause Ubuntu priority and CVSS v3 use different scoring models, some vulnerabilities may appear with a different severity after the update.\nFor example, Ubuntu lists CVE-2026-7474 with:\nUbuntu priority: Medium CVSS v3 severity: High (8.8) You may observe severity distribution changes in vulnerability reports, dashboards, policies, and alerts.\nPython PDM SupportSysdig will add dependency extraction support for Python PDM projects.\nAfter this update, Sysdig will detect and scan dependencies managed through Python PDM as part of expanded package manager coverage.\nMay 15, 2026Response Actions in Resource DrawerYou can now perform Response Actions directly from the resource drawer. Use them to fetch data for threat hunting or to stop incidents without leaving the resource view.\nSupported resource types include:\nHosts: Host, Container, and File actions when Response Actions is configured on Host Shield. Kubernetes workloads: Kubernetes actions compatible with the selected resource when Response Actions is enabled on Cluster Shield. AWS resources: Cloud Response Actions compatible with the selected resource when Cloud Response Actions are deployed. You can also review the Response History for a resource and inspect action details, including execution status, target information, and configuration.\nFor more information, see Resources.\nMay 13, 2026KSPM Collector v1.39.19Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-15281 CVE-2025-68121 CVE-2026-0861 CVE-2026-0915 CVE-2026-25679 CVE-2026-27139 CVE-2026-27142 CVE-2026-32280 CVE-2026-32281 CVE-2026-32282 CVE-2026-32283 CVE-2026-32288 CVE-2026-32289 CVE-2026-33186 CVE-2026-33811 CVE-2026-33814 CVE-2026-39820 CVE-2026-39823 CVE-2026-39825 CVE-2026-39826 CVE-2026-39836 CVE-2026-42499 CVE-2026-4878 May 12, 2026Host Scanner v0.16.6Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-33811 CVE-2026-33814 CVE-2026-39820 CVE-2026-39823 CVE-2026-39825 CVE-2026-39826 CVE-2026-39836 CVE-2026-42499 CVE-2026-4878 May 8, 2026KSPM Analyzer v1.48.4Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-42501 CVE-2026-39825 CVE-2026-39836 CVE-2026-42499 CVE-2026-39820 CVE-2026-39819 CVE-2026-39817 CVE-2026-33814 CVE-2026-39826 CVE-2026-33811 CVE-2026-39823 May 7, 2026KSPM Analyzer v1.48.3Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-27135 CVE-2026-29111 CVE-2026-4424 CVE-2026-4786 CVE-2026-4878 CVE-2026-5121 CVE-2026-6100 May 5, 2026Response HistoryYou can now see what Response Actions have been taken, where, when and by who in the Response History page. The page collects all the Response Actions performed across the product, manually from events, automatically from Automations or through APIs, providing you with a single place to get collected artifacts or revert containment actions performed by mistake.\nFor more information, see Response History.\nMay 4, 2026Registry Scanner v0.11.4Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-27135 CVE-2026-4424 CVE-2026-4878 CVE-2026-29111 CVE-2026-5121 April 24, 2026Host Scanner v0.16.5Defect Fixes Fixed a bug which could cause host-scanner to hang indefinitely at startup when attempting to ping the Docker daemon if Non-Kubernetes Containers scanning is enabled. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-34040 CVE-2026-33997 April 15, 2026Agentless Host Scanning: Windows, Fedora, and Bottlerocket SupportSysdig Agentless Host Scanning now supports Windows, Fedora, and AWS Bottlerocket hosts, closing coverage gaps where these platforms previously appeared as \u0026ldquo;Not Supported\u0026rdquo; in agentless scanning. All scanning is performed from snapshots.\nNew platform support includes:\nWindows hosts: Host vulnerability scanning from snapshots. Fedora hosts: Host and container vulnerability scanning from snapshots. AWS Bottlerocket hosts: Host and container vulnerability scanning from snapshots. No new deployment steps are required. Supported hosts are scanned automatically as part of existing Agentless Host Scanning workflows. Coverage and findings appear in the same workspaces and reports.\nFor more information on Agentless Host Scanning, see Scanning Guidelines.\nApril 14, 2026Sysdig CLI Scanner v1.26.0Enhancements When outputting the scan results in v1 format, the JSON output now includes end-of-life (EOL) information for operating systems and the Go runtime package. Defect Fixes Fixed a bug where scanning a directory containing both CloudFormation and Terraform files with --iac mode returned no results. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-32280 CVE-2026-32281 CVE-2026-32282 CVE-2026-32283 CVE-2026-32288 CVE-2026-32289 Sysdig Runtime Scanner v1.8.9Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-32280 CVE-2026-32281 CVE-2026-32282 CVE-2026-32283 CVE-2026-32288 CVE-2026-32289 CVE-2026-33186 CVE-2026-34986 April 13, 2026Host Scanner v0.16.4Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-32280 CVE-2026-32281 CVE-2026-32282 CVE-2026-32283 CVE-2026-32288 CVE-2026-32289 CVE-2026-39883 April 10, 2026KSPM Analyzer v1.48.2Defect Fixes Fixed a bug where Linux host benchmark checks could produce duplicate sysctl values, causing incorrect false-positive posture results. Fixed a bug where kspm-analyzer sent requests incompatible with on-prem deployments earlier than version 7.7.0, preventing host posture scans from being scheduled. Fixed a bug where kspm-analyzer could send duplicated results for the same host, preventing host posture evaluation from being performed. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-32280 CVE-2026-32281 CVE-2026-32282 CVE-2026-32283 CVE-2026-32288 CVE-2026-32289 CVE-2026-4519 April 8, 2026Registry Scanner v0.11.3Defect Fixes Implemented prioritized detection logic for Red Hat Enterprise Linux Extended Update Support (EUS) versions. Fixed an issue where the new VM scanner Kubernetes job was unable to properly parse comma-separated pull secrets. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-33186 CVE-2025-15558 CVE-2026-4111 CVE-2025-14831 CVE-2026-25679 CVE-2026-27142 CVE-2026-0915 CVE-2026-27139 CVE-2025-15281 CVE-2025-9820 CVE-2026-0861 March 31, 2026EnhancementsSysdig Secure Main Navigation UpdateSysdig has now updated the Secure main navigation to improve access to key workflows and consolidate product areas. The navigation now includes:\nDashboards (Formerly Home): Gives you insights into identity, posture, vulnerabilities, and threats. Threat Intelligence: Displays a feed that highlights findings that need your attention. Graph Search: Lets you use a unified search to explore resources and relationships in ways that are faster and more complete. Attack Surface: Lets you identify risks and manage findings and exceptions. Detection \u0026amp; Response: Monitors and detects threats, events, audit activity, and captures, and configures Rapid Response flows. Inventory: Displays your multi-cloud resources. Reporting: Allows you to access Reports Manager and Scheduled Reports. Policies: Lets you view and set up policies. Integrations: Lets you connect your cloud accounts, data sources, and third-party tools. Settings: Manages account configuration, including API keys, SSO, users, teams, and certificates. Legacy navigation items remain available under Legacy submenus.\nMarch 25, 2026Host Scanner v0.16.2Enhancements Sysdig now supports Talos Linux OS, with vulnerability matching for non-OS packages. OS-level Talos vulnerabilities are not currently supported. Defect Fixes Fixed a bug which could cause unstructured logs to be emitted under specific conditions. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-33186 KSPM Analyzer v1.48.1Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-33186 March 23, 2026Sysdig CLI Scanner v1.25.2Defect Fixes Fixed a bug causing an incorrect fixVersion value in CSV and JSON scan report outputs. Fixed a bug causing a fatal error: concurrent map writes crash when analyzing Python uv.lock files. Fixed a bug causing RHEL EUS to be identified as a standard RHEL distribution. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-15558 CVE-2026-24051 CVE-2026-25679 CVE-2026-25934 CVE-2026-27139 CVE-2026-27142 CVE-2026-33186 March 17, 2026New Falco Rules for AI AgentsThe Sysdig Threat Research Team has released new managed Falco rules to detect suspicious activity involving AI coding agents (Codex, Gemini CLI, and Claude Code). The new rules are available in dedicated managed Policies.\nThe Policies are disabled by default. You can enable them from the Runtime Policies page, in Policies \u0026gt; Runtime Policies.\nNew Rules Codex Installation Detected Unauthorized Process Accessed Codex CLI Configuration Directory Codex CLI Executed with Risky CLI Arguments Codex CLI Accessing Sensitive Files Gemini Installation Detected Unauthorized Process Accessed Gemini CLI Configuration Directory Gemini CLI Accessing Sensitive Files Gemini CLI Executed with Risky CLI Arguments Claude Code Installation Detected Unauthorized Process Accessed Claude Code Configuration Directory Claude Code Executed with Risky CLI Arguments Claude Code Accessing Sensitive Files New Policies Sysdig AI Runtime Notable Events Sysdig AI Runtime Activity Logs For the full changelog, see Falco Rules Changelog.\nMarch 16, 2026Host Scanner v0.16.1Defect Fixes Fixed a bug which could cause host-scanner to use a wrong socket path when connecting to the container-runtime March 12, 2026Sysdig Runtime Scanner v1.8.8Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-15281 CVE-2025-68121 CVE-2026-0861 CVE-2026-0915 CVE-2026-22772 CVE-2026-24051 CVE-2026-24137 CVE-2026-25679 CVE-2026-27139 CVE-2026-27142 March 11, 2026KSPM Analyzer v1.48.0 Fixed an issue causing KSPM Analyzer to log the Sysdig backend access key when log level was set to debug. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-15281 CVE-2026-0861 CVE-2026-0915 CVE-2026-25679 CVE-2026-27137 CVE-2026-27138 CVE-2026-27139 CVE-2026-27142 March 10, 2026Host Scanner v0.16.0Defect Fixes Fixed an issue causing packages to not be detected in Amazon Linux, EulerOS, Talos, Alpine minimal/hardened oses. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2026-0915 CVE-2026-24051 CVE-2026-25679 CVE-2026-27137 CVE-2026-27138 CVE-2026-27142 CVE-2025-15281 CVE-2026-0861 CVE-2026-27139 March 3, 2026Be Notified in Local Time Instead of UTCYou can now configure notifications to display timestamps in local time instead of UTC. This setting applies globally to all notifications sent from the system.\nFor more information, see Time zone settings.\nFebruary 26, 2026Cloud Detection and Response (CDR) Renamed to Threat DetectionWhat was previously referred to as Cloud Detection and Response (CDR) is now called Threat Detection across Sysdig Secure. All documentation and UI references have been updated accordingly.\nCloud Response ActionsSysdig now supports Cloud Response Actions for AWS, allowing you to take containment and investigative actions directly from the Events feed. Available actions include EBS Volume Snapshot, Fetch Cloud Logs, Remove Public Access, and IAM Quarantine. For setup instructions, see Configure Threat Response on AWS. For details on executing actions, see Response Actions.\nSysdig Terraform Provider and Module Version UpdateThe Sysdig Terraform provider has been updated to ~\u0026gt;3.3 and all modules across AWS, GCP, Azure, and OCI have been bumped to a new major version. Existing customers who want to add new modules (including Cloud Response Actions) must update their main.tf provider version to ~\u0026gt;3.3, upgrade all existing module versions, and run terraform init -upgrade \u0026amp;\u0026amp; terraform apply. This is a one-time upgrade. For more details, see the Permissions and Resources page for your cloud:\nAWS Permissions and Resources Azure Permissions and Resources GCP Permissions and Resources OCI Permissions and Resources February 18, 2026Streamlined Jira Integration ConfigurationSysdig now automatically maps Jira issue status in Sysdig to the corresponding status categories in your Jira project, with no additional configuration required while setting up the integration. In addition, when you edit an existing Jira integration, you no longer need to re-enter your Jira API token. For more details, see Configure Jira Ticketing Integration.\nFebruary 17, 2026Amazon Kinesis Data Streams and Kinesis Firehose integrationsIt\u0026rsquo;s now possible to stream data from Sysdig out to these two streaming platforms available in AWS.\nYou can find the supported data types in the SIEM and Data Platforms integrations page. In the Sysdig Secure dashboard, you can find this under Integrations \u0026gt; SIEM \u0026amp; Data Platforms.\nThe instructions to set them up are available in the Forwarding to Amazon Kinesis Data Streams and Forwarding to Amazon Kinesis Firehose pages.\nRegistry Scanner v0.11.2Defect Fixes Fixed ROSA (Red Hat OpenShift Service on AWS) audience detection. Now we can also detect Azure Red Hat OpenShift and OSD (Red Hat OpenShift Dedicated) audiences. February 13, 2026Sysdig CLI Scanner v1.25.1Defect Fixes Fixed issue causing packages to not be detected in Alpine minimal/hardened images. February 10, 2026Sysdig CLI Scanner v1.25.0Enhancements Added flag --registry-insecure to support pulling images from HTTP registry. Added flag --registry-skiptlsverify to disable TLS certificate verification when pulling images from registries. Added flag --api-skiptlsverify to disable TLS certificate verification for interactions with the Sysdig backend. Added v2 format for csv output. This format includes non-package components, such as Application, OS, and Container Image. Deprecation Notice Deprecated --skiptlsverify flag. This flag generically applies to both registry and Sysdig backend interaction. To avoid security risks, migrate to the new flags --api-skiptlsverify and --registry-skiptlsverify. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-61726 CVE-2025-66506 CVE-2025-68121 CVE-2025-61728 CVE-2025-22772 CVE-2025-24137 Registry Scanner v0.11.1Enhancements Added ROSA (Red Hat OpenShift Service on AWS) audience detection for improved authentication support. Defect Fixes Fixed issue with track files for analyzer to ensure proper file tracking during scans. Security UpdatesUpdated dependencies to address the following high-severity vulnerabilities:\nCVE-2025-15467 CVE-2025-61726 CVE-2025-68121 CVE-2025-68973 CVE-2025-11187 CVE-2025-13601 CVE-2025-14104 CVE-2025-61728 CVE-2025-69419 CVE-2025-9086 CVE-2025-15468 CVE-2025-15469 CVE-2025-66199 CVE-2025-68160 CVE-2025-69418 CVE-2025-69420 CVE-2025-69421 CVE-2026-22795 CVE-2026-22796 CVE-2025-61730 KSPM Analyzer v1.47.1Security UpdatesUpdated dependencies to address the following high-severity vulnerabilities:\nCVE-2025-68121 Host Scanner v0.15.1Security UpdatesUpdated dependencies to address the following high-severity vulnerabilities:\nCVE-2025-68121 February 3, 2026Vulnerability Management Overview \u0026amp; Findings is Generally AvailableVulnerability Management Overview \u0026amp; Findings is now generally available. This release provides a supported workspace for VM program owners to monitor program health, analyze risk trends, and prioritize remediation.\nWhat\u0026rsquo;s New\nExpanded Program Dashboards: View risk trends and identify the primary sources of exposure, including namespaces, cloud accounts, images, and repositories. Enhanced Context: Gain deeper visibility across image, OS, application, and package layers, enabling more precise remediation and exception scoping. Better Prioritization: Findings are sorted by default to highlight the most critical, exploitable, and recently discovered vulnerabilities. Migration is automatic for existing users. For more information, see Vulnerability Overview\nJanuary 29, 2026KSPM Analyzer v1.47.1Defect Fixes Fixed an issue that could make kspm-analyzer log the error Failed to setup lease owner reference on OpenShift clusters. January 28, 2026Host Scanner v0.14.2Defect Fixes Fixed an issue which could cause the Host Scanner to perform unnecessary scans after restarts. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-61726 CVE-2025-61728 CVE-2025-61730 Sysdig Runtime Scanner v1.8.7Defect Fixes Fixed an issue which could cause the Runtime Scanner to leak unused temporary copies of the vulnerability database. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-61726 CVE-2025-61728 CVE-2025-61730 CVE-2025-66506 January 27, 2026KSPM Analyzer v1.47.0Enhancements Added support for Kubernetes versions 1.29 through 1.32 with new compliance audits. Improved Docker audits to skip evaluation when Mirantis Container Runtime (MCR) is detected. Improved startup performance, reducing initialization time and liveness probe response. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2024-5642 CVE-2025-13601 CVE-2025-4598 CVE-2025-6069 CVE-2025-6075 CVE-2025-61726 CVE-2025-61728 CVE-2025-61730 CVE-2025-68973 CVE-2025-8291 KSPM Collector v1.39.18Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-61728 CVE-2025-61726 CVE-2025-68121 CVE-2025-61731 CVE-2025-68119 January 24, 2026Agentless Scanning Support for LVM-Based and Multi-Partition Root VolumesSysdig Agentless Workload Scanning now supports LVM-based instances and hosts with multi-partition root volumes, reconstructing the full filesystem from /etc/fstab so all relevant mount points (for example, /, /usr, /var, /home) are included in analysis.\nFor more information on Agentless Host Scanning, see Scanning Guidelines.\nJanuary 20, 2026Expanded Compliance CoverageAdded new compliance posture policies across benchmarks, regulatory standards, security frameworks, and Sysdig benchmarks. For more details, see Posture Policies.\nJanuary 20, 2026EnhancementsGraph Inventory (New Experience)The Inventory introduces a new experience for exploring and analyzing resources across your environment. This update provides a unified Inventory \u0026gt; Resources view with improved navigation, filtering, and visibility into resource relationships, powered by Sysdig’s graph query engine.\nThe new experience includes:\nA hierarchical, searchable resource navigation Context-aware filtering and pagination Detailed resource insights via an interactive side panel This enhancement helps you discover, filter, and analyze resources more efficiently across connected environments. For more information, see Resources.\nJanuary 19, 2026Agentless Vulnerability Scanning for AWS Lambda ZIP FunctionsSysdig has expanded Agentless Workload Scanning to support AWS Lambda functions packaged as ZIP archives. Previously, scanning was limited to Lambda functions deployed as container images.\nThis enhancement allows you to:\nClose visibility gaps: Discover and scan serverless functions deployed as ZIP files alongside your containerized workloads. Automated SBOM extraction: Sysdig builds a detailed Software Bill of Materials (SBOM) by analyzing the AWS-managed base image, application code, and dependencies within the ZIP archive. Unified reporting: Findings from Lambda ZIP functions appear in Sysdig Secure alongside other assets, complete with severity scoring, fix availability, and policy evaluation. If you already use Sysdig Agentless Workload Scanning for AWS, Lambda ZIP functions will be included automatically once discovered.\nNew Response Actions are supported in AutomationsAutomations triggered from a Runtime Event extend the support to all the available actions:\nKill container Stop container Pause container Kill Process File acquire File quarantine Kill Pod Kubernetes Rollout restart Kubernetes Volume snapshot Kubernetes Get Logs Kubernetes Network isolate Read more in the Automations page for more details.\nJanuary 13, 2026Registry Scanner v0.11.0Enhanced Image Filtering CapabilitiesImproved image filtering functionality with expanded filter limits to support larger registries and more complex filtering requirements. This enhancement allows for more comprehensive control over which container images are included in vulnerability scanning workflows.\nFilter limit increases:\nconfig.filter.maxRepositoriesPerRegistry: Increased from 10,000 to 20,000 repositories per registry config.filter.maxTagsPerRepository: Increased from 50 to 100 tags per repository config.filter.maxAgeDays: Extended from 365 days (1 year) to 1,825 days (5 years) for image age filtering Refer to chart documentation for more details. Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-4598 January 12, 2026KSPM Collector v1.39.17Security UpdatesUpdated dependencies to address the following vulnerabilities:\nCVE-2025-61727 CVE-2025-61729 January 5, 2026Risk Spotlight (In-Use) for Non-Kubernetes ContainersSysdig has expanded Risk Spotlight (In-Use) prioritization to support non-Kubernetes container workloads. You can now identify which packages are actively loaded at runtime for bare containers (Docker and Podman) running on Linux hosts protected by the Sysdig Host Shield.\nThis enhancement allows you to reduce vulnerability noise and prioritize remediation efforts for your entire Linux ecosystem, including orchestrators such as Nomad or Mesos, by focusing on the vulnerabilities that are actually executable in production.\nFor more information, see Risk Spotlight.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-secure-release-notes/"},{"id":525,"title":"Severity and Status","content":"The categories are:\nHigh (red) Medium (orange) Low (yellow) Info (blue) The category Info refers to events, having little or no impact on operations, mostly containing informational messages.\nScripts that used the former severity values (0-7) will continue to work as expected, as the new categories are simplified groupings of those values.\nThis image outlines the former severity value breakdown:\nEvent StatusThere are two primary states for Alert Events: triggered, and resolved. Sysdig Monitor also allows for three purely visual available to improve filtering practices: acknowledged, unacknowledged, and silenced.\nEvent Status\nDescription\nTriggered\nThe circumstances that triggered the event remain in place, for example, the node remains down.\nResolved\nThe circumstances that triggered the event are no longer in place, for example, the metric value has returned to within a normal range.\nAcknowledged\nManual label to assist in filtering.\nWhen an alert is acknowledged, you will not be re-notified.\nThe acknowledged label is a purely visual marker. It does not reflect the current state (triggered/resolved) of the event.\nCustom events cannot be marked as acknowledged.\nUnacknowledged\nManual label to assist in filtering.\nAll events are marked as unacknowledged by default.\nSilenced\nManual label to assist in filtering.\nWhen an alert is silenced, you will not be re-notified for a period of time chosen when you create a silence. For more information, see Silence Alert Notifications.\nFor more information on filtering the Events feed, refer to Filter and Search Events.\nSee Secure Events to understand the Event severity levels for Sysdig Secure.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/severity-and-status/"},{"id":526,"title":"Silence Alert Notifications","content":"Silencing Rules do not affect the evaluation of alert rules. If an alert rule is triggered during an active Silencing Rule, the alert occurrence will still be recorded as an Event with an indication that it was silenced.\nScenariosSilencing rules can affect alert notifications and events in several ways depending on when the alert condition was met and resolved.\nAlert Rule Triggers and Resolves During Silencing Rule WindowIf the alert rule triggers and resolves during the Silencing Rule window:\nEvents Feed: A silenced alert occurrence appears in the event feed. Upon resolution, this alert occurrence is marked as resolved. Notification Channels: No alert notifications are forwarded to notification channels. Alert Rule Triggers Before Silencing RuleIf an alert rule is satisfied before the silencing rule, it will not be impacted by the silencing rule. You will still receive a notification when the alert resolves if the alert rule is configured to forward resolution notifications.\nEvents Feed: An alert occurrence appears in the event feed. Upon resolution, this alert occurrence is marked as resolved. Notification Channels: An alert notification is forwarded to the user-specified notification channels when the alert triggers. If configured, a resolution notification is also forwarded upon resolution. Alert Rule Triggers During Silencing Rule but Resolves LaterAn alert rule that is satisfied during a silencing rule window will trigger a notification at the end of the silencing rule window if the alert condition is still met.\nEvents Feed: A silenced alert occurrence appears in the event feed. After the silencing rule has expired, a new alert occurrence will appear in the event feed. This alert occurrence is responsible for forwarding alert notifications to the user-specified notification channels.\nNotification Channels: A notification appears when the alert rule is satisfied after the silencing rule expires. If configured, a resolution notification is also forwarded upon resolution.\nConfigure Silence RuleYou can enable Silencing Rules immediately or schedule them for the future. This provides the flexibility to plan ahead and avoid unnecessary disruptions.\nTo configure a Silencing Rule:\nLog in to Sysdig Monitor.\nFrom the left navigation bar, select Alerts \u0026gt; Silence.\nThe page shows the list of all the existing silences.\nClick Set a Silence.\nThe Silencing Rule modal appears.\nSpecify the following:\nName: Specify a name to identify the silence.\nSilence Criteria: Create a silence by alert, by scope, or by both. If you leave both fields empty, only the Team Scope is used as the silencing criterion. The entire infrastructure can be silenced if the Team Scope contains the entire infrastructure.\nBy Scope: Specify the entity, workload, or namespace you want to apply the scope as. For example, configuring a silence on the region=us-east-1 scope will silence all alerts in the us-east-1 region.\nBy Alert: Specify the alert that you want to mute. You can configure a silence for one or more alerts. Silencing the Datacenter Down alert instead of the region=us-east-1 scope allows other alerts within the scope to continue notifying.\nFor maximum specificity, combine both scope and alert.\nBegins: Select the day you want the silence to begin.\nDuration: Specify how long notifications should be muted.\nNotify: Select a notification channel that you want to notify when the Silence starts and ends. The available channels are Email and Slack.\nClick Save.\nConfigure Recurring Silence RuleYou can schedule notification silences that automatically activate at specific times or repeat at defined intervals (for example, weekdays 9 PM to 6 AM or weekends). During a silence period, alerts are still evaluated and logged, but notifications are suppressed until the next active window. Normal alerting resumes automatically once silence ends.\nTo configure a Recurring Silence Rule:\nLog in to Sysdig Monitor.\nFrom the left navigation bar, select Alerts \u0026gt; Recurring Silences.\nThe page displays a list of all the existing recurring silences.\nClick New Recurring Silence.\nThe Recurring Silence Rule modal appears.\nSpecify the following:\nName: Specify a name to identify the silence.\nSilence Criteria: Create a silence by alert, by scope, or by both. If you leave both fields empty, only the Team Scope is used as the silencing criterion. The entire infrastructure can be silenced if the Team Scope contains the entire infrastructure.\nBy Scope: Specify the entity, workload, or namespace to silence. For example, silencing the scope region=us-east-1 mutes all alerts in the us-east-1 region.\nBy Alert: Specify the alert that you want to mute. You can configure a silence for one or more alerts. For example, silencing the Datacenter Down alert allows other alerts within the same scope to continue notifying.\nFor the most specific control, combine both Scope and Alert criteria.\nScheduling: Define the recurring silence schedule.\nSchedule Begins: Select the date and time you want the recurring silence to begin.\nSchedule Ends: Specify on which day to end the recurring silence.\nEvery: Specify the recurrence interval (for example, daily or weekly).\nSilence Duration: Specify how long notifications should be muted.\nSummary: Add a human-readable description of the recurring silence schedule.\nNotify: Select a notification channel to alert when the silence starts and ends. The available channels are Email and Slack.\nClick Save. The recurring silence is created.\nSilence Alert Notifications from Alerts PageTo configure a Silence Rule for a specific alert, navigate to the Alerts page and select the alert you want to silence. You can then configure a Silence Rule specifically for that alert.\nSilence Alert Notifications from Events FeedTo configure a Silence Rule, access the Events feed. On the Events feed, find the Alert Event created when an alert is triggered. From the Alert Event, you can configure the Silence Rule to include both the scope and the alert that generated the event.\nAlert Events from Silenced AlertsWhen an alert is silenced, it will not send notifications to your configured notification channels, but it will still generate Alert Events. These events will include information indicating that the alert was triggered during an active silence.\nAfter the silencing window expires, the alert will trigger again if the alert rule continues to be satisfied.\nBy generating Alert Events, you can review the event history to see when the alert was silenced and when it resumed normal notifications. This helps provide visibility into what happened during the silence and can help with troubleshooting any issues that may arise.\nAlerts without a notification channel won’t be marked as silenced, and won’t have the crossed bell icon or option to silence events in the events feed.\nManage Silencing RulesYou can manage silences individually, or as a group, by using the checkboxes on the left side of the Silence UI and the customization bar. Select a group of silences and perform batch delete operations.\nSelect individual silences to perform tasks such as enabling, disabling, duplicating, and editing.\nFiltering capabilities:\nSearch - You can search for recurring silences by name.\nStatus - Filter silences by their current state: Active, Scheduled, or Completed.\nEditing capabilities:\nState - Enable or disable a silence using the State toggle. Active silences include both running silences and scheduled silences. From the actions menu on the right hand side menus, you can perform the following actions:\nTime Duration - Extend the silence period by 1 hour, 2 hours, 6 hours, 12 hours, or 24 hours.\nEdit - Modify the existing silencing rule.\nDuplicate - Create a copy of the existing silencing rule and open the dialog to make further edits.\nDelete - Permanently remove a silencing rule. A confirmation dialog appears before deletion. You cannot recover the silencing rules after they are deleted.\nYou can only extend or disable Active silences. If you configure a notification channel for the Silencing Rule, the channel receives notifications when the rule is extended or disabled.\nManage Recurring Silence RulesThe page offers an overview of existing recurring silence rules with the ability to manage them.\nFiltering capabilities:\nSearch - You can search the recurring silences by name, description, or tags.\nEnabled - Can be either True or False\nStatus - Can be Active, Scheduled, or Completed\nEditing capabilities:\nState - You can change the state of each individual recurring silence rule by toggling the status in the Enabled column. From the right hand side menus, you can perform the following actions:\nDuplicate - Copies the existing recurring silence rule and opens a dialog to perform further changes\nEdit - Allows you to edit the recurring silence rule\nDelete - Allows you to delete the recurring silence rule. After selecting this option a second confirmation dialog is shown to confirm the action. There is no way to recover the deleted recurring silence rules after they are deleted.\nDisable Silencing RuleTo disable silencing rules, use the API call PATCH /api/v1/silencingRules/disable to provide a list of rule IDs The API call executes necessary operations to resolve associated alert occurrences with the alert rule and disable it immediately. Example:\ncurl --location --request PATCH \u0026#39;http://{sysdig_url}/api/v1/silencingRules/disable\u0026#39; \\ --header \u0026#39;Content-Type: application/json\u0026#39; \\ --data \u0026#39;{ \u0026#34;silencingRules\u0026#34;: { \u0026#34;ids\u0026#34;: [9] } }\u0026#39; Pause Alerts for DowntimeAdmin users can temporarily pause all alert rule evaluations across every Sysdig team. This stops alert events from triggering and suspends notifications across all configured notification channels.\nLog in to Sysdig Monitor as an Admin.\nSelect Settings \u0026gt; Notification Channels.\nToggle Pause Alert Rule Evaluation on. A confirmation dialog will appear.\nOptional: Set a Duration to automatically resume alert evaluation after a specified time.\nOptional: To inform others that alerts are paused, check Notify via email or Slack, and choose the notification channel to notify from the drop-down menu.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/silence-alert-notifications/"},{"id":527,"title":"Sysdig Admission Controller","content":" This integration is enabled by default.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 47 metrics.\nList of Alerts Alert Description Format [Sysdig Admission Controller] No K8s Audit Events Received The Admission Controller is not receiving Kubernetes Audit events Prometheus [Sysdig Admission Controller] K8s Audit Events Throttling Kubernetes Audit events is being throttled Prometheus [Sysdig Admission Controller] Scanning Events Throttling Scanning events is being throttled Prometheus [Sysdig Admission Controller] Inline Scanning Throttling The inline scanning queue is not empty for a long time Prometheus [Sysdig Admission Controller] High Error Rate In Scan Status From Backend High Error Rate In Scan Status From Backend Prometheus [Sysdig Admission Controller] High Error Rate In Scan Report From Backend High Error Rate In Scan Status From Backend Prometheus [Sysdig Admission Controller] High Error Rate In Image Scan High Error Rate In Image Scan Prometheus List of DashboardsSysdig Admission ControllerThe dashboard provides information on the Sysdig Admission Controller integration. List of Metrics Metric name go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads k8s_audit_ac_alerts_total k8s_audit_ac_events_processed_total k8s_audit_ac_events_received_total process_cpu_seconds_total process_max_fds process_open_fds queue_length scan_report_cache_hits scan_report_cache_misses scan_status_cache_hits scan_status_cache_misses scanner_scan_errors scanner_scan_report_error_from_backend_count scanner_scan_report_retrieved_from_backend_count scanner_scan_requests_already_queued scanner_scan_requests_error scanner_scan_requests_queued scanner_scan_status_error_from_backend_count scanner_scan_status_retrieved_from_backend_count scanner_scan_success scanning_ac_admission_responses_total scanning_ac_containers_processed_total scanning_ac_http_scanning_handler_requests_total PrerequisitesInstall Sysdig Admission ControllerInstall Sysdig Admission Controller following the official documentation and make sure to provide a valid Sysdig Secure valid ULR and API token.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: sysdig-admission-controller-default tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: keep source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape] regex: true - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_pod_container_name - __meta_kubernetes_pod_annotation_prometheus_io_port regex: admission-controller;(8080|5000) - action: replace source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port] regex: ([^:]+)(?::\\d+)?;(\\d+) replacement: $1:$2 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scheme] target_label: __scheme__ regex: (https?) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/sysdig-admission-controller/"},{"id":528,"title":"Sysdig Cost Advisor","content":" This integration is disabled by default. Please refer to Enable and Disable Integrations to enable it in your account.\nThis integration has 30 metrics.\nList of Alerts Alert Description Format [Sysdig Cost Advisor] Workload daily cost exceeds 1000$ There has been a high increase in the daily costs of a workload. Prometheus [Sysdig Cost Advisor] Workloads daily costs exceeds 20% of cluster daily costs Workload costs are more than 20% of cluster cost Prometheus [Sysdig Cost Advisor] Workload daily cost, owned by {teamName},exceeds 1000$ ( There has been a high increase in the daily costs of a workload owned by {teamName}. (Replace the kube_workload_label_team label in the query with your workload label) Prometheus List of DashboardsCluster Cost OverviewThe dashboard provides information about the cluster costs.\nWorkload Cost OverviewThe dashboard provides information about the workload costs.\nCluster Metrics ShowcaseThis dashboard serves as a comprehensive showcase of all available cost-related metrics associated with your cluster and nodes. It is designed to help you explore and discover the various metrics that Sysdig Monitor offers to track and manage resource usage and costs efficiently.\nWorkload Cost Metrics ShowcaseThis dashboard serves as a comprehensive showcase of all available cost-related metrics associated with your workloads. It is designed to help you explore and discover the various metrics that Sysdig Monitor offers to track and manage resource usage and costs efficiently.\nList of Metrics Metric name kube_node_info kube_node_status_capacity_cpu_cores kube_node_status_capacity_memory_bytes kube_persistentvolume_capacity_bytes kube_persistentvolumeclaim_resource_requests_storage_bytes kube_pod_container_resource_requests kubelet_volume_stats_used_bytes sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes sysdig_costs_cloud_account_private_billing_info sysdig_costs_cluster_details_info sysdig_costs_cluster_management_fees_cost_total sysdig_costs_node_cost_total sysdig_costs_node_cpu_capacity_cost_total sysdig_costs_node_memory_capacity_cost_total sysdig_costs_pv_cost_total sysdig_costs_service_load_balancer_cost_total sysdig_costs_workload_cpu_allocated_cores_total sysdig_costs_workload_cpu_allocated_cost_total sysdig_costs_workload_cpu_used_cores_total sysdig_costs_workload_cpu_used_cost_total sysdig_costs_workload_memory_allocated_bytes_total sysdig_costs_workload_memory_allocated_cost_total sysdig_costs_workload_memory_used_bytes_total sysdig_costs_workload_memory_used_cost_total sysdig_costs_workload_storage_allocated_bytes_total sysdig_costs_workload_storage_allocated_cost_total sysdig_costs_workload_storage_capacity_bytes_total sysdig_costs_workload_storage_capacity_cost_total sysdig_costs_workload_storage_used_cost_total PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/sysdig-cost-advisor/"},{"id":529,"title":"Sysdig Info Metrics","content":"For example, querying sysdig_host_info in PromQL Query Explorer will provide all labels associated with the host, such as:\nagent_id agent_tag_cluster host_hostname domain host host_domain host_mac instance_id Although info metrics are available, all the metrics that are ingested by Sysdig agents are automatically enriched with the metadata and you don\u0026rsquo;t need to do PromQL joins. For more information, see Run PromQL Queries Faster with Extended Label Set.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/sysdig-info-metrics/"},{"id":530,"title":"Sysdig Monitor","content":" This integration is enabled by default.\nThis integration has 31 metrics.\nList of Alerts Alert Description Format [Sysdig Monitor] High increase in Timeseries compared to last week There has been a high increase in Timeseries ingested by the Sysdig Agent compared to last week. Prometheus [Sysdig Monitor] Timeseries at least doubled compared to last week The number of Timeseries ingested by the Sysdig Agent has at least doubled compared to last week. Prometheus [Sysdig Monitor] Timeseries 10% greater than the current entitlement The number of Timeseries ingested by the Sysdig Agent is 10% greater than the current entitlement. Prometheus [Sysdig Monitor] Host Agent usage over 90% of entitlement Total number (reserved and ondemand) of connected host agents is over 90% of entitlement. Prometheus [Sysdig Monitor] Agent Exceeding \u0026gt; 90% of limit of Prometheus metrics on host The number of Prometheus metrics ingested by the Sysdig Agent is over 90% of the limit. Prometheus List of DashboardsSysdig Agent Health \u0026amp; StatusThe dashboard provides information on the Sysdig Agent health and its status. Time Series UsageThe dashboard provides information on the number of timeseries scraped. New Time Series UsageThe dashboard provides information on the number of timeseries scraped. Agents and Jobs Time SeriesThe dashboard provides information on the Sysdig Agent health and its status. List of Metrics Metric name agent.mode agent.version scrape_samples_post_metric_relabeling statsd_dragent_analyzer_fl_ms statsd_dragent_analyzer_n_drops statsd_dragent_analyzer_n_drops_buffer statsd_dragent_analyzer_n_evts statsd_dragent_analyzer_sr statsd_dragent_metricCount_limit_appCheck statsd_dragent_metricCount_limit_appcheck statsd_dragent_metricCount_limit_jmx statsd_dragent_metricCount_limit_prometheus statsd_dragent_metricCount_limit_statsd statsd_host_uname sysdig_agent_info sysdig_agent_timeseries_count_appcheck sysdig_agent_timeseries_count_jmx sysdig_agent_timeseries_count_prometheus sysdig_agent_timeseries_count_statsd sysdig_host_container_count sysdig_host_count sysdig_host_timeseries_count_appcheck sysdig_host_timeseries_count_jmx sysdig_host_timeseries_count_prometheus sysdig_host_timeseries_count_statsd sysdig_license_agent_limit sysdig_ts_entitlement sysdig_ts_hourly_overage sysdig_ts_hourly_usage sysdig_ts_usage sysdig_ts_usage_10s PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/sysdig-monitor/"},{"id":531,"title":"Terraform Provider","content":"Sysdig provides a Terraform Provider to expose and use some of the most common Sysdig API functions for\nSysdig Platform Sysdig Secure Sysdig Monitor Learn more about using the provider in the official Terraform Registry - Sysdig Provider repository.\nYou can also provide feedback or create pull requests in the Sysdig Terraform Provider Source GitHub Repository\nUsing TerraformTerraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing and popular service providers as well as custom in-house solutions.\nConfiguration files describe to Terraform the components needed to run a single application or your entire data center. Terraform generates an execution plan describing what it will do to reach the desired state, and then executes it to build the described infrastructure or configuration.\nAs the configuration changes, Terraform is able to determine what changed and create incremental execution plans which can be applied.\nTerraform Provider for SysdigThe Terraform Provider for Sysdig allows you to manage your configuration in Sysdig Secure and Sysdig Monitor as code, allowing you to synchronize your declarative configuration with the configuration at the Platform.\nYou can instrument several use cases like:\nBackup/restore Disaster recovery Configuration version management InstallationFollow Terraform Registry - Sysdig Provider official instructions.\nCreate Resources with TerraformThis is an example to create a pair of rules able to detect SSH connections and shells spawned in containers.\nDefine a couple of rules in the rules.tf file. One rule to detect inbound and outbound connections made to the port 22, and the other to detect a shell process being spawned.\nresource \u0026#34;sysdig_secure_rule_network\u0026#34; \u0026#34;disallowed_ssh_connection\u0026#34; { name = \u0026#34;Disallowed SSH Connection detected\u0026#34; description = \u0026#34;Detect any new ssh connection to a host\u0026#34; tags = [\u0026#34;network\u0026#34;] block_inbound = true block_outbound = true tcp { matching = true ports = [22] } } resource \u0026#34;sysdig_secure_rule_process\u0026#34; \u0026#34;terminal_shell\u0026#34; { name = \u0026#34;Terminal shell detected\u0026#34; description = \u0026#34;A shell was used as the entrypoint/exec point\u0026#34; tags = [\u0026#34;shell\u0026#34;] processes = [\u0026#34;ash\u0026#34;, \u0026#34;bash\u0026#34;, \u0026#34;csh\u0026#34;, \u0026#34;ksh\u0026#34;, \u0026#34;sh\u0026#34;, \u0026#34;tcsh\u0026#34;, \u0026#34;zsh\u0026#34;, \u0026#34;dash\u0026#34;] } For more information about the configuration blocks, see Terraform Syntax.\nCreate a policy in a file called policy.tf to define how these rules are applied. The policy will stop the affected container and trigger a capture for further troubleshooting.\nresource \u0026#34;sysdig_secure_policy\u0026#34; \u0026#34;terminal_shell_or_ssh_in_container\u0026#34; { name = \u0026#34;Terminal shell or SSH detected in container\u0026#34; description = \u0026#34;Detects a terminal shell or a ssh spawned in a container\u0026#34; enabled = true severity = 0 // HIGH scope = \u0026#34;container.id != \\\u0026#34;\\\u0026#34;\u0026#34; rule_names = [sysdig_secure_rule_network.disallowed_ssh_connection.name, sysdig_secure_rule_process.terminal_shell.name] actions { container = \u0026#34;stop\u0026#34; capture { seconds_before_event = 5 seconds_after_event = 10 } } } With the given scope, the policy will only be applied to processes being executed inside containers:\nscope = \u0026#34;container.id != \\\u0026#34;\\\u0026#34;\u0026#34; Run terraform apply.\nUsing terraform apply the resources are applied in the backend:\nTerraform reports that three resources will be created, which matches what you defined in rules.tf and policy.tf.\nAfter applying the plan, ensure that Terraform reports about the resource creation.\nThe policy uses the rules created before, therefore, it’s the last one being created.\nWhen the resources have been created, they appear as follows in the Sysdig Secure UI.\nHowever, if this policy triggers no alert notification unless you create notification channels.\nCreate two notification channels, one for the email and another one for slack in a file called notification.tf.\nresource \u0026#34;sysdig_secure_notification_channel_email\u0026#34; \u0026#34;devops-email\u0026#34; { name = \u0026#34;DevOps e-mail\u0026#34; enabled = true recipients = \u0026#34;devops@example.com\u0026#34; notify_when_ok = false notify_when_resolved = false } resource \u0026#34;sysdig_secure_notification_channel_slack\u0026#34; \u0026#34;devops-slack\u0026#34; { name = \u0026#34;DevOps Slack\u0026#34; enabled = true url = \u0026#34;https://hooks.slack.com/services/xyz\u0026#34; channel = \u0026#34;#devops\u0026#34; notify_when_ok = false notify_when_resolved = false } They will alert when the policy is triggered.\nBind them to the policy by modifying the policy.tf file. Note the notification_channels property:\nresource \u0026#34;sysdig_secure_policy\u0026#34; \u0026#34;terminal_shell_or_ssh_in_container\u0026#34; { name = \u0026#34;Terminal shell or SSH detected in container\u0026#34; description = \u0026#34;Detects a terminal shell or a ssh spawned in a container\u0026#34; enabled = true severity = 0 // HIGH scope = \u0026#34;container.id != \\\u0026#34;\\\u0026#34;\u0026#34; rule_names = [sysdig_secure_rule_network.disallowed_ssh_connection.name, sysdig_secure_rule_process.terminal_shell.name] actions { container = \u0026#34;stop\u0026#34; capture { seconds_before_event = 5 seconds_after_event = 10 } } notification_channels = [sysdig_secure_notification_channel_email.devops-email.id, sysdig_secure_notification_channel_slack.devops-slack.id] } Perform terraform apply.\nTerraform will create two new resources and modify the existing policy\nChoose yes.\nTerraform will create the notification channels and bind them to the policy, ensuring that the state in Monitor and Secure matches our state defined in the code.\nThis is how the resources appear on the Sysdig Secure UI:\nNow, if you try to update it manually, by re-applying the policies, Terraform will restore the desired status from the .tf manifests.\nCreate Custom Controls with Terraform Define the control in the controls.tf file. Given below is an example to create a custom control to detect S3 Buckets without versioning enabled (custom controls for cloud):\nresource \u0026#34;sysdig_secure_posture_control\u0026#34; \u0026#34;s3_bucket_without_versioning\u0026#34; { name = \u0026#34;S3 Bucket without versioning\u0026#34; description = \u0026#34;Ensure that S3 object versioning is enabled for your Amazon S3 buckets in order to preserve and recover overwritten and deleted S3 objects as an extra layer of data protection and/or data retention.\u0026#34; resource_kind = \u0026#34;AWS_S3_BUCKET\u0026#34; severity = \u0026#34;High\u0026#34; rego = \u0026lt;\u0026lt;-EOF package sysdig import future.keywords.if import future.keywords.in default risky := false risky if { count(input.Versioning) == 0 } risky if { some version in input.Versioning lower(version.Status) != \u0026#34;enabled\u0026#34; } EOF remediation_details = \u0026lt;\u0026lt;-EOF ## Remediation Impact Versioning-enabled Amazon S3 buckets will allow you to preserve, retrieve, and restore every version of an S3 object. S3 versioning can be used for data protection and retention scenarios such as recovering objects that have been accidentally/intentionally deleted or overwritten by AWS users or applications and archiving previous versions of objects to Amazon S3 Glacier for long-term low-cost storage. With S3 versioning, you can easily recover from both unintended user actions and application failures. ## Remediate Using Command Line 1. Run put-bucket-versioning command (OSX/Linux/UNIX) using the name of the Amazon S3 bucket that you want to reconfigure as the identifier parameter, to enable S3 object versioning for the selected bucket. If the request is successful, the put-bucket-versioning command should not return an output: ``` aws s3api put-bucket-versioning --bucket cc-prod-web-data --versioning-configuration Status=Enabled ``` 2. Repeat step no. 1 to enable S3 object versioning for other Amazon S3 buckets available within your AWS cloud account. EOF } Given below is an example to create a custom control to detect images comming from an unapproved registry (custom controls for Kubernetes):\nresource \u0026#34;sysdig_secure_posture_control\u0026#34; \u0026#34;deployment-image-must-come-from-correct-registry\u0026#34; { name = \u0026#34;Deployment\u0026#39;s Image must come from Correct Registry\u0026#34; description = \u0026#34;KSPM - Validate if Image is coming from Correct Registry\u0026#34; resource_kind = \u0026#34;DEPLOYMENT\u0026#34; severity = \u0026#34;Medium\u0026#34; rego = \u0026lt;\u0026lt;-EOF package sysdig import future.keywords.if import future.keywords.in default risky := false risky if { input.kind == \u0026#34;Deployment\u0026#34; some container in input.spec.template.spec.containers not startswith(container.image, \u0026#34;quay.io/sysdig\u0026#34;) } EOF remediation_details = \u0026lt;\u0026lt;-EOF **THIS IS MY Custom REMEDIATION** EOF } Perform terraform apply. The new control will appear in the Control Library and is ready to be used in custom policies.\nLearn MoreCheck all the available resources and datasources for the Terraform Provider for Sysdig in the official Terraform Registry.\n","url":"https://docs.sysdig.com/en/developer-tools/terraform-provider/"},{"id":532,"title":"Troubleshoot AWS Account Connections","content":" AWS credentials are invalid or role was configured incorrectly. Creating or updating stack failed. Metric stream stopped. Sysdig could not process the requests due to having a wrong token. Sysdig displays an error with potential causes when you hover on the status.\nTo troubleshoot:\nEnsure that your access key and secret access key are correct. The edit functionality is unavailable so you will have to delete the entry and create a new one. Log in to the AWS console. Check the status of the stack and troubleshoot it in on the AWS console. Find the metric stream created as part of stack and start it. Ensure that Sysdig services are up and running by visiting Sysdig Infrastructure Status. Contact Sysdig Support to check the logs on Sysdig side. See AWS Documentation. ","url":"https://docs.sysdig.com/en/sysdig-monitor/cloud-accounts/connect-aws-account/troubleshoot-aws-account-connections/"},{"id":533,"title":"Dashboards Visualization Types","content":" To access different visualization types, click the current visualization type when editing a metric query.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/visualisation-types/"},{"id":534,"title":"VM Reporting","content":" Reports created within a team are only visible to that team. They can’t be accessed by members of other teams, neither through the UI nor via API token downloads.\nReporting in Vulnerability Management allows you to:\nCreate a report definition. Schedule its frequency. Define notification channels in which to receive the reports (email, Slack, or webhook). Preview how the data will appear (optional). Download the resulting reports in CSV, JSON, or NDJSON. Compression options: ZIP and GZ Optionally, generate a manual (unscheduled) report. Regardless of the schedule, reports always include data for the following timeframes:\nRuntime: Last 24 hours Host: Last 24 hours Container: Last 24 hours Registry: Last 7 days (Technically 7–14 days. Records the data starting from Monday of the previous week) Pipeline: Last 7 days (Technically 7–14 days. Records the data starting from Monday of the previous week) You can schedule reports according to this timeline to avoid gaps in the data. Past reports are stored for two weeks. For example, if you schedule a weekly report, the list of available reports will only contain the two most recent records.\nCreate a Report DefinitionAccess Report Definition Log in to Sysdig Secure with Advanced User or higher permissions.\nSelect Reporting.\nThe Reporting page appears.\nIf you have previously created report definitions, you can click one to see the details.\nClick New Report.\nThe New Report page is displayed.\nSpecify the name and description to identify the report.\nChoose the entity you want and follow the appropriate instructions given below:\nRuntime Workloads Runtime Hosts Runtime Containers Image Registry Image Pipeline Runtime WorkloadsPrerequisite: These reports are available whenever you have the current Vulnerability Management module installed (not Legacy Scanning).\nAccess the Report Definition and specify the following:\nBasic Information: Define the basic information for the report:\nName: A unique name for the report Description: A concise summary providing insight into the purpose of this report. Export file format: CSV, JSON, or Newline Delimited JSON (ndsjon) Select Definitions:\nEntity: Runtime Workloads\nScope: Entire infrastructure or subset from the drop-down menu\nConditions: (Optional) Click Add condition to choose conditions from the drop-down to filter reported items.\nThe available conditions include:\nImage Name (only for this Entity)\nOS Name\nIn Use (only for this Entity)\nPackage Name\nPackage Path\nPackage Type\nPackage Version\nVulnerability ID\nCVSS Score\nCVSS Vector\nVulnerability Publish Date\nExploitable\nFix Available\nRisk Accepted\nSeverity\nEPSS Score\nNVD Score\nNVD Severity\nRedHat Score\nRedHat Severity\nVulnerability Fix Date\nExample 1: You want a report of all vulnerabilities with a Severity \u0026gt;= High, and for which a Fix is Available. Example 2: You want a report of all vulnerabilities that are In Use with Accepted Risks.\nSchedule and Notifications: Define the Frequency and time of day the report should be run.\nThe schedule determines when the report data collection begins. As soon as evaluation is complete, you will receive a notification in the configured notification channels.\nUse the toggle to enable/disable Notifications. Slack, email or webhook notification channels you have configured will appear in the dropdown.\nSince reports are typically large, the actual data is not sent to the notification channel; you receive a link to download it. You must be a valid Sysdig Secure user (Advanced User+) to access the link.\nPreview: Click Preview to apply the configuration you\u0026rsquo;ve chosen and pull up on the center bar of the panel to see sample results.\nClick Save.\nRuntime HostsPrerequisite: To get these reports, you must have Vulnerability Host scanning installed.\nAccess the Report Definition and complete everything the same as for Runtime Workloads, with the following exceptions:\nBasic Information: Define the report basic info:\nName: A unique name for the report Description: A concise summary providing insight into the purpose of this report Export file format: .csv, .json, or .ndjson Compression: GZ or ZIP Select Definitions:\nEntity: Runtime Hosts\nScope: Entire infrastructure or subset from the drop-down menu\nConditions: (Optional) Click Add conditions to choose from the dropdown how you want to filter the items reported on.\nThe available Conditions include:\nArchitecture * (only for this entity)\nOS Name\nPackage Name\nPackage Path\nPackage Type\nPackage Version\nVulnerability ID\nCVSS Score\nCVSS Vector\nVulnerability Publish Date\nExploitable\nFix Available\nRisk Accepted\nSeverity\nEPSS Score\nNVD Score\nNVD Severity\nRedHat Score\nRedHat Severity\nVulnerability Fix Date\nRuntime ContainersPrerequisite: Ensure that you have the current Vulnerability Management module installed (not Legacy Scanning) to get these reports.\nAccess the Report Definition and specify the following:\nBasic Information: Enter the basic information:\nName: A unique name for the report Description: A concise summary providing insight into the purpose of this report Export file format: CSV, JSON, or Newline Delimited JSON (ndsjon) Compression: GZ or ZIP Select Definitions:\nEntity: Runtime Containers\nScope: Entire infrastructure or subset from the drop-down menu, which includes:\ncloudProvider.account.id cloudProvider.region container.id container.name container.runtime.type host.hostName Conditions: (Optional) Click Add conditions to choose from the dropdown how you want to filter the items reported on.\nThe available Conditions include:\nImage Name\nOS Name\nPackage Name\nPackage Path\nPackage Type\nPackage Version\nVulnerability ID\nCVSS Score\nCVSS Vector\nVulnerability Publish Date\nExploitable\nFix Available\nRisk Accepted\nEPSS Score\nNVD Score\nNVD Severity\nRedHat Score\nRedHat Severity\nSeverity\nVulnerability Fix Date\nSchedule and Notifications: Define the Frequency and time of day the report should be run.\nUse the toggle to enable/disable Notifications.\nSlack, email or webhook notification channels you have configured will appear in the dropdown.\nSince reports are typically large, the actual data is not sent to the notification channel; instead you receive a link to download it. To access the link, you must be a valid Sysdig Secure user with at least Advanced User permission.\nPreview: Click Preview to apply the configuration you\u0026rsquo;ve chosen and pull up on the center bar of the panel to see the sample results.\nClick Save.\nContainer Image RegistriesNOTE: To get these reports, you must have Registry scanning installed.\nAccess the Report Definition and complete everything the same as for Runtime Workloads, with the following exceptions:\nBasic Information: Define the report basic info:\nName: A unique name for the report Description: A concise summary providing insight into the purpose of this report. Export file format: .csv, .json, or .ndjson Compression: GZ or ZIP Select Definitions:\nEntity: Image Registry\nScope: Entire infrastructure or subset from the drop-down menu\nConditions: (Optional) Click Add conditions to choose from the dropdown how you want to filter the items reported on.\nThe available Conditions include:\nImage Name\nOS Name\nPackage Name\nPackage Path\nPackage Type\nPackage Version\nVulnerability ID\nCVSS Score\nCVSS Vector\nVuln Publish Date\nExploitable\nFix Available\nSeverity\nEPSS Score\nNVD Score\nNVD Severity\nRedHat Score\nRedHat Severity\nVuln Fix Date\nContainer Images do not have runtime-specific scopes and metadata, like Kubernetes cluster name. Instead, they have registry-specific metadata and filters, such as registry.vendor. See the following table:\nAttribute Possible Values Description cloudProvider.name aws, azure, ibm a shortname of the Cloud Provider, if applies cloudProvider.region One of the AWS cloud provider regions For AWS only, the region in where the cloud registry is located cloudProvider.account.id AWS account ID, for example, 012345678901 For AWS only, the accountID in where the cloud registry is located registry.vendor Installation configuration config.registryType value Specific value given in the installation to identify the vendor specific scanner type registry.name Example: given example.com/k8s-project/metrics-server:v0.6.1 it would be example.com Registry hostname, up till first / registry.image.repo Example: given example.com/k8s-project/metrics-server:v0.6.1 it would be /k8s-project/metrics-server Image repository including possible intermediate paths, from first / up till the : SchedulingThe Frequency with which reporting is configured in registry is closely linked to the refresh cycle, defined during installation. The report frequency must be set up to be coherent with the cronjob.schedule cycle. For example, the default value ( \u0026quot;0 6 * * 6\u0026quot; as every Saturday morning) is set to be performed weekly, which means daily reports would not make sense, since all results would be the same within those dates.\nLimitations Registry Scanner does not handle Vulnerability Policies. cloudProvider.* attributes will only be populated for AWS cloud provider. Image PipelineNOTE: To get these reports, you must have Pipeline scanning version 1.4.0 or above installed.\nAccess the Report Definition and complete everything the same as for Runtime Workloads, with the following exceptions:\nBasic Information: Define the report basic info:\nName: A unique name for the report Description: A concise summary providing insight into the purpose of this report Export file format: .csv, .json, or .ndjson Compression: GZ or ZIP Select Definitions:\nEntity: Image Pipeline.\nScope: Entire infrastructure or subset from the drop-down menu.\nConditions: (Optional) Click Add conditions to choose from the dropdown how you want to filter the items reported on. The available Conditions include:\nImage Name\nOS Name\nPackage Name\nPackage Path\nPackage Type\nPackage Version\nVulnerability ID\nCVSS Score\nCVSS Vector\nVulnerability Publish Date\nExploitable\nFix Available\nRisk Accepted\nSeverity\nEPSS Score\nNVD Score\nNVD Severity\nRedHat Score\nRedHat Severity\nVuln Fix Date\nContainer Images do not have runtime-specific scopes and metadata, like Kubernetes cluster name. Instead, they have registry-specific metadata and filters, such as registry.vendor. See the following table:\nAttribute Possible Values Description registry.name ex.: given example.com/k8s-project/metrics-server:v0.6.1 it would be example.com Registry hostname, up till first / registry.image.repo ex.: given example.com/k8s-project/metrics-server:v0.6.1 it would be /k8s-project/metrics-server Image repository including possible intermediate paths, from first / up till the : Manage ReportsView and Edit Report Definition Select an entry in the Reporting list to see the detail panel.\nClick Edit to change the report definition parameters. You can also access this panel from the three-dot menu.\nMake your edits, click Preview to see the Data Preview, and then Save.\nDownload Reports From the Reporting main page, download links for reports appear in the Download column.\nTo see older reports, select an entry in the Reports list to open the detail panel and select from the report download list.\nThe report will be downloaded in the format you defined.\nThe file is compressed in ZIP (.zip) or GZ (.gz) format.\nDouble-click the report to extract and view. You might require additional software to decompress the file.\nGenerate Report Manually Select an entry in the Reporting list to see the detail panel. Click Generate Now. A Scheduled entry will appear under Latest reports. In approximately 15 minutes, it will change to Completed and you can download the manually generated report.\nDuplicate a Report Definition Choose the three-dot menu for a scheduled report.\nClick Duplicate.\nReport Definition RetentionThe scheduled and manually created reports are retained for 14 days.\nDelete a Report DefinitionBe sure to download any needed reports before deleting the definition.\nChoose the three-dot menu for a scheduled report.\nClick Delete, click Yes when prompted.\nThe report definition and all associated reports are deleted.\n","url":"https://docs.sysdig.com/en/sysdig-secure/vm-reporting/"},{"id":535,"title":"Add Custom CA Certificates","content":"Upload Custom CA Certificates at Deployment TimeYou can upload custom CA certificates to the Workload Agent during deployment by using the SYSDIG_EXTRA_FILES environment variable.\nSYSDIG_EXTRA_FILES accepts JSON values in the following structure:\n{ \u0026#34;files\u0026#34;: [ { \u0026#34;path\u0026#34;: \u0026#34;path/to/file\u0026#34;, \u0026#34;encoding\u0026#34;: \u0026#34;base64\u0026#34;, \u0026#34;data\u0026#34;: \u0026#34;base64-encoded-data\u0026#34; } ] } The JSON file contains an array of files that need to be uploaded to the Workload Agent.\nEach file contains the following fields:\npath: the path where the file will be stored in the Workload Agent container. encoding: the encoding of the file. Currently, only base64 is supported. data: the base64-encoded data of the file. Example: Upload a CA CertificateThe following example shows how to upload a custom CA Certificate custom_ca.crt to the Workload Agent. The file you are uploading will be base64 encoded and stored in the /etc/ssl directory.\nEncode Your Custom FileUse any methods to encode the files in base64. For example, in a Linux shell, run:\n$ base64 custom_ca.crt TXkgY3VzdG9tIENBIENlcnRpZmljYXRlCg== The base64 output value shown here is an example. The actual value will be longer.\nSet the SYSDIG_EXTRA_FILES Environment VariableNow that you have the base64-encoded value, add the SYSDIG_EXTRA_FILES environment variable to the container running the agent, which gets the following JSON:\nSYSDIG_EXTRA_FILES=\u0026#39;{\u0026#34;files\u0026#34;: [{\u0026#34;path\u0026#34;: \u0026#34;/etc/ssl/custom_ca.crt\u0026#34;, \u0026#34;encoding\u0026#34;: \u0026#34;base64\u0026#34;, \u0026#34;data\u0026#34;: \u0026#34;TXkgY3VzdG9tIENBIENlcnRpZmljYXRlCg==\u0026#34;}]}\u0026#39; Configure the Connection to the HTTP Proxyset the SYSDIG_EXTRA_CONF environment variable to configure the agent to use the custom CA certificates for HTTP Proxy connections.\n","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-custom-ca-certificates/"},{"id":536,"title":"Agent Logs Configuration","content":"Set Global Log LevelThe environment variable SYSDIG_LOGGING sets the global log level.\nIt defaults to info.\nAvailable options are: silent | fatal | critical | error | warning | info | debug | trace.\nSet Log Level per ComponentYou can also gain fine-grained control over the log level of specific components, as described in Manage Agent Log Levels, using the SYSDIG_EXTRA_CONF environment variable.\nThe following example shows how to configure the global log level to info and set the log level of the security_mgr component to warning.\nSYSDIG_EXTRA_CONF=\u0026#34;log: { console_priority: info, console_priority_by_component: [ \u0026#39;security_mgr: warning\u0026#39; ] }\u0026#34; Note that newlines and spaces are important when passing this configuration as YAML to the Workload Agent.\n","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-configure-logs/"},{"id":537,"title":"Alert Inhibition","content":" Alert Inhibition rules can only be configured via the API and are available only for Prometheus Alerts.\nGlossary Alert Type: A category of alert rules, each with distinct evaluation logic, such as Prometheus Alert, Group Outlier Alert, Threshold Alert, or Event Alert.\nAlert Rule: The specific configuration of an alert type, which is evaluated by Sysdig. For example, Instance Down: Up == 0.\nAlert Occurrence: The event when an alert rule’s conditions are met, triggering the alert rule. For example, Up{job=\u0026quot;nginx\u0026quot;} == 0.\nAlert Notification: The payload sent from a triggered alert rule to a configured notification channel, such as JIRA, Slack, or Webhooks.\nUse Cases for Alert InhibitionAlert Inhibition helps reduce alert fatigue by ensuring that only the most relevant and actionable alert notifications are sent out. For example, if a data center has gone down, it is redundant to receive notifications about individual servers being down. Similarly, if a network interface has failed, alerts for high network latency can distract from the underlying root cause. Alert Inhibition Rules allow you to suppress these secondary notifications when an upstream issue has already been identified.\nAlert Inhibition lets you prioritize high severity alerts over low severity ones. If a \u0026ldquo;database full\u0026rdquo; alert is active, you can suppress \u0026ldquo;database almost full\u0026rdquo; alerts.\nAlert Inhibition allow systems to stabilize to prevent false positives. If a \u0026ldquo;deployment in progress\u0026rdquo; alert is active, suppress \u0026ldquo;service endpoint unreachable\u0026rdquo; alerts as they may resolve once the deployment completes.\nUnlike Alert Silencing which has specific start and end times, Alert Inhibition rules are always active and evaluate whenever an alert rule is triggered. Alert Inhibition rules can also be more targeted than Silence Rules, taking into account the current context of the system to selectively suppress less relevant alerts notifications.\nConfigure Alert Inhibition RulesInhibition Rules determine whether an alert occurrence identified by the targetMatcher should be suppressed by another alert occurrence identified by the sourceMatcher. If both triggering alert occurrences match on a label specified by the equal parameter, the alert notification for the targetMatcher is suppressed and not sent out.\nIn order to precisely suppress the correct alert notifications, the equal field must specify labels that are shared between the sourceMatcher and targetMatcher. We would not want an offline database in {region=us-east-1, component=cache} to suppress a notification in {region=us-east-2, component=cache}. We also wouldn\u0026rsquo;t want an offline database in {region=us-east-1, component=cache} to suppress a notification in {region=us-east-1, component=API} if the API layer and the cache layer don\u0026rsquo;t share the same database.\nWith this inhibition rule, application_connection_failure alert notifications are suppressed if a database_offline alert is active, provided both alerts share the same region and component label values:\nsourceMatchers: - labelName: alertName operator: Equal value: database_offline targetMatchers: - labelName: alertName operator: Equal value: application_connection_failure equal: - region - component Access Next Gen API Docs Using Regional EndpointsFor further detail regarding API usage, Access Next Gen API docs.\nSuppress Downstream Alert Notification without an Equal FieldWithout an equal field, any alert matched by the sourceMatcher will suppress every alert notification matched by the targetMatcher. This is useful when all alerts matched by the targetMatcher are downstream of the sourceMatcher. For instance, in a single cluster, if the Kubernetes Control Plane is down, it is likely the Kubernetes API server will also be down. However, it is generally best practice to include an equal value to prevent unintended inhibition:\nsourceMatchers: - labelName: alertName operator: Equal value: KubernetesControlPlaneDown targetMatchers: - labelName: alertname operator: Equal value: KubernetesAPIServerDown Considerations for Alert InhibitionOnly Notifying Alerts Can Be InhibitedInhibition Rules only suppress alert notifications that are configured to forward to a notification channel. If an alert rule does not have a notification channel configured, its notifications cannot be inhibited. Inhibition Rules only affect the forwarding of alert notifications; they do not influence the evaluation of alert rules.\nAlerts Cannot Inhibit ThemselvesIf a triggering alert occurrence matches both the sourceMatcher and targetMatcher, the inhibition rule does not apply and an alert notification will still be sent. This ensures that critical alerts notifications are always forwarded, even in scenarios where the alert occurrence may inadvertently match both conditions of the inhibition rule.\nCircular DependenciesCircular dependencies occur when the triggering alert matched by the targetMatcher of one inhibition rule also matches the sourceMatcher of another inhibition rule. For example, if AlertA inhibits AlertB, but AlertB also inhibits AlertA, no alert notifications will be sent for either alert. Careful management of Inhibition Rules is necessary to avoid such scenarios.\nAlert Notifications that match the targetMatcher may be delayedBy default, alert notifications matching the targetMatcher are delayed by 2 minutes to allow time for a sourceMatcher to be identified. If a sourceMatcher is found during this delay, the alert notification is suppressed. However, to avoid delaying critical alerts, notifications matching the targetMatcher will be sent after the configured delay period, even if no sourceMatcher is identified. The default delay can be adjusted by submitting a support request.\nInteraction of Silenced Alerts with Alert InhibitionSilencing an alert occurrence does not prevent it from inhibiting an alert notification matched by the targetMatcher. Alert Silencing affects only the forwarding of alert notifications, not the evaluation of alert rules. The state of an alert occurrence remains unchanged whether it is silenced or not. If it matches a sourceMatcher, it can still inhibit an alert notification matched by the targetMatcher.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/alert-inhibition/"},{"id":538,"title":"Azure Platform Log Policy","content":" Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nCreate an Azure Platform Log PolicyTo create a Azure Platform Log policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select Azure Platform Log.\nConfigure an Azure Platform Log PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate personnel.\nSee also: Set Up Notification Channels.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and Azure Platform Log.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose Azure Platform Log to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/azure_platform_log_policy/"},{"id":539,"title":"Configure Interactive Session Expiration","content":"The parameters, with sample settings, are:\nsysdig inactivitySettings: trackerEnabled: true trackerTimeout: 1800 api: jvmOptions: -Ddraios.security.rememberMe.tokenValiditySeconds=1800 -Ddraios.security.session.timeoutMinutes=30 Parameter\nDescription\nValues\nsysdig.inactivitySettings.trackerEnabled\nMust be set to enable frontend activity tracker in general, boolean\nfalse by default\nsysdig.inactivitySettings.trackerTimeout\nTimeout in seconds before the inactive interactive session expires, valid only if\nsysdig.inactivitySettings.trackerEnabled is set to true\n1800 seconds by default\ndraios.security.rememberMe.tokenValiditySeconds\nMust match the trackerTimeout value\n1800 if trackerTimeout default is used\ndraios.security.session.timeoutMinutes\nConvert validitySeconds to minutes\n30 if trackerTimeout default is used\nThe jvmOptions parameters handle the backend session expiration, while the sysdig.inactivitySettings.trackerEnabled and\nsysdig.inactivitySettings.trackerTimeout handle the frontend activity tracker.\nLearn More sysdig.inactivitySettings.trackerEnabled sysdig.inactivitySettings.trackerTimeout ","url":"https://docs.sysdig.com/en/administration/onprem-interactive-session-expiration/"},{"id":540,"title":"Agent Configuration for Monitor","content":"To apply configurations, see Configure the Agent.\nStatsDThe statsd parameter controls StatsD metric collection. It is enabled by default.\nThe following configurations are available:\nstatsd: blacklisted_ports statsd: tcp_port statsd: udp_port statsd: ip_address: 0.0.0.0 The value indicates that the StatsD server will accept incoming traffic from any IP, local or remote. Use this configuration to add the ability to send statsd messages to a host running the agent from a remote host, and for the agent to process the message as if they have originated on the host on which the agent is running.\nBy default, the agent includes a statsd server that listens on the loopback interface (127.0.0.1) for incoming statsd messages, which does not allow accepting messages originating from remote hosts. Use the ip_address: 0.0.0.0 configuration to change this default behavior.\nEventsThe events parameter controls Event Metric Collection.\nevents: docker events: kubernetes LogThe log parameter lets you configure log levels metric collection.\nlog: event_priority log: console_priority log: file_priority PrometheusThe prometheus parameter controls Prometheus Native Service Discovery.\nprometheus: enabled JMXThe jmx parameter controls JMX metrics collection.\njmx: enabled App ChecksControls monitoring capabilities using App Check.\napp_checks: enabled KSMEnable and disable Kube State Metrics (KSM) collection. It is enabled by default.\nk8s_extra_resources: - include ... Go EventsThe go_k8s_user_events parameter streamlines Sysdig agent processing times and reduce CPU load. The default is true.\nAgent ConsoleEnable Agent Console to interact with the Sysdig agent to troubleshoot and investigate agent configuration problems quickly\ncommand_line: enabled Node MetricsTo enable the UDP/TCP sockets in use in your node, add the following configuration to dragent.yaml file.\nnode_metrics: enabled: true sockstat: enabled: true ExamplesDisable StatsD CollectionThis example shows how to turn off StatsD collection and blacklist port 6443.\nSysdig agent uses port 6443 for both inbound and outbound communication with the Sysdig backend. The agent initiates a request and keeps a connection open with the Sysdig backend for the backend to push configurations, Falco rules, policies, and so on.\nEnsure that you allow the agents\u0026rsquo; inbound and outbound communication on TCP 6443 from the respective IP addresses associated with your SaaS Regions. Note that you are allowing the agent to send communication outbound on TCP 6443 to the inbound IP ranges listed in the SaaS Regions.\nYAML Formatstatsd: enabled: false blacklisted_ports: - 6443 Single-Line FormatUse spaces, hyphens, and \\n correctly when manually converting to a single line:\nADDITIONAL_CONF=\u0026quot;statsd:\\n enabled: false\\n blacklisted_ports:\\n - 6443\u0026quot;\nYou can run a full agent startup Docker command in a single line as follows:\ndocker run --name sysdig-agent \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ -e TAGS=dept:sales,local:NYC \\ -e ADDITIONAL_CONF=\u0026#34;statsd:\\n enabled: false\\n blacklisted_ports:\\n - 6443\u0026#34; \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ quay.io/sysdig/agent Add RabbitMQ App CheckThis example helps you override the default configuration for a RabbitMQ app check.\nYAML Formatapp_checks: - name: rabbitmq pattern: port: 15672 conf: rabbitmq_api_url: \u0026#34;http://localhost:15672/api/\u0026#34; rabbitmq_user: myuser rabbitmq_pass: mypassword queues: - MyQueue1 - MyQueue2 Single-Line Format (echo | sed)From a Bash shell, issue the echo command and sed script.\necho \u0026#34;app_checks: - name: rabbitmq pattern: port: 15672 conf: rabbitmq_api_url: \u0026#34;http://localhost:15672/api/\u0026#34; rabbitmq_user: myuser rabbitmq_pass: mypassword queues: - MyQueue1 - MyQueue2 \u0026#34; | sed -e \u0026#39;:a\u0026#39; -e \u0026#39;N\u0026#39; -e \u0026#39;$!ba\u0026#39; -e \u0026#39;s/\\n/\\\\n/g\u0026#39; This results in the single-line format to be used with ADDITIONAL_CONF in a Docker command or DaemonSet file.\n\u0026#34;app_checks:\\n - name: rabbitmq\\n pattern:\\n port: 15672\\n conf:\\n rabbitmq_api_url: http://localhost:15672/api/\\n rabbitmq_user: myuser\\n rabbitmq_pass: mypassword\\n queues:\\n - MyQueue1\\n - MyQueue2\\n\u0026#34; ","url":"https://docs.sysdig.com/en/sysdig-monitor/agent-configuration-for-monitor/"},{"id":541,"title":"Connection between Agent and Sysdig Collector","content":"During this period, the Sysdig Agent continues to collect events as they occur, buffers the data locally, and attempts to resend them to the Sysdig collector. To store data locally, the agent maintains an internal buffer of 300 messages. This means that the agent\u0026rsquo;s ability to retain information during a network disruption is entirely dependent on the number of messages generated, not the size of the individual messages.\nFor example, in a Monitor-only SaaS environment sending metrics every 10 seconds, the agent can queue the data for 50 minutes. This queue far surpasses the Sysdig collector\u0026rsquo;s ability to ingest historical data. If you have a Platform SaaS environment sending a steady stream of metrics, policy events, captures, and so on, the 300 slots could be exhausted quickly, as a single capture can produce far more than 300 messages.\nOnce the connection is re-established, the agent transmits all queued messages in the order they were generated.\nYou can configure the queue length by setting the following parameter in the dragent.yaml file.\ncollector_endpoint: transmit_queue_depth: 300 When the queue depth is increased, the additional messages will also be stored in memory, therefore, the memory allocation for the agent will also need to be adjusted in the host. The amount of memory required for the agent is determined by the average size of messages produced by the agent. If the average size of the message is 100 KB and the queue depth is doubled in size from the default 300 to 600, the host requires 100KB*300 = 30 MB additional memory for the agent. But if the average message size is 1MB, the host would require 300 MB more. Most users should not need to adjust the internal queue depth, but if assistance is needed then please contact Sysdig support.\n","url":"https://docs.sysdig.com/en/sysdig-secure/agent-downtime-behavior/"},{"id":542,"title":"Consul Base Metrics","content":"See Application Integrations for more information.\nconsul.catalog.nodes_criticalNumber of nodes with service status `critical` from those registered.\nconsul.catalog.nodes_passingNumber of nodes with service status `passing` from those registered.\nconsul.catalog.nodes_upNumber of nodes.\nconsul.catalog.nodes_warningNumber of nodes with service status `warning` from those registered.\nconsul.catalog.services_criticalTotal critical services on nodes.\nconsul.catalog.services_passingTotal passing services on nodes.\nconsul.catalog.services_upTotal services registered on nodes.\nconsul.catalog.services_warningTotal warning services on nodes.\nconsul.catalog.total_nodesNumber of nodes registered in the consul cluster.\nconsul.net.node.latency.maxMaximum latency from this node to all others.\nconsul.net.node.latency.medianMedian latency from this node to all others.\nconsul.net.node.latency.minMinimum latency from this node to all others.\nconsul.net.node.latency.p25p25 latency from this node to all others.\nconsul.net.node.latency.p75p75 latency from this node to all others.\nconsul.net.node.latency.p90p90 latency from this node to all others.\nconsul.net.node.latency.p95p95 latency from this node to all others.\nconsul.net.node.latency.p99p99 latency from this node to all others.\nconsul.peersNumber of peers in the peer set.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/consul-base-metrics/"},{"id":543,"title":"Containers","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\ncontainer.countThe number of containers in the infrastructure.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Time Aggregation Formats Avg, Sum, Min, Max container.idThe container\u0026rsquo;s identifier.\nFor Docker containers, this value is a 12 digit hex number.\nMetadata Description Metric Type Gauge Value Type String Segment By Container Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Time Aggregation Formats N/A container.imageThe name of the image used to run the container.\nMetadata Description Metric Type Gauge Value Type String Segment By Container Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Time Aggregation Formats N/A container.nameThe name of the container.\nMetadata Description Metric Type Gauge Value Type String Segment By Container Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Time Aggregation Formats N/A container.typeThe type of container (for example, Docker, LXC, or Mesos).\nMetadata Description Metric Type Gauge Value Type String Segment By Container Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Time Aggregation Formats N/A cpu.quota.used.percentThe percentage of CPU quota a container actually used over a defined period of time.\nCPU quotas are a common way of creating a CPU limit for a container. A container can only spend its quota of time on CPU cycles across a given time period. The default time period is 100ms.\nUnlike CPU shares, CPU quota is a hard limit for the amount of CPU the container can use. For this reason, the CPU quota should not exceed 100% for an extended period of time. For a shorter time, containers are allowed to consume higher than the CPU quota.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Time Aggregation Formats Avg, Sum, Min, Max cpu.shares.countThe amount of CPU shares assigned to the container\u0026rsquo;s cgroup. CPU shares represent a relative weight used by the kernel to distribute CPU cycles across different containers. Each container receives its own allocation of CPU cycles, based on the ratio of share allocation for the container versus the total share allocation for all containers. For example, if an environment has three containers, each with 1024 shares, then each will receive 1/3 of the CPU cycles.\nThe default value for a container is 1024.\nDefining a CPU shares count is a common way to create a CPU limit for a container.\nThe CPU shares count is not a hard limit. A container can consume more than its allocation, as long as the CPU has cycles that are not being consumed by the container they were originally allocated to.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Time Aggregation Formats Avg, Sum, Min, Max cpu.shares.used.percentThe percentage of a container\u0026rsquo;s allocated CPU shares that are used. CPU shares are a common way of creating a CPU limit for a container, as they represent a relative weight used by the kernel to distribute CPU cycles across different containers. Each container receives its own allocation of CPU cycles, according to the ratio of share count vs the total number of shares claimed by all containers. For example, in an infrastructure with three containers, each with 1024 shares, each container receives 1/3 of the CPU cycles.\nA container can use more CPU cycles than allocated if the CPU has cycles that are not being consumed by the container they were originally allocated to. This means that the value of cpu.shares.used.percent can exceed 100%.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Time Aggregation Formats Avg, Sum, Min, Max memory.limit.bytesThe RAM limit assigned to a container. The default value is 0.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Time Aggregation Formats Avg, Sum, Min, Max memory.limit.used.percentThe percentage of the memory limit used by a container.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Time Aggregation Formats Avg, Sum, Min, Max swap.limit.bytesThe swap limit assigned to a container.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Time Aggregation Formats Avg, Sum, Min, Max swap.limit.used.percentThe percentage of swap limit used by the container.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Time Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/containers/"},{"id":544,"title":"Custom Certificates","content":"Some differences exist depending on the type of installation you are performing.\nHost InstallationIn a host installation, you can specify the location of the CA certificate in the dragent.yaml file.\nca_certificate: /path/to/ca.crt For Windows host installations, the path should be in the format C:\\path\\to\\ca.crt. Stop the Sysdig Agent service in Windows host installations before performing this configuration.\nAfter you modify the dragent.yaml file, restart the services to apply the changes.\nCluster InstallationIn a cluster installation, you can specify the content of the custom certificate in the values.yaml file or directly using the key-value pair.\nUse the Key-Value PairSpecify each parameter using the --set key=value[,key=value] argument to the helm install command.\nhelm install sysdig sysdig/sysdig-deploy \\ --set global.ssl.ca.certs[0]=\u0026lt;CA_CERTIFICATE\u0026gt; Use values.yamlThe values.yaml file specifies the values for the configuration parameters. You can add the configuration to the values.yaml file, then use it in the helm install command.\nglobal: ssl: ca: certs: - | -----BEGIN CERTIFICATE----- MIIDEzCCAfugAwIBAgIQKiv9U+KxPJzu1adXwC06RzANBgkqhkiG9w0BAQsFADAU MRIwEAYDVQQDEwloYXJib3ItY2EwHhcNMjIwMjIzMDY1NjExWhcNMjMwMjIzMDY1 NjExWjAUMRIwEAYDVQQDEwloYXJib3ItY2EwggEiMA0GCSqGSIb3DQEBAQUAA4IB MMNlTAQ9fvdNOTzZntye0PQYR5SR13E= -----END CERTIFICATE----- # Filename that is used when creating the secret. Required if cert is provided. keyName: \u0026#34;ca.crt\u0026#34; Execute the following command after modifying the values.yaml file. This will mount the certificate as a secret in the agent namespace.\nhelm install sysdig sysdig/sysdig-deploy -f values.yaml There are other options to configure the CA certificate in the values.yaml file depending on the existing secret or configmap that contains the CA certificate.\n# Provide the name of an existing Secret that contains the CA required existingCaSecret: \u0026#34;my-certificate\u0026#34; # Provide the filename that is defined inside the existing Secret existingCaSecretKeyName: \u0026#34;ca.crt\u0026#34; # Provide the name of an existing ConfigMap that contains the CA required existingCaConfigMap: \u0026#34;my-ca-configmap\u0026#34; # Provide the filename that is defined inside the existing ConfigMap existingCaConfigMapKeyName: \u0026#34;ca.crt\u0026#34; Learn More Sysdig Helm Chart documentation ","url":"https://docs.sysdig.com/en/administration/onprem-custom-certificates/"},{"id":545,"title":"Configure Custom Integrations","content":"View Unidentified WorkloadsWhen Sysdig does not recognize the application from which metrics have come, it categorizes them as “Unidentified workloads.” You can configure these integrations via custom integration steps.\nTo view unidentified workloads Sysdig has detected in your environments:\nLog in to Sysdig Monitor. Select Integrations \u0026gt; Monitoring Integrations. Select the Show Unidentified Workloads toggle on the top right of the page. In rare cases, Sysdig may have a default integration, but the backend did not correctly identify the workload. To manually assign the correct integration, click the unidentified workload in the Monitoring Integrations page. In the wizard, under Select an Out of Box Integration, choose the correct integration from the list.\nCollect Metrics with Custom IntegrationsThere are several ways to collect metrics with custom integrations, depending on the location of the workload, and the type of metrics:\nPrometheus Metrics: See Collect Prometheus Metrics.\nJava Management Extensions (JMX) Metrics: See Integrate JMX Metrics from Java Virtual Machines.\nNode.js Metrics: See Integrate Node.js Application Metrics.\nStatsD Metrics: See Integrate StatsD Metrics.\nOnce configured, custom integrations will not be visible from the Monitoring Integrations page. To view those metrics:\nSelect Explore \u0026gt; Metrics Usage. Select the All jobs drop down to filter your metrics by job. The metrics will also be available in modules such as Dashboards and Alerts.\nThird Party IntegrationsPlatform Metrics (IBM)For Sysdig instances deployed on IBM Cloud Monitoring with Sysdig, an additional form of metrics collection is offered: Platform metrics. Rather than being collected by the Sysdig agent, when enabled, Platform metrics are reported to Sysdig directly by the IBM Cloud infrastructure.\nPlatform metrics are metrics that are exposed by enabled services across the IBM Cloud platform. These services have made metrics and pre-defined dashboards for their services available by publishing metrics associated with the customer’s space or account. Customers can view these platform metrics alongside the metrics from their applications and other services within IBM Cloud monitoring.\nEnable this feature by logging into the IBM Cloud console and selecting Enable for IBM Platform metrics under the Configure your resource section when creating a new IBM Cloud Monitoring with a Sysdig instance. See Enabling a monitoring instance through the UI.\nKedaTo integrate Keda for Horizontal Pod Autoscaler (HPA), see Integrate Keda for HPA.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/custom-integrations/"},{"id":546,"title":"Developer Tools","content":"Sysdig APISysdig provides a Sysdig API that enables you to programmatically access and manage Sysdig Monitor, Sysdig Secure, and Sysdig Platform\nTerraform ProviderSysdig provides a Terraform Provider to expose and use some of the most common Sysdig API functions.\nSysdig Software Development KitSysdig provides a Sysdig Python SDK and a CLI tool to extend and automate the functions of the Sysdig Monitor and Secure capabilities. The Sysdig Platform CLI (sdc-cli) is a unified tool implemented using Sysdig Python SDK to manage Sysdig Monitor and Sysdig Secure using your terminal.\nSysdig Platform CLI is no longer under active maintenance. For the most up-to-date endpoints and support, use the Sysdig API.\nNext Steps Terraform Provider\nSysdig SDK for Python\nSysdig Platform CLI\nSysdig API\n","url":"https://docs.sysdig.com/en/developer-tools/"},{"id":547,"title":"Disable Password Authentication","content":" For SaaS environments, see Disable Password Authentication (SaaS).\nOn-Prem DeploymentsAs a super administrator, perform the following:\nGet the Sysdig Platform settings:\nGET https://\u0026lt;URL-installation\u0026gt;/api/admin/auth/settings Replace \u0026lt;URL-installation\u0026gt; with the URL of your on-prem deployment.\nRetrieve the specific settings associated with the SSO setup. In a typical scenario, only one IDP exists per deployment.\nGET https://\u0026lt;URL-installation\u0026gt;/api/auth/settings/{id} The setting is displayed in a JSON file.\nIn the JSON file, change the following from false to true:\nsettings/forbidPasswordLogin: True Update the setting with a request to the same URL with the same JSON, with the changed parameter. URL depends on the type of deployment.\nPUT https://app.sysdigcloud.com/api/admin/auth/settings/{id} Migrating from the ConfigMap MethodPreviously, the sysdigcloud.restrict.password.login parameter in the Kubernetes ConfigMap was used to disable password authentication. After installing 3.2.0, deployments utilizing the sysdigcloud.restrict.password.login settings will be automatically migrated to use the new settings.\n","url":"https://docs.sysdig.com/en/administration/onprem-disable-password-auth/"},{"id":548,"title":"Driver Modes","content":"PerformanceThe Performance mode uses a Sysdig proprietary instrumentation library built on top of ptrace. It offers the same data precision as kernel captures, full support for any type of executable, and overhead comparable to kernel instrumentation in the majority of workloads.\nCompatibilityThe Compatibility mode uses pure ptrace, reducing interference between Sysdig instrumentation and the secured workload application, though it comes with a performance trade-off. This mode can help factor out issues in the instrumented workload that occur in Performance mode.\nConfigure the Driver ModeThe Serverless Agent driver defaults to the Performance mode. You can switch to the Compatibility mode by providing the container running the instrumented application with the following environment variable:\nSYSDIG_INSTRUMENTATION_LIBRARY=\u0026#34;none\u0026#34; ","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-driver-modes/"},{"id":549,"title":"Elastic Load Balancing (ELB)","content":"aws.elb.BackendConnectionErrorsThe number of errors encountered by the load balancer while attempting to connect to your application.\nFor high error counts, look for network related issues or check that your servers are operating correctly. The ELB is having problems connecting to them.\nFor more information, refer to the Elastic Load Balancing documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.HealthyHostCountA count of the number of healthy instances that are bound to the load balancer.\nHosts are declared healthy if they meet the threshold for the number of consecutive health checks that are successful. Hosts that have failed more health checks than the value of the unhealthy threshold are considered unhealthy. If cross-zone is enabled, the count of the number of healthy instances is calculated for all Availability Zones.\nFor more information, refer to the Elastic Load Balancing documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.HTTPCode_Backend_2XXThe count of the number of HTTP 2XX response codes generated by back-end instances. This metric does not include any response codes generated by the load balancer.\nThe 2XX class status codes represent successful actions (e.g., 200-OK, 201-Created, 202-Accepted, 203-Non-Authoritative Info).\nFor more information, refer to the Elastic Load Balancing documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.HTTPCode_Backend_3XXThe count of the number of HTTP 3XX response codes generated by back-end instances. This metric does not include any response codes generated by the load balancer.\nThe 3XX class status code indicates that the user agent requires action (e.g., 301-Moved Permanently, 302-Found, 305-Use Proxy, 307-Temporary Redirect).\nFor more information, refer to the Elastic Load Balancing documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.HTTPCode_Backend_4XXThe count of the number of HTTP 4XX response codes generated by back-end instances. This metric does not include any response codes generated by the load balancer. For more information, refer to the Elastic Load Balancing documentation.\nThe 4XX class status code represents client errors (e.g., 400-Bad Request, 401-Unauthorized, 403-Forbidden, 404-Not Found).\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.HTTPCode_Backend_5XXThe count of the number of HTTP 5XX response codes generated by back-end instances. This metric does not include any response codes generated by the load balancer. For more information, refer to the Elastic Load Balancing documentation.\nThe 5XX class status code represents back-end server errors e.g., 500-Internal Server Error, 501-Not implemented, 503-Service Unavailable).\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.HTTPCode_ELB_4XXThe count of the number of HTTP 4XX client error codes generated by the load balancer when the listener is configured to use HTTP or HTTPS protocols. For more information, refer to the Elastic Load Balancing documentation.\nClient errors are generated when a request is malformed or is incomplete.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.HTTPCode_ELB_5XXThe count of the number of HTTP 5XX server error codes generated by the load balancer when the listener is configured to use HTTP or HTTPS protocols. This metric does not include any responses generated by back-end instances.For more information, refer to the Elastic Load Balancing documentation.\nThe metric is reported if there are no back-end instances that are healthy or registered to the load balancer, or if the request rate exceeds the capacity of the instances or the load balancers.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.LatencyA measurement of the time backend requests require to process. For more information, refer to the Elastic Load Balancing documentation.\nLatency metrics from the ELB are good indicators of the overall performance of your application.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.RequestCountThe number of requests handled by the load balancer. For more information, refer to the Elastic Load Balancing documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.SpilloverCountA count of the total number of requests that were rejected due to the queue being full. For more information, refer to the Elastic Load Balancing documentation.\nPositive numbers indicate some requests are not being forwarded to any server. Clients are not notified that their request was dropped.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.SurgeQueueLengthA count of the total number of requests that are pending submission to a registered instance. For more information, refer to the Elastic Load Balancing documentation.\nPositive numbers indicate clients are waiting for their requests to be forwarded to a server for processing.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.elb.UnHealthyHostCountThe count of the number of unhealthy instances that are bound to the load balancer. For more information, refer to the Elastic Load Balancing documentation.\nHosts are declared healthy if they meet the threshold for the number of consecutive health checks that are successful. Hosts that have failed more health checks than the value of the unhealthy threshold are considered unhealthy.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/sysdig-monitor/aws-metrics-legacy/elastic-load-balancing-elb/"},{"id":550,"title":"Elasticsearch","content":"You can edit the configuration to collect Primary Shard stats.\nThis page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nElasticsearch SetupElasticsearch is ready to expose metrics without any special configuration.\nSysdig Agent ConfigurationReview how to edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with Elasticsearch and collect basic metrics.\napp_checks: - name: elasticsearch check_module: elastic pattern: port: 9200 comm: java conf: url: http://localhost:9200 For more metrics, you may need to change the elasticsearch default setting in dragent.yaml:\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1: Agent authentication to Elasticsearch Cluster with AuthenticationPassword Authenticationapp_checks: - name: elasticsearch check_module: elastic pattern: port: 9200 comm: java conf: url: https://sysdigcloud-elasticsearch:9200 username: readonly password: some_password ssl_verify: false Certificate Authenticationapp_checks: - name: elasticsearch check_module: elastic pattern: port: 9200 comm: java conf: url: https://localhost:9200 ssl_cert: /tmp/certs/ssl.crt ssl_key: /tmp/certs/ssl.key ssl_verify: true ssl_cert: Path to the certificate chain used for validating the authenticity of the Elasticsearch server.\nssl_key: Path to the certificate key used for authenticating to the Elasticsearch server.\nExample 2: Enable Primary shard Statisticsapp_checks: - name: elasticsearch check_module: elastic pattern: port: 9200 comm: java conf: url: http://localhost:9200 pshard_stats : true pshard-specific MetricsEnable pshard_stats to monitor the following additional metrics:\nMetric Name elasticsearch.primaries.flush.total elasticsearch.primaries.flush.total.time elasticsearch.primaries.docs.count elasticsearch.primaries.docs.deleted elasticsearch.primaries.get.current elasticsearch.primaries.get.exists.time elasticsearch.primaries.get.exists.total elasticsearch.primaries.get.missing.time elasticsearch.primaries.get.missing.total elasticsearch.primaries.get.time elasticsearch.primaries.get.total elasticsearch.primaries.indexing.delete.current elasticsearch.primaries.indexing.delete.time elasticsearch.primaries.indexing.delete.total elasticsearch.primaries.indexing.index.current elasticsearch.primaries.indexing.index.time elasticsearch.primaries.indexing.index.total elasticsearch.primaries.merges.current elasticsearch.primaries.merges.current.docs elasticsearch.primaries.merges.current.size elasticsearch.primaries.merges.total elasticsearch.primaries.merges.total.docs elasticsearch.primaries.merges.total.size elasticsearch.primaries.merges.total.time elasticsearch.primaries.refresh.total elasticsearch.primaries.refresh.total.time elasticsearch.primaries.search.fetch.current elasticsearch.primaries.search.fetch.time elasticsearch.primaries.search.fetch.total elasticsearch.primaries.search.query.current elasticsearch.primaries.search.query.time elasticsearch.primaries.search.query.total elasticsearch.primaries.store.size Example 3: Enable Primary shard Statistics for Master Node onlyapp_checks: - name: elasticsearch check_module: elastic pattern: port: 9200 comm: java conf: url: http://localhost:9200 pshard_stats_master_node_only: true Note that this option takes precedence over the pshard_stats option (above). This means that if the following configuration were put into place, only the pshard_stats_master_node_only option would be respected:\napp_checks: - name: elasticsearch check_module: elastic pattern: port: 9200 comm: java conf: url: http://localhost:9200 pshard_stats: true pshard_stats_master_node_only: true All Available MetricsWith the default settings and the pshard setting, the total available metrics are listed here: Elasticsearch Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/elasticsearch/"},{"id":551,"title":"Elasticsearch Metrics","content":"See Application Integrations for more information.\nAll Elasticsearch metrics have the type gauge.\nelasticsearch.active_primary_shardsThe number of active primary shards in the cluster.\nelasticsearch.active_shardsThe number of active shards in the cluster.\nelasticsearch.breakers.fielddata.estimated_size_in_bytesThe estimated size in bytes of the field data circuit breaker.\nelasticsearch.breakers.fielddata.overheadThe constant multiplier for byte estimations of the field data circuit breaker.\nelasticsearch.breakers.fielddata.trippedThe number of times the field data circuit breaker has tripped.\nelasticsearch.breakers.parent.estimated_size_in_bytesThe estimated size in bytes of the parent circuit breaker.\nelasticsearch.breakers.parent.overheadThe constant multiplier for byte estimations of the parent circuit breaker.\nelasticsearch.breakers.parent.trippedThe number of times the parent circuit breaker has tripped.\nelasticsearch.breakers.request.estimated_size_in_bytesThe estimated size in bytes of the request circuit breaker.\nelasticsearch.breakers.request.overheadThe constant multiplier for byte estimations of the request circuit breaker.\nelasticsearch.breakers.request.trippedThe number of times the request circuit breaker has tripped.\nelasticsearch.breakers.inflight_requests.trippedThe number of times the inflight circuit breaker has tripped.\nelasticsearch.breakers.inflight_requests.overheadThe constant multiplier for byte estimations of the inflight circuit breaker.\nelasticsearch.breakers.inflight_requests.estimated_size_in_bytesThe estimated size in bytes of the inflight circuit breaker.\nelasticsearch.cache.field.evictionsThe total number of evictions from the field data cache.\nelasticsearch.cache.field.sizeThe size of the field cache.\nelasticsearch.cache.filter.countThe number of items in the filter cache.\nelasticsearch.cache.filter.evictionsThe total number of evictions from the filter cache.\nelasticsearch.cache.filter.sizeThe size of the filter cache.\nelasticsearch.cluster_statusThe elasticsearch cluster health as a number: red = 0, yellow = 1, green = 2\nelasticsearch.docs.countThe total number of documents in the cluster across all shards.\nelasticsearch.docs.deletedThe total number of documents deleted from the cluster across all shards.\nelasticsearch.fielddata.evictionsThe total number of evictions from the fielddata cache.\nelasticsearch.fielddata.sizeThe size of the fielddata cache.\nelasticsearch.flush.totalThe total number of index flushes to disk since start.\nelasticsearch.flush.total.timeThe total time spent flushing the index to disk.\nelasticsearch.fs.total.available_in_bytesThe total number of bytes available to this Java virtual machine on this file store.\nelasticsearch.fs.total.disk_io_opThe total I/O operations on the file store.\nelasticsearch.fs.total.disk_io_size_in_bytesTotal bytes used for all I/O operations on the file store.\nelasticsearch.fs.total.disk_read_size_in_bytesThe total bytes read from the file store.\nelasticsearch.fs.total.disk_readsThe total number of reads from the file store.\nelasticsearch.fs.total.disk_write_size_in_bytesThe total bytes written to the file store.\nelasticsearch.fs.total.disk_writesThe total number of writes to the file store.\nelasticsearch.fs.total.free_in_bytesThe total number of unallocated bytes in the file store.\nelasticsearch.fs.total.total_in_bytesThe total size in bytes of the file store.\nelasticsearch.get.currentThe number of get requests currently running.\nelasticsearch.get.exists.timeThe total time spent on get requests where the document existed.\nelasticsearch.get.exists.totalThe total number of get requests where the document existed.\nelasticsearch.get.missing.timeThe total time spent on get requests where the document was missing.\nelasticsearch.get.missing.totalThe total number of get requests where the document was missing.\nelasticsearch.get.timeThe total time spent on get requests.\nelasticsearch.get.totalThe total number of get requests.\nelasticsearch.http.current_openThe number of current open HTTP connections.\nelasticsearch.http.total_openedThe total number of opened HTTP connections.\nelasticsearch.id_cache.sizeThe size of the id cache\nelasticsearch.indexing.delete.currentThe number of documents currently being deleted from an index.\nelasticsearch.indexing.delete.timeThe total time spent deleting documents from an index.\nelasticsearch.indexing.delete.totalThe total number of documents deleted from an index.\nelasticsearch.indexing.index.currentThe number of documents currently being indexed to an index.\nelasticsearch.indexing.index.timeThe total time spent indexing documents to an index.\nelasticsearch.indexing.index.totalThe total number of documents indexed to an index.\nelasticsearch.indices.countThe number of indices in the cluster.\nelasticsearch.indices.indexing.index_failedThe number of failed indexing operations.\nelasticsearch.indices.indexing.throttle_timeThe total time indexing waited due to throttling.\nelasticsearch.indices.query_cache.evictionsThe number of query cache evictions.\nelasticsearch.indices.query_cache.hit_countThe number of query cache hits.\nelasticsearch.indices.query_cache.memory_size_in_bytesThe memory used by the query cache.\nelasticsearch.indices.query_cache.miss_countThe number of query cache misses.\nelasticsearch.indices.recovery.current_as_sourceThe number of ongoing recoveries for which a shard serves as a source.\nelasticsearch.indices.recovery.current_as_targetThe number of ongoing recoveries for which a shard serves as a target.\nelasticsearch.indices.recovery.throttle_timeThe total time recoveries waited due to throttling.\nelasticsearch.indices.request_cache.evictionsThe number of request cache evictions.\nelasticsearch.indices.request_cache.hit_countThe number of request cache hits.\nelasticsearch.indices.request_cache.memory_size_in_bytesThe memory used by the request cache.\nelasticsearch.indices.request_cache.miss_countThe number of request cache misses.\nelasticsearch.indices.segments.countThe number of segments in an index shard.\nelasticsearch.indices.segments.doc_values_memory_in_bytesThe memory used by doc values.\nelasticsearch.indices.segments.fixed_bit_set_memory_in_bytesThe memory used by fixed bit set.\nelasticsearch.indices.segments.index_writer_max_memory_in_bytesThe maximum memory used by the index writer.\nelasticsearch.indices.segments.index_writer_memory_in_bytesThe memory used by the index writer.\nelasticsearch.indices.segments.memory_in_bytesThe memory used by index segments.\nelasticsearch.indices.segments.norms_memory_in_bytesThe memory used by norms.\nelasticsearch.indices.segments.stored_fields_memory_in_bytesThe memory used by stored fields.\nelasticsearch.indices.segments.term_vectors_memory_in_bytesThe memory used by term vectors.\nelasticsearch.indices.segments.terms_memory_in_bytesThe memory used by terms.\nelasticsearch.indices.segments.version_map_memory_in_bytesThe memory used by the segment version map.\nelasticsearch.indices.translog.operationsThe number of operations in the transaction log.\nelasticsearch.indices.translog.size_in_bytesThe size of the transaction log.\nelasticsearch.initializing_shardsThe number of shards that are currently initializing.\nelasticsearch.merges.currentThe number of currently active segment merges.\nelasticsearch.merges.current.docsThe number of documents across segments currently being merged.\nelasticsearch.merges.current.sizeThe size of the segments currently being merged.\nelasticsearch.merges.totalThe total number of segment merges.\nelasticsearch.merges.total.docsThe total number of documents across all merged segments.\nelasticsearch.merges.total.sizeThe total size of all merged segments.\nelasticsearch.merges.total.timeThe total time spent on segment merging.\nelasticsearch.number_of_data_nodesThe number of data nodes in the cluster.\nelasticsearch.number_of_nodesThe total number of nodes in the cluster.\nelasticsearch.pending_tasks_priority_highThe number of high priority pending tasks.\nelasticsearch.pending_tasks_priority_urgentThe number of urgent priority pending tasks.\nelasticsearch.pending_tasks_time_in_queueThe average time spent by tasks in the queue.\nelasticsearch.pending_tasks_totalThe total number of pending tasks.\nelasticsearch.process.open_fdThe number of opened file descriptors associated with the current process, or -1 if not supported.\nelasticsearch.refresh.totalThe total number of index refreshes.\nelasticsearch.refresh.total.timeThe total time spent on index refreshes.\nelasticsearch.relocating_shardsThe number of shards that are relocating from one node to another.\nelasticsearch.search.fetch.currentThe number of search fetches currently running.\nelasticsearch.search.fetch.open_contextsThe number of active searches.\nelasticsearch.search.fetch.timeThe total time spent on the search fetch.\nelasticsearch.search.fetch.totalThe total number of search fetches.\nelasticsearch.search.query.currentThe number of currently active queries.\nelasticsearch.search.query.timeThe total time spent on queries.\nelasticsearch.search.query.totalThe total number of queries.\nelasticsearch.store.sizeThe total size in bytes of the store.\nelasticsearch.thread_pool.bulk.activeThe number of active threads in the bulk pool.\nelasticsearch.thread_pool.bulk.queueThe number of queued threads in the bulk pool.\nelasticsearch.thread_pool.bulk.threadsThe total number of threads in the bulk pool.\nelasticsearch.thread_pool.bulk.rejectedThe number of rejected threads in the bulk pool.\nelasticsearch.thread_pool.fetch_shard_started.activeThe number of active threads in the fetch shard started pool.\nelasticsearch.thread_pool.fetch_shard_started.threadsThe total number of threads in the fetch shard started pool.\nelasticsearch.thread_pool.fetch_shard_started.queueThe number of queued threads in the fetch shard started pool.\nelasticsearch.thread_pool.fetch_shard_started.rejectedThe number of rejected threads in the fetch shard started pool.\nelasticsearch.thread_pool.fetch_shard_store.activeThe number of active threads in the fetch shard store pool.\nelasticsearch.thread_pool.fetch_shard_store.threadsThe total number of threads in the fetch shard store pool.\nelasticsearch.thread_pool.fetch_shard_store.queueThe number of queued threads in the fetch shard store pool.\nelasticsearch.thread_pool.fetch_shard_store.rejectedThe number of rejected threads in the fetch shard store pool.\nelasticsearch.thread_pool.flush.activeThe number of active threads in the flush queue.\nelasticsearch.thread_pool.flush.queueThe number of queued threads in the flush pool.\nelasticsearch.thread_pool.flush.threadsThe total number of threads in the flush pool.\nelasticsearch.thread_pool.flush.rejectedThe number of rejected threads in the flush pool.\nelasticsearch.thread_pool.force_merge.activeThe number of active threads for force merge operations.\nelasticsearch.thread_pool.force_merge.threadsThe total number of threads for force merge operations.\nelasticsearch.thread_pool.force_merge.queueThe number of queued threads for force merge operations.\nelasticsearch.thread_pool.force_merge.rejectedThe number of rejected threads for force merge operations.\nelasticsearch.thread_pool.generic.activeThe number of active threads in the generic pool.\nelasticsearch.thread_pool.generic.queueThe number of queued threads in the generic pool.\nelasticsearch.thread_pool.generic.threadsThe total number of threads in the generic pool.\nelasticsearch.thread_pool.generic.rejectedThe number of rejected threads in the generic pool.\nelasticsearch.thread_pool.get.activeThe number of active threads in the get pool.\nelasticsearch.thread_pool.get.queueThe number of queued threads in the get pool.\nelasticsearch.thread_pool.get.threadsThe total number of threads in the get pool.\nelasticsearch.thread_pool.get.rejectedThe number of rejected threads in the get pool.\nelasticsearch.thread_pool.index.activeThe number of active threads in the index pool.\nelasticsearch.thread_pool.index.queueThe number of queued threads in the index pool.\nelasticsearch.thread_pool.index.threadsThe total number of threads in the index pool.\nelasticsearch.thread_pool.index.rejectedThe number of rejected threads in the index pool.\nelasticsearch.thread_pool.listener.activeThe number of active threads in the listener pool.\nelasticsearch.thread_pool.listener.queueThe number of queued threads in the listener pool.\nelasticsearch.thread_pool.listener.threadsThe total number of threads in the listener pool.\nelasticsearch.thread_pool.listener.rejectedThe number of rejected threads in the listener pool.\nelasticsearch.thread_pool.management.activeThe number of active threads in the management pool.\nelasticsearch.thread_pool.management.queueThe number of queued threads in the management pool.\nelasticsearch.thread_pool.management.threadsThe total number of threads in the management pool.\nelasticsearch.thread_pool.management.rejectedThe number of rejected threads in the management pool.\nelasticsearch.thread_pool.merge.activeThe number of active threads in the merge pool.\nelasticsearch.thread_pool.merge.queueThe number of queued threads in the merge pool.\nelasticsearch.thread_pool.merge.threadsThe total number of threads in the merge pool.\nelasticsearch.thread_pool.merge.rejectedThe number of rejected threads in the merge pool.\nelasticsearch.thread_pool.percolate.activeThe number of active threads in the percolate pool.\nelasticsearch.thread_pool.percolate.queueThe number of queued threads in the percolate pool.\nelasticsearch.thread_pool.percolate.threadsThe total number of threads in the percolate pool.\nelasticsearch.thread_pool.percolate.rejectedThe number of rejected threads in the percolate pool.\nelasticsearch.thread_pool.refresh.activeThe number of active threads in the refresh pool.\nelasticsearch.thread_pool.refresh.queueThe number of queued threads in the refresh pool.\nelasticsearch.thread_pool.refresh.threadsThe total number of threads in the refresh pool.\nelasticsearch.thread_pool.refresh.rejectedThe number of rejected threads in the refresh pool.\nelasticsearch.thread_pool.search.activeThe number of active threads in the search pool.\nelasticsearch.thread_pool.search.queueThe number of queued threads in the search pool.\nelasticsearch.thread_pool.search.threadsThe total number of threads in the search pool.\nelasticsearch.thread_pool.search.rejectedThe number of rejected threads in the search pool.\nelasticsearch.thread_pool.snapshot.activeThe number of active threads in the snapshot pool.\nelasticsearch.thread_pool.snapshot.queueThe number of queued threads in the snapshot pool.\nelasticsearch.thread_pool.snapshot.threadsThe total number of threads in the snapshot pool.\nelasticsearch.thread_pool.snapshot.rejectedThe number of rejected threads in the snapshot pool.\nelasticsearch.thread_pool.write.activeThe number of active threads in the write pool.\nelasticsearch.thread_pool.write.queueThe number of queued threads in the write pool.\nelasticsearch.thread_pool.write.threadsThe total number of threads in the write pool.\nelasticsearch.thread_pool.write.rejectedThe number of rejected threads in the write pool.\nelasticsearch.transport.rx_countThe total number of packets received in cluster communication.\nelasticsearch.transport.rx_sizeThe total size of data received in cluster communication.\nelasticsearch.transport.server_openThe number of connections opened for cluster communication.\nelasticsearch.transport.tx_countThe total number of packets sent in cluster communication.\nelasticsearch.transport.tx_sizeThe total size of data sent in cluster communication.\nelasticsearch.unassigned_shardsThe number of shards that are unassigned to a node.\nelasticsearch.delayed_unassigned_shardsThe number of shards whose allocation has been delayed.\njvm.gc.collection_countThe total number of garbage collections run by the JVM.\njvm.gc.collection_timeThe total time spent on garbage collection in the JVM.\njvm.gc.collectors.old.collection_timeThe total time spent in major GCs in the JVM that collect old generation objects.\njvm.gc.collectors.old.countThe total count of major GCs in the JVM that collect old generation objects.\njvm.gc.collectors.young.collection_timeThe total time spent in minor GCs in the JVM that collects young generation objects.\njvm.gc.collectors.young.countThe total count of minor GCs in the JVM that collects young generation objects.\njvm.gc.concurrent_mark_sweep.collection_timeThe total time spent on \u0026ldquo;concurrent mark \u0026amp; sweep\u0026rdquo; GCs in the JVM.\njvm.gc.concurrent_mark_sweep.countThe total count of \u0026ldquo;concurrent mark \u0026amp; sweep\u0026rdquo; GCs in the JVM.\njvm.gc.par_new.collection_timeThe total time spent on \u0026ldquo;parallel new\u0026rdquo; GCs in the JVM.\njvm.gc.par_new.countThe total count of \u0026ldquo;parallel new\u0026rdquo; GCs in the JVM.\njvm.mem.heap_committedThe amount of memory guaranteed to be available to the JVM heap.\njvm.mem.heap_in_useThe amount of memory currently used by the JVM heap as a value between 0 and 1.\njvm.mem.heap_maxThe maximum amount of memory that can be used by the JVM heap.\njvm.mem.heap_usedThe amount of memory in bytes currently used by the JVM heap.\njvm.mem.non_heap_committedThe amount of memory guaranteed to be available to JVM non-heap.\njvm.mem.non_heap_usedThe amount of memory in bytes currently used by the JVM non-heap.\njvm.mem.pools.young.usedThe amount of memory in bytes currently used by the Young Generation heap region.\njvm.mem.pools.young.maxThe maximum amount of memory that can be used by the Young Generation heap region.\njvm.mem.pools.old.usedThe amount of memory in bytes currently used by the Old Generation heap region.\njvm.mem.pools.old.maxThe maximum amount of memory that can be used by the Old Generation heap region.\njvm.mem.pools.survivor.usedThe amount of memory in bytes currently used by the Survivor Space.\njvm.mem.pools.survivor.maxThe maximum amount of memory that can be used by the Survivor Space.\njvm.threads.countThe number of active threads in the JVM.\njvm.threads.peak_countThe peak number of threads used by the JVM.\nelasticsearch.index.healthThe status of the index.\nelasticsearch.index.docs.countThe number of documents in the index.\nelasticsearch.index.docs.deletedThe number of deleted documents in the index.\nelasticsearch.index.primary_shardsThe number of primary shards in the index.\nelasticsearch.index.replica_shardsThe number of replica shards in the index.\nelasticsearch.index.primary_store_sizeThe store size of primary shards in the index.\nelasticsearch.index.store_sizeThe store size of primary and replica shards in the index.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/elasticsearch-metrics/"},{"id":552,"title":"Events","content":"OverviewIn Sysdig Monitor, an event is a record indicating a specific occurrence or change within the monitored environment, encompassing alerts, and infrastructure events, which include containers, Kubernetes, and custom events.\nClick any event to open the event detail panel on the right:\nOn the panel, you will find detailed information on the event, such as precisely when and where it occurred. Perform additional actions, such as Explore to examine the event\u0026rsquo;s origin in your infrastructure, or Create an Alert to be notified about future occurrences of this event.\nAdditionally, you can:\nExamine event details to gather context, such as the origin of an issue\nFilter the event feed by severity, to find the most urgent events.\nSearch the event feed for a particular event, such as \u0026ldquo;Container Crashing\u0026rdquo;\nCreate an alert so you will be instantly notified whenever a known issue arises.\nPrerequisitesIf you do not have Sysdig Agent installed in your environment, or you are not logged in to an account with permission to access an environment, the Events module will appear empty to you.\nTo populate the Events feed:\nInstall the Sysdig Agent.\nLog in to Sysdig Monitor and ensure that your account has permission to access the environment.\nOnce installed, the Sysdig Agent will collect certain events by default. These include Sysdig-integrated services like Kubernetes, ContainerD, and Docker. To collect events from additional sources, such as LogDNA, see Collect Event Data.\nAdministrators will be able to see events from the entire infrastructure, while members of a team will only see events from the part of infrastructure assigned to their team.\nTypes of EventsEvents are classified by type and by status. Types of Events include\nAlert Events : Generated whenever an alert rule is triggered. Alert Events indicate that a specific condition defined in an alert rule has been met. Sysdig Events : System-level events related to your Sysdig environment, such as the deactivation of an alert rule Infrastructure Events : Events that originate from your infrastructure components, including containers, Kubernetes, and Docker are classified as infrastructure events Custom Events : Events manually uploaded by users. Custom Events can be displayed in the event feed alongside other event types. See Event Types for more details.\nStatuses only apply to Alert Events. Alerts have two states and the state is conveyed by an icon.\nTriggered A ringing bell icon indicates a triggered alert. Resolved A silent bell icon indicates that it is resolved. Understand Trends Over TimeThe Trends Over Time histogram compresses the count of events based on the selected criteria. This allows for efficient analysis of events, especially when dealing with large datasets or high-frequency data streams.\nUsageHover over a section that interests you to see data for that specific type of event.\nSelect a section to pin the data. This lets you expand or collapse events.\nSelect the specific value to copy the value. You can use copied values n filters.\nTo see the color legend, select the option at the top right corner of the histogram (next to the drop-down label selector). Selecting a value from this list also applies the filter using that value.\nGroup Chart ByYou can select the label to group the events by. Sysdig offers two types of labels:\nEvent Specific Labels: These labels are specific for events Suggested Labels: Other labels that might be of interest for grouping of events Understand Events Detail PanelIn addition to visualizing events in your environment, the Events module allows you to engage directly with events. Select any event to open the Events details panel. Depending on the status of the event, various operations will be available:\nTriggering Alert Event\nAcknowledge Manually Resolve Create Silence from an event Explore (if Threshold Alert) Open in PromQL Query (if Prometheus Alert) Troubleshoot Edit Alert Resolved Alert Event\nCreate Silence from an Event Explore Triggering Event Alert\nAcknowledge Manually Resolve Create Silence from Event Resolved Event Alert\nCreate Silence from Event Non-Alert Event\nCreate Alert from Event\n","url":"https://docs.sysdig.com/en/sysdig-monitor/monitor-events/"},{"id":553,"title":"Forwarding to Kafka Topic","content":"Events are organized and durably stored in topics. In simple terms, a topic is like a folder in a filesystem, and the events are the files in that folder.\nPrerequisitesThis integration is available for Sysdig On-Premises or through Agent Local Forwarding only.\nConfigure Standard IntegrationTo forward secure data to Kafka:\nLog in to Sysdig Secure On-Prem as Admin.\nFrom the user menu on the bottom left, go to Integrations \u0026gt; Add Integrations.\nSearch and choose Kafka topic from the drop-down.\nConfigure the required options:\nIntegration Name: Define an integration name.\nBrokers: Kafka server endpoints. A Kafka cluster may provide several brokers; it follows the \u0026ldquo;hostname: port\u0026rdquo; (without protocol scheme). You can list several using a comma-separated list.\nTopic: Kafka topic where you want to store the forwarded data\nPartitioner/Balancer: Algorithm that the client uses to multiplex data between the multiple Brokers. For compatibility with the Java client, Murmur2 is used as the default partitioner. Supported algorithms are:\nMurmur2\nRound robin\nLeast bytes\nHash\nCRC32\nCompression: Compression standard used for the data. Supported algorithms are:\nLZ4\nSnappy\nGzip\nStandard\nAuthentication: The authentication method to adopt. Supported methods are:\nNone\nKerberos (GSSAPI). If you select this, you must provide the:\nPrincipal Realm Service And the following files:\nKeytab krb5.conf SASL/PLAIN. If you select this, you must provide:\nUsername Password SASL/SCRAM. If you select this, you must provide:\nAlgorithm, choosing between SHA-256 and SHA-512 Username Password Data to Send: Select from the drop-down the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled.\nSelect whether or not you want to allow insecure connections. Insecure connections have invalid or self-signed certificate on the receiving side.\nSelect Test Integration.\nToggle the enable switch as necessary\nClick Save.\nConfigure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description KAFKA brokers yes string KAFKA topic yes string KAFKA compression no string lz4, snappy, zstd, gzip KAFKA balancer no string roundrobin, leastbytes, hash, crc32, murmur2 murmur2 KAFKA tls no bool false KAFKA insecure no bool false Doesn’t verify TLS certificate KAFKA auth no string gssapi, sasl/plain, sasl/scram The authentication method to optionally use. Currently supporting GSSAPI, SASL/PLAIN and SASL/SCRAM KAFKA principal no string GSSAPI principal. Required is GSSAPI authentication is selected KAFKA realm no string GSSAPI realm. Required is GSSAPI authentication is selected KAFKA service no string GSSAPI Service name. Required is GSSAPI authentication is selected KAFKA keytab no string base64 encoded Kerberos keytab for GSSAPI. Required is GSSAPI authentication is selected KAFKA krb5 no string Kerberos krb5.conf file content for GSSAPI. Required is GSSAPI authentication is selected KAFKA algorithm no string sha256, sha512 SASL/SCRAM hashing algorithm KAFKA username no string SASL username KAFKA password no string SASL password ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forwarding-to-kafka-topic/"},{"id":554,"title":"Configure Google Workspace for SAML","content":"Prerequisites Review SAML (SaaS). Configure Sysdig Monitor or Sysdig Secure, or both as a SAML application using Google Workspace\u0026rsquo;s documentation: Set up your own custom SAML application. The notes below call out specific steps that require additional action.\nSysdig-Specific Configuration for Google WorkspaceConfigure User accessSet up user access permissions according to your organization\u0026rsquo;s requirements.\nSpecify Service Provider DetailsEnter the values shown in the table below. If you wish to configure IdP-initiated login flow, replace CUSTOMER-ID-NUMBER with the number retrieved as described in Find Your Customer Number.\nSee SaaS Regions and IP Ranges and identify the correct URLs associated with your Sysdig application and region. For example, in US East, the endpoints are:\nSetting Value for Sysdig Monitor Value for Sysdig Secure ACS URL \u0026lt;REGION_URL\u0026gt;/api/saml/auth \u0026lt;REGION_URL\u0026gt;/api/saml/secureAuth Entity ID \u0026lt;REGION_URL\u0026gt; \u0026lt;REGION_URL\u0026gt; Start URL #/\u0026amp;customer=\u0026lt;CUSTOMER_ID\u0026gt; #/\u0026amp;customer=\u0026lt;CUSTOMER_ID\u0026gt; If an integration name is defined, or if multiple integrations are used, add the integration name to the Start URL parameter in the following format \u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;, so it becomes #/\u0026amp;customer=\u0026lt;CUSTOMER-ID-NUMBER\u0026gt;\u0026amp;integrationName=\u0026lt;INTEGRATION_NAME\u0026gt;.\nReplace \u0026lt;REGION_URL\u0026gt; with the region URL where your Sysdig application is hosted. For example, for Sysdig Monitor in the EU, you use https://eu1.app.sysdig.com.\nSpecify SAML Attribute MappingConfigure the following:\nGoogle Directory attributes App attributes Primary email email First name first name Last name last name Note that the attributes are case sensitive, so use caution when entering them.\nOnly email is required. However, including first and last names is recommended since these values will now be included in the records created in the Sysdig platform\u0026rsquo;s database when new users successfully log in via SAML for the first time.\nConfigure SysdigTo configure Sysdig for Google Workspace:\nLog in to Sysdig Platform.\nNavigate to Settings via the user menu icon at the bottom of the left navigation bar.\nUnder Access \u0026amp; Secrets, select Authentication (SSO).\nEdit existing or create a new SSO integration (type: SAML).\nCopy the URL and paste it into the Metadata entry on the SAML Configuration page in the SAML connection settings.\nFor Email Parameter, write email.\nThe rest of the fields and toggles can be left as default.\nSelect Save Settings.\nEnable the integration by selecting the option from the Enabled column in the integration\n(Optional) Test SAML LoginTo ensure the IdP flow works, you can perform a test login from your browser. Ensure the selected user has access to the Sysdig application you have configured.\n","url":"https://docs.sysdig.com/en/administration/google-workspace-saml/"},{"id":555,"title":"Group Mapping Settings API","content":"You can configure Group Mappings behavior in the following scenarios:\nWhen a user has no groups assigned When a user has several conflicting groups assigned PrerequisitesRetrieve the Sysdig API Token from the Sysdig UI to use with the API.\nReplace the API_TOKEN with your API token in the API calls given below.\nRetrieve Existing Group MappingsTo retrieve all the Group Mappings for your Sysdig instance, issue a curl GET request against the Sysdig Monitor endpoint.\nRequest Bodycurl -X GET -H \u0026#39;Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;\u0026#39; https://\u0026lt;HOSTNAME\u0026gt;/api/groupmappings Replace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;HOSTNAME\u0026gt; with the Sysdig domain associated with your region. Sample ResponseThe output will provide a list of Group Mappings in the response:\n{ \u0026#34;groupMappings\u0026#34;: [ { \u0026#34;id\u0026#34;: 2136, \u0026#34;groupName\u0026#34;: \u0026#34;GroupOne\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;ROLE_TEAM_STANDARD\u0026#34;, \u0026#34;systemRole\u0026#34;: \u0026#34;ROLE_USER\u0026#34;, \u0026#34;teamMap\u0026#34;: { \u0026#34;allTeams\u0026#34;: false, \u0026#34;teamIds\u0026#34;: [ 20008990 ] }, \u0026#34;weight\u0026#34;: 32767 }, { \u0026#34;id\u0026#34;: 2137, \u0026#34;groupName\u0026#34;: \u0026#34;GroupTwo\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;ROLE_TEAM_EDIT\u0026#34;, \u0026#34;systemRole\u0026#34;: \u0026#34;ROLE_USER\u0026#34;, \u0026#34;teamMap\u0026#34;: { \u0026#34;allTeams\u0026#34;: false, \u0026#34;teamIds\u0026#34;: [ 20008990 ] }, \u0026#34;weight\u0026#34;: 32767 } ] } Retrieve Settings for the Existing Group MappingsTo retrieve settings for the Group Mapping associated with your Sysdig instance, issue a curl GET request against the Sysdig Monitor endpoint.\nRequest Bodycurl -X GET -H \u0026#39;Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;\u0026#39; https://\u0026lt;HOSTNAME\u0026gt;/api/groupmappings/settings Replace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;HOSTNAME\u0026gt; with the Sysdig domain associated with your region. Sample ResponseThe output provides Group Mapping settings in the response.\n{ \u0026#34;noMappingStrategy\u0026#34;: \u0026#34;UNAUTHORIZED\u0026#34;, \u0026#34;differentRolesSameTeamStrategy\u0026#34;: \u0026#34;UNAUTHORIZED\u0026#34; } If you have not already configured Group Mappings, the response will be “Not Found” with a status 404. This is normal, and will change after you configure the behavior for the first time. For the default behavior, see Group Mapping behavior.\nChange Group Mapping SettingsTo change the Group Mapping settings, issue a curl PUT request against the Sysdig endpoint:\nRequest Bodycurl -XPUT -H \u0026#39;Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;\u0026#39; -d \u0026lt;PAYLOAD\u0026gt; https://\u0026lt;HOSTNAME\u0026gt;/api/groupmappings/settings Replace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved. \u0026lt;HOSTNAME\u0026gt; with the Sysdig domain associated with your region. Query Parameters` contains the strategies for the configurable options.\nSee Group Mapping Configuration for more information.\ndifferentRolesSameTeamStrategy: Determines which behavior to use when several groups exist placing the user in the same team with a different role. UNAUTHORIZED: Users will not be able to log in FIRST_MATCH: If conflicts are found, the first group mapping that matches is processed, no further group mapping is processed. WEIGHTED: If weight is defined, weight information is used to resolve the conflict and place the user in the team with the correct role. The resolution is global, this option does not process team level conflicts. WEIGHTED_BY_TEAM: Similar to WEIGHTED, but conflicts are resolved on the team level, not globally. noMappingStrategy: Determines which behavior to use when the user has no groups mapped. UNAUTHORIZED: Users will not be able to login. DEFAULT_TEAM_DEFAULT_ROLE: Users will be able to login and will be placed in the default team with the default role. NO_MAPPINGS_ERROR_REDIRECT: Users will not be able to login and will be redirected to a URL specified in noMappingsErrorRedirectURL. Make sure the URL is set and valid before using this option. noMappingsErrorRedirectURL: The URL to send the users to if noMappingStrategy is configured as NO_MAPPINGS_ERROR_REDIRECT. Please note that no validation of the redirect URL is performed. Sample PayloadStructure the payload as follows: ```json '{ // Options: \u0026quot;UNAUTHORIZED\u0026quot;, \u0026quot;FIRST_MATCH\u0026quot;, \u0026quot;WEIGHTED\u0026quot;, \u0026quot;WEIGHTED_BY_TEAM\u0026quot; \u0026quot;differentRolesSameTeamStrategy\u0026quot;: \u0026quot;UNAUTHORIZED\u0026quot;, // Options: \u0026quot;UNAUTHORIZED\u0026quot;, \u0026quot;DEFAULT_TEAM_DEFAULT_ROLE\u0026quot;, \u0026quot;NO_MAPPINGS_ERROR_REDIRECT\u0026quot; \u0026quot;noMappingStrategy\u0026quot;: \u0026quot;UNAUTHORIZED\u0026quot;, // Options: Redirect URL (optional) \u0026quot;noMappingsErrorRedirectURL\u0026quot;: \u0026quot;\u0026quot; }' ``` Sample ResponseIf successful, the output matches the configuration you sent.\n{ \u0026#34;noMappingStrategy\u0026#34;: \u0026#34;UNAUTHORIZED\u0026#34;, \u0026#34;differentRolesSameTeamStrategy\u0026#34;: \u0026#34;UNAUTHORIZED\u0026#34;, \u0026#34;noMappingsErrorRedirectURL\u0026#34;: \u0026#34;\u0026#34; } Change Specific Group Mapping by IDTo change specific Group Mapping based on the ID, issue a curl PUT request against the Sysdig endpoint:\nRequest Body curl -XPUT -H \u0026#39;Authorization: Bearer \u0026lt;API_TOKEN\u0026gt;\u0026#39; -d \u0026lt;PAYLOAD\u0026gt; https://\u0026lt;HOSTNAME\u0026gt;/api/groupmappings/\u0026lt;GROUP_MAPPING_ID\u0026gt; Replace the following:\n\u0026lt;API_TOKEN\u0026gt; with the token you retrieved.\n\u0026lt;HOSTNAME\u0026gt; with the Sysdig domain associated with your region.\n\u0026lt;GROUP_MAPPING_ID\u0026gt; with the ID of the Group Mapping you want to alter. See Retrieve Existing Group Mappings.\n\u0026lt;PAYLOAD\u0026gt; contains Group Mapping that overwrites the existing Group Mapping for a given Group Mapping ID.\nweight can be between 1 and 32767. The lower the weight, the higher the mapping priority. For more information, see Group Mapping.\nSample PayloadStructure the payload as follows: ```json '{ \u0026quot;id\u0026quot;: \u0026lt;GROUP_MAPPING_ID\u0026gt;, \u0026quot;groupName\u0026quot;: \u0026quot;GroupOne\u0026quot;, \u0026quot;role\u0026quot;: \u0026quot;ROLE_TEAM_STANDARD\u0026quot;, \u0026quot;systemRole\u0026quot;: \u0026quot;ROLE_USER\u0026quot;, \u0026quot;teamMap\u0026quot;: { \u0026quot;allTeams\u0026quot;: false, \u0026quot;teamIds\u0026quot;: [ 20008990 ] }, \u0026quot;weight\u0026quot;: 32767 }' ``` Sample ResponseIf successful, the output matches the configuration that was sent.\n{ \u0026#34;id\u0026#34;: 2136, \u0026#34;groupName\u0026#34;: \u0026#34;GroupOne\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;ROLE_TEAM_STANDARD\u0026#34;, \u0026#34;systemRole\u0026#34;: \u0026#34;ROLE_USER\u0026#34;, \u0026#34;teamMap\u0026#34;: { \u0026#34;allTeams\u0026#34;: false, \u0026#34;teamIds\u0026#34;: [ 20008990 ] }, \u0026#34;weight\u0026#34;: 32767 } ","url":"https://docs.sysdig.com/en/developer-tools/group-mapping-api/"},{"id":556,"title":"Groups","content":" Deprecation Notice Upcoming Changes to Sysdig Product Line\nThe legacy Identity pages are now deprecated and will be phased out over a transition period. During this time, both the legacy and new experiences will remain available. We encourage you to start using the new Identity Overview and Findings pages to become familiar with the updated experience.\nSysdig recommends creating Groups of user accounts and assigning permissions at the Group level rather than the individual User account level to facilitate administration tasks.\nFilter and Sort GroupsUse the sortable columns to organize and filter Groups for assessing identity risks. You can sort groups based on the following criteria:\nUnused Permission CriticalityUnused Permission Criticality focuses on unused permissions, while Permission Criticality looks at all permissions. Unused Permission Criticality is designed to help you achieve Least Permissive access.\nValues: Critical, High, Medium, Low\nRiskThis is a calculation of risk based on all permissions. See Understanding Risk Scoring for more information.\nValues: Critical, High, Medium, Low\n% of Unused PermissionsThis shows the number of unused permissions per total permissions for the group, shown as a percentage graph.\nWhen remediating, immediately target the groups with the greatest exposure and refine them according to the suggestions.\nMembershipThe number of users who are part of this group.\nHighest AccessValues:\nAdmin: Admin access granted Write: Write access granted Read: Read access granted Empty Access: No permissions are granted at all See Understand Highest Access.\nFindingsA finding in Cloud Infrastructure Entitlement Management (CIEM) indicates poor security hygiene, either due to misconfiguration or inadequate identity security practices. The findings on Groups page include:\nAdmin Inactive Available Filters Search: Free text search on terms in the resource name Platform: by provider. For example, AWS Unused Permission Criticality: By severity Cloud Accounts: Account name/number by cloud provider. For example, GCP Access Categories: Admin, Write, Read, or Empty Access Findings: Admin , Inactive Next Steps Optimize AWS Group Entitlements Optimize GCP Group Entitlements Optimize Azure Group Entitlements ","url":"https://docs.sysdig.com/en/sysdig-secure/groups/"},{"id":557,"title":"Host","content":"sysdig_host_container_count Prometheus ID sysdig_host_container_count Legacy ID container.count Metric Type gauge Unit number Description Count of the number of containers. Additional Notes This metric is perfect for dashboards and alerts. In particular, you can create alerts that notify you when you have too many (or too few) containers of a certain type in a certain group or node - try segmenting by container.image, .id or .name. See also: host.count. sysdig_host_container_start_count Prometheus ID sysdig_host_container_start_count Legacy ID host.container.start.count Metric Type counter Unit number Description Additional Notes sysdig_host_count Prometheus ID sysdig_host_count Legacy ID host.count Metric Type gauge Unit number Description Count of the number of hosts. Additional Notes This metric is perfect for dashboards and alerts. In particular, you can create alerts that notify you when you have too many (or too few) machines of a certain type in a certain group - try segment by tag or hostname. See also: container.count. sysdig_host_cpu_cores_used Prometheus ID sysdig_host_cpu_cores_used Legacy ID cpu.cores.used Metric Type gauge Unit number Description Additional Notes sysdig_host_cpu_cores_total Prometheus ID sysdig_host_cpu_cores_total Legacy ID cpu.cores.total Metric Type gauge Unit number Description Additional Notes sysdig_host_cpu_cores_used_percent Prometheus ID sysdig_host_cpu_cores_used_percent Legacy ID cpu.cores.used.percent Metric Type gauge Unit percent Description Additional Notes sysdig_host_cpu_idle_percent Prometheus ID sysdig_host_cpu_idle_percent Legacy ID cpu.idle.percent Metric Type gauge Unit percent Description Percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_cpu_iowait_percent Prometheus ID sysdig_host_cpu_iowait_percent Legacy ID cpu.iowait.percent Metric Type gauge Unit percent Description Percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_cpu_nice_percent Prometheus ID sysdig_host_cpu_nice_percent Legacy ID cpu.nice.percent Metric Type gauge Unit percent Description Percentage of CPU utilization that occurred while executing at the user level with nice priority. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_cpu_stolen_percent Prometheus ID sysdig_host_cpu_stolen_percent Legacy ID cpu.stolen.percent Metric Type gauge Unit percent Description CPU steal time is a measure of the percent of time that a virtual machine\u0026rsquo;s CPU is in a state of involuntary wait due to the fact that the physical CPU is shared among virtual machines. In calculating steal time, the operating system kernel detects when it has work available but does not have access to the physical CPU to perform that work. Additional Notes If the percent of steal time is consistently high, you may want to stop and restart the instance (since it will most likely start on different physical hardware) or upgrade to a virtual machine with more CPU power. Also see the metric \u0026lsquo;capacity total percent\u0026rsquo; to see how steal time directly impacts the number of server requests that could not be handled. On AWS EC2, steal time does not depend on the activity of other virtual machine neighbours. EC2 is simply making sure your instance is not using more CPU cycles than paid for. sysdig_host_cpu_system_percent Prometheus ID sysdig_host_cpu_system_percent Legacy ID cpu.system.percent Metric Type gauge Unit percent Description Percentage of CPU utilization that occurred while executing at the system level (kernel). Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_cpu_used_percent Prometheus ID sysdig_host_cpu_used_percent Legacy ID cpu.used.percent Metric Type gauge Unit percent Description The CPU usage for each container is obtained from cgroups, and normalized by dividing by the number of cores to determine an overall percentage. For example, if the environment contains six cores on a host, and the container or processes are assigned two cores, Sysdig will report CPU usage of 2/6 * 100% = 33.33%. This metric is calculated differently for hosts and processes. Additional Notes sysdig_host_cpu_user_percent Prometheus ID sysdig_host_cpu_user_percent Legacy ID cpu.user.percent Metric Type gauge Unit percent Description Percentage of CPU utilization that occurred while executing at the user level (application). Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_cpucore_idle_percent Prometheus ID sysdig_host_cpucore_idle_percent Legacy ID cpucore.idle.percent Metric Type gauge Unit percent Description Additional Notes sysdig_host_cpucore_iowait_percent Prometheus ID sysdig_host_cpucore_iowait_percent Legacy ID cpucore.iowait.percent Metric Type gauge Unit percent Description Additional Notes sysdig_host_cpucore_nice_percent Prometheus ID sysdig_host_cpucore_nice_percent Legacy ID cpucore.nice.percent Metric Type gauge Unit percent Description Additional Notes sysdig_host_cpucore_stolen_percent Prometheus ID sysdig_host_cpucore_stolen_percent Legacy ID cpucore.stolen.percent Metric Type gauge Unit percent Description Additional Notes sysdig_host_cpucore_system_percent Prometheus ID sysdig_host_cpucore_system_percent Legacy ID cpucore.system.percent Metric Type gauge Unit percent Description Additional Notes sysdig_host_cpucore_used_percent Prometheus ID sysdig_host_cpucore_used_percent Legacy ID cpucore.used.percent Metric Type gauge Unit percent Description Additional Notes sysdig_host_cpucore_user_percent Prometheus ID sysdig_host_cpucore_user_percent Legacy ID cpucore.user.percent Metric Type gauge Unit percent Description Additional Notes sysdig_host_fd_used_percent Prometheus ID sysdig_host_fd_used_percent Legacy ID fd.used.percent Metric Type gauge Unit percent Description Percentage of used file descriptors out of the maximum available. Additional Notes Usually, when a process reaches its FD limit it will stop operating properly and possibly crash. As a consequence, this is a metric you want to monitor carefully, or even better use for alerts. sysdig_host_file_error_open_count Prometheus ID sysdig_host_file_error_open_count Legacy ID file.error.open.count Metric Type counter Unit number Description Number of errors in opening files. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_file_error_total_count Prometheus ID sysdig_host_file_error_total_count Legacy ID file.error.total.count Metric Type counter Unit number Description Number of error caused by file access. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_file_in_bytes Prometheus ID sysdig_host_file_in_bytes Legacy ID file.bytes.in Metric Type counter Unit data Description Amount of bytes read from file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_file_in_iops Prometheus ID sysdig_host_file_in_iops Legacy ID file.iops.in Metric Type counter Unit number Description Number of file read operations per second. Additional Notes This is calculated by measuring the actual number of read and write requests made by a process. Therefore, it can differ from what other tools show, which is usually based on interpolating this value from the number of bytes read and written to the file system. sysdig_host_file_in_time Prometheus ID sysdig_host_file_in_time Legacy ID file.time.in Metric Type counter Unit time Description Time spent in file reading. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_file_open_count Prometheus ID sysdig_host_file_open_count Legacy ID file.open.count Metric Type counter Unit number Description Number of time the file has been opened. Additional Notes sysdig_host_file_out_bytes Prometheus ID sysdig_host_file_out_bytes Legacy ID file.bytes.out Metric Type counter Unit data Description Amount of bytes written to file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_file_out_iops Prometheus ID sysdig_host_file_out_iops Legacy ID file.iops.out Metric Type counter Unit number Description Number of file write operations per second. Additional Notes This is calculated by measuring the actual number of read and write requests made by a process. Therefore, it can differ from what other tools show, which is usually based on interpolating this value from the number of bytes read and written to the file system. sysdig_host_file_out_time Prometheus ID sysdig_host_file_out_time Legacy ID file.time.out Metric Type counter Unit time Description Time spent in file writing. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_file_total_bytes Prometheus ID sysdig_host_file_total_bytes Legacy ID file.bytes.total Metric Type counter Unit data Description Amount of bytes read from and written to file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_file_total_iops Prometheus ID sysdig_host_file_total_iops Legacy ID file.iops.total Metric Type counter Unit number Description Number of read and write file operations per second. Additional Notes This is calculated by measuring the actual number of read and write requests made by a process. Therefore, it can differ from what other tools show, which is usually based on interpolating this value from the number of bytes read and written to the file system. sysdig_host_file_total_time Prometheus ID sysdig_host_file_total_time Legacy ID file.time.total Metric Type counter Unit time Description Time spent in file I/O. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_fs_free_bytes Prometheus ID sysdig_host_fs_free_bytes Legacy ID fs.bytes.free Metric Type gauge Unit data Description Filesystem available space. Additional Notes sysdig_host_fs_free_percent Prometheus ID sysdig_host_fs_free_percent Legacy ID fs.free.percent Metric Type gauge Unit percent Description Percentage of filesystem free space. Additional Notes sysdig_host_fs_inodes_total_count Prometheus ID sysdig_host_fs_inodes_total_count Legacy ID fs.inodes.total.count Metric Type gauge Unit number Description Additional Notes sysdig_host_fs_inodes_used_count Prometheus ID sysdig_host_fs_inodes_used_count Legacy ID fs.inodes.used.count Metric Type gauge Unit number Description Additional Notes sysdig_host_fs_inodes_used_percent Prometheus ID sysdig_host_fs_inodes_used_percent Legacy ID fs.inodes.used.percent Metric Type gauge Unit percent Description Additional Notes sysdig_host_fs_largest_used_percent Prometheus ID sysdig_host_fs_largest_used_percent Legacy ID fs.largest.used.percent Metric Type gauge Unit percent Description Percentage of the largest filesystem in use. Additional Notes sysdig_host_fs_root_used_percent Prometheus ID sysdig_host_fs_root_used_percent Legacy ID fs.root.used.percent Metric Type gauge Unit percent Description Percentage of the root filesystem in use. Additional Notes sysdig_host_fs_total_bytes Prometheus ID sysdig_host_fs_total_bytes Legacy ID fs.bytes.total Metric Type gauge Unit data Description Filesystem size. Additional Notes sysdig_host_fs_used_bytes Prometheus ID sysdig_host_fs_used_bytes Legacy ID fs.bytes.used Metric Type gauge Unit data Description Filesystem used space. Additional Notes sysdig_host_fs_used_percent Prometheus ID sysdig_host_fs_used_percent Legacy ID fs.used.percent Metric Type gauge Unit percent Description Percentage of the sum of all filesystems in use. Additional Notes sysdig_host_info Prometheus ID sysdig_host_info Legacy ID info Metric Type gauge Unit number Description Additional Notes sysdig_host_load_average_15m Prometheus ID sysdig_host_load_average_15m Legacy ID load.average.15m Metric Type gauge Unit number Description The 15 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 15 minutes for all cores. The value should correspond to the third (and last) load average value displayed by \u0026lsquo;uptime\u0026rsquo; command. Additional Notes sysdig_host_load_average_1m Prometheus ID sysdig_host_load_average_1m Legacy ID load.average.1m Metric Type gauge Unit number Description The 1 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 1 minute for all cores. The value should correspond to the first (of three) load average values displayed by \u0026lsquo;uptime\u0026rsquo; command. Additional Notes sysdig_host_load_average_5m Prometheus ID sysdig_host_load_average_5m Legacy ID load.average.5m Metric Type gauge Unit number Description The 5 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 5 minutes for all cores. The value should correspond to the second (of three) load average values displayed by \u0026lsquo;uptime\u0026rsquo; command. Additional Notes sysdig_host_load_average_percpu_15m Prometheus ID sysdig_host_load_average_percpu_15m Legacy ID load.average.percpu.15m Metric Type gauge Unit number Description The 15 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 15 minutes, divided by number of system CPUs. Additional Notes sysdig_host_load_average_percpu_1m Prometheus ID sysdig_host_load_average_percpu_1m Legacy ID load.average.percpu.1m Metric Type gauge Unit number Description The 1 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 1 minute, divided by number of system CPUs. Additional Notes sysdig_host_load_average_percpu_5m Prometheus ID sysdig_host_load_average_percpu_5m Legacy ID load.average.percpu.5m Metric Type gauge Unit number Description The 5 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 5 minutes, divided by number of system CPUs. Additional Notes sysdig_host_memory_available_bytes Prometheus ID sysdig_host_memory_available_bytes Legacy ID memory.bytes.available Metric Type gauge Unit data Description The available memory for a host is obtained from /proc/meminfo. For environments using Linux kernel version 3.12 and later, the available memory is obtained using the mem.available field in /proc/meminfo. For environments using earlier kernel versions, the formula is MemFree + Cached + Buffers. Additional Notes sysdig_host_memory_swap_available_bytes Prometheus ID sysdig_host_memory_swap_available_bytes Legacy ID memory.swap.bytes.available Metric Type gauge Unit data Description Available amount of swap memory. Additional Notes Sum of free and cached swap memory. By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_memory_swap_total_bytes Prometheus ID sysdig_host_memory_swap_total_bytes Legacy ID memory.swap.bytes.total Metric Type gauge Unit data Description Total amount of swap memory. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_memory_swap_used_bytes Prometheus ID sysdig_host_memory_swap_used_bytes Legacy ID memory.swap.bytes.used Metric Type gauge Unit data Description Used amount of swap memory. Additional Notes The amount of used swap memory is calculated by subtracting available from total swap memory. By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_memory_swap_used_percent Prometheus ID sysdig_host_memory_swap_used_percent Legacy ID memory.swap.used.percent Metric Type gauge Unit percent Description Used percent of swap memory. Additional Notes The percentage of used swap memory is calculated as percentual ratio of used and total swap memory. By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_memory_total_bytes Prometheus ID sysdig_host_memory_total_bytes Legacy ID memory.bytes.total Metric Type gauge Unit data Description The total memory of a host, in bytes. This value is obtained from /proc. Additional Notes sysdig_host_memory_used_bytes Prometheus ID sysdig_host_memory_used_bytes Legacy ID memory.bytes.used Metric Type gauge Unit data Description The amount of physical memory currently in use. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_memory_used_percent Prometheus ID sysdig_host_memory_used_percent Legacy ID memory.used.percent Metric Type gauge Unit percent Description The percentage of physical memory in use. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_memory_virtual_bytes Prometheus ID sysdig_host_memory_virtual_bytes Legacy ID memory.bytes.virtual Metric Type gauge Unit data Description The virtual memory size of the process, in bytes. This value is obtained from Sysdig events. Additional Notes sysdig_host_net_connection_in_count Prometheus ID sysdig_host_net_connection_in_count Legacy ID net.connection.count.in Metric Type counter Unit number Description Number of currently established client (inbound) connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_host_net_connection_out_count Prometheus ID sysdig_host_net_connection_out_count Legacy ID net.connection.count.out Metric Type counter Unit number Description Number of currently established server (outbound) connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_host_net_connection_total_count Prometheus ID sysdig_host_net_connection_total_count Legacy ID net.connection.count.total Metric Type counter Unit number Description Number of currently established connections. This value may exceed the sum of the inbound and outbound metrics since it represents client and server inter-host connections as well as internal only connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_host_net_error_count Prometheus ID sysdig_host_net_error_count Legacy ID net.error.count Metric Type counter Unit number Description Number of network-related system calls that returned an error from the kernel in one second. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_net_http_error_count Prometheus ID sysdig_host_net_http_error_count Legacy ID net.http.error.count Metric Type counter Unit number Description Number of failed HTTP requests as counted from 4xx/5xx status codes. Additional Notes sysdig_host_net_http_request_count Prometheus ID sysdig_host_net_http_request_count Legacy ID net.http.request.count Metric Type counter Unit number Description Count of HTTP requests. Additional Notes sysdig_host_net_http_request_time Prometheus ID sysdig_host_net_http_request_time Legacy ID net.http.request.time Metric Type counter Unit time Description Average time for HTTP requests. Additional Notes sysdig_host_net_http_statuscode_error_count Prometheus ID sysdig_host_net_http_statuscode_error_count Legacy ID net.http.statuscode.error.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_http_statuscode_request_count Prometheus ID sysdig_host_net_http_statuscode_request_count Legacy ID net.http.statuscode.request.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_http_url_error_count Prometheus ID sysdig_host_net_http_url_error_count Legacy ID net.http.url.error.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_http_url_request_count Prometheus ID sysdig_host_net_http_url_request_count Legacy ID net.http.url.request.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_http_url_request_time Prometheus ID sysdig_host_net_http_url_request_time Legacy ID net.http.url.request.time Metric Type counter Unit time Description Additional Notes sysdig_host_net_mongodb_collection_error_count Prometheus ID sysdig_host_net_mongodb_collection_error_count Legacy ID net.mongodb.collection.error.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_mongodb_collection_request_count Prometheus ID sysdig_host_net_mongodb_collection_request_count Legacy ID net.mongodb.collection.request.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_mongodb_collection_request_time Prometheus ID sysdig_host_net_mongodb_collection_request_time Legacy ID net.mongodb.collection.request.time Metric Type counter Unit time Description Additional Notes sysdig_host_net_mongodb_error_count Prometheus ID sysdig_host_net_mongodb_error_count Legacy ID net.mongodb.error.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_mongodb_operation_error_count Prometheus ID sysdig_host_net_mongodb_operation_error_count Legacy ID net.mongodb.operation.error.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_mongodb_operation_request_count Prometheus ID sysdig_host_net_mongodb_operation_request_count Legacy ID net.mongodb.operation.request.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_mongodb_operation_request_time Prometheus ID sysdig_host_net_mongodb_operation_request_time Legacy ID net.mongodb.operation.request.time Metric Type counter Unit time Description Additional Notes sysdig_host_net_mongodb_request_count Prometheus ID sysdig_host_net_mongodb_request_count Legacy ID net.mongodb.request.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_mongodb_request_time Prometheus ID sysdig_host_net_mongodb_request_time Legacy ID net.mongodb.request.time Metric Type counter Unit time Description Additional Notes sysdig_host_net_in_bytes Prometheus ID sysdig_host_net_in_bytes Legacy ID net.bytes.in Metric Type counter Unit data Description Inbound network bytes. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_net_out_bytes Prometheus ID sysdig_host_net_out_bytes Legacy ID net.bytes.out Metric Type counter Unit data Description Outbound network bytes. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_net_request_count Prometheus ID sysdig_host_net_request_count Legacy ID net.request.count Metric Type counter Unit number Description Total number of network requests. Note, this value may exceed the sum of inbound and outbound requests, because this count includes requests over internal connections. Additional Notes sysdig_host_net_request_in_count Prometheus ID sysdig_host_net_request_in_count Legacy ID net.request.count.in Metric Type counter Unit number Description Number of inbound network requests. Additional Notes sysdig_host_net_request_in_time Prometheus ID sysdig_host_net_request_in_time Legacy ID net.request.time.in Metric Type counter Unit time Description Average time to serve an inbound request. Additional Notes sysdig_host_net_request_out_count Prometheus ID sysdig_host_net_request_out_count Legacy ID net.request.count.out Metric Type counter Unit number Description Number of outbound network requests. Additional Notes sysdig_host_net_request_out_time Prometheus ID sysdig_host_net_request_out_time Legacy ID net.request.time.out Metric Type counter Unit time Description Average time spent waiting for an outbound request. Additional Notes sysdig_host_net_request_time Prometheus ID sysdig_host_net_request_time Legacy ID net.request.time Metric Type counter Unit time Description Average time to serve a network request. Additional Notes sysdig_host_net_server_connection_in_count Prometheus ID sysdig_host_net_server_connection_in_count Legacy ID net.server.connection.count.in Metric Type counter Unit number Description Additional Notes sysdig_host_net_server_in_bytes Prometheus ID sysdig_host_net_server_in_bytes Legacy ID net.server.bytes.in Metric Type counter Unit data Description Additional Notes sysdig_host_net_server_out_bytes Prometheus ID sysdig_host_net_server_out_bytes Legacy ID net.server.bytes.out Metric Type counter Unit data Description Additional Notes sysdig_host_net_server_total_bytes Prometheus ID sysdig_host_net_server_total_bytes Legacy ID net.server.bytes.total Metric Type counter Unit data Description Additional Notes sysdig_host_net_sql_error_count Prometheus ID sysdig_host_net_sql_error_count Legacy ID net.sql.error.count Metric Type counter Unit number Description Number of Failed SQL requests. Additional Notes sysdig_host_net_sql_query_error_count Prometheus ID sysdig_host_net_sql_query_error_count Legacy ID net.sql.query.error.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_sql_query_request_count Prometheus ID sysdig_host_net_sql_query_request_count Legacy ID net.sql.query.request.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_sql_query_request_time Prometheus ID sysdig_host_net_sql_query_request_time Legacy ID net.sql.query.request.time Metric Type counter Unit time Description Additional Notes sysdig_host_net_sql_querytype_error_count Prometheus ID sysdig_host_net_sql_querytype_error_count Legacy ID net.sql.querytype.error.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_sql_querytype_request_count Prometheus ID sysdig_host_net_sql_querytype_request_count Legacy ID net.sql.querytype.request.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_sql_querytype_request_time Prometheus ID sysdig_host_net_sql_querytype_request_time Legacy ID net.sql.querytype.request.time Metric Type counter Unit time Description Additional Notes sysdig_host_net_sql_request_count Prometheus ID sysdig_host_net_sql_request_count Legacy ID net.sql.request.count Metric Type counter Unit number Description Number of SQL requests. Additional Notes sysdig_host_net_sql_request_time Prometheus ID sysdig_host_net_sql_request_time Legacy ID net.sql.request.time Metric Type counter Unit time Description Average time to complete a SQL request. Additional Notes sysdig_host_net_sql_table_error_count Prometheus ID sysdig_host_net_sql_table_error_count Legacy ID net.sql.table.error.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_sql_table_request_count Prometheus ID sysdig_host_net_sql_table_request_count Legacy ID net.sql.table.request.count Metric Type counter Unit number Description Additional Notes sysdig_host_net_sql_table_request_time Prometheus ID sysdig_host_net_sql_table_request_time Legacy ID net.sql.table.request.time Metric Type counter Unit time Description Additional Notes sysdig_host_net_tcp_queue_len Prometheus ID sysdig_host_net_tcp_queue_len Legacy ID net.tcp.queue.len Metric Type counter Unit number Description Length of the TCP request queue. Additional Notes sysdig_host_net_total_bytes Prometheus ID sysdig_host_net_total_bytes Legacy ID net.bytes.total Metric Type counter Unit data Description Total network bytes, inbound and outbound. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_proc_count Prometheus ID sysdig_host_proc_count Legacy ID proc.count Metric Type counter Unit number Description Number of processes on host or container. Additional Notes sysdig_host_syscall_count Prometheus ID sysdig_host_syscall_count Legacy ID syscall.count Metric Type gauge Unit number Description Total number of syscalls seen Additional Notes Syscalls are resource intensive. This metric tracks how many have been made by a given process or container sysdig_host_syscall_error_count Prometheus ID sysdig_host_syscall_error_count Legacy ID host.error.count Metric Type counter Unit number Description Number of system call errors. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_host_system_uptime Prometheus ID sysdig_host_system_uptime Legacy ID system.uptime Metric Type gauge Unit time Description This metric is sent by the agent and represent the amount of seconds since host boot time. Additional Notes sysdig_host_thread_count Prometheus ID sysdig_host_thread_count Legacy ID thread.count Metric Type counter Unit number Description Additional Notes sysdig_host_timeseries_count_appcheck Prometheus ID sysdig_host_timeseries_count_appcheck Legacy ID metricCount.appCheck Metric Type gauge Unit number Description Additional Notes sysdig_host_timeseries_count_jmx Prometheus ID sysdig_host_timeseries_count_jmx Legacy ID metricCount.jmx Metric Type gauge Unit number Description Additional Notes sysdig_host_timeseries_count_prometheus Prometheus ID sysdig_host_timeseries_count_prometheus Legacy ID metricCount.prometheus Metric Type gauge Unit number Description Additional Notes sysdig_host_timeseries_count_statsd Prometheus ID sysdig_host_timeseries_count_statsd Legacy ID metricCount.statsd Metric Type gauge Unit number Description Additional Notes sysdig_host_up Prometheus ID sysdig_host_up Legacy ID uptime Metric Type gauge Unit number Description The percentage of time the selected entity was down during the visualized time sample. This can be used to determine if a machine (or a group of machines) went down. Additional Notes ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/host/"},{"id":558,"title":"Hosts","content":"Prerequisites Review Installation Requirements Understand Agent Drivers Collect the following: Sysdig access key Collector address For more information on agent configuration, see Configure Sysdig Agent.\nUse the Quick Start WizardThis option provides a script for installing the agent and is appropriate for quick trial installations to get Sysdig up and running.\nInstall as a Container Log in to Sysdig Monitor as an administrator.\nSelect Integrations \u0026gt; Sysdig Agent.\nClick +Add Account and select Docker.\nAs prompted by the screen, enter the list of tags. For example, env:production, cluster:east-cluster-a.\n​ The Wizard will autopopulate a code snippet with autodetected Sysdig Monitor endpoint and the agent access key.\nCopy and run the script.\nThis will install the Sysdig agent.\nInstall as a Package Log in to Sysdig Monitor as an administrator.\nSelect Integrations \u0026gt; Sysdig Agent.\nClick +Add Account and select Linux.\nAs prompted by the screen, enter the list of tags. For example, env:production, cluster:east-cluster-a.\n​ The Wizard will autopopulate a code snippet with autodetected Sysdig Monitor endpoint and the agent access key.\nCopy and run the script.\nThis will install the Sysdig agent.\nCustomized InstallationThis option can be integrated with your enterprise deployment methods at a production scale.\nInstall as a Container Google Kubernetes Engine (GKE) Container-Optimized OS (COS) environments require the eBPF or Universal eBPF driver to run the Sysdig Agent. Agent versions 12.17.0 and newer ship with a pre-built Universal eBPF object embedded in the agent binary. It is not necessary to run the sysdig-agent-kmodule container when using the Universal eBPF driver. Build and load the kernel module or eBPF object file, kernel module and eBPF drivers, only: If you are using the kernel module driver, run:\ndocker run -it --privileged --rm --name sysdig-agent-kmodule \\ -v /usr:/host/usr:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules \\ quay.io/sysdig/agent-kmodule If you are using the eBPF driver, run:\ndocker run -it --privileged --rm --name sysdig-agent-kmodule \\ -e SYSDIG_BPF_PROBE=\u0026#34;\u0026#34; \\ -v /usr:/host/usr:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /etc/os-release:/host/etc/os-release:ro \\ -v /root/.sysdig:/root/.sysdig \\ quay.io/sysdig/agent-kmodule Configure the kernel module to load during system boot. Skip eBPF and Universal eBPF:\nsudo mkdir -p /etc/modules-load.d sudo bash -c \u0026#34;echo sysdigcloud-probe \u0026gt; /etc/modules-load.d/sysdigcloud-probe.conf\u0026#34; Run the agent container providing the access key and, optionally, user-defined tags:\nIf you are using kernel module, run:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ --shm-size=512m \\ quay.io/sysdig/agent-slim If you are using eBPF, run:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e SYSDIG_BPF_PROBE=\u0026#34;\u0026#34; \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt; ] \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /root/.sysdig:/root/.sysdig \\ --shm-size=512m \\ quay.io/sysdig/agent-slim If you are using Universal eBPF, run:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e SYSDIG_AGENT_DRIVER=universal_ebpf \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt; ] \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ --shm-size=512m \\ quay.io/sysdig/agent-slim Replace \u0026lt;ACCESS_KEY\u0026gt; and \u0026lt;COLLECTOR_ADDRESS\u0026gt; with the access key and collector address associated with your account. \u0026lt;TAGS\u0026gt; is optional. You can use it to add custom tags to your metrics. For example, env:production, cluster:east-cluster-a.\nVerify that Sysdig Agent is running: docker ps You should see the sysdig-agent container listed in the output.\nThe Sysdig Agent is now installed and running on your host. You can begin monitoring your system, and view dashboards and alerts on the Sysdig Monitor UI.\nInstall as a PackageInstalling agent as a package is supported on the following :\nDebian, Ubuntu CentOS, RHEL, Fedora, Amazon AMI, Amazon Linux 2 Starting with agent version 13.1.0, separate packages will have to be installed depending on the driver to be used. Please see the table below.\nPackage Reference Driver Main Package Dependency Packages kmod (compatibility mode) draios-agent draios-agent-slim, draios-agent-kmodule kmod (recommended) draios-agent-kmodule draios-agent-slim legacy_ebpf draios-agent-legacy-ebpf draios-agent-slim universal_ebpf draios-agent-slim Debian and Ubuntu Trust the Sysdig Monitor GNU Privacy Guard (GPG) key, configure the apt repository, and update the package list:\ncurl -s https://download.sysdig.com/DRAIOS-GPG-KEY.public -o /usr/share/keyrings/sysdig-keyring.asc echo \u0026#39;deb [signed-by=/usr/share/keyrings/sysdig-keyring.asc] https://download.sysdig.com/stable/deb stable-$(ARCH)/\u0026#39; | tee /etc/apt/sources.list.d/sysdig.list \u0026gt; /dev/null apt-get update Install kernel development files, (kernel module and eBPF drivers, only):\nsudo apt-get -y install linux-headers-$(uname -r) Install, configure, and restart the Sysdig agent:\nInstall the agent and specify the agent driver:\nTo select the kernel module driver: sudo apt-get -y install draios-agent-kmodule cat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=kmod\u0026#34; Note: On new installations, the kernel module driver is selected by default, and specifying it explicitly in /etc/default/dragent is optional. To select the eBPF driver: sudo apt-get -y install draios-agent-legacy-ebpf cat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#39;SYSDIG_BPF_PROBE=\u0026#34;\u0026#34;\u0026#39; cat \u0026gt;\u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=legacy_ebpf\u0026#34; To select the Universal eBPF driver: sudo apt-get -y install draios-agent-slim cat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=universal_ebpf\u0026#34; Configure dragent.yaml:\nsudo bash -c `echo customerid: ACCESS_KEY \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml` sudo bash -c `echo tags: [TAGS] \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml` sudo bash -c `echo collector: COLLECTOR_ADDRESS \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml` Replace ACCESS_KEY and COLLECTOR_ADDRESS with the access key and collector address associated with your account. [TAGS] are optional and can be used to add custom tags to the agent\u0026rsquo;s metrics.\nRestart the agent:\nsudo systemctl enable dragent sudo systemctl start dragent CentOS, RHEL, Fedora, Amazon AMI, Amazon Linux 2 Trust the Sysdig Monitor GPG key and configure the yum repository:\nsudo rpm --import https://download.sysdig.com/DRAIOS-GPG-KEY.public \u0026amp;\u0026amp; sudo curl -s -o /etc/yum.repos.d/draios.repo https://download.sysdig.com/stable/rpm/draios.repo Install the Extra Packages for Enterprise Linux (EPEL) repository, (kernel module and eBPF drivers, only):\nsudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm This command is required only if Dynamic Kernel Module Support (DKMS) is not available in the base distribution.\nInstall the kernel development files, (kernel module and eBPF drivers, only):\nsudo yum -y install kernel-devel-$(uname -r) Install, configure, and start the Sysdig Agent:\nInstall the agent and specify the agent driver: To select the kernel module driver: yum -y install draios-agent-kmodule cat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=kmod\u0026#34; Note: On new installations, the kernel module driver is selected by default, and specifying it explicitly in /etc/sysconfig/dragent is optional. To select the legacy eBPF driver yum -y install draios-agent-legacy-ebpf cat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#39;SYSDIG_BPF_PROBE=\u0026#34;\u0026#34;\u0026#39; cat \u0026gt;\u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=legacy_ebpf\u0026#34; To select the Universal eBPF driver: yum -y install draios-agent-slim cat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=universal_ebpf\u0026#34; Configure dragent.yaml: echo customerid: ACCESS_KEY \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml echo tags: [TAGS] \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml echo collector: COLLECTOR_ADDRESS \u0026gt;\u0026gt; /opt/draios/etc/dragent.yaml Replace ACCESS_KEY and COLLECTOR_ADDRESS with installation-specific values. [TAGS] is optional and can be used to add custom tags to your metrics. For example, env:production, cluster:east-cluster-a. Start the agent: sudo systemctl enable dragent sudo systemctl start dragent Uninstall AgentContainerIf Sysdig Agent was installed as a container, remove it using the standard container commands.\nDebian and UbuntuTo uninstall the agent from Debian Linux distributions, including Ubuntu:\nRun the following command in a terminal on each host:\nsudo apt-get purge -y draios-agent Fedora, CentOS, RHEL, Amazon AMI, Amazon Linux 2To uninstall the agent from Fedora Linux distributions, run the following command in a terminal on each host:\nsudo yum -y erase draios-agent Install As a Single Container (Legacy)The legacy way of installing an agent involves running it as a single container. It includes the components for downloading and building the kernel module, as well as for gathering and reporting on a wide variety of pre-defined metrics and events.\nSaaS Collect the necessary environment variables.\nRun the agent container providing the access key and, optionally, user-defined tags:\nTo use the kernel module driver:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=[TAGS]] \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=512m \\ -v /etc/modprobe.d:/etc/modprobe.d \\ quay.io/sysdig/agent To use the eBPF driver:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] \\ -e SYSDIG_BPF_PROBE=\u0026#34;\u0026#34; \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=512m \\ -v /etc/modprobe.d:/etc/modprobe.d \\ quay.io/sysdig/agent To use the Universal eBPF driver:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY? \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] \\ -e SYSDIG_AGENT_DRIVER=universal_ebpf \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ --shm-size=512m \\ quay.io/sysdig/agent-slim On-Premises Collect the necessary environment variables.\nRun the agent container providing the access key and, optionally, user-defined tags:\nTo use the kernel module driver:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ -e SECURE=true \\ -e CHECK_CERTIFICATE=true \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=512m \\ quay.io/sysdig/agent To use the eBPF driver:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ -e SECURE=true \\ -e CHECK_CERTIFICATE=true \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] -e SYSDIG_BPF_PROBE=\u0026#34;\u0026#34; \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=512m \\ quay.io/sysdig/agent To use the Universal eBPF driver:\ndocker run -d --name sysdig-agent \\ --restart always \\ --privileged \\ --net host \\ --pid host \\ -e ACCESS_KEY=\u0026lt;ACCESS_KEY\u0026gt; \\ -e COLLECTOR=\u0026lt;COLLECTOR_ADDRESS\u0026gt; \\ -e SECURE=true \\ -e CHECK_CERTIFICATE=true \\ [-e TAGS=\u0026lt;TAGS\u0026gt;] -e SYSDIG_AGENT_DRIVER=universal_ebpf \\ -v /sys/kernel/debug:/sys/kernel/debug:ro \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ --shm-size=512m \\ quay.io/sysdig/agent-slim Common Environment Variables for Agent Containers Option Description ACCESS_KEY The agent access key. You can retrieve this from Settings \u0026gt; Agent Installation in either Sysdig Monitor or Sysdig Secure. TAGS The list of tags for the host where the agent is installed. For example: role:webserver, location:europe COLLECTOR The collector URL for Sysdig Monitor or Sysdig Secure. This value is region-dependent in SaaS and is auto-completed on the Get Started page in the Monitor UI or Data Sources page in Secure. It is a custom value in on-prem installations. See SaaS Regions and IP Ranges. COLLECTOR_PORT The default is 6443. ADDITIONAL_CONF Optional. Use this option to provide custom configuration values to the agent as environment variables. If provided, will be appended to the agent configuration file. SYSDIG_AGENT_DRIVER Optional. The syscall capture driver that is used by the agent. Valid values are kmod, universal_ebpf, and legacy_ebpf. Agent defaults to kmod if this environment variable is not set SYSDIG_BPF_PROBE Optional. Deprecated and superseded by SYSDIG_AGENT_DRIVER. The old environment variable that is used to force the agent to load the current eBPF driver. Valid values are \u0026quot;\u0026quot; or a path within the container to a compatible eBPF object file.\nNote: The agent will exit with an error if SYSDIG_AGENT_DRIVER and SYSDIG_BPF_PROBE are set to conflicting values. See Understand the Agent Configuration for additional information on agent and container environment variables.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/install-classic-agent-hosts/"},{"id":559,"title":"IBM Kubernetes API Server","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 11 metrics.\nTimeseries generated: ~1200 TS\nList of Alerts Alert Description Format [IBM Kubernetes API Server] Certificate Expiry API-Server Certificate Expiry Prometheus [IBM Kubernetes API Server] Admission Controller High Latency API-Server Admission Controller High Latency Prometheus [IBM Kubernetes API Server] High 4xx RequestError Rate APIS-Server High 4xx Request Error Rate Prometheus [IBM Kubernetes API Server] High 5xx RequestError Rate APIS-Server High 5xx Request Error Rate Prometheus [IBM Kubernetes API Server] High Request Latency APIS-Server High Request Latency Prometheus List of DashboardsIBM Kubernetes API ServerThe dashboard provides information on the IBM Kubernetes API Server. List of Metrics Metric name apiserver_admission_controller_admission_duration_seconds_count apiserver_admission_controller_admission_duration_seconds_sum apiserver_client_certificate_expiration_seconds_bucket apiserver_client_certificate_expiration_seconds_count apiserver_request_duration_seconds_count apiserver_request_duration_seconds_sum apiserver_request_total apiserver_response_sizes_count apiserver_response_sizes_sum workqueue_adds_total workqueue_depth PrerequisitesInstall Sysdig AgentTo collect the IBM Kubernetes API Server metrics, you must install Sysdig Agent on your IKS cluster nodes.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting IBM Kubernetes API ServerLearning how to monitor Kubernetes API server is vital when running Kubernetes in production. Monitoring kube-apiserver will help you detect and troubleshoot latency and errors, and validate whether the service performs as expected.\nHere are some interesting queries to run and metrics to monitor for troubleshooting the IBM Kubernetes API Server.\nCertificate ExpirationCertificates are used to authenticate to the API server, and you can check with the following query if a certificate is expiring next week:\napiserver_client_certificate_expiration_seconds_count \u0026gt; 0 and histogram_quantile(0.01, sum by (job, le) (rate(apiserver_client_certificate_expiration_seconds_bucket[5m]))) \u0026lt; 7*24*60*60 API Server LatencyLatency spike is typically a sign of overload in the API server. Probably your cluster has a high load and the API server needs to be scaled out. Use the following query to check for latency spikes in the last 10 minutes.\nsum by (kube_cluster_name,verb,apiserver)(rate(apiserver_request_duration_seconds_sum{verb!=\u0026#34;WATCH\u0026#34;}[10m]))/sum by (kube_cluster_name,verb,apiserver)(rate(apiserver_request_duration_seconds_count{verb!=\u0026#34;WATCH\u0026#34;}[10m])) Request Error RateRequest error rate means that the API server is responding with 5xx errors.\nsum by(kube_cluster_name)(rate(apiserver_request_total{code=~\u0026#34;5..\u0026#34;}[5m])) / sum by(kube_cluster_name)(rate(apiserver_request_total[5m])) \u0026gt; 0.05 Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: iks-apiservers-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true scheme: https kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: [__meta_kubernetes_pod_container_name] regex: dashboard-metrics-scraper - action: replace source_labels: [__address__] target_label: __address__ replacement: kubernetes.default.svc:443 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (apiserver_admission_controller_admission_duration_seconds_count|apiserver_admission_controller_admission_duration_seconds_sum|apiserver_client_certificate_expiration_seconds_bucket|apiserver_client_certificate_expiration_seconds_count|apiserver_request_duration_seconds_count|apiserver_request_duration_seconds_sum|apiserver_request_total|apiserver_response_sizes_count|apiserver_response_sizes_sum|workqueue_adds_total|workqueue_depth) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/ibm-kubernetes-api-server/"},{"id":560,"title":"K8s cAdvisor","content":" This integration is enabled by default.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 5 metrics.\nTimeseries generated: The expected cardinality of the Kubernetes cAdvisor metrics is 5 timeseries per container and pod (one timeseries for each of the five metrics).\nList of Metrics Metric name container_cpu_cfs_periods_total container_cpu_cfs_throttled_periods_total container_cpu_cfs_throttled_seconds_total container_cpu_usage_seconds_total container_spec_cpu_period PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: k8s-cadvisor-default scrape_interval: 60s bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true metrics_path: \u0026#39;/metrics/cadvisor\u0026#39; kubernetes_sd_configs: - role: node relabel_configs: - action: keep source_labels: [__meta_kubernetes_node_address_InternalIP] regex: __HOSTIPS__ - action: labelmap regex: __meta_kubernetes_node_label_(.+) replacement: kube_node_label_$1 - replacement: localhost:10250 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_node_name] target_label: kube_node_name - action: replace source_labels: [__meta_kubernetes_namespace] target_label: kube_namespace_name metric_relabel_configs: - source_labels: [__name__] regex: \u0026#34;container_cpu_cfs_throttled_periods_total|container_cpu_cfs_periods_total|container_cpu_cfs_throttled_seconds_total|container_cpu_usage_seconds_total|container_spec_cpu_period\u0026#34; action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-cadvisor/"},{"id":561,"title":"K8s cAdvisor full","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 48 metrics.\nTimeseries generated: The expected cardinality of the Kubernetes cAdvisor full integration is 5.97K timeseries per container and pod.\nList of DashboardscAdvisorThe dashboard provides information on the Kubernetes Cadvisor. List of Metrics Metric name container_cpu_cfs_periods_total container_cpu_cfs_throttled_periods_total container_cpu_cfs_throttled_seconds_total container_cpu_load_average_10s container_cpu_system_seconds_total container_cpu_usage_seconds_total container_cpu_user_seconds_total container_fs_inodes_free container_fs_inodes_total container_fs_io_current container_fs_io_time_seconds_total container_fs_io_time_weighted_seconds_total container_fs_limit_bytes container_fs_read_seconds_total container_fs_reads_merged_total container_fs_reads_total container_fs_sector_reads_total container_fs_sector_writes_total container_fs_usage_bytes container_fs_write_seconds_total container_fs_writes_merged_total container_fs_writes_total container_last_seen container_memory_cache container_memory_failcnt container_memory_failures_total container_memory_mapped_file container_memory_max_usage_bytes container_memory_rss container_memory_swap container_memory_usage_bytes container_memory_working_set_bytes container_network_receive_bytes_total container_network_receive_errors_total container_network_receive_packets_dropped_total container_network_receive_packets_total container_network_transmit_bytes_total container_network_transmit_errors_total container_network_transmit_packets_dropped_total container_network_transmit_packets_total container_oom_events_total container_scrape_error container_spec_cpu_period container_spec_memory_limit_bytes container_spec_memory_reservation_limit_bytes container_spec_memory_swap_limit_bytes container_start_time_seconds container_tasks_state PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: k8s-cadvisor-full scrape_interval: 60s bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true metrics_path: \u0026#39;/metrics/cadvisor\u0026#39; kubernetes_sd_configs: - role: node relabel_configs: - action: keep source_labels: [__meta_kubernetes_node_address_InternalIP] regex: __HOSTIPS__ - action: labelmap regex: __meta_kubernetes_node_label_(.+) replacement: kube_node_label_$1 - replacement: localhost:10250 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_node_name] target_label: kube_node_name - action: replace source_labels: [__meta_kubernetes_namespace] target_label: kube_namespace_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-cadvisor-full/"},{"id":562,"title":"Kubernetes","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration has 70 metrics.\nList of Alerts Alert Description Format [Kubernetes] Container Waiting Container in waiting status for long time (CrashLoopBackOff, ImagePullErr\u0026hellip;) Prometheus [Kubernetes] Container Restarting Container restarting Prometheus [Kubernetes] Pod Not Ready Pod in not ready status Prometheus [Kubernetes] Init Container Waiting For a Long Time Init container in waiting state (CrashLoopBackOff, ImagePullErr\u0026hellip;) Prometheus [Kubernetes] Pod Container Creating For a Long Time Pod is stuck in ContainerCreating state Prometheus [Kubernetes] Pod Container Terminated With Error Pod Container Terminated With Error (OOMKilled, Error\u0026hellip;) Prometheus [Kubernetes] Init Container Terminated With Error Init Container Terminated With Error (OOMKilled, Error\u0026hellip;) Prometheus [Kubernetes] Workload with Pods not Ready Workload with Pods not Ready (Evicted, NodeLost, UnexpectedAdmissionError) Prometheus [Kubernetes] Workload Replicas Mismatch There are pod in the workload that could not start Prometheus [Kubernetes] Pod Not Scheduled For DaemonSet Pods cannot be scheduled for DaemonSet Prometheus [Kubernetes] Pods In DaemonSet Incorrectly Scheduled There are pods from a DaemonSet that should not be running Prometheus [Kubernetes] CPU Overcommit CPU resources in the cluster are overcommitted. If a node fails, the cluster may be unable to reschedule the affected pods due to insufficient CPU capacity. Prometheus [Kubernetes] Memory Overcommit Memory resources in the cluster are overcommitted. If a node fails, the cluster may be unable to reschedule the affected pods due to insufficient memory capacity. Prometheus [Kubernetes] CPU OverUsage CPU OverUsage in cluster. If one node fails, the cluster will not have enough CPU to run all the current pods. Prometheus [Kubernetes] Memory OverUsage Memory OverUsage in cluster. If one node fails, the cluster will not have enough memory to run all the current pods. Prometheus [Kubernetes] Container CPU Throttling Container CPU usage next to limit. Possible CPU Throttling. Prometheus [Kubernetes] Container Memory Next To Limit Container memory usage next to limit. Risk of Out Of Memory Kill. Prometheus [Kubernetes] Container CPU Unused Container unused CPU higher than 85% of request for 8 hours. Prometheus [Kubernetes] Container Memory Unused Container unused Memory higher than 85% of request for 8 hours. Prometheus [Kubernetes] Node Not Ready Node in Not-Ready condition Prometheus [Kubernetes] Not All Nodes Are Ready Not all nodes are in Ready condition. Prometheus [Kubernetes] Too Many Pods In Node Node close to its limits of pods. Prometheus [Kubernetes] Node Readiness Flapping Node availability is unstable. Prometheus [Kubernetes] Nodes Disappeared Less nodes in cluster than 30 minutes before. Prometheus [Kubernetes] All Nodes Gone In Cluster All Nodes Gone In Cluster. Prometheus [Kubernetes] Node CPU High Usage High usage of CPU in node. Prometheus [Kubernetes] Node Memory High Usage High usage of memory in node. Risk of pod eviction. Prometheus [Kubernetes] Node Root File System Almost Full Root file system in node almost full. To include other file systems, change the value of the device label from \u0026lsquo;.root.\u0026rsquo; to your device name Prometheus [Kubernetes] Max Schedulable Pod Less Than 1 CPU Core The maximum schedulable CPU request in a pod is less than 1 core. Prometheus [Kubernetes] Max Schedulable Pod Less Than 512Mb Memory The maximum schedulable memory request in a pod is less than 512Mb. Prometheus [Kubernetes] HPA Desired Scale Up Replicas Unreached HPA could not reach the desired scaled up replicas for long time. Prometheus [Kubernetes] HPA Desired Scale Down Replicas Unreached HPA could not reach the desired scaled down replicas for long time. Prometheus [Kubernetes] Job failed to complete Job failed to complete Prometheus [Kubernetes] Cluster is reaching maximum pod capacity (95%) Review cluster pod capacity to ensure pods can be scheduled. Prometheus List of DashboardsWorkload Status \u0026amp; PerformanceThe dashboard provides information on the Workload Status and Performance. Pod Status \u0026amp; PerformanceThe dashboard provides information on the Pod Status and Performance. Cluster / Namespace Available ResourcesThe dashboard provides information on the Cluster and Namespace Available Resources. Cluster Capacity PlanningDashboard used for Cluster Capacity Planning. Container Resource Usage \u0026amp; TroubleshootingThe dashboard provides information on the Container Resource Usage and Troubleshooting. Node Status \u0026amp; PerformanceThe dashboard provides information on the Node Status and Performance. Pod Rightsizing \u0026amp; Workload Capacity OptimizationDashboard used for Pod Rightsizing and Workload Capacity Optimization. Pod Scheduling TroubleshootingDashboard used for Pod Scheduling Troubleshooting. Horizontal Pod AutoscalerThe dashboard provides information on the Horizontal Pod Autoscalers. Kubernetes JobsThe dashboard provides information on the Kubernetes Jobs. List of Metrics Metric name container.image container.image.tag kube_cronjob_next_schedule_time kube_cronjob_status_active kube_cronjob_status_last_schedule_time kube_daemonset_status_current_number_scheduled kube_daemonset_status_desired_number_scheduled kube_daemonset_status_number_misscheduled kube_daemonset_status_number_ready kube_hpa_status_current_replicas kube_hpa_status_desired_replicas kube_job_complete kube_job_failed kube_job_spec_completions kube_job_status_active kube_namespace_labels kube_node_info kube_node_status_allocatable kube_node_status_allocatable_cpu_cores kube_node_status_allocatable_memory_bytes kube_node_status_capacity kube_node_status_capacity_cpu_cores kube_node_status_capacity_memory_bytes kube_node_status_capacity_pods kube_node_status_condition kube_node_sysdig_host kube_pod_container_info kube_pod_container_resource_limits kube_pod_container_resource_requests kube_pod_container_status_restarts_total kube_pod_container_status_terminated_reason kube_pod_container_status_waiting_reason kube_pod_info kube_pod_init_container_status_terminated_reason kube_pod_init_container_status_waiting_reason kube_pod_status_ready kube_resourcequota kube_workload_pods_status_reason kube_workload_status_desired kube_workload_status_ready kubernetes.hpa.replicas.current kubernetes.hpa.replicas.desired kubernetes.hpa.replicas.max kubernetes.hpa.replicas.min sysdig_container_cpu_cores_used sysdig_container_cpu_quota_used_percent sysdig_container_info sysdig_container_memory_limit_used_percent sysdig_container_memory_used_bytes sysdig_container_net_connection_in_count sysdig_container_net_connection_out_count sysdig_container_net_connection_total_count sysdig_container_net_error_count sysdig_container_net_http_error_count sysdig_container_net_http_request_time sysdig_container_net_http_statuscode_request_count sysdig_container_net_in_bytes sysdig_container_net_out_bytes sysdig_container_net_request_count sysdig_container_net_request_time sysdig_fs_free_bytes sysdig_fs_inodes_used_percent sysdig_fs_total_bytes sysdig_fs_used_bytes sysdig_fs_used_percent sysdig_program_cpu_cores_used sysdig_program_cpu_used_percent sysdig_program_memory_used_bytes sysdig_program_net_connection_total_count sysdig_program_net_total_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/kubernetes/"},{"id":563,"title":"Kubernetes API server","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 42 metrics.\nList of Alerts Alert Description Format [Kubernetes API Server] Deprecated APIs API-Server Deprecated APIs Prometheus [Kubernetes API Server] Certificate Expiry API-Server Certificate Expiry Prometheus [Kubernetes API Server] Admission Controller High Latency API-Server Admission Controller High Latency Prometheus [Kubernetes API Server] Webhook Admission Controller High Latency API-Server Webhook Admission Controller High Latency Prometheus [Kubernetes API Server] High 4xx RequestError Rate APIS-Server High 4xx Request Error Rate Prometheus [Kubernetes API Server] High 5xx RequestError Rate APIS-Server High 5xx Request Error Rate Prometheus [Kubernetes API Server] High Request Latency APIS-Server High Request Latency Prometheus List of DashboardsKubernetes API ServerThe dashboard provides information on the Kubernetes API Server. List of Metrics Metric name apiserver_admission_controller_admission_duration_seconds_count apiserver_admission_controller_admission_duration_seconds_sum apiserver_admission_webhook_admission_duration_seconds_count apiserver_admission_webhook_admission_duration_seconds_sum apiserver_client_certificate_expiration_seconds_bucket apiserver_client_certificate_expiration_seconds_count apiserver_request_duration_seconds_count apiserver_request_duration_seconds_sum apiserver_request_total apiserver_requested_deprecated_apis apiserver_response_sizes_count apiserver_response_sizes_sum go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds process_resident_memory_bytes workqueue_adds_total workqueue_depth PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: kubernetes-apiservers-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep regex: kube-system;kube-apiserver source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_container_name - source_labels: - __address__ action: replace target_label: __address__ regex: (.+)(:\\d.+) replacement: $1:443 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - action: replace source_labels: - __name__ - resource target_label: k8sresource regex: (apiserver_requested_deprecated_apis);(.+) replacement: $2 - action: labeldrop regex: \u0026#34;^(resource|resourcescope|subresource)$\u0026#34; - source_labels: [__name__] regex: (apiserver_admission_controller_admission_duration_seconds_count|apiserver_admission_controller_admission_duration_seconds_sum|apiserver_admission_webhook_admission_duration_seconds_count|apiserver_admission_webhook_admission_duration_seconds_sum|apiserver_client_certificate_expiration_seconds_bucket|apiserver_client_certificate_expiration_seconds_count|apiserver_request_duration_seconds_count|apiserver_request_duration_seconds_sum|apiserver_request_total|apiserver_requested_deprecated_apis|apiserver_response_sizes_count|apiserver_response_sizes_sum|go_info|go_gc_duration_seconds|go_gc_duration_seconds_count|go_gc_duration_seconds_sum|go_goroutines|go_memstats_buck_hash_sys_bytes|go_memstats_gc_sys_bytes|go_memstats_heap_alloc_bytes|go_memstats_heap_idle_bytes|go_memstats_heap_inuse_bytes|go_memstats_heap_released_bytes|go_memstats_heap_sys_bytes|go_memstats_lookups_total|go_memstats_mallocs_total|go_memstats_mcache_inuse_bytes|go_memstats_mcache_sys_bytes|go_memstats_mspan_inuse_bytes|go_memstats_mspan_sys_bytes|go_memstats_next_gc_bytes|go_memstats_stack_inuse_bytes|go_memstats_stack_sys_bytes|go_memstats_sys_bytes|go_threads|process_cpu_seconds_total|process_max_fds|process_open_fds|process_resident_memory_bytes|workqueue_adds_total|workqueue_depth) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-api-server/"},{"id":564,"title":"Kubernetes controller manager","content":" This integration is enabled by default.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 46 metrics.\nList of Alerts Alert Description Format [Kubernetes controller manager] High 4xx RequestError Rate Kubernetes Controller Manager High 4xx Request Error Rate Prometheus [Kubernetes controller manager] High 5xx RequestError Rate Kubernetes Controller Manager High 5xx Request Error Rate Prometheus List of DashboardsKubernetes Controller ManagerThe dashboard provides information on the Kubernetes Controller Manager. List of Metrics Metric name apiserver_client_certificate_expiration_seconds_bucket apiserver_client_certificate_expiration_seconds_count apiserver_client_certificate_expiration_seconds_sum cloudprovider_aws_api_request_duration_seconds_count cloudprovider_aws_api_request_duration_seconds_sum cloudprovider_aws_api_request_errors go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds rest_client_request_duration_seconds_count rest_client_request_duration_seconds_sum rest_client_requests_total sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes workqueue_adds_total workqueue_depth workqueue_queue_duration_seconds_count workqueue_queue_duration_seconds_sum workqueue_retries_total workqueue_unfinished_work_seconds workqueue_work_duration_seconds_count workqueue_work_duration_seconds_sum PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: kube-controller-manager-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/kube-controller-manager.+\u0026#39; - source_labels: - __address__ action: replace target_label: __address__ regex: (.+?)(\\\\:\\\\d)? replacement: $1:10257 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (cloudprovider_aws_api_request_duration_seconds_count|cloudprovider_aws_api_request_duration_seconds_sum|cloudprovider_aws_api_request_errors|go_goroutines|rest_client_request_duration_seconds_count|rest_client_request_duration_seconds_sum|rest_client_requests_total|workqueue_adds_total|workqueue_depth|workqueue_queue_duration_seconds_count|workqueue_queue_duration_seconds_sum|workqueue_retries_total|workqueue_unfinished_work_seconds|workqueue_work_duration_seconds_count|workqueue_work_duration_seconds_sum|go_gc_duration_seconds|go_gc_duration_seconds_count|go_gc_duration_seconds_sum|go_goroutines|go_info|go_memstats_buck_hash_sys_bytes|go_memstats_gc_sys_bytes|go_memstats_heap_alloc_bytes|go_memstats_heap_idle_bytes|go_memstats_heap_inuse_bytes|go_memstats_heap_released_bytes|go_memstats_heap_sys_bytes|go_memstats_lookups_total|go_memstats_mallocs_total|go_memstats_mcache_inuse_bytes|go_memstats_mcache_sys_bytes|go_memstats_mspan_inuse_bytes|go_memstats_mspan_sys_bytes|go_memstats_next_gc_bytes|go_memstats_stack_inuse_bytes|go_memstats_stack_sys_bytes|go_memstats_sys_bytes|go_threads|apiserver_client_certificate_expiration_seconds_bucket|apiserver_client_certificate_expiration_seconds_sum|apiserver_client_certificate_expiration_seconds_count) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-controller-manager/"},{"id":565,"title":"Kubernetes CoreDNS","content":" This integration is enabled by default.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 38 metrics.\nList of Alerts Alert Description Format [CoreDNS] Error High High Request Duration Prometheus [CoreDNS] Latency High Latency High Prometheus List of DashboardsKubernetes CoreDNSThe dashboard provides information on the Kubernetes CoreDNS. List of Metrics Metric name coredns_cache_hits_total coredns_cache_misses_total coredns_dns_request_duration_seconds_bucket coredns_dns_request_size_bytes_bucket coredns_dns_requests_total coredns_dns_response_size_bytes_bucket coredns_dns_responses_total coredns_forward_request_duration_seconds_bucket coredns_panics_total coredns_plugin_enabled go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds process_resident_memory_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: kube-dns-default honor_labels: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/coredns.+\u0026#39; - source_labels: - __address__ action: keep regex: (.*:9153) - source_labels: - __meta_kubernetes_pod_name action: replace target_label: instance - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-coredns/"},{"id":566,"title":"Kubernetes etcd","content":" This integration is enabled by default.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 55 metrics.\nList of Alerts Alert Description Format [Etcd] Etcd Members Down There are members down. Prometheus [Etcd] Etcd Insufficient Members Etcd cluster has insufficient members Prometheus [Etcd] Etcd No Leader Member has no leader. Prometheus [Etcd] Etcd High Number Of Leader Changes Leader changes within the last 15 minutes. Prometheus [Etcd] Etcd High Number Of Failed GRPC Requests High number of failed grpc requests Prometheus [Etcd] Etcd GRPC Requests Slow gRPC requests are taking too much time Prometheus [Etcd] Etcd High Number Of Failed Proposals High number of proposal failures within the last 30 minutes on etcd instance Prometheus [Etcd] Etcd High Fsync Durations 99th percentile fync durations are too high Prometheus [Etcd] Etcd High Commit Durations 99th percentile commit durations are too high Prometheus List of DashboardsKubernetes EtcdThe dashboard provides information on the Kubernetes Etcd. List of Metrics Metric name apiserver_client_certificate_expiration_seconds_bucket apiserver_client_certificate_expiration_seconds_count apiserver_client_certificate_expiration_seconds_sum etcd_debugging_mvcc_db_total_size_in_bytes etcd_disk_backend_commit_duration_seconds_bucket etcd_disk_wal_fsync_duration_seconds_bucket etcd_grpc_proxy_cache_hits_total etcd_grpc_proxy_cache_misses_total etcd_mvcc_db_total_size_in_bytes etcd_network_client_grpc_received_bytes_total etcd_network_client_grpc_sent_bytes_total etcd_network_peer_received_bytes_total etcd_network_peer_received_failures_total etcd_network_peer_round_trip_time_seconds_bucket etcd_network_peer_sent_bytes_total etcd_network_peer_sent_failures_total etcd_server_has_leader etcd_server_id etcd_server_leader_changes_seen_total etcd_server_proposals_applied_total etcd_server_proposals_committed_total etcd_server_proposals_failed_total etcd_server_proposals_pending go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads grpc_server_handled_total grpc_server_handling_seconds_bucket grpc_server_started_total process_cpu_seconds_total process_max_fds process_open_fds sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent jobs for this integration are as follows:\n- job_name: etcd-default scheme: https tls_config: insecure_skip_verify: true cert_file: /host/etc/kubernetes/pki/etcd/ca.crt key_file: /host/etc/kubernetes/pki/etcd/ca.key kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/etcd-.+\u0026#39; - source_labels: - __address__ action: replace target_label: __address__ regex: (.+?)(\\\\:\\\\d)? replacement: $1:2379 # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (go_build_info|etcd_server_has_leader|etcd_server_leader_changes_seen_total|etcd_server_proposals_failed_total|go_info|go_gc_duration_seconds|go_gc_duration_seconds_count|go_gc_duration_seconds_sum|go_memstats_buck_hash_sys_bytes|go_memstats_gc_sys_bytes|go_memstats_heap_alloc_bytes|go_memstats_heap_idle_bytes|go_memstats_heap_inuse_bytes|go_memstats_heap_released_bytes|go_memstats_heap_sys_bytes|go_memstats_lookups_total|go_memstats_mallocs_total|go_memstats_mcache_inuse_bytes|go_memstats_mcache_sys_bytes|go_memstats_mspan_inuse_bytes|go_memstats_mspan_sys_bytes|go_memstats_next_gc_bytes|go_memstats_stack_inuse_bytes|go_memstats_stack_sys_bytes|go_memstats_sys_bytes|go_threads|process_cpu_seconds_total|grpc_server_started_total|grpc_server_started_total|grpc_server_started_total|grpc_server_handled_total|etcd_debugging_mvcc_db_total_size_in_bytes|etcd_disk_wal_fsync_duration_seconds_bucket|etcd_disk_backend_commit_duration_seconds_bucket|sysdig_container_memory_used_bytes|etcd_server_proposals_committed_total|etcd_server_proposals_applied_total|sysdig_container_cpu_cores_used|go_goroutines|grpc_server_handled_total|grpc_server_handled_total|etcd_server_id|etcd_disk_backend_commit_duration_seconds_bucket|etcd_grpc_proxy_cache_hits_total|etcd_grpc_proxy_cache_misses_total|etcd_network_client_grpc_received_bytes_total|etcd_network_client_grpc_sent_bytes_total|process_max_fds|process_open_fds|etcd_server_proposals_pending|etcd_network_peer_sent_failures_total|etcd_network_peer_received_failures_total|etcd_network_peer_round_trip_time_seconds_bucket|etcd_network_client_grpc_sent_bytes_total|etcd_network_client_grpc_received_bytes_total|etcd_network_peer_sent_bytes_total|etcd_network_peer_received_bytes_total|grpc_server_handling_seconds_bucket|apiserver_client_certificate_expiration_seconds_bucket|apiserver_client_certificate_expiration_seconds_sum|apiserver_client_certificate_expiration_seconds_count|etcd_mvcc_db_total_size_in_bytes) action: keep - job_name: etcd-legacy-default scheme: https tls_config: insecure_skip_verify: true cert_file: /host/etc/kubernetes/pki/etcd-manager-main/etcd-clients-ca.crt key_file: /host/etc/kubernetes/pki/etcd-manager-main/etcd-clients-ca.key kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/etcd-manager-main.+\u0026#39; - source_labels: - __address__ action: replace target_label: __address__ regex: (.+?)(\\\\:\\\\d)? replacement: $1:4001 # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (etcd_server_has_leader|etcd_server_leader_changes_seen_total|etcd_server_proposals_failed_total|go_info|go_gc_duration_seconds|go_gc_duration_seconds_count|go_gc_duration_seconds_sum|go_memstats_buck_hash_sys_bytes|go_memstats_gc_sys_bytes|go_memstats_heap_alloc_bytes|go_memstats_heap_idle_bytes|go_memstats_heap_inuse_bytes|go_memstats_heap_released_bytes|go_memstats_heap_sys_bytes|go_memstats_lookups_total|go_memstats_mallocs_total|go_memstats_mcache_inuse_bytes|go_memstats_mcache_sys_bytes|go_memstats_mspan_inuse_bytes|go_memstats_mspan_sys_bytes|go_memstats_next_gc_bytes|go_memstats_stack_inuse_bytes|go_memstats_stack_sys_bytes|go_memstats_sys_bytes|go_threads|process_cpu_seconds_total|grpc_server_started_total|grpc_server_started_total|grpc_server_started_total|grpc_server_handled_total|etcd_debugging_mvcc_db_total_size_in_bytes|etcd_disk_wal_fsync_duration_seconds_bucket|etcd_disk_backend_commit_duration_seconds_bucket|sysdig_container_memory_used_bytes|etcd_server_proposals_committed_total|etcd_server_proposals_applied_total|sysdig_container_cpu_cores_used|go_goroutines|grpc_server_handled_total|grpc_server_handled_total|etcd_server_id|etcd_disk_backend_commit_duration_seconds_bucket|etcd_grpc_proxy_cache_hits_total|etcd_grpc_proxy_cache_misses_total|etcd_network_client_grpc_received_bytes_total|etcd_network_client_grpc_sent_bytes_total|process_max_fds|process_open_fds|etcd_server_proposals_pending|etcd_network_peer_sent_failures_total|etcd_network_peer_received_failures_total|etcd_network_peer_round_trip_time_seconds_bucket|etcd_network_client_grpc_sent_bytes_total|etcd_network_client_grpc_received_bytes_total|etcd_network_peer_sent_bytes_total|etcd_network_peer_received_bytes_total|grpc_server_handling_seconds_bucket|apiserver_client_certificate_expiration_seconds_bucket|apiserver_client_certificate_expiration_seconds_sum|apiserver_client_certificate_expiration_seconds_count|etcd_mvcc_db_total_size_in_bytes) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-etcd/"},{"id":567,"title":"Kubernetes kube-proxy","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 15 metrics.\nList of Alerts Alert Description Format [KubeProxy] Kube Proxy Down KubeProxy detected down Prometheus [KubeProxy] High Rest Client Latency High Rest Client Latency detected Prometheus [KubeProxy] High Rule Sync Latency High Rule Sync Latency detected Prometheus [KubeProxy] Too Many 500 Code Too Many 500 Code detected Prometheus List of DashboardsKubernetes ProxyThe dashboard provides information on the Kubernetes Proxy. List of Metrics Metric name apiserver_client_certificate_expiration_seconds_bucket apiserver_client_certificate_expiration_seconds_count apiserver_client_certificate_expiration_seconds_sum go_goroutines go_info kube_node_info kubeproxy_network_programming_duration_seconds_bucket kubeproxy_network_programming_duration_seconds_count kubeproxy_sync_proxy_rules_duration_seconds_bucket kubeproxy_sync_proxy_rules_duration_seconds_count process_cpu_seconds_total process_resident_memory_bytes rest_client_request_duration_seconds_bucket rest_client_requests_total up PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: kubernetes-kube-proxy-default honor_labels: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/kube-proxy.+\u0026#39; - replacement: localhost:10249 target_label: __address__ - source_labels: - __meta_kubernetes_pod_name action: replace target_label: instance - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (up|kubeproxy_sync_proxy_rules_duration_seconds_count|kubeproxy_sync_proxy_rules_duration_seconds_bucket|kubeproxy_network_programming_duration_seconds_count|kubeproxy_network_programming_duration_seconds_bucket|rest_client_requests_total|rest_client_request_duration_seconds_bucket|rest_client_request_duration_seconds_bucket|process_resident_memory_bytes|process_cpu_seconds_total|go_goroutines|go_info|apiserver_client_certificate_expiration_seconds_bucket|apiserver_client_certificate_expiration_seconds_sum|apiserver_client_certificate_expiration_seconds_count) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-kubeproxy/"},{"id":568,"title":"Kubernetes kubelet","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 26 metrics.\nList of Alerts Alert Description Format [k8s-kubelet] Kubelet Too Many Pods Kubelet Too Many Pods Prometheus [k8s-kubelet] Kubelet Pod Lifecycle Event Generator Duration High Kubelet Pod Lifecycle Event Generator Duration High Prometheus [k8s-kubelet] Kubelet Pod StartUp Latency High Kubelet Pod StartUp Latency High Prometheus [k8s-kubelet] Kubelet Down Kubelet Down Prometheus List of DashboardsKubernetes KubeletThe dashboard provides information on the Kubernetes Kubelet. List of Metrics Metric name go_goroutines go_info kube_node_status_capacity_pods kube_node_status_condition kubelet_cgroup_manager_duration_seconds_bucket kubelet_cgroup_manager_duration_seconds_count kubelet_node_config_error kubelet_pleg_relist_duration_seconds_bucket kubelet_pleg_relist_interval_seconds_bucket kubelet_pod_start_duration_seconds_bucket kubelet_pod_start_duration_seconds_count kubelet_pod_worker_duration_seconds_bucket kubelet_pod_worker_duration_seconds_count kubelet_running_containers kubelet_running_pods kubelet_runtime_operations_duration_seconds_bucket kubelet_runtime_operations_errors_total kubelet_runtime_operations_total kubernetes_build_info process_cpu_seconds_total process_resident_memory_bytes rest_client_request_duration_seconds_bucket rest_client_requests_total storage_operation_duration_seconds_bucket storage_operation_duration_seconds_count volume_manager_total_volumes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: k8s-kubelet-default scrape_interval: 60s bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: node relabel_configs: - action: keep source_labels: [__meta_kubernetes_node_address_InternalIP] regex: __HOSTIPS__ - action: labelmap regex: __meta_kubernetes_node_label_(.+) replacement: kube_node_label_$1 - replacement: localhost:10250 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_node_name] target_label: kube_node_name - action: replace source_labels: [__meta_kubernetes_namespace] target_label: kube_namespace_name metric_relabel_configs: # - source_labels: [__name__] # regex: \u0026#34;kubelet_volume(.+)|storage(.+)\u0026#34; # action: drop - source_labels: [__name__] regex: (go_goroutines|go_info|kube_node_status_capacity_pods|kube_node_status_condition|kubelet_cgroup_manager_duration_seconds_bucket|kubelet_cgroup_manager_duration_seconds_count|kubelet_node_config_error|kubelet_pleg_relist_duration_seconds_bucket|kubelet_pleg_relist_interval_seconds_bucket|kubelet_pod_start_duration_seconds_bucket|kubelet_pod_start_duration_seconds_count|kubelet_pod_worker_duration_seconds_bucket|kubelet_pod_worker_duration_seconds_count|kubelet_running_containers|kubelet_running_pods|kubelet_runtime_operations_duration_seconds_bucket|kubelet_runtime_operations_errors_total|kubelet_runtime_operations_total|kubernetes_build_info|process_cpu_seconds_total|process_resident_memory_bytes|rest_client_request_duration_seconds_bucket|rest_client_requests_total|volume_manager_total_volumes) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-kubelet/"},{"id":569,"title":"Kubernetes PVC","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 9 metrics.\nList of Alerts Alert Description Format [k8s-pvc] PV Not Available Persistent Volume not available Prometheus [k8s-pvc] PVC Pending For a Long Time Persistent Volume Claim not available Prometheus [k8s-pvc] PVC Lost Persistent Volume Claim lost Prometheus [k8s-pvc] PVC Storage Usage Is Reaching The Limit Persistent Volume Claim storage at 95% Prometheus [k8s-pvc] PVC Inodes Usage Is Reaching The Limit PVC inodes Usage Is Reaching The Limit Prometheus [k8s-pvc] PV Full In Four Days Persistent Volume Full In Four Days Prometheus List of DashboardsPVC and StorageThe dashboard provides information on the Kubernetes PVC and Storage. List of Metrics Metric name kube_persistentvolume_status_phase kube_persistentvolumeclaim_status_phase kubelet_volume_stats_available_bytes kubelet_volume_stats_capacity_bytes kubelet_volume_stats_inodes kubelet_volume_stats_inodes_used kubelet_volume_stats_used_bytes storage_operation_duration_seconds_bucket storage_operation_duration_seconds_count PrerequisitesEnable PVC metrics in Sysdig AgentEnable PVC metrics as seen in Configure PVC Metrics.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: k8s-pvc-default scrape_interval: 60s bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: node relabel_configs: - action: keep source_labels: [__meta_kubernetes_node_address_InternalIP] regex: __HOSTIPS__ - action: labelmap regex: __meta_kubernetes_node_label_(.+) replacement: kube_node_label_$1 - replacement: localhost:10250 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_node_name] target_label: kube_node_name metric_relabel_configs: # - source_labels: [__name__] # regex: \u0026#34;kubelet_volume(.+)\u0026#34; # action: keep - source_labels: [__name__] regex: (kube_persistentvolume_status_phase|kube_persistentvolumeclaim_status_phase|kubelet_volume_stats_available_bytes|kubelet_volume_stats_capacity_bytes|kubelet_volume_stats_inodes|kubelet_volume_stats_inodes_used|kubelet_volume_stats_used_bytes) action: keep - action: replace source_labels: [namespace] target_label: kube_namespace_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-pvc/"},{"id":570,"title":"Kubernetes Scheduler","content":" This integration is enabled by default.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 49 metrics.\nList of Alerts Alert Description Format [Kubernetes Scheduler] Failed Attempts to Schedule Pods The error rate of attempts to schedule pods is high. Prometheus List of DashboardsKubernetes SchedulerThe dashboard provides information on the Kubernetes Scheduler. List of Metrics Metric name apiserver_client_certificate_expiration_seconds_bucket apiserver_client_certificate_expiration_seconds_count apiserver_client_certificate_expiration_seconds_sum go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds rest_client_request_duration_seconds_count rest_client_request_duration_seconds_sum rest_client_requests_total scheduler_e2e_scheduling_duration_seconds_count scheduler_e2e_scheduling_duration_seconds_sum scheduler_pending_pods scheduler_pod_scheduling_attempts_count scheduler_pod_scheduling_attempts_sum scheduler_schedule_attempts_total sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes workqueue_adds_total workqueue_depth workqueue_queue_duration_seconds_count workqueue_queue_duration_seconds_sum workqueue_retries_total workqueue_unfinished_work_seconds workqueue_work_duration_seconds_count workqueue_work_duration_seconds_sum PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: kube-scheduler-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/kube-scheduler.+\u0026#39; - source_labels: - __address__ action: replace target_label: __address__ regex: (.+?)(\\\\:\\\\d)? replacement: $1:10259 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name metric_relabel_configs: - source_labels: [__name__] regex: (rest_client_request_duration_seconds_count|rest_client_request_duration_seconds_sum|rest_client_requests_total|scheduler_e2e_scheduling_duration_seconds_count|scheduler_e2e_scheduling_duration_seconds_sum|scheduler_pending_pods|scheduler_pod_scheduling_attempts_count|scheduler_pod_scheduling_attempts_sum|scheduler_schedule_attempts_total|workqueue_adds_total|workqueue_depth|workqueue_queue_duration_seconds_count|workqueue_queue_duration_seconds_sum|workqueue_retries_total|workqueue_unfinished_work_seconds|workqueue_work_duration_seconds_count|workqueue_work_duration_seconds_sum|go_gc_duration_seconds|go_gc_duration_seconds_count|go_gc_duration_seconds_sum|go_goroutines|go_info|go_memstats_buck_hash_sys_bytes|go_memstats_gc_sys_bytes|go_memstats_heap_alloc_bytes|go_memstats_heap_idle_bytes|go_memstats_heap_inuse_bytes|go_memstats_heap_released_bytes|go_memstats_heap_sys_bytes|go_memstats_lookups_total|go_memstats_mallocs_total|go_memstats_mcache_inuse_bytes|go_memstats_mcache_sys_bytes|go_memstats_mspan_inuse_bytes|go_memstats_mspan_sys_bytes|go_memstats_next_gc_bytes|go_memstats_stack_inuse_bytes|go_memstats_stack_sys_bytes|go_memstats_sys_bytes|go_threads|apiserver_client_certificate_expiration_seconds_bucket|apiserver_client_certificate_expiration_seconds_sum|apiserver_client_certificate_expiration_seconds_count) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-scheduler/"},{"id":571,"title":"Kubernetes storage","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 8 metrics.\nList of Alerts Alert Description Format [k8s-storage] High Storage Error Rate High Storage Error Rate Prometheus [k8s-storage] High Storage Latency High Storage Latency Prometheus List of Metrics Metric name kube_persistentvolume_status_phase kube_persistentvolumeclaim_status_phase kubelet_volume_stats_capacity_bytes kubelet_volume_stats_inodes kubelet_volume_stats_inodes_used kubelet_volume_stats_used_bytes storage_operation_duration_seconds_bucket storage_operation_duration_seconds_count PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: k8s-storage-default scrape_interval: 60s bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: node relabel_configs: - action: keep source_labels: [__meta_kubernetes_node_address_InternalIP] regex: __HOSTIPS__ - action: labelmap regex: __meta_kubernetes_node_label_(.+) replacement: kube_node_label_$1 - replacement: localhost:10250 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_node_name] target_label: kube_node_name metric_relabel_configs: # - source_labels: [__name__] # regex: \u0026#34;storage(.+)\u0026#34; # action: keep - source_labels: [__name__] regex: (storage_operation_duration_seconds_bucket|storage_operation_duration_seconds_count) action: keep - action: replace source_labels: [namespace] target_label: kube_namespace_name ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/k8s-storage/"},{"id":572,"title":"Legacy Alerts Editor","content":"Alert TypesThe types of alerts available in Sysdig Monitor:\nDowntime: Monitor any type of entity, such as a host, a container, or a process, and alert when the entity goes down.\nMetric: Monitor time-series metrics, and alert if they violate user-defined thresholds.\nPromQL: Monitor metrics through a PromQL query.\nEvent: Monitor occurrences of specific events, and alert if the total number of occurrences violates a threshold. Useful for alerting on container, orchestration, and service events like restarts and unauthorized access.\nAnomaly Detection: Monitor hosts based on their historical behaviors, and alert when they deviate from the expected pattern.\nGroup Outlier: Monitor a group of hosts and be notified when one acts differently from the rest. Group Outlier Alert is supported only on hosts.\nAlert ToolsThe following tools help with alert creation:\nAlert Library: Sysdig Monitor provides a set of alerts by default. Use it as it is or as a template to create your own.\nSysdig API: Use Sysdig\u0026rsquo;s Python client to create, list, delete, update and restore alerts. See examples.\nGuidelines for Creating Alerts Steps\nDescription\nDecide What to monitor\nDetermine what type of problem you want to be alerted on. See Alert Types to choose a type of problem.\nDefine how it will be monitored\nSpecify exactly what behavior triggers a violation. For example, Marathon App is down on the Kubernetes Cluster named Production for ten minutes.\nDecide Where to monitor\nNarrow down your environment to receive fine-tuned results. Use Scope to choose an entity that you want to keep a close watch on. Specify additional segments (entities) to give context to the problem. For example, in addition to specifying a Kubernetes cluster, add a namespace and deployment to refine your scope.\nDefine when to notify\nDefine the threshold and time window for assessing the alert condition.\nSingle Alert fires an alert for your entire scope, while Multiple Alert fires if any or every segment breach the threshold at once.\nMultiple Alerts include all the segments you specified to uniquely identify the location and thus provides a full qualification of where the problem occurred. The higher the number of segments the easier to uniquely identify the affected entities.\nA good analogy for multiple alerts is alerting on cities. For example, creating multiple alerts on San Francisco would trigger an alert which will include information such as the country that it is part of is the USA and the continent is North America.\nTrigger gives you control over how notifications are created. For example, you may want to receive a notification for every violation, or want only a single notification for a series of consecutive violations.\nDecide how notifications are sent\nAlert supports customizable notification channels, including email, mobile push notifications, OpsGenie, Slack, and more. To see supported services, see Set Up Notification Channels.\nTo create alerts, simply:\nChoose an alert type.\nConfigure alert parameters.\nConfigure the notification channels you want to use for alert notification.\nSysdig sometimes deprecates outdated metrics. Alerts that use these metrics will not be modified or disabled, but will no longer be updated. See Deprecated Metrics and Labels.\nConfigure AlertsUse the Alert wizard to create or edit alerts.\nOpen the Alert WizardThere are multiple ways to access the Alert wizard:\nFrom ExploreDo one of the following:\nSelect New Alert next to an entity.\nClick More Options (three dots), and select Create a new alert.\nFrom DashboardsClick the More Options (three dots) icon for a panel, and select Create Alert.\nFrom AlertsDo one of the following:\nClick Add Alerts.\nSelect an existing alert and click Edit.\nFrom OverviewFrom the Events panel on the Overview screen, select a custom or an Infrastructure type event. From the event description screen, click Create Alert from Event.\nCreate an AlertConfigure notification channels before you begin, so the channels are available to assign to the alert. Optionally, you can add a custom subject and body information into individual alert notifications.\nEnter Basic Alert InformationConfiguration slightly defers for each Alert type. See respective pages to learn more. This section covers general instructions to help you acquainted with and navigate the Alerts user interface.\nTo configure an alert, open the Alert wizard and set the following parameters:\nCreate the alert:\nType: Select the desired Alert Types.\nEach type has different parameters, but they follow the same pattern:\nName: Specify a meaningful name that can uniquely represent the Alert that you are creating. For example, the entity that an alert targets, such as Production Cluster Failed Scheduling pods.\nGroup (optional): Specify a meaningful group name for the alert you are creating. Group name helps you narrow down the problem area and focus on the infrastructure view that needs your attention. For example, you can enter Redis for alerts related to Redis services. When the alert triggers you will know which service in your workload requires inspection. Alerts that have no group name will be added to the Default Group. Group name is editable. Edit the alert to do so.\nAn alert can belong to only one group. An alert created from an alert template will have the group already configured by the Monitor Integrations. You can see the existing alert groups on the Alerts details page.\nSee Groupings for more information on how Sysdig handles infrastructure views.\nDescription (optional): Briefly expand on the alert name or alert condition to give additional context for the recipient.\nPriority: Select a priority. High, Medium, Low, and Info. You can later sort by the severity by using the top navigation pane.\nSpecify the parameters in the Define, Notify, and Act sections.\nDefine:\nBased on the alert type, define the parameters.\nDowntime: Select the entity to monitor. For more information, see Downtime Alert.\nMetric: Select a metric that this alert will monitor. You also define how the data is aggregated, such as average, maximum, minimum, or sum. Metrics are applied to a group of items (group aggregation). For more information, see Metric Alerts.\nPromQL: Enter the PromQL query and duration. For more information, see PromQL Alerts.\nEvent: Filter the custom event to be alerted on by using the name, tag, description and one or more event sources. For more information, see Event Alerts\nAnomaly Detection: Specify the metrics to be monitored for anomalies. For more information, see Anomaly Detection Alerts.\nGroup Outlier: Specify the metrics to be monitored for outliers. For more information, see Group Outlier Alerts.\nTo alert on multiple metrics using boolean logic, click Create multi-condition alerts. See Multi-Condition Alerts.\nScope: Everywhere, or a more limited scope to filter a specific component of the infrastructure monitored, such as a Kubernetes deployment, a Sysdig Agent, or a specific service.\nTrigger: Boundaries for assessing the alert condition, and whether to send a single alert or multiple alerts. Supported time scales are minute, hour, or day.\nSingle alert: Single Alert fires an alert for your entire scope.\nMultiple alerts: Multiple Alert fires if any or every segment breaches the threshold at once.\nMultiple alerts are triggered for each segment you specify. The specified segments will be represented in alerts. The higher the number of segments the easier to uniquely identify the affected entities.\nFor detailed description, see respective sections on Alert Types.\n(2) Notify\nNotification Channel: Select from the configured notification channels in the list. Supported channels are:\nEmail\nSlack\nAmazon SNS Topic\nOpsgenie\nPagerduty\nVictorOps\nWebhook\nYou can view the list of notification channels configured for each alert on the Alerts page.\nNotification Options: Set the time interval at which multiple alerts should be sent.\nFormat Message: If applicable, add message format details. See Customize Notifications.\n(3) Act\n(Optional): Configure a Sysdig capture. See also Captures.\nSysdig capture files are not available for Event Alerts.\nClick Create.\nOptional: Customize NotificationsYou can optionally customize individual notifications to provide context for the errors that triggered the alert. All the notification channels support this added contextual information and customization flexibility.\nModify the subject, body, or both of the alert notification with the following:\nPlaintext: A custom message stating the problem. For example, Stalled Deployment.\nHyperlink: For example, URL to a Dashboard.\nDynamic Variable: For example, a hostname. Note the conventions:\nAll variables that you insert must be enclosed in double curly braces, such as {{file_mount}}.\nVariables are case sensitive.\nThe variables should correspond to the segment values you created the alert for. For example, if an alert is segmented byhost.hostName andcontainer.name, the corresponding variables will be{{host.hostName}}and {{container.name}} respectively. In addition to these segment variables, __alert_name__ and __alert_status__ are supported. No other segment variables are allowed in the notification subject and body.\nNotification subjects will not show up on the Event feed.\nUsing a variable that is not a part of the segment will trigger an error.\nThe segment variables used in an alert are turned to the current system values upon sending the alert.\nThe body of the notification message contains a Default Alert Template. It is the default alert notification generated by Sysdig Monitor. You may add free text, variables, or hyperlinks before and after the template.\nYou can send a customized alert notification to the following channels:\nEmail\nSlack\nAmazon SNS Topic\nOpsgenie\nPagerduty\nVictorOps\nWebhook\nMulti-Condition AlertsMulti-condition alerts are advanced alert threshold created on complex conditions. To do so, you define alert thresholds as custom boolean expressions that can involve multiple conditions. Click Create multi-condition alerts to enable adding conditions as boolean expressions.\nThese advanced alerts require specific syntax, as described in the examples below.\nFormat and OperationsEach condition has five parts:\nMetric Name : Use the exact metric names. To avoid typos, click the HELP link to access the drop-down list of available metrics. Selecting a metric from the list will automatically add the name to the threshold expression being edited.\nGroup Aggregation (optional): If no group aggregation type is selected, the appropriate default for the metric will be applied (either sum or average). Group aggregation functions must be applied outside of time aggregation functions.\nTime aggregation : It\u0026rsquo;s the historical data rolled up over a selected period of time.\nOperator: Both logical and relational operators are supported.\nValue: A static numerical value against which a condition is evaluated.\nThe table below displays supported time aggregation functions, group aggregation functions, and relational operators:\nTime Aggregation Function Group Aggregation Function Relational Operator timeAvg() avg() = min() min() \u0026lt; max() max() \u0026gt; sum() sum() \u0026lt;= \u0026gt;= != The format is:\ncondition1 AND condition2 condition1 OR condition2 NOT condition1 The order of operations can also be altered via parenthesis:\nNOT (condition1 AND (condition2 OR condition3)) Conditions take the following form:\ngroupAggregation(timeAggregation(metric.name)) operator value Example ExpressionsSeveral examples of advanced alerts are given below:\ntimeAvg(cpu.used.percent) \u0026gt; 50 AND timeAvg(memory.used.percent) \u0026gt; 75 timeAvg(cpu.used.percent) \u0026gt; 50 OR timeAvg(memory.used.percent) \u0026gt; 75 timeAvg(container.count) != 10 min(min(cpu.used.percent)) \u0026lt;= 30 OR max(max(cpu.used.percent)) \u0026gt;= 60 sum(file.bytes.total) \u0026gt; 0 OR sum(net.bytes.total) \u0026gt; 0 timeAvg(cpu.used.percent) \u0026gt; 50 AND (timeAvg(mysql.net.connections) \u0026gt; 20 OR timeAvg(memory.used.percent) \u0026gt; 75) ","url":"https://docs.sysdig.com/en/sysdig-monitor/-legacy-alerts-editor/"},{"id":573,"title":"Legacy PromQL Alerts","content":"ExamplesFor PromQL alerts, you can use any metric that is available in PromQL, including Sysdig native metrics. For more details see the various integrations available on promcat.io.\nLow Disk Space AlertWarn if disk space falls below a specified quantity. For example disk space is below 10GB in the 24h hour:\npredict_linear(sysdig_fs_free_bytes{fstype!~\u0026#34;tmpfs\u0026#34;}[1h], 24*3600) \u0026lt; 10000000000 Slow Etcd RequestsNotify if etcd requests are slow. This example uses the promcat.io integration.\nhistogram_quantile(0.99, rate(etcd_http_successful_duration_seconds_bucket[5m]) \u0026gt; 0.15 High Heap UsageWarn when the heap usage in ElasticSearch is more than 80%. This example uses the promcat.io integration.\n(elasticsearch_jvm_memory_used_bytes{area=\u0026#34;heap\u0026#34;} / elasticsearch_jvm_memory_max_bytes{area=\u0026#34;heap\u0026#34;}) * 100 \u0026gt; 80 GuidelinesSysdig Monitor does not currently support the following:\nInteract with the Prometheus alert manager or import alert manager configuration.\nProvide the ability to use, copy, paste, and import predefined alert rules.\nConvert the alert rules to map to the Sysdig alert editor.\nCreate a PromQL AlertSet a meaningful name and description that help recipients easily identify the alert.\nSet a PrioritySelect a priority for the alert that you are creating. The supported priorities are High, Medium, Low, and Info. You can also view and sort events in the dashboard and explore UI, as well as sort them by severity.\nDefine a PromQL AlertPromQL: Enter a valid PromQL expression. The query will be executed every minute. However, the alert will be triggered only if the query returns data for the specified duration.\nIn this example, you will be alerted when the rate of HTTP requests has doubled over the last 5 minutes.\nDuration: Specify the time window for evaluating the alert condition in minutes, hour, or day. The alert will be triggered if the query returns data for the specified duration.\nDefine NotificationNotification Channels: Select from the configured notification channels in the list.\nRe-notification Options: Set the time interval at which multiple alerts should be sent if the problem remains unresolved.\nNotification Message \u0026amp; Events: Enter a subject and body. Optionally, you can choose an existing template for the body. Modify the subject, body, or both for the alert notification with a hyperlink, plain text, or dynamic variables.\nImport Prometheus Alert RulesSysdig Alert allows you to import Prometheus rules or create new rules on the fly and add them to the existing list of alerts. Click the Upload Prometheus Rules option and enter the rules as YAML in the Upload Prometheus Rules YAML editor. Importing your Prometheus alert rules will convert them to PromQL-based Sysdig alerts. Ensure that the alert rules are valid YAML.\nYou can upload one or more alert rules in a single YAML and create multiple alerts simultaneously.\nOnce the rules are imported to Sysdig Monitor, the alert list will be automatically sorted by last modified date.\nBesides the pre-populated template, each rule specified in the Upload Prometheus Rules YAML editor requires the following fields:\nalert\nexpr\nfor\nSee the following examples to understand the format of Prometheus Rules YAML. Ensure that the alert rules are valid YAML to pass validation.\nExample: Alert Prometheus Crash LoopingTo alert potential Prometheus crash looping. Create a rule to alert when Prometheus restart more than twice in the last 10 minutes.\ngroups: - name: crashlooping rules: - alert: PrometheusTooManyRestarts expr: changes(process_start_time_seconds{job=~\u0026#34;prometheus|pushgateway|alertmanager\u0026#34;}[10m]) \u0026gt; 2 for: 0m labels: severity: warning annotations: summary: Prometheus too many restarts (instance {{ $labels.instance }}) description: Prometheus has restarted more than twice in the last 15 minutes. It might be crashlooping.\\n VALUE = {{ $value }}\\n Example: Alert HTTP Error RateTo alert HTTP requests with status 5xx (\u0026gt; 5%) or high latency:\ngroups: - name: default rules: # Paste your rules here - alert: NginxHighHttp5xxErrorRate expr: sum(rate(nginx_http_requests_total{status=~\u0026#34;^5..\u0026#34;}[1m])) / sum(rate(nginx_http_requests_total[1m])) * 100 \u0026gt; 5 for: 1m labels: severity: critical annotations: summary: Nginx high HTTP 5xx error rate (instance {{ $labels.instance }}) description: Too many HTTP requests with status 5xx - alert: NginxLatencyHigh expr: histogram_quantile(0.99, sum(rate(nginx_http_request_duration_seconds_bucket[2m])) by (host, node)) \u0026gt; 3 for: 2m labels: severity: warning annotations: summary: Nginx latency high (instance {{ $labels.instance }}) description: Nginx p99 latency is higher than 3 seconds Learn More PromQL Query Explorer\nPromQL Library\nRun PromQL Queries Faster with Extended Label Set\n","url":"https://docs.sysdig.com/en/sysdig-monitor/-legacy-alerts-editor/legacy-promql-alerts/"},{"id":574,"title":"Linux","content":" This integration is enabled by default.\nThis integration has 18 metrics.\nList of Alerts Alert Description Format [Linux] High CPU Usage The CPU of the Linux instance reached 95% of use Prometheus [Linux] High Disk Usage Disk full over 95% in host Prometheus [Linux] Disk Will Fill In 12 Hours Disk full in 12h in host Prometheus [Linux] High Physical Memory Usage High physical memory usage in instance Prometheus List of DashboardsLinux Host OverviewThe dashboard provides a general overview for a regular Linux host. List of Metrics Metric name sysdig_fs_used_percent sysdig_host_cpu_cores_used_percent sysdig_host_cpu_system_percent sysdig_host_file_open_count sysdig_host_file_total_bytes sysdig_host_fs_free_bytes sysdig_host_fs_used_percent sysdig_host_memory_available_bytes sysdig_host_memory_used_percent sysdig_host_net_connection_in_count sysdig_host_net_connection_out_count sysdig_host_net_total_bytes sysdig_program_cpu_used_percent sysdig_program_file_open_count sysdig_program_memory_used_percent sysdig_program_net_connection_total_count sysdig_program_net_request_in_count sysdig_program_net_total_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting LinuxThe Linux integration uses the out-of-the-box sysdig_host_* and sysdig_program_* metrics in the dashboards and alerts.\nSysdig Host Metrics Documentation Sysdig Program Metrics Documentation Agent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/linux/"},{"id":575,"title":"Manage Scanning Alerts","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nExamples of when you might implement alerts:\nI want to know if there are new CVE updates for the 3 different images I handle\nI want to be notified if any of the common images from docker hub that are used all over my organization have a policy status that has changed\nManage the Scanning Alert ListFrom the Image Scanning module, choose the Alerts tab. The Scanning Alert list is displayed.\nFrom here you can search for existing alerts, and create, duplicate or delete alerts.\nAdd an Alert To create a new alert: From the Image Scanning module, choose the Alerts tab and click Add Alert.\nSelect either Runtime or Repository alert type.\nFill in the appropriate New Alert page (below).\nCreate a Runtime AlertUse Runtime alerts to scan running images and trigger a notification in case of a policy violation, status change, or unscanned image added to the environment. Enter the alert parameters and click Save.\nBasic ParametersEnter a Name and optional Description.\nScopeUse Everywhere or define a narrower scope.\nTriggersUnscanned ImageCheck the box to trigger an alert. To have images scanned automatically instead of simply triggering the alert, install the Node Image Analyzer.\nNote that this is a change from the way automated scanning was handled in previous releases.\nScan Result Change Pass/Fail: Choose this option to be notified when an image that had previously passed now fails its policy evaluation.\nAny Change: Choose this option to be notified when there is any change on a previously scanned image result.\nNote that if Scan Result Change is checked and a notification channel is configured, an alert will be sent. If no channel is set up, nothing will happen.\nFor example, the following image shows a Slack notification that was triggered when \u0026ldquo;Any Change\u0026rdquo; was configured.\nCVE UpdateChoose this option to be notified whenever a vulnerability is added, updated, or removed from a running image.\nNotification ChannelClick Add Channel to select a configured notification channel (e.g. email) to be used for alert notifications.\nIf no notification channels have been defined for your Sysdig Secure environment yet, see Set Up Notification Channels.\nOpsGenie and ViktorOps notification channels are not supported for image scanning alerts.\nCreate a Repository AlertUse Repository alerts to scan static images in the repository and trigger a notification in case of a policy violation, status change, or a new image added to the environment. Enter the alert parameters and click Save.\nBasic ParametersEnter a Nameand optional Description.\nRegistry/Repo/TagEnter the registry scope to be considered in the alert. Wildcards * are supported. If a wildcard is used for either the registry or the repo, the only alert option will be New Image Analyzed.\nTriggersNew Image AnalyzedCheck the box to be alerted whenever a new image is analyzed, regardless of the result.\nScan Result Change Pass/Fail: Choose this option to be notified when an image that had previously passed now fails its policy evaluation.\nAny Change: Choose this option to be notified when there is any change on a previously scanned image result.\nNote that if Scan Result Change is checked and a notification channel is configured, an alert will be sent. If no channel is set up, nothing will happen.\nCVE UpdateChoose this option to be notified whenever a vulnerability is added, updated, or removed from an image within the repository alert scope.\nFor example, the following image shows a Slack notification that was triggered when \u0026ldquo;CVE Update\u0026rdquo; was configured.\nNotification ChannelClick Add Channel to select a configured notification channel (e.g. email) to be used for alert notifications.\nIf no notification channels have been defined for your Sysdig Secure environment yet, see Set Up Notification Channels.\nEdit an Alert From the Image Scanning module, choose the Alerts tab.\nSelect the desired alert from the list.\nEdit the alert trigger, scope, and notification channels as necessary, and click Save.\nDuplicate an Alert From the Image Scanning module, choose the Alerts tab.\nSelect the desired alert from the list.\nClick the More (three dots) icon and click Duplicate Alert from the drop-down, then Yes to confirm.\nDelete an Alert From the Image Scanning module, choose the Alerts tab.\nSelect the desired alert from the list.\nClick the More (three dots) icon and click Delete Alert from the drop-down, then Yes to confirm.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/manage-scanning-alerts/"},{"id":576,"title":"Sysdig On-Premises Release Notes","content":" Supported Web Browsers: Sysdig supports, tests, and verifies the latest versions of Chrome and Firefox. Other browsers may also work but are not tested with the same rigour. Falco Rules: You may also want to review the update log for Falco Rules. used in the Sysdig Secure Policy Editor. 7.7.1 Hotfix Release, April 2026Upgrade ProcessDirect upgrades are supported from version: 6.x, 7.x\nFor compatibility matrix, see Kubernetes support matrix. For installation and upgrade instructions, see Installation overview.\nDefect FixesImproved PostgreSQL maintenance to automatically clean up unused large objects and prevent excessive WAL and disk growth.\n7.7.0 Release, April 2026Upgrade ProcessDirect upgrades are supported from version: 6.x, 7.x\nFor compatibility matrix, see Kubernetes support matrix. For installation and upgrade instructions, see Installation overview.\nSysdig SecureLocal Scanning for Kubernetes Container WorkloadsSysdig Secure now supports Local Scanning, a new deployment option for Sysdig Vulnerability Management that runs scanners directly on Kubernetes nodes and hosts to discover and analyze images in place, including ephemeral and non‑registry images. This reduces dependence on central registries, closes visibility gaps across complex environments, and makes it easier to scale vulnerability coverage. Local Scanning requires Host Shield 14.5.0) or later.\nFor more information, see Local Scanning.\nHost and Kubernetes Response Actions in AutomationsAutomations triggered from Runtime Events now support the full set of response actions, enabling faster containment and forensics directly from detections:\nKill container Stop container Pause container Kill Process File acquire File quarantine Kill Pod Kubernetes Rollout restart Kubernetes Volume snapshot Kubernetes Get Logs Kubernetes Network isolate For more information, see Response Actions in Automations.\nGraph SearchGraph Search introduces an intuitive query builder on top of our graph database, allowing users to explore relationships across their On-Premise environments and Kubernetes assets and quickly surface the security issues that matter most in their environments. For more information, see Graph Search.\nSysdig PlatformOn-Prem Platform Version in UIYou can now access the On-Prem platform version directly in the UI from the Version \u0026amp; License page under Settings, making it easier for administrators to see which Sysdig On-Prem release is running.\n7.6.0 Release, February 2026Upgrade ProcessDirect upgrades are supported from version: 6.x, 7.x\nFor compatibility matrix, see Kubernetes support matrix. For installation and upgrade instructions, see Installation overview.\nSysdig SecureRuntime Detection: File Integrity Monitoring (FIM)A new runtime detection type, File Integrity Monitoring (FIM), is now available. FIM enables you to monitor file changes and create detection policies aligned with PCI DSS requirements 10.5.5 and 11.5. FIM monitoring requires Host Shield version 14.3 or later.\nFor more information, see FIM Policies.\nEvents Feed: Customizable ColumnsYou can now customize the columns displayed in the Events Feed to view relevant attributes directly in the event list, without opening individual events. For more information, see Events Feed.\nRisk Spotlight (In-Use) Support for Non-Kubernetes ContainersRisk Spotlight (In-Use) prioritization now supports non-Kubernetes container workloads, including Docker and Podman containers running on Linux hosts protected by Sysdig Host Shield. This enhancement allows you to reduce vulnerability noise and prioritize remediation efforts for your entire Linux ecosystem by focusing on the vulnerabilities that are actively executable across your Linux container environments.\nFor more information, see Risk Spotlight.\nChanges to List Matching Policies and RulesCreation of new List Matching Policies and Rules is no longer supported. Existing policies and rules continue to function and can still be modified.\nFor new detections, use Falco rules, which provide expanded detection capabilities and flexibility.\nFor more information, see List Matching Policy.\nZones: Additional Filtering OperatorsTwo new filtering operators are available for Zones:\nis not does not contain These operators enable more precise exclusion filtering for events and findings.\nSysdig MonitorRecurring Alert Silencing RulesAlert silencing rules now support recurring schedules, allowing you to automatically mute alerts during defined maintenance windows (for example, daily or weekly). Silences can be applied to the entire infrastructure within the selected team scope.\nFor more information, see Configure Recurring Silence Rule.\n","url":"https://docs.sysdig.com/en/release-notes/sysdig-on-premises-release-notes/"},{"id":577,"title":"OpenShift API-Server","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nVersions supported: \u0026gt; v4.8\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 18 metrics.\nTimeseries generated: API Server generates ~5k timeseries\nList of Alerts Alert Description Format [OpenShift API Server] Deprecated APIs API-Server Deprecated APIs Prometheus [OpenShift API Server] Certificate Expiry API-Server Certificate Expiry Prometheus [OpenShift API Server] Admission Controller High Latency API-Server Admission Controller High Latency Prometheus [OpenShift API Server] Webhook Admission Controller High Latency API-Server Webhook Admission Controller High Latency Prometheus [OpenShift API Server] High 4xx RequestError Rate APIS-Server High 4xx Request Error Rate Prometheus [OpenShift API Server] High 5xx RequestError Rate APIS-Server High 5xx Request Error Rate Prometheus [OpenShift API Server] High Request Latency APIS-Server High Request Latency Prometheus List of DashboardsOpenShift v4 API ServerThe dashboard provides information on the K8s API Server and OpenShift API Server. List of Metrics Metric name apiserver_admission_controller_admission_duration_seconds_count apiserver_admission_controller_admission_duration_seconds_sum apiserver_admission_webhook_admission_duration_seconds_count apiserver_admission_webhook_admission_duration_seconds_sum apiserver_client_certificate_expiration_seconds_bucket apiserver_client_certificate_expiration_seconds_count apiserver_request_duration_seconds_count apiserver_request_duration_seconds_sum apiserver_request_total apiserver_requested_deprecated_apis apiserver_response_sizes_count apiserver_response_sizes_sum apiserver_tls_handshake_errors_total go_goroutines process_cpu_seconds_total process_resident_memory_bytes workqueue_adds_total workqueue_depth PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting OpenShift API ServerBecause OpenShift 4.X comes with both Prometheus and API servers ready to use, no additional installation is required. The OpenShift API server metrics are exposed using the \\federated endpoint.\nLearning how to monitor Kubernetes API server is vital when running Kubernetes in production. Monitoring kube-apiserver will help you detect and troubleshoot latency and errors, and validate whether the service performs as expected.\nHere are some interesting queries to run and metrics to monitor for troubleshooting the OpenShift API Server.\nDeprecated APIsTo check if deprecated API versions are used, use the following query:\nsum by (kube_cluster_name, resource, removed_release,version)(apiserver_requested_deprecated_apis) Certificate ExpirationCertificates are used to authenticate to the API server, and you can check with the following query if a certificate is expiring next week:\napiserver_client_certificate_expiration_seconds_count \u0026gt; 0 and histogram_quantile(0.01, sum by (job, le) (rate(apiserver_client_certificate_expiration_seconds_bucket[5m]))) \u0026lt; 7*24*60*60 API Server LatencyLatency spike is typically a sign of overload in the API server. Probably your cluster has a high load and the API server needs to be scaled out. Use the following query to check for latency spikes in the last 10 minutes.\nsum by (kube_cluster_name,verb,apiserver)(rate(apiserver_request_duration_seconds_sum{verb!=\u0026#34;WATCH\u0026#34;}[10m]))/sum by (kube_cluster_name,verb,apiserver)(rate(apiserver_request_duration_seconds_count{verb!=\u0026#34;WATCH\u0026#34;}[10m])) Request Error RateRequest errror rate means that the API server is responding with 5xx errors. Check the CPU and memory of your api-server pods.\nsum by(kube_cluster_name)(rate(apiserver_request_total{code=~\u0026#34;5..\u0026#34;,kube_cluster_name=~$cluster}[5m])) / sum by(kube_cluster_name)(rate(apiserver_request_total{kube_cluster_name=~$cluster}[5m])) \u0026gt; 0.05 Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: openshift-apiserver-default honor_labels: true scheme: https bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true metrics_path: \u0026#39;/federate\u0026#39; params: \u0026#39;match[]\u0026#39;: - \u0026#39;{__name__=~\u0026#34;apiserver_request_total|apiserver_request_duration_seconds_sum|apiserver_request_duration_seconds_count|workqueue_adds_total|workqueue_depth|apiserver_response_sizes_sum|apiserver_response_sizes_count|apiserver_requested_deprecated_apis|apiserver_client_certificate_expiration_seconds_bucket|apiserver_client_certificate_expiration_seconds_count|apiserver_admission_controller_admission_duration_seconds_sum|apiserver_admission_controller_admission_duration_seconds_count|apiserver_admission_webhook_admission_duration_seconds_sum|apiserver_admission_webhook_admission_duration_seconds_count|apiserver_tls_handshake_errors_total|go_goroutines|process_resident_memory_bytes|process_cpu_seconds_total\u0026#34;,code!=\u0026#34;0\u0026#34;}\u0026#39; kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;openshift-monitoring/prometheus-k8s-0\u0026#39; # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_apiserver replacement: true metric_relabel_configs: - source_labels: [__name__] regex: (apiserver_request_total|apiserver_request_duration_seconds_sum|apiserver_request_duration_seconds_count|workqueue_adds_total|workqueue_depth|apiserver_response_sizes_sum|apiserver_response_sizes_count|apiserver_requested_deprecated_apis|apiserver_client_certificate_expiration_seconds_bucket|apiserver_client_certificate_expiration_seconds_count|apiserver_admission_controller_admission_duration_seconds_sum|apiserver_admission_controller_admission_duration_seconds_count|apiserver_admission_webhook_admission_duration_seconds_sum|apiserver_admission_webhook_admission_duration_seconds_count|apiserver_tls_handshake_errors_total|go_goroutines|process_resident_memory_bytes|process_cpu_seconds_total) action: keep - action: replace source_labels: [namespace] target_label: kube_namespace_name - action: replace source_labels: [pod] target_label: kube_pod_name - action: replace target_label: job replacement: openshift-apiserver-default ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/openshift-api-server/"},{"id":578,"title":"OpenShift Controller Manager","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v4.8\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 12 metrics.\nTimeseries generated: Controller Manager generates ~650 timeseries\nList of Alerts Alert Description Format [OpenShift Controller Manager] Process Down Controller Manager has disappeared from target discovery. Prometheus [OpenShift Controller Manager] High 4xx RequestError Rate OpenShift Controller Manager High 4xx Request Error Rate Prometheus [OpenShift Controller Manager] High 5xx RequestError Rate OpenShift Controller Manager High 5xx Request Error Rate Prometheus List of DashboardsOpenShift v4 Controller Manager If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_controller_manager replacement: true The dashboard provides information on the K8s and OpenShift Controller Manager. List of Metrics Metric name go_goroutines rest_client_requests_total sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes workqueue_adds_total workqueue_depth workqueue_queue_duration_seconds_count workqueue_queue_duration_seconds_sum workqueue_retries_total workqueue_unfinished_work_seconds workqueue_work_duration_seconds_count workqueue_work_duration_seconds_sum PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting OpenShift Controller ManagerBecause OpenShift 4.X comes with both Prometheus and Controller Manager ready to use, no additional installation is required. The OpenShift Controller Manager metrics are exposed using a federated endpoint.\nHere are some interesting queries to run and metrics to monitor for troubleshooting the OpenShift Controller Manager.\nWork QueueWork Queue RetriesThe total number of retries that have been handled by the work queue. This value should be near 0.\ntopk(30,rate(workqueue_retries_total{job=\u0026#34;openshift-controller-default\u0026#34;}[10m])) Work Queue LatencyQueue latency is the time tasks spend in the queue before being processed\ntopk(30,rate(workqueue_queue_duration_seconds_sum{job=\u0026#34;openshift-controller-default\u0026#34;}[10m]) / rate(workqueue_queue_duration_seconds_count{job=\u0026#34;openshift-controller-default\u0026#34;}[10m])) Work Queue DepthThis query checks the depth of the queue. High values can indicate the saturation of the controller manager.\ntopk(30,rate(workqueue_depth{job=\u0026#34;openshift-controller-default\u0026#34;}[10m])) Scheduler API RequestsKube API Requests By CodeCheck that there are no 5xx or 4xx error codes in the scheduler requests.\nsum by (kube_cluster_name,kube_pod_name)(rate(rest_client_requests_total{job=\u0026#34;openshift-controller-default\u0026#34;,code=~\u0026#34;4..\u0026#34;}[10m])) sum by (kube_cluster_name,kube_pod_name)(rate(rest_client_requests_total{job=\u0026#34;openshift-controller-default\u0026#34;,code=~\u0026#34;5..\u0026#34;}[10m])) Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: openshift-controller-manager-default honor_labels: true scheme: https bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true metrics_path: \u0026#39;/federate\u0026#39; params: \u0026#39;match[]\u0026#39;: - \u0026#39;{job=~\u0026#34;kube-controller-manager|controller-manager\u0026#34;,__name__=~\u0026#34;workqueue_retries_total|workqueue_unfinished_work_seconds|workqueue_queue_duration_seconds_count|workqueue_work_duration_seconds_count|workqueue_queue_duration_seconds_sum|workqueue_work_duration_seconds_sum|workqueue_depth|workqueue_adds_total|rest_client_requests_total|go_goroutines\u0026#34;}\u0026#39; kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;openshift-monitoring/prometheus-k8s-1\u0026#39; # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name # Remove extended labelset - action: replace replacement: true target_label: sysdig_omit_source metric_relabel_configs: - source_labels: [__name__] regex: (go_goroutines|rest_client_requests_total|sysdig_container_cpu_cores_used|sysdig_container_memory_used_bytes|workqueue_adds_total|workqueue_depth|workqueue_queue_duration_seconds_count|workqueue_queue_duration_seconds_sum|workqueue_retries_total|workqueue_unfinished_work_seconds|workqueue_work_duration_seconds_count|workqueue_work_duration_seconds_sum) action: keep - action: replace source_labels: [namespace] target_label: kube_namespace_name - action: replace source_labels: [pod] target_label: kube_pod_name - source_labels: [job] target_label: controller - action: replace target_label: job replacement: openshift-controller-manager-default - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_controller_manager replacement: true - action: replace source_labels: [controller] regex: \u0026#39;(controller-manager)\u0026#39; target_label: controller replacement: \u0026#39;openshift-$1\u0026#39; ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/openshift-controller-manager/"},{"id":579,"title":"OpenShift CoreDNS","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v4.8\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 13 metrics.\nTimeseries generated: CoreDNS generates ~230 timeseries per dns-default pod\nList of Alerts Alert Description Format [OpenShift CoreDNS] Process Down CoreDNS has disappeared from target discovery. Prometheus [OpenShift CoreDNS] High Failed Responses CoreDNS is returning failed responses. Prometheus [OpenShift CoreDNS] High Latency CoreDNS responses latency is higher than 60ms. Prometheus [OpenShift CoreDNS] Panics Observed CoreDNS Panics Observed. Prometheus List of DashboardsOpenShift v4 CoreDNS If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_coredns replacement: true The dashboard provides information on the OpenShift CoreDNS. List of Metrics Metric name coredns_cache_hits_total coredns_cache_misses_total coredns_dns_request_duration_seconds_bucket coredns_dns_request_size_bytes_bucket coredns_dns_requests_total coredns_dns_response_size_bytes_bucket coredns_dns_responses_total coredns_forward_request_duration_seconds_bucket coredns_panics_total coredns_plugin_enabled go_goroutines process_cpu_seconds_total process_resident_memory_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting OpenShift CoreDNSBecause OpenShift 4.X comes with both Prometheus and CoreDNS ready to use, no additional installation is required. OpenShift CoreDNS metrics are exposed on the SSL port 9154.\nHere are some interesting queries to run and metrics to monitor for troubleshooting OpenShift 4.\nCoreDNS PanicsNumber of PanicsTo check the CoreDNS number of panics, use the following query:\nsum(coredns_panics_total) See the CoreDNS pods logs when you see this number growing.\nDNS RequestsBy TypeTo filter DNS request types, use the following query:\n(sum(rate(coredns_dns_requests_total[$__interval])) by (type,kube_cluster_name,kube_pod_name)) By ProtocolTo filter DNS request types by protocol, use the following query:\n(sum(rate(coredns_dns_requests_total[$__interval]) ) by (proto,kube_cluster_name,kube_pod_name)) By ZoneTo filter DNS request types by zone, use the following query:\n(sum(rate(coredns_dns_requests_total[$__interval]) ) by (zone,kube_cluster_name,kube_pod_name)) By LatencyThis metrics detects any degradation in the service. With the following query, you can compare percentile 99 against average.\nhistogram_quantile(0.99, sum(rate(coredns_dns_request_duration_seconds_bucket[5m])) by(server, zone, le)) Error RateWatch carefully for this metric as you can filter depending on the status code: 200,404,400,500.\nsum by (server, status)(coredns_dns_https_responses_total{server, status}) CacheCache HitTo check the cache hit rate, use the following query:\nsum(rate(coredns_cache_hits_total[$__interval])) by (type,kube_cluster_name,kube_pod_name) Cache MissTo check the cache miss rate, use the following query:\nsum(rate(coredns_cache_misses_total[$__interval])) by(server,kube_cluster_name,kube_pod_name) Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: openshift-dns-default honor_labels: true tls_config: insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;openshift-dns/dns-default.+\u0026#39; - source_labels: - __address__ action: keep regex: (.*:9154) - source_labels: - __meta_kubernetes_pod_name action: replace target_label: instance - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_coredns replacement: true metric_relabel_configs: - source_labels: [__name__] regex: (coredns_cache_hits_total|coredns_cache_misses_total|coredns_dns_request_duration_seconds_bucket|coredns_dns_request_size_bytes_bucket|coredns_dns_requests_total|coredns_dns_response_size_bytes_bucket|coredns_dns_responses_total|coredns_forward_request_duration_seconds_bucket|coredns_panics_total|coredns_plugin_enabled|go_goroutines|process_cpu_seconds_total|process_resident_memory_bytes) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/openshift-coredns/"},{"id":580,"title":"OpenShift Etcd","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nVersions supported: \u0026gt; v4.8\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 29 metrics.\nTimeseries generated: Etcd generates ~1200 timeseries per etcd-ip pod\nList of Alerts Alert Description Format [OpenShiftEtcd] Etcd Insufficient Members Etcd cluster has insufficient members. Prometheus [OpenShiftEtcd] Etcd No Leader Member has no leader. Prometheus [OpenShiftEtcd] Etcd High Number Of Leader Changes Leader changes within the last 15 minutes. Prometheus [OpenShiftEtcd] Etcd High Number Of Failed GRPC Requests. High number of failed grpc requests Prometheus [OpenShiftEtcd] Etcd GRPC Requests Slow gRPC requests are taking too much time. Prometheus [OpenShiftEtcd] Etcd High Number Of Failed Proposals High number of proposal failures within the last 30 minutes on etcd instance. Prometheus [OpenShiftEtcd] Etcd High Fsync Durations 99th percentile fync durations are too high. Prometheus [OpenShiftEtcd] Etcd High Commit Durations 99th percentile commit durations are too high. Prometheus [OpenShiftEtcd] Etcd Excesive Database Growth Etcd cluster database is growing very fast. Prometheus List of DashboardsOpenShift v4 Etcd If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_etcd replacement: true The dashboard provides information on the OpenShift Etcd. List of Metrics Metric name etcd_debugging_mvcc_db_total_size_in_bytes etcd_disk_backend_commit_duration_seconds_bucket etcd_disk_wal_fsync_duration_seconds_bucket etcd_grpc_proxy_cache_hits_total etcd_grpc_proxy_cache_misses_total etcd_mvcc_db_total_size_in_bytes etcd_network_client_grpc_received_bytes_total etcd_network_client_grpc_sent_bytes_total etcd_network_peer_received_bytes_total etcd_network_peer_received_failures_total etcd_network_peer_round_trip_time_seconds_bucket etcd_network_peer_sent_bytes_total etcd_network_peer_sent_failures_total etcd_server_has_leader etcd_server_id etcd_server_leader_changes_seen_total etcd_server_proposals_applied_total etcd_server_proposals_committed_total etcd_server_proposals_failed_total etcd_server_proposals_pending etcd_server_quota_backend_bytes go_goroutines grpc_server_handled_total grpc_server_handling_seconds_bucket grpc_server_started_total process_max_fds process_open_fds sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting OpenShift EtcdBecause OpenShift 4.X comes with both Prometheus and API servers ready to use, no additional installation is required. OpenShift Etcd metrics are exposed using the \\federated endpoint.\nHere are some interesting queries to run and metrics to monitor for troubleshooting OpenShift Etcd.\nEtcd Consensus \u0026amp; LeaderProblems in the leader and consensus of the etcd cluster can cause outages in the cluster.\nEtcd Leader If a member does not have a leader, it is totally unavailable. If all the members in a cluster do not have any leader, the entire cluster is totally unavailable. Check the leader using this query:\ncount(etcd_server_id) % 2 If they query returns 1, etcd has a leader.\nLeader ChangesRapid leadership changes impact the performance of etcd significantly and it can also mean that the leader is unstable, perhaps due to network connectivity issues or excessive load hitting the etcd cluster.\nCheck for leader changes in the last hour:\nmax(increase(etcd_server_leader_changes_seen_total[60m])) Failed ProposalsCheck if etcd has failed proposals. Failing proposals are caused by two issues:\nTemporary failures related to a leader election Longer downtime caused by a loss of quorum in the cluster max(rate(etcd_server_proposals_failed_total[60m])) Pending ProposalsRising pending proposals suggests that client load is high or the member cannot commit proposals.\nsum(etcd_server_proposals_pending) Total Number of Consensus Proposals CommitedThe etcd server applies every committed proposal asynchronously.\nCheck if the difference between proposals committed and proposals applied is small within a few thousands even under high load:\nIf the difference between them continues to rise, the etcd server is overloaded. This might happen when applying expensive queries like heavy range queries or large txn operations. Proposals commited:\nsum(rate(etcd_server_proposals_committed_total[60m])) by (kube_cluster_name) Proposals applied:\nsum(rate(etcd_server_proposals_applied_total[60m])) by (kube_cluster_name) gRPCError RateCheck the gRPC error rate. These errors are most likely related to networking issues.\nsum(rate(grpc_server_handled_total{container_name=~\u0026#34;.*etcd.*|http\u0026#34;,grpc_type=\u0026#34;unary\u0026#34;,grpc_code!=\u0026#34;OK\u0026#34;}[10m])) by (kube_cluster_name,kube_pod_name) / sum(rate(grpc_server_handled_total{container_name=~\u0026#34;.*etcd.*|http\u0026#34;,grpc_type=\u0026#34;unary\u0026#34;}[10m])) by (kube_cluster_name,kube_pod_name) gRPC TrafficCheck for unusual spikes in the traffic. They could be related to networking issues.\nrate(etcd_network_client_grpc_received_bytes_total[10m]) rate(etcd_network_client_grpc_sent_bytes_total[10m]) DiskDisk SyncCheck if the fsync and commit latencies are below limits:\nHigh disk operation latencies often indicate disk issues. It may cause high request latency or make the cluster unstable histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[10m])) by (instance, le,kube_cluster_name,kube_pod_name)) histogram_quantile(0.99, sum(rate(etcd_disk_backend_commit_duration_seconds_bucket[10m])) by (instance, le,kube_cluster_name,kube_pod_name)) DB SizeCheck for DB size if it keeps increasing. You should defrag etcd to decrease the DB size.\netcd_debugging_mvcc_db_total_size_in_bytes{container_name=~\u0026#34;.*etcd.*|http\u0026#34;} or etcd_mvcc_db_total_size_in_bytes{container_name=~\u0026#34;.*etcd.*|http\u0026#34;} Networking Between PeersThis is only applicable to multi-master.\nErrors from / to PeerCheck the total number of failures sent from peers:\nrate(etcd_network_peer_sent_failures_total{container_name=~\u0026#34;.*etcd.*|http\u0026#34;}[10m]) Check the total number of failures received by peers:\nrate(etcd_network_peer_received_failures_total{container_name=~\u0026#34;.*etcd.*|http\u0026#34;}[10m]) Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: openshift-etcd-default honor_labels: true scheme: https bearer_token_file: /run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true metrics_path: \u0026#39;/federate\u0026#39; params: \u0026#39;match[]\u0026#39;: - \u0026#39;{job=~\u0026#34;etcd\u0026#34;}\u0026#39; kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;openshift-monitoring/prometheus-k8s-1\u0026#39; # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name # Remove extended labelset - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_etcd replacement: true metric_relabel_configs: - source_labels: [__name__] regex: (etcd_debugging_mvcc_db_total_size_in_bytes|etcd_disk_backend_commit_duration_seconds_bucket|etcd_disk_wal_fsync_duration_seconds_bucket|etcd_grpc_proxy_cache_hits_total|etcd_grpc_proxy_cache_misses_total|etcd_network_client_grpc_received_bytes_total|etcd_network_client_grpc_sent_bytes_total|etcd_network_peer_received_bytes_total|etcd_network_peer_received_failures_total|etcd_network_peer_round_trip_time_seconds_bucket|etcd_network_peer_sent_bytes_total|etcd_network_peer_sent_failures_total|etcd_server_has_leader|etcd_server_id|etcd_server_leader_changes_seen_total|etcd_server_proposals_applied_total|etcd_server_proposals_committed_total|etcd_server_proposals_failed_total|etcd_server_proposals_pending|go_goroutines|grpc_server_handled_total|grpc_server_handling_seconds_bucket|grpc_server_started_total|process_max_fds|process_open_fds|etcd_mvcc_db_total_size_in_bytes|etcd_server_quota_backend_bytes) action: keep - action: replace source_labels: [namespace] target_label: kube_namespace_name - action: replace source_labels: [pod] target_label: kube_pod_name - action: replace source_labels: [endpoint] target_label: container_name - action: replace target_label: job replacement: openshift-etcd-default ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/openshift-etcd/"},{"id":581,"title":"OpenShift Kubelet","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nVersions supported: \u0026gt; v4.7\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 25 metrics.\nTimeseries generated: Kubelet generates ~1200 timeseries per node\nList of Alerts Alert Description Format [openshift-kubelet] Kubelet Too Many Pods Kubelet Too Many Pods Prometheus [openshift-kubelet] Kubelet Pod Lifecycle Event Generator Duration High Kubelet Pod Lifecycle Event Generator Duration High Prometheus [openshift-kubelet] Kubelet Pod StartUp Latency High Kubelet Pod StartUp Latency High Prometheus [openshift-kubelet] Kubelet Down Kubelet Down Prometheus List of DashboardsOpenShift v4 KubeletThe dashboard provides information on the OpenShift Kubelet. List of Metrics Metric name go_goroutines kube_node_status_capacity_pods kube_node_status_condition kubelet_cgroup_manager_duration_seconds_bucket kubelet_cgroup_manager_duration_seconds_count kubelet_node_config_error kubelet_pleg_relist_duration_seconds_bucket kubelet_pleg_relist_interval_seconds_bucket kubelet_pod_start_duration_seconds_bucket kubelet_pod_start_duration_seconds_count kubelet_pod_worker_duration_seconds_bucket kubelet_pod_worker_duration_seconds_count kubelet_running_containers kubelet_running_pod_count kubelet_running_pods kubelet_runtime_operations_duration_seconds_bucket kubelet_runtime_operations_errors_total kubelet_runtime_operations_total process_cpu_seconds_total process_resident_memory_bytes rest_client_request_duration_seconds_bucket rest_client_requests_total storage_operation_duration_seconds_bucket storage_operation_duration_seconds_count volume_manager_total_volumes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/openshift-kubelet/"},{"id":582,"title":"OpenShift Scheduler","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v4.7\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 20 metrics.\nTimeseries generated: Scheduler generates ~300 timeseries\nList of Alerts Alert Description Format [OpenShift Scheduler] Process Down Scheduler has disappeared from target discovery. Prometheus [OpenShift Scheduler] Failed Attempts to Schedule Pods Scheduler Failed Attempts to Schedule Pods. Prometheus [OpenShift Scheduler] High 4xx RequestError Rate Scheduler High 4xx Request Error Rate. Prometheus [OpenShift Scheduler] High 5xx RequestError Rate Scheduler High 5xx Request Error Rate. Prometheus List of DashboardsOpenShift v4 Scheduler If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_scheduler replacement: true The dashboard provides information on the OpenShift Scheduler. List of Metrics Metric name go_goroutines rest_client_request_duration_seconds_count rest_client_request_duration_seconds_sum rest_client_requests_total scheduler_e2e_scheduling_duration_seconds_count scheduler_e2e_scheduling_duration_seconds_sum scheduler_pending_pods scheduler_pod_scheduling_attempts_count scheduler_pod_scheduling_attempts_sum scheduler_schedule_attempts_total sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes workqueue_adds_total workqueue_depth workqueue_queue_duration_seconds_count workqueue_queue_duration_seconds_sum workqueue_retries_total workqueue_unfinished_work_seconds workqueue_work_duration_seconds_count workqueue_work_duration_seconds_sum PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nHow to monitor OpenShift Scheduler with Sysdig agentNo further installation is needed, since OpenShift 4.X comes with both Prometheus and Scheduler ready to use. OpenShift Scheduler metrics are exposed using /federate endpoint.\nHere are some interesting metrics and queries to monitor and troubleshoot OpenShift Scheduler.\nSchedulingFailed attempts to Schedule podsUnschedulable pods means that a pod could not be scheduled, use this query to check for failed attempts:\nsum by (kube_cluster_name,kube_pod_name,result) (rate(scheduler_schedule_attempts_total{result!~\u0026#34;scheduled\u0026#34;}[10m])) / ignoring(result) group_left sum by (kube_cluster_name,kube_pod_name)(rate(scheduler_schedule_attempts_total[10m])) Pending podsCheck that there are no pods in pending queues with this query:\ntopk(30,rate(scheduler_pending_pods[10m])) Work QueueWork Queue RetriesThe total number of retries that have been handled by the work queue. This value should be near 0.\ntopk(30,rate(workqueue_retries_total{job=~\u0026#34;kube-scheduler-default|openshift-scheduler-default\u0026#34;}[10m])) Work Queue LatencyQueue latency is the time tasks spend in the queue before being processed\ntopk(30,rate(workqueue_queue_duration_seconds_sum{job=~\u0026#34;kube-scheduler-default|openshift-scheduler-default\u0026#34;}[10m]) / rate(workqueue_queue_duration_seconds_count{job=~\u0026#34;kube-scheduler-default|openshift-scheduler-default\u0026#34;}[10m])) Work Queue DepthCheck the depth of the queue. High values can indicate the saturation of the controller manager.\ntopk(30,rate(workqueue_depth{container_name=~\u0026#34;.*kube-scheduler.*\u0026#34;}[10m])) Scheduler API RequestsKube API Requests by codeCheck that there are no 5xx or 4xx error codes in the scheduler requests.\nsum by (kube_cluster_name,kube_pod_name)(rate(rest_client_requests_total{container_name=~\u0026#34;.*kube-scheduler.*\u0026#34;,code=~\u0026#34;4..\u0026#34;}[10m])) sum by (kube_cluster_name,kube_pod_name)(rate(rest_client_requests_total{container_name=~\u0026#34;.*kube-scheduler.*\u0026#34;,code=~\u0026#34;5..\u0026#34;}[10m])) Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: openshift-scheduler-default honor_labels: true scheme: https bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token tls_config: insecure_skip_verify: true metrics_path: \u0026#39;/federate\u0026#39; params: \u0026#39;match[]\u0026#39;: - \u0026#39;{job=~\u0026#34;scheduler\u0026#34;,__name__=~\u0026#34;scheduler_schedule_attempts_total|scheduler_pod_scheduling_attempts_sum|scheduler_pod_scheduling_attempts_count|scheduler_e2e_scheduling_duration_seconds_sum|scheduler_e2e_scheduling_duration_seconds_count|scheduler_pending_pods|workqueue_retries_total|workqueue_work_duration_seconds_sum|workqueue_work_duration_seconds_count|workqueue_unfinished_work_seconds|workqueue_queue_duration_seconds_sum|workqueue_queue_duration_seconds_count|workqueue_depth|workqueue_adds_total|rest_client_requests_total|rest_client_request_duration_seconds_sum|rest_client_request_duration_seconds_count|go_goroutines\u0026#34;}\u0026#39; kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;openshift-monitoring/prometheus-k8s-0\u0026#39; # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name # Remove extended labelset - action: replace replacement: true target_label: sysdig_omit_source - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_scheduler replacement: true metric_relabel_configs: - source_labels: [__name__] regex: (go_goroutines|rest_client_request_duration_seconds_count|rest_client_request_duration_seconds_sum|rest_client_requests_total|scheduler_e2e_scheduling_duration_seconds_count|scheduler_e2e_scheduling_duration_seconds_sum|scheduler_pending_pods|scheduler_pod_scheduling_attempts_count|scheduler_pod_scheduling_attempts_sum|scheduler_schedule_attempts_total|sysdig_container_cpu_cores_used|sysdig_container_memory_used_bytes|workqueue_adds_total|workqueue_depth|workqueue_queue_duration_seconds_count|workqueue_queue_duration_seconds_sum|workqueue_retries_total|workqueue_unfinished_work_seconds|workqueue_work_duration_seconds_count|workqueue_work_duration_seconds_sum) action: keep - action: replace source_labels: [namespace] target_label: kube_namespace_name - action: replace source_labels: [pod] target_label: kube_pod_name - action: replace source_labels: [container] target_label: container_name - action: replace source_labels: [job] regex: \u0026#39;(.*)\u0026#39; target_label: job replacement: \u0026#39;openshift-$1-default\u0026#39; ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/openshift-scheduler/"},{"id":583,"title":"OpenShift State Metrics","content":" This integration is enabled by default.\nVersions supported: \u0026gt; v4.7\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 4 metrics.\nTimeseries generated: 30 timeseries + 4 series per route\nList of Alerts Alert Description Format [OpenShift-state-metrics] CPU Resource Request Quota Usage Resource request CPU usage is over 90% resource quota. Prometheus [OpenShift-state-metrics] CPU Resource Limit Quota Usage Resource limit CPU usage is over 90% resource limit quota. Prometheus [OpenShift-state-metrics] Memory Resource Request Quota Usage Resource request memory usage is over 90% resource quota. Prometheus [OpenShift-state-metrics] Memory Resource Limit Quota Usage Resource limit memory usage is over 90% resource limit quota. Prometheus [OpenShift-state-metrics] Routes with issues A route status is in error and is having issues. Prometheus [OpenShift-state-metrics] Buid Processes with issues A build process is in error or failed status. Prometheus List of DashboardsOpenShift v4 State Metrics If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_state_metrics replacement: true The dashboard provides information on the special OpenShift-state-metrics. List of Metrics Metric name openshift_build_created_timestamp_seconds openshift_build_status_phase_total openshift_clusterresourcequota_usage openshift_route_status PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting OpenShift State MetricsNo further installation is needed, since OKD4 comes with both Prometheus and OSM ready to use.\nHere are some interesting metrics and queries to monitor and troubleshoot OpenShift 4.\nResource QuotasResource Quotas Requests% CPU Used vs Request QuotaLet\u0026rsquo;s get what\u0026rsquo;s the % of CPU used vs the request quota.\nsum by (name, kube_cluster_name) (openshift_clusterresourcequota_usage{resource=\u0026#34;requests.cpu\u0026#34;, type=\u0026#34;used\u0026#34;}) / sum by (name, kube_cluster_name) (openshift_clusterresourcequota_usage{resource=\u0026#34;requests.cpu\u0026#34;, type=\u0026#34;hard\u0026#34;}) \u0026gt; 0 % Memory Used vs Request QuotaNow, the same but for the memory.\nsum by (name, kube_cluster_name)(openshift_clusterresourcequota_usage{resource=\u0026#34;requests.memory\u0026#34;, type=\u0026#34;used\u0026#34;}) / sum by (name, kube_cluster_name)(openshift_clusterresourcequota_usage{resource=\u0026#34;requests.memory\u0026#34;, type=\u0026#34;hard\u0026#34;}) \u0026gt; 0 These queries return one time series for each resource quota deployed in the cluster.\nPlease, not that if your requests are near 100%, you can use the Pod Rightsizing \u0026amp; Workload Capacity Optimization dashboard to fix it. You can also talk to your cluster administrator to check your resource quota. Also, if your requests are too low, the resource quota could be rightsized.\nResource Quotas Limits% CPU Used vs Limit QuotaLet\u0026rsquo;s get what\u0026rsquo;s the % of CPU used vs the limit quota.\nsum by (name, kube_cluster_name)(openshift_clusterresourcequota_usage{resource=\u0026#34;limits.cpu\u0026#34;, type=\u0026#34;used\u0026#34;}) / sum by (name, kube_cluster_name)(openshift_clusterresourcequota_usage{resource=\u0026#34;limits.cpu\u0026#34;, type=\u0026#34;hard\u0026#34;}) \u0026gt; 0 % Memory Used vs Limit QuotaNow, the same but for the memory.\nsum by (name, kube_cluster_name)(openshift_clusterresourcequota_usage{resource=\u0026#34;limits.memory\u0026#34;, type=\u0026#34;used\u0026#34;}) / sum by (name, kube_cluster_name)(openshift_clusterresourcequota_usage{resource=\u0026#34;limits.memory\u0026#34;, type=\u0026#34;hard\u0026#34;}) \u0026gt; 0 These queries return one time series for each resource quota deployed in the cluster.\nPlease, note that quota limits are normally higher than the quota requests. If your limits are too close to 100%, you might face scheduling issues. The Pod Scheduling Troubleshooting dashboard might help you to troubleshoot this scenario. Also, if limit usage is too low, the resource quota could be rightsized.\nRoutesList the RoutesLet\u0026rsquo;s get a list of all the routes present in the cluster, aggregated by host and namespace\nsum by (route, host, namespace) (openshift_route_info) Duplicated RoutesNow, let\u0026rsquo;s find our duplicated routes:\nsum by (host) (openshift_route_info) \u0026gt; 1 This query will return the duplicated hosts. If you want the full information for the duplicated routes, try this one:\nopenshift_route_info * on (host) group_left(host_name) label_replace((sum by (host) (openshift_route_info) \u0026gt; 1), \u0026#34;host_name\u0026#34;, \u0026#34;$0\u0026#34;, \u0026#34;host\u0026#34;, \u0026#34;.+\u0026#34;) Why the label_replace? because to get the full info, joining the openshift_route_info metric with itself was necessary, but, as both sides of the join have the same labels, there wasn\u0026rsquo;t any extra label to join by.\nWhat you can do is to perform a label_replace to create a new label host_name with the content of the host label and the join will work.\nRoutes with IssuesLet\u0026rsquo;s get what are the routes with issues (a.k.a. routes with a False status)\nopenshift_route_status{status == \u0026#39;False\u0026#39;} \u0026gt; 0 BuildsNew Builds, by Processing TimeLet\u0026rsquo;s list the new builds, by how many time they have been processing. This query can be useful to detect slow processes.\ntime() - (openshift_build_created_timestamp_seconds) * on (build) group_left(build_phase) (openshift_build_status_phase_total{build_phase=\u0026#34;new\u0026#34;} == 1) Builds with ErrorsUse this query to get builds that are in failed or error state.\nsum by (build, buildconfig, kube_namespace_name, kube_cluster_name) (openshift_build_status_phase_total{build_phase=~\u0026#34;failed|error\u0026#34;}) \u0026gt; 0 Agent ConfigurationThe default agent job for this integration is as follows:\n- job_name: \u0026#39;openshift-state-metrics\u0026#39; tls_config: insecure_skip_verify: true bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - action: drop source_labels: [__meta_kubernetes_pod_annotation_promcat_sysdig_com_omit] regex: true - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: replace source_labels: - __meta_kubernetes_pod_container_name regex: (openshift-state-metrics) replacement: openshift-state-metrics target_label: __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type - action: keep source_labels: - __meta_kubernetes_pod_annotation_promcat_sysdig_com_integration_type regex: \u0026#34;openshift-state-metrics\u0026#34; - action: replace source_labels: [__address__] regex: ([^:]+)(?::\\d+)? replacement: $1:8443 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_openshift_state_metrics replacement: true metric_relabel_configs: - source_labels: [__name__] regex: (openshift_build_created_timestamp_seconds|openshift_build_status_phase_total|openshift_clusterresourcequota_usage|openshift_route_status) action: keep ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/openshift-state-metrics/"},{"id":584,"title":"Percentage of Change Alerts","content":" Percentage of Change Alerts were formerly known as Change Alerts.\nPercentage of Change Alerts let you receive alerts when your metrics change considerably over time. Instead of setting a fixed threshold for when a metric goes above or below a certain value, use Percentage of Change Alerts to be notified when the metric changes by a certain percentage. This is ideal for environments with multiple regions where traffic and usage variations occur. By setting up a Percentage of Change alert, you can detect changes relative to the baseline, rather than just using a static threshold.\nWhen to Use Percentage of Change Alerts A historical baseline can be established. For example, steady network traffic Metric is relatively steady. For example, database disk usage An abrupt metric spike. For example, request latency When Not to Use Percentage of Change Alerts Metric is expected to fluctuate significantly over time Metric is noisy and unreliable Metric has a low baseline Define a Percentage of Change AlertTo create a Percentage of Change Alert:\nLog in to Sysdig Monitor.\nSelect Alerts.\nSelect New Alert \u0026gt; Percentage of Change.\nPercentage of Change Alerts compare a shorter time aggregation to a longer one and trigger an alert if the difference between the two time aggregations exceeds a threshold defined by you.\nFor example, if you want to be alerted on an increase in database latency, you can configure a Percentage of Change Alerts on the relevant metric, such as database_query_duration_seconds, comparing the last 5 minutes with the last 1 hour. If the change in the metric between the two time time aggregations exceeds the custom-defined threshold, the Percentage of Change Alert will trigger and you will receive an alert notification.\nPercentage of Change Alerts ResolutionUnlike alerts with static thresholds which resolve when the threshold is no longer met, Percentage of Change Alerts resolve when difference between the shorter interval and the longer interval no longer violate the user-defined threshold.\nFor instance, the following graph shows database latency that increases significantly after 3:00 and remains high. Using a static threshold of 5s for a Threshold Alert would result in an alert that remains triggered.\n​ On the other hand, setting a threshold of 50% for a Percentage of Change Alert would result in an alert that triggers for the initial spike and then resolves. This is because the difference between the last 5 minutes and the last 1 hour is no longer significant.\n​ Prevent Automatic Alert ResolutionIn order to prevent an incident from being automatically closed when a Percentage of Change Alert no longer violates the threshold, you can configure an alert to not send alert resolutions to the notification channel when an alert resolves. This can help prevent confusion in the on-call process as an alert resolution does not necessarily mean that an incident has been resolved.\nFor more information, see Notify when Resolved.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/change-alerts/"},{"id":585,"title":"Prioritize Designated Containers","content":"OverviewBy default, a Sysdig agent will collect metrics from all containers it detects in an environment. When reporting to the Monitor interface, it uses default sorting behavior to prioritize what container information to display first.\nUnderstand Default BehaviorOut of the box, it chooses the containers with the highest\nCPU\nMemory\nFile IO\nNet IO\nand allocates approximately 1/4 of the total limit to each stat type.\nUnderstand Simple Container FilteringYou can use the use_container_filter parameter in the agent configuration file, label specific containers, and set include/exclude rules to push those containers to the top of the reporting hierarchy.\nThis is an effective sorting tool when:\nYou can manually mark each container with an include or exclude label\nThe number of includes is small (say, less than 100)\nIn this case, the containers that explicitly match the include rules will take top priority.\nUnderstand Smart Container ReportingIn some enterprises, the number of containers is too high to tag with simple filtering rules, and the include_all group is too large to ensure that the most-desired containers are consistently reported. In this case, you can append another parameter, smart_container_reporting, to the configuration file.\nThis is an effective sorting tool when:\nThe number of containers is large and you can\u0026rsquo;t or won\u0026rsquo;t mark each one with include/exclude tags, AND\nThere are certain containers you would like to always prioritize\nThis helps ensure that even when there are thousands of containers in an environment, the most-desired containers are consistently reported.\nContainer filtering and smart container reporting affect the monitoring of all the processes/metrics within a container, including StatsD, JMX, app-checks, and built-in metrics.\nPrometheus metrics are attached to processes, rather than containers, and are therefore handled differently.\nThe container limit is set in dragent.yaml under containers:limit: Understand Sysdig Aggregated ContainerThe sysdig_aggregated parameter is automatically activated when smart container reporting is enabled, to capture the most-desired metrics from the containers that were excluded by smart filtering and report them under a single entity. It appears like any other container in the Sysdig Monitor UI, with the name \u0026ldquo;sysdig_aggregated.\u0026rdquo;\nSysdig_aggregated can report on a wide array of metrics. However, because this is not a regular container, certain limitations apply:\ncontainer\\_id and container\\_image do not exist.\nThe aggregated container cannot be segmented by certain metrics that are excluded, such as process.\nSome default dashboards associated with the aggregated container may have some empty graphs.\nUse Simple Container FilteringBy default, the filtering feature is turned off. It can be enabled by adding the following line to the agent configuration:\nuse_container_filter: true When enabled, the agent will follow include/exclude filtering rules based on:\ncontainer image\ncontainer name\ncontainer label\nKubernetes annotation or label\nThe default behavior in default.dragent.yaml excludes based on a container label (com.sysdig.report) and a Kubernetes pod annotation (.sysdig.com/report ).\nContainer Condition Parameters and RulesParametersThe condition parameters are described in the following table:\nPattern name\nDescription\nExample\ncontainer.image\nMatches if the process is running inside a container running the specified image\n- include:\ncontainer.image: luca3m/prometheus-java-app\ncontainer.name Matches if the process is running inside a container with the specified name\n- include:\ncontainer.name: my-java-app\ncontainer.label.*\nMatches if the process is running in a container that has a Label matching the given value\n- include:\ncontainer.label.class: exporter\nkubernetes.\u0026lt;object\u0026gt;.annotation.* kubernetes.\u0026lt;object\u0026gt;.label.*\nMatches if the process is attached to a Kubernetes object (Pod, Namespace, etc.) that is marked with the Annotation/Label matching the given value.\n- include:\nkubernetes.pod.annotation.prometheus.io/scrape: true\nall\nMatches all. Use as last rule to determine default behavior.\n- include:\nall\nRulesOnce enabled by setting use_container_filter: true , the agent will follow filtering rules from the container_filter section.\nEach rule is an include or exclude rule which can contain one or more conditions.\nThe first matching rule in the list will determine if the container is included or excluded.\nThe conditions consist of a key name and a value. If the given key for a container matches the value, the rule will be matched.\nIf a rule contains multiple conditions they all need to match for the rule to be considered a match.\nDefault ConfiguratonThe default configuration file contains the following for container filters:\nuse_container_filter: false container_filter: - include: container.label.com.sysdig.report: true - exclude: container.label.com.sysdig.report: false - include: kubernetes.pod.annotation.sysdig.com/report: true - exclude: kubernetes.pod.annotation.sysdig.com/report: false - include: all Note that it excludes via a container.label and by a kubernetes.pod.annotation. The examples on this page show how to edit in the dragent.yaml file directly. Convert the examples to Docker or Helm commands, if applicable for your situation.\nEnable Container FilteringOption 1: Use the Default ConfigurationTo enable container filtering using the default configuration in default.dragent.yaml (above), follow the steps below.\n1. Apply Labels and Annotations to Designated ContainersTo set up, decide which containers should be excluded from automatic monitoring.\nApply the container label .com.sysdig.report and/or the Kubernetes pod annotation sysdig.com/report to the designated containers.\n2. Edit the Agent ConfigurationAdd the following line to dragent.yaml to turn on the default functionality:\nuse_container_filter: true Option 2: Define Your Own RulesYou can also edit dragent.yaml to apply your own container filtering rules.\n1. Designate ContainersTo set up, decide which containers should be excluded from automatic monitoring.\nNote the image, name, label, or Kubernetes pod information as appropriate, and build your rule set accordingly.\n2. Edit the Agent ConfigurationFor example:\nuse_container_filter: true container_filter: - include: container.name: my-app - include: container.label.com.sysdig.report: true - exclude: kubernetes.namespace.name: kube-system container.image: \u0026#34;gcr.io*\u0026#34; - include: all The above example shows a container_filter with 3 include rules and 1 exclude rule.\nIf the container name is \u0026ldquo;my-app\u0026rdquo; it will be included.\nLikewise, if the container has a label with the key \u0026ldquo;com.sysdig.report\u0026rdquo; and with the value \u0026ldquo;true\u0026rdquo;.\nIf neither of those rules is true, and the container is part of a Kubernetes hierarchy within the \u0026ldquo;kube-system\u0026rdquo; namespace and the container image starts with \u0026ldquo;gcr.io\u0026rdquo;, it will be excluded.\nThe last rule includes all, so any containers not matching an earlier rule will be monitored and metrics for them will be sent to the backend.\nUse Smart Container ReportingAs of Sysdig agent version 0.91, you can add another parameter to the config file: smart_container_reporting = true\nThis enables several new prioritization checks:\ncontainer_filter (you would enable and set include/exclude rules, as described above)\ncontainer age\nhigh stats\nlegacy patterns\nThe sort is modified with the following rules in priority order:\nUser-specified containers come before others\nContainers reported previously should be reported before those which have never been reported\nContainers with higher usage by each of the 4 default stats should come before those with lower usage\nEnable Smart Container Reporting Set up any simple container filtering rules you need, following either Option 1 or Option 2, above.\nEdit the agent configuration:\nsmart_container_reporting: true This turns on both smart_container_reporting and sysdig_aggregated. The changes will be visible in the Sysdig Monitor UI.\nLoggingWhen the log level is set to DEBUG, the following messages may be found in the logs:\nmessage meaning container \u0026lt;id\u0026gt;, no filter configured container filtering is not enabled container \u0026lt;id\u0026gt;, include in report container is included container \u0026lt;id\u0026gt;, exclude in report container is excluded Not reporting thread \u0026lt;thread-id\u0026gt; in container \u0026lt;id\u0026gt; Process thread is excluded See Change the Agent Log Level.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/prioritize-designated-containers/"},{"id":586,"title":"Pull Images from Private Registry","content":"PrerequisitesCollect the following information associated with your private registry:\nRegistry URL Username Access token or password Email address Ensure you update the Sysdig Helm chart before installation. This lets you access the latest features and fixes.\nCreate a Secret for Registry CredentialsCreate a Kubernetes secret that stores your private registry credentials.\nkubectl create secret docker-registry \u0026lt;SECRET_NAME\u0026gt; \\ --docker-server=\u0026lt;SERVER\u0026gt; \\ --docker-username=\u0026lt;USERNAME\u0026gt; \\ --docker-password=\u0026lt;TOKEN\u0026gt; \\ --docker-email=\u0026lt;YOUR-EMAIL\u0026gt; Replace the placeholders with your registry information.\nConfigure Helm ChartsUpdate the helm installation command or values.yaml with the following parameters. You can use either your current one or from the Kubernetes installation instructions.\nReplace the placeholders with your registry information:\nHelm values.yaml helm install ... \\ --set global.imageRegistry=\u0026lt;IMAGE_REGISTRY\u0026gt; \\ # Use global pullSecrets and pullPolicy params if they’re shared --set \u0026#39;global.image.pullSecrets[0].name\u0026#39;=\u0026lt;SECRET_NAME\u0026gt; \\ --set global.image.pullPolicy=\u0026lt;PULL_POLICY\u0026gt; \\ --set agent.repository=\u0026lt;IMAGE_REPOSITORY\u0026gt; \\ --set nodeAnalyzer.nodeAnalyzer.runtimeScanner.image.repository=\u0026lt;IMAGE_REPOSITORY\u0026gt; \\ --set nodeAnalyzer.nodeAnalyzer.benchmarkRunner.image.repository=\u0026lt;IMAGE_REPOSITORY\u0026gt; \\ --set nodeAnalyzer.nodeAnalyzer.hostScanner.image.repository=\u0026lt;IMAGE_REPOSITORY\u0026gt; \\ --set nodeAnalyzer.nodeAnalyzer.kspmAnalyzer.image.repository=\u0026lt;IMAGE_REPOSITORY\u0026gt; \\ --set nodeAnalyzer.nodeAnalyzer.imageAnalyzer.image.repository=\u0026lt;IMAGE_REPOSITORY\u0026gt; \\ --set kspmCollector.repository=\u0026lt;IMAGE_REPOSITORY\u0026gt; # You can use the specific params to override the pullSecrets and pullPolicy if needed for agent # --set \u0026#39;agent.image.pullSecrets[0].name\u0026#39;=\u0026lt;SECRET_NAME\u0026gt; \\ # --set agent.image.pullPolicy=\u0026lt;PULL_POLICY\u0026gt; \\ # for nodeAnalyzer # --set \u0026#39;nodeAnalyzer.nodeAnalyzer.pullSecrets[0]\u0026#39;=\u0026lt;SECRET_NAME\u0026gt; \\ # --set nodeAnalyzer.nodeAnalyzer.runtimeScanner.image.pullPolicy=\u0026lt;PULL_POLICY\u0026gt; \\ # --set nodeAnalyzer.nodeAnalyzer.benchmarkRunner.image.pullPolicy=\u0026lt;PULL_POLICY\u0026gt; \\ # --set nodeAnalyzer.nodeAnalyzer.hostScanner.image.pullPolicy=\u0026lt;PULL_POLICY\u0026gt; \\ # --set nodeAnalyzer.nodeAnalyzer.kspmAnalyzer.image.pullPolicy=\u0026lt;PULL_POLICY\u0026gt; \\ # --set nodeAnalyzer.nodeAnalyzer.imageAnalyzer.image.pullPolicy=\u0026lt;PULL_POLICY\u0026gt; \\ # for kspmCollector # --set \u0026#39;kspmCollector.imagePullSecrets[0].name\u0026#39;=\u0026lt;SECRET_NAME\u0026gt; # --set kspmCollector.image.pullPolicy=\u0026lt;PULL_POLICY\u0026gt; global: imageRegistry: \u0026lt;IMAGE_REGISTRY\u0026gt; # Optional shared image pullSecrets and pullPolicy image: pullSecrets: - name: \u0026lt;SECRET_NAME\u0026gt; pullPolicy: \u0026lt;PULL_POLICY\u0026gt; # This pulls the agent image from the private repository agent: image: # Specific pullSecrets and pullPolicy override for agent # pullSecrets # - name: \u0026lt;SECRET_NAME\u0026gt; # pullPolicy: \u0026lt;PULL_POLICY\u0026gt; repository: \u0026lt;IMAGE_REPOSITORY\u0026gt; # This pulls the nodeAnalyzer images from the private repository nodeAnalyzer: # Specific pullSecrets override for nodeAnalyzer # nodeAnalyzer # pullSecrets # - name: \u0026lt;SECRET_NAME\u0026gt; hostScanner: image: repository: \u0026lt;IMAGE_REPOSITORY\u0026gt; # Specific pullPolicy override for hostScanner # pullPolicy: \u0026lt;PULL_POLICY\u0026gt; runtimeScanner: image: repository: \u0026lt;IMAGE_REPOSITORY\u0026gt; # Specific pullPolicy override for runtimeScanner # pullPolicy: \u0026lt;PULL_POLICY\u0026gt; kspmAnalyzer: image: repository: \u0026lt;IMAGE_REPOSITORY\u0026gt; # Specific pullPolicy override for kspmAnalyzer # pullPolicy: \u0026lt;PULL_POLICY\u0026gt; # This pulls the KSPM collector image from a private repository kspmCollector: repository: \u0026lt;IMAGE_REPOSITORY\u0026gt; # Specific pullSecrets and pullPolicy override # imagePullSecrets # - name: \u0026lt;SECRET_NAME\u0026gt; # image # pullPolicy: \u0026lt;PULL_POLICY\u0026gt; ","url":"https://docs.sysdig.com/en/sysdig-secure/configure-private-registry/"},{"id":587,"title":"Rancher RKE API Server","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 42 metrics.\nTimeseries generated: 70K TS\nList of Alerts Alert Description Format [Rancher RKE API Server] Deprecated APIs API-Server Deprecated APIs Prometheus [Rancher RKE API Server] Certificate Expiry API-Server Certificate Expiry Prometheus [Rancher RKE API Server] Admission Controller High Latency API-Server Admission Controller High Latency Prometheus [Rancher RKEKubernetes API Server] Webhook Admission Controller High Latency API-Server Webhook Admission Controller High Latency Prometheus [Rancher RKE API Server] High 4xx RequestError Rate APIS-Server High 4xx Request Error Rate Prometheus [Rancher RKE API Server] High 5xx RequestError Rate APIS-Server High 5xx Request Error Rate Prometheus [Rancher RKE API Server] High Request Latency APIS-Server High Request Latency Prometheus List of DashboardsRancher RKE API Server If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_api_server replacement: true The dashboard provides information on the RKE API Server. List of Metrics Metric name apiserver_admission_controller_admission_duration_seconds_count apiserver_admission_controller_admission_duration_seconds_sum apiserver_admission_webhook_admission_duration_seconds_count apiserver_admission_webhook_admission_duration_seconds_sum apiserver_client_certificate_expiration_seconds_bucket apiserver_client_certificate_expiration_seconds_count apiserver_request_duration_seconds_count apiserver_request_duration_seconds_sum apiserver_request_total apiserver_requested_deprecated_apis apiserver_response_sizes_count apiserver_response_sizes_sum go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds process_resident_memory_bytes workqueue_adds_total workqueue_depth PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke-api-server-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: node relabel_configs: - action: keep source_labels: [__meta_kubernetes_node_address_InternalIP] regex: __HOSTIPS__ - action: labelmap regex: __meta_kubernetes_node_label_(.+) replacement: kube_node_label_$1 - replacement: localhost:6443 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_node_name] target_label: kube_node_name - action: replace source_labels: [__meta_kubernetes_namespace] target_label: kube_namespace_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_api_server replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke-api-server/"},{"id":588,"title":"Rancher RKE Controller Manager","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 43 metrics.\nTimeseries generated: 1.99K TS\nList of Alerts Alert Description Format [Rancher RKE Controller Manager] High 4xx RequestError Rate Rancher RKE Controller Manager High 4xx Request Error Rate Prometheus [Rancher RKE controller manager] High 5xx RequestError Rate Rancher RKE Controller Manager High 5xx Request Error Rate Prometheus List of DashboardsRancher RKE Controller Manager If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_controller_manager replacement: true The dashboard provides information on the RKE Controller Manager. List of Metrics Metric name cloudprovider_aws_api_request_duration_seconds_count cloudprovider_aws_api_request_duration_seconds_sum cloudprovider_aws_api_request_errors go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds rest_client_request_duration_seconds_count rest_client_request_duration_seconds_sum rest_client_requests_total sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes workqueue_adds_total workqueue_depth workqueue_queue_duration_seconds_count workqueue_queue_duration_seconds_sum workqueue_retries_total workqueue_unfinished_work_seconds workqueue_work_duration_seconds_count workqueue_work_duration_seconds_sum PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke-controller-manager-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: node relabel_configs: - action: keep source_labels: [__meta_kubernetes_node_address_InternalIP] regex: __HOSTIPS__ - action: labelmap regex: __meta_kubernetes_node_label_(.+) replacement: kube_node_label_$1 - replacement: localhost:10257 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_node_name] target_label: kube_node_name - action: replace source_labels: [__meta_kubernetes_namespace] target_label: kube_namespace_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_controller_manager replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke-controller-manager/"},{"id":589,"title":"Rancher RKE CoreDNS","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 38 metrics.\nTimeseries generated: 502 TS\nList of Alerts Alert Description Format [RancherRKECoreDNS] Error High High Request Duration Prometheus [RancherRKECoreDNS] Latency High Latency High Prometheus List of DashboardsRancher RKE CoreDNS If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_coredns replacement: true The dashboard provides information on the RKE CoreDNS. List of Metrics Metric name coredns_cache_hits_total coredns_cache_misses_total coredns_dns_request_duration_seconds_bucket coredns_dns_request_size_bytes_bucket coredns_dns_requests_total coredns_dns_response_size_bytes_bucket coredns_dns_responses_total coredns_forward_request_duration_seconds_bucket coredns_panics_total coredns_plugin_enabled go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds process_resident_memory_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke-coredns-default kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep regex: kube-system;coredns source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_container_name - source_labels: - __address__ action: replace target_label: __address__ regex: (.+?)(:(\\d+))? replacement: $1:9153 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_coredns replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke-coredns/"},{"id":590,"title":"Rancher RKE Kube Proxy","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 35 metrics.\nTimeseries generated: 700 TS\nList of Alerts Alert Description Format [Rancher RKE Kube Proxy] Kube Proxy Down KubeProxy detected down Prometheus [Rancher RKE Kube Proxy] High Rest Client Latency High Rest Client Latency detected Prometheus [Rancher RKE Kube Proxy] High Rule Sync Latency High Rule Sync Latency detected Prometheus [Rancher RKE Kube Proxy] Too Many 500 Code Too Many 500 Code detected Prometheus List of DashboardsRancher RKE Proxy If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_kube_proxy replacement: true The dashboard provides information on the RKE Kube Proxy. List of Metrics Metric name go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads kube_node_info kubeproxy_network_programming_duration_seconds_bucket kubeproxy_network_programming_duration_seconds_count kubeproxy_sync_proxy_rules_duration_seconds_bucket kubeproxy_sync_proxy_rules_duration_seconds_count process_cpu_seconds_total process_max_fds process_open_fds process_resident_memory_bytes rest_client_request_duration_seconds_bucket rest_client_requests_total PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke-kube-proxy-default scrape_interval: 60s kubernetes_sd_configs: - role: node relabel_configs: - action: keep source_labels: [__meta_kubernetes_node_address_InternalIP] regex: __HOSTIPS__ - action: labelmap regex: __meta_kubernetes_node_label_(.+) replacement: kube_node_label_$1 - replacement: localhost:10249 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_node_name] target_label: kube_node_name - action: replace source_labels: [__meta_kubernetes_namespace] target_label: kube_namespace_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_kube_proxy replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke-kube-proxy/"},{"id":591,"title":"Rancher RKE Scheduler","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 46 metrics.\nTimeseries generated: 1.2K TS\nList of Alerts Alert Description Format [Rancher RKE Scheduler] Failed Attempts to Schedule Pods The error rate of attempts to schedule pods is high. Prometheus List of DashboardsRancher RKE Scheduler If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_scheduler replacement: true The dashboard provides information on the RKE Scheduler. List of Metrics Metric name go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds rest_client_request_duration_seconds_count rest_client_request_duration_seconds_sum rest_client_requests_total scheduler_e2e_scheduling_duration_seconds_count scheduler_e2e_scheduling_duration_seconds_sum scheduler_pending_pods scheduler_pod_scheduling_attempts_count scheduler_pod_scheduling_attempts_sum scheduler_schedule_attempts_total sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes workqueue_adds_total workqueue_depth workqueue_queue_duration_seconds_count workqueue_queue_duration_seconds_sum workqueue_retries_total workqueue_unfinished_work_seconds workqueue_work_duration_seconds_count workqueue_work_duration_seconds_sum PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke-scheduler-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: node relabel_configs: - action: keep source_labels: [__meta_kubernetes_node_address_InternalIP] regex: __HOSTIPS__ - action: labelmap regex: __meta_kubernetes_node_label_(.+) replacement: kube_node_label_$1 - replacement: localhost:10259 target_label: __address__ - action: replace source_labels: [__meta_kubernetes_node_name] target_label: kube_node_name - action: replace source_labels: [__meta_kubernetes_namespace] target_label: kube_namespace_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke_scheduler replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke-scheduler/"},{"id":592,"title":"Rancher RKE2 API Server","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 42 metrics.\nTimeseries generated: 21K TS\nList of Alerts Alert Description Format [Rancher RKE2 API Server] Deprecated APIs API-Server Deprecated APIs Prometheus [Rancher RKE2 API Server] Certificate Expiry API-Server Certificate Expiry Prometheus [Rancher RKE2 API Server] Admission Controller High Latency API-Server Admission Controller High Latency Prometheus [Rancher RKE2 API Server] Webhook Admission Controller High Latency API-Server Webhook Admission Controller High Latency Prometheus [Rancher RKE2 API Server] High 4xx RequestError Rate APIS-Server High 4xx Request Error Rate Prometheus [Rancher RKE2 API Server] High 5xx RequestError Rate APIS-Server High 5xx Request Error Rate Prometheus [Rancher RKE2 API Server] High Request Latency APIS-Server High Request Latency Prometheus List of DashboardsRancher RKE2 API Server If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_api_server replacement: true The dashboard provides information on the RKE2 API Server. List of Metrics Metric name apiserver_admission_controller_admission_duration_seconds_count apiserver_admission_controller_admission_duration_seconds_sum apiserver_admission_webhook_admission_duration_seconds_count apiserver_admission_webhook_admission_duration_seconds_sum apiserver_client_certificate_expiration_seconds_bucket apiserver_client_certificate_expiration_seconds_count apiserver_request_duration_seconds_count apiserver_request_duration_seconds_sum apiserver_request_total apiserver_requested_deprecated_apis apiserver_response_sizes_count apiserver_response_sizes_sum go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds process_resident_memory_bytes workqueue_adds_total workqueue_depth PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke2-api-server-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep regex: kube-system;kube-apiserver source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_container_name - source_labels: - __address__ action: replace target_label: __address__ regex: (.+?)(\\\\:\\\\d)? replacement: $1:6443 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_api_server replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke2-api-server/"},{"id":593,"title":"Rancher RKE2 Controller Manager","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 43 metrics.\nTimeseries generated: 2.2K TS\nList of Alerts Alert Description Format [Rancher RKE2 Controller Manager] High 4xx RequestError Rate Rancher RKE2 Controller Manager High 4xx Request Error Rate Prometheus [Rancher RKE2 controller manager] High 5xx RequestError Rate Rancher RKE2 Controller Manager High 5xx Request Error Rate Prometheus List of DashboardsRancher RKE2 Controller Manager If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_controller_manager replacement: true The dashboard provides information on the RKE2 Controller Manager. List of Metrics Metric name cloudprovider_aws_api_request_duration_seconds_count cloudprovider_aws_api_request_duration_seconds_sum cloudprovider_aws_api_request_errors go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds rest_client_request_duration_seconds_count rest_client_request_duration_seconds_sum rest_client_requests_total sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes workqueue_adds_total workqueue_depth workqueue_queue_duration_seconds_count workqueue_queue_duration_seconds_sum workqueue_retries_total workqueue_unfinished_work_seconds workqueue_work_duration_seconds_count workqueue_work_duration_seconds_sum PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke2-controller-manager-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/kube-controller-manager.+\u0026#39; - source_labels: - __address__ action: replace target_label: __address__ replacement: localhost:10257 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_controller_manager replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke2-controller-manager/"},{"id":594,"title":"Rancher RKE2 CoreDNS","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 38 metrics.\nTimeseries generated: 350 TS\nList of Alerts Alert Description Format [RancherRKE2CoreDNS] Error High High Request Duration Prometheus [RancherRKE2CoreDNS] Latency High Latency High Prometheus List of DashboardsRancher RKE2 CoreDNS If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_coredns replacement: true The dashboard provides information on the RKE2 CoreDNS. List of Metrics Metric name coredns_cache_hits_total coredns_cache_misses_total coredns_dns_request_duration_seconds_bucket coredns_dns_request_size_bytes_bucket coredns_dns_requests_total coredns_dns_response_size_bytes_bucket coredns_dns_responses_total coredns_forward_request_duration_seconds_bucket coredns_panics_total coredns_plugin_enabled go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds process_resident_memory_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke2-coredns-default kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep regex: kube-system;coredns source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_container_name - source_labels: - __address__ action: replace target_label: __address__ regex: (.+?)(:(\\d+))? replacement: $1:9153 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_coredns replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke2-coredns/"},{"id":595,"title":"Rancher RKE2 Etcd","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 52 metrics.\nTimeseries generated: 1.5K TS\nList of Alerts Alert Description Format [RKE2-Etcd] Etcd Members Down There are members down. Prometheus [RKE2-Etcd] Etcd Insufficient Members Etcd cluster has insufficient members Prometheus [RKE2-Etcd] Etcd No Leader Member has no leader. Prometheus [RKE2-Etcd] Etcd High Number Of Leader Changes Leader changes within the last 15 minutes. Prometheus [RKE2-Etcd] Etcd High Number Of Failed GRPC Requests High number of failed grpc requests Prometheus [RKE2-Etcd] Etcd GRPC Requests Slow gRPC requests are taking too much time Prometheus [RKE2-Etcd] Etcd High Number Of Failed Proposals High number of proposal failures within the last 30 minutes on etcd instance Prometheus [RKE2-Etcd] Etcd High Fsync Durations 99th percentile fync durations are too high Prometheus [RKE2-Etcd] Etcd High Commit Durations 99th percentile commit durations are too high Prometheus List of DashboardsRancher RKE2 Etcd If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_etcd replacement: true The dashboard provides information on the RKE2 Etcd. List of Metrics Metric name etcd_debugging_mvcc_db_total_size_in_bytes etcd_disk_backend_commit_duration_seconds_bucket etcd_disk_wal_fsync_duration_seconds_bucket etcd_grpc_proxy_cache_hits_total etcd_grpc_proxy_cache_misses_total etcd_mvcc_db_total_size_in_bytes etcd_network_client_grpc_received_bytes_total etcd_network_client_grpc_sent_bytes_total etcd_network_peer_received_bytes_total etcd_network_peer_received_failures_total etcd_network_peer_round_trip_time_seconds_bucket etcd_network_peer_sent_bytes_total etcd_network_peer_sent_failures_total etcd_server_has_leader etcd_server_id etcd_server_leader_changes_seen_total etcd_server_proposals_applied_total etcd_server_proposals_committed_total etcd_server_proposals_failed_total etcd_server_proposals_pending go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads grpc_server_handled_total grpc_server_handling_seconds_bucket grpc_server_started_total process_cpu_seconds_total process_max_fds process_open_fds sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke2-etcd-default scheme: https tls_config: insecure_skip_verify: true cert_file: /host/var/lib/rancher/rke2/server/tls/etcd/client.crt key_file: /host/var/lib/rancher/rke2/server/tls/etcd/client.key kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/etcd-.+\u0026#39; - source_labels: - __address__ action: replace target_label: __address__ regex: (.+?)(\\\\:\\\\d)? replacement: $1:2379 # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_etcd replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke2-etcd/"},{"id":596,"title":"Rancher RKE2 Kube Proxy","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 35 metrics.\nTimeseries generated: 1.5K TS\nList of Alerts Alert Description Format [Rancher RKE2 Kube Proxy] Kube Proxy Down KubeProxy detected down Prometheus [Rancher RKE2 Kube Proxy] High Rest Client Latency High Rest Client Latency detected Prometheus [Rancher RKE2 Kube Proxy] High Rule Sync Latency High Rule Sync Latency detected Prometheus [Rancher RKE2 Kube Proxy] Too Many 500 Code Too Many 500 Code detected Prometheus List of DashboardsRancher RKE2 Kube Proxy If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_kube_proxy replacement: true The dashboard provides information on the RKE2 Proxy. List of Metrics Metric name go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads kube_node_info kubeproxy_network_programming_duration_seconds_bucket kubeproxy_network_programming_duration_seconds_count kubeproxy_sync_proxy_rules_duration_seconds_bucket kubeproxy_sync_proxy_rules_duration_seconds_count process_cpu_seconds_total process_max_fds process_open_fds process_resident_memory_bytes rest_client_request_duration_seconds_bucket rest_client_requests_total PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke2-kube-proxy-default honor_labels: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/kube-proxy.+\u0026#39; - replacement: localhost:10249 target_label: __address__ - source_labels: - __meta_kubernetes_pod_name action: replace target_label: instance - action: labelmap regex: __meta_kubernetes_pod_label_(.+) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_kube_proxy replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke2-kube-proxy/"},{"id":597,"title":"Rancher RKE2 Scheduler","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration is out-of-the-box, so it doesn\u0026rsquo;t require any exporter.\nThis integration has 46 metrics.\nTimeseries generated: 1.5K TS\nList of Alerts Alert Description Format [Rancher RKE2 Scheduler] Failed Attempts to Schedule Pods The error rate of attempts to schedule pods is high. Prometheus List of DashboardsRancher RKE2 Scheduler If you are using Prometheus Remote Write you will need to add the following metric relabel config for this label.\n- action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_scheduler replacement: true The dashboard provides information on the RKE2 Scheduler. List of Metrics Metric name go_build_info go_gc_duration_seconds go_gc_duration_seconds_count go_gc_duration_seconds_sum go_goroutines go_info go_memstats_buck_hash_sys_bytes go_memstats_gc_sys_bytes go_memstats_heap_alloc_bytes go_memstats_heap_idle_bytes go_memstats_heap_inuse_bytes go_memstats_heap_released_bytes go_memstats_heap_sys_bytes go_memstats_lookups_total go_memstats_mallocs_total go_memstats_mcache_inuse_bytes go_memstats_mcache_sys_bytes go_memstats_mspan_inuse_bytes go_memstats_mspan_sys_bytes go_memstats_next_gc_bytes go_memstats_stack_inuse_bytes go_memstats_stack_sys_bytes go_memstats_sys_bytes go_threads process_cpu_seconds_total process_max_fds process_open_fds rest_client_request_duration_seconds_count rest_client_request_duration_seconds_sum rest_client_requests_total scheduler_e2e_scheduling_duration_seconds_count scheduler_e2e_scheduling_duration_seconds_sum scheduler_pending_pods scheduler_pod_scheduling_attempts_count scheduler_pod_scheduling_attempts_sum scheduler_schedule_attempts_total sysdig_container_cpu_cores_used sysdig_container_memory_used_bytes workqueue_adds_total workqueue_depth workqueue_queue_duration_seconds_count workqueue_queue_duration_seconds_sum workqueue_retries_total workqueue_unfinished_work_seconds workqueue_work_duration_seconds_count workqueue_work_duration_seconds_sum PrerequisitesNone.\nInstallationInstalling an exporter is not required for this integration.\nAgent ConfigurationThe default agent job for this integration is as follows:\n- job_name: rancher-rke2-scheduler-default bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token scheme: https tls_config: ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ - source_labels: [__meta_kubernetes_pod_phase] action: keep regex: Running - action: keep source_labels: - __meta_kubernetes_namespace - __meta_kubernetes_pod_name separator: \u0026#39;/\u0026#39; regex: \u0026#39;kube-system/kube-scheduler.+\u0026#39; - source_labels: - __address__ action: replace target_label: __address__ replacement: localhost:10259 - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name - action: replace source_labels: [ __address__ ] target_label: _sysdig_integration_rke2_scheduler replacement: true ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/rancher-rke2-scheduler/"},{"id":598,"title":"S3 Capture Storage","content":"The following alternative storage options are available for SaaS:\nCustom AWS S3: Use your own custom AWS S3 bucket for storage. Through the UI Through the API (For Secure-only users) AWS-Compatible: Use AWS-compatible storage, such as GCP, Minio, or IBM Cloud Object Storage. Through the API (for all users) On-Prem users should see (On-Prem) Configure Custom S3 Storage.\n(SaaS) Configure Custom AWS S3 StorageIf you want to use your own AWS S3 bucket, you must append some code to the Identity Access Management (IAM) Policy you created in AWS for Sysdig integration.\nAWS integration is only available through the Monitor UI. If you are on a Secure-only SaaS license, you will need to configure your integrate AWS with Sysdig via API commands. See (SaaS Sysdig Secure Only) Configure Custom S3 Endpoint.\nPrerequisites Your AWS account must be integrated with Sysdig. Ensure there is a valid account visible in Settings \u0026gt; S3 Capture Storage.\nHave an AWS bucket set up. Have your bucket name ready.\nSet Up Your AWS Bucket Log in to AWS, and add the following code snippet in your Identity and Access Management (IAM) page:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Action\u0026#34;: [ \u0026#34;s3:Put*\u0026#34;, \u0026#34;s3:List*\u0026#34;, \u0026#34;s3:Delete*\u0026#34;, \u0026#34;s3:Get*\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:s3:::BUCKET_NAME\u0026#34;, \u0026#34;arn:aws:s3:::BUCKET_NAME/*\u0026#34; ] } ] } Replace BUCKET_NAME with the bucket name you chose.\nIf you are using AWS Key Management Service (KMS) for AWS S3 encryption, ensure that necessary privileges are given to the Sysdig Account or Role to use the custom key.\nUse the Key users option to do so:\nLog in to Sysdig Monitor, and navigate to the S3 Capture Storage page via Settings or Integrations.\nToggle to Enable custom S3 bucket and enter your AWS S3 bucket name.\nEnsure that you enter the exact name you\u0026rsquo;ve used earlier.\nIgnore the optional fields Principal and Trace files root folder.\nIgnore the optional code snippet generated on this page.\nCode snippet might result in an error.\nEnable SSE-C encryption if needed.\nThe key must be AES-256 and Base64 encoded. When this option is enabled, all data is stored and read by using the provided key. Use the correct key to avoid loosing access to the data.\nUpon setting or changing the SSE-C key, the old data will become unreadable. Sysdig does not provide tools for migrating the data.\nTo Test: Capture a Trace File in Sysdig Monitor UIWhen configured successfully, you will have the option to select between Sysdig Monitor Storage or your own storage bucket when configuring a capture.\nS3 Storage API DescriptionThe endpoint for configuring S3 Storage is /api/sysdig/settings.\nThe endpoint takes the following parameters as part of the payload:\nenabled: Boolean. Specifies if this S3 bucket enabled or not. enabledSSE: Boolean. Specifies if Server Side Encryption should be enabled (default on for AWS). enabledSSE_C: Boolean. Specifies if the user Provided Server-Side Encryption key should be used. customerEncryptionKey: String. The Base64-encoded AES256 encryption key to be used. Applicable only if enabledSSE_C is used. buckets providerKeyId: Integer. The API provider key ID. Retrieved from the call to /api/providers. name: String. A unique name to identify your S3 bucket. description: String. A description about the S3 bucket. region: String. A label that identifies where the S3 bucket is located. endpoint: String. The endpoint label. folder: String. The folder path. For example: \u0026ldquo;/\u0026rdquo;. pathStyleAccess: Boolean. Specifies if the Path Style Access should be forced. true: Force path style access. false or null: Try to infer. If the endpoint contains an IP, use path style access. If the endpoint contains a DNS name, use virtual host style access. awsKey: String: Obsolete; not used any more. Not all parameters are required and required parameters depend on the use case. See below for specific use cases.\n(SaaS Secure Only) Configure Custom S3 EndpointIf your Sysdig license does not include Sysdig Monitor, you will not be able to integrate AWS through the UI. Instead, configure your AWS S3 storage bucket by executing two HTTP requests against the Sysdig API. This can be accomplished through either using an ID and KEY or AWS Role Delegation.\nUse ID and Key This is the recommended method for the GCP-hosted regions, such as US West and the Middle East. See SaaS Regions. For all other regions and on-prem, we recommend you Use AWS Role Delegation.\nPrerequisites Have an AWS S3 Storage bucket set up.\nHave your AWS ID (Access Key ID) and key (Secret Access Key) ready.\nConfigure a Custom S3 Bucket Create a new customer provider key setting with POST endpoint: /api/providers\ncurl $HOST \\ -k -X POST \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer ${TOKEN}\u0026#34; \\ -d \u0026#34;{ \\\u0026#34;name\\\u0026#34;: \\\u0026#34;aws\\\u0026#34;, \\\u0026#34;credentials\\\u0026#34;: { \\\u0026#34;id\\\u0026#34;: \\\u0026#34;${ID}\\\u0026#34;, \\\u0026#34;key\\\u0026#34;: \\\u0026#34;${KEY}\\\u0026#34; }}\u0026#34; Example result after running the first query:\n{ \u0026#34;provider\u0026#34;: { \u0026#34;id\u0026#34;: \u0026lt;PROVIDER_ID\u0026gt;, \u0026#34;name\u0026#34;: \u0026#34;aws\u0026#34;, \u0026#34;credentials\u0026#34;: { \u0026#34;id\u0026#34;: \u0026#34;*****\u0026#34;, \u0026#34;role\u0026#34;: null }, \u0026#34;tags\u0026#34;: [], \u0026#34;status\u0026#34;: { \u0026#34;status\u0026#34;: \u0026#34;configured\u0026#34;, \u0026#34;lastUpdate\u0026#34;: 1683114364207, \u0026#34;percentage\u0026#34;: 0, \u0026#34;lastProviderMessages\u0026#34;: [] }, \u0026#34;alias\u0026#34;: null, \u0026#34;accountId\u0026#34;: null, \u0026#34;skipFetch\u0026#34;: false, \u0026#34;regions\u0026#34;: null } } Note the id from this response.\nCreate a new storage configuration with POST endpoint: /api/sysdig/settings. Set providerKeyId to the database id generated by your previous POST command. BUCKET_NAME must match your bucket name:\ncurl $HOST \\ -k -X POST \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer ${TOKEN}\u0026#34; \\ -d \u0026#34;{ \\\u0026#34;enabled\\\u0026#34;: true, \\\u0026#34;buckets\\\u0026#34;: [{ \\\u0026#34;folder\\\u0026#34;:\\\u0026#34;/\\\u0026#34;, \\\u0026#34;name\\\u0026#34;: \\\u0026#34;${BUCKET_NAME}\\\u0026#34;, \\\u0026#34;providerKeyId\\\u0026#34;: ${PROVIDER_ID} }] }\u0026#34; Example result after running the second query:\n{ \u0026#34;enabled\u0026#34;: true, \u0026#34;enabledSSE\u0026#34;: false, \u0026#34;buckets\u0026#34;: [ { \u0026#34;awsKey\u0026#34;: null, \u0026#34;name\u0026#34;: \u0026#34;\u0026lt;BUCKET_NAME\u0026gt;\u0026#34;, \u0026#34;folder\u0026#34;: \u0026#34;/\u0026#34;, \u0026#34;description\u0026#34;: null, \u0026#34;providerKeyId\u0026#34;: \u0026lt;PROVIDER_ID\u0026gt;, \u0026#34;endpoint\u0026#34;: null, \u0026#34;region\u0026#34;: null } ] } Your custom S3 storage has now been configured for Secure. To test, check you have the option to select between Sysdig Secure Storage or your own storage bucket when configuring a capture.\nUse AWS Role Delegation This is the recommended method for most regions. For GCP-hosted regions, such as US West and the Middle East, we recommend you Use ID and Key.\nPrerequisites Create a role and Configure Role Delegation.\nEnsure you use the correct Sysdig Account ID. See AWS Account IDs.\nHave an AWS S3 bucket set up.\nConfigure a custom S3 bucket Create a policy with these permissions:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Action\u0026#34;: [ \u0026#34;s3:Put*\u0026#34;, \u0026#34;s3:List*\u0026#34;, \u0026#34;s3:Delete*\u0026#34;, \u0026#34;s3:Get*\u0026#34; ], \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:s3:::BUCKET_NAME\u0026#34;, \u0026#34;arn:aws:s3:::BUCKET_NAME/*\u0026#34; ] } ] } Replace BUCKET_NAME with the name of your S3 bucket.\nLink the role with the policy above.\nCreate a new customer provider key setting with POST endpoint: /api/providers.\ncurl $HOST \\ -k -X POST \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer ${TOKEN}\u0026#34; \\ -d \u0026#34;{ \\\u0026#34;name\\\u0026#34;: \\\u0026#34;aws\\\u0026#34;, \\\u0026#34;role\\\u0026#34;: \\\u0026#34;${ARN}\u0026#34;\\\u0026#34;}\u0026#34; Replace ARN with the Amazon Resource Name (ARN) of your AWS role.\nHere\u0026rsquo;s a sample result after running the first query. \u0026lt;ACCOUNT_ID\u0026gt; is the AWS Account ID, \u0026lt;ROLE_NAME\u0026gt; is the name of the role, and \u0026lt;PROVIDER_ID\u0026gt; is the provider ID in Sysdig.\n{ \u0026#34;provider\u0026#34;: { \u0026#34;id\u0026#34;: \u0026lt;PROVIDER_ID\u0026gt;, \u0026#34;name\u0026#34;: \u0026#34;aws\u0026#34;, \u0026#34;credentials\u0026#34;: { \u0026#34;id\u0026#34;: \u0026#34;role_delegation\u0026#34;, \u0026#34;role\u0026#34;: \u0026#34;arn:aws:iam::\u0026lt;ACCOUNT_ID\u0026gt;:role/\u0026lt;ROLE_NAME\u0026gt;\u0026#34; }, \u0026#34;tags\u0026#34;: [], \u0026#34;status\u0026#34;: { \u0026#34;status\u0026#34;: \u0026#34;\u0026#34;, \u0026#34;lastUpdate\u0026#34;: 1683823773381, \u0026#34;percentage\u0026#34;: 0, \u0026#34;lastProviderMessages\u0026#34;: [] }, \u0026#34;alias\u0026#34;: null, \u0026#34;accountId\u0026#34;: \u0026#34;\u0026lt;ACCOUNT_ID\u0026gt;\u0026#34;, \u0026#34;skipFetch\u0026#34;: false, \u0026#34;regions\u0026#34;: null } Note the id from this response.\nCreate a new storage configuration with POST endpoint: /api/sysdig/settings\ncurl $HOST \\ -k -X POST \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer $TOKEN\u0026#34; \\ -d \u0026#34;{ \\\u0026#34;enabled\\\u0026#34;: true, \\\u0026#34;buckets\\\u0026#34;: [{ \\\u0026#34;folder\\\u0026#34;:\\\u0026#34;/\\\u0026#34;, \\\u0026#34;name\\\u0026#34;: \\\u0026#34;${BUCKET_NAME\\\u0026#34;, \\\u0026#34;providerKeyId\\\u0026#34;: ${PROVIDER_ID} }] }\u0026#34; The providerKeyId parameter should be set to the database id that was generated from the previous POST command.\nBUCKET_NAME must match your bucket name.\nHere\u0026rsquo;s a sample result after running the second query:\n{ \u0026#34;enabled\u0026#34;: true, \u0026#34;enabledSSE\u0026#34;: false, \u0026#34;buckets\u0026#34;: [ { \u0026#34;awsKey\u0026#34;: null, \u0026#34;name\u0026#34;: \u0026#34;\u0026lt;BUCKET_NAME\u0026gt;\u0026#34;, \u0026#34;folder\u0026#34;: \u0026#34;/\u0026#34;, \u0026#34;description\u0026#34;: null, \u0026#34;providerKeyId\u0026#34;: \u0026lt;PROVIDER_ID\u0026gt;, \u0026#34;endpoint\u0026#34;: null, \u0026#34;region\u0026#34;: \u0026#34;us-east-1\u0026#34; } ] } Your custom S3 storage has now been configured for Secure. To test, check you have the option to select between Sysdig Secure Storage or your own storage bucket when configuring a capture.\n(SaaS) Configure Custom S3 StorageYou can set up a custom AWS-S3-compatible storage, such as GCP, Minio, and IBM Cloud Object Storage, for storing Captures and Rapid Response logs. This is an API-only functionality and currently no UI support is available.\nIf Google Cloud Storage is used as the S3-compatible storage, you will not be able to bulk delete captures due to compatibility issues with Google’s S3 API implementation. You can delete captures one by one or delete them directly from the Google console.\nThe example below is for GCP, but is easily adaptable to Minio and IBM Cloud Object Storage.\nTo configure a Custom S3 bucket via the Sysdig API, follow these steps:\nGet hold of an id and key. In GCP, for example, this is found in the Interoperability tab of the GCP Storage settings.\nCreate a new customer provider key setting with POST endpoint: /api/providers, using the parameters you\u0026rsquo;ve generated in step 1.\ncurl $HOST \\ -k -X POST \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer $TOKEN\u0026#34; \\ -d \u0026#34;{ \\\u0026#34;name\\\u0026#34;: \\\u0026#34;aws\\\u0026#34;, \\\u0026#34;skipFetch\\\u0026#34;: true, \\\u0026#34;credentials\\\u0026#34;: { \\\u0026#34;id\\\u0026#34;: \\\u0026#34;${ID}\\\u0026#34;, \\\u0026#34;key\\\u0026#34;: \\\u0026#34;${KEY}\\\u0026#34; }}\u0026#34; Create a new storage configuration with POST endpoint: /api/sysdig/settings, using the database id you generated in step 2 for the providerKeyId parameter.\ncurl $HOST \\ -k -X POST \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer $TOKEN\u0026#34; \\ -d \u0026#34;{ \\\u0026#34;enabled\\\u0026#34;: true, \\\u0026#34;buckets\\\u0026#34;: [{ \\\u0026#34;folder\\\u0026#34;:\\\u0026#34;/\\\u0026#34;, \\\u0026#34;name\\\u0026#34;: \\\u0026#34;$BUCKET_NAME\\\u0026#34;, \\\u0026#34;providerKeyId\\\u0026#34;: $PROVIDER_KEY, \\\u0026#34;endpoint\\\u0026#34;: \\\u0026#34;$ENDPOINT\\\u0026#34; }] }\u0026#34; In the case of GCP, the endpoint parameter should be set to https://storage.googleapis.com\nWhen including a folder name, omit any prefix slashes. For example, “test-folder” is acceptable, but not \u0026quot;/test-folder\u0026quot;.\n(On-Prem) Configure Custom S3 StorageYou can set up a custom Amazon-S3-compatible storage, such as Minio or IBM Cloud Object Storage, for storing Captures and Rapid Response logs in a Sysdig on-premises deployment. The storage location can be used for both Sysdig Monitor and Sysdig Secure. This is an API-only functionality and currently, no UI support is available.\nIn the steps below, you will configure values.yaml in accordance with your Sysdig installation.\nPrerequisites Your on-premises installation is Installer-based. If you have installed Sysdig Platform manually and you want to configure custom S3 buckets to store your files, contact your Sysdig representative.\nEnsure that AWS-client compatible credentials used for authentication are present in the environment.\nEnsure that the list, get, and put operations are functional on the S3 bucket that you wish to use. Confirm this by using the S3 native tools, for example, as described in AWS Command Line Interface (CLI) for IBM Cloud.\nConfigure InstallerConfigure the following parameters in the values.yaml file so that collectors, workers, and the API server are aware of the custom endpoint configuration.\nsysdig.s3.enabled\nRequired: true Description: Specifies if storing Sysdig Captures in S3 or S3-compatible storage is enabled or not. Options:true|false Default:false For example:\nsysdig: s3: enabled: true sysdig.s3.endpoint\nRequired: true Description: The S3 or S3-compatible endpoint for the bucket. This option is ignored if sysdig.s3.enabled is not configured. For example:\nsysdig: s3: endpoint: \u0026lt;your S3-Compatible custom bucket\u0026gt; sysdig.s3.capturesFolder\nRequired: false Description: Name of the folder in S3 bucket to be used for storing captures, this option is ignored if sysdig.s3.enabled is not configured. For example:\nsysdig: s3: capturesFolder: my_captures_folder The path to the capture folder in the S3 bucket will be ​{​​customerId​​}/{​my_captures_folder​​}​​. For on-prem deployments, the ​customerID​ is ​1​​. If your capture folder is named ​finance​, the path to the folder in the S3 bucket will be 1/finance​​.\nsysdig.s3.bucketName\nRequired: true Description: The name of the S3 or S3-compatible bucket to be used for captures. This option is ignored if sysdig.s3.enabled is not configured For example:\nsysdig: s3: bucketName: \u0026lt;Name of the S3-compatible bucket to be used for captures\u0026gt; sysdig.accessKey\nRequired: true Description: The AWS or AWS-compatible access key to be used by Sysdig components to write captures in the S3 bucket. For example:\nsysdig: accessKey: \u0026lt;AWS-compatible access key\u0026gt; sysdig.secretKey\nRequired: true Description: The AWS or AWS-compatible secret key to be used by Sysdig components to write captures in the s3 bucket. For example:\nsysdig: secretKey: \u0026lt;AWS-compatible secret key\u0026gt; Starting from on-premise version 7.4.0 the values.yaml schema has changed. See the release notes for more details.\nUpdated Configuration (version 7.4.0 and later)global: legacyS3: s3: enabled: true endpoint: \u0026lt;your S3-Compatible custom bucket\u0026gt; bucketName: \u0026lt;Name of the S3-compatible bucket to be used for captures\u0026gt; capturesFolder: \u0026lt;my_captures_folder\u0026gt; accessKey: my_awesome_aws_access_key secretKey: my_super_secret_secret_key The following AWS CLI command uploads a Sysdig Capture file to a Minio bucket:\naws --profile minio --endpoint http://10.101.140.1:9000 s3 cp \u0026lt;Sysdig Capture filename\u0026gt; s3://test/ In this case, the endpoint is http://10.101.140.1:9000/ and the name of the bucket is test.\nWhen you finish the S3 configuration, continue with the instructions for on-premises installation by using the Installer.\n","url":"https://docs.sysdig.com/en/administration/s3_capture_storage/"},{"id":599,"title":"Sysdig API","content":"API Documentation StatusSysdig is actively working on improving the Sysdig API. There are two documentation versions:\nNext Gen Sysdig API docs — This includes new API versions standardized for both Sysdig Monitor and Sysdig Secure. Current Sysdig API docs — You can still use the current APIs until all the new API versions are introduced. Getting StartedAuthenticationTo use the APIs, you must authenticate with one of the following authentication options:\nTeam-Based Service Account Global Service Account Sysdig API token (user-based) To use any of the methods, set an Authorization header and provide a Bearer token:\nAuthorization: Bearer { team-based service account | global service account | api token } Obtain the Sysdig API TokenSee Retrieve the Sysdig API Token for instructions on retrieving the API token.\nObtain the Service AccountSee Service Accounts for instructions on retrieving the Team-Based Service Account.\nAuthorizationThe API documentation provides the permissions required to access a specific endpoint. Available permissions depend on the selected role. Not all permissions or roles are available for Team-Based Service Accounts because they are based on User (non-admin) roles.\nSee Understand Sysdig Users for more information.\nConventionsAPI access is over HTTPS. Data is sent and received primarily in JSON format.\nHTTP PUT Request Method ConventionEnsure that you provide all fields in the endpoint when using the PUT method, unless otherwise specified in the API endpoint documentation.\nPerform the HTTP GET request first to obtain the contents before making any changes.\nSee the endpoint documentation before using HTTP PUT method.\nAccess the Sysdig API Using the Regional EndpointsIf you are using Sysdig SaaS, use the following links to access the standardized Sysdig API for each region:\nRegion Hostname US East (North Virginia) https://api.us1.sysdig.com US West (Oregon) https://api.us2.sysdig.com US-3 https://api.us3.sysdig.com US West (GCP) https://api.us4.sysdig.com EU Central (Frankfurt) https://api.eu1.sysdig.com EU North (Stockholm) https://api.eu2.sysdig.com Asia Pacific (Sydney) https://api.au1.sysdig.com Middle East (Dammam - GCP) https://api.me2.sysdig.com Asia Pacific South (Mumbai) https://api.in1.sysdig.com Access the Sysdig APIs Using HostnameIf you are using Sysdig On-Prem, you can access public APIs use the Sysdig hostname.\nUse the format https://api.sysdig.dnsName, where sysdig.dnsName is the hostname from the Installer values.\nAccess the DocumentationYou can access the API docs through the UI or directly using the URL of your SaaS region or On-Prem installation.\nAccess from the Sysdig UI Log in to either Sysdig Monitor or Sysdig Secure and click the User menu at the bottom of the left navigation bar.\nLook for the group labeled Help, where you will find two entries:\nNext Gen API Docs - Updated and standardized Sysdig API documentation Current API Docs - Current Sysdig API documentation Access Next Gen API Documentation Using Regional EndpointsIf you are using Sysdig SaaS, you can access the Next Gen API documentation directly with the following links. The correct link will depend on your SaaS region. See SaaS Regions and IP Ranges for details.\nRegion Secure Monitor US East (North Virginia) https://secure.sysdig.com/apidocs/secure?_product=SDS https://app.sysdigcloud.com/apidocs/monitor?_product=SDC US West (Oregon) https://us2.app.sysdig.com/apidocs/secure?_product=SDS https://us2.app.sysdig.com/apidocs/monitor?_product=SDC US-3 https://app.us3.sysdig.com/apidocs/secure?_product=SDS https://app.us3.sysdig.com/apidocs/monitor?_product=SDC US West (GCP) https://app.us4.sysdig.com/apidocs/secure?_product=SDS https://app.us4.sysdig.com/apidocs/monitor?_product=SDC EU Central (Frankfurt) https://eu1.app.sysdig.com/apidocs/secure?_product=SDS https://eu1.app.sysdig.com/apidocs/monitor?_product=SDC EU North (Stockholm) https://app.eu2.sysdig.com/apidocs/secure?_product=SDS https://app.eu2.sysdig.com/apidocs/monitor?_product=SDC Asia Pacific (Sydney) https://app.au1.sysdig.com/apidocs/secure?_product=SDS https://app.au1.sysdig.com/apidocs/monitor?_product=SDC Middle East (Dammam - GCP) https://app.me2.sysdig.com/apidocs/secure?_product=SDS https://app.me2.sysdig.com/apidocs/monitor?_product=SDC Asia Pacific South (Mumbai) https://app.in1.sysdig.com/apidocs/secure?_product=SDS https://app.in1.sysdig.com/apidocs/monitor?_product=SDC Access Current API Documentation Using Regional EndpointsIf you are using Sysdig SaaS, you can access the Current API documentation directly with the following links. The correct link will depend on your SaaS region. See SaaS Regions and IP Ranges for details.\nRegion Secure Monitor US East (North Virginia) https://secure.sysdig.com/secure/swagger.html https://app.sysdigcloud.com/api/public/docs/index.html US West (Oregon) https://us2.app.sysdig.com/secure/swagger.html https://us2.app.sysdig.com/api/public/docs/index.html US-3 https://app.us3.sysdig.com/secure/swagger.html https://app.us3.sysdig.com/api/public/docs/index.html US West (GCP) https://app.us4.sysdig.com/secure/swagger.html https://app.us4.sysdig.com/api/public/docs/index.html EU Central (Frankfurt) https://eu1.app.sysdig.com/secure/swagger.html https://eu1.app.sysdig.com/api/public/docs/index.html EU North (Stockholm) https://app.eu2.sysdig.com/secure/swagger.html https://app.eu2.sysdig.com/api/public/docs/index.html Asia Pacific (Sydney) https://app.au1.sysdig.com/secure/swagger.html https://app.au1.sysdig.com/api/public/docs/index.html Middle East (Dammam - GCP) https://app.me2.sysdig.com/secure/swagger.html https://app.me2.sysdig.com/api/public/docs/index.html Asia Pacific South (Mumbai) https://app.in1.sysdig.com/secure/swagger.html https://app.in1.sysdig.com/api/public/docs/index.html ","url":"https://docs.sysdig.com/en/developer-tools/sysdig-api/"},{"id":600,"title":"Troubleshoot Monitoring Integrations","content":"If you are directed to this page from the Sysdig Monitor app, your agent deployment might include a configuration that:\nProhibits the use of Monitoring Integrations Affect the metrics you are currently collecting Ensure that you meet the prerequisites to successfully use Monitoring Integrations. For technical assistance, contact Sysdig Support.\nCheck PrerequisitesTo use Monitoring Integrations, ensure the following prerequisites are met:\nSysdig agent v12.0.0+\nIf you have clusters with more than 50 nodes and don\u0026rsquo;t have the prom_service_discovery option enabled:\nEnabling the latest Prometheus features might create an additional connection to the Kubernetes API server from each Sysdig agent in your environment. The surge in agent connections can increase the CPU and memory load in your API servers. Therefore, ensure that your API servers are suitably sized to handle the increased load in large clusters. Remove the following manual configurations in the dragent.yaml file because they might interfere with those provided by Sysdig:\nuse_promscrape promscrape_fastproto prom_service_discovery prometheus.max_metrics prometheus.ingest_raw prometheus.ingest_calculated The sysdig_sd_configs configuration is no longer supported. Remove the existing prometheus.yaml if it includes the sysdig_sd_configs configuration.\nIf you are not currently using Prometheus metrics in Sysdig Monitor, you can skip the following steps:\nIf you are using a custom Prometheus process_filter in dragent.yaml to trigger scraping, see Migrating from Promscrape V1 to V2.\nIf you are using service annotations or container labels to find scrape targets, you may need to create new scrape_configs in prometheus.yaml , preferably based on Kubernetes pods service discovery. This configuration can be complicated in certain environments and therefore we recommend that you contact Sysdig support for help.\nSome integrations require secrets and other resources available in the correct namespace in order for it to work. Integrations such as database exporters might require you to create a user and provide special permissions in the database to connect to the endpoint and generate metrics.\nVerify the Exporter is RunningSome integrations require exporters. If the problematic integration uses an exporter, ensure the pods corresponding to the exporter are running correctly. You can check this after installing the integration. If the exporter is installed as a sidecar of the application (such as Nginx), verify that the exporter container is added to the pod.\nYou can check the status of the pods with the Kubernetes dashboard Pod Status \u0026amp; Performance, or with the following command:\nkubectl get pods --namespace=\u0026lt;namespace\u0026gt; Additionally, if the container has problems and cannot start, use this command to check the description of the pod for error messages:\nkubectl describe pod \u0026lt;pod-name\u0026gt; --namespace=\u0026lt;namespace\u0026gt; Verify Metrics Are GeneratedCheck whether a running exporter is generating metrics by accessing the metrics endpoint:\nkubectl port-forward \u0026lt;pod-name\u0026gt; \u0026lt;pod-port\u0026gt; \u0026lt;local-port\u0026gt; --namespace=\u0026lt;namespace\u0026gt; curl http://localhost:\u0026lt;local-port\u0026gt;/metrics This is also valid for applications that don\u0026rsquo;t need an exporter to generate their own metrics.\nIf the exporter is not generating metics, there could be problems accessing or authenticating with the application. Check the logs associated with the pods:\nkubectl logs \u0026lt;pod-name\u0026gt; --namespace=\u0026lt;namespace\u0026gt; If the application is instrumented and is not generating metrics, check if the Prometheus metrics option or the module is activated.\nVerify Sysdig Agent Is Scraping MetricsIf an application doesn\u0026rsquo;t need an exporter to generate metrics, check if it has the default Prometheus annotations.\nAdditionally, you can check if the Sysdig agent can access the metrics endpoint with the following command:\nkubectl exec \u0026lt;sysdig-agent-pod-name\u0026gt; --namespace=sysdig-agent -- /bin/sh -c \u0026#34;curl http://\u0026lt;exporer-pod-ip\u0026gt;:\u0026lt;pod-port\u0026gt;/metrics\u0026#34; Select the Sysdig Agent pod in the same node than the pod used to scrape.\nContact SupportIf your problems persist after troubelshooting, contact Sysdig Support.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/monitoring-integrations/troubleshoot-integrations/"},{"id":601,"title":"Troubleshooting Agent","content":"Disconnecting AgentsIf agents are disconnecting, there could be problems with addresses that need to be resolved in the agent configuration files. See also Understanding the Agent Config Files.\nCheck for Duplicate MAC addressesThe Sysdig agent will use the eth0 MAC address to identify the different hosts within an infrastructure. In a virtualized environment, you should confirm each of your VM\u0026rsquo;s eth0 MAC addresses are unique.\nIf a unique address cannot be configured, you can supply an additional parameter in the Sysdig agent\u0026rsquo;s dragent.yaml configuration file: machine_id_prefix: prefix\nThe prefix text can be any string and will be prepended to the MAC address as reported in the Sysdig Monitor web interface\u0026rsquo;s Explore tables.\nExample: (using ADDITIONAL_CONF rather than Kubernetes Configmap)\nHere is an example Docker run command installing the parameter via the ADDITIONAL_CONF parameter\ndocker run --name sysdig-agent --privileged --net host --pid host -e ACCESS_KEY=abc123-1234-abcd-4321-abc123def456 -e TAGS=tag1:value1 -e ADDITIONAL_CONF=\u0026#34;machine_id_prefix: MyPrefix123-\u0026#34; -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro sysdig/agent The resulting /opt/draios/etc/dragent.yaml config file would look like this:\ncustomerid:abc123-1234-abcd-4321-abc123def456 tags: tag1:value1 machine_id_prefix: MyPrefix123- You will then see all of your hosts, provided that all the prefixes are unique. The prefix will be visible whenever the MAC address is displayed in any view.\nSee also: Agent Configuration.\nCheck for Conflicting MAC addresses in GKE environmentsIn Google Container Engine (GKE) environments, MAC addresses could be repeated across multiple hosts. This would cause some hosts running Sysdig agents not to appear in your web interface.\nTo address this, add a unique machine ID prefix to each config you use to deploy the agent to a given cluster (i.e. each sysdig-daemonset.yaml file).\nNote: This example uses the (v1) ADDITIONAL_CONF, rather than (v2 Configmap method.\n- name: ADDITIONAL_CONF value: \u0026quot;machine_id_prefix: mycluster1-prefix-\u0026quot; Can\u0026rsquo;t See Metrics After Agent InstallIf agents were successfully installed, you could log in to the Sysdig Monitor UI, but no metrics are displayed in the Explore panel, first confirm that the agent license count has not been exceeded. Then check for any proxy, firewall, or host security policies preventing proper agent communication to the Sysdig Monitor backend infrastructure.\nCheck License CountIf network connectivity is good, the agent will connect to the backend but will be disconnected after a few seconds if the license count has been exceeded.\nTo check whether you are over-subscribed, go to Settings \u0026gt; Subscription.\nSee Subscription for details.\nCheck Network PolicyAgent Connection PortCheck your service provider VPC security groups to verify that network ACLs are set to allow the agent\u0026rsquo;s outbound traffic over TCP ports. See Sysdig Collector Ports for the supported TCP ports for each region.\nOutbound IP AddressesDue to the distributed nature of the Sysdig Monitor infrastructure, the agent must be open for outbound connections to collector.sysdigcloud.com on all outbound IP addresses.\nCheck Amazon\u0026rsquo;s public IP ranges file to see all the potential IP addresses the Sysdig agent can use to communicate with the Sysdig backend databases.\nAWS Metadata EndpointAWS metadata is used for gathering information about the instance itself, such as instance id, public IP address, etc.\nWhen running on an AWS instance, access to the following AWS metadata endpoint is also needed: 169.254.169.254\nCheck Local Host PolicyThe agent requires access to the following local system resources in order to gather metrics:\nRead/Write access to /dev/sysdig devices.\nRead access to all the files under /proc file system.\nFor container support, the Docker API endpoint /var/run/docker.sock\nIf any settings or firewall modifications are made, you may need to restart the agent service. In a shell on the affected instances issue the following command:\nsudo service dragent restart Troubleshoot Common ProblemsSome of the common problems you might encounter are:\nA host is not showing up in the user interface.\nThe agent log file shows \u0026ldquo;Error, connection_manager: Lost connection\u0026rdquo; messages.\nSuspect agent connectivity problems and troubleshoot for those. Inspect the agent log file is located at /opt/draios/logs/draios.log.\nPerform the following checks and see if it solves your problem:\nCheck LicensesConfirm that you have not used all available agent licenses.\nThe agent license count is available in the Settings \u0026gt; Subscription tab. Administrators can purchase additional agent licenses using the UI if needed.\nCheck FirewallConfirm basic connectivity through your firewall:\nping collector.sysdigcloud.com Check PortsConfirm the correct port is open through your firewall:\ntelnet collector.sysdigcloud.com 6443 In earlier versions, the Sysdig Agent connected to port 6666. This behavior has been deprecated, as the Sysdig Agent now connects to port 6443.\nCheck MAC AddressesCheck for duplicate MAC addresses in your hosts.\nWhen the agent starts, an entry in the /opt/draios/logs/draios.log file reports the host\u0026rsquo;s MAC:\n2016-09-26 10:20:25.982, 2363, Information, machine id: a2:11:0b:84:11:21 Compare the logged MAC address to any existing reporting agents in the Explore tab using the Hosts \u0026amp; Containers hierarchy.\nCheck Access KeySee Settings \u0026gt; Agent Access Keys for the access key and confirm that it is correct.\nThe Sysdig Agent key is configured in the agent configuration file, opt/draios/etc/dragent.yaml. See Understanding the Agent Config Files for more information.\nOut-of-memory Errors when Building kmod on ARMSome kernel versions require higher memory limits when building the kmod driver on ARM architecture. This does not affect Universal eBPF or any other architecture.\nThe default shield chart specifies 512Mi as the slim driver build memory limit, which should be increased to 768Mi for ARM.\nagent: slim: resources: limits: memory: 768Mi Upgrade the Sysdig AgentThe agent is routinely updated to include new features and resolve defects. Many times problems can be resolved by upgrading the agent. If problems persist after troubleshooting, Contact Support.\n","url":"https://docs.sysdig.com/en/sysdig-secure/troubleshooting-agent/"},{"id":602,"title":"Windows","content":" This integration is disabled by default. See Enable and Disable Integrations to enable it in your account.\nThis integration has 77 metrics.\nList of Alerts Alert Description Format [Windows] High CPU Usage The CPU of the Windows instance reached 95% of use Prometheus [Windows] High Disk Usage Disk full over 95% in instance {{$labels.instance}} Prometheus [Windows] High Physical Memory Usage High physical memory usage in instance Prometheus [Windows] High Network Inbound Errors High inbound network error rate in instance Prometheus [Windows] High Network Outbound Errors High outbound network error rate in instance Prometheus [Windows] Increase of Disk writes time Increase of Disk writes time Prometheus [Windows] Queue of Writes and reads Disk operations is growing The queue for writes and reads disk operations is growing Prometheus [Windows] High percent of swap space used The swap space has reached high amount of used Prometheus [Windows] Network bandwidth is reaching its limit Network Bandwith use is reaching its limit Prometheus [Windows] High number of transitions virtual addresses into disk The rate at which pages transition to resident memory without being written to disk has reached problematic limit Prometheus List of DashboardsWindows Host OverviewThe dashboard provides information about the Windows host. Windows Process OverviewThe dashboard provides information about the Windows processes. Windows Services OverviewThe dashboard provides information about the Windows services. Windows Node Overview (Legacy)The dashboard provides information about the Windows nodes (legacy). List of Metrics Metric name windows_cpu_core_frequency_mhz windows_cpu_time_total windows_cs_physical_memory_bytes windows_logical_disk_free_bytes windows_logical_disk_read_bytes_total windows_logical_disk_reads_total windows_logical_disk_requests_queued windows_logical_disk_size_bytes windows_logical_disk_split_ios_total windows_logical_disk_write_bytes_total windows_logical_disk_write_seconds_total windows_logical_disk_writes_total windows_memory_transition_faults_total windows_net_bytes_received_total windows_net_bytes_sent_total windows_net_bytes_total windows_net_current_bandwidth_bytes windows_net_packets_outbound_discarded_total windows_net_packets_outbound_errors windows_net_packets_outbound_errors_total windows_net_packets_received_discarded_total windows_net_packets_received_errors windows_net_packets_received_errors_total windows_net_packets_received_total windows_net_packets_sent_total windows_os_paging_free_bytes windows_os_paging_limit_bytes windows_os_physical_memory_free_bytes windows_os_processes windows_os_users windows_os_virtual_memory_bytes windows_os_virtual_memory_free_bytes windows_process_cpu_time_total windows_process_io_bytes_total windows_process_io_operations_total windows_process_threads windows_process_working_set_bytes windows_service_info windows_service_start_mode windows_service_state windows_service_status windows_system_context_switches_total windows_system_processor_queue_length windows_system_system_up_time windows_system_threads wmi_cpu_core_frequency_mhz wmi_cpu_time_total wmi_cs_physical_memory_bytes wmi_logical_disk_free_bytes wmi_logical_disk_read_bytes_total wmi_logical_disk_reads_total wmi_logical_disk_requests_queued wmi_logical_disk_size_bytes wmi_logical_disk_split_ios_total wmi_logical_disk_write_bytes_total wmi_logical_disk_writes_total wmi_net_bytes_received_total wmi_net_bytes_sent_total wmi_net_bytes_total wmi_net_current_bandwidth wmi_net_packets_outbound_discarded wmi_net_packets_outbound_errors wmi_net_packets_received_discarded wmi_net_packets_received_errors wmi_net_packets_received_total wmi_net_packets_sent_total wmi_os_paging_free_bytes wmi_os_paging_limit_bytes wmi_os_physical_memory_free_bytes wmi_os_processes wmi_os_users wmi_os_virtual_memory_bytes wmi_os_virtual_memory_free_bytes wmi_system_context_switches_total wmi_system_processor_queue_length wmi_system_system_up_time wmi_system_threads PrerequisitesWindows Prometheus BundleThe Sysdig Windows Prometheus Bundle is a comprehensive package that installs and configures a Prometheus Agent and the Windows Exporter allowing you to send metrics to your Sysdig Monitor account with ease\nGetting StartedTo begin monitoring your Windows machines, follow these steps:\nDownload the binary installer from the latest release of this project Run the installer in your windows machine Configure the Sysdig region and your Sysdig API token in the wizard Select the collectors that you want to enable to produce metrics Finish the installation Go to your Sysdig Monitor account and start using the Microsoft Windows dashboards and alerts Automated installationYou can automate the installation of the Sysdig Windows Prometheus Bundle across multiple machines using the command line or PowerShell.\nUse the following command as an example:\nmsiexec /i windows_exporter-1.0.0-x64.msi ENABLED_COLLECTORS=cpu,os SYSDIG_URL=\u0026#34;https://api.sysdigcloud.com/prometheus/remote/write\u0026#34; SYSDIG_TOKEN=\u0026#34;yyyyyyy-zzzz-zzzz-zzzz-xxxxxxxx\u0026#34; /qn This command will install the Sysdig Windows Prometheus Bundle with the specified settings, making it easy to deploy across your infrastructure.\nBy default, the Prometheus config file is installed in the path C:\\Program Files\\windows_exporter\\prometheus.yml, which can be manually edited to include additional Prometheus jobs.\nOptions and parametersFrom the command line you can use these options:\nENABLED_COLLECTORS: Comma separated list of collectors SYSDIG_URL: The Prometheus endpoint of your Sysdig Monitor region in the form https://api.sysdigcloud.com/prometheus/remote/write. Consult the available regions here. COMPUTER_NAME (optional): Overrides the label instance in metrics generated by the Windows Exporter with a custom value. The default value is the computer name stored in the COMPUTERNAME Windows environment variable. PROMETHEUS_PORT (optional): The Prometheus port. The default value is \u0026lsquo;9090\u0026rsquo;. PROMETHEUS_LOG_ENABLED (optional): The Prometheus log feature, this creates log file of the prometheus agent into the windows_exporter folder. The default value is \u0026lsquo;0\u0026rsquo;. PROMETHEUS_LOG_LEVEL (optional): The Prometheus log level, this configure the level of the log file if we previously enable the log. The default value is \u0026lsquo;info\u0026rsquo;. WINDOWS_EXPORTER_LISTEN_ADDR (optional): The Windows Exporter IP address. The default value is \u0026lsquo;0.0.0.0\u0026rsquo;. WINDOWS_EXPORTER_LISTEN_PORT (optional): The Windows Exporter port. The default value is \u0026lsquo;9182\u0026rsquo;. WINDOWS_EXPORTER_EXTRA_FLAGS (optional): Windows Exporter additional CLI flags. The default value is an empty string. WINDOWS_EXPORTER_FIREWALL_REMOTE_ADDR (optional): Comma separated remote IP addresses for the Windows Firewall exception (allow list). The default value is an empty string (any remote address). TEXTFILE_DIR (only if textfile collector is enabled): The local folder where the textfile collector will look for files Automated uninstallationUse the following command to uninstall:\nmsiexec /x windows_exporter-1.0.0-x64.msi /qn InstallationInstalling an exporter is not required for this integration.\nMonitoring and Troubleshooting WindowsThis document describes important metrics and queries that you can use to monitor and troubleshoot Windows.\nWindows Host MonitoringCPUBecause CPU usage is critical, be aware of the mode of use of CPU. With 100 * avg by (mode) (rate(windows_cpu_time_total[5m])) you can identify who is consuming the processor the most. One tip for this visualization is to focus on idle processes because they contribute to CPU usage.\nFor environments where you have huge machines and tons of cores, you can use the 100 * sum by (core) (rate(windows_cpu_time_total{mode != 'idle'}[5m])) query to check for any potential peaks in every each of them and verify that they are sharing the load correctly.\nMemoryUse the following queries to determine memory consumption in your windows host:\n100* (windows_cs_physical_memory_bytes - windows_os_physical_memory_free_bytes) / windows_cs_physical_memory_bytes\nwindows_os_physical_memory_free_bytes\nAdditionally, you can use the following alert when the memory utilization is greater than the defined threshold:\n100 * (windows_cs_physical_memory_bytes - windows_os_physical_memory_free_bytes) / windows_cs_physical_memory_bytes \u0026gt; 95 DiskDisk capacity can be monitored by windows_logical_disk_free_bytes and windows_logical_disk_size_bytes.\nWith this query you can monitor if the disk is reaching its maximum capacity:\n100 * (windows_logical_disk_size_bytes - windows_logical_disk_free_bytes) / windows_logical_disk_size_bytes \u0026gt; 95 Another factor to consider when you measure disk usage is IOPS. To monitor the write operations, use this query:\nrate(windows_logical_disk_writes_total[5m]) NetworkYou can monitor network error rate for inbound and outbound packages with these following queries:\n100 * rate(windows_net_packets_received_errors[5m]) / (rate(windows_net_packets_received_errors[5m]) + rate(windows_net_packets_received_total[5m])\u0026gt;0) \u0026gt; 75 100 * rate(windows_net_packets_outbound_errors[5m]) / (rate(windows_net_packets_outbound_errors[5m]) + rate(windows_net_packets_sent_total[5m])\u0026gt;0) \u0026gt; 75 Windows Process MonitoringYou can manage processes inside your machine and be aware about CPU that every process consume with the metric windows_process_cpu_time_total for CPU, and the metric windows_process_working_set_bytes for memory.\nYou can track Input and Output operations by process with the metric windows_process_io_operations_total. This metric will give you information about some process that can overload your system.\nWindows Service MonitoringYou can know about the status and health of the services inside your environment.\nYou can use this query to monitor the services that are running aggregated by status.\ncount by (status,instance)((windows_service_status \u0026gt; 0) * on (name) group_left(state) (windows_service_state{state=~\u0026#34;running\u0026#34;} \u0026gt; 0)) In order to identify every single behavior that is critical for your infrastructure, you have to learn about the properties and states of your services.\nFor state you need to focus on stopped and running, for start mode you have auto, manual and disabled and for status you will manage ok and error.\nWith those properties defined, you can monitor your services in running state and error status with the following query:\ncount(windows_service_status{status=~\u0026#34;error\u0026#34;} \u0026gt; 0) You can also verify the services that are disabled with the following query:\nsum by(name,instance) (windows_service_start_mode{start_mode=~\u0026#34;disabled\u0026#34;} \u0026gt; 0) Agent ConfigurationThis integration has no default agent job.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/integration-library/windows/"},{"id":603,"title":"(Legacy) Example Configuration","content":"Default ConfigurationAs an example that pulls together many of the configuration elements shown above, consider the default Agent configuration that\u0026rsquo;s inherited from the dragent.default.yaml.\nprometheus: enabled: true interval: 10 log_errors: true max_metrics: 1000 max_metrics_per_process: 100 max_tags_per_metric: 20 # Filtering processes to scan. Processes not matching a rule will not # be scanned # If an include rule doesn\u0026#39;t contain a port or port_filter in the conf # section, we will scan all the ports that a matching process is listening to. process_filter: - exclude: process.name: docker-proxy - exclude: container.image: sysdig/agent # special rule to exclude processes matching configured prometheus appcheck - exclude: appcheck.match: prometheus - include: container.label.io.prometheus.scrape: \u0026#34;true\u0026#34; conf: # Custom path definition # If the Label doesn\u0026#39;t exist we\u0026#39;ll still use \u0026#34;/metrics\u0026#34; path: \u0026#34;{container.label.io.prometheus.path}\u0026#34; # Port definition # - If the Label exists, only scan the given port. # - If it doesn\u0026#39;t, use port_filter instead. # - If there is no port_filter defined, skip this process port: \u0026#34;{container.label.io.prometheus.port}\u0026#34; port_filter: - exclude: [9092,9200,9300] - include: 9090-9500 - include: [9913,9984,24231,42004] - exclude: container.label.io.prometheus.scrape: \u0026#34;false\u0026#34; - include: kubernetes.pod.annotation.prometheus.io/scrape: true conf: path: \u0026#34;{kubernetes.pod.annotation.prometheus.io/path}\u0026#34; port: \u0026#34;{kubernetes.pod.annotation.prometheus.io/port}\u0026#34; - exclude: kubernetes.pod.annotation.prometheus.io/scrape: false Consider the following about this default configuration:\nAll Prometheus scraping is disabled by default. To enable the entire configuration shown here, you would only need to add the following to your dragent.yaml:\nprometheus: enabled: true Enabling this option and any pods (in case of Kubernetes) that have the right annotation set or containers (if not) that have the labels set will automatically be scrapped.\nOnce enabled, this default configuration is ideal for the use case described in the Quick Start For Kubernetes Environments.\nA Process Filter rule excludes processes that are likely to exist in most environments but are known to never export Prometheus metrics, such as the Docker Proxy and the Agent itself.\nAnother Process Filter rule ensures that any processes configured to be scraped by the legacy Prometheus application check will not be scraped.\nAnother Process Filter rule is tailored to use container Labels. Processes marked with the container Label io.prometheus.scrape will become eligible for scraping, and if further marked with container Labels io.prometheus.port and/or io.prometheus.path, scraping will be attempted only on this port and/or endpoint. If the container is not marked with the specified path Label, scraping the /metrics endpoint will be attempted. If the container is not marked with the specified port Label, any listening ports in the port_filter will be attempted for scraping (this port_filter in the default is set for the range of ports for common Prometheus exporters, with exclusions for ports in the range that are known to be used by other applications that are not exporters).\nThe final Process Filter Include rule is tailored to the use case described in the Quick Start For Kubernetes Environments.\nScrape a Single Custom ProcessIf you need to scrape a single custom process, for instance, a java process listening on port 9000 with path /prometheus, add the following to the dragent.yaml:\nprometheus: enabled: true process_filter: - include: process.name: java port: 9000 conf: # ensure we only scrape port 9000 as opposed to all ports this process may be listening to port: 9000 path: \u0026#34;/prometheus\u0026#34; This configuration overrides the default process_filter section shown in Default Configuration. You can add relevant rules from the default configuration to this to further filter down the metrics.\nport has different purposes depending on where it\u0026rsquo;s placed in the configuration. When placed under the include section, it is a condition for matching the include rule.\nPlacing a port under conf indicates that only that particular port is scraped when the rule is matched as opposed to all the ports that the process could be listening on.\nIn this example, the first rule will be matched for the Java process listening on port 9000. The java process listening only on port 9000 will be scrapped.\nScrape a Single Custom Process Based on Container LabelsIf you still want to scrape based on container labels, you could just append the relevant rules from the defaults to the process_filter. For example:\nprometheus: enabled: true process_filter: - include: process.name: java port: 9000 conf: # ensure we only scrape port 9000 as opposed to all ports this process may be listening to port: 9000 path: \u0026#34;/prometheus\u0026#34; - exclude: process.name: docker-proxy - include: container.label.io.prometheus.scrape: \u0026#34;true\u0026#34; conf: path: \u0026#34;{container.label.io.prometheus.path}\u0026#34; port: \u0026#34;{container.label.io.prometheus.port}\u0026#34; port has a different meaning depending on where it\u0026rsquo;s placed in the configuration. When placed under the include section, it\u0026rsquo;s a condition for matching the include rule.\nPlacing port under conf indicates that only that port is scraped when the rule is matched as opposed to all the ports that the process could be listening on.\nIn this example, the first rule will be matched for the process listening on port 9000. The java process listening only on port 9000 will be scrapped.\nContainer EnvironmentWith this default configuration enabled, a containerized install of our example exporter shown below would be automatically scraped via the Agent.\n# docker run -d -p 8080:8080 \\ --label io.prometheus.scrape=\u0026#34;true\u0026#34; \\ --label io.prometheus.port=\u0026#34;8080\u0026#34; \\ --label io.prometheus.path=\u0026#34;/prometheus\u0026#34; \\ luca3m/prometheus-java-app Kubernetes EnvironmentIn a Kubernetes-based environment, a Deployment with the Annotations as shown in this example YAML would be scraped by enabling the default configuration.\napiVersion: extensions/v1beta1 kind: Deployment metadata: name: prometheus-java-app spec: replicas: 1 template: metadata: labels: app: prometheus-java-app annotations: prometheus.io/scrape: \u0026#34;true\u0026#34; prometheus.io/path: \u0026#34;/prometheus\u0026#34; prometheus.io/port: \u0026#34;8080\u0026#34; spec: containers: - name: prometheus-java-app image: luca3m/prometheus-java-app imagePullPolicy: Always Non-Containerized EnvironmentThis is an example of a non-containerized environment or a containerized environment that doesn\u0026rsquo;t use Labels or Annotations. The following dragent.yaml would override the default and do per-second scrapes of our sample exporter and also a second exporter on port 5005, each at their respective non-standard endpoints. This can be thought of as a conservative \u0026ldquo;whitelist\u0026rdquo; type of configuration since it restricts scraping to only exporters that are known to exist in the environment and the ports on which they\u0026rsquo;re known to export Prometheus metrics.\nprometheus: enabled: true interval: 1 process_filter: - include: process.cmdline: \u0026#34;*app.jar*\u0026#34; conf: port: 8080 path: \u0026#34;/prometheus\u0026#34; - include: port: 5005 conf: port: 5005 path: \u0026#34;/wacko\u0026#34; port has a different meaning depending on where it\u0026rsquo;s placed in the configuration. When placed under the include section, it\u0026rsquo;s a condition for matching the include rule. Placing port under conf indicates that only that port is scraped when the rule is matched as opposed to all the ports that the process could be listening on.\nIn this example, the first rule will be matched for the process *app.jar*. The java process listening only on port 8080 will be scrapped as opposed to all the ports that *app.jar* could be listening on. The second rule will be matched for port 5005 and the process listening only on 5005 will be scraped.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycollect-prometheus-metrics/example-configuration/"},{"id":604,"title":"(Legacy) Integrate Applications (Default App Checks)","content":" We are sunsetting application checks in favor of Monitoring Integrations.\nMany app checks are enabled by default in the agent and when a supported application is found, the correct app check script will be called and metrics polled automatically.\nHowever, if default connection parameters are changed in your application, you will need to modify the app check connection parameters in the Sysdig Agent configuration file (dragent.yaml) to match your application.\nIn some cases, you may also need to enable the metrics reporting functionality in the application before the agent can poll them.\nThis page details how to make configuration changes in the agent\u0026rsquo;s configuration file, and provides an application integration example. Click the Supported Applications links for application-specific details.\nPython Version for App Checks:\nAs of agent version 9.9.0, the default version of Python used for app checks is Python 3.\nPython 2 can still be used by setting the following option in your dragent.yaml:\npython_binary: \u0026lt;path to python 2.7 binary\u0026gt;\nFor containerized agents, this path will be: /usr/bin/python2.7\nEdit dragent.yaml to Integrate or Modify Application ChecksOut of the box, the Sysdig agent will gather and report on a wide variety of pre-defined metrics. It can also accommodate any number of custom parameters for additional metrics collection.\nThe agent relies on a pair of configuration files to define metrics collection parameters:\ndragent.default.yaml\nThe core configuration file. You can look at it to understand more about the default configurations provided.\nLocation: \"/opt/draios/etc/dragent.default.yaml.\"\nCAUTION. This file should never be edited.\ndragent.yaml\nThe configuration file where parameters can be added, either directly in YAML as name/value pairs, or using environment variables such as 'ADDITIONAL_CONF.\" Location: \"/opt/draios/etc/dragent.yaml.\"\nThe \u0026ldquo;dragent.yaml\u0026rdquo; file can be accessed and edited in several ways, depending on how the agent was installed.\nReview Understanding the Agent Config Files for details.\nThe examples in this section presume you are entering YAML code directly intodragent.yaml, under the app_checks section.\nFind the default settingsTo find the default app-checks for already supported applications, check the dragent.default.yaml file.\n(Location: /opt/draios/etc/dragent.default.yaml.)\nSample formatagent: sysdig: settings: app_checks: - name: APP_NAME check_module: APP_CHECK_SCRIPT pattern: comm: PROCESS_NAME conf: host: IP_ADDR port: PORT Parameter\nParameter 2\nDescription\nSample Value\napp_checks\nThe main section of dragent.default.yaml that contains a list of pre-configured checks.\nn/a\nname\nEvery check should have a uniquename: which will be displayed on Sysdig Monitor as the process name of the integrated application.\ne.g. MongoDB\ncheck_module\nThe name of the Python plugin that polls the data from the designated application.\nAll the app check scripts can be found inside the /opt/draios/lib/python/checks.d directory.\ne.g. elastic\npattern\nThis section is used by the Sysdig agent to match a process with a check. Four kinds of keys can be specified along with any arguments to help distinguish them.\nn/a\ncomm\nMatches process name as seen in /proc/PID/status\nport\nMatches based on the port used (i.e MySQL identified by 'port: 3306')\narg\nMatches any process arguments\nexe\nMatches the process exe as seen in /proc/PID/exe link\nconf\nThis section is specific for each plugin. You can specify any key/values that the plugins support.\nhost\nApplication-specific. A URL or IP address\nport\n{\u0026hellip;} tokens can be used as values, which will be substituted with values from process info.\nChange the default settingsTo override the defaults:\nCopy relevant code blocks from dragent.default.yaml into dragent.yaml . (Or copy the code from the appropriate app check integration page in this documentation section.)\nAny entries copied into dragent.yaml file will override similar entries in dragent.default.yaml.\nNever modify dragent.default.yaml, as it will be overwritten whenever the agent is updated.\nModify the parameters as needed.\nBe sure to use proper YAML. Pay attention to consistent spacing for indents (as shown) and list all check entries under an app_checks: section title.\nSave the changes and restart the agent.\nUse service restart agent or docker restart sysdig-agent.\nMetrics for the relevant application should appear in the Sysdig Monitor interface under the appropriate name.\nExample 1: Change Name and Add PasswordHere is a sample app-check entry for Redis. The app_checks section was copied from the dragent.default.yaml file and modified for a specific instance.\nagent: sysdig: settings: app_checks: - name: redis-6380 check_module: redisdb pattern: comm: redis-server conf: host: 127.0.0.1 port: PORT password: PASSWORD Edits made:\nThe name to be displayed in the interface\nA required password.\nAs the token PORT is used, it will be translated to the actual port where Redis is listening.\nExample 2: Increase Polling IntervalThe default interval for an application check to be run by the agent is set to every second. You can increase the interval per application check by adding the interval: parameter (under the -name section) and the number of seconds to wait before each run of the script.\ninterval: must be put into each app check entry that should run less often; there is no global setting.\nExample: Run the NTP check once per minute:\nagent: sysdig: settings: app_checks: - name: ntp interval: 60 pattern: comm: systemd conf: host: us.pool.ntp.org DisablingDisable a Single Application CheckSometimes the default configuration shipped with the Sysdig agent does not work for you or you may not be interested in checks for a single application. To turn a single check off, add an entry like this to disable it:\nagent: sysdig: settings: app_checks: - name: nginx enabled: false This entry overrides the default configuration of the nginx check, disabling it.\nIf you are using the ADDITIONAL_CONF parameter to modify your container agent\u0026rsquo;s configuration, you would add an entry like this to your Docker run command (or Kubernetes manifest):\n-e ADDITIONAL_CONF=\u0026#34;app_checks:\\n - name: nginx\\n enabled: false\\n\u0026#34; Disable ALL Application ChecksIf you do not need it or otherwise want to disable the application check functionality, you can add the following entry to the agent\u0026rsquo;s user settings configuration file /opt/draios/etc/dragent.yaml:\napp_checks_enabled: false Restart the agent as shown immediately above for either the native Linux agent installation or the container agent installation.\nMetrics LimitMetric limits are defined by your payment plan. If more metrics are needed please contact your sales representative with your use case.\nNote that a metric with the same name but different tag name will count as a unique metric by the agent. Example: a metric 'user.clicks' with the tag 'country=us' and another 'user.clicks' with the 'tag country=it'are considered two metrics which count towards the limit.\nSupported ApplicationsBelow is the supported list of applications the agent will automatically poll.\nSome app-check scripts will need to be configured since no defaults exist, while some applications may need to be configured to output their metrics. Click a highlighted link to see application-specific notes.\nActive MQ Apache Apache CouchDB Apache HBase Apache Kafka Apache Zookeeper Consul Couchbase Elasticsearch etcd fluentd Go HAProxy HDFS HTTP Jenkins JVM Lighttpd Memcached Mesos/Marathon MongoDB MySQL NGINX and NGINX Plus NTP PGBouncer PHP-FPM Postfix PostgreSQL Prometheus RabbitMQ RedisDB Supervisord SNMP TCP You can also\nCreate a Custom App Check from scratch\nCreate Per-Container Custom App Checks\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/"},{"id":605,"title":"(Legacy) Integrations for Sysdig Monitor","content":"Key Benefits Collects the richest data set for cloud-native visibility and security\nPolls data, auto-discover context in order to provide operational and security insights\nExtends the power of Prometheus metrics with additional insights from other metrics types and infrastructure stack\nIntegrate Prometheus alert and events for Kubernetes monitoring needs\nExpose application metrics using Java JMX and MBeans monitoring\nKey IntegrationsInbound Prometheus Metrics\nDescribes how Sysdig Agent enables automatically collecting metrics from Prometheus exporters, how to set up your environment, and scrape Prometheus metrics from local as well as remote hosts.\nJava Management Extention (JMX) Metrics\nDescribes how to configure your Java virtual machines so Sysdig Agent can collect JMX metrics using the JMX protocol.\nStatsD Metrics\nDescribes how the Sysdig agent collects custom StatsD metrics with an embedded StatsD server.\nNode.JS Metrics\nIllustrates how Sysdig is able to monitor node.js applications by linking a library to the node.js codebase.\nIntegrate Applications\nDescribes the monitoring capabilities of Sysdig agent with application check scripts or \u0026lsquo;app checks\u0026rsquo;.\nAWS CloudWatch\nIllustrates how to configure Sysdig to collect various types of CloudWatch metrics.\nAgent Installation\nLearn how to install Sysdig agents on supported platforms.\nOubound Notification Channels\nLearn how to add, edit, or delete a variety of notification channel types, and how to disable or delete notifications when they are not needed, for example, during scheduled downtime.\nS3 Capture Storage\nLearn how to configure Sysdig to use an AWS S3 bucket or custom S3 storage for storing Capture files.\nPlatform Metrics (IBM)For Sysdig instances deployed on IBM Cloud Monitoring with Sysdig, an additional form of metrics collection is offered: Platform metrics. Rather than being collected by the Sysdig agent, when enabled, Platform metrics are reported to Sysdig directly by the IBM Cloud infrastructure.\nPlatform metrics are metrics that are exposed by enabled services across the IBM Cloud platform. These services have made metrics and pre-defined dashboards for their services available by publishing metrics associated with the customer’s space or account. Customers can view these platform metrics alongside the metrics from their applications and other services within IBM Cloud monitoring.\nEnable this feature by logging into the IBM Cloud console and selecting \u0026ldquo;Enable\u0026rdquo; for IBM Platform metrics under the Configure your resource section when creating a new IBM Cloud Monitoring with a Sysdig instance, as described here.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/"},{"id":606,"title":"Alerts","content":"Alert TypesSysdig Monitor offers several types of alerts, adapted to suit different needs and scenarios. To learn about the different types of alerts, see Alert Types.\nAlert ToolsThe following tools help with alert creation:\nAlert Library: Sysdig Monitor provides alert rules that can be used as a template.\nSysdig API: Use Sysdig\u0026rsquo;s Python client to create, list, delete, update and restore alerts. See examples.\nImport Prometheus Rules: Sysdig Monitor allows you to import Prometheus rules or create new rules on the fly and add them to the existing list of alerts.\nAlert Automations: Create automated workflows that trigger when alerts fire, routing notifications to the right channels based on alert type, severity, or group.\nGuidelines for Creating Alerts Steps\nDescription\nDecide What to monitor\nDetermine what type of problem you want to be alerted on. See Alert Types to choose a type of problem.\nDefine how it will be monitored\nSpecify exactly what behavior triggers a violation. For example, Marathon App is down on the Kubernetes Cluster named Production for ten minutes.\nDecide Where to monitor\nNarrow down your environment to receive fine-tuned results. Use Scope to choose an entity that you want to keep a close watch on. Specify additional segments (entities) to give context to the problem. For example, in addition to specifying a Kubernetes cluster, add a namespace and deployment to refine your scope.\nDefine when to notify\nDefine the threshold and time window for assessing the alert condition.\nSetting up a Warning Threshold allows you to notify of incidents earlier. For example, a database using 60% disk may trigger a warning to Slack but the same database using 80% disk may page the on-call team.\nDecide how notifications are sent\nYou can configure an alert rule to send a notification to any of Sysdig's supported notification channel types. To set up a notification channel, see Set Up Notification Channels.\nTo create an alert:\nLog in to Sysdig Monitor.\nSelect Alerts from the left navigation bar.\nSelect New Alert.\nChoose an Alert Type.\nConfigure alert parameters.\nConfigure the notification channels you want to use for alert notification.\nSysdig sometimes deprecates outdated metrics. Alerts that use these metrics will not be modified or disabled, but will no longer be updated. See Deprecated Metrics and Labels.\nCreate Alerts for CloudWatch MetricsCloudWatch metrics queries are displayed as no data in the Alerts Editor. This is because our metric store does not currently store CloudWatch metrics and therefore, the UI displays the missing metrics as no data. However, you can successfully create alerts using these metrics.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/alerts/"},{"id":607,"title":"Integrate with Backstage","content":"By embedding Sysdig security insights directly within Backstage, you gain immediate visibility into security concerns, significantly accelerating the time to detect and respond to issues. This makes it easier to identify and address potential issues in your applications earlier in the devops cycle.\nPrerequisites Backstage is up and running\nSee Getting Started with Backstage.\nSysdig Requirements\nSysdig Secure API Key\nSee Retrieve Sysdig API Key for more information.\nSysdig Secure Endpoint\nSee SaaS Regions and IP Ranges for more information.\nInstallationChange directory to the root of the Backstage application directory and install backstage-plugin-sysdig. Use of the following methods:\nNPM# From your Backstage root directory yarn --cwd packages/app add @sysdig/backstage-plugin-sysdig GitHub# From your Backstage root directory git clone https://github.com/sysdiglabs/backstage-plugin-sysdig plugins/sysdig yarn install ConfigurationSysdig plugin uses the following to perform various operations such as fetching vulnerability scan results from Sysdig backend.\nAPIs: The Sysdig plugin interacts with the Backstage through APIs that leverages annotations in the catalog-info.yaml files associated with the components.\nAnnotation: Annotations are a key concept in the Backstage catalog. They attach metadata to entities defined in the catalog-info.yaml files. The metadata could be links to the documentation, system dependencies, and integration points with tools such as Jenkins for CI/CD, or Sysdig for security insights.\nConfigure Route Reference for SysdigRoutes implements cross-plugin communication within the Backstage application and define routing hierarchy to ensure smooth working of the plugin. For more information, see Backstage Frontend Routes.\nIn order for the Sysdig plugin to work, you must add route reference for Sysdig to the entity routes in packages/app/src/components/catalog/EntityPage.tsx:\nimport { SysdigPage } from \u0026#39;@sysdig/backstage-plugin-sysdig\u0026#39;; ... const serviceEntityPage = ( \u0026lt;EntityLayoutWrapper\u0026gt; ... \u0026lt;EntityLayout.Route path=\u0026#34;/sysdig\u0026#34; title=\u0026#34;Sysdig\u0026#34;\u0026gt; \u0026lt;SysdigPage /\u0026gt; \u0026lt;/EntityLayout.Route\u0026gt; ... \u0026lt;/EntityPageLayout\u0026gt; ) Route references expose a path in Backstage\u0026rsquo;s routing system. They have opaque values that symbolizes route targets within an app, tied to specific paths during runtime. Routes indirectly connect various pages that lack inherent routing links, enabling navigation between them.\nConfigure Sysdig ConnectionIn order for the Backstage application to communicate with Sysdig, you need to define Sysdig connection setting in the Backstage application configuration file.\nOpen your terminal, set the following environment variable: SYSDIG_SECURE_ENDPOINT: Your Sysdig Secure endpoint. SYSDIG_SECURE_TOKEN: The Sysdig Secure API token associated with your Sysdig Secure account. Add the Sysdig connection settings to the app-config.yaml file: proxy: endpoints: \u0026#39;/sysdig\u0026#39;: target: ${SYSDIG_SECURE_ENDPOINT} changeOrigin: true allowedMethods: [\u0026#39;GET\u0026#39;] headers: \u0026#34;Authorization\u0026#34;: \u0026#34;Bearer ${SYSDIG_SECURE_TOKEN}\u0026#34; \u0026#34;Content-Type\u0026#34;: \u0026#34;application/json\u0026#34; \u0026#34;Accept\u0026#34;: \u0026#34;application/json\u0026#34; \u0026#34;X-Sysdig-Product\u0026#34;: \u0026#34;SDS\u0026#34; ... sysdig: endpoint: ${SYSDIG_SECURE_ENDPOINT} Annotate Sysdig ServicesA service is registered in the Backstage Catalog by using a catalog-info.yaml file. This file contains annotations that connect it to its source code repository and other integrations.\nThe following is an example of a catalog-info.yaml for an service called sock-shop-cart.\nRuntime ScanningTo identify vulnerabilities at runtime and in-use vulnerable packages, you can use the following annotation:\nannotations: # VM Runtime sysdigcloud.com/kubernetes-cluster-name: \u0026lt;cluster-name\u0026gt; sysdigcloud.com/kubernetes-namespace-name: \u0026lt;namespace-name\u0026gt; sysdigcloud.com/kubernetes-workload-name: \u0026lt;workload-name\u0026gt; sysdigcloud.com/kubernetes-workload-type: \u0026lt;workload-type\u0026gt; They connect to the Sysdig service and fetch the runtime scan results of the sock-shop-cart application.\nRegistry ScanningTo identify vulnerabilities vulnerable packages in your registry, you can use the annotation similar to the following:\n# VM Registry sysdigcloud.com/registry-vendor: harbor sysdigcloud.com/registry-name: registry-harbor-registry.registry.svc.cluster.local:5443 Example AnnotationSysdig provides curated annotations to help you with insights into the potential risks associated with your current build. In addition to the previous examples, you can fetch pipeline results, compliance reports, and more.\nHere is an example of the catalog-info.yaml for a service named sock-shop-carts:\napiVersion: backstage.io/v1alpha1 kind: Component metadata: name: sock-shop-carts annotations: # VM Runtime sysdigcloud.com/kubernetes-cluster-name: sock-shop-cluster sysdigcloud.com/kubernetes-namespace-name: sock-shop sysdigcloud.com/kubernetes-workload-name: sock-shop-carts sysdigcloud.com/kubernetes-workload-type: deployment # VM Registry sysdigcloud.com/registry-vendor: harbor sysdigcloud.com/registry-name: registry-harbor-registry.registry.svc.cluster.local:5443 # VM Pipeline sysdigcloud.com/image-freetext: ghcr.io/sysdiglabs # Posture sysdigcloud.com/resource-name: sock-shop-carts sysdigcloud.com/resource-type: \u0026#34;Deployment\u0026#34; description: | This is the Sock shop service that keeps track of socks pairs to be purchased. spec: type: service lifecycle: experimental owner: team-c system: sock-shop dependsOn: - component:default/sock-shop-carts-db Not all the annotations are necessary for the plugin to work; the functionality of various reports may vary based on the information provided. For instance, to access Registry scanning results, you must annotate the relevant services with registry data.\nOnce the service is added to the catalog, you can manage the sock-shop-cart from Backstage.\nFor the detailed workflow, see Sysdig Integration with Backstage.\n","url":"https://docs.sysdig.com/en/sysdig-secure/backstage-integration/"},{"id":608,"title":"Change the Agent Log Directory","content":"You can change the default location as follows:\nlog: location: new_directory By default, this location is rooted in the agent install path: /opt/draios/. Therefore, the new log location for the given example would be /opt/draios/new_directory.\nYou cannot write agent logs outside of the agent install path.\n","url":"https://docs.sysdig.com/en/sysdig-secure/change-classic-agent-log-dir/"},{"id":609,"title":"Collect Metrics from Remote File Systems","content":"To enable collecting these metrics, add the following entry to the dragent.yaml file:\nremotefs: true In addition to the remote file systems, the following mount types are also excluded because they cause high load.\nmounts_filter: - exclude: \u0026#34;*|autofs|*\u0026#34; - exclude: \u0026#34;*|proc|*\u0026#34; - exclude: \u0026#34;*|cgroup|*\u0026#34; - exclude: \u0026#34;*|subfs|*\u0026#34; - exclude: \u0026#34;*|debugfs|*\u0026#34; - exclude: \u0026#34;*|devpts|*\u0026#34; - exclude: \u0026#34;*|fusectl|*\u0026#34; - exclude: \u0026#34;*|mqueue|*\u0026#34; - exclude: \u0026#34;*|rpc_pipefs|*\u0026#34; - exclude: \u0026#34;*|sysfs|*\u0026#34; - exclude: \u0026#34;*|devfs|*\u0026#34; - exclude: \u0026#34;*|devtmpfs|*\u0026#34; - exclude: \u0026#34;*|kernfs|*\u0026#34; - exclude: \u0026#34;*|ignore|*\u0026#34; - exclude: \u0026#34;*|rootfs|*\u0026#34; - exclude: \u0026#34;*|none|*\u0026#34; - exclude: \u0026#34;*|tmpfs|*\u0026#34; - exclude: \u0026#34;*|pstore|*\u0026#34; - exclude: \u0026#34;*|hugetlbfs|*\u0026#34; - exclude: \u0026#34;*|*|/etc/resolv.conf\u0026#34; - exclude: \u0026#34;*|*|/etc/hostname\u0026#34; - exclude: \u0026#34;*|*|/etc/hosts\u0026#34; - exclude: \u0026#34;*|*|/var/lib/rkt/pods/*\u0026#34; - exclude: \u0026#34;overlay|*|/opt/stage2/*\u0026#34; - exclude: \u0026#34;/dev/mapper/cl-root*|*|/opt/stage2/*\u0026#34; - exclude: \u0026#34;*|*|/dev/termination-log*\u0026#34; - include: \u0026#34;*|*|/var/lib/docker\u0026#34; - exclude: \u0026#34;*|*|/var/lib/docker/*\u0026#34; - exclude: \u0026#34;*|*|/var/lib/kubelet/pods/*\u0026#34; - exclude: \u0026#34;*|*|/run/secrets\u0026#34; - exclude: \u0026#34;*|*|/run/containerd/*\u0026#34; - include: \u0026#34;*|*|*\u0026#34; To include a mount type:\nOpen the dragent.yaml file.\nRemove the corresponding line from the exclude list in the mount_filter.\nAdd the file mount to the include list under mount_filter .\nThe format is:\n# format of a mount filter is: # ``` # mounts_filter: # - exclude: \u0026#34;device|filesystem|mount_directory\u0026#34; # - include: \u0026#34;pattern1|pattern2|pattern3\u0026#34; For example:\nmounts_filter: - include: \u0026#34;*|autofs|*\u0026#34;mounts_filter: - include: \u0026#34;overlay|*|/opt/stage2/*\u0026#34; - include: \u0026#34;/dev/mapper/cl-root*|*|/opt/stage2/*\u0026#34; Save the configuration changes and restart the agent.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/collect-metrics-from-remote-file-systems/"},{"id":610,"title":"Configure Event Alerts","content":"To create an alert for an event:\nLog in to Sysdig Monitor.\nNavigate to Events from the navigation bar on the left.\nThe Events feed appears.\nSelect an event to open the Event Details panel.\nClick Create Alert from Event.\nThe Alert Editor opens.\nConfigure the alert as necessary.\nAlert configuration will be auto-filled with information from the event.\nFor more information on configuring alerts, see Configure Alerts.\nClick Save to create and enable the alert rule.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/configure-event-alerts/"},{"id":611,"title":"Cost Explorer","content":" GroupingUse the Group by option to select which labels you want to group costs by. Use this option to group costs across any Kubernetes Namespace or Workload label.\nFilteringUse the Add Filter option to filter the cost data by specific label values. For example, only return costs from production clusters. You can save or favorite filters for future use.\nExport ResultsTo export your results from an existing Cost Exploration:\nSelect Export all results from the bottom of the Cost Explorer page.\nChoose a Format: JSON or CSV.\nSelect a File name for the exported file.\nSelect Export.\nCreate New ReportTo create a report from an existing Cost exploration in Cost Explorer:\nSelect Create New Report in the top right corner.\nThe New Report page opens.\nSpecify a unique Name and Description.\nChoose an Export Format of CSV of JSON.\nYou might wish to process exported reports offline, or integrate them with third-party tools.\nSet the scope of the report.\nScope controls which portions of your infrastructure cost data will be included for.\nSelect appropriate grouping.\nYou can Group By cluster, namespace, or workload. Wasted Workload Spend reports require the groups kube_cluster_name, kube_namespace_name, and kube_workload_name by default.\nConfigure the Frequency.\nThe frequency of the report will determine the timeframe of cost data included in the final report.\nConfigure Notifications to send a friendly report to your team. The available channels are Email and Slack.\nYou can generate a Data Preview of the data to export. You can also retrieve the latest report through our API and connect with your preferred tools.\nSelect Save.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/cost-explorer/"},{"id":612,"title":"Detailed Role Permissions","content":"This page provides a detailed outline of the permissions granted to the default roles in Secure and Monitor.\nSysdig Monitor System RolesAdmin Category Item Permission Description INTERNAL_UNCATEGORIZED secure.access OTHER N/A Posture compliance.policies.admin OTHER_MUTATOR N/A INTERNAL_UNCATEGORIZED customer.admin OTHER_MUTATOR N/A INTERNAL_UNCATEGORIZED team-admin.insight OTHER N/A INTERNAL_ADMIN onboarding.admin OTHER_MUTATOR N/A Integrations promcat.integrations.manage MANAGE Change monitoring integration type or status INTERNAL_SERVICE active-secure-compliance-users-admin.read READ N/A INTERNAL_SERVICE active-secure-overview-users-admin.read READ N/A INTERNAL_ADMIN inactive-users-admin.read READ N/A INTERNAL_SERVICE metrics-data-admin.read READ Access metrics data associated with a time series. Reports reports.manage MANAGE Change monitoring reports Posture secure.onboarding.admin OTHER_MUTATOR N/A Posture secure.todo.admin OTHER_MUTATOR N/A INTERNAL_ADMIN system-admin.edit EDIT N/A INTERNAL_ADMIN system-admin.read READ N/A Explore / Metrics agent.cli.agent_internal_diagnostics READ Use Agent Console commands which access internal diagnostics of the agent Explore / Metrics agent.cli.agent_network_calls_to_remote_pods EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore / Metrics agent.cli.agent_status READ Use Agent Console commands which access agent status Explore / Metrics agent.cli.view VIEW Use Agent Console commands Explore / Metrics agent.cli.view_configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Explore / Metrics agent.cli.view_sensitive_configuration VIEW Use Agent Console commands to view the configuration of the agent which does contain sensitive information like passwords. There are currently zero commands that implement this permission Settings sso.config EDIT N/A INTERNAL_ADMIN sso-system.config EDIT N/A Settings customer-admin-users.create CREATE Create new customer admin users ROLE_MANAGEMENT custom-team-roles.create CREATE N/A Settings teams.create CREATE N/A Settings users.create CREATE Invite new users ROLE_MANAGEMENT custom-team-roles.delete DELETE N/A Settings teams.delete DELETE N/A Settings access-keys.edit EDIT N/A Settings sso-active.edit EDIT N/A Policies secure.admission-controller.edit EDIT N/A Scanning (Legacy) agentscanning.config.edit EDIT N/A Settings api-token.edit EDIT Reset users API token in scope of a team Settings aws-settings.edit EDIT N/A Settings beacon-configuration.edit EDIT N/A Posture secure.benchmark.results.edit EDIT N/A Settings certman.edit EDIT N/A Costs cost-advisor.edit EDIT Change Cost Advisor pricing Costs cost-reports.edit EDIT Change cost reports USERS user-deactivation-configuration.edit EDIT Modify user deactivation configuration Data Access Settings datastream.edit EDIT N/A INTERNAL_SERVICE data-api-settings.edit EDIT N/A INTERNAL_SERVICE data-throttling-settings.edit EDIT N/A Settings downtimes.edit EDIT N/A Settings events-forwarder.edit EDIT N/A Integrations file-storage-config.edit EDIT N/A Settings global.notification-channels.edit EDIT N/A Settings global.service-accounts.edit EDIT N/A Settings global-service-account-notification-settings.edit EDIT N/A Data Access Settings groupings.edit EDIT Create and edit custom groupings Settings group-mappings.edit EDIT Modify mapping of users IDP groups to Sysdig teams/roles Settings ip-filters.edit EDIT Modify IP filter configuration Settings login-banner.edit EDIT N/A Settings memberships.edit EDIT Invite other users to the teams Settings memberships-roles.edit EDIT Modify team members roles Network Security netsec.edit EDIT N/A Get Started onboarding.edit EDIT N/A INTERNAL_ADMIN service.platform-alerts-settings.edit EDIT Edit platform alerts settings Policies policy-tuner.edit EDIT N/A Integrations promcat.integrations.edit EDIT Change monitoring integration type or status Integrations providers.edit EDIT N/A Scanning (Legacy) scanning.retention.edit EDIT N/A Scanning (Legacy) secure.images.edit EDIT N/A Settings secure-settings.edit EDIT Modify Sysdig Secure configuration Settings service-account.edit EDIT Modify service accounts in scope of a team Settings service-account-notification-settings.edit EDIT N/A Settings service-account-role.edit EDIT Change service account roles Settings subscription.edit EDIT N/A Settings sysdig-storage.edit EDIT N/A INTERNAL_ADMIN system-falco.edit EDIT N/A Settings teams.edit EDIT N/A Settings team-agent-cli-settings.edit EDIT Toggle access to agent console for a team Settings team-capture-settings.edit EDIT Toggle access to captures for a team Settings team-rapid-response-settings.edit EDIT N/A Integrations third-party-integrations.edit EDIT N/A Ticketing ticketing-customer-settings.edit EDIT Edit ticketing customer settings UI Settings ui-customer-settings.edit EDIT N/A UI Settings ui-inactivity-settings.edit EDIT N/A UI Settings ui-settings.edit EDIT N/A UI Settings ui-user-app-settings.edit EDIT N/A Settings users.edit EDIT N/A Settings user-list.edit EDIT N/A USERS user-password.edit EDIT N/A USERS user-profile.edit EDIT N/A INTERNAL_UNCATEGORIZED dev-task.exec EXEC N/A INTERNAL_UNCATEGORIZED es-query.exec EXEC N/A Captures / Investigate secure.rapid-response.exec EXEC Use rapid response INTERNAL_ADMIN protobuf.export OTHER_MUTATOR N/A INTERNAL_ADMIN impersonate.edit EDIT N/A Data Access Settings ingest.prws OTHER N/A Data Access Settings ingest.prws.controlled OTHER N/A Captures / Investigate secure.rapid-response.kill KILL N/A INTERNAL_SERVICE metrics-descriptors.manage MANAGE Manage metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. INTERNAL_UNCATEGORIZED quartz-jobs.manage MANAGE N/A Settings secure.risk-spotlight-integration-tokens.manage MANAGE Manage risk spotlight integration tokens from the UI Settings access-keys.read READ N/A Scanning (Legacy) agentscanning.config.read READ N/A Settings agent-installation.read READ Get agent access key (required for agent installation) Settings agreement.read READ N/A Settings api-token.read READ Access users API token in scope of a team INTERNAL_UNCATEGORIZED audit-trail-events.read READ N/A Settings aws-settings.read READ Access AWS settings Settings azure-settings.read READ N/A Settings beacon-configuration.read READ N/A Settings certman.read READ N/A Settings cloud.accounts.read READ Access cloud accounts Costs cost-advisor.read READ Access Cost Advisor INTERNAL_SERVICE cost-digest.read READ Read cost digest enabled customers Costs cost-explorer.read READ Access Cost Explorer Costs cost-reports.read READ Access cost reports INTERNAL_SERVICE customer-by-accesskey.read READ N/A Settings customer-plan.read READ N/A Settings customer-teams.read READ Access and list teams data USERS user-deactivation-configuration.read READ Access user deactivation configuration Events custom-events.read READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API ROLE_MANAGEMENT custom-team-roles.read READ N/A Dashboards dashboard-metrics-data.read READ Access metrics data associated with a dashboard. Data Access Settings datastream.read READ Access data stream configuration INTERNAL_SERVICE data-api-settings.read READ N/A INTERNAL_SERVICE data-throttling-settings.read READ N/A Settings downtimes.read READ List alert downtimes for the customer Settings events-forwarder.read READ Access event forwarding configuration Explore / Metrics explore.read READ Metric querying with Explore INTERNAL_UNCATEGORIZED external-links.read READ N/A Integrations file-storage-config.read READ N/A Settings global.service-accounts.read READ N/A Settings global-service-account-notification-settings.read READ N/A Data Access Settings groupings.read READ Access default and custom groupings Settings group-mappings.read READ Access mapping of users IDP groups to Sysdig teams/roles Integrations helmsrenderer.read READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the Terraform snippet. Data Access Settings history-data.read READ N/A INTERNAL_UNCATEGORIZED impersonate.read READ N/A Integrations infrastructure.read READ View discovered infrastructure Integrations integrations.read READ View discovered workload integrations Settings ip-filters.read READ Access IP Filter configuration Advisor kubernetes-api-commands.read READ Kubernetes API feature Advisor live-logs.view VIEW Access Live Logs feature Settings login-banner.read READ N/A Data Access Settings mds.read-metadata READ N/A Settings memberships.read READ Access team members Data Access Settings metadata-defaults.read READ N/A Data Access Settings metrics-data.read READ Access metrics data associated with a time series. Data Access Settings metrics-descriptors.read READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. Get Started onboarding.read READ N/A Advisor overviews.read READ Access Advisor Settings payment-details.read READ N/A ROLE_MANAGEMENT permissions.read READ N/A INTERNAL_ADMIN service.platform-alerts-settings.read READ Read platform alerts settings Integrations promcat.integrations.read READ Access monitoring integration type or status Data Access Settings promql-metadata.read READ Access Prometheus metrics and labels Integrations providers.read READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Scanning (Legacy) scanning.read READ Read scan results Scanning (Legacy) scanning.retention.read READ N/A Get Started secure.onboarding.read READ N/A Settings secure-settings.read READ N/A Settings service-account.read READ Access service accounts in scope of a team Settings service-account-notification-settings.read READ N/A Integrations spotlight.read READ Access spotlight Settings subscription.read READ Access customer subscription details Settings sysdig-storage.read READ View Sysdig storage configuration INTERNAL_UNCATEGORIZED teams.read READ N/A Settings team-agent-cli-settings.read READ See the agent console access settings for a team Settings team-capture-settings.read READ See the capture settings for a team Settings team-rapid-response-settings.read READ N/A INTERNAL_UNCATEGORIZED team-search.read READ N/A Integrations third-party-integrations.read READ N/A Ticketing ticketing-customer-settings.read READ Read ticketing customer settings UI Settings ui-customer-settings.read READ N/A UI Settings ui-inactivity-settings.read READ N/A UI Settings ui-settings.read READ N/A UI Settings ui-user-app-settings.read READ N/A Settings users.read READ Access existing users data Settings user-list.read READ See the list of users for a customer USERS user-profile.read READ N/A Captures / Investigate secure.rapid-response.sessions.read.all READ N/A Settings agreement.sign SIGN N/A INTERNAL_UNCATEGORIZED system-support.edit EDIT N/A INTERNAL_ADMIN agent-availability.toggle TOGGLE N/A INTERNAL_UNCATEGORIZED track.event OTHER_MUTATOR N/A ROLE_MANAGEMENT custom-team-roles.update UPDATE N/A Sage sage.exec EXEC Sysdig Sage chat Integrations promcat.integrations.validate VALIDATE Change monitoring integration status to Pending Metrics Sysdig Monitor Team RolesStandard User Category Item Permission Description Advisor Manage access to Advisor Advisor READ Access Advisor Kubernetes API READ Kubernetes API feature Live Logs VIEW Access Live Logs feature Alerts Manage access to Alerts Alert Events EDIT Acknowledge an event triggered by an alert in the events feed in scope of a team Alert Events READ Access the events generated by triggered alerts in scope of a team Alerts EDIT Modify alerts in scope of a team Alerts READ Access the alerts in scope of a team Captures / Investigate Manage access to Captures / Investigate Captures EDIT Modify captures Captures READ Access captures Captures VIEW View captures in the UI Dashboards\nManage access to dashboards Dashboard Metrics Data READ N/A Dashboards EDIT Modify dashboards in scope of a team Dashboards READ Access dashboards in scope of a team Data Access Settings Manage access to Data Settings Datastream READ Access data stream configuration Groupings EDIT Create and edit custom groupings Groupings READ Access default and custom groupings Metrics Data READ Access metrics data associated with a time series. Metrics Descriptors READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. PromQL Metadata READ Access Prometheus metrics and labels Events Manage access to Events Custom Events EDIT Acknowledge the infrastructure and other events created by Sysdig Agent or Sysdig API Custom Events READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Explore / Metrics Manage access to Explore / Metrics Agent Console VIEW Use Agent Console commands Agent Console - Agent Status READ Use Agent Console commands which access agent status Agent Console - Configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Network Calls EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore READ Use metric querying with Explore Integrations Custom Integrations EDIT Modify custom integrations in spotlight Custom Integrations READ Access custom integrations in spotlight Helm Renderer READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the terraform snippet. Infrastructure READ View discovered infrastructure Integrations READ View discovered workload integrations Monitoring Integrations EDIT Change monitoring integration type or status Monitoring Integrations READ Access monitoring integration type or status Monitoring Integrations VALIDATE Change monitoring integration status to Pending Metrics Providers READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Spotlight READ Access spotlight Settings Agent Installation READ Get agent access key (required for agent installation) Alert Downtimes READ List alert downtimes for the customer API Access Token EDIT Reset users API token in scope of a team API Access Token READ Access users API token in scope of a team API Access Token VIEW View your API token AWS Settings READ Access AWS settings Events Forwarder READ Access event forwarding configuration Global Notification Channels READ Access global notification channels Notification Channels READ Access notification channels in scope of a team Service Accounts READ Access service accounts in scope of a team Subscriptions READ Access customer subscription details Sysdig Storage READ View Sysdig storage configuration View Only Category Item Permission Description Advisor Manage access to Advisor Advisor READ Access Advisor Kubernetes API READ Kubernetes API feature Live Logs VIEW Access Live Logs feature Alerts Manage access to Alerts Alert Events READ Access the events generated by triggered alerts in scope of a team Alerts READ Access the alerts in scope of a team Captures / Investigate Manage access to Captures / Investigate Captures READ Access captures Captures VIEW View captures in the UI Dashboards\nManage access to dashboards Dashboard Metrics Data READ N/A Dashboards READ Access dashboards in scope of a team Data Access Settings\nManage access to Data Settings Datastream READ Access data stream configuration Groupings EDIT Create and edit custom groupings Groupings READ Access default and custom groupings Metrics Data READ Access metrics data associated with a time series. Metrics Descriptors READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. PromQL Metadata READ Access Prometheus metrics and labels Events\nManage access to Events Custom Events READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Explore / Metrics\nManage access to Explore / Metrics Agent Console VIEW Use Agent Console commands Agent Console - Agent Status READ Use Agent Console commands which access agent status Agent Console - Configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Network Calls EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore READ Metric querying with Explore Integrations Custom Integrations READ Access custom integrations in spotlight File Storage Config READ N/A Helm Renderer READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the terraform snippet. Infrastructure READ View discovered infrastructure Integrations READ View discovered workload integrations Monitoring Integrations READ Access monitoring integration type or status Monitoring Integrations VALIDATE Change monitoring integration status to Pending Metrics Providers READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Spotlight READ Access spotlight Settings Agent Installation READ Get agent access key (required for agent installation) Alert Downtimes READ List alert downtimes for the user. API Access Token READ Access users API token in scope of a team API Access Token VIEW View your API token AWS Settings READ Access AWS settings Events Forwarder READ Access event forwarding configuration Global Notification Channels READ Access global notification channels Notification Channels READ Access notification channels in scope of a team Service Accounts READ Access service accounts in scope of a team Subscriptions READ Access customer subscription details Sysdig Storage READ View Sysdig storage configuration Team Manager Category Item Permission description Advisor Advisor READ Access Advisor Kubernetes API READ Kubernetes API feature Live Logs VIEW Access Live Logs feature Alerts Alert Events EDIT Acknowledge an event triggered by an alert in the events feed in scope of a team Alert Events READ Access the events generated by triggered alerts in scope of a team Alerts EDIT Modify alerts in scope of a team Alerts READ Access the alerts in scope of a team Captures / Investigate Captures EDIT Modify captures Captures READ Access captures Captures VIEW View captures in the UI Dashboards Dashboard Metrics Data READ N/A Dashboards EDIT Modify dashboards in scope of a team Dashboards READ Access dashboards in scope of a team Data Access Settings Groupings EDIT Create and edit custom groupings Groupings READ Access default and custom groupings Metrics Data READ Access metrics data associated with a time series. Metrics Descriptors READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. PromQL Metadata READ Access Prometheus metrics and labels Events Custom Events EDIT Acknowledge the infrastructure and other events created by Sysdig Agent or Sysdig API Custom Events READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Explore / Metrics Agent Console VIEW Use Agent Console commands Agent Console - Agent Status READ Use Agent Console commands which access agent status Agent Console - Configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Network Calls EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore EDIT N/A Explore READ Metric querying with Explore Shared Groupings with Team TOGGLE Whether the user can share a custom Explore Grouping to the team. Integrations Custom Integrations EDIT Modify custom integrations in spotlight Custom Integrations READ Access custom integrations in spotlight Helm Renderer READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the terraform snippet. Infrastructure READ View discovered infrastructure Integrations READ View discovered workload integrations Monitoring Integrations EDIT Change monitoring integration type or status Monitoring Integrations READ Access monitoring integration type or status Monitoring Integrations VALIDATE Change monitoring integration status to Pending Metrics Providers READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Spotlight READ Access spotlight Settings Agent Installation READ Get agent access key (required for agent installation) Alert Downtimes READ List alert downtimes for the customer API Access Token EDIT Reset users API token in scope of a team API Access Token READ Access users API token in scope of a team API Access Token VIEW View your API token AWS Settings READ Access AWS settings Events Forwarder READ Access event forwarding configuration Global Notification Channels READ Access global notification channels Notification Channels EDIT Modify notification channels in scope of a team Notification Channels READ Access notification channels in scope of a team Service Accounts EDIT Modify service accounts in scope of a team Service Accounts READ Access service accounts in scope of a team Subscriptions READ Access customer subscription details Sysdig Storage READ View Sysdig storage configuration Teams MANAGE Modify team settings without the ability to modify team membership for users Advanced User Category Item Permission Description Advisor Advisor READ Access Advisor Kubernetes API READ Kubernetes API feature Live Logs VIEW Access Live Logs feature Alerts Alert Events EDIT Acknowledge an event triggered by an alert in the events feed in scope of a team Alert Events READ Access the events generated by triggered alerts in scope of a team Alerts EDIT Modify alerts in scope of a team Alerts READ Access the alerts in scope of a team Captures / Investigate Captures EDIT Modify captures Captures READ Access captures Captures VIEW View captures in the UI Dashboards Dashboard Metrics Data READ N/A Dashboards EDIT Modify dashboards in scope of a team Dashboards READ Access dashboards in scope of a team Data Settings Groupings EDIT Create and edit custom groupings Groupings READ Access default and custom groupings Metrics Data READ Access metrics data associated with a time series. Metrics Descriptors READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. PromQL Metadata READ Access Prometheus metrics and labels Events Custom Events EDIT Acknowledge the infrastructure and other events created by Sysdig Agent or Sysdig API Custom Events READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Explore / Metrics Agent Console VIEW Use Agent Console commands Agent Console - Agent Status READ Use Agent Console commands which access agent status Agent Console - Configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Network Calls EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore EDIT N/A Explore READ Metric querying with Explore Shared Groupings with Team TOGGLE Whether the user can share a custom Explore Grouping to the team. Integrations Custom Integrations EDIT Modify custom integrations in spotlight Custom Integrations READ Access custom integrations in spotlight Helm Renderer READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the Terraform snippet. Infrastructure READ View discovered infrastructure Integrations READ View discovered workload integrations Monitoring Integrations EDIT Change monitoring integration type or status Monitoring Integrations READ Access monitoring integration type or status Monitoring Integrations VALIDATE Change monitoring integration status to Pending Metrics Providers READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Spotlight READ Access spotlight Settings Agent Installation READ Get agent access key (required for agent installation) Alert Downtimes READ List alert downtimes for the customer API Access Token EDIT Reset users API token in scope of a team API Access Token READ Access users API token in scope of a team API Access Token VIEW View your API token AWS Settings READ Access AWS settings Events Forwarder READ Access event forwarding configuration Global Notification Channels READ Access global notification channels Notification Channels EDIT Modify notification channels in scope of a team Notification Channels READ Access notification channels in scope of a team Service Accounts READ Access service accounts in scope of a team Subscriptions READ Access customer subscription details Sysdig Storage READ View Sysdig storage configuration Sysdig Secure System RolesAdmin Category Item Permission Description Captures / Investigate secure.rapid-response.exec EXEC Use rapid response Captures / Investigate secure.rapid-response.kill KILL N/A Captures / Investigate secure.rapid-response.sessions.read.all READ N/A Costs cost-advisor.edit EDIT Change Cost Advisor pricing Costs cost-reports.edit EDIT Change cost reports Costs cost-advisor.read READ Access Cost Advisor Costs cost-explorer.read READ Access Cost Explorer Costs cost-reports.read READ Access cost reports Data Access Settings datastream.edit EDIT N/A Data Access Settings datastream.read READ Access data stream configuration Data Access Settings groupings.edit EDIT Create and edit custom groupings Data Access Settings groupings.read READ Access default and custom groupings Data Access Settings history-data.read READ N/A Data Access Settings ingest.prws OTHER N/A Data Access Settings ingest.prws.controlled OTHER N/A Data Access Settings mds.read-metadata READ N/A Data Access Settings metadata-defaults.read READ N/A Data Access Settings metrics-data.read READ Access metrics data associated with a time series. Data Access Settings metrics-descriptors.read READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. Data Access Settings promql-metadata.read READ Access Prometheus metrics and labels Events custom-events.read READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Explore / Metrics agent.cli.agent_internal_diagnostics READ Use Agent Console commands which access internal diagnostics of the agent Explore / Metrics agent.cli.agent_network_calls_to_remote_pods EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore / Metrics agent.cli.agent_status READ Use Agent Console commands which access agent status Explore / Metrics agent.cli.view VIEW Use Agent Console commands Explore / Metrics agent.cli.view_configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Explore / Metrics agent.cli.view_sensitive_configuration VIEW Use Agent Console commands to view the configuration of the agent which does contain sensitive information like passwords. There are currently zero commands that implement this permission Explore / Metrics explore.read READ Metric querying with Explore Get Started onboarding.read READ N/A Identity identity.read READ Access data related to Cloud Infrastructure Entitlements Management (CIEM) Identity identity.edit EDIT Change compromised status of users flagged as Potentially Compromised INTERNAL_UNCATEGORIZED secure.access OTHER N/A INTERNAL_UNCATEGORIZED customer.admin OTHER_MUTATOR N/A INTERNAL_UNCATEGORIZED team-admin.insight OTHER N/A INTERNAL_ADMIN onboarding.admin OTHER_MUTATOR N/A Integrations promcat.integrations.manage MANAGE Change monitoring integration type or status INTERNAL_SERVICE active-secure-compliance-users-admin.read READ N/A INTERNAL_SERVICE active-secure-overview-users-admin.read READ N/A INTERNAL_ADMIN inactive-users-admin.read READ N/A INTERNAL_SERVICE metrics-data-admin.read READ Access metrics data. Settings sso.config EDIT N/A INTERNAL_ADMIN sso-system.config EDIT N/A Settings customer-admin-users.create CREATE Create new customer admin users Posture compliance.policies.admin OTHER_MUTATOR N/A Reports reports.manage MANAGE Change monitoring reports Posture secure.onboarding.admin OTHER_MUTATOR N/A Posture secure.todo.admin OTHER_MUTATOR N/A INTERNAL_ADMIN system-admin.edit EDIT N/A INTERNAL_ADMIN system-admin.read READ N/A ROLE_MANAGEMENT custom-team-roles.create CREATE N/A Settings teams.create CREATE N/A Settings users.create CREATE Invite new users ROLE_MANAGEMENT custom-team-roles.delete DELETE N/A Settings teams.delete DELETE N/A Settings access-keys.edit EDIT N/A Settings sso-active.edit EDIT N/A Policies secure.admission-controller.edit EDIT N/A Scanning (Legacy) agentscanning.config.edit EDIT N/A Settings api-token.edit EDIT Reset users API token in scope of a team Settings aws-settings.edit EDIT N/A Settings beacon-configuration.edit EDIT N/A Posture secure.benchmark.results.edit EDIT N/A Settings certman.edit EDIT N/A USERS user-deactivation-configuration.edit EDIT Modify user deactivation configuration INTERNAL_SERVICE data-api-settings.edit EDIT N/A INTERNAL_SERVICE data-throttling-settings.edit EDIT N/A Settings downtimes.edit EDIT N/A Settings events-forwarder.edit EDIT N/A Integrations file-storage-config.edit EDIT N/A Settings global.notification-channels.edit EDIT N/A Settings global.service-accounts.edit EDIT N/A Settings global-service-account-notification-settings.edit EDIT N/A Settings group-mappings.edit EDIT Modify mapping of users IDP groups to Sysdig teams/roles Settings ip-filters.edit EDIT Modify IP filter configuration Settings login-banner.edit EDIT N/A Settings memberships.edit EDIT Invite other users to the teams Settings memberships-roles.edit EDIT Modify team members roles Network Security netsec.edit EDIT N/A Get Started onboarding.edit EDIT N/A INTERNAL_ADMIN service.platform-alerts-settings.edit EDIT Edit platform alerts settings Policies policy-tuner.edit EDIT N/A Integrations promcat.integrations.edit EDIT Change monitoring integration type or status Integrations providers.edit EDIT N/A Scanning (Legacy) scanning.retention.edit EDIT N/A Scanning (Legacy) secure.images.edit EDIT N/A Settings secure-settings.edit EDIT Modify Sysdig Secure configuration Settings service-account.edit EDIT Modify service accounts in scope of a team Settings service-account-notification-settings.edit EDIT N/A Settings service-account-role.edit EDIT Change service account roles Settings subscription.edit EDIT N/A Settings sysdig-storage.edit EDIT N/A INTERNAL_ADMIN system-falco.edit EDIT N/A Settings teams.edit EDIT N/A Settings team-agent-cli-settings.edit EDIT Toggle access to agent console for a team Settings team-capture-settings.edit EDIT Toggle access to captures for a team Settings team-rapid-response-settings.edit EDIT N/A Integrations third-party-integrations.edit EDIT N/A Ticketing ticketing-customer-settings.edit EDIT Edit ticketing customer settings UI Settings ui-customer-settings.edit EDIT N/A UI Settings ui-inactivity-settings.edit EDIT N/A UI Settings ui-settings.edit EDIT N/A UI Settings ui-user-app-settings.edit EDIT N/A Settings users.edit EDIT N/A Settings user-list.edit EDIT N/A USERS user-password.edit EDIT N/A USERS user-profile.edit EDIT N/A INTERNAL_UNCATEGORIZED dev-task.exec EXEC N/A INTERNAL_UNCATEGORIZED es-query.exec EXEC N/A INTERNAL_ADMIN protobuf.export OTHER_MUTATOR N/A INTERNAL_ADMIN impersonate.edit EDIT N/A INTERNAL_SERVICE metrics-descriptors.manage MANAGE Manage metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. INTERNAL_UNCATEGORIZED quartz-jobs.manage MANAGE N/A Settings secure.risk-spotlight-integration-tokens.manage MANAGE Manage risk spotlight integration tokens from the UI Settings access-keys.read READ N/A Scanning (Legacy) agentscanning.config.read READ N/A Settings agent-installation.read READ Get agent access key (required for agent installation) Settings agreement.read READ N/A Settings api-token.read READ Access users API token in scope of a team INTERNAL_UNCATEGORIZED audit-trail-events.read READ N/A Settings aws-settings.read READ Access AWS settings Settings azure-settings.read READ N/A Settings beacon-configuration.read READ N/A Settings certman.read READ N/A Settings cloud.accounts.read READ Access cloud accounts INTERNAL_SERVICE cost-digest.read READ Read cost digest enabled customers INTERNAL_SERVICE customer-by-accesskey.read READ N/A Settings customer-plan.read READ N/A Settings customer-teams.read READ Access and list teams data USERS user-deactivation-configuration.read READ Access user deactivation configuration ROLE_MANAGEMENT custom-team-roles.read READ N/A Dashboards dashboard-metrics-data.read READ N/A INTERNAL_SERVICE data-api-settings.read READ N/A INTERNAL_SERVICE data-throttling-settings.read READ N/A Settings downtimes.read READ List alert downtimes for the customer Settings events-forwarder.read READ Access event forwarding configuration INTERNAL_UNCATEGORIZED external-links.read READ N/A Integrations file-storage-config.read READ N/A Settings global.service-accounts.read READ N/A Settings global-service-account-notification-settings.read READ N/A Settings group-mappings.read READ Access mapping of users IDP groups to Sysdig teams/roles Integrations helmsrenderer.read READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the terraform snippet. INTERNAL_UNCATEGORIZED impersonate.read READ N/A Integrations infrastructure.read READ View discovered infrastructure Integrations integrations.read READ View discovered workload integrations Settings ip-filters.read READ Access IP Filter configuration Advisor kubernetes-api-commands.read READ Kubernetes API feature Advisor live-logs.view VIEW Access Live Logs feature Settings login-banner.read READ N/A Settings memberships.read READ Access team members Advisor overviews.read READ Access Advisor Settings payment-details.read READ N/A ROLE_MANAGEMENT permissions.read READ N/A INTERNAL_ADMIN service.platform-alerts-settings.read READ Read platform alerts settings Integrations promcat.integrations.read READ Access monitoring integration type or status Integrations providers.read READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Scanning (Legacy) scanning.read READ Read scan results Scanning (Legacy) scanning.retention.read READ N/A Get Started secure.onboarding.read READ N/A Settings secure-settings.read READ N/A Settings service-account.read READ Access service accounts in scope of a team Settings service-account-notification-settings.read READ N/A Integrations spotlight.read READ Access spotlight Settings subscription.read READ Access customer subscription details Settings sysdig-storage.read READ View Sysdig storage configuration INTERNAL_UNCATEGORIZED teams.read READ N/A Settings team-agent-cli-settings.read READ See the agent console access settings for a team Settings team-capture-settings.read READ See the capture settings for a team Settings team-rapid-response-settings.read READ N/A INTERNAL_UNCATEGORIZED team-search.read READ N/A Integrations third-party-integrations.read READ N/A Ticketing ticketing-customer-settings.read READ Read ticketing customer settings UI Settings ui-customer-settings.read READ N/A UI Settings ui-inactivity-settings.read READ N/A UI Settings ui-settings.read READ N/A UI Settings ui-user-app-settings.read READ N/A Settings users.read READ Access existing users data Settings user-list.read READ See the list of users for a customer USERS user-profile.read READ N/A Settings agreement.sign SIGN N/A INTERNAL_UNCATEGORIZED system-support.edit EDIT N/A INTERNAL_ADMIN agent-availability.toggle TOGGLE N/A INTERNAL_UNCATEGORIZED track.event OTHER_MUTATOR N/A ROLE_MANAGEMENT custom-team-roles.update UPDATE N/A Sage sage.exec EXEC Sysdig Sage chat Integrations promcat.integrations.validate VALIDATE Change monitoring integration status to Pending Metrics Sysdig Secure Team RolesStandard User Category Item Permission Description Advisor Kubernetes API READ Kubernetes API feature Live Logs VIEW Access Live Logs feature Alerts Alerts READ Access the alerts in scope of a team Captures / Investigate Captures READ Access captures Captures VIEW View captures in the UI Containment Response Actions VIEW View executions of Containment Response Actions Data Gathering Response Actions VIEW View executions of Response Actions that collect Data Data Access Settings Groupings EDIT Create and edit custom groupings Groupings READ Access default and custom groupings Metrics Data READ Access metrics data Metrics Descriptors READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. Events Custom Events READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Policy Events READ Access policy events Explore / Metrics Agent Console VIEW Use Agent Console commands Agent Console - Agent Status READ Use Agent Console commands which access agent status Agent Console - Configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Network Calls EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore READ Metric querying with Explore Shared Groupings with Team TOGGLE Whether the user can share a custom Explore Grouping to the team. Identity CIEM features READ Access information related to Cloud Infrastructure Entitlement Management. Identity CIEM features EDIT Modify compromised status of users flagged as Potentially Compromised. Integrations Helm Renderer READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the terraform snippet. Infrastructure READ View discovered infrastructure Monitoring Integrations READ Access monitoring integration type or status Providers READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Policies Posture Policies READ View Posture policies Posture Controls READ View Posture Controls Zones READ View Zones that are assigned to current team Posture Compliance READ Access Compliance results Risk Acceptance READ Access to Posture Risk Acceptance management page Legacy Benchmark Tasks EDIT Create and modify scheduled Legacy benchmark and compliance tasks Legacy Benchmark Tasks READ Access scheduled Legacy benchmark tasks Legacy Benchmarks READ Access Legacy benchmark results Legacy Compliance READ Access Legacy Compliance tasks and reports Risk Risks READ Read Risks Scanning (legacy) Image Import EDIT Import scanning images Scanning READ Read scan results Scanning Alerts READ Access scanning alerts Scanning Image Results CREATE Create scanning events Scanning Image Results READ List scanning images Scanning Runtime EDIT Query runtime containers API Scanning Scheduled Reports READ View and download existing reports Scanning Trusted Images READ Access the trusted images list Scanning Untrusted Images READ Access the untrusted images list Scanning Vulnerability Exceptions READ Access vulnerability exceptions Settings Agent Installation READ Get agent access key (required for agent installation) API Access Token EDIT Reset users API token in scope of a team API Access Token READ Access users API token in scope of a team API Access Token VIEW View your API token AWS Settings READ Access AWS settings Cloud Accounts READ Access cloud accounts Global Notification Channels READ Access global notification channels IAC READ Access IAC results Notification Channels READ Access notification channels in scope of a team Service Accounts READ Access service accounts in scope of a team Subscriptions READ Access customer subscription details Sysdig Secure Settings EDIT Modify Sysdig Secure configuration Sysdig Storage READ View Sysdig storage configuration Vulnerability Management Scan Results READ View scan results on the Pipeline, Runtime, and Registry UI. Retrieve SBOM results from the SBOM API. Reporting READ View and download scan reports Policy READ View policy details Risk Acceptance READ View Exceptions Registry Credentials READ View registry credentials Service Manager Category Item Permission Description Advisor Kubernetes API READ Kubernetes API feature Live Logs VIEW Access Live Logs feature Alerts Alerts READ Access the alerts in scope of a team Captures / Investigate Captures READ Access captures Captures VIEW View captures in the UI Containment Response Actions VIEW View executions of Containment Response Actions Data Gathering Response Actions VIEW View executions of Response Actions that collect Data Data Access Settings Groupings EDIT Create and edit custom groupings Groupings READ Access default and custom groupings Metrics Data READ Access metrics data associated with a time series. Metrics Descriptors READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. Events Custom Events READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Policy Events READ Access policy events Explore / Metrics Agent Console VIEW Use Agent Console commands Agent Console - Agent Status READ Use Agent Console commands which access agent status Agent Console - Configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Network Calls EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore READ Metric querying with Explore Shared Groupings with Team TOGGLE Whether the user can share a custom Explore Grouping to the team. Identity CIEM features READ Access information related to Cloud Infrastructure Entitlement Management. Identity CIEM features EDIT Modify compromised status of users flagged as Potentially Compromised. Integrations Helm Renderer READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the Terraform snippet. Infrastructure READ View discovered infrastructure Monitoring Integrations READ Access monitoring integration type or status Providers READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Policies Posture Policies READ View Posture policies Posture Controls READ View Posture Controls Zones READ View Zones that are assigned to current team Posture Compliance READ Access Compliance results Risk Acceptance READ Access to Posture Risk Acceptance management page Legacy Benchmark Tasks EDIT Create and modify scheduled Legacy benchmark and compliance tasks Legacy Benchmark Tasks READ Access scheduled Legacy benchmark tasks Legacy Benchmarks READ Access Legacy benchmark results Legacy Compliance READ Access Legacy Compliance tasks and reports Risk Risks READ Read Risks Scanning (Legacy) Image Import EDIT Import scanning images Scanning EXEC Execute backend scanning Scanning READ Read scan results Scanning WRITE Modify scanning alerts and registry credentials Scanning Alerts EDIT Modify scanning alerts Scanning Alerts READ Access scanning alerts Scanning Scanning Image Results CREATE Create scanning events Scanning Image Results READ List scanning images Scanning Policy Assignments READ Access policy mappings Scanning Runtime EDIT Query runtime containers API Scanning Scheduled Reports READ View and download existing reports Scanning Trusted Images READ Access the trusted images list Scanning Untrusted Images READ Access the untrusted images list Scanning Vulnerability Exceptions READ Access vulnerability exceptions Settings Agent Installation READ Get agent access key (required for agent installation) API Access Token EDIT Reset users API token in scope of a team API Access Token READ Access users API token in scope of a team API Access Token VIEW View your API token AWS Settings READ Access AWS settings Cloud Accounts READ Access cloud accounts Global Notification Channels READ Access global notification channels IAC READ Access IAC results Notification Channels EDIT Modify notification channels in scope of a team Notification Channels READ Access notification channels in scope of a team Service Accounts READ Access service accounts in scope of a team Subscriptions READ Access customer subscription details Sysdig Secure Settings EDIT Modify Sysdig Secure configuration Sysdig Storage READ View Sysdig storage configuration Team Membership EDIT Invite other users to the teams Team Membership READ Access team members Team Membership Roles EDIT Modify team members roles Teams MANAGE Modify team settings without the ability to modify team membership for users Teams READ N/A Users READ Access existing users data Vulnerability Management Scan Results READ View scan results on the Pipeline, Runtime, and Registry UI. Retrieve SBOM results from the SBOM API. Reporting READ View and download scan reports Reporting WRITE Create, modify, and delete reports Policy READ View policy details Policy WRITE Create, edit, and delete policies Risk Acceptance READ View Exceptions CLI Execution EXEC Ability to run CLI Scanner Scan Now EXEC Ability to instantly scan using Scan Now Registry Credentials READ View registry credentials Registry Credentials WRITE Add registry credentials Registry Scanner EXEC Ability to run Registry Scanner View Only Category Item Permission Description Advisor Kubernetes API READ Kubernetes API feature Live Logs VIEW Access Live Logs feature Alerts Alerts READ Access the alerts in scope of a team Captures / Investigate Activity Audit Commands READ Access activity audit commands Captures READ Access captures Captures VIEW View captures in the UI Containment Response Actions VIEW View executions of Containment Response Actions Data Gathering Response Actions VIEW View executions of Response Actions that collect Data Data Access Settings Groupings EDIT Create and edit custom groupings Groupings READ Access default and custom groupings Metrics Data READ Access metrics data associated with a time series. Metrics Descriptors READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. Events Custom Events READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Policy Events READ Access policy events Explore / Metrics Agent Console VIEW Use Agent Console commands Agent Console - Agent Status READ Use Agent Console commands which access agent status Agent Console - Configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Network Calls EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore READ Metric querying with Explore Identity CIEM features READ Access information related to Cloud Infrastructure Entitlement Management. Integrations Helm Renderer READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the Terraform snippet. Infrastructure READ View discovered infrastructure Monitoring Integrations READ Access monitoring integration type or status Providers READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Network Security Network Security READ Access Kubernetes Network Security policy advisor Policies Posture Policies READ View Posture policies Posture Controls READ View Posture Controls Zones READ View Zones that are assigned to current team Image profiling READ View existing image profiles Policies READ Access policies Policy Advisor READ Read PSP advisor simulations Posture Compliance READ Access Compliance results Risk Acceptance READ Access to Posture Risk Acceptance management page Legacy Benchmark Tasks EDIT Create and modify scheduled Legacy benchmark and compliance tasks Legacy Benchmark Tasks READ Access scheduled Legacy benchmark tasks Legacy Benchmarks READ Access Legacy benchmark results Legacy Compliance READ Access Legacy Compliance tasks and reports Scanning (Legacy) Scanning READ Read scan results Scanning Alerts READ Access scanning alerts Scanning Image Results READ List scanning images Scanning Policies READ Access security policies Scanning Policy Assignments READ Access policy mappings Scanning Registry Credentials READ List container registries Scanning Runtime EDIT Query runtime containers API Scanning Scheduled Reports READ View and download existing reports Scanning Trusted Images READ Access the trusted images list Scanning Untrusted Images READ Access the untrusted images list Scanning Vulnerability Exceptions READ Access vulnerability exceptions Settings Agent Installation READ Get agent access key (required for agent installation) API Access Token EDIT Reset users API token in scope of a team API Access Token READ Access users API token in scope of a team API Access Token VIEW View your API token AWS Settings READ Access AWS settings Cloud Accounts READ Access cloud accounts Global Notification Channels READ Access global notification channels IAC READ Access IAC results Notification Channels READ Access notification channels in scope of a team Service Accounts READ Access service accounts in scope of a team Subscriptions READ Access customer subscription details Sysdig Secure Settings EDIT Modify Sysdig Secure configuration Settings Sysdig Storage READ View Sysdig storage configuration Vulnerability Management Scan Results READ View scan results on the Pipeline, Runtime, and Registry UI. Retrieve SBOM results from the SBOM API. Reporting READ View and download scan reports Policy READ View policy details Risk Acceptance READ View Exceptions Registry Credentials READ View registry credentials Team Manager Category Item Permission Description Advisor Kubernetes API READ Kubernetes API feature Live Logs VIEW Access Live Logs feature Alerts Alerts EDIT Modify alerts in scope of a team Alerts READ Access the alerts in scope of a team Captures / Investigate Activity Audit Commands READ Access activity audit commands Captures EDIT Modify captures Captures READ Access captures Captures VIEW View captures in the UI Containment Response Actions VIEW View executions of Containment Response Actions Containment Response Actions EXEC Execute Containment Response Actions Data Gathering Response Actions VIEW View executions of Response Actions that collect Data Data Gathering Response Actions EXEC Execute Response Actions that collect Data Containment Response Actions EXEC Execute Containment Response Actions Rapid Response EXEC Use rapid response Data Access Settings Datastream READ Access data stream configuration Groupings EDIT Create and edit custom groupings Groupings READ Access default and custom groupings Metrics Data READ Access metrics data associated with a time series. Metrics Descriptors READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. Events Custom Events READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Policy Events READ Access policy events Explore / Metrics Agent Console VIEW Use Agent Console commands Agent Console - Agent Status READ Use Agent Console commands which access agent status Agent Console - Configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Network Calls EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore EDIT N/A Explore READ Metric querying with Explore Shared Groupings with Team TOGGLE Whether the user can share a custom Explore Grouping to the team. Identity CIEM features READ Access information related to Cloud Infrastructure Entitlement Management. Identity CIEM features EDIT Modify compromised status of users flagged as Potentially Compromised. Integrations Helm Renderer READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the Terraform snippet. Infrastructure READ View discovered infrastructure Monitoring Integrations READ Access monitoring integration type or status Providers READ Related to cloud account setups (both Metric Stream and Cost Private Pricing). Network Security Network Security READ Access Kubernetes Network Security policy advisor Policies Zones EDIT View and Edit All Zones Posture Policies EDIT View and Edit Posture policies Posture Controls EDIT View and Edit Posture Controls Image profiling EXEC Execute image profiling Image profiling READ View existing image profiles Image profiling WRITE Write image profiles Policies EDIT Modify policies Policies READ Access policies Policy Advisor EXEC Execute PSP advisor simulation Policy Advisor READ Read PSP advisor simulations Policy Advisor WRITE Create PSP advisor simulation Posture Compliance READ Access Compliance results Risk Acceptance EDIT Access and modify Posture Risk Acceptance Open PR EDIT Setup Pull Requests from posture remediation panel Legacy Benchmark Tasks EDIT Access, Create and modify scheduled Legacy benchmark and compliance tasks Legacy Benchmarks READ Access Legacy benchmark results Legacy Compliance READ Access Legacy Compliance tasks and reports Risk Risks READ Read Risks Scanning Image Import EDIT Import scanning images Scanning EXEC Execute backend scanning Scanning READ Read scan results Scanning WRITE Modify scanning alerts and registry credentials Scanning Alerts EDIT Modify scanning alerts Scanning Alerts READ Access scanning alerts Scanning Image Results CREATE Create scanning events Scanning Image Results READ List scanning images Scanning Policies EDIT Modify security policies Scanning Policies READ Access security policies Scanning Policy Assignments EDIT Create and modify policy mappings Scanning Policy Assignments READ Access policy mappings Scanning Registry Credentials EDIT Create and modify container registries configuration Scanning Registry Credentials READ List container registries Scanning Runtime EDIT Query runtime containers API Scanning Scheduled Reports EDIT Create and modify reports Scanning Scheduled Reports READ View and download existing reports Scanning Trusted Images EDIT Modify the trusted images list Scanning Trusted Images READ Access the trusted images list Scanning Untrusted Images EDIT Modify the untrusted images list Scanning Untrusted Images READ Access the untrusted images list Scanning Vulnerability Exceptions EDIT Edit vulnerability exceptions Scanning Vulnerability Exceptions READ Access vulnerability exceptions Settings Agent Installation READ Get agent access key (required for agent installation) API Access Token EDIT Reset users API token in scope of a team API Access Token READ Access users API token in scope of a team API Access Token VIEW View your API token AWS Settings READ Access AWS settings Cloud Accounts READ Access cloud accounts Global Notification Channels READ Access global notification channels IAC READ Access IAC results Notification Channels EDIT Modify notification channels in scope of a team Notification Channels READ Access notification channels in scope of a team Service Accounts EDIT Modify service accounts in scope of a team Service Accounts READ Access service accounts in scope of a team Subscriptions READ Access customer subscription details Sysdig Secure Settings EDIT Modify Sysdig Secure configuration Sysdig Storage READ View Sysdig storage configuration Teams MANAGE Modify team settings without the ability to modify team membership for users Vulnerability Management Scan Results READ View scan results on the Pipeline, Runtime, and Registry UI. Retrieve SBOM results from the SBOM API. Reporting READ View and download scan reports Reporting WRITE Create, modify, and delete reports Policy READ View policy details Policy WRITE Create, edit, and delete policies Risk Acceptance READ View Exceptions Risk Acceptance WRITE Create, update, and delete Exceptions CLI Execution EXEC Ability to run CLI Scanner Scan Now EXEC Ability to instantly scan using Scan Now Registry Credentials READ View registry credentials Registry Credentials WRITE Add registry credentials Registry Scanner EXEC Ability to run Registry Scanner Advanced User Category Item Permission Description Advisor Kubernetes API READ Kubernetes API feature Live Logs VIEW Access Live Logs feature Alerts Alerts EDIT Modify alerts in scope of a team Alerts READ Access the alerts in scope of a team Captures / Investigate Activity Audit Commands READ Access activity audit commands Captures EDIT Modify captures Captures READ Access captures Captures VIEW View captures in the UI Containment Response Actions VIEW View executions of Containment Response Actions Containment Response Actions EXEC Execute Containment Response Actions Data Gathering Response Actions VIEW View executions of Response Actions that collect Data Data Gathering Response Actions EXEC Execute Response Actions that collect Data Rapid Response EXEC Use rapid response Data Access Settings Datastream READ Access data stream configuration Groupings EDIT Create and edit custom groupings Groupings READ Access default and custom groupings Metrics Data READ Access metrics data associated with a time series. Metrics Descriptors READ Access metrics descriptors, which are unique combinations of metrics and labels that create a time series. For example, sysdig_container_cpu_used_percent{host_hostname=foo,region=bar}. Events Custom Events READ Access the infrastructure and other events created by Sysdig Agent or Sysdig API Policy Events READ Access policy events Explore / Metrics Agent Console VIEW Use Agent Console commands Agent Console - Agent Status READ Use Agent Console commands which access agent status Agent Console - Configuration VIEW Use Agent Console commands to view the configuration of the agent which does not contain sensitive information like passwords Agent Console - Network Calls EXEC Use Agent Console commands which make network calls to remote pods and endpoints Explore EDIT N/A Explore READ Metric querying with Explore Shared Groupings with Team TOGGLE Whether the user can share a custom Explore Grouping to the team. Identity CIEM features READ Access information related to Cloud Infrastructure Entitlement Management. Identity CIEM features EDIT Modify compromised status of users flagged as Potentially Compromised. Integrations Helm Renderer READ Access Helm-renderer component. During cloud account setup in Secure, the wizard calls the Helm Renderer to generate the Terraform snippet. Infrastructure READ View discovered infrastructure Monitoring Integrations READ Access monitoring integration type or status Providers READ Cloud account setups (both Metric Stream and Cost Private Pricing). Network Security Network Security READ Access Kubernetes Network Security policy advisor Policies Zones EDIT View and Edit All Zones Posture Policies EDIT View and Edit Posture policies Posture Controls EDIT View and Edit Posture Controls Image profiling EXEC Execute image profiling Image profiling READ View existing image profiles Image profiling WRITE Write image profiles Policies EDIT Modify policies Policies READ Access policies Policy Advisor EXEC Execute PSP advisor simulation Policy Advisor READ Read PSP advisor simulations Policy Advisor WRITE Create PSP advisor simulation Compliance READ Access Compliance results Risk Acceptance EDIT Access and modify Posture Risk Acceptance Posture Open PR EDIT Setup Pull Requests from posture remediation panel Legacy Benchmark Tasks EDIT Access, Create and modify scheduled Legacy benchmark and compliance tasks Legacy Benchmarks READ Access Legacy benchmark results Legacy Compliance READ Access Legacy Compliance tasks and reports Risk Risks READ Read Risks Scanning (Legacy) Image Import EDIT Import scanning images Scanning EXEC Execute backend scanning Scanning READ Read scan results Scanning WRITE Modify scanning alerts and registry credentials Scanning Alerts EDIT Modify scanning alerts Scanning Alerts READ Access scanning alerts Scanning Image Results CREATE Create scanning events Scanning Image Results READ List scanning images Scanning Policies EDIT Modify security policies Scanning Policies READ Access security policies Scanning Policy Assignments EDIT Create and modify policy mappings Scanning Policy Assignments READ Access policy mappings Scanning Registry Credentials EDIT Create and modify container registries configuration Scanning Registry Credentials READ List container registries Scanning Runtime EDIT Query runtime containers API Scanning Scheduled Reports EDIT Create and modify reports Scanning Scheduled Reports READ View and download existing reports Scanning Trusted Images EDIT Modify the trusted images list Scanning Trusted Images READ Access the trusted images list Scanning Untrusted Images EDIT Modify the untrusted images list Scanning Untrusted Images READ Access the untrusted images list Scanning Vulnerability Exceptions EDIT Edit vulnerability exceptions Scanning Vulnerability Exceptions READ Access vulnerability exceptions Settings Agent Installation READ Get agent access key (required for agent installation) API Access Token EDIT Reset users API token in scope of a team API Access Token READ Access users API token in scope of a team API Access Token VIEW View your API token AWS Settings READ Access AWS settings Cloud Accounts READ Access cloud accounts Global Notification Channels READ Access global notification channels IAC READ Access IAC results Notification Channels EDIT Modify notification channels in scope of a team Notification Channels READ Access notification channels in scope of a team Service Accounts READ Access service accounts in scope of a team Subscriptions READ Access customer subscription details Sysdig Secure Settings EDIT Modify Sysdig Secure configuration Sysdig Storage READ View Sysdig storage configuration Vulnerability Management Scan Results READ View scan results on the Pipeline, Runtime, and Registry UI. Retrieve SBOM results from the SBOM API. Reporting READ View and download scan reports Reporting WRITE Create, modify, and delete reports Policy READ View policy details Policy WRITE Create, edit, and delete policies Risk Acceptance READ View Exceptions Risk Acceptance WRITE Create, update, and delete Exceptions CLI Execution EXEC Ability to run CLI Scanner Scan Now EXEC Ability to instantly scan using Scan Now Registry Credentials READ View registry credentials Registry Credentials WRITE Add registry credentials Registry Scanner EXEC Ability to run Registry Scanner ","url":"https://docs.sysdig.com/en/administration/role_permissions/"},{"id":613,"title":"Downtime Alert","content":" In this example, the downtime of the containers are monitored. When one of more containers in the given scope go down in the 1-minute time window, notifications will be sent with necessary information on both the containers and the agents.\nThe lines shown in the preview chart represent the values for the segments selected to monitor. The popup is a color-coded legend to show which segment (or combination of segments if there is more than one) the lines represent. You can also deselect some segment lines to prevent them from showing in the chart. Note that there is a limit of 10 lines that Sysdig Monitor ever shows in the preview chart. For downtime alerts, segments are actually what you select for the Alerts if any of option.\nAbout Up MetricsTo monitor the downtime of the entities, the following up metrics are used: sysdig_host_up, sysdig_container_up, and sysdig_program_up. They indicate whether the agent is able to communicate with the collector. The value 1 represents the entity is up and agent is sending this information to the collector. The value 0 represents the entity is down, implies no communication from agent to the collector about the entity.\nWhen an alert is configured based on Up metric, two data API queries are performed during the alert check. One query will retrieve the current values and the other will retrieve the values from the previous alert check interval. For any entity that was present in previous interval and is not present in current interval, the metric is marked as 0.\nAn aggregated value of the up metric is displayed on the dashboard on the Alert Editor, and therefore, you might see a value between 0 and 1.\nDefine a Downtime AlertGuidelines Set a unique name and description: Set a meaningful name and description that help recipients easily identify the alert.\nSeverity: Set a severity level for your alert. The Priority—High, Medium, Low, and Info—are reflected in the Alert list, where you can sort by the severity of the Alert. You can use severity as a criterion when creating alerts, for example: if there are more than 10 high severity events, notify.\nSpecify multiple segments: Selecting a single segment might not always supply enough information to troubleshoot. Enrich the selected entity with related information by adding additional related segments. Enter hierarchical entities so you have the bottom-down picture of what went wrong and where. For example, specifying a Kubernetes cluster alone does not provide the context necessary to troubleshoot. In order to narrow down the issue, add further contextual information, such as Kubernetes Namespace, Kubernetes Deployment, and so on.\nConfigure ConditionScopeFilter the environment on which this alert will apply. For example, an alert will fire when a container associated with the agent 197288 goes down. The alert will be triggered for each container name and agent ID.\nUse in or contain operators to match multiple different possible values to apply scope.\nThe contain and not contain operators help you retrieve values if you know part of the values. For example, us retrieves values that contain strings that start with \u0026ldquo;us\u0026rdquo;, such as \u0026ldquo;us-east-1b\u0026rdquo;, \u0026ldquo;us-west-2b\u0026rdquo;, and so on.\nThe in and not in operators help you filter multiple values.\nYou can also create alerts directly from Explore and Dashboards for automatically populating this scope.\nMetricSelect an uptime metric associated with the entity whose downtime you want to monitor for. You can select one of the following entities: host, container, program.\nEntitySpecify additional segments by using the Alert if any of option.\nThe specified entities are segmented on and notified with the default notification template as well as on the Preview. In this example, data is segmented on container name and agent ID. When a container is affected, the notification will not only include the affected container details but also the associated agent IDs.\nTriggerDefine the threshold and time window for assessing the alert condition. Supported time scales are minute, hour, or day.\nIf the monitored program is not available or not responding for the last 1 minute, recipients will be notified.\nYou can set any value for % and a value greater than 1 for the time window. For example, If you choose 50% instead of 100%, a notification will be triggered when the entity is down for 5 minutes in the selected time window of 10 minutes.\nUse Cases Your e-commerce website is down during the peak hours of Black Friday, Christmas, or New Year season.\nProduction servers of your data center experience a critical outage\nMySQL database is unreachable\nFile upload does not work on your marketing website.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/downtime-alert/"},{"id":614,"title":"Drift Detection Policy","content":" Drift Detection applies to containers only and does not work on hosts.\nThis policy was formerly known as \u0026ldquo;Container Drift\u0026rdquo; and \u0026ldquo;Drift Control\u0026rdquo;.\nOverviewDrift Detection helps you:\nPrevent attacks by blocking container drift in production: Drift Detection automatically flags and denies deviations from the original container, blocking malicious executables before damage is done. Enforce immutability best practice: Drift Detection ensures that container software is not modified during its lifetime, driving good practices, consistency from source to run, and preventing actions that could be part of an attack. Enable easy and effective security: Teams are often overwhelmed by cloud-native complexity and blind to container drift, especially at scale. Now, security teams and IT can enable Drift Detection for the entire container environment and immediately start protecting it. The Drift Detection policy has the following unique attributes:\nIt includes only one pre-configured rule, which cannot be edited, and no other rules can be added to Drift Detection policies. It is a custom policy, not a managed policy. Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nPrerequisites Agent version 12.16+ for Drift Detection Policy Agent version 13.0 and above for captures and container stop/pause/kill actions On agent version v13.1 and above: ignore_container_action: Ignores kill, stop, pause container operation ignore_action: Ignores all the actions including kill, prevent malware, prevent drift and container actions. Kernel version 5.0 and above (see Prevent action) Agent version 13.1.0+ for the rule Detect Volume Drift. In v13.1.1, it is enabled by default.\nIn v13.1.0, add the following configuration to the dragent.yaml file:\ndrift_deny_execution_from_volumes: true Agent version 13.2.0+ to Block Prohibited Binary Execution. Shield version 14.0+ to enable Detect Volume Binaries without enabling Detect Binary Drift first. For more details, see Configure Drift Detection in Agent Configuration.\nCreate a Drift Detection PolicyTo configure a Drift Detection Policy in the Sysdig Secure UI:\nSelect Policies \u0026gt; Runtime Policies to display the Runtime Policies page.\nClick + Add Policy in the top right of the page.\nSelect the Drift Detection policy type.\nNext, you can configure the policy.\nConfigure a Drift Detection PolicyName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled: Toggle to enable or disable the policy. When the policy is enabled, it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, or Info.\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy. Scope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nAuto-tuning is not used with Drift policies. If you have too many false positives, use Scope to tune them. Link to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example, https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, a View Runbook option will be displayed in any corresponding Event. Policy RulesIn the Policy Rules section, you can enable or disable the following rules:\nBinary Drift: Toggle this on to dynamically detect the execution of drifted binaries.\nA drifted binary is any binary that was not part of the original image of the container. It is typically downloaded or compiled into a running container. If a detected binary attempts to run when this toggle is enabled, Sysdig will create an event. To prevent a detected drifted binary from running, use Prevent. Volume Drift: Toggle this on to treat all binaries from mounted volumes as drifted. This will generate events and prevent the binaries from being executed.\nIndependent volume drift requires shield version 14.0+. On earlier versions, you must enable Binary Drift detection first in order to enable Volume Drift detection. Block Prohibited Binary Execution: Toggle this on to block execution of detected drifted binaries. When toggled on, the Prohibited Binaries section appears in the Rules Configuration section. You must define at least one prohibited binary to enable this toggle.\nRequires agent version 13.2.0+. Rules ConfigurationDefine binaries with their full path, separated by commas, using string or regex (if enabled). Defining with string is very specific, while regex is pattern matching and more flexible.\nUse Regex: Toggle this on to use regex (regular expression) when you configure exceptions.\nRegex allows you to create patterns for matching file names or process paths. For example, .*\\.log$ matches any file ending with “.log”. You can use regex to identify drifted files or processes that should be allowed or blocked by matching their names or paths the the regex pattern defined. To learn more about regex syntax, see Regular Expression Syntax. Agent version 13.2.0 or above is required for this feature. File-based ExceptionsExceptions: Specify which drifted files can execute within a container. If a file matches any condition in the Exceptions list, it will be allowed. Even if a file is prohibited, has been modified or added post-deployment, it can still be executed if it is listed as an exception. This is useful for scenarios where certain files need to be updated or added and executed as part of legitimate operations, such as configuration scripts or updates.\nProhibited Binaries: Specify which drifted files are not allowed to execute. Prohibited binaries will be prevented from executing unless they are listed as an Exception.\nProcess-based ExceptionsExceptions: Specify which processes can execute drifted files. If a process matches any condition in the Exceptions list, it will be allowed. Specified processes can interact with modified or newly added files without triggering security alerts, facilitating legitimate operations that require such interactions. Use Exceptions sparingly to ensure that only necessary drifted processes are allowed.\nProhibited Binaries: Specify binaries of processes whose execution is blocked even if they are built with the image. Prohibited binaries will be prevented from executing unless they are listed as an Exception.\nIf a file or process matches an entry in both the Exceptions and Prohibited Binaries lists, the Exception will take precedence. This means the file or process will be allowed to execute even if it is also listed as prohibited. Once something is explicitly added to the Exceptions list, it overrides any detection or prohibition rules.\nThe Prohibited Binaries option was formerly called always deny.\nActionsDetermine what should be done if a Policy is violated.\nPreventPrevent Execution: Toggle this to stop detected executables from running.\nDepending on the kernel version, the agent will either:\nKill the process once it is detected as drifted (kernel version \u0026lt;5.0)\nPrevent drifted processes from running (kernel version 5.0+)\nThe latter method is preferable because it stops the drifted process from running for any period. The agent determines which mode to use at agent startup. One of the above-mentioned types of prevention is always available with 12.15+ agents. For example, Bottlerocket prevents by using the kill action.\nContainersContainer policy actions coverage map:\nEnvironment Container Policy Action Supported? Kubernetes - Linux ✅ Kubernetes - Windows ❌ Hosts - Linux Containers ✅ Hosts - Linux Packages ✅ Hosts - Windows ❌ Hosts - ECS on EC2 ❌ Serverless - Azure Container Apps ❌ Serverless - Cloud Run Service ❌ Serverless - ECS on Fargate ❌ Select what should happen to affected containers if the policy rules are breached. The appropriate action depends on your use case:\nNo container action: Do not change the container behavior; send a notification according to Notification Channel settings. Kill: Kill one or more running containers immediately. Stop: Allow a graceful shutdown (10-seconds) before killing the container. Pause: Suspend all processes in the specified containers. For details, see Available Response Actions.\nYou can configure the agent to prevent kill/pause/stop actions, regardless of the policy.\nSee Ignore Container Actions at the Agent Level.\nCaptureToggle Capture ON if you want to create a capture in case of an event, and define the number of seconds before and after the event that should be in the snapshot.\nSee also: Captures.\nNotifySelect a notification channel from the drop-down to send notifications of events to appropriate personnel.\nThis will ensure you know there\u0026rsquo;s a serious security incident. You can then save the notification as a record of what happened for later analysis.\nSee also: Set Up Notification Channels.\nCheck EventsWhen the policy is enabled, you can check for any detected events:\nLog in to Sysdig Secure and select Events.\nType Drift in the filter bar to find where the Drift policy was triggered and drill down to examine the event details.\nKnown LimitationsThere are certain conditions that the Drift Detection policy will not catch.\nScript Execution using Binaries from the Base ImageDrift detections tracks the execution of binaries that were not part of the original image. It does not cover cases where a script is executed leveraging binaries from the original image. For example, if an attacker downloads a Python script and leverages an existing Python binary from the base image, drift detection will not detect it at runtime.\nPersistent VolumesAs the Drift Detection policy uses overlays for detection, execution from persistent volumes is not considered \u0026ldquo;drifted.\u0026rdquo; Therefore, if a malicious binary is downloaded to a persistent volume and executed, it will not be caught.\nSuppose you are using persistent volumes exclusively for data. In that case, you can set the following option in the agent config file to treat the execution of all binaries from persistent volumes as drifted:\ndrift_deny_execution_from_volumes: true Use with caution. When this option is used with the Prevent action, the execution of any binary from any mounted volumes will be stopped.\nContainer Limits For kernel versions below v5.13, Drift Detection can monitor up to 128 containers per node.\nFor kernel versions v5.13 or above, you can modify the container limit as described in Configure Container Limits.\n","url":"https://docs.sysdig.com/en/sysdig-secure/drift_policy/"},{"id":615,"title":"DynamoDB","content":"In DynamoDB, provisioned throughput requirements are specified in terms of capacity units: Read Capacity unit and Write Capacity unit. A unit of read capacity represents one strongly consistent read per second for items up to 4 KB in size. One write capacity unit represents one write per second for items up to 1 KB in size. Larger items will require more capacity. You can calculate the number of units of read and write capacity by estimating the number of reads or writes required per second and multiplying by the size of the items rounded up to the nearest KB.\nFor more information, see the Amazon DynamoDB documentation.\naws.dynamodb.ConditionalCheckFailedRequestsThe number of failed attempts to perform conditional writes.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.ConsumedReadCapacityUnitsThe amount of read capacity units consumed over the defined time period. Amazon CloudWatch aggregates the metrics at one-minute intervals. Use the Sum aggregation to calculate the consumed throughput. For example, get the Sum value over a span of one minute, and divide it by the number of seconds in a minute (60) to calculate the average ConsumedReadCapacityUnits per second.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.ConsumedWriteCapacityUnitsThe amount of write capacity units consumed over the specified time interval. Amazon CloudWatch aggregates the metrics at one-minute intervals. Use the Sum aggregation to calculate the consumed throughput. For example, get the Sum value over a span of one minute, and divide it by the number of seconds in a minute (60) to calculate the average ConsumedWriteCapacityUnits per second.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.ProvisionedReadCapacityUnitsThe number of read capacity units provisioned for a table or a global secondary index.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.ProvisionedWriteCapacityUnitsThe number of write capacity units provisioned for a table or global secondary table.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.ReadThrottleEventsThe number of DynamoDB requests that exceed the amount of read capacity units provisioned.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.ReturnedBytes.GetRecordsThe number of bytes returned by GetRecords operation during the specified time period.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.ReturnedItemCountThe number of items returned by query or scan operations during the specified time period.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.ReturnedRecordsCount.GetRecordsThe number of stream records returned by the GetRecords operations during the specific period.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.SuccessfulRequestLatencyThe number of successful requests to DynamoDB or Amazon DynamoDB Streams during the specified time period. The time period is in milliseconds.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.SystemErrorsThe number of requests made to DynamoDB or Amazon DynamoDB Streams that resulted in an HTTP 500 status code during the specified time period. HTTP 500 usually indicates an internal service error.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.ThrottledRequestsThe number of requests to DynamoDB that exceed the provisioned throughput limits on a resource, such as a table or an index. ThrottledRequests is incremented by one if any event within a request exceeds a provisioned throughput limit.\nIf any individual request for read or write events within the batch is throttled, ReadThrottleEvents metrics or WriteThrottleEvents metrics is incremented respectively.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.UserErrorsThe number of requests to DynamoDB or Amazon DynamoDB Streams that returned an HTTP 400 status code during the specified time period. HTTP 400 usually indicates a client-side error.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.dynamodb.WriteThrottleEventsThe number of requests to DynamoDB that exceed the provisioned write capacity units for a table or a global secondary index.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/sysdig-monitor/aws-metrics-legacy/dynamodb/"},{"id":616,"title":"ECS on EC2","content":"PrerequisitesReview the Installation Requirements.\nInstallationTo install the Sysdig agent on ECS:\nCreate an ECS task definition for the Sysdig agent.\nUse the values listed in Prerequisites to customize the example task definition given below. Save the file with the name sysdig-agent-ecs.json.\nRegister the task definition in your AWS account:\naws ecs register-task-definition \\ --cli-input-json file://sysdig-agent-ecs.json Using the ECS task definition you have created, create a service in the cluster that you want to monitor with Sysdig.\nYou can use the example task definition given below.\nRun the agent as an ECS Service.\naws ecs create-service \\ --cluster $CLUSTER_NAME \\ --service-name sysdig-agent-svc \\ --launch-type EC2 \\ --task-definition sysdig-agent-ecs \\ --scheduling-strategy DAEMON Use this service to run the Sysdig agent on each nodes of your ECS cluster.\nIf you are using ECS Anywhere, change the launch type to EXTERNAL when the service is created.\nWith the successful agent installation, Sysdig will begin auto-discovering your containers and other resources of your ECS environment.\nExample Task DefinitionSave this JSON snippet as sysdig-agent-ecs.json. You can customize and use it as the task definition for installing the agent.\nNote that both memory and CPU have been set to 1024, but depending on the size of your cluster, you might want to tune the values.\n{ \u0026#34;family\u0026#34;: \u0026#34;sysdig-agent-ecs\u0026#34;, \u0026#34;containerDefinitions\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;sysdig-agent\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/agent-slim\u0026#34;, \u0026#34;cpu\u0026#34;: 1024, \u0026#34;memory\u0026#34;: 1024, \u0026#34;privileged\u0026#34;: true, \u0026#34;environment\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;ACCESS_KEY\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$ACCESS_KEY\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;COLLECTOR\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$COLLECTOR\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;TAGS\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;$TAG1,TAG2\u0026#34; }, { \u0026#34;name\u0026#34;: \u0026#34;ADDITIONAL_CONF\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;\u0026lt;config_yaml\u0026gt;\u0026#34; // Example: \u0026#34;value\u0026#34;: \u0026#34;malware_control\\n enabled: true\u0026#34; // Must be a valid YAML, converted into a single-line string with \\n for a newline } ], \u0026#34;mountPoints\u0026#34;: [ { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/boot\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;boot\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/dev\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;dev\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/lib/modules\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;modules\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/proc\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;proc\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/var/run/docker.sock\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;sock\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/usr\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;usr\u0026#34; } ], \u0026#34;dependsOn\u0026#34;: [ { \u0026#34;containerName\u0026#34;: \u0026#34;sysdig-agent-kmodule\u0026#34;, \u0026#34;condition\u0026#34;: \u0026#34;SUCCESS\u0026#34; } ] }, { \u0026#34;name\u0026#34;: \u0026#34;sysdig-agent-kmodule\u0026#34;, \u0026#34;image\u0026#34;: \u0026#34;quay.io/sysdig/agent-kmodule\u0026#34;, \u0026#34;memory\u0026#34;: 512, \u0026#34;privileged\u0026#34;: true, \u0026#34;essential\u0026#34;: false, \u0026#34;mountPoints\u0026#34;: [ { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/boot\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;boot\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/dev\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;dev\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/lib/modules\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;modules\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/proc\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;proc\u0026#34; }, { \u0026#34;containerPath\u0026#34;: \u0026#34;/host/var/run/docker.sock\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;sock\u0026#34; }, { \u0026#34;readOnly\u0026#34;: true, \u0026#34;containerPath\u0026#34;: \u0026#34;/host/usr\u0026#34;, \u0026#34;sourceVolume\u0026#34;: \u0026#34;usr\u0026#34; } ] } ], \u0026#34;pidMode\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;networkMode\u0026#34;: \u0026#34;host\u0026#34;, \u0026#34;volumes\u0026#34;: [ { \u0026#34;name\u0026#34;: \u0026#34;sock\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/var/run/docker.sock\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;dev\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/dev/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;proc\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/proc/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;boot\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/boot/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;modules\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/lib/modules/\u0026#34; } }, { \u0026#34;name\u0026#34;: \u0026#34;usr\u0026#34;, \u0026#34;host\u0026#34;: { \u0026#34;sourcePath\u0026#34;: \u0026#34;/usr/\u0026#34; } } ], \u0026#34;requiresCompatibilities\u0026#34;: [ \u0026#34;EC2\u0026#34; ] } ","url":"https://docs.sysdig.com/en/sysdig-monitor/ecs-on-ec2/"},{"id":617,"title":"etcd","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\netcd Versionsetcd v2The app check functionality described on this page supports etcd metrics from APIs that are specific to v2 of etcd.\nThese APIs are present in etcd v3 as well, but export metrics only for the v2 datastores. For example, after upgrading from etcd v2 to v3, if the v2 datastores are not migrated to v3, the v2 APIs will continue exporting metrics for these datastores. If the v2 datastores are migrated to v3, the v2 APIs will no longer export metrics for these datastores.\netcd v3etcd v3 uses a native Prometheus exporter. The exporter only exports metrics for v3 datastores. For example, after upgrading from etcd v2 to v3, if v2 datastores are not migrated to v3, the Prometheus endpoint will not export metrics for these datastores. The Prometheus endpoint will only export metrics for datastores migrated to v3 or datastores created after the upgrade to v3.\nIf your etcd version is v3 or higher, use the information on this page to enable an integration: Integrate Prometheus Metrics.\netcd Setupetcd will automatically expose all metrics. You do not need to add anything to the etcd instance.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nThe default agent configuration for etcd will look for the application on localhost, port 2379. No customization is required.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with etcd and collect all metrics.\napp_checks: - name: etcd pattern: comm: etcd conf: url: \u0026#34;http://localhost:2379\u0026#34; etcd (before version 2) does not listen on localhost, so the Sysdig agent will not connect to it automatically. In such case, you may need edit the dragent.yaml file with the hostname and port. See Example 1.\nAlternatively, you can add the option -bind-addr 0.0.0.0:4001 to the etcd command line to allow the agent to connect.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1You can use {hostname} and {port} as a tokens in the conf: section. This is the recommended setting for Kubernetes customers.\napp_checks: - name: etcd pattern: comm: etcd conf: url: \u0026#34;http://{hostname}:{port}\u0026#34; Alternatively you can specify the real hostname and port.\napp_checks: - name: etcd pattern: comm: etcd conf: url: \u0026#34;http://my_hostname:4000\u0026#34; #etcd service listening on port 4000 Example 2: SSL/TLS CertificateIf encryption is used, add the appropriate SSL/TLS entries. Provide correct path of SSL/TLS key and certificates used in etcd configuration in fields ssl_keyfile, ssl_certfile, ssl_ca_certs.\napp_checks: - name: etcd pattern: comm: etcd conf: url: \u0026#34;https://localhost:PORT\u0026#34; ssl_keyfile: /etc/etcd/peer.key # Path to key file ssl_certfile: /etc/etcd/peer.crt # Path to SSL certificate ssl_ca_certs: /etc/etcd/ca.crt # Path to CA certificate ssl_cert_validation: True Metrics AvailableSee etcd Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/etcd/"},{"id":618,"title":"etcd Metrics","content":"See Application Integrations for more information.\netcd.leader.counts.failRate of failed Raft RPC requests.\netcd.leader.counts.successRate of successful Raft RPC requests.\netcd.leader.latency.avgAverage latency to each peer in the cluster.\netcd.leader.latency.currentCurrent latency to each peer in the cluster.\netcd.leader.latency.maxMaximum latency to each peer in the cluster.\netcd.leader.latency.minMinimum latency to each peer in the cluster.\netcd.leader.latency.stddevStandard deviation latency to each peer in the cluster.\netcd.self.recv.appendrequest.countRate of append requests this node has processed.\netcd.self.recv.bandwidthrateRate of bytes received.\netcd.self.recv.pkgrateRate of packets received.\netcd.self.send.appendrequest.countRate of append requests this node has sent.\netcd.self.send.bandwidthrateRate of bytes sent.\netcd.self.send.pkgrateRate of packets sent.\netcd.store.compareanddelete.failRate of compare and delete requests failure.\netcd.store.compareanddelete.successRate of compare and delete requests success.\netcd.store.compareandswap.failRate of compare and swap requests failure.\netcd.store.compareandswap.successRate of compare and swap requests success.\netcd.store.create.failRate of failed create requests.\netcd.store.create.successRate of successful create requests.\netcd.store.delete.failRate of failed delete requests.\netcd.store.delete.successRate of successful delete requests.\netcd.store.expire.countRate of expired keys.\netcd.store.gets.failRate of failed get requests.\netcd.store.gets.successRate of successful get requests.\netcd.store.sets.failRate of failed set requests.\netcd.store.sets.successRate of successful set requests.\netcd.store.update.failRate of failed update requests.\netcd.store.update.successRate of successful update requests.\netcd.store.watchersRate of watchers.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/etcd-metrics/"},{"id":619,"title":"Falco Rules Changelog","content":"Subscribe to the RSS feed to stay updated with the latest Falco rules.\nCommit Date\nRule Notes\nVersion of the Falco Rules Installer (On-Prem)\nMay 27, 2026\nRule Changes\nReduced FPs for Launch Excessively Capable Container rule.\nReduced FPs for Suspicious device created in container rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Exfiltration of GCP IMDS Credentials Using LOTL Binary rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Reverse Shell Spawned From Binary Through Pipes rule.\nReduced FPs for AF_ALG Page Cache Poisoning Leading to Privilege Escalation rule.\n0.251.4\nMay 26, 2026\nRule Changes\nReduced FPs for Launch Excessively Capable Container rule.\nReduced FPs for Cgroup Filesystem Mounted in Container rule.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for Mailbox Data Modification rule.\nReduced FPs for Modification of pam.d detected rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for System Capabilities Configuration Updated rule.\nReduced FPs for Python .pth Persistence File Written by Non-Package-Manager rule.\nReduced FPs for Remove Bulk Data from Disk rule.\nReduced FPs for Launch Sensitive Mount Container rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Suspicious Cron Modification rule.\nReduced FPs for Suspicious System Service Modification rule.\nReduced FPs for JVM Attach Attempt using Unix Socket rule.\nReduced FPs for Read sensitive file untrusted rule.\n0.251.3\nMay 21, 2026\nWhat's Changed\nRule Changes\nReduced FPs for Run shell untrusted rule.\nReduced FPs for Launch Sensitive Mount Container rule.\nReduced FPs for Database Dump Command Detected rule.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for Mkdir binary dirs rule.\nReduced FPs for Clear Log Activities rule.\nReduced FPs for Modify binary dirs rule.\nReduced FPs for Suspicious System Service Modification rule.\nReduced FPs for Disable or Modify Linux Audit System rule.\nReduced FPs for Suspicious device created in container rule.\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Cgroup Filesystem Mounted in Container rule.\nReduced FPs for Possible Backdoor using BPF rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Database Exfiltrated to Cloud Storage rule.\n0.251.2\nMay 19, 2026\nWhat's Changed\n## Rule Changes\nReduced FPs for eBPF Program Loaded into Kernel rule.\nReduced FPs for Fileless Malware Detected (memfd) rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Modify Shell Configuration File rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\nReduced FPs for Execution from Temporary Filesystem (tmpfs) rule.\nReduced FPs for nsenter Container Escape rule.\nReduced FPs for Modification of Container Image Cache rule.\nReduced FPs for DNS Lookup for Uncommon TLD Domain Detected rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for Set Setuid or Setgid bit rule.\nReduced FPs for Write below etc rule.\nReduced FPs for Write below root rule.\nReduced FPs for Container Launched In Host Network Namespace rule.\nReduced FPs for Read Shell Configuration File rule.\nReduced FPs for AF_ALG Page Cache Poisoning Targeting Sensitive File rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Read sensitive file untrusted rule.\n0.251.1\nMay 18, 2026\nWhat's Changed\nNew Rules\nAdded rule Sensitive File Descriptor Theft via pidfd_getfd.\n0.251.0\nMay 14, 2026\n## What's Changed\n## New Rules\nAdded rule Dirty Frag ESP-in-TCP Page Cache Poisoning LPE.\nRule Changes\nReduced FPs for Run shell untrusted rule.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for AF_ALG Page Cache Poisoning Leading to Privilege Escalation rule.\nDefault Policy Changes\nPolicy Sysdig Runtime Behavioral Analytics updated\n0.250.0\nMay 13, 2026\n## What's Changed\n## Rule Changes\nReduced FPs for Read ssh information rule.\nReduced FPs for Write below etc rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so rule.\n0.249.1\nMay 12, 2026\n## What's Changed\n## New Rules\nAdded rule Azure Policy Assignment Deleted.\nRule Changes\nImproved Output for Github Workflow Injection rule.\nImproved Condition for Suspicious Domain Contacted During Package Install rule.\nImproved Condition for Dirty Frag RxRPC Page Cache Poisoning LPE rule.\nImproved Condition for Dirty Frag xfrm-ESP Page Cache Poisoning LPE rule.\nImproved Condition for Ransomware Filenames Detected rule.\nReduced FPs for Run shell untrusted rule.\nReduced FPs for Set Setuid or Setgid bit rule.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for System Geolocation Discovery rule.\nReduced FPs for Write below rpm database rule.\nReduced FPs for Peripheral Device Discovery Activity Detected rule.\nDeprecated Azure Server Vulnerability Assessment on SQL Server Has Been Removed rule.\nDefault Policy Changes\nPolicy Sysdig Azure Notable Events updated\n0.249.0\nMay 11, 2026\n## What's Changed\n## Rule Changes\nReduced FPs for Dirty Frag xfrm-ESP Page Cache Poisoning LPE rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Suspicious RC Script Modification rule.\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for AF_ALG Page Cache Poisoning Targeting Sensitive File rule.\nReduced FPs for Share EBS Snapshot With Foreign Account.\nReduced FPs for Share AMI With Foreign Account.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for Python .pth Persistence File Written by Non-Package-Manager rule.\nReduced FPs for Drop and execute new binary in container rule.\nReduced FPs for Write below etc rule.\nReduced FPs for AF_ALG Page Cache Poisoning Leading to Privilege Escalation rule.\n0.248.1\nMay 08, 2026\nAdded rule Dirty Frag RxRPC Page Cache Poisoning LPE. Added rule Dirty Frag xfrm-ESP Page Cache Poisoning LPE.\n0.248.0\nMay 07, 2026\nWhat's Changed\nRule Changes\nReduced FPs for AF_ALG Page Cache Poisoning Targeting Sensitive File rule.\nReduced FPs for Network Tool Executed During NPM Install rule.\nReduced FPs for System procs network activity rule.\nReduced FPs for Write below etc rule.\nReduced FPs for Suspicious Domain Contacted rule.\nReduced FPs for eBPF Program Loaded into Kernel rule.\nReduced FPs for DNS Lookup for Tunneling Service Domain Detected rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for DNS Fast Flux Activity Detected rule.\n0.247.1\nMay 05, 2026\nNew Rules\nAdded rule AF_ALG Page Cache Poisoning Targeting Sensitive File.\nAdded rule Database Exfiltrated to Cloud Storage.\nRule Changes\nImprove Output for AWS ECS Create Task Definition.\nReduced FPs for AF_ALG Page Cache Poisoning Leading to Privilege Escalation rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Suspicious device created in container rule.\nReduced FPs for Debugfs Launched on Host rule.\nReduced FPs for Directory traversal monitored file read rule.\nReduced FPs for Detection bypass by symlinked files rule.\nReduced FPs for Contact EC2 Instance Metadata Service From Container rule.\nReduced FPs for DB program spawned process rule.\nReduced FPs for Possible Backdoor using BPF rule.\nDefault Policy Changes\nPolicy Sysdig Runtime Behavioral Analytics updated.\n0.247.0\nApril 30, 2026\nNew Rules\nAdded Unexpected Process Using Kernel AEAD Crypto Socket rule.\nRule Changes\nReduced FPs for AF_ALG Page Cache Poisoning Leading to Privilege Escalation rule.\n0.246.1\nAdded rule AF_ALG Page Cache Poisoning Leading to Privilege Escalation.\nRule Changes\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\nDefault Policy Changes\nPolicy Sysdig Runtime Behavioral Analytics updated.\n0.246.0\nApril 28, 2026\nRule Changes\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Fileless Malware Detected (memfd) rule.\nReduced FPs for Reverse Shell Spawned From Interpreted or Compiled Program Through Pipes rule.\nReduced FPs for Clear Log Activities rule.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for Execution from Temporary Filesystem (tmpfs) rule.\nReduced FPs for Suspicious System Service Modification rule.\nReduced FPs for Mkdir binary dirs rule.\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Unauthorized Process Accessed Claude Code Configuration Directory rule.\nReduced FPs for Unauthorized Process Accessed Codex CLI Configuration Directory rule.\n0.245.0\nApril 27, 2026\nRule Changes\nImproved condition for DNS Lookup for Offensive Security Tool Domain Detected rule.\nReduced FPs for Unauthorized Process Accessed Codex CLI Configuration Directory rule.\nReduced FPs for Modify binary dirs rule.\nReduced FPs for Redirect STDOUT/STDIN to Network Connection in Container rule.\nReduced FPs for Python .pth Persistence File Written by Non-Package-Manager rule.\n0.244.6\nApril 21, 2026\nRule Changes\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for Suspicious System Service Modification rule.\n0.244.5\nApril 20, 2026\nRule Changes\nReduced FPs for Reverse Shell via Unnamed Pipes rule.\nReduced FPs for Exfiltration of Secrets in Runner Using LOTL Binary rule.\nReduced FPs for Possible Exploitation of Kernel Netfilter Vulnerability (CVE-2024-1086) rule.\nReduced FPs for Possible Exploitation of Kernel Netfilter Vulnerability (CVE-2024-53141) rule.\nReduced FPs for Possible Sudo Chroot Exploitation Attempt rule.\nReduced FPs for SSH Shell Spawned from Known Brute-Forcer IP rule.\nReduced FPs for Exfiltration of K8s Service Account Token rule.\nReduced FPs for Exfiltration of GCP IMDS Credentials Using LOTL Binary rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT To Sibling Processes Using Named Pipe rule.\nReduced FPs for Dynamic Linker Hijacking Using LD_AUDIT rule.\nReduced FPs for Launch Root User Container rule.\nReduced FPs for Container Launched In Host Network Namespace rule.\nReduced FPs for Launch Privileged Container rule.\nReduced FPs for Write below root rule.\nReduced FPs for Archive or Compression Activity Detected rule.\nReduced FPs for Read ssh information rule.\nReduced FPs for Read Shell Configuration File rule.\nReduced FPs for System Geolocation Discovery rule.\nReduced FPs for Contact K8S API Server From Container rule.\nReduced FPs for Write below rpm database rule.\nReduced FPs for Drop and Execute New Binary in Container rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\nReduced FPs for Suspicious System Service Modification rule.\nReduced FPs for Mkdir binary dirs rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for Cgroup Filesystem Mounted in Container rule.\nReduced FPs for Modification of Udev Rules Detected rule.\nReduced FPs for Modify ld.so.preload rule.\nReduced FPs for Possible Remote Command Execution Detected rule.\nReduced FPs for Kernel startup modules changed rule.\nReduced FPs for Detection bypass by symlinked files rule.\nReduced FPs for CSharp Compiler Library Loaded at Runtime rule.\nReduced FPs for Mailbox Data Modification rule.\nReduced FPs for Clear Log Activities rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for DNS Lookup for Reconnaissance Service Detected rule.\nReduced FPs for Run shell untrusted rule.\nReduced FPs for Packet socket created in container rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Suspicious device created in container rule.\nReduced FPs for eBPF Program Loaded into Kernel rule.\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Launch Excessively Capable Container rule.\nReduced FPs for Launch Sensitive Mount Container rule.\nReduced FPs for Database Dump Command Detected rule.\nReduced FPs for Block Device Mounted in Container rule.\n0.244.4\nApril 17, 2026\nRule Changes\nReduced FPs for PTRACE Anti-Debug Attack and Container Escape with PTRACE rules.\nReduced FPs for Find and Execute SUID Binary rule.\nReduced FPs for Data Exfiltration using DNS rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for New Kernel Module Created and Loaded rule.\nReduced FPs for Container Escape using Kernel Module rule.\nReduced FPs for Staged Meterpreter Reverse Shell rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Read K8s Service Account Token from Terminal rule.\nReduced FPs for Reverse Shell Spawned From Interpreted or Compiled Program Through Pipes rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT To Socket With Pipes rule.\nReduced FPs for DB program spawned process rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for Contact GCP Instance Metadata Service from Host rule.\nReduced FPs for Possible Backdoor using BPF rule.\nReduced FPs for Disable or Modify Linux Audit System rule.\n0.244.3\nApril 16, 2026\nRule Changes\nReduced FPs for Sensitive File Access Attempt Detected During Package Install rule.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\nReduced FPs for Execution of binary using ld-linux rule.\nReduced FPs for Delete or rename shell history rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Modification of pam.d detected rule.\nReduced FPs for Read Environment Variable from /proc files in Container rule.\nReduced FPs for System procs network activity rule.\nReduced FPs for Block Device Mounted in Container rule.\n0.244.2\nApril 15, 2026\nRule Changes\nReduced FPs for Dynamic Linker Hijacking Using LD_AUDIT rule.\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for DNS Fast Flux Activity Detected rule.\nReduced FPs for Block Device Mounted in Container rule.\n0.244.1\nApril 14, 2026\nNew Rules\nAdded Codex CLI Yolo Mode Spawned Suspicious Process rule.\nAdded Claude Code Yolo Mode Spawned Suspicious Process rule.\nAdded Gemini CLI Yolo Mode Spawned Suspicious Process rule.\nAdded Symlink Targeting Proc in Container rule.\nAdded Block Device Mounted in Container rule.\nRule Changes\nReduced FPs for nsenter Container Escape rule.\nReduced FPs for Unauthorized Process Accessed Codex CLI Configuration Directory rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Suspicious System Service Modification rule.\nReduced FPs for Suspicious device created in container rule.\nReduced FPs for Execution of binary using ld-linux rule.\nReduced FPs for Disable or Modify Linux Audit System rule.\nReduced FPs for Suspicious Capabilities Granted to File rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nImproved output for AWS Falco Cloud.\nDefault Policy Changes\nPolicy Sysdig AI Runtime Notable Events updated.\nPolicy Sysdig Runtime Notable Events updated.\n0.244.0\nApril 13, 2026\nRule Changes\nReduced FPs for CSharp Compiler Library Loaded at Runtime rule.\nReduced FPs for DNS Fast Flux Activity Detected rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Contact GCP Instance Metadata Service from Host rule.\nReduced FPs for Packet Socket Created on Host rule.\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for Unauthorized Process Accessed Claude Code Configuration Directory rule.\n0.243.3\nApril 10, 2026\nRule Changes\nReduced FPs for Unauthorized Process Accessed Claude Code Configuration Directory rule.\nReduced FPs for DNS Fast Flux Activity Detected rule (zabbix_proxy fix).\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for JVM Attach Attempt using Unix Socket rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for Possible Backdoor using BPF rule.\nReduced FPs for Modification of Container Image Cache rule.\nReduced FPs for AWS CLI used with endpoint url parameter rule.\nReduced FPs for Dynamic Linker Hijacking Using LD_AUDIT rule.\n0.243.2\nApril 08, 2026\nRule Changes\nReduced FPs for DNS Lookup for Dynamic DNS Domain Detected rule.\nReduced FPs for DNS Lookup for Reconnaissance Service Detected rule.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for CSharp Compiler Library Loaded at Runtime rule.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for Launch Excessively Capable Container rule.\nReduced FPs for Python .pth Persistence File Written by Non-Package-Manager rule.\nReduced FPs for Clear Log Activities rule.\nReduced FPs for Curl Exfiltrating File rule.\nReduced FPs for Find Authentication Certificates rule.\nReduced FPs for Redirect STDOUT/STDIN to Network Connection in Host rule.\nReduced FPs for Launch Suspicious Network Tool on Host rule.\nReduced FPs for AWS SSM Agent Activity Using SendCommand RunShellScript or RunPowerShellScript rule.\nReduced FPs for DNS Fast Flux Activity Detected rule.\n0.243.1\nApril 07, 2026\nNew Rules\nAdd Rule Bedrock AgentCore Gateway Created Without Authorization.\nAdd Rule Bedrock AgentCore Runtime Created.\nAdd Rule Bedrock AgentCore API Key Created.\nAdd Rule Bedrock AgentCore Policy Updated.\nAdd Rule Bedrock AgentCore Policy Deleted.\nAdded rule Azure VM Access Extension Written.\nAdded rule CSharp Compiler Library Loaded at Runtime.\nAdded Python .pth Persistence File Written by Non-Package-Manager rule.\nRule Changes\nDeprecate Azure VM Reset Local Administrator Password rule.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Create Privileged Pod rule.\nReduced FPs for Sensitive File Access Attempt Detected During Package Install rule.\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for PTRACE attached to process rule.\nReduced FPs for Run shell untrusted rule.\nReduced FPs for DNS Fast Flux Activity Detected rule.\nDefault Policy Changes\nUpdated Sysdig Runtime Notable Events policy.\n0.243.0\nApril 06, 2026\nRule Changes\nReduced FPs for Clear Log Activities rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Possible Jynx Rootkit Detected rule.\nReduced FPs for Reverse Shell via Unnamed Pipes rule.\nReduced FPs for Unauthorized Process Accessed Codex CLI Configuration Directory rule.\n0.242.5\nMarch 31, 2026\nRule Changes\nImproved Condition Remove Bulk Data from Disk rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\n0.242.4\nMarch 27, 2026\nRule Changes\nDeprecated Contact cloud metadata service from container rule.\nReduced FPs for Exfiltration of Secrets in Runner Using LOTL Binary rule.\nReduced FPs for Unauthorized Process Accessed Claude Code Configuration Directory rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Gemini CLI Executed with Risky CLI arguments rule.\n0.242.3\nMarch 26, 2026\nRule Changes\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for Claude Code Executed with Risky CLI arguments rule.\nReduced FPs for Codex CLI Executed with Risky CLI arguments rule.\nReduced FPs for Exfiltration of Secrets in Runner Using LOTL Binary rule.\nReduced FPs for Unauthorized Process Accessed Codex CLI Configuration Directory rule.\nReduced FPs for Unauthorized Process Accessed Claude Code Configuration Directory rule.\nReduced FPs for Unauthorized Process Accessed Gemini CLI Configuration Directory rule.\n0.242.2\nMarch 25, 2026\nRule Changes\nReduced FPs for Exfiltration of Secrets in Runner Using LOTL Binary rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\n0.242.1\nMarch 24, 2026\nNew Rules Added rule Exfiltration of Secrets in Runner Using LOTL Binary.\nAdded rule Reverse Shell via Unnamed Pipes.\nAdded rule Github Workflow Injection.\nRule Changes\nImproved Condition for DNS Lookup for Offensive Security Tool Domain Detected rule.\nReduced FPs for Unauthorized Process Accessed Claude Code Configuration Directory rule.\nImproved Condition for Detect malicious cmdlines rule.\nImproved Condition for Remove Bulk Data from Disk rule.\nReduced FPs for Unauthorized Process Accessed Gemini CLI Configuration Directory rule.\nReduced FPs for Gemini CLI Installation Detected rule.\nDefault Policy Changes\nUpdated Sysdig Runtime Behavioral Analytics policy.\n0.242.0\nMarch 24, 2026\nRule Changes\nReduced FPs for Unauthorized Process Accessed Claude Code Configuration Directory rule.\n0.241.5\nMarch 23, 2026\nRule Changes\nReduced FPs for Launch Excessively Capable Container rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Base64-encoded Python Script Execution rule.\n0.241.4\nMarch 20, 2026\nRule Changes\nReduced FPs for Claude Code Installation Detected rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\n0.241.3\nMarch 20, 2026\nRule Changes\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT To Socket With Pipes rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\n0.241.2\nMarch 18, 2026\nRule Changes\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nDefault Policy Changes\nPolicy Sysdig AI Runtime Activity Logs updated.\n0.241.1\nMarch 17, 2026\nNew Rules\nCodex Installation Detected.\nUnauthorized Process Accessed Codex CLI Configuration Directory.\nCodex CLI Executed with Risky CLI arguments.\nCodex CLI Accessing Sensitive Files.\nGemini Installation Detected.\nUnauthorized Process Accessed Gemini CLI Configuration Directory.\nGemini CLI Accessing Sensitive Files.\nGemini CLI Executed with Risky CLI arguments.\nClaude Code Installation Detected.\nUnauthorized Process Accessed Claude Code Configuration Directory.\nClaude Code Executed with Risky CLI arguments.\nClaude Code Accessing Sensitive Files.\nRule Changes\nDefault Policy Changes\nAdded Policy Sysdig AI Runtime Notable Events.\nAdded Policy Sysdig AI Runtime Activity Logs.\n0.241.0\nMarch 16, 2026\nNew Rules\nAdded Rule Ingress NGINX Malicious Annotation or Path Injection.\nRule Changes\nReduced FPs for Tampering with Security Software in Container rule.\nReduced FPs for New Kernel Module Created and Loaded rule.\nRule Ingress NGINX Annotation Validation Potential Bypass (CVE-2024-7646) Deprecated.\nDefault Policy Changes\nPolicy Sysdig K8s Notable Events updated.\n0.240.0\nMarch 03, 2026\nNew Rules\nAdded Rule Github Actions Workflow Triggered by Issue Event.\nAdded Rule Github Forked Repository Deleted.\nRule Changes\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nImproved condition for Netcat remote code execution rule.\nImproved condition for Netcat Remote Code Execution in Container rule.\nImproved condition for Execution from /dev/shm rule.\n0.239.0\nFebruary 27, 2026\nRule Changes\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Run shell untrusted rule.\nReduced FPs for Unprivileged Delegation of Page Faults Handling to a Userspace Process rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nImproved Output for Execution from /tmp rule.\n0.238.1\nFebruary 24, 2026\nRule Changes\nReduce FPs for AWS ECS Create Task Definition.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Suspicious RC Script Modification rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Container Launched In Host PID Namespace rule.\nReduced FPs for Unprivileged Delegation of Page Faults Handling to a Userspace Process rule.\n0.238.0\nFebruary 20, 2026\nRule Changes\nReduced FPs for DNS Lookup for Reconnaissance Service Detected rule.\nReduced FPs for Modification of Container Image Cache rule.\nImproved Output for Launch Remote File Copy Tools on Host rule.\nImproved Output for several rules.\n0.237.2\nReduced FPs for Execution from /tmp rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Memory Manipulation by Fileless Program rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\n0.237.1\nFebruary 17, 2026\nRule Changes\nReduced FPs for Unprivileged Delegation of Page Faults Handling to a Userspace Process rule.\nReduced FPs for DNS Tunneling Activity Detected rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Container Launched In Host PID Namespace rule.\n0.237.0\nFebruary 16, 2026\nRule Changes\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Run shell untrusted rule.\n0.236.2\nFebruary 13, 2026\nRule Changes\nReduced FPs for Unprivileged Delegation of Page Faults Handling to a Userspace Process rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Container Escape using Kernel Module rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\n0.236.1\nFebruary 10, 2026\nRule Changes\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Launch Suspicious Network Tool in Container rule.\nReduced FPs for Clear Log Activities rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Mailbox Data Modification rule.\nReduced FPs for Launch Excessively Capable Container rule.\nReduced FPs for Suspicious RC Script Modification rule.\n0.236.0\nFebruary 09, 2026\nRule Changes\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Contact Task Metadata Endpoint rule.\nReduced FPs for Redirect STDOUT/STDIN to Network Connection in Container rule.\nReduced FPs for Run shell untrusted rule.\nReduced FPs for Execution of binary using ld-linux rule.\nReduced FPs for New Kernel Module Created and Loaded rule.\n0.235.4\nFebruary 06, 2026\nRule Changes\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for Fileless Malware Detected (memfd) rule.\n0.235.3\nFebruary 05, 2026\nRule Changes\nReduced FPs for Offensive Security Tool Detected rule.\nReduced FPs for Suspicious Java Child Processes rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for Container Escape using Kernel Module rule.\n0.235.2\nFebruary 04, 2026\nRule Changes\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Find GCP Credentials rule.\n0.235.1\nFebruary 03, 2026\nRule Changes\nReduced FPs for Run Several XLarge EC2 Instances.\nReduced FPs for eBPF Program Loaded into Kernel rule.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for AWS SSM Agent Activity using StartSession rule.\n0.235.0\nFebruary 02, 2026\nRule Changes\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for Run shell untrusted rule.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Launch Suspicious Network Tool in Container rule.\n0.234.3\nJanuary 30, 2026\nRule Changes\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Find GCP Credentials rule.\nReduced FPs for Suspicious RC Script Modification rule.\n0.234.2\nJanuary 28, 2026\nRule Changes\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Clear Log Activities rule.\nReduced FPs for Reconnaissance attempt to find SUID binaries rule.\nReduced FPs for Reconnaissance attempt to find SETGID binaries rule.\n0.234.1\nJanuary 27, 2026\nNew Rules\nAdded rule CodeCommit Create Git Credentials.\nAdded rule Change Policy's Default Version.\nRule Changes\nReduced FPs for Base64-encoded Python Script Execution rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Reverse Shell Spawned From Binary Through Pipes rule.\nReduced FPs for Modify Grub Configuration Files rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\n0.234.0\nJanuary 26, 2026\nRule Changes\nReduced FPs for Execution from Temporary Filesystem (tmpfs) rule.\nReduced FPs for Reverse Shell Spawned From Binary Through Pipes rule.\nReduced FPs for Modification of Container Image Cache rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Find GCP Credentials rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\n0.233.3\nJanuary 23, 2026\nRule Changes\nReduced FPs for New Kernel Module Created and Loaded rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\n0.233.2\nJanuary 22, 2026\nRule Changes\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Launch Suspicious Network Tool on Host rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for PTRACE Attached to Process rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT To Socket with Pipes rule.\n0.233.1\nJanuary 20, 2026\nRule Changes\nReduced FPs for EC2 Create Launch Template rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Reverse Shell Spawned From Binary Through Pipes rule.\nReduced FPs for Launch Ingress Remote File Copy Tools in Container rule.\nReduced FPs for DNS Fast Flux Activity Detected rule.\n0.233.0\nJanuary 16, 2026\nRule Changes\nReduced FPs for Modify Grub Configuration Files rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\nReduced FPs for Execution from /dev/shm rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Detect reconnaissance scripts rule.\nReduced FPs for nsenter Container Escape rule.\n0.232.2\nJanuary 14, 2026\nRule Changes\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Launch Ingress Remote File Copy Tools in Container rule.\nReduced FPs for Detect reconnaissance scripts rule.\nReduced FPs for Mount on Container Path Detected rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\nReduced FPs for Reverse Shell Spawned From Binary Through Pipes rule.\n0.232.1\nJanuary 13, 2026\nRule Changes\nReduced FPs for nsenter Container Escape rule.\nReduced FPs for EC2 Get User Data.\nReduced FPs for EC2 Create Launch Template.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\nReduced FPs for Execution from /dev/shm rule.\nReduced FPs for Base64-encoded Shell Script Execution rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for New Kernel Module Created and Loaded rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nImprove Output for Allocate New Elastic IP Address to AWS Account.\n0.232.0\nJanuary 09, 2026\nRule Changes\nReduced FPs for JVM Attach Attempt using Unix Socket rule.\nReduced FPs for DNS Fast Flux Activity Detected rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for PTRACE attached to process rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Network Tool Executed During NPM Install rule.\nReduced FPs for DNS Lookup for Proxy/VPN Domain Detected rule.\n0.231.7\nJanuary 05, 2026\nRule Changes\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Possible Remote Command Execution Detected rule.\nReduced FPs for BPF Command Executed by Fileless Program rule.\nReduced FPs for Modify Grub Configuration Files rule.\n0.231.6\n","url":"https://docs.sysdig.com/en/release-notes/falco-rules-changelog/"},{"id":620,"title":"JMX/JVM","content":"jmx_jvm_class_loaded Prometheus ID jmx_jvm_class_loaded Legacy ID jvm.class.loaded Metric Type gauge Unit number Description The number of classes that are currently loaded in the JVM. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_class_unloaded Prometheus ID jmx_jvm_class_unloaded Legacy ID jvm.class.unloaded Metric Type gauge Unit number Description Additional Notes jmx_jvm_gc_ConcurrentMarkSweep_count Prometheus ID jmx_jvm_gc_ConcurrentMarkSweep_count Legacy ID jvm.gc.ConcurrentMarkSweep.count Metric Type counter Unit number Description The number of times the Concurrent Mark-Sweep garbage collector has run. Additional Notes jmx_jvm_gc_ConcurrentMarkSweep_time Prometheus ID jmx_jvm_gc_ConcurrentMarkSweep_time Legacy ID jvm.gc.ConcurrentMarkSweep.time Metric Type counter Unit time Description The amount of time the Concurrent Mark-Sweep garbage collector has run. Additional Notes jmx_jvm_gc_Copy_count Prometheus ID jmx_jvm_gc_Copy_count Legacy ID jvm.gc.Copy.count Metric Type counter Unit number Description Additional Notes jmx_jvm_gc_Copy_time Prometheus ID jmx_jvm_gc_Copy_time Legacy ID jvm.gc.Copy.time Metric Type counter Unit time Description Additional Notes jmx_jvm_gc_G1_Old_Generation_count Prometheus ID jmx_jvm_gc_G1_Old_Generation_count Legacy ID jvm.gc.G1_Old_Generation.count Metric Type counter Unit number Description Additional Notes jmx_jvm_gc_G1_Old_Generation_time Prometheus ID jmx_jvm_gc_G1_Old_Generation_time Legacy ID jvm.gc.G1_Old_Generation.time Metric Type counter Unit time Description Additional Notes jmx_jvm_gc_G1_Young_Generation_count Prometheus ID jmx_jvm_gc_G1_Young_Generation_count Legacy ID jvm.gc.G1_Young_Generation.count Metric Type counter Unit number Description Additional Notes jmx_jvm_gc_G1_Young_Generation_time Prometheus ID jmx_jvm_gc_G1_Young_Generation_time Legacy ID jvm.gc.G1_Young_Generation.time Metric Type counter Unit time Description Additional Notes jmx_jvm_gc_MarkSweepCompact_count Prometheus ID jmx_jvm_gc_MarkSweepCompact_count Legacy ID jvm.gc.MarkSweepCompact.count Metric Type counter Unit number Description Additional Notes jmx_jvm_gc_MarkSweepCompact_time Prometheus ID jmx_jvm_gc_MarkSweepCompact_time Legacy ID jvm.gc.MarkSweepCompact.time Metric Type counter Unit time Description Additional Notes jmx_jvm_gc_PS_MarkSweep_count Prometheus ID jmx_jvm_gc_PS_MarkSweep_count Legacy ID jvm.gc.PS_MarkSweep.count Metric Type counter Unit number Description The number of times the parallel scavenge Mark-Sweep old generation garbage collector has run. Additional Notes jmx_jvm_gc_PS_MarkSweep_time Prometheus ID jmx_jvm_gc_PS_MarkSweep_time Legacy ID jvm.gc.PS_MarkSweep.time Metric Type counter Unit time Description The amount of time the parallel scavenge Mark-Sweep old generation garbage collector has run. Additional Notes jmx_jvm_gc_PS_Scavenge_count Prometheus ID jmx_jvm_gc_PS_Scavenge_count Legacy ID jvm.gc.PS_Scavenge.count Metric Type counter Unit number Description The number of times the parallel eden/survivor space garbage collector has run. Additional Notes jmx_jvm_gc_PS_Scavenge_time Prometheus ID jmx_jvm_gc_PS_Scavenge_time Legacy ID jvm.gc.PS_Scavenge.time Metric Type counter Unit time Description The amount of time the parallel eden/survivor space garbage collector has run. Additional Notes jmx_jvm_gc_ParNew_count Prometheus ID jmx_jvm_gc_ParNew_count Legacy ID jvm.gc.ParNew.count Metric Type counter Unit number Description The number of times the parallel garbage collector has run. Additional Notes jmx_jvm_gc_ParNew_time Prometheus ID jmx_jvm_gc_ParNew_time Legacy ID jvm.gc.ParNew.time Metric Type counter Unit time Description The amount of time the parallel garbage collector has run. Additional Notes jmx_jvm_heap_committed Prometheus ID jmx_jvm_heap_committed Legacy ID jvm.heap.committed Metric Type counter Unit number Description The amount of memory that is currently allocated to the JVM for heap memory. Heap memory is the storage area for Java objects. The JVM may release memory to the system and Heap Committed could decrease below Heap Init; but Heap Committed can never increase above Heap Max. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_heap_init Prometheus ID jmx_jvm_heap_init Legacy ID jvm.heap.init Metric Type counter Unit number Description The initial amount of memory that the JVM requests from the operating system for heap memory during startup (defined by the –Xms option). The JVM may request additional memory from the operating system and may also release memory to the system over time. The value of Heap Init may be undefined. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_heap_max Prometheus ID jmx_jvm_heap_max Legacy ID jvm.heap.max Metric Type counter Unit number Description The maximum size allocation of heap memory for the JVM (defined by the –Xmx option). Any memory allocation attempt that would exceed this limit will cause an OutOfMemoryError exception to be thrown. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_heap_used Prometheus ID jmx_jvm_heap_used Legacy ID jvm.heap.used Metric Type counter Unit number Description The amount of allocated heap memory (ie Heap Committed) currently in use. Heap memory is the storage area for Java objects. An object in the heap that is referenced by another object is \u0026rsquo;live\u0026rsquo;, and will remain in the heap as long as it continues to be referenced. Objects that are no longer referenced are garbage and will be cleared out of the heap to reclaim space. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_heap_used_percent Prometheus ID jmx_jvm_heap_used_percent Legacy ID jvm.heap.used.percent Metric Type gauge Unit percent Description The ratio between Heap Used and Heap Committed. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_nonHeap_committed Prometheus ID jmx_jvm_nonHeap_committed Legacy ID jvm.nonHeap.committed Metric Type counter Unit number Description The amount of memory that is currently allocated to the JVM for non-heap memory. Non-heap memory is used by Java to store loaded classes and other meta-data. The JVM may release memory to the system and Non-Heap Committed could decrease below Non-Heap Init; but Non-Heap Committed can never increase above Non-Heap Max. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_nonHeap_init Prometheus ID jmx_jvm_nonHeap_init Legacy ID jvm.nonHeap.init Metric Type counter Unit number Description The initial amount of memory that the JVM requests from the operating system for non-heap memory during startup. The JVM may request additional memory from the operating system and may also release memory to the system over time. The value of Non-Heap Init may be undefined. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_nonHeap_max Prometheus ID jmx_jvm_nonHeap_max Legacy ID jvm.nonHeap.max Metric Type counter Unit number Description The maximum size allocation of non-heap memory for the JVM. This memory is used by Java to store loaded classes and other meta-data. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_nonHeap_used Prometheus ID jmx_jvm_nonHeap_used Legacy ID jvm.nonHeap.used Metric Type counter Unit number Description The amount of allocated non-heap memory (ie Non-Heap Committed) currently in use. Non-heap memory is used by Java to store loaded classes and other meta-data. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_nonHeap_used_percent Prometheus ID jmx_jvm_nonHeap_used_percent Legacy ID jvm.nonHeap.used.percent Metric Type gauge Unit percent Description The ratio between Non-Heap Used and Non-Heap Committed. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_thread_count Prometheus ID jmx_jvm_thread_count Legacy ID jvm.thread.count Metric Type gauge Unit number Description The current number of live daemon and non-daemon threads. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. jmx_jvm_thread_daemon Prometheus ID jmx_jvm_thread_daemon Legacy ID jvm.thread.daemon Metric Type gauge Unit number Description The current number of live daemon threads. Daemon threads are used for background supporting tasks and are only needed while normal threads are executing. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/jmx/"},{"id":621,"title":"Legacy Components","content":"BackgroundSysdig Secure has multiple benchmark and compliance solutions (from oldest to newest):\nBenchmarks (V1) - Retired Dec. 1, 2022 Benchmarks (V2)/Compliance (legacy - Retired March 15, 2023 Compliance (Unified) - Retired March 15, 2023, for SaaS. Still in use for On-Prem. Compliance (Formerly called \u0026ldquo;Actionable Compliance\u0026rdquo;) KSPM components are used for the current Compliance module as well as other upcoming Sysdig Secure features.\nUse this page to understand:\nWhy to upgrade your Sysdig Benchmark/Compliance version Which version you are currently using Which upgrade path is appropriate and how to complete it Benefits of UpgradingThe new Compliance module moves beyond just finding violations to promoting remediations from source to run.\nAdditionally:\nAll resources are added to a central inventory data store along with their configuration information The policy evaluation happens in the backend using OPA (Open Policy Agent) as the policy engine 900+ controls are evaluated OOTB supporting: Kubernetes (both vanilla and managed - EKS, GKE, AKS) Linux Docker AWS GCP Azure Simple and intuitive creation of custom policies to match your organization’s needs Unified experience across different target endpoints Clear and concise explanations of violations Which Version Am I Using?If you are using Unified Compliance, the URL will have the form: https://secure.sysdig.com/#/compliance/tasks\nEnable ComplianceEnablement requires two basic steps:\nAgent upgrade or agent install, using Helm enablement to take advantage of PR-integrated remediation (optional) The precise upgrade/install steps differ depending which version you are currently using. When the basic steps are complete, the UI for actionable compliance will be populated with your environment\u0026rsquo;s content.\nUpgrading from any Other Version or New InstallNote that Sysdig is currently supporting two Helm chart versions: the original and the new, and the parameters differ slightly between them.\nUse the new chart if:\nYou are installing agents for the first time, or You installed using the new chart and now want to upgrade to enable Compliance. If necessary, check the Secure endpoint for your region. Replace the sysdigcloud-benchmark-runner with the KSPM collector.\nIf you installed the Sysdig agent using the original chart, add the following flags:\n--set nodeAnalyzer.benchmarkRunner.deploy=false \\ --set kspm.deploy=true \\ --set kspmCollector.apiEnpoint=\u0026lt;endpoint\u0026gt; \\ If you installed the Sysdig agent using the new chart, or are installing the agent for the first time, add the following flags:\n--set nodeAnalyzer.nodeAnalyzer.benchmarkRunner.deploy=false \\ --set global.kspm.deploy=true \\ --set kspmCollector.apiEndpoint=\u0026lt;endpoint\u0026gt; \\ Disable existing compliance and benchmark tasks. In the UI, switch the Enabled toggle of each task. All tasks will be automatically disabled on March 15, 2023, and will no longer be able to be created or re-enabled.\n","url":"https://docs.sysdig.com/en/sysdig-secure/legacy-agent-components/"},{"id":622,"title":"Legacy Metric Alerts","content":" The lines shown in the preview chart represent the values for the segments selected to monitor. The popup is a color-coded legend to show which segment (or combination of segments if there is more than one) the lines represent. You can also deselect some segment lines to prevent them from showing in the chart. Note that there is a limit of 10 lines that Sysdig Monitor ever shows in the preview chart.\nDefine a Metric AlertGuidelines Set a unique name and description: Set a meaningful name and description that help recipients easily identify the alert\nSpecify multiple segments: Selecting a single segment might not always supply enough information to troubleshoot. Enrich the selected entity with related information by adding additional related segments. Enter hierarchical entities so you have the bottom-down picture of what went wrong and where. For example, specifying a Kubernetes Cluster alone does not provide the context necessary to troubleshoot. In order to narrow down the issue, add further contextual information, such as Kubernetes Namespace, Kubernetes Deployment, and so on.\nSpecify MetricsSelect a metric that this alert will monitor. You can also define how data is aggregated, such as avg, max, min or sum. To alert on multiple metrics using boolean logic, switch to multi-condition alert.\nConfigure ScopeFilter the environment on which this alert will apply.\nFilter the environment on which this alert will apply. An alert will fire when a host goes down in the availability zone, us-east-1b.\nUse advanced operators to include, exclude, or pattern-match groups, tags, and entities. See Multi-Condition Alerts.\nYou can also create alerts directly from Explore and Dashboards for automatically populating this scope.\nConfigure TriggerDefine the threshold and time window for assessing the alert condition. Single Alert fires an alert for your entire scope, while Multiple Alert fires if any or every segment breach the threshold at once.\nMetric alerts can be triggered to notify you of different aggregations:\nAggregation\nDescription\non average\nThe average of the retrieved metric values across the time period. Actual number of samples retrieved is used to calculate the value.\nFor example, if new data is retrieved in the 7th minute of a 10-minutes sample and the alert is defined as on average, the alert will be calculated by summing the 3 recorded values and dividing by 3.\nas a rate\nThe average value of the metric across the time period evaluated. The expected number of values is used to calculate the rate to trigger the alert.\nFor example, if new data is retrieved in the 7th minute of a 10-minutes sample and the alert is defined as as a rate, the alert will be calculated by summing the 3 recorded values and dividing by 10 ( 10 x 1 minute samples).\nin sum\nThe combined sum of the metric across the time period evaluated.\nat least once\nThe trigger value is met for at least one sample in the evaluated period.\nfor the entire time\nThe trigger value is met for a every sample in the evaluated period.\nas a rate of change\nThe trigger value is met the change in value over the evaluated period.\nFor example, if the file system used percentage goes above 75 for the last 5 minutes on an average, multiple alerts will be triggered. The mac address of the host and mount directory of the file system will be represented in the alert notification.\nUse Cases Number of processes running on a host is not normal\nRoot volume disk usage in a container is high\n","url":"https://docs.sysdig.com/en/sysdig-monitor/-legacy-alerts-editor/legacy-metric-alerts/"},{"id":623,"title":"Migrating from Promscrape V1 to V2","content":"To use the latest features, such as Service Discovery and Monitoring Integrations, enable the prom_service_discovery option in your environment. This configuration is controlled by the prom_discovery_service parameter in the dragent.yaml file. You can either modify directly the dragent.yaml file or add the parameter in the values.yaml file of the Helm chart.\nprometheus: prom_service_discovery: true # Enables Promscrape V2 (enabled by default) For the sysdig-deploy chart, set the configuration under the agent.sysdig.settings key.\nagent: sysdig: settings: prometheus: prom_service_discovery: true # Enables Promscrape V2 (enabled by default) For the shield chart, write the configuration under the host.additional_settings key.\nhost: additional_settings: prometheus: prom_service_discovery: true # Enables Promscrape V2 (enabled by default) How to check which version of Promscrape is runningTo check which version of Promscrape is running, you can use the following command in the Agent Console:\n$ prometheus ? $ prometheus config ? $ prometheus config show ? Similarly, you can look for prometheus.prom_discovery_service: in the draios.log file to check if Promscrape V2 is enabled.\nCompare Promscrape V1 and V2The main difference between V1 and V2 is how scrape targets are determined.\nIn V1 targets are found through process-filtering rules configured in dragent.yaml or dragent.default.yaml (if no rules are given in dragent.yaml). The process-filtering rules are applied to all the running processes on the host. Matches are made based on process attributes, such as process name or TCP ports being listened to, as well as associated contexts from docker or Kubernetes, such as container labels or Kubernetes annotations.\nWith Promscrape V2, scrape targets are determined by scrape_configs fields in a prometheus.yaml file (or the prometheus-v2.default.yaml file if no prometheus.yaml exists). The scrape_config settings are compatible with the normal Prometheus configuration. Here is an example:\nglobal: scrape_interval: 10s scrape_configs: - job_name: \u0026#39;my_pod_job\u0026#39; sample_limit: 40000 tls_config: insecure_skip_verify: true kubernetes_sd_configs: - role: pod relabel_configs: # Look for pod name starting with \u0026#34;my_pod_prefix\u0026#34; in namespace \u0026#34;my_namespace\u0026#34; - action: source_labels: [__meta_kubernetes_namespace,__meta_kubernetes_pod_name,__meta_kubernetes_pod_label] separator: / regex: my_namespace/my_pod_prefix.+ - action: keep source_labels: [__meta_kubernetes_pod_label_app] regex: my_app_metrics # In those pods try to scrape from port 9876 - source_labels: [__address__] action: replace target_label: __address__ regex: (.+?)(\\\\:\\\\d)? replacement: $1:9876 # Trying to ensure we only scrape local targets # __HOSTIPS__ is replaced by promscrape with a regex list of the IP addresses # of all the active network interfaces on the host - action: keep source_labels: [__meta_kubernetes_pod_host_ip] regex: __HOSTIPS__ # Holding on to pod-id and container name so we can associate the metrics # with the container (and cluster hierarchy) - action: replace source_labels: [__meta_kubernetes_pod_uid] target_label: sysdig_k8s_pod_uid - action: replace source_labels: [__meta_kubernetes_pod_container_name] target_label: sysdig_k8s_pod_container_name Migrate Using Default ConfigurationThe default configuration for Promscrape V1 triggers the scraping based on standard Kubernetes pod annotations and container labels. Users running Kubernetes with Promscrape V1 default rules and triggering scraping based on pod annotations do not need to take any action to migrate to V2. The migration happens automatically.\nThe default configuration for Promscrape V2 currently triggers scraping only based on the standard Kubernetes pod annotations leveraging the Prometheus native service discovery.\nExample Pod Annotations Annotation\nValue\nDescription\nprometheus.io/scrape\ntrue\nRequired field.\nprometheus.io/port\nThe port number to scrape\nOptional. It will scrape all pod-registered ports if omitted.\nprometheus.io/scheme\n\u0026lt;http|https\u0026gt;\nThe default is http.\nprometheus.io/path\nThe URL\nThe default is /metrics.\nNon-Kubernetes EnvironmentsUsers operating non-Kubernetes environments might need to continue using V1 for now, depending on how scraping is triggered. As of today Promscrape V2 doesn\u0026rsquo;t support leveraging container and Docker labels to discover Prometheus metrics endpoints. If your environment is one of these, define static jobs with the IP:port to be scrapped.\nExample Static Job- job_name: \u0026#39;static10\u0026#39; static_configs: - targets: [\u0026#39;localhost:5010\u0026#39;] Migrate Using Custom RulesIf you relying on custom process_filter rules to collect metrics, use any method using standard Prometheus configuration syntax to scrape the endpoints. We recommend one of the following:\nAdopt the standard approach of adding the standard Prometheus annotations to their pods. For more information, see Migrate Using Default Configuration. Write a Prometheus scrape_config by using Kubernetes pods service discovery and use the appropriate pod metadata to trigger their scrapes. See the below example for converting your process_filter rules to Prometheus terminology.\nprocess_filter (Promscrape V1)\nPrometheus (Promscrape V2)\n- include: kubernetes.pod.annotation.sysdig.com/test: true - action: keep source_labels: [__meta_kubernetes_pod_annotation_sysdig_com_test] regex: true - include: kubernetes.pod.label.app: sysdig - action: keep source_labels: [__meta_kubernetes_pod_label_app] regex: \u0026#39;sysdig\u0026#39; -include: container.label.com.sysdig.test: true Not supported.\n- include: process.name: test Not supported.\n- include: process.cmdline: sysdig-agent Not supported.\n- include: port: 8080 - action: keep source_labels: [__meta_kubernetes_pod_container_port_number] regex: \u0026#39;8080\u0026#39; - include: container.image: sysdig-agent Not supported.\n- include: container.name: sysdig-agent - action: keep source_labels: [__meta_kubernetes_pod_container_name] regex: \u0026#39;sysdig-agent\u0026#39; - include: appcheck.match: sysdig Appchecks are not compatible with Promscrape v2. See Configure Monitoring Integrations for supported integrations.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/custom-integrations/migrating-from-promscrape-v1-to-v2/"},{"id":624,"title":"OCI","content":" Automatic Cloud Account Onboarding and Selective Cloud Account Onboarding are currently not supported on OCI.\nReview Oracle Cloud IAMSysdig Oracle Cloud integration leverages Cross-Tenancy Policies to manage access to your environment. An Admit Policy will be created in the root Compartment of your Tenancy, granting access to a Sysdig owned Oracle Tenancy that contains the corresponding Endorse policy. The Endorse policy exists in the Sysdig Tenant, and defines the general set of actions that a groups in the Sysdig Tenancy can perform in your tenancy.\nOCI IAM Resources do not support Cross Tenancy Access, and thus a User will also be created in your OCI Tenancy to collect these resources.\nThe onboarding process involves the following concepts:\nCustomer Tenancy: The Tenancy that you are connecting to Sysdig. Installer: An OCI User role that will be used to perform the onboarding. This User must exist in the Customer Tenancy. Sysdig does not have access to this identity. Sysdig: A Sysdig owned OCI Tenancy that contains a set of IAM Groups organized by feature. Sysdig has access to these Groups, and they will be granted specific permissions within your Tenancy. Prerequisites Sysdig Secure SaaS with Admin permissions Terraform v1.5.0+ Access to a User with the permissions required to install Permissions Required to InstallThe Installer must have at least the following permission assigned:\nPermission to create policies, users and groups in the root Compartment. Permissions Granted to SysdigThe installation creates two Policies that grant the following permissions to Sysdig:\nAdmitSysdigSecureTenantOnboarding-XXXX policy to manage the base integration with Sysdig inspect tenancies in tenancy inspect compartments in tenancy AllowSysdigSecureTenantConfigPosture-XXXX policy to collect an Inventory of cloud resources, and perform CSPM read all-resources in tenancy Supported OCI RegionsSysdig supports agentless scanning in the following OCI regions:\nRegion Display Name ap-hyderabad-1 Hyderabad ap-mumbai-1 Mumbai ap-sydney-1 Sydney ap-tokyo-1 Tokyo eu-amsterdam-1 Amsterdam eu-frankfurt-1 Frankfurt me-abudhabi-1 Abu Dhabi me-jeddah-1 Jeddah me-riyadh-1 Riyadh us-ashburn-1 Ashburn us-phoenix-1 Phoenix us-sanjose-1 San Jose Need support for a region not listed? Contact your Sysdig representative to request additional region coverage.\nPrepare Your EnvironmentConfigure Installation PermissionsEnsure the User you use to log in to OCI has the necessary permissions to install.\nYou can:\nUse an existing User who meets the permissions requirements. Create a new User and set up permissions. Add permissions to an existing User. Log into Oracle Cloud and navigate to Identity \u0026amp; Security\u0026gt;Policies. Under Policies, verify and add necessary policies. Authenticate and Configure TerraformConfigure Terraform to use Oracle Cloud Credentials for the User from step 1. A simple way is to configure your ~/.oci/config file using Oracle\u0026rsquo;s How to Generate an API Signing Key document.\nFor alternative ways to authenticate Terraform, see the OCI Terraform Provider documentation.\nCollect your Tenancy DetailsTenancy OCID \u0026amp; Home Region Sign in to the OCI Console. Navigate to Governance \u0026amp; Administration \u0026gt; Tenancy details. Copy the OCID shown under Tenancy information. Note the Home region shown under Tenancy information. (Optional) Compartment OCIDBy default, your entire OCI Tenancy will be onboarded. If you would like to restrict the onboarding to a subset of Compartments, you can specify the top level compartment that will be onboarded. All subcompartments under this top level compartment will also be onboarded.\nTo onboard multiple independent compartments (and their subcomparments), you must complete the onboarding once per top level compartment.\nConnect Oracle Cloud using the Terraform Log in to Sysdig Secure Select Integrations \u0026gt; Environments \u0026gt; Oracle Cloud, and select Add Oracle Cloud Account in the top right corner. Enter your: Tenancy OCID: The OCID of your Oracle Tenancy. Home Region: The home region of your tenancy. (optional) Compartment OCID: To a specific compartment of Tenancy, enter the compartment OCID. Leave this field blank to onboard your entire Tenancy. Generate and apply the Terraform code: Create a main.tf file. Copy the snippet provided into the file. Run the command: terraform init \u0026amp;\u0026amp; terraform apply. Ensure that you are using Terraform provider version ~\u0026gt;3.3 and the latest available module versions. If it has been some time since your initial onboarding, regenerate the Terraform main.tf file from the Sysdig UI under Integrations \u0026gt; OCI. For example:\nterraform { required_providers { sysdig = { source = \u0026#34;sysdiglabs/sysdig\u0026#34; version = \u0026#34;~\u0026gt;3.3\u0026#34; } } } ... module \u0026#34;onboarding\u0026#34; { source = \u0026#34;sysdiglabs/secure/oracle//modules/onboarding\u0026#34; version = \u0026#34;~\u0026gt;2.0\u0026#34; } ... module \u0026#34;config-posture\u0026#34; { source = \u0026#34;sysdiglabs/secure/oracle//modules/config-posture\u0026#34; version = \u0026#34;~\u0026gt;2.0\u0026#34; sysdig_secure_account_id = module.onboarding.sysdig_secure_account_id } After deployment, your Compartments will appear on the Cloud Accounts page.\nCheck the Connection StatusYou can verify your CSPM configuration by checking the connection status.\nIn Sysdig Secure, select Integrations \u0026gt; Environments \u0026gt; Oracle Cloud.\nThe Status column shows the overall connection status:\nConnected Error Unknown Select the desired account to review the individual services in the detail drawer.\nThe health status for CSPM configuration is given below:\nCSPM Status Description Healthy ✅ The account has been successfully connected, and all the resources have been scanned. Error ❌ Authentication errors. For example: Invalid account IDInvalid client secretInvalid access credentialsAccess token errors Deny policy created by the user is preventing Sysdig from collecting resourcesThe scan takes too long and eventually times out.Unknown error Not Enabled The feature is not enabled ","url":"https://docs.sysdig.com/en/sysdig-secure/connect-oracle-cloud/"},{"id":625,"title":"Release Notes","content":"Sysdig components are released on varying schedules. The links below point to the ever-updated changes.\nIt is recommended to follow upgrade best practices:\nKeep upgrades current. Test upgrades in a non-mission-critical or staging environment before rolling into production. Installed Components ChangelogSysdig Linux Agent Release Notes\nSysdig Windows Agent Release Notes\nSysdig Cluster Shield\nSysdig Host Shield for Linux\nSysdig Host Shield for Windows\nSysdig Serverless Agent Release Notes\nSysdig SaaS ChangelogSaaS: Sysdig Monitor Release Notes\nSaaS: Sysdig Secure Release Notes\nSysdig On-Prem ChangelogSysdig On-Premises Release Notes\nSysdig On-Premises Release Support\nRules ChangelogsFalco Rules Changelog\nBehavioral Analytics\nRSS Feed for Sysdig DocumentationSubscribe to the RSS feed for Sysdig Release Notes to stay updated with the latest product releases. Use your favorite news aggregation apps, such as RSS Feed Reader, to get notified immediately when we post new content.\nAdd the desired RSS feed URL to your reader and it should notify you whenever a new release note is available.\nSysdig Shield\nSysdig Serverless Agent\nSysdig Monitor Release Notes\nSysdig Secure Release Notes\nSysdig On-Premises Release Notes\nFalco Rules Release Notes\n","url":"https://docs.sysdig.com/en/release-notes/"},{"id":626,"title":"Cost Reports","content":"Review ReportsTo access the Reports page and review reports:\nLog in to Sysdig Monitor.\nSelect Costs \u0026gt; Reports.\nThe Reports page appears. Here, you can review your existing reports.\nUse the search bar to find a report by name.\nUse the Select Report Type dropdown to filter reports by type.\nSelect columns, such as Name, Enabled or Report Type to sort the list alphabetically, by enablement status, or by type.\nCreate a ReportTo create a Costs Report:\nLog in to Sysdig Monitor, and select Costs | Reports or Costs | Costs Explorer.\nFrom either Reports or Cost Explorer, select Create New Report in the top right corner.\nThe New Report page opens.\nConfigure the report details:\nName: Enter a unique name for your report. Description: Enter a meaningful description. Report type: Select your preferred report type. Workload Cost Trends: Analyze workload cost changes over time to track spending trends. This is useful for comparing costs between periods. See Workload Cost Trends Report Wasted Workload Spend: Gain insight into expenses from oversized or underutilized workloads. This is useful for identifying inefficiencies in resource usage. See Wasted Workload Spend Report Export Format: Choose the format the report should be exported in: JSON or CSV. You can export reports for offline processing or integration with third-party tools. Define the report. By default, the scope includes the Team Scope of the team your current login. You can see the form your report will take in the Data Preview below.\nFilter the scope with labels. For example, to limit the report to the namespace risk-flow, use the labels kube_namespace_name in risk-flow. You can add multiple labels to build a highly specific report.\nUse Group By to determine which grouping columns will appear in the report. Wasted Workload Spend reports have the groups kube_cluster_name, kube_namespace_name, and kube_workload_name by default.\nTime Window: For Wasted Workload Spend, choose the Time Window of the report.\nSet the frequency of the report. This determines the time frame of cost data included in the final report.\nSelect which notification channel, if any, should be notified when the report is ready. The available channels are Email and Slack.\nYou can observe a Preview of the data to export. You can also retrieve the latest report through our API and connect with your preferred tools.\nYou can also create Cost Reports in Cost Explorer.\nTypes of Cost ReportsWorkload Cost Trends ReportWorkload Cost Trends Reports reveal which resource consumption trends drive changes in your costs. Use these reports to compare costs between periods, such as week over week or month over month. By grouping data with labels like kube_cluster_name and kube_namespace_name you can identify whether workloads are becoming more or less expensive over time.\nWasted Workload Spend ReportWasted Workload Spend Reports provide insights into resource consumption at the workload level by calculating how much allocated CPU and memory a workload uses. By default, these reports group cost data by kube_cluster_name, kube_namespace_name, and kube_workload_name. You can add additional label groupings, but these defaults are the minimum required. The report calculates the following cost metrics at a workload level:\nAccrued Cost: Represents the CPU and memory costs allocated to a workload, based on its configured CPU and memory quotas. If usage exceeds these quotas, the actual usage determines the accrued cost. Costs from Persistent Volume Claims (PVC) are also included in this calculation.\nEstimated Rightsizing Spend: Represents the cost of resources based on actual usage of CPU and memory as an average over a specified time window. It provides insights into potential savings by aligning resource allocation with actual usage patterns.\nWasted Spend: The cost of CPU and memory resources requested by a workload but not utilized. While some buffer is essential for handling spikes, excessive unused resources can result in unnecessary costs.\nThe relationship between these terms is represented in the formula: Accrued Costs = Estimated Rightsizing Spend + Wasted Spend\nWorkload Rightsizing Report This feature is currently in beta.\nWorkload Rightsizing Reports optimize resource allocation for Kubernetes workloads by comparing actual resource usage (CPU and memory) of containers within those workloads against historical usage. These reports help identify opportunities to downsize or upsize workloads based on real usage patterns, reducing resource waste and improving performance.\nBy default, rightsizing recommendations are grouped by kube_cluster_name, kube_namespace_name, and kube_workload_name. This grouping reflects how CPU and memory resources are allocated in Kubernetes (at the workload level) and cannot be modified.\nTo refine the scope of the report, you can configure a scope using workload labels only. This concentrates focus on specific workloads or subsets of workloads.\nRightsizing recommendations are based on usage data collected across the full time window. If you narrow the scope by adding extra labels, you might exclude some containers from the analysis, which can lead to inaccurate or incomplete recommendations if the label was applied inconsistently or only to a subset of containers.\nAlgorithmsWhen you define the report, you can choose from these algorithms to determine how CPU and memory usage data is interpreted to generate rightsizing recommendations:\nAvg - Savings Focused: Calculates the average CPU and memory usage over the selected time window. This approach tends to recommend lower resource requests, focusing on potential savings.\nMax - Reliability Optimized: Uses the maximum CPU and memory usage observed during the time window. This is best when you want to avoid throttling or OOM (Out of Memory) risks, ensuring enough headroom for peak usage.\nP95 - Balanced: Uses the 95th percentile of CPU and memory usage, excluding the top 5% of usage spikes. This provides a balance between cost efficiency and reliability.\nTime WindowThe selected time window determines the range of usage data considered by the algorithm. For example, if you choose a 1-week window with the Max algorithm, the recommendation will reflect the highest resource usage seen in that week for each workload.\nReport FieldsNumber of Pods: The total number of Pods, including those in ReplicaSets, Deployments, DaemonSets, and StatefulSets, that contain the container associated with this recommendation.\nMonthly Cost: An estimate of the workload\u0026rsquo;s current monthly cost, based on its daily cost multiplied by 30.\nMonthly Potential Savings: The estimated monthly savings if the workload is rightsized based on the suggested values. This can be negative if the workload is currently underprovisioned.\nSuggested CPU (m): The recommended CPU request in millicores (1 CPU = 1000m).\nSuggested Memory (Mi):The recommended memory request in mebibytes (1 Mi = 1,048,576 bytes)\nDownload ReportsTo download a report as a CSV or JSON, depending on the Report\u0026rsquo;s configuration:\nLog in to Sysdig Monitor and select Costs \u0026gt; Reports.\nThe Reports page appears.\nOptional: To download the latest report, select the download icon on a Report listing.\nSelect the report from the list.\nThe detail panel opens with a full list of generated reports.\nIdentify the report you want, and click Download.\nDisable or Enable a ReportOnce you create a report, it will generate according to the schedule you configured. To disable a scheduled Report:\nLog in to Sysdig Monitor.\nNavigate to Costs \u0026gt; Reports.\nUnder the Enabled column, toggle the Report off.\nThe Report schedule is now disabled. To re-enable it, toggle it back on.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/cost-reports/"},{"id":627,"title":"Resource Ownership","content":" 1. Add Owner KeysOwner keys are used to identify the person or team that owns a resource. Sysdig scans your cloud tags or Kubernetes labels for these specific keys to determine ownership.\nNavigate to the Settings and Admin section and locate the Resource Ownership section. Locate the Owner Keys field: This is the first input box under the Configure section. Add a Key: Type the exact label or tag key you use in your environment (for example, dept\\_owner or business\\_unit). By default sysdig\\_owner will be searched for if you choose to add this label or tag to your resources. Finalize: Press enter after typing each key to turn it into a tag. Limit: You can specify up to 10 different keys. Add Ticket Assignee KeysTicket Assignee keys are used to identify the specific individual or email address that should be assigned a ticket in your integrated ticketing system (like Jira).\nNavigate to the Settings and Admin section and locate the Resource Ownership section. Locate the Ticket Assignee Keys field: This is the second input box in the Configure section. Add a Key: Type the key that maps to your ticketing assignee metadata. Sysdig\\_ticket\\_assignee will be searched for by default if you choose to add this label or tag to your resources. Sysdig recommends that you specify a distinct email address that matches a user within your Jira organization. Finalize: Save the tag. Limit: You have a maximum of 10 slots. Once you add or remove keys, click the Save button in the top right corner of the screen to apply your changes.\n","url":"https://docs.sysdig.com/en/administration/resource-ownership/"},{"id":628,"title":"Response Actions","content":"PrerequisitesTo perform Response Actions, you need:\nA role with Response Actions permissions. Contained by default in Admin, Advanced User, and Team Manager. See Role management. The required permissions are: Containment Response Actions: READ, EXEC. Data Gathering Response Actions: READ, EXEC. For Host and Kubernetes Response Actions, Sysdig Shield must be installed and configured. For more installation instructions, see: Install Shield on Linux Nodes Install Shield as a Container Install Shield as Package For Cloud Response Actions, you must enable Threat Response in your connected account(s). These actions are currently available on AWS Cloud only. Refer to the documentation to learn more about it ConfigurationTo enable or disable Response Actions you can modify the dedicated flags.\nSysdig Shield Shield Chart (Kubernetes), in values.yaml Shield Chart (Linux Host) as a container, in ADDITIONAL_CONF environment variable Host Shield (Linux Host) as a package, in dragent.yaml features: respond: response_actions: # Enable Response Actions enabled: true/false On the Shield Chart (Kubernetes), alternatively, as a Helm command argument:\n--set features.respond.response_actions.enabled=true/false Each action can be customized individually. The following sections address the available actions along with their specific configuration. Overall, it\u0026rsquo;s also possible to disable them selectively:\nfeatures: respond: response_actions: \u0026lt;action_name\u0026gt;: trigger: NONE # Set this to disable the action. Default: ALL Along with the action being deactivated, if the Shield is installed through the Chart-based installation, the permissions and facilities for the action will not be provisioned, following the principle of least privilege.\nAdditional global configurations:\nParameter Description Default docker.socket_path File paths that Sysdig checks for the Docker/Podman socket [\u0026quot;/var/run/docker.sock\u0026quot;, \u0026quot;/run/podman/podman.sock\u0026quot;, \u0026quot;/run/*/*/podman/podman.sock\u0026quot;] cri.socket_path File paths that Sysdig checks for the CRI socket for Containerd/CRI-O [\u0026quot;/run/**/containerd.sock\u0026quot;, \u0026quot;/var/run/**/containerd.sock\u0026quot;, \u0026quot;/run/**/dockershim.sock\u0026quot;, \u0026quot;/var/run/**/dockershim.sock\u0026quot;, \u0026quot;/run/**/crio.sock\u0026quot;, \u0026quot;/var/run/**/crio.sock\u0026quot;] Cloud Response ActionsYou can configure Cloud Response Actions during their setup. Cloud Response Actions are currently available only in AWS. Refer to the setup documentation for further details.\nExecute a Response ActionTo execute a response action from an event in the Events feed:\nLog in to Sysdig Secure.\nSelect Threats \u0026gt; Activity | Events.\nOpen an event happening on a Kubernetes, Host or Container workload.\nSelect Respond.\nOptional: Select Ask for Response Advice to open Sysdig Sage. Sage will suggest remediation actions based on your current context. If a response action is available for you on that host, select Run Response Action to see the actions available for that context, as well as the last executed action, if any.\nAfter you select an action, you can review the parameters.\nTo execute the action, select Run Action.\nAfter the action executes, a message appears reporting the status and, in case of an error, the reason.\nAvailable Response ActionsContainer Kill Type Containment Reverse Action N/A Requirements Agent version 13.9 or higher The Container Kill action instantly terminates the container, along with all of its process, without waiting for them to shut down. This can stop a malicious activity quickly, but can result in data loss (in stateful applications) and service disruption. It is the best choice for containing severe and urgent threats.\nIf the container is orchestrated with Kubernetes, the control plane will typically attempt to restart the container based on its configuration.\nDrawbacks: Any possible forensic data will be lost. Possible service disruption, in cases where there\u0026rsquo;s no container orchestration or it\u0026rsquo;s not working as expected.\nContainer Stop Type Containment Reverse Action Container Start Requirements Agent version 13.9 or higher Container Stop gracefully terminates the container with its processes, deleting the memory state and the file system upper layer. It\u0026rsquo;s best for stateful applications.\nIf the container is orchestrated with Kubernetes and it has a liveness probe defined, the control plane will restart the pod as soon as the liveness probe fails. If no liveness probe is defined, Kubernetes will restart the container based on the restartPolicy. By default, the behavior is to restart terminated containers. In case of Kubernetes environments, this action cannot be reverted, i.e. containers cannot be restarted directly.\nOn non-orchestrated environments, or when the control plane doesn\u0026rsquo;t restart the container, you can start the container again from Sysdig. Follow the steps in the Revert a Response Action section to understand how to do it.\nDrawbacks: Possible service disruption, in cases where there\u0026rsquo;s no container orchestration or it\u0026rsquo;s not working as expected.\nContainer Pause Type Containment Reverse Action Container Unpause Requirements Agent version 13.9 or higher Container Pause suspends the execution of a container, freezing its processes and preserving its runtime state. The container memory state and disk state are maintained. This is ideal for forensic analysis and limiting disruption, but may result in higher resource consumption and prolonged risk due to lack of resolution.\nIf the container is orchestrated with Kubernetes and the pod\u0026rsquo;s liveness probe will start failing, it will be restarted, making this have the same effect of a Container Stop action.\nIn other cases, the execution will be temporarily stopped until further actions are taken. You can start the container again by reverting the action\nDrawbacks: Possible service disruption, in cases where there\u0026rsquo;s no container orchestration or it\u0026rsquo;s not working as expected.\nProcess Kill Type Containment Reverse Action N/A Requirements Agent version 13.9 or higher The Process Kill action sends a SIGKILL signal to the process, causing it to terminate instantly.\nWhen you execute this action from an event, you can decide to kill the process that originated the event itself or any of the processes in its ancestor line.\nDrawbacks: Possible service disruption, when the process is in charge of executing business critical applications without orchestrations/watchdog mechanisms.\nFile Quarantine Type Containment Reverse Action File Restore Requirements Agent version 13.9 or higher Write permissions on the target file and the sandbox folder File Quarantine is a Response Action you can use to isolate a suspicious or vulnerable file, so that it cannot be executed and can be accessed later for further investigations.\nThis action compresses the file, to make it non-executable, and moves it inside a quarantine folder. Optional: To change the default quarantine folder, see Configure File Quarantine.\nAs an example, this action can be useful if you see an Event warning you about a process receiving an unexpected connection. You can use the File Quarantine action to move the executable elsewhere and make it non-executable. Later, you can inspect the file in its safe new location.\nThis action can be reverted, moving the file back to its original location. To do this, see Revert a Response Action.\nDrawbacks: If the action is performed on a business critical application executable, this can cause possible service disruptions.\nConfigure File QuarantineIn order to perform the File Quarantine action, Sysdig needs write access to the source file and the quarantine folder. You can customize the quarantine folder path by editing the configuration:\nfeatures: respond: response_actions: file_quarantine: quarantine_path: \u0026#34;/var/lib/sysdig/quarantine\u0026#34; Alternatively, you can grant the write permission on that folder.\nWith regards to the source file, Sysdig permissions change based on the different Shield setup:\nShield chart: Sysdig has full write access to the root file system when Response Actions is enabled Package setup: The Shield package defines systemd directives required to apply the principle of least privilege. This means that, by default, some files cannot be quarantined. This behavior can be customized. Learn how in the next section. Parameter Description Default file_quarantine.max_file_size_mb Maximum file size that Sysdig is allowed to quarantine (in MB) 50 file_quarantine.quarantine_path Quarantine folder path, where quarantined files are moved into /var/lib/sysdig/quarantine Linux package Host Shield - customize read only pathBy default, the Linux Host agent is not allowed to write in the following folders:\n/home /root /run/user /usr /boot /efi /etc This configuration is managed using systemd\u0026rsquo;s Unit configuration:\nProtectHome=read-only ProtectSystem=full ProtectHome manages the access to /home, /root and /run/user. ProtectSystem manages the access to /usr, /boot, /efi and /etc. To perform File Quarantine on files in those directories, the agent needs write permission.\nTo grant the agent write permission to these folders:\nEdit the dragent configuration by writing this command on your terminal: sudo systemctl edit dragent.\nAn editable file to configure the dragent systemd configuration appears.\nDefine or edit the ProtectHome and ProtectSystem directives. To grant the agent full write permissions, change them to:\n[Service] ProtectHome=no ProtectSystem=no Run the following commands to restart the agent and systemd: sudo systemctl daemon-reexec sudo systemctl restart dragent Troubleshoot File QuarantineIf you receive an error message, such as failed to remove quarantined file or file system mounted as read-only, the file may be in a folder the agent does not have permission to perform write actions in. The File Quarantine action requires write permissions on the target file and on the quarantine folder path.\nVerify the instructions for customizing the quarantine folder path and the write permissions in the Configuration section\nFile Acquire Type Data Gathering Reverse Action N/A Requirements Agent version 13.9 or higher Custom Storage configured The File Acquire action allows you to fetch a file from a workload. This can be useful to:\nDownload suspicious executable files for further examining them Access log files to analyze the system activities and trace user actions Check for modifications performed by actors to understand if they are malicious Drawbacks: whoever is entitled to execute this action will be able to pull data from workloads, if the Sysdig agent has such a permissions.\nConfigure File AcquireIn order to acquire a file, you need to setup a Custom Storage, where the file is uploaded from the workload. See how to do it in the S3 Capture Storage page.\nFile Acquire also supports limiting the maximum file size to acquire, to avoid excessive resource usage.\nParameter Description Default file_acquire.max_file_size_mb Maximum file size that Sysdig is allowed to acquire (in MB) 50 Download an acquired fileOnce you terminate a File Acquire action with success, you will see the execution in the Response History. In the case of successful File Acquire actions, you will also be able to download the file from the context menu or from the execution details.\nNetwork Isolate Type Containment Reverse Action Unblock Connection Requirements Cluster Shield version 1.14 or higher. The Network Isolate action allows you to block incoming or outgoing connections to or from a Kubernetes workload. This action relies on Kubernetes Network Policies to:\nDeny data exfiltration to malicious IPs. Block the download of malware or any unwanted payload. Prevent malicious actors from connecting to the workload. Starting from the information available in the event you\u0026rsquo;re initiating the Response Action from, you can decide to deploy broader or narrower rules, targeting the transport protocol, remote IP address and server port specific to the event, or be broader applying, applying a catch-all rule.\nThis action can be performed on DaemonSets, Deployments, Jobs, ReplicaSets, StatefulSets.\nDrawbacks: Possible service disruption if you block a connection used for business-critical functionalities.\nDelete Pod Type Containment Reverse Action N/A Requirements Cluster Shield version 1.14.0 or higher. Delete Pod can be used to stop an ongoing attack or, more generally, to clean up compromised containers in a Kubernetes environment.\nKubernetes will try to replace the deleted pod if it\u0026rsquo;s managed by a controller, such as a ReplicaSet (Deployment), DaemonSet, StatefulSet, Job/CronJob.\nDrawbacks: Standalone Pods (not managed by a controller) will not be recreated after deletion. There might also be other factors preventing a pod from re-spawning, like image pull errors, or other constraints leaving the pod in Pending state.\nRollout Restart Type Containment Reverse Action N/A Requirements Cluster Shield version 1.14.0 or higher. Rollout Restart asks Kubernetes to delete all the pods of a workload and start from a clean slate. Like the Delete Pod action, you can use Rollout Restart to stop an attack when workloads are compromised.\nThe action is available on Deployments, StatefulSets and DaemonSets.\nDrawbacks: As in Delete Pod, pods might have issues re-starting. This can be caused by image pull errors, or other constraints leaving the pod in Pending state.\nGet Kubernetes Logs Type Data Gathering Reverse Action N/A Requirements Cluster Shield version 1.14.0 or higher. Custom Storage configured The Get Kubernetes Logs action allows you to obtain the logs from a workload or a pod. These logs can provide more information about behaviors observed in the workload and reveal whether a particular operation was expected or not. This helps you to distinguish real attacks from expected misbehaviors and false positives.\nThe action is available on DaemonSets, Deployments, Jobs, ReplicaSets and StatefulSets.\nDrawbacks: If sensitive data is present in Kubernetes logs, using the Get Kubernetes Logs action will move this to your storage, where it will be accessible through Sysdig.\nConfigure Kubernetes LogsTo fetch the Kubernetes logs, you need to setup a Custom Storage, where Sysdig stores the logs. See how to do it in the S3 Capture Storage page.\nDownload the logsAs soon as the logs are collected, you will see the execution in the Response History. If that is successful, you will also be able to download the log file from the context menu or from the execution details.\nVolume Snapshot Type Data Gathering Reverse Action Delete Snapshot Requirements Cluster Shield version 1.14.0 or higher. Volume Snapshot lets you capture a point-in-time backup of a Persistent Volume (PV). You can use this to analyze the volume content without disrupting normal workload operations.\nThe action executes on a Persistent Volume Claim (PVC), asking the Control Plane to perform the snapshot. Alternatively, you can provide a workload reference. In this case, if the workload has exactly 1 PVC, Sysdig will take the snapshot of that Volume. In case of multiple PVCs, the action will fail, allowing you to specify the PVC afterwards. The supported workloads are DaemonSets, Deployments, Jobs, ReplicaSets and StatefulSets.\nVerify the requirements to create a Volume Snapshot in your Kubernetes distribution, like defining a VolumeSnapshotClass or configuring a Snapshot Controller.\nDrawbacks: This operation relies on the underlying Container Storage Interface (CSI). Each CSI operates differently, therefore this action can show different behaviors based on that, like taking very long or resulting in different types of errors.\nEBS Volume Snapshot Type Data Gathering Reverse Action Delete Snapshot Requirements AWS Cloud Response Actions 1.0.0 Volume Snapshot lets you capture a point-in-time backup of the EBS Volumes attached to an EC2 Instance. You can use this to analyze the volume content without disrupting normal workload operations.\nThe action takes a snapshot of all the EBS volumes attached to the specified EC2 instance.\nDrawbacks: The number of parallel snapshots per-region per-account is limited, so abusing this might interfere with other functionalities like Volume Scanning (and vice-versa). This only works with EBS storages, i.e. no Object, Local or Network storages.\nFetch Cloud Logs Type Data Gathering Reverse Action N/A Requirements AWS Cloud Response Actions 1.0.0 Custom Storage configured The Fetch Cloud Logs action allows you to query Cloudtrail logs. These logs can provide more information about behaviors observed in the cloud account and reveal whether a particular operation was expected or not. This helps you to distinguish real attacks from expected misbehaviors and false positives.\nDrawbacks: If the query is too broad or there is a lot of activity in the cloud environment, fetching the logs might take considerable time, consume a lot of storage space and be very hard to read through. The execution duration is limited to 5 minutes.\nConfigure Fetch Cloud LogsTo Fetch Cloud Logs, you need to setup a Custom Storage, where Sysdig stores the logs. See how to do it in the S3 Capture Storage page.\nDownload the logsAs soon as the logs are collected, you will see the execution in the Response History. If that is successful, you will also be able to download the log file from the context menu or from the execution details.\nRemove Public Access Type Containment Reverse Action Restore public access Requirements AWS Cloud Response Actions 1.0.0 The Remove public access action allows you to ensure that S3 Buckets and RDS instances are not erroneously made public.\nDrawbacks: Possible service disruption if you remove an access used for business-critical functionalities.\nIAM Quarantine Type Containment Reverse Action IAM Unquarantine Requirements AWS Cloud Response Actions 1.0.0 The IAM quarantine action allows blocking the access to a compromised User or Role, by attaching a \u0026ldquo;Deny All\u0026rdquo; policy to them.\nDrawbacks: Possible service disruption if you block a IAM used for business-critical functionalities.\nSee Previous ExecutionsYou can review all past response action executions from the Response History page. The page lets you see all response action executed across your environment, with filters for action type, status, cluster, and more. See the dedicated page for additional information.\nIf you\u0026rsquo;re instead interested in knowing which actions where taken in the context of an Event, you can check the Response History tab in the Event panel.\nLog in to Sysdig Secure.\nSelect Threats \u0026gt; Activity | Events.\nOpen an event happening on a Kubernetes, Host or Container workload.\nThe Event Details panel appears.\nIn the Response History section, you can see response actions previously taken in that context. For example, container actions targeting the same host or cluster. Each row in the section represents an execution request sent to the agent.\nThe actions displayed are limited by the time frame currently applied to the Events page. See Change Time Span to expand or reduce it.\nBy using the \u0026ldquo;View Detail\u0026rdquo; contextual action, you can see the action parameters:\nMetadata, containing the execution status and the execution timestamp Inputs, showing the action target information Configuration, having details about the setup when that action was run Revert a Response ActionWhen you\u0026rsquo;re looking at the execution of a Response Action that can be reverted in the Response History, you will see the possibility to execute the reciprocal revert action from the context menu in the Response History and from the execution details.\nFrom the Response History:\nFrom the execution details:\nOnce you select that, you will be prompted to review the parameters, like with normal executions.\nUpon submission, the revert action will trigger, trying to revert the previous action execution.\nYou will be able to see the outcome of that action and the details as for any other action.\n","url":"https://docs.sysdig.com/en/sysdig-secure/response-actions/"},{"id":629,"title":"Review Scan Results","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nThere are different ways to access scan results:\nExternally (for developers): From an external Continuous Integration (CI) tool such as Jenkins.\nInternally (for security personnel): From the Runtime tab or the Scan Results tab (formerly titled \u0026ldquo;Repositories\u0026rdquo;) in the Image Scanning module of Sysdig Secure.\nNOTE: Images containing RPM packages with SHA512 hashes are not supported.\nScan Results Landing PageOnce a scan has been run, choose Image Scanning \u0026gt; Scan Results to see the landing page.\nFrom here you can:\nCheck quick-view charts for at-a-glance summaries of:\nNumber of images scanned\nPass/fail status\nOrigins of image feeds\nSearch and filter results, by:\nKeyword\nPass/fail status\nOrigin (drop-down menu)\nRegistry (drop-down menu)\nSave or Reset a search from the three-dots menu to the right of the nav bar.\nSort the results list by date.\nSelect an Image to see its Summary page.\nSummary ViewSelect Image Scanning \u0026gt; Scan Results and select an Image to land on the results summary.\nOn the Summary page you can:\nReview results of vulnerability matching and policy evaluations in two separate sections\nCheck the date and time of the vulnerability match and the most recent policy evaluation. These usually differ.\nExpand/collapse the policy breakdown for ease of view and removal of visual clutter\nClick Reevaluate Policies to trigger new policy results.\nDownload results as a PDF, including all the policy and vulnerability details.\nSelect detail pages from the left navigation to see detail views.\nRuntime ViewRuntime provides an always-updated report on images that have been running in your environment over the past 1 hour.\nIn the left column: view the Entire Infrastructure or drill down to a namespace.\nIn the Image Overview: See the percentage of Unscanned, Failed, and Passed images and click on each to get the relevant filtered list.\nUse the Search bar: To find images based on Registry, Image Name, or Tag.\nYou can drill down to the scan result details.\nUnscanned ImagesSelect an unscanned image to manually trigger a scan.\nScanned ImagesSelect a scanned image to drill down into the details: a Summary page, Policy details, Vulnerability details, and Content violations (e.g., licenses).\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/review-scan-results/"},{"id":630,"title":"Service Identities","content":" Deprecation Notice Upcoming Changes to Sysdig Product Line\nThe legacy Identity pages are now deprecated and will be phased out over a transition period. During this time, both the legacy and new experiences will remain available. We encourage you to start using the new Identity Overview and Findings pages to become familiar with the updated experience.\nFilter and Sort Service IdentitiesUse the sortable columns to organize and filter service accounts for assessing identity risks. You can sort service accounts based on the following criteria:\nUnused Permission CriticalityUnused Permission Criticality focuses on unused permissions, while Permission Criticality looks at all permissions. It is designed to help you achieve Least Permissive access.\nValues: Critical, High, Medium, Low\nPermission CriticalityPermission criticality is derived from the threat research severities associated with each permission granted to this Service Principal through roles assigned to the Service Principal.\nValues: Critical, High, Medium, Low\nRiskThis is a calculation of risk based on all permissions. See Understanding Risk Scoring for more information.\nValues: Critical, High, Medium, Low\n% of Unused PermissionsThis shows the number of unused permissions per total permissions for the group, shown as a percentage graph.\nWhen remediating, immediately target the groups with the greatest exposure and refine them according to the suggestions.\nHighest AccessValues:\nAdmin: Admin access granted Write: Write access granted Read: Read access granted Empty Access: No permissions are granted at all See Understand Highest Access for more information.\nFindingsA finding in Cloud Infrastructure Entitlement Management (CIEM) indicates poor security hygiene, either due to misconfiguration or inadequate identity security practices.\nThe findings for GCP accounts focus on highly permissive Google IAM roles and key management.\nAdmin: Admin access granted Multiple Access Keys Active: Rotating access keys is safer than maintaining multiple active keys. Editor Role Applied: The GCP Editor role includes permissions to create and delete resources for most Google Cloud services. User-Managed Key: User-managed keys are less secure than Google-managed keys. Lateral Movement: Sysdig leverages findings from the GCP Recommender Insights API to detect when a Service Account can move laterally from one project to another due to the roles/permissions it is granted. Owner Role Applied: The GCP project owner role includes all Editor permissions plus many others. Available Filters Search: Free text search on terms in the resource name Unused Permission Criticalities: By severity Cloud Accounts: GCP cloud account name/number Access Categories: Admin, Write, Read, or Empty Access Findings: Admin , `Multiple Access Keys Active, Editor Role Applied, User Managed Key, Lateral Movement, Owner Role Applied ","url":"https://docs.sysdig.com/en/sysdig-secure/service-accounts/"},{"id":631,"title":"Service Limits","content":"Alerts Resource Limit Description Daily Notifications per Alert 2000 The daily total number of triggering Alert Notifications for a single alert. Segments per Alert 10,000 The total number of segments returned in a single alert query. For example, configuring an alert on (container_memory_usage_bytes) by (container) will result in deactivation of the alert if there are more than 10,000 containers returned by this query. Deactivated AlertsThe alerts that exceed service limits will result in alert deactivation. Alerts that are deactivated will be disabled by Sysdig and no longer evaluated until the user manually re-enables the alert. If usage thresholds continue to be exceeded, the alert will again be deactivated.\nSegmentation LimitThe total number of entities that are returned when grouping a metric by one or more labels.\nDiscover Deactivated AlertsWhen an alert is deactivated, all triggering alert events associated with the alert are also deactivated. An email notification containing the deactivation reason and a link to the deactivated alert is sent to all admin users and team managers.\nDeactivated Alerts appear on the Alerts page in the summary widget. Additionally, a Sysdig Event is created whenever an alert is deactivated.\n​ Fix Alert DeactivationsDeactivated due to the daily notification limit Refine the alert scope and segmentation before re-enabling the alert. Intentional and significant changes in the infrastructure can also cause large numbers of alerts to trigger. Check the infrastructure before re-enabling the alert. If Alert is deactivated due to segmentation limit Refine the alert scope. Reduce segmentation in alert configuration. Intentional and significant changes in the infrastructure can also cause large numbers of alerts to trigger. Check the infrastructure before re-enabling the alert. ","url":"https://docs.sysdig.com/en/sysdig-monitor/service-limits/"},{"id":632,"title":"Sysdig Platform Audit","content":"With Platform Audit, you can answer questions such as:\nWho deleted a policy? From where was a policy modified? Which modifications were made to a specific alert? Who added this user? When did we change the single sign-on (SSO) settings? The audit includes the following request methods against the Sysdig system:\nPUT POST DELETE PATCH GET Platform Audit logs are read-only, and cannot be edited.\nSysdig retains system audit data for 90 days. To retain Sysdig Secure platform audit data for longer, you can use Event Forwarding, to forward platform audit events to third-party tools, such as Mezmo. See Event Forwarding. You cannot forward Sysdig Monitor system audit data.\nUse the Platform Audit UIAccess the UITo access the Platform Audit in Sysdig Secure or Sysdig Monitor UI:\nLog in as an administrator.\nSelect Settings from the user menu in the bottom left corner.\nThe Settings \u0026amp; Admin page appears.\nUnder App Status \u0026amp; Audit, select Sysdig Platform Audit.\nUse the UIPlatform Audit lets you understand what was done on the Sysdig platform, when, and by whom.\nYou can create custom filters by typing in the filter box, or by choosing from the selection of operators shown in the UI.\nData can be filtered based on:\nUser Team Request Method Entity Type Origin IP By default, the Platform Audit UI page filters out READ statements through the filter requestMethod != GET. This is based on the assumption that you might be primarily interested in changes made on the platform with commands such as PUT, POST, DELETE, and PATCH. To view READ actions, click X to delete the requestMethod != GET filter.\nThe date range is given to the right of the filter bar. Select the dates to open up a calendar, where you can define a custom range. The date range can be a maximum of 14 days.\nUse the Platform Audit APIPrerequisitesEnsure you have the following information to hand:\nYour Sysdig Secure or Sysdig Monitor API token with administrator permissions. The correct URL for the region where your Sysdig SaaS platform is deployed. For example, https://app.sysdigcloud.com for AWS US-East. To find the correct URL for your region, see SaaS Regions and IP Ranges. The code of the Sysdig product you want to audit. Secure = SDS. Monitor = SDC. Commands Overview Command Description filter=source in (\u0026quot;auditTrail\u0026quot;) Informs the events feed API that you want to fetch auditTrail type of events. {{host}} Host of the region for which you want to fetch audit events. For example, https://app.sysdigcloud.com for AWS US-East. {{from}} (nanoseconds) Timestamp date range, for example, from=1648477226000000000\u0026amp;to=164934122600000000 {{to}} (nanoseconds) Timestamp date range, for example, from=1648477226000000000\u0026amp;to=164934122600000000 {{limit}} (integer) - The upper bound is 999. Defines how many events you will receive, and is used in combination with offset. For example, offset=100\u0026amp;limit=100 (skip first 100 and show next 100). {{offset}} (integer) Used when we implement paging; allows you to skip the first x events. For example, offset=100 will skip the first 100 events. {{token}} (string) - Sysdig Secure or Sysdig Monitor API token. API UsageGet All Audit Events Across the Product and ServicesFor Sysdig Secure\nGET {{host}}/api/v1/platformAuditEvents?from={{from}}\u0026amp;to={{to}}\u0026amp;limit={{limit}} X-Sysdig-Product: SDS Authorization: Bearer {{token}} For Sysdig Monitor\nGET {{host}}/api/v1/platformAuditEvents?from={{from}}\u0026amp;to={{to}}\u0026amp;limit={{limit}} X-Sysdig-Product: SDC Authorization: Bearer {{token}} Get Audit Events for a Specific EntityauditTrail.entityType is used if you want to list audit events only for a specific entity or list of entities. In this example, we want to fetch only auth audit events.\nX-Sysdig-Product:= SDS (Sysdig Secure) SDC (Sysdig Monitor)\nGET {{host}}/api/v1/platformAuditEvents?filter=auditTrail.entityType in (\u0026#34;auth\u0026#34;)\u0026amp;from={{from}}\u0026amp;to={{to}}\u0026amp;limit={{limit}} X-Sysdig-Product: SDS Authorization: Bearer {{token}} EntitiesSysdig Admin Endpoints Entity Used for billing_report Subscription billing report. customer Customers management. customer_metrics Customers metrics management. customer_signup Customer signup process. ondemand_usage Calculating on demand usage. trial_plan Trial plans management. usage_summary Usage summary. Sysdig Monitor and Sysdig PlatformSome entities are also used in Sysdig Secure but are served by Sysdig Monitor\nEntity Used for agent Agent operations. alert Alert management. alert_notification (Legacy) Alert notifications. alert_silencing_rule Alert Silencing Rules Management. alert_template_group Listing alert template groups. api_token User Profile to read and reset API token. application_user_settings Fetching some user app settings like firstTimeOnApp, userTrackingEnabled, and so on. auth Login/logout events. auth_settings Authentication settings. auth_sso SSO authentication events. aws_settings AWS settings to enable/disable CloudWatch Integration. benchmark Benchmark tests and results management. capture Capture management. cloud_subscription Cloud subscription management. customer_access_key Access keys management. API only. customer_agreement Agreements that customer can sign, for example, end-user license agreements (EULA). customer_settings User Profile to hide Access Key and Agent Installation page for non-admin users. dashboard Dashboard management. dashboard_template Fetching dashboard templates. datasource Listing metric data sources. datastream Configuring datastream. default_dashboard Fetching default dashboards. downtime Notification channel settings to temporarily disable alert events and mute all notifications. event Events management falco_list Create, read, update and delete (CRUD) operations related to lists (In the UI: Policies-\u0026gt;Falco Lists). falco_macro CRUD operations related to macros (In the UI: Policies-\u0026gt;Falco Macros). falco_rules_file CRUD operations for Falco-related files like default and custom rules files that create macros, lists and rules using yaml (on UI: Policies-\u0026gt;Rules Editor). file_storage_config File storage management. group_mapping Mapping identity provider (IdP) groups to Sysdig teams and roles. ibm_resource Fetching IBM resource instances. inactivity_settings Session expiration settings. integration Integrations. invoice Listing invoices. license Used to fetch on-prem licenses. login_banner The agreement that must be accepted before logging in. notification_channel Notification channel settings. offer Listing offers. onboarding Fetching onboarding data and updating steps. overview Fetching overviews. permission Permissions management. plan_settings Fetching plan settings. policy Secure policies management. policy_action Getting a list of actions corresponding to a policy type when you try to create/edit a policy (in the UI: Policies-\u0026gt;Runtime Policies-\u0026gt;Add or Edit existing policy). policy_descriptor Defining the scope in which to apply a policy type when creating/editing a policy CRUD operations related to lists (in the UI: Policies-\u0026gt;Runtime Policies-\u0026gt;Add or Edit existing policy). prometheus_rule Used to export alerts and alert notifications in a Prometheus API format. Also allows users to create/export Prometheus alerting/recording rules. provider Used in AWS settings for AWS Accounts management. restricted_token IBM restricted API token management role Role management. runtime_policy_rule CRUD operations related to runtime policy rules (on UI: Policies-\u0026gt;Rules Library). s3_settings Sysdig Storage settings. scanning_event Scanning events operations. secure_settings Secure settings management. service_account Service account management silencing_rule Silencing Rules Management. slack Slack integration setup. statement Listing statements. subscription Manafinf subscription. team Teams management. ui_user_settings Fetching some UI user settings. usage_report Listing usage reports. user Users Management and in User Profile to reset passwords. Sysdig Secure Entity Used for acceptance-edit Post, put and delete operations in Vulnerability Management (VM) in Risk Acceptance. acceptance-read Get operations in VM Risk Acceptance. acceptance-read-scanner Get operations in VM Risk Acceptance. account blackout cluster Used in VM Legacy for CREATE, READ, UPDATE and DELETE operations on clusters and heartbeat. compliance the Legacy Compliance module. csv customerOptOut dataSource download Downloading VM Reports. event Viewing an event. falco Viewing or modifying a Falco rule. feature forwarding_integration framework group health host internal kubernetesNetworking labels list Referring to a list of items in Falco Rules. macro Encapsulating small expressions for use in Falco Rules. networkSecurity Viewing or changing Network Security configurations and see how a KNP policy is generated. networkTopology Viewing the Network Security Topology. overview policy Create, read, update and delete (CRUD) operations related to runtime policies. policyTuner Viewing or editing exceptions. provider reader VM Reporting, as well as SNOW and EVE integrations. remediations report resource rule Used to view a Falco rule through the rules library, a runtime policy, or an event. schema secure-iac-acprovider CSPM. Not related to a user action. secure-iac-agenthandler Posture. Not related to a user action. secure-iac-cloudcollector CSPM. Not related to a user action. secure-iac-cloudengine Posture for reading cloud assets posture, creating cloud asset report, and reading remediation playbook. secure-iac-clusteranalysis Posture for reading host assets posture, creating host asset report, and reading remediation playbook. secure-iac-compliance Posture and Compliance for reading compliance results, creating compliance report, accepting posture risks, editing \\ revoking \\ reading posture risks, and adding compliance views to favorites. secure-iac-gitprovider reading git integration, creating git integration, and git source. secure-iac-inventory Inventory to read assets/resources details, compliance posture status, list resources, their connections, attributes and configuration. secure-iac-policy Posture, Compliance and Zones to read policies, controls, CRUD custom policies, CRUD custom controls, CRUD ACEnforcement, CRUD Zones. secure-iac-scheduler KSPM and CSPM scan tasks: read tasks, re-run task, re-schedule task. secure-iac-temporalworker CSPM. Not related to a user action. secure-iac-workload Reading Kubernetes assets posture, create Kubernetes asset report, read Kubernetes remediation playbook. session task ticketing user vm-collector-write CLI or other component sending a scan result to the collector. vm-policies-read Internal API to read VM policies. vm-policies-write Internal API to write VM policies. vm-riskacceptance-read-scanner GET operations in Accepted Risk. vm-riskacceptance-read-ui GET operations in Accepted Risk. vm-riskacceptance-write-ui POST, PUT and DELETE operations in Accepted Risk. writer VM Reporting configuration and EVE Integration data reception. The Infrastructure as Code (IAC) EntitiesThis list contains Infrastructure as Code (IAC) entities in Sysdig Secure:\nEntity Description secure-iac-cloudengine Used to read cloud assets posture, create cloud asset reports, and read remediation playbook. secure-iac-clusteranalysis Used to read hosts assets posture, create a host asset report, and read the remediation playbook. secure-iac-compliance Used to read compliance results, create compliance report, accept posture risks, edit, revoke, and read posture risks, as well as star favorite compliance views. secure-iac-gitprovider Used to read Git integration, create a Git integration, and Git source. secure-iac-inventory Used to read assets, resources details, compliance posture status, lists resources, their connections, attributes and configuration. secure-iac-policy Used to read policies, controls, create, read, update and delete (CRUD) operations on custom policies, CRUD operations on custom controls, CRUD operations on ACEnforcement, and CRUD operations on Zones. secure-iac-scheduler Kubernetes Security Posture Management (KSPM) and Cloud Security Posture Management (CSPM) scan tasks, such as read tasks, re-run tasks, and re-schedule tasks. secure-iac-workload Used to read Kubernetes assets posture, create Kubernetes asset report, and read Kubernetes remediation playbook. ","url":"https://docs.sysdig.com/en/administration/platform_audit/"},{"id":633,"title":"Troubleshooting On-Premises Installation","content":"Disable Proxy SettingsDuring upgrade, the Installer might attempt to import the old proxy settings. In such cases, ensure that you remove the existing proxy settings before the upgrade operations. To completely remove the existing proxy configuration:\nRemove the relevant entries from the values.yaml file. Use the --disable-proxy when running the installer commands, such as generate, diff, and deploy Collect Troubleshooting DataWhen experiencing issues, you can collect troubleshooting data that can help the support team. The data can be collected by hand, or Sysdig provides a very simple get_support_bundle.sh script that takes as an argument the namespace where Sysdig is deployed and will generate a tarball containing some information (mostly log files). The script is located in the GitHub repository.\n$ ./scripts/get_support_bundle.sh -n sysdigcloud Getting support logs for sysdigcloud-api-1477528018-4od59 Getting support logs for sysdigcloud-api-1477528018-ach89 Getting support logs for sysdigcloud-cassandra-2987866586-fgcm8 Getting support logs for sysdigcloud-collector-2526360198-e58uy Getting support logs for sysdigcloud-collector-2526360198-v1egg Getting support logs for sysdigcloud-mysql-2388886613-a8a12 Getting support logs for sysdigcloud-redis-1701952711-ezg8q Getting support logs for sysdigcloud-worker-1086626503-4cio9 Getting support logs for sysdigcloud-worker-1086626503-sdtrc Support bundle generated: 1473897425_sysdig_cloud_support_bundle.tgz Docker Connectivity Issues (IPv4/IPv6)Some issues with IPv4 and IPv6 interconnectivity between on-premises containers and the outside world have been detected.\nIP packet forwarding is governed by the ip_forward system parameter. Packets can only pass between containers if this parameter is 1. Usually, you will simply leave the Docker server at its default setting --ip-forward=true and Docker will go set ip_forward to 1 for you when the server starts up. If you set --ip-forward=false and your system\u0026rsquo;s kernel has it enabled, the --ip-forward=false option has no effect.\nTo check the setting on your kernel use:\nsysctl net.ipv4.conf.all.forwarding To turn it on use:\nsysctl net.ipv4.conf.all.forwarding=1 Please see this article from dockerfor more details on Docker Connectivity.\nProxy/Firewall IssuesPrior to installing ensure your proxy settings are valid for the session. You can use curl, lynx, or wget to test internet connectivity:\nexport http_proxy=\u0026#34;http://user:password@proxy_server:port\u0026#34; export https_proxy=\u0026#34;https://user:password@proxy_server:port\u0026#34; echo $http_proxy You can then attempt a curl or docker hub call to ensure outside connectivity.\nFirewallPrior to installation, you may want to disable local firewall (iptables) to rule out local connectivity issues.\nHowever here are some details around Sysdig connectivity and backend connectivity requirements.\nSysdig Connectivity:\n6443 Agent communication\n443 Sysdig Monitor UI access\n8800 Management console access\nHere are specifics around what is used for connectivity for the Sysdig backend for on-premises solution:\nhttps://www.replicated.com/docs/kb/supporting-your-customers/firewalls/\nFile Write Permissions Issues (SELINUX or APP ARMOR)During the install, you may see errors writing to volumes such as (/var or /opt) from either the onprem install scripts or Docker. You should disable SELINUX (CENTOS/RHEL) or Apparmor (UBUNTU/DEBIAN) during the course of the install so the valid directories can be created. This can be accomplished by:\nCentos (SELINUX)\nFrom the command line, edit the /etc/sysconfig/selinux file. This file is a symlink to /etc/selinux/config. The configuration file is self-explanatory. Changing the value of SELINUX or *SELINUXTYPE*changes the state of SELinux and the name of the policy to be used the next time the system boots.\n[root@host2a ~]# cat /etc/sysconfig/selinux # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=permissive # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted # SETLOCALDEFS= Check local definition changes SETLOCALDEFS=0 See SELinux Modes for more information.\nUBUNTU/Debian (AppArmor)\nAppArmor can be disabled, and the kernel module unloaded by entering the following:\nsudo systemctl stop apparmor.service sudo update-rc.d -f apparmor remove To re-enable AppArmor enter:\nsudo systemctl start apparmor.service sudo update-rc.d apparmor defaults Advanced Troubleshooting - Firewall, IPtables, IP forwardingIn the preflight check step with Replicated, if you come across the error:\ngetsockopt: no route to host Please do the following:\nFor CentOS 7/RedHat:\nLog in as root or run these commands via sudo:\nservice firewalld stop systemctl disable firewalld sysctl -w net.ipv4.ip_forward=1 iptables -F setenforce 0 service docker restart For Ubuntu:\nLog in as root or run these commands via sudo:\nsysctl -w net.ipv4.ip_forward=1 systemctl stop apparmor.service update-rc.d -f apparmor remove ufw disable iptables -F service docker restart Learn MoreSee Get Help | Using Sysdig Support (On-Prem).\n","url":"https://docs.sysdig.com/en/administration/troubleshoot-onprem-installation/"},{"id":634,"title":"Upgrade Agents for Monitor","content":" Follow the upgrade best practices for a smooth upgrade and to maximize the value of Sysdig applications:\nKeep upgrades current\nUpgrade progressively without skipping versions\nTest upgrades in a non-mission-critical or staging environment before rolling in to production.\nThis section describes how to check the current version of the installed agents, and then how to upgrade them.\nAgent Version CheckKubernetes installationIf the agent is installed in a Kubernetes environment, run:\nkubectl get pods -n sysdig-agent -l=app=sysdig-agent -o=jsonpath=\u0026#39;{.items[0].spec.containers[:1].image}\u0026#39; Container InstallationIf the agent is installed as container, run:\ndocker exec sysdig-agent /opt/draios/bin/dragent --version Package InstallationIf the agent is installed as a service, run:\n/opt/draios/bin/dragent --version You can also find the agent version in the agent log file,/opt/draios/logs/draios.log.\nLook for the Agent starting message, which is logged whenever the agent restarts.\nUpdate AgentUpdate the containerized agent version as you normally update any container; the basic steps are given below.\nUse the full run command as shown in the Agent Installation Wizard of your account.\nContainerized AgentSee tags for the available agent versions.\nKubernetesHelm Update the chart:\nhelm repo update Do one of the following:\nIf you have deployed the chart with a values.yaml file, modify or add (if it’s missing) the agent.image.tag field and run:\nhelm upgrade --namespace sysdig-agent sysdig-agent -f values.yaml sysdig/sysdig-deploy If you have deployed the chart by setting the values as CLI parameters, run:\nhelm upgrade --namespace sysdig-agent --set agent.image.tag=\u0026lt;latest_version\u0026gt; --reuse-values sysdig-agent sysdig/sysdig-deploy Replace \u0026lt;latest_version\u0026gt; with the latest version number of Sysdig Agent.\nFor more information on using Helm, see Helm Charts.\nManual Check whether .yaml files must be updated.\nUpdating the agent image does not overwrite the daemonset.yaml and sysdig-agent-configmap.yaml on your local system. Check the Sysdig Agent Release Notes to see if you need to download the latest .yaml files from the Agent repository.\nPerform the update:\nkubectl set image ds/sysdig-agent sysdig-agent=quay.io/sysdig/agent:\u0026lt;tag\u0026gt; -n sysdig-agent Watch update status:\nkubectl rollout status ds/sysdig-agent -n sysdig-agent DockerTo upgrade, stop the agent, remove it, pull the new agent, and install it.\nYou can also find the installation command in the Sysdig Agent Installation Wizard.\ndocker stop sysdig-agent docker rm sysdig-agent docker pull sysdig/agent docker run PackageFor service (non-containerized) agent installations, updates are installed as part of the normal system upgrade available with apt-get or yum.\nStarting with agent version 13.1.0, separate packages will have to be installed depending on the driver to be used. Please refer to Package Reference.\nDebian, Ubuntuapt-get update apt-get -y install draios-agent CentOS, RHEL, Fedora, Amazon AMI, Amazon Linux 2yum clean expire-cache yum -y install draios-agent Restart the agentAfter the upgrade, you will need to manually restart the agent\nsystemctl restart dragent Verify UpgradeTo verify the upgrade,\nLog in to Sysdig Monitor.\nSelect Integrations \u0026gt; Data Sources \u0026gt; Sysdig Agents .\nOn the Sysdig Agents page, check if the upgraded agent version is listed.\nYou can use this page to determine which agent is up-to-date, out of date, or approaching being out of date.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/upgrade-agents/"},{"id":635,"title":"Upgrade On-Premises License","content":" After a license expires, there is a 14 day grace period before the agents disconnect. Make sure to renew the license to avoid any disruption.\nPrerequisitesWhen you upgrade, whether manually or with the update-license command, ensure you update your values.yaml with the new license to prevent redeploying the Sysdig application with an old license in the future.\nIf you don\u0026rsquo;t update values.yaml and run the installer next time, say for an upgrade, the application will be redeployed with the old license.\nMake sure that all the records you hold are updated with the latest license to prevent any license mismatch.\nVersion 7.x.x or 6.x.xAutomatic Upgrade Do one of the following options.\nPass the license from a file: installer update-license --license-file license.txt --namespace \u0026lt;YOUR-NAMESPACE\u0026gt; Pass the license as a string: installer update-license --license \u0026lt;license-string\u0026gt; --namespace \u0026lt;YOUR-NAMESPACE\u0026gt; Replace \u0026lt;YOUR-NAMESPACE\u0026gt; with the namespace where your Sysdig application is installed.\nAutomatic Upgrade Using installer deployOptionally, you can use the installer deploy method explained in Automatic Upgrade in Version 5.x.x.\nManual Upgrade Update the license in all the applicable secrets:\nsysdigcloud-api-secret sysdigcloud-collector-secrets sysdigcloud-streamsnap-secret sysdigcloud-anchore-secret sysdigcloud-worker-secret (Optional) If scanning v2 engine is enabled, update the license in the following ConfigMaps:\nsysdigcloud-scanningv2-pkgmeta-api-config sysdigcloud-scanningv2-vulns-api-config Restart the applicable deployments:\nsysdigcloud-api\nsysdigcloud-collector\nsysdigcloud-streamsnap\nsysdigcloud-worker\nsysdigcloud-scanningv2-pkgmeta-api\nsysdigcloud-scanningv2-vulns-api\nsysdigcloud-anchore-core\nsysdigcloud-anchore-policy-engine\nsysdigcloud-anchore-api\nsysdigcloud-anchore-catalog\nFor example:\nkubectl rollout restart deployment \\ sysdigcloud-api \\ sysdigcloud-collector \\ sysdigcloud-worker \\ sysdigcloud-streamsnap \\ sysdigcloud-scanningv2-pkgmeta-api \\ sysdigcloud-scanningv2-vulns-api \\ sysdigcloud-anchore-core \\ sysdigcloud-anchore-policy-engine \\ sysdigcloud-anchore-api \\ sysdigcloud-anchore-catalog \\ -n sysdigcloud Version 5.x.xAutomatic UpgradeThe license file is simply entered as a configuration parameter in the values.yaml file. To apply the new license, update the values.yaml file with the new license, and run the installer.\nOpen the values.yaml file.\nSpecify your license as follows:\nsysdig: license: \u0026lt;replace_with_your_license\u0026gt; Run the following:\n./installer deploy Manual Upgrade Update the ConfigMap for sysdigcloud-config.\n# Required: Sysdig Cloud license sysdigcloud.license: \u0026#34;\u0026lt;replace_with_your_license\u0026gt;\u0026#34; Restart the Sysdig API, Worker, and Collector pods.\n(Optional) Restart the Anchore pods.\nFor example:\nkubectl rollout restart deployment \\ sysdigcloud-api \\ sysdigcloud-collector \\ sysdigcloud-worker \\ sysdigcloud-anchore-core \\ sysdigcloud-anchore-policy-engine \\ sysdigcloud-anchore-api \\ sysdigcloud-anchore-catalog \\ -n sysdigcloud Learn More On-Premises Installation System Requirements Authentication and Authorization ","url":"https://docs.sysdig.com/en/administration/upgrade-an-on-premises-license/"},{"id":636,"title":"Integrate with Visual Studio Code","content":"With Sysdig VS Code extension, you can:\nScan Dockerfiles, Docker-compose, and Kubernetes manifests. Uncover vulnerabilities within software packages. Scan Infrastructure as Code (IaC) projects Evaluate compliance with Sysdig’s Vulnerability Management (VM) policies. Detect vulnerabilities and misconfigurations in your Dockerfile references and codebase with Sysdig Language Server Protocol (LSP). This is available for SaaS users only. No additional configuration is required to use Sysdig LSP with the Sysdig VS Code extension. To access Sysdig LSP with other editors, such as Helix, Kate, and Vim, you must perform manual configuration. For details and instructions, see Sysdig LSP. Prerequisites Visual Studio Code (VS Code) installed.\nA Sysdig Secure account.\nA Sysdig Secure API token. See Retrieve the Sysdig API Token. A Sysdig Secure URL. See SaaS Regions and IP Ranges. Optional: Docker installed to use the Build and Scan action on Dockerfiles.\nSysdig SaaS: For Sysdig LSP support.\nLimitationsWhile the Sysdig extension offers powerful scanning capabilities, there are some limitations to be aware of:\nNon-concurrent scanning — Scans are performed sequentially, which might affect performance in large projects. No Multiple YAML support — The extension currently does not support scanning multiple Kubernetes or Docker-compose YAML files in a single run. ARG statements in Dockerfiles — Scanning does not currently resolve ARG statements (build arguments), which may limit the detection of vulnerabilities in certain scenarios. If you need ARGs to build, you can manually scan an image with the Image to Scan feature in Settings. See Configure Settings. The Sysdig VS Code extension is not available for Windows. Install the VS Code PluginTo install Sysdig Scanner, the Sysdig VS Code plugin:\nSearch for \u0026ldquo;Sysdig Scanner\u0026rdquo; in the VS Code Extension tab, or in the VS Code Marketplace.\nSelect Install.\nOnce installed, launch the Command Palette (⌘ +Shift+P on Mac and Ctrl+Shift+P on Linux).\nSearch Sysdig and select Authenticate with Sysdig Secure API Token.\nEnter your Sysdig Secure endpoint.\nSee Retrieve the Sysdig API Token.\nEnter your Sysdig Secure API Token.\nSee Retrieve the Sysdig API Token.\nClose and relaunch VS Code.\nThe extension is now linked to your Sysdig Secure account.\nUse Sysdig ScannerYou can use the Sysdig VS Code extension, also known as Sysdig Scanner as follows:\nOpen the Explorer tab in VS Code. In the bottom left, you will see Policy Evaluation and Vulnerabilities tabs. Select the Infos icons in the bottom left of your VSCode window to access the Problems tab.\nProblems are grouped into three severities: high, medium, and low.\nClick on an issue to view the corresponding file.\nUse the Command Palette (⌘ +Shift+P on Mac and Ctrl+Shift+P on Linux) to run commands with Sysdig Scanner, such as: Scan Workspace for Iac Files: Sysdig scans the entire workspace, including the Terraform and Kubernetes manifests, to list all misconfigurations associated with these files. This provides the necessary context needed by security teams to respond. Scan Image for Vulnerabilities Scan Kubernetes manifest for Vulnerabilities Scan Dockerfile for Vulnerabilities Scan Docker Compose manifest for Vulnerabilities As you edit files, you will also see prompts from Sysdig Scanner. For example, when you specify an image in a yaml file, you will see an unobtrusive prompt asking if you would like to Scan Image. Scan DockerfilesWhen you open a Dockerfile in VSCode, the Sysdig Scanner extension lets you:\nBuild and Scan: Build the entire Dockerfile and scan for vulnerabilities in the software packages used in the project through layered analysis. Scan Base Image: Look for security gaps within the base image. In both cases, a detailed report of all detected vulnerabilities is generated. These are categorized by severity. You can filter results by Exploitable and Fixable.\nConfigure SettingsChange the settings to customize the extension to your needs:\nOpen VSCode.\nSelect the Extensions tab.\nClick the settings icon beside Sysdig Scanner.\nSelect Extension Settings.\nThe Extension Settings page opens.\nHere you can configure:\nUser/Workspace: Select between the User and Workspace tab to configure settings globally for your user account, or for a specific workspace. This is useful for applying custom policies to a specific project. Cli Scanner Source: Specify a custom path to retrieve Sysdig CLI Scanner. Add Policies: By default, the extension applies Sysdig Secure managed VM policies. Use this setting to add custom policies. Detailed Reports: By default, the extension summarizes its findings in reports. Use this setting to generate more detailed reports. Filter Packages With No Vulnerabilities: By default, Sysdig filters out packages with no vulnerabilities in the Vulnerabilities view. Use this setting to include these packages. Image to Scan: Use the box to manually specify an image for Sysdig to scan. Standalone Mode: Standalone mode allows Sysdig Scanner to work in a limited capacity with a local Vulnerabilities Database, but without policies. By default, the Sysdig Scanner uses standalone mode when offline. You can set Sysdig Scanner to use Standalone Mode Always, Never, or When Disconnected (the default). Upload Results: Tick the box to upload scans to the Sysdig backend. This can be used to share scan results. The setting is off by default to reduce noise. ","url":"https://docs.sysdig.com/en/sysdig-secure/vscode-integration/"},{"id":637,"title":"(Legacy) Logging and Troubleshooting","content":"LoggingAfter the Agent begins scraping Prometheus metrics, there may be a delay of up to a few minutes before the metrics become visible in Sysdig Monitor. To help quickly confirm your configuration is correct, starting with Agent version 0.80.0, the following log line will appear in the Agent log the first time since starting that it has found and is successfully scraping at least one Prometheus exporter:\n2018-05-04 21:42:10.048, 8820, Information, 05-04 21:42:10.048324 Starting export of Prometheus metrics As this is an INFO level log message, it will appear in Agents using the default logging settings. To reveal even more detail,increase the Agent log level to DEBUG , which produces a message like the following that reveals the name of a specific metric first detected. You can then look for this metric to be visible in Sysdig Monitor shortly after.\n2018-05-04 21:50:46.068, 11212, Debug, 05-04 21:50:46.068141 First prometheus metrics since agent start: pid 9583: 5 metrics including: randomSummary.95percentile TroubleshootingIf you have enabled Prometheus and are not seeing the Starting export message shown there, revisit your configuration.\nIt is also suggested to leave the configuration option in its default setting of log_errors: true , which will reveal any issues scraping eligible processes in the Agent log.\nFor example, here is an error message for a failed scrape of a TCP port that was listening but not accepting HTTP requests:\n2017-10-13 22:00:12.076, 4984, Error, sdchecks[4987] Exception on running check prometheus.5000: Exception(\u0026#39;Timeout when hitting http://localhost:5000/metrics\u0026#39;,) 2017-10-13 22:00:12.076, 4984, Error, sdchecks, Traceback (most recent call last): 2017-10-13 22:00:12.076, 4984, Error, sdchecks, File \u0026#34;/opt/draios/lib/python/sdchecks.py\u0026#34;, line 246, in run 2017-10-13 22:00:12.076, 4984, Error, sdchecks, self.check_instance.check(self.instance_conf) 2017-10-13 22:00:12.076, 4984, Error, sdchecks, File \u0026#34;/opt/draios/lib/python/checks.d/prometheus.py\u0026#34;, line 44, in check 2017-10-13 22:00:12.076, 4984, Error, sdchecks, metrics = self.get_prometheus_metrics(query_url, timeout, \u0026#34;prometheus\u0026#34;) 2017-10-13 22:00:12.076, 4984, Error, sdchecks, File \u0026#34;/opt/draios/lib/python/checks.d/prometheus.py\u0026#34;, line 105, in get_prometheus_metrics 2017-10-13 22:00:12.077, 4984, Error, sdchecks, raise Exception(\u0026#34;Timeout when hitting %s\u0026#34; % url) 2017-10-13 22:00:12.077, 4984, Error, sdchecks, Exception: Timeout when hitting http://localhost:5000/metrics Here is an example error message for a failed scrape of a port that was responding to HTTP requests on the /metrics endpoint but not responding with valid Prometheus-format data. The invalid endpoint is responding as follows:\n# curl http://localhost:5002/metrics This ain\u0026#39;t no Prometheus metrics! And the corresponding error message in the Agent log, indicating no further scraping will be attempted after the initial failure:\n2017-10-13 22:03:05.081, 5216, Information, sdchecks[5219] Skip retries for Prometheus error: could not convert string to float: ain\u0026#39;t 2017-10-13 22:03:05.082, 5216, Error, sdchecks[5219] Exception on running check prometheus.5002: could not convert string to float: ain\u0026#39;t ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycollect-prometheus-metrics/logging-and-troubleshooting/"},{"id":638,"title":"Authentication and Authorization (On-Prem)","content":" This section is for the Sysdig On-Premises software platform only. If you are using SaaS (cloud-based) Sysdig applications, see Authentication and Authorization (SaaS) instead.\nType Enabled by Default Integration Steps Required User email/password Yes No Google OAuth No Yes SAML No Yes OpenID Connect No Yes LDAP No Yes The pages in this section describe the integration and enablement steps required for SAML or OpenID Connect, and the Identity Provider (IdP) services that support these protocols, such as Okta, OneLogin, and Keycloak.\nIn the SaaS environment, Google)login can be enabled with a simple drop-down selection; the integration has already been performed.\nTo enable a third-party authentication method for both Sysdig Monitor and Sysdig Secure, you must configure the SSO settings separately for each.\nWorkflowTo enable a Single Sign-On (SSO) option:\nDetermine which SSO option, such as GoogleOAuth, SAML, OpenID, or LDAP, your enterprise uses, and which IdP service, such as Okta or OneLogin, is used if any.\nConfigure any associated IdP settings on the IdP side.\nEnter the required connection settings for the chosen SSO on the appropriate Authentication tab in Sysdig Settings.\nYou can also configure the settings using a script, if preferred.\nSelect the SSO option from the Enabled Single Sign-On drop-down and click Save Authentication.\nIf enabling for both Sysdig Monitor and Sysdig Secure, perform the necessary steps on the second application.\nView of the Authentication page for SAML.\n","url":"https://docs.sysdig.com/en/administration/onprem-auth/"},{"id":639,"title":"Consul StatsD Metrics","content":"See Application Integrations for more information.\nconsul.memberlist.msg.suspectNumber of times an agent suspects another as failed while probing during gossip protocol.\nconsul.raft.applyNumber of raft transactions occurring.\nconsul.raft.commitTime.95percentileThe p95 time it takes to commit a new entry to the raft log on the leader.\nconsul.raft.commitTime.avgThe average time it takes to commit a new entry to the raft log on the leader.\nconsul.raft.commitTime.countThe number of samples of raft.commitTime\nconsul.raft.commitTime.maxThe max time it takes to commit a new entry to the raft log on the leader.\nconsul.raft.commitTime.medianThe median time it takes to commit a new entry to the raft log on the leader.\nconsul.raft.leader.dispatchLog.95percentileThe p95 time it takes for the leader to write log entries to disk.\nconsul.raft.leader.dispatchLog.avgThe average time it takes for the leader to write log entries to disk.\nconsul.raft.leader.dispatchLog.countThe number of samples of raft.leader.dispatchLog.\nconsul.raft.leader.dispatchLog.maxThe max time it takes for the leader to write log entries to disk.\nconsul.raft.leader.dispatchLog.medianThe median time it takes for the leader to write log entries to disk.\nconsul.raft.leader.lastContact.95percentileP95 time elapsed since the leader was last able to check its lease with followers.\nconsul.raft.leader.lastContact.avgAverage time elapsed since the leader was last able to check its lease with followers.\nconsul.raft.leader.lastContact.countThe number of samples of raft.leader.lastContact.\nconsul.raft.leader.lastContact.maxMax time elapsed since the leader was last able to check its lease with followers.\nconsul.raft.leader.lastContact.medianMedian time elapsed since the leader was last able to check its lease with followers.\nconsul.raft.state.candidateThe number of initiated leader elections.\nconsul.raft.state.leaderNumber of completed leader elections.\nconsul.runtime.alloc_bytesCurrent bytes allocated by the Consul process.\nconsul.runtime.free_countCumulative count of heap objects freed.\nconsul.runtime.heap_objectsNumber of objects allocated on the heap.\nconsul.runtime.malloc_countCumulative count of heap objects allocated.\nconsul.runtime.num_goroutinesNumber of running goroutines.\nconsul.runtime.sys_bytesTotal size of the virtual address space reserved by the Go runtime.\nconsul.runtime.total_gc_pause_nsCumulative nanoseconds in GC stop-the-world pauses since Consul started.\nconsul.runtime.total_gc_runsNumber of completed GC cycles.\nconsul.serf.eventsIncremented when an agent processes a serf event.\nconsul.serf.member.flapNumber of times an agent is marked dead and then quickly recovers.\nconsul.serf.member.joinIncremented when an agent processes a join event.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/consul-statsd-metrics/"},{"id":640,"title":"Deprecated Metrics and Labels","content":"If you encounter any issues, contact Sysdig Support.\nWe have applied automatic mapping of all net.*.request.time.worst metrics to net.*.request.time, because the maximum aggregation gives equivalent results and it was almost exclusively used in combination with these metrics.\nDeprecated MetricsThe following metrics are no longer supported.\nnet.request.time.file net.request.time.file.percent net.request.time.local net.request.time.local.percent net.request.time.net net.request.time.net.percent net.request.time.nextTiers net.request.time.nextTiers.percent net.request.time.processing net.request.time.processing.percent net.request.time.worst.in net.request.time.worst.out net.incomplete.connection.count.total net.http.request.time.worst net.mongodb.request.time.worst net.sql.request.time.worst net.link.clientServer.bytes net.link.delay.perRequest net.link.serverClient.bytes capacity.estimated.request.stolen.count capacity.estimated.request.total.count capacity.stolen.percent capacity.total.percent capacity.used.percent Deprecated LabelsThe following labels are no longer supported:\nnet.connection.client net.connection.client.pid net.connection.direction net.connection.endpoint.tcp net.connection.udp.inverted net.connection.errorCode net.connection.l4proto net.connection.server net.connection.server.pid net.connection.state net.role cloudProvider.resource.endPoint host.container.mappings host.ip.all host.ip.private host.ip.public host.server.port host.isClientServer host.isInstrumented host.isInternal host.procList.main proc.id proc.name.client proc.name.server program.environment program.usernames mesos_cluster mesos_node mesos_pid In addition to this list, the composite labels ending with \u0026lsquo;.label\u0026rsquo; string will no longer be supported. For example kubernetes.service.label will be deprecated, but kubernetes.service.label.* labels are supported.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/deprecated-metrics-and-labels/"},{"id":641,"title":"Disable Captures","content":"In such cases, you can disable Captures altogether by configuring the agent. See Configure the Agent.\nDisable Captures ManuallyTo disable captures through direct access of dragent.yaml:\nAccess dragent.yaml by using one of the options listed in Configure the Agent.\nSet the parameter:\nsysdig_capture_enabled: false Restart the agent, using the command:\nservice dragent restart Disable Captures via sysdig-deploy Helm ChartTo disable Captures via Helm, edit the boolean parameter disableCaptures in agent.sysdig:\nUse the following Helm configuration: agent: sysdig: disableCaptures: true Alternatively, use: --set agent.sysdig.disableCaptures=true ","url":"https://docs.sysdig.com/en/sysdig-secure/disable-captures/"},{"id":642,"title":"File","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nfile.bytes.inThe number of bytes read from the file. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max file.bytes.outThe number of bytes written to the file. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max file.bytes.totalThe total number of bytes written to, and read from, the file. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max file.error.open.countThe number of errors that occurred when opening files. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max file.error.total.countThe number of errors encountered by file system calls, such as open(), close(), and create(). By default, this metric displays the total value for the defined scope. For example, if the scope is defined as a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max file.iops.inThe number of file read operations per second. This metric is calculated by measuring the actual number of read requests made by a process. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nThe value of file.iops.in can differ from the value other tools show, as they are usually based on interpolating this value from the number of bytes read and written to the file system.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max file.iops.outThe number of file write operations per second. This metric is calculated by measuring the actual number of write requests made by a process. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nThe value of file.iops.out can differ from the value other tools show, as they are usually based on interpolating this value from the number of bytes read and written to the file system.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max file.iops.totalThe number of file read and write operations per second. This metric is calculated by measuring the actual number of read/write requests made by a process. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nThe value of file.iops.total can differ from the value other tools show, as they are usually based on interpolating this value from the number of bytes read and written to the file system.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max file.nameThe name of the file.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A file.open.countWhen segmenting by file name, the metric represents the rate of open events for a particular file With other segmentations, it represents the number of all files currently open in a particular context (host, container, process, etc.).\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max file.time.inThe time spent reading the file. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max file.time.outThe time spent writing in the file. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max file.time.totalThe time spent during file I/O. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/file/"},{"id":643,"title":"Filter and Search Events","content":"Scope-Based FilteringThe scope of an event are the labels that define the environment or context in which an event has occurred. Dimensions of the scope can include the cluster, container image, and IP address. If recurrent Container died events are observed, it may be useful to filter the event feed by host in order to investigate if the host hardware is responsible for the container failures.\nFilter ButtonsIn addition to using scope-based filters through the search bar, filter buttons are available in the Event Feed and in the Event Detail panel. You can use filter buttons on label values and event titles to instantly include or exclude relevant events.\nFree Text SearchFree text search facilitates searching through various event attributes, including ID, name, description, and scope values. A free text search issued for Pod will return any events with Pod in the name, description, or scope value. Combine scope-based filtering with free text for the most precise results. The following queries pull any instance of Back-off pulling image in the web-shop namespace.\nSearch FieldsThe search terms are used in a full text search across the following event fields:\nID Name Description Scope Label Values Tag Values Additionally, for Alert Events, the following fields are included in the full text search:\nAlert Condition Alert State Alert Threshold Alert Type Alert Notification Title Search SyntaxEvent search supports the following operators:\n+ signifies AND operation (all the terms have to be in the document) | signifies OR operation - negates a single term \u0026quot; wraps a number of terms to signify a phrase for searching * at the end of a term signifies a prefix query ( and ) signify precedence The default operator binding together the search terms is AND. Implications of this are shown below in the Examples Searches.\nExample SearchesContainer Killed: Match the events containing all search terms (Container AND Killed) because the default operator is AND.\nContainer + Killed: Match the events containing all search terms (Container AND Killed).\nContainer | Killed: Match the events containing any of the search terms (Container OR Killed).\n-Container: Match the events that do not contain the search term (NOT Container).\n\u0026quot;Container Killed\u0026quot;: Match the events containing the exact phrase \u0026quot;Container Killed\u0026quot;.\n-\u0026quot;Container Killed\u0026quot;: Match the events that do not contain the exact phrase \u0026quot;Container Killed\u0026quot;.\nCont*: Match the events containing any term starting with Cont.\n\u0026quot;Container + (Killed | Starting)\u0026quot;: Match the events containing either the two terms Container and Killed or the two terms Container and Starting\nContainer -Killed: Match the events that contain the term Container AND do not contain the term Killed. The default AND operator applies here.\nContainer | -Killed: Match the events that contain the term Container OR do not contain the term Killed. The query overrides the default AND operator by using an explicit |.\nDate RangeSelected Date Range at the bottom of the screen affect the search.\nDate Range: Selecting date range allows you to customize the date range for which you want to filter the results. The range is limited to 30 days in the past. UTC Switcher: Allows you to quickly toggle between Local Time and UTC time Time Window: Shows you the data for the selected time window. Turns on Live tracking automatically and continues to change over time. Zoom Out: Increases the time window. Actual zoom out value depends on the starting time window. Skip Previous: Move 1 step back in time using the currently selected time window Pause/Play: Toggles between paused and live tracking Skip Next: Move 1 step forward in time using the currently selected time window Live/Paused: Indication if the paused or live data is being observed ","url":"https://docs.sysdig.com/en/sysdig-monitor/filter-and-search-events/"},{"id":644,"title":"fluentd","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nFluentd SetupFluentd can be installed as a package (.deb, .rpm, etc) depending on the OS flavor, or it can be deployed in a Docker container. Fluentd installation is documented here. For the examples on this page, a .deb package installation is used.\nAfter installing Fluentd, add following lines in fluentd.conf :\n\u0026lt;source\u0026gt; @type monitor_agent bind 0.0.0.0 port 24220 \u0026lt;/source\u0026gt; Sysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;sdragent.default.yaml uses the following code to connect with Fluentd and collect default metrics.\n(If you use a non-standard port for monitor_agent , you can configure it as usual in the agent config file dragent.yaml.)\n- name: fluentd pattern: comm: fluentd conf: monitor_agent_url: http://localhost:24220/api/plugins.json Remember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExampleTo generate the metric data, it is necessary to generate some logs through an application. In the following example, HTTP is used. (For more information, see Life of a Fluentd event.)\nExecute the following command on in the Fluentd environment:\n$ curl -i -X POST -d \u0026#39;json={\u0026#34;action\u0026#34;:\u0026#34;login\u0026#34;,\u0026#34;user\u0026#34;:2}\u0026#39; http://localhost:8888/test.cycle Expected output: (Note: Here the status code is 200 OK, as HTTP traffic is successfully generated; it will vary per application.)\nHTTP/1.1 200 OK Content-type: text/plain Connection: Keep-Alive Content-length: 0 Metrics Available\nSee fluentd Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/fluentd/"},{"id":645,"title":"fluentd Metrics","content":"See Application Integrations for more information.\nfluentd.buffer_queue_lengthThe length of the plugin buffer queue for this plugin.\nfluentd.buffer_total_queued_sizeThe size of the buffer queue for this plugin.\nfluentd.retry_countThe number of retries for this plugin.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/fluentd-metrics/"},{"id":646,"title":"Forwarding to IBM MCM","content":"There are two ways to integrate IBM MCM with Sysdig Secure: through the UI, or through Agent Local Forwarding. Sysdig recommends the former method, but both are covered on this page.\nPrerequisites Generate a Grafeas API key and authenticate an IBM Cloud IAM token. Integrate IBM MCM through the UIEvent data can be forwarded to IBM Cloud Pak for Multicloud Management. Here\u0026rsquo;s how to set up an integration through the UI:\nLog in to Sysdig Secure as an Admin.\nNavigate to Integrations \u0026gt; Add Integrations.\nSearch and choose IBM MCM .\nConfigure the required options:\nIntegration Name: Define an integration name.\nURL: This is the URL for your IBM MCM API endpoint. This should be the same that you use to connect to the IBM MCM CloudPak console. Use the format scheme://host:port.\nGrafeas API Key: Enter your IBM API key.\nAccount ID: (Optional) You can leave it blank to use the default value of id-mycluster-account. If you want to use a different account name, provide it here.\nData to Send: Select from the drop-down the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled.\nAllow insecure connections: Click the box if you want to skip TLS certificate verification and allow insecure connections.\nEnabled: Toggle to enable the integration. You will need to successfully Test Integration with the button below before the integration can be enabled.\nClick Save.\nIntegrate IBM MCM through Agent Local ForwardingIf you wish to integrate IBM MCM through Agent Local Forwarding, review the configuration steps and use the following parameters for this integration:\nAttribute Required? Type Default Description endpoint yes string The URL, including protocol and port (if non standard), to your IBM Cloud Pak for Multicloud Management API endpoint apiKey yes string IBM Cloud API Key insecure no bool false Skip TLS certificate verification accountId no string id-mycluster-account Account ID to use on MCM providerId no string sysdig-secure The provider the findings will be associated with noteName no string policy-event The note to use. If unspecified, a note with policy-event ID will be created and used. ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forwarding-to-ibm-mcm/"},{"id":647,"title":"GCP Audit Log Policy","content":" Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nCreate a GCP Audit Log PolicyTo create a GCP Audit Log policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select GCP Audit Log.\nConfigure a GCP Audit Log PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate personnel.\nSee also: Set Up Notification Channels.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and GCP Audit Log.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose GCP Audit Log to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/gcp_auditlog_policy/"},{"id":648,"title":"Kubernetes","content":"kube_cluster_info Prometheus ID kube_cluster_info Legacy ID Metric Type gauge Unit number Description Details about the cluster hosting Sysdig agent. The label kube_cluster_flavour reports whether Sysdig agent is running on Kubernetes or OpenShift. The label kube_cluster_type tells you the type of service, such as Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE). Additional Notes kube_certificatesigningrequest_created Prometheus ID kube_certificatesigningrequest_created Legacy ID Metric Type gauge Unit number Description Timestamp of when the CSR object was created. Additional Notes The timestamp is in Unix epoch time. kube_certificatesigningrequest_condition Prometheus ID kube_certificatesigningrequest_condition Legacy ID Metric Type gauge Unit number Description Stores whether the CSR was approved or denied Additional Notes The metric will be 1 if the condition occurred and 0 if it didn\u0026rsquo;t. kube_certificatesigningrequest_labels Prometheus ID kube_certificatesigningrequest_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_certificatesigningrequest_cert_length Prometheus ID kube_certificatesigningrequest_cert_length Legacy ID Metric Type gauge Unit number Description The number of characters in the certificate Additional Notes kube_cronjob_created Prometheus ID kube_cronjob_created Legacy ID Metric Type gauge Unit number Description Timestamp of when the Kubernetes Cronjob was created. Additional Notes The timestamp is in Unix epoch time. kube_cronjob_info Prometheus ID kube_cronjob_info Legacy ID Metric Type gauge Unit number Description Additional Notes kube_cronjob_labels Prometheus ID kube_cronjob_labels Legacy ID Metric Type gauge Unit number Description Additional Notes kube_cronjob_next_schedule_time Prometheus ID kube_cronjob_next_schedule_time Legacy ID Metric Type gauge Unit time Description Additional Notes kube_cronjob_spec_starting_deadline_seconds Prometheus ID kube_cronjob_spec_starting_deadline_seconds Legacy ID Metric Type gauge Unit time Description Additional Notes kube_cronjob_spec_suspend Prometheus ID kube_cronjob_spec_suspend Legacy ID Metric Type gauge Unit number Description Additional Notes kube_cronjob_status_active Prometheus ID kube_cronjob_status_active Legacy ID Metric Type gauge Unit number Description Additional Notes kube_cronjob_status_last_schedule_time Prometheus ID kube_cronjob_status_last_schedule_time Legacy ID Metric Type relativeTime Unit number Description Additional Notes kube_daemonset_labels Prometheus ID kube_daemonset_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_daemonset_status_current_number_scheduled Prometheus ID kube_daemonset_status_current_number_scheduled Legacy ID kubernetes.daemonSet.pods.scheduled Metric Type gauge Unit number Description The number of nodes that running at least one daemon and are supposed to. Additional Notes kube_daemonset_status_desired_number_scheduled Prometheus ID kube_daemonset_status_desired_number_scheduled Legacy ID kubernetes.daemonSet.pods.desired Metric Type gauge Unit number Description The number of nodes that should be running the daemon Pod. Additional Notes kube_daemonset_status_number_misscheduled Prometheus ID kube_daemonset_status_number_misscheduled Legacy ID kubernetes.daemonSet.pods.misscheduled Metric Type gauge Unit number Description The number of nodes running a daemon Pod that are not supposed to. Additional Notes kube_daemonset_status_number_ready Prometheus ID kube_daemonset_status_number_ready Legacy ID kubernetes.daemonSet.pods.ready Metric Type gauge Unit number Description The number of nodes that should be running the daemon Pod and have one or more of the daemon Pod running and ready. Additional Notes kube_deployment_labels Prometheus ID kube_deployment_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_deployment_spec_paused Prometheus ID kube_deployment_spec_paused Legacy ID kubernetes.deployment.replicas.paused Metric Type gauge Unit number Description The number of paused Pods per deployment. These Pods will not be processed by the deployment controller. Additional Notes kube_deployment_spec_replicas Prometheus ID kube_deployment_spec_replicas Legacy ID kubernetes.deployment.replicas.desired Metric Type gauge Unit number Description The number of desired Pods per deployment. Additional Notes kube_deployment_status_replicas Prometheus ID kube_deployment_status_replicas Legacy ID kubernetes.deployment.replicas.running Metric Type gauge Unit number Description The number of running Pods per deployment. Additional Notes kube_deployment_status_replicas_available Prometheus ID kube_deployment_status_replicas_available Legacy ID kubernetes.deployment.replicas.available Metric Type gauge Unit number Description The number of available Pods per deployment. Additional Notes kube_deployment_status_replicas_unavailable Prometheus ID kube_deployment_status_replicas_unavailable Legacy ID kubernetes.deployment.replicas.unavailable Metric Type gauge Unit number Description The number of unavailable Pods per deployment. Additional Notes kube_deployment_status_replicas_updated Prometheus ID kube_deployment_status_replicas_updated Legacy ID kubernetes.deployment.replicas.updated Metric Type gauge Unit number Description The number of updated Pods per deployment. Additional Notes kube_hpa_labels Prometheus ID kube_hpa_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_hpa_spec_max_replicas Prometheus ID kube_hpa_spec_max_replicas Legacy ID kubernetes.hpa.replicas.max Metric Type gauge Unit number Description Upper limit for the number of Pods that can be set by the autoscaler. Additional Notes kube_hpa_spec_min_replicas Prometheus ID kube_hpa_spec_min_replicas Legacy ID kubernetes.hpa.replicas.min Metric Type gauge Unit number Description Lower limit for the number of Pods that can be set by the autoscaler. Additional Notes kube_hpa_status_current_replicas Prometheus ID kube_hpa_status_current_replicas Legacy ID kubernetes.hpa.replicas.current Metric Type gauge Unit number Description Current number of replicas of Pods managed by this autoscaler. Additional Notes kube_hpa_status_desired_replicas Prometheus ID kube_hpa_status_desired_replicas Legacy ID kubernetes.hpa.replicas.desired Metric Type gauge Unit number Description Desired number of replicas of Pods managed by this autoscaler. Additional Notes kube_hpa_status_condition Prometheus ID kube_hpa_status_condition Legacy ID Metric Type gauge Unit number Description Additional Notes kube_ingress_created Prometheus ID kube_ingress_created Legacy ID Metric Type gauge Unit number Description Timestamp of when the ingress object was created Additional Notes The timestamp is in Unix epoch time. kube_ingress_info Prometheus ID kube_ingress_info Legacy ID Metric Type gauge Unit number Description The labels on the metric store information about the object. Additional Notes The value of the metric will always be 1. kube_ingress_labels Prometheus ID kube_ingress_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_ingress_path Prometheus ID kube_ingress_path Legacy ID Metric Type gauge Unit number Description Information about the path of the ingress object is stored as labels on the metric. Additional Notes The value of the metric will always be 1. kube_ingress_tls Prometheus ID kube_ingress_tls Legacy ID Metric Type gauge Unit number Description Information about the TLS configuration of the ingress object is stored as labels on the metric. Additional Notes The value of the metric will always be 1. kube_job_complete Prometheus ID kube_job_complete Legacy ID kubernetes.job.numSucceeded Metric Type gauge Unit number Description The number of Pods which reached Phase Succeeded. Additional Notes kube_job_failed Prometheus ID kube_job_failed Legacy ID kubernetes.job.numFailed Metric Type gauge Unit number Description The number of Pods which reached Phase Failed. Additional Notes kube_job_info Prometheus ID kube_job_info Legacy ID Metric Type gauge Unit number Description The labels on the metric store information about the object. Additional Notes The value of the metric will always be 1. kube_job_labels Prometheus ID kube_job_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_job_owner Prometheus ID kube_job_owner Legacy ID Metric Type gauge Unit number Description Information about the owner of the job is stored as labels on the metric. Additional Notes The value of the metric will always be 1. kube_job_spec_completions Prometheus ID kube_job_spec_completions Legacy ID kubernetes.job.completions Metric Type gauge Unit number Description The desired number of successfully finished Pods that the job should be run with. Additional Notes kube_job_spec_parallelism Prometheus ID kube_job_spec_parallelism Legacy ID kubernetes.job.parallelism Metric Type gauge Unit number Description The maximum desired number of Pods that the job should run at any given time. Additional Notes kube_job_status_active Prometheus ID kube_job_status_active Legacy ID kubernetes.job.status.active Metric Type gauge Unit number Description The number of actively running Pods. Additional Notes kube_namespace_labels Prometheus ID kube_namespace_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_namespace_sysdig_count Prometheus ID kube_namespace_sysdig_count Legacy ID kubernetes.namespace.count Metric Type gauge Unit number Description The number of namespaces. Additional Notes kube_namespace_sysdig_deployment_count Prometheus ID kube_namespace_sysdig_deployment_count Legacy ID kubernetes.namespace.deployment.count Metric Type gauge Unit number Description The number of deployments per namespace. Additional Notes kube_namespace_sysdig_hpa_count Prometheus ID kube_namespace_sysdig_hpa_count Legacy ID kubernetes.namespace.hpa.count Metric Type gauge Unit number Description The number of HPA per namespace. Additional Notes kube_namespace_sysdig_job_count Prometheus ID kube_namespace_sysdig_job_count Legacy ID kubernetes.namespace.job.count Metric Type gauge Unit number Description The number of jobs per namespace. Additional Notes kube_namespace_sysdig_persistentvolumeclaim_count Prometheus ID kube_namespace_sysdig_persistentvolumeclaim_count Legacy ID kubernetes.namespace.persistentvolumeclaim.count Metric Type gauge Unit number Description The number of persistentvolumeclaim per namespace. Additional Notes kube_namespace_sysdig_pod_available_count Prometheus ID kube_namespace_sysdig_pod_available_count Legacy ID kubernetes.namespace.pod.available.count Metric Type gauge Unit number Description The number of available Pods per namespace. Additional Notes kube_namespace_sysdig_pod_desired_count Prometheus ID kube_namespace_sysdig_pod_desired_count Legacy ID kubernetes.namespace.pod.desired.count Metric Type gauge Unit number Description The number of desired Pods per namespace. Additional Notes kube_namespace_sysdig_pod_running_count Prometheus ID kube_namespace_sysdig_pod_running_count Legacy ID kubernetes.namespace.pod.running.count Metric Type gauge Unit number Description The number of Pods running per namespace. Additional Notes kube_namespace_sysdig_replicaset_count Prometheus ID kube_namespace_sysdig_replicaset_count Legacy ID kubernetes.namespace.replicaSet.count Metric Type gauge Unit number Description The number of replicaSets per namespace. Additional Notes kube_namespace_sysdig_resourcequota_count Prometheus ID kube_namespace_sysdig_resourcequota_count Legacy ID kubernetes.namespace.resourcequota.count Metric Type gauge Unit number Description The number of resource quota per namespace. Additional Notes kube_namespace_sysdig_service_count Prometheus ID kube_namespace_sysdig_service_count Legacy ID kubernetes.namespace.service.count Metric Type gauge Unit number Description The number of services per namespace. Additional Notes kube_namespace_sysdig_statefulset_count Prometheus ID kube_namespace_sysdig_statefulset_count Legacy ID kubernetes.namespace.statefulSet.count Metric Type gauge Unit number Description The number of statefulset per namespace. Additional Notes kube_node_info Prometheus ID kube_node_info Legacy ID Metric Type gauge Unit number Description The labels on the metric store information about the object. Additional Notes The value of the metric will always be 1. kube_node_labels Prometheus ID kube_node_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_node_spec_taint Prometheus ID kube_node_spec_taint Legacy ID Metric Type gauge Unit number Description Stores the taint\u0026rsquo;s key, value, and effect as labels on the metric. Additional Notes The value of the metric will always be 1. kube_node_spec_unschedulable Prometheus ID kube_node_spec_unschedulable Legacy ID kubernetes.node.unschedulable Metric Type gauge Unit number Description The number of nodes unavailable to schedule new Pods. Additional Notes kube_node_status_allocatable Prometheus ID kube_node_status_allocatable Legacy ID Metric Type gauge Unit number Description The amount of a resource on a node that is freely available. Additional Notes The type and unit of the resource are stored as labels on the metric. kube_node_status_allocatable_cpu_cores Prometheus ID kube_node_status_allocatable_cpu_cores Legacy ID kubernetes.node.allocatable.cpuCores Metric Type gauge Unit number Description The CPU resources of a node that are available for scheduling. Additional Notes kube_node_status_allocatable_memory_bytes Prometheus ID kube_node_status_allocatable_memory_bytes Legacy ID kubernetes.node.allocatable.memBytes Metric Type gauge Unit data Description The memory resources of a node that are available for scheduling. Additional Notes kube_node_status_allocatable_pods Prometheus ID kube_node_status_allocatable_pods Legacy ID kubernetes.node.allocatable.pods Metric Type gauge Unit number Description The Pod resources of a node that are available for scheduling. Additional Notes kube_node_status_capacity Prometheus ID kube_node_status_capacity Legacy ID Metric Type gauge Unit number Description The total amount of a resource on a node. Additional Notes The type and unit of the resource are stored as labels on the metric. kube_node_status_capacity_cpu_cores Prometheus ID kube_node_status_capacity_cpu_cores Legacy ID kubernetes.node.capacity.cpuCores Metric Type gauge Unit number Description The maximum CPU resources of the node. Additional Notes kube_node_status_capacity_memory_bytes Prometheus ID kube_node_status_capacity_memory_bytes Legacy ID kubernetes.node.capacity.memBytes Metric Type gauge Unit data Description The maximum memory resources of the node. Additional Notes kube_node_status_capacity_pods Prometheus ID kube_node_status_capacity_pods Legacy ID kubernetes.node.capacity.pods Metric Type gauge Unit number Description The maximum number of Pods of the node. Additional Notes kube_node_status_condition Prometheus ID kube_node_status_condition Legacy ID Metric Type gauge Unit number Description Stores the condition of the node as a label on the metric. Additional Notes The value of the metric will always be 1. kube_node_sysdig_disk_pressure Prometheus ID kube_node_sysdig_disk_pressure Legacy ID kubernetes.node.diskPressure Metric Type gauge Unit number Description The number of nodes with disk pressure. Additional Notes kube_node_sysdig_host Prometheus ID kube_node_sysdig_host Legacy ID Metric Type gauge Unit number Description Stores the hostname of the node as a label on the metric. Additional Notes The value of the metric will always be 1. kube_node_sysdig_memory_pressure Prometheus ID kube_node_sysdig_memory_pressure Legacy ID kubernetes.node.memoryPressure Metric Type gauge Unit number Description The number of nodes with memory pressure. Additional Notes kube_node_sysdig_network_unavailable Prometheus ID kube_node_sysdig_network_unavailable Legacy ID kubernetes.node.networkUnavailable Metric Type gauge Unit number Description The number of nodes with network unavailable. Additional Notes kube_node_sysdig_ready Prometheus ID kube_node_sysdig_ready Legacy ID kubernetes.node.ready Metric Type gauge Unit number Description The number of nodes that are ready. Additional Notes kube_persistentvolume_capacity_bytes Prometheus ID kube_persistentvolume_capacity_bytes Legacy ID kubernetes.persistentvolume.storage Metric Type gauge Unit number Description The persistent volume\u0026rsquo;s capacity. Additional Notes kube_persistentvolume_claim_ref Prometheus ID kube_persistentvolume_claim_ref Legacy ID Metric Type gauge Unit number Description Stores the claim\u0026rsquo;s name and namespace as labels on the metric. Additional Notes The value of the metric will always be 1. kube_persistentvolume_info Prometheus ID kube_persistentvolume_info Legacy ID Metric Type gauge Unit number Description The labels on the metric store information about the object. Additional Notes The value of the metric will always be 1. kube_persistentvolume_labels Prometheus ID kube_persistentvolume_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_persistentvolume_status_phase Prometheus ID kube_persistentvolume_status_phase Legacy ID Metric Type gauge Unit number Description Stores the phase of the PV as a label on the metric. Additional Notes The value of the metric will always be 1. kube_persistentvolume_sysdig_count Prometheus ID kube_persistentvolume_sysdig_count Legacy ID Metric Type gauge Unit number Description Additional Notes kube_persistentvolumeclaim_access_mode Prometheus ID kube_persistentvolumeclaim_access_mode Legacy ID Metric Type gauge Unit number Description Stores the access mode of the PVC as a label on the metric. Additional Notes The value of the metric will always be 1. kube_persistentvolumeclaim_info Prometheus ID kube_persistentvolumeclaim_info Legacy ID Metric Type gauge Unit number Description The labels on the metric store information about the object. Additional Notes The value of the metric will always be 1. kube_persistentvolumeclaim_labels Prometheus ID kube_persistentvolumeclaim_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_persistentvolumeclaim_resource_requests_storage_bytes Prometheus ID kube_persistentvolumeclaim_resource_requests_storage_bytes Legacy ID kubernetes.persistentvolumeclaim.requests.storage Metric Type gauge Unit number Description The amount of bytes that the PVC has requested. Additional Notes kube_persistentvolumeclaim_status_phase Prometheus ID kube_persistentvolumeclaim_status_phase Legacy ID Metric Type gauge Unit number Description Stores the phase of the PVC as a label on the metric. Additional Notes The value of the metric will always be 1. kube_persistentvolumeclaim_sysdig_storage Prometheus ID kube_persistentvolumeclaim_sysdig_storage Legacy ID kubernetes.persistentvolumeclaim.storage Metric Type gauge Unit number Description The actual resources of the underlying volume. Additional Notes kube_pod_container_info Prometheus ID kube_pod_container_info Legacy ID Metric Type gauge Unit number Description The labels on the metric store information about the object. Additional Notes The value of the metric will always be 1. kube_pod_container_resource_limits Prometheus ID kube_pod_container_resource_limits Legacy ID Metric Type gauge Unit number Description The amount of the resource limit for a container in a pod. Additional Notes kube_pod_container_resource_requests Prometheus ID kube_pod_container_resource_requests Legacy ID Metric Type gauge Unit number Description The amount of the resource request for a container in a pod. Additional Notes kube_pod_container_status_last_terminated_reason Prometheus ID kube_pod_container_status_last_terminated_reason Legacy ID Metric Type gauge Unit number Description Stores the reason for the last terminated state as a label on the metric. Additional Notes The value of the metric will always be 1. kube_pod_container_status_ready Prometheus ID kube_pod_container_status_ready Legacy ID Metric Type gauge Unit number Description The number of containers in the Pod in the ready state. Additional Notes kube_pod_container_status_restarts_total Prometheus ID kube_pod_container_status_restarts_total Legacy ID Metric Type counter Unit number Description The number of times that containers in the Pod have restarted. Additional Notes kube_pod_container_status_running Prometheus ID kube_pod_container_status_running Legacy ID Metric Type gauge Unit number Description The number of containers in the Pod in the running state. Additional Notes kube_pod_container_status_terminated Prometheus ID kube_pod_container_status_terminated Legacy ID Metric Type gauge Unit number Description The number of containers in the Pod in the terminated state. Additional Notes kube_pod_container_status_terminated_reason Prometheus ID kube_pod_container_status_terminated_reason Legacy ID Metric Type gauge Unit number Description Stores the reason that the container is in the terminated state as a label on the metric. Additional Notes The value of the metric will always be 1. kube_pod_container_status_waiting Prometheus ID kube_pod_container_status_waiting Legacy ID Metric Type gauge Unit number Description The number of containers in the Pod in the waiting state. Additional Notes kube_pod_container_status_waiting_reason Prometheus ID kube_pod_container_status_waiting_reason Legacy ID Metric Type gauge Unit number Description Stores the reason that the container is in the waiting state as a label on the metric. Additional Notes The value of the metric will always be 1. kube_pod_info Prometheus ID kube_pod_info Legacy ID kubernetes.pod.info Metric Type gauge Unit number Description The labels on the metric store information about the object. Additional Notes The value of the metric will always be 1. kube_pod_init_container_resource_limits Prometheus ID kube_pod_init_container_resource_limits Legacy ID Metric Type gauge Unit number Description The amount of the resource limit for an init container in a pod. Additional Notes kube_pod_init_container_resource_requests Prometheus ID kube_pod_init_container_resource_requests Legacy ID Metric Type gauge Unit number Description The amount of the resource request for an init container in a pod. Additional Notes kube_pod_init_container_status_last_terminated_reason Prometheus ID kube_pod_init_container_status_last_terminated_reason Legacy ID Metric Type gauge Unit number Description Stores the reason for the last terminated state as a label on the metric. Additional Notes The value of the metric will always be 1. kube_pod_init_container_status_ready Prometheus ID kube_pod_init_container_status_ready Legacy ID Metric Type gauge Unit number Description The number of init containers in the Pod in the ready state. Additional Notes kube_pod_init_container_status_restarts_total Prometheus ID kube_pod_init_container_status_restarts_total Legacy ID Metric Type counter Unit number Description The number of times that init containers in the Pod have restarted. Additional Notes kube_pod_init_container_status_running Prometheus ID kube_pod_init_container_status_running Legacy ID Metric Type gauge Unit number Description The number of init containers in the Pod in the running state. Additional Notes kube_pod_init_container_status_terminated Prometheus ID kube_pod_init_container_status_terminated Legacy ID Metric Type gauge Unit number Description The number of init containers in the Pod in the terminated state. Additional Notes kube_pod_init_container_status_terminated_reason Prometheus ID kube_pod_init_container_status_terminated_reason Legacy ID Metric Type gauge Unit number Description Stores the reason that the init container is in the terminated state as a label on the metric. Additional Notes The value of the metric will always be 1. kube_pod_init_container_status_waiting Prometheus ID kube_pod_init_container_status_waiting Legacy ID Metric Type gauge Unit number Description The number of init containers in the Pod in the waiting state. Additional Notes kube_pod_init_container_status_waiting_reason Prometheus ID kube_pod_init_container_status_waiting_reason Legacy ID Metric Type gauge Unit number Description Stores the reason that the init container is in the waiting state as a label on the metric. Additional Notes The value of the metric will always be 1. kube_pod_labels Prometheus ID kube_pod_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_pod_owner Prometheus ID kube_pod_owner Legacy ID Metric Type gauge Unit number Description Information about the owner of the pod is stored as labels on the metric. Additional Notes The value of the metric will always be 1. kube_pod_spec_volumes_persistentvolumeclaims_info Prometheus ID kube_pod_spec_volumes_persistentvolumeclaims_info Legacy ID Metric Type gauge Unit number Description Stores information about the PVC specified in a Pod\u0026rsquo;s spec. Additional Notes The value of the metric will always be 1. kube_pod_spec_volumes_persistentvolumeclaims_readonly Prometheus ID kube_pod_spec_volumes_persistentvolumeclaims_readonly Legacy ID Metric Type gauge Unit number Description Describes whether a PVC is mounted read-only. Additional Notes The value of the metric wil be 1 if the PVC is read-only and 0 if not. kube_pod_start_time Prometheus ID kube_pod_start_time Legacy ID Metric Type gauge Unit number Description Start time in unix timestamp for a pod Additional Notes kube_pod_status_ready Prometheus ID kube_pod_status_ready Legacy ID Metric Type gauge Unit number Description Additional Notes kube_pod_status_ready_time Prometheus ID kube_pod_status_ready_time Legacy ID Metric Type gauge Unit number Description Time when pod passed readiness probes. Additional Notes kube_pod_sysdig_containers_waiting Prometheus ID kube_pod_sysdig_containers_waiting Legacy ID kubernetes.pod.containers.waiting Metric Type gauge Unit number Description The number of containers waiting for a Pod. Additional Notes kube_pod_sysdig_resource_limits_cpu_cores Prometheus ID kube_pod_sysdig_resource_limits_cpu_cores Legacy ID kubernetes.pod.resourceLimits.cpuCores Metric Type gauge Unit number Description The limit on CPU cores to be used by a container. Additional Notes kube_pod_sysdig_resource_limits_memory_bytes Prometheus ID kube_pod_sysdig_resource_limits_memory_bytes Legacy ID kubernetes.pod.resourceLimits.memBytes Metric Type gauge Unit data Description The limit on memory to be used by a container in bytes. Additional Notes kube_pod_sysdig_resource_requests_cpu_cores Prometheus ID kube_pod_sysdig_resource_requests_cpu_cores Legacy ID kubernetes.pod.resourceRequests.cpuCores Metric Type gauge Unit number Description The number of CPU cores requested by containers in the Pod. Additional Notes kube_pod_sysdig_resource_requests_memory_bytes Prometheus ID kube_pod_sysdig_resource_requests_memory_bytes Legacy ID kubernetes.pod.resourceRequests.memBytes Metric Type gauge Unit data Description The number of memory bytes requested by containers in the Pod. Additional Notes kube_pod_sysdig_restart_count Prometheus ID kube_pod_sysdig_restart_count Legacy ID kubernetes.pod.restart.count Metric Type gauge Unit number Description The number of container restarts for the Pod. Additional Notes kube_pod_sysdig_restart_rate Prometheus ID kube_pod_sysdig_restart_rate Legacy ID kubernetes.pod.restart.rate Metric Type gauge Unit number Description Number of times the pod has been restarted per second Additional Notes kube_pod_sysdig_status_ready Prometheus ID kube_pod_sysdig_status_ready Legacy ID kubernetes.pod.status.ready Metric Type gauge Unit number Description The number of pods ready to serve requests. Additional Notes kube_poddisruptionbudget_created Prometheus ID kube_poddisruptionbudget_created Legacy ID Metric Type gauge Unit number Description Created time in unix timestamp for a poddisruptionbudget Additional Notes kube_poddisruptionbudget_status_current_healthy Prometheus ID kube_poddisruptionbudget_status_current_healthy Legacy ID Metric Type gauge Unit number Description current number of healthy pods Additional Notes kube_poddisruptionbudget_status_desired_healthy Prometheus ID kube_poddisruptionbudget_status_desired_healthy Legacy ID Metric Type gauge Unit number Description minimum desired number of healthy pods Additional Notes kube_poddisruptionbudget_status_expected_pods Prometheus ID kube_poddisruptionbudget_status_expected_pods Legacy ID Metric Type gauge Unit number Description total number of pods counted by this disruption budget Additional Notes kube_poddisruptionbudget_status_observed_generation Prometheus ID kube_poddisruptionbudget_status_observed_generation Legacy ID Metric Type gauge Unit number Description Most recent generation observed when updating this PDB status Additional Notes kube_poddisruptionbudget_status_pod_disruptions_allowed Prometheus ID kube_poddisruptionbudget_status_pod_disruptions_allowed Legacy ID Metric Type gauge Unit number Description Number of pod disruptions that are currently allowed Additional Notes kube_replicaset_labels Prometheus ID kube_replicaset_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_replicaset_owner Prometheus ID kube_replicaset_owner Legacy ID Metric Type gauge Unit number Description Information about the owner of the pod is stored as labels on the metric. Additional Notes The value of the metric will always be 1. kube_replicaset_spec_replicas Prometheus ID kube_replicaset_spec_replicas Legacy ID kubernetes.replicaSet.replicas.desired Metric Type gauge Unit number Description The number of desired Pods per replicaSet. Additional Notes kube_replicaset_status_fully_labeled_replicas Prometheus ID kube_replicaset_status_fully_labeled_replicas Legacy ID kubernetes.replicaSet.replicas.fullyLabeled Metric Type gauge Unit number Description The number of fully labeled Pods per replicaSet. Additional Notes kube_replicaset_status_ready_replicas Prometheus ID kube_replicaset_status_ready_replicas Legacy ID kubernetes.replicaSet.replicas.ready Metric Type gauge Unit number Description The number of ready Pods per replicaSet. Additional Notes kube_replicaset_status_replicas Prometheus ID kube_replicaset_status_replicas Legacy ID kubernetes.replicaSet.replicas.running Metric Type gauge Unit number Description The number of running Pods per replicaSet. Additional Notes kube_replicationcontroller_owner Prometheus ID kube_replicationcontroller_owner Legacy ID Metric Type gauge Unit number Description Additional Notes kube_replicationcontroller_spec_replicas Prometheus ID kube_replicationcontroller_spec_replicas Legacy ID Metric Type gauge Unit number Description Number of desired pod replicas for the replication controller. Additional Notes kube_replicationcontroller_status_fully_labeled_replicas Prometheus ID kube_replicationcontroller_status_fully_labeled_replicas Legacy ID Metric Type gauge Unit number Description Additional Notes kube_replicationcontroller_status_ready_replicas Prometheus ID kube_replicationcontroller_status_ready_replicas Legacy ID Metric Type gauge Unit number Description Additional Notes kube_replicationcontroller_status_replicas Prometheus ID kube_replicationcontroller_status_replicas Legacy ID Metric Type gauge Unit number Description Number of running pod replicas for the replication controller. Additional Notes kube_resourcequota Prometheus ID kube_resourcequota Legacy ID Metric Type gauge Unit number Description The amount of a resource that the resource quota is configured for. Additional Notes The resource type and whether the quota is hard or soft is stored as labels on the metric. kube_resourcequota_sysdig_limits_cpu_hard Prometheus ID kube_resourcequota_sysdig_limits_cpu_hard Legacy ID kubernetes.resourcequota.limits.cpu.hard Metric Type gauge Unit number Description Enforced CPU Limit quota per namespace. Additional Notes kube_resourcequota_sysdig_limits_cpu_used Prometheus ID kube_resourcequota_sysdig_limits_cpu_used Legacy ID kubernetes.resourcequota.limits.cpu.used Metric Type gauge Unit number Description Current observed CPU limit usage per namespace. Additional Notes kube_resourcequota_sysdig_limits_memory_hard Prometheus ID kube_resourcequota_sysdig_limits_memory_hard Legacy ID kubernetes.resourcequota.limits.memory.hard Metric Type gauge Unit number Description Enforced memory limit quota per namespace. Additional Notes kube_resourcequota_sysdig_limits_memory_used Prometheus ID kube_resourcequota_sysdig_limits_memory_used Legacy ID kubernetes.resourcequota.limits.memory.used Metric Type gauge Unit number Description Current observed memory limit usage per namespace. Additional Notes kube_resourcequota_sysdig_persistentvolumeclaims_hard Prometheus ID kube_resourcequota_sysdig_persistentvolumeclaims_hard Legacy ID kubernetes.resourcequota.persistentvolumeclaims.hard Metric Type gauge Unit number Description Enforced Peristentvolumeclaim quota per namespace. Additional Notes kube_resourcequota_sysdig_persistentvolumeclaims_used Prometheus ID kube_resourcequota_sysdig_persistentvolumeclaims_used Legacy ID kubernetes.resourcequota.persistentvolumeclaims.used Metric Type gauge Unit number Description Current observed Persistentvolumeclaim usage per namespace. Additional Notes kube_resourcequota_sysdig_pods_hard Prometheus ID kube_resourcequota_sysdig_pods_hard Legacy ID kubernetes.resourcequota.pods.hard Metric Type gauge Unit number Description Enforced Pod quota per namespace. Additional Notes kube_resourcequota_sysdig_pods_used Prometheus ID kube_resourcequota_sysdig_pods_used Legacy ID kubernetes.resourcequota.pods.used Metric Type gauge Unit number Description Current observed Pod usage per namespace. Additional Notes kube_resourcequota_sysdig_requests_cpu_hard Prometheus ID kube_resourcequota_sysdig_requests_cpu_hard Legacy ID kubernetes.resourcequota.requests.cpu.hard Metric Type gauge Unit number Description Enforced CPU request quota per namespace. Additional Notes kube_resourcequota_sysdig_requests_cpu_used Prometheus ID kube_resourcequota_sysdig_requests_cpu_used Legacy ID kubernetes.resourcequota.requests.cpu.used Metric Type gauge Unit number Description Current observed CPU request usage per namespace. Additional Notes kube_resourcequota_sysdig_requests_memory_hard Prometheus ID kube_resourcequota_sysdig_requests_memory_hard Legacy ID kubernetes.resourcequota.requests.memory.hard Metric Type gauge Unit number Description Enforced memory request quota per namespace. Additional Notes kube_resourcequota_sysdig_requests_memory_used Prometheus ID kube_resourcequota_sysdig_requests_memory_used Legacy ID kubernetes.resourcequota.requests.memory.used Metric Type gauge Unit number Description Current observed memory request usage per namespace. Additional Notes kube_resourcequota_sysdig_services_hard Prometheus ID kube_resourcequota_sysdig_services_hard Legacy ID kubernetes.resourcequota.services.hard Metric Type gauge Unit number Description Enforced service quota per namespace. Additional Notes kube_resourcequota_sysdig_services_used Prometheus ID kube_resourcequota_sysdig_services_used Legacy ID kubernetes.resourcequota.services.used Metric Type gauge Unit number Description Current observed service usage per namespace. Additional Notes kube_service_info Prometheus ID kube_service_info Legacy ID Metric Type gauge Unit number Description The labels on the metric store information about the object. Additional Notes The value of the metric will always be 1. kube_service_labels Prometheus ID kube_service_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_statefulset_labels Prometheus ID kube_statefulset_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_statefulset_replicas Prometheus ID kube_statefulset_replicas Legacy ID kubernetes.statefulSet.replicas Metric Type gauge Unit number Description Desired number of replicas of the given Template. Additional Notes kube_statefulset_status_replicas Prometheus ID kube_statefulset_status_replicas Legacy ID kubernetes.statefulSet.status.replicas Metric Type gauge Unit number Description Number of Pods created by the StatefulSet controller. Additional Notes kube_statefulset_status_replicas_current Prometheus ID kube_statefulset_status_replicas_current Legacy ID kubernetes.statefulSet.status.replicas.current Metric Type gauge Unit number Description The number of Pods created by the StatefulSet controller from the StatefulSet version indicated by currrentRevision. Additional Notes kube_statefulset_status_replicas_ready Prometheus ID kube_statefulset_status_replicas_ready Legacy ID kubernetes.statefulSet.status.replicas.ready Metric Type gauge Unit number Description Number of Pods created by the StatefulSet controller that have a Ready Condition. Additional Notes kube_statefulset_status_replicas_updated Prometheus ID kube_statefulset_status_replicas_updated Legacy ID kubernetes.statefulSet.status.replicas.updated Metric Type gauge Unit number Description Number of Pods created by the StatefulSet controller from the StatefulSet version indicated by updateRevision. Additional Notes kube_storageclass_created Prometheus ID kube_storageclass_created Legacy ID Metric Type gauge Unit - Description Unix epoch time when the storageclass was created. Additional Notes kube_storageclass_info Prometheus ID kube_storageclass_info Legacy ID Metric Type gauge Unit number Description The labels on the metric store information about the object. Additional Notes The value of the metric will always be 1. kube_storageclass_labels Prometheus ID kube_storageclass_labels Legacy ID Metric Type gauge Unit number Description Stores the labels associated with the object as labels on the metric. Additional Notes The value of the metric will always be 1. The labels will be prepended with \u0026rsquo;label_'. kube_workload_pods_status_phase Prometheus ID kube_workload_pods_status_phase Legacy ID kubernetes.workload.pods.status.phase Metric Type gauge Unit number Description The number of Pods in a particular phase for the workload. Additional Notes Stores the phase as a label on the metric. kube_workload_status_desired Prometheus ID kube_workload_status_desired Legacy ID kubernetes.workload.status.desired Metric Type gauge Unit number Description Additional Notes kube_workload_status_ready Prometheus ID kube_workload_status_ready Legacy ID kubernetes.workload.status.ready Metric Type gauge Unit number Description Additional Notes kube_workload_status_replicas_misscheduled Prometheus ID kube_workload_status_replicas_misscheduled Legacy ID kubernetes.workload.status.replicas.misscheduled Metric Type gauge Unit number Description The number of running Pods for a workload that are not supposed to be running. Additional Notes kube_workload_status_replicas_scheduled Prometheus ID kube_workload_status_replicas_scheduled Legacy ID kubernetes.workload.status.replicas.scheduled Metric Type gauge Unit number Description The number of Pods scheduled to be run for a workload. Additional Notes kube_workload_status_replicas_updated Prometheus ID kube_workload_status_replicas_updated Legacy ID kubernetes.workload.status.replicas.updated Metric Type gauge Unit number Description The number of updated Pods per workload. Additional Notes kube_workload_status_running Prometheus ID kube_workload_status_running Legacy ID kubernetes.workload.status.running Metric Type gauge Unit number Description The number of running Pods for a workload. Additional Notes kube_workload_status_unavailable Prometheus ID kube_workload_status_unavailable Legacy ID kubernetes.workload.status.unavailable Metric Type gauge Unit number Description The number of unavailable Pods per workload. Additional Notes ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/kubernetes/"},{"id":649,"title":"Legacy Event Alerts","content":"Alerts on events support only one segmentation label. An alert is generated for each segment.\nDefining a Metric AlertGuidelines Set a unique name and description: Set a meaningful name and description that help recipients easily identify the alert.\nSeverity: Set a severity level for your alert. The Priority: High, Medium, Low, and Info are reflected in the Alert list, where you can sort by the severity by using the top navigation pane. You can use severity as a criterion when creating events and alerts, for example: if there are more than 10 high severity events, notify.\nEvent Source: Filter by one or more event sources that should be considered by the alert. Predefined options are included for infrastructure event sources (kubernetes, docker, and containerd), but you can freely specify other values to match custom event sources.\nTrigger: Specify the trigger condition in terms of the number of events for a given range.\nEvent alert support only one segmentation label. If you choose Multiple Alerts, Sysdig generates only one alert for a selected segment.\nSpecify Event Specify the name, tag, or description of an event.\nSpecify one or more Event Sources.\nConfigure ScopeFilter the environment on which this alert will apply. Use advanced operators to include, exclude, or pattern-match groups, tags, and entities. You can also create alerts directly from Explore and Dashboards for automatically populating this scope.\nIn this example, failing a liveness probe in the agent-process-whitelist-cluster cluster triggers an alert.\nConfigure TriggerDefine the threshold and time window for assessing the alert condition. Single Alert fires an alert for your entire scope, while Multiple Alert fires if any or every segment breach the threshold at once.\nIf the number of events triggered in the monitored entity is greater than 5 for the last 10 minutes, recipients will be notified through the selected channel.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/-legacy-alerts-editor/legacy-event-alerts/"},{"id":650,"title":"Relational Database Service (RDS)","content":"aws.rds.BinLogDiskUsageThe amount of disk space occupied by binary logs on the master. Applies to MySQL read replicas.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.CPUUtilizationThe percentage of CPU utilization.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Gauge Value Type % Segment By CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.DatabaseConnectionsThe number of database connections in use.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.DiskQueueDepthThe number of outstanding I/Os (read/write requests) waiting to access the disk.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.FreeableMemoryThe amount of available random access memory, in megabytes.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Gauge Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.FreeStorageSpaceThe amount of available storage space in bytes.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Gauge Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.NetworkReceiveThroughputThe incoming (Receive) network traffic on the DB instance, including both customer database traffic and Amazon RDS traffic used for monitoring and replication. The metric is measured in bytes per second.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.NetworkTransmitThroughputThe outgoing (Transmit) network traffic on the DB instance, including both customer database traffic and Amazon RDS traffic used for monitoring and replication. The metric is measured in bytes per second.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.ReadIOPSThe average number of read I/O operations per second.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.ReadLatencyThe average amount of seconds taken per read I/O operation.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.ReadThroughputThe average number of bytes read from disk per second.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.ReplicaLagThe amount of time, in nanoseconds, a Read Replica DB instance lags behind the source DB instance.\nThis metric applies to MySQL read replicas.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.SwapUsageThe amount of swap space used by the database, measured in megabytes.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Gauge Value Type Byte Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.WriteIOPSThe average number of write I/O operations per second.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.WriteLatencyThe average amount of time taken per write I/O operation.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max aws.rds.WriteThroughputThe average number of bytes written to disk per second.\nFor more information, refer to the Amazon Relational Database (RDS) documentation.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/sysdig-monitor/aws-metrics-legacy/relational-database-service-rds/"},{"id":651,"title":"Responsible Disclosure","content":"If you believe you have identified a security vulnerability in any of our services, products, or infrastructure, we encourage you to report it to us responsibly.\nReporting a VulnerabilityReport security issues by emailing us at security@sysdig.com.\nInclude the following details in your report if applicable:\nA clear description of the vulnerability Steps to reproduce the issue The potential impact Any relevant screenshots or proof-of-concept code Your contact information for follow-up questions Guidelines for Responsible DisclosureWhen reporting a vulnerability, we ask that you:\nDo not publicly disclose the issue until we have had a reasonable amount of time to investigate and address it Avoid violating the privacy of others or disrupting services Limit testing to your own accounts or systems for which you have explicit permission We sincerely appreciate your efforts to help keep Sysdig and our users safe. Thank you for practicing responsible disclosure.\n","url":"https://docs.sysdig.com/en/sysdig-security-responsible-disclosure/"},{"id":652,"title":"Scheduled Reports","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nImage Scanning Reports [BETA]OverviewEnable this feature from the Sysdig Labs setting on the User Profile page. Once enabled, it will replace the Reporting v2 UI in the product page. (Reporting v2 API endpoints will still be available at this time.)\nImage Scanning Reports has moved from a synchronous model to an asynchronous mode, in which you schedule the reports you need and then receive them through notification channels.\nOnly email, Slack, and webhook notification channels are supported at this time.\nThe new version also includes:\nA preview function to check report structure in the UI\nA more advanced query builder\nExtended set of data columns (i.e. CVSS base score and vector) and extended set of available filters (i.e. package type)\nAsynchronous Reports can be run on vulnerabilities and on policies.\nThere are two different types of asynchronous reports:\nVulnerabilities: Vulnerabilities, package and image data\nPolicies: Images and scanning policies data\nCreate Report Definition Log in to Sysdig Secure with Advanced User or higher permissions, and select Image Scanning|Reports.\nNote: For Runtime Reports, the runtime scope must fall within your team\u0026rsquo;s designated scope. (For static reports, there is no scope requirement.)\nFrom the Reports list page, click Add Report.\nDefine the Report Configuration and Data as described below. Optionally, Preview the selected Data.\nClick Save and review the entry on the Report list page.\nDefine Report ConfigurationReporting creates a point-in-time snapshot of the scanning results state whenever the process starts, regardless of reports frequency.\nHere you define the report name, description, schedule, and the notification channel(s) used to deliver the report.\nDefine the following properties:\nName and Description: Choose a meaningful title and description\nSchedule- Report creation starts: Choose the cadence (daily, weekly, monthly) and the time (by half-hour) at which you want this report generated.\nThe schedule determines when the report data collection begins. As soon as evaluation is complete, you will receive a notification in the configured notification channels.\nNotification channel: The options presented in the drop-down list correspond to the notification channels you have set up in your environment.\nSince reports are typically large, the actual data is not sent to the notification channel; you receive a link to download it. You must be a valid Sysdig Secure user (Advanced User+) to access the link .\nDefine Report DataHere you define the data to be included in the report.\nSelect from the options:\nType: Choose whether to report on Vulnerabilities or Policies.\nVulnerability Vulnerabilities, package and image data\nColumns:\nVulnerability ID\nSeverity\nVulnerability type (OS / NON-OS)\nVulnerability feed link\nFix version (if any)\nImage name\nImage tag\nImage added date (to the Sysdig backend)\nPackage name\nPackage version\nCVSS v2 vector (if any), CVSS v2 base score (if any), CVSS v3 vector (if any), CVSS v3 base score (if any)\nImage ID\nVuln exception (Whether you have configured an exception for this vulnerability)\nRuntime scope (only if configuring a runtime scope)\nPolicies: Images and scanning policies data\nColumns:\nPolicy name\nPolicy evaluation (pass / fail)\nImage name\nImage tag\nImage ID\nImage added date (to the Sysdig backend)\nLast evaluation date (against this scanning policy)\nRuntime scope (only if configuring a runtime scope)\nScope: Choose Registry or Runtime.\nRegistry: Report on the images belonging to a registry and present on the Sysdig Secure scan results. The Registry field is mandatory (i.e. docker.io), repository and tag are optional, if you want to narrow down the report to a specific set of images.\nRuntime: Report on the runtime images present on the Sysdig Secure scan results. You can select Entire infrastructure or scope down using Sysdig runtime scope labels (i.e. kubernetes.cluster.name = mycluster).\nNote that the runtime scope must fall within your team\u0026rsquo;s designated scope, and only those options will be displayed.\nCondition: (Optional) You can configure one or more conditions that will filter the data that you deem relevant for the report.\nVulnerability Report Filters\nVulnerability type (OS/Non-OS)\nVulnerability ID\nVulnerability added to feed (x days ago)\nPackage name: supports startswith, i.e. \u0026lsquo;cur\u0026rsquo; will match \u0026lsquo;curl\u0026rsquo;\nSeverity: supports exact match, equals or greater than and equals or lower than\nCVSS v2 score greater than \u0026lsquo;value\u0026rsquo;, one decimal place supported\nCVSS v3 score greater than \u0026lsquo;value\u0026rsquo;, one decimal place supported\nFeed source (multi-select)\nFix Available (yes/no)\nSeverity (critical, high, medium, low,. negligible, unknown)\nPackage type (i.e. rpm, apk, python)\nOS name, i.e. debian, supports startswith\nImage added to the Sysdig scan results \u0026lsquo;more than\u0026rsquo; or \u0026rsquo;less than\u0026rsquo; X days ago\nVuln exception (true/false)\nPolicy Report Filters\nPolicy: Filter by images evaluated by a specific policy (i.e. NIST scan policy)\nPolicy evaluation (pass/fail)\nLast evaluation \u0026lsquo;more than\u0026rsquo; or \u0026rsquo;less than\u0026rsquo; X days ago\nOS Name, i.e. \u0026lsquo;debian\u0026rsquo;, supports startswith\nDocker file available (yes/no)\nImage added to the Sysdig scan results \u0026lsquo;more than\u0026rsquo; or \u0026rsquo;less than\u0026rsquo; X days ago\nPreview or ClearPreview offers a quick sample of the rows that will be obtained given the current report configuration. Preview can be used to verify format, filters and expected output. Take into account that preview data, although extracted from the real environment data, is too reduced to be significant.\nThe Clear button will reset the filters.\nSample Use Cases and their Previews Show me all Vulnerabilities in my Runtime with High Severity and a Fix Available, which are not on an Exclusions list.\nShow Images in my docker.io registry failing the NIST 800-190 scanning policy.\nManage Reports List Enable/Disable: By default, all report definitions are enabled. To disable, toggle the button by the Name on the List view. The report definition will be saved, but the report will not be run. It can be re-enabled at any time.\nUse the More (three dot) menu to:\nEdit Report Definition\nDuplicate the Report Definition Delete Report Definition\nInstrumenting ReportsFrom email notification:\nIf you have configured email as a notification channel for reports (see sample screenshot) :\nthen click the button to automatically download the report, provided your browser contains a valid Sysdig Secure user session. If no session is found, you will be redirected to the login screen.\nFrom a webhook or Slack notification:\nThese methods will also send a link to the report, which you can download programmatically using the your Sysdig API token, for example:\ncurl -L -H \u0026#34;Authorization: Bearer \u0026lt;my_API_token\u0026gt;\u0026#34; https://\u0026lt;Sysdig-SaaS-URL\u0026gt;/api/reporting/v1/scanning/reports/1q8gX9ErBwpDdNZKDbYm5Zzzyyxxx -o report.zip ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/scheduled-reports/"},{"id":653,"title":"Sysdig App Status","content":"Check the Status of SysdigTo reach the Sysdig status page through the UI:\nLog in to Sysdig Platform.\nOpen Settings through the user menu in the bottom left corner.\nClick Sysdig App Status under Sysdig Platform \u0026amp; Audit.\nYou will be brought to the Sysdig status webpage.\nOn this page you can:\nCheck the status of Sysdig servers. Click Subscribe to Updates to receive automated notifications. Take note of upcoming scheduled maintenance. Review past incidents and historical outages. We advise you to bookmark the status page for convenience.\nThe webpage displays the status of Sysdig in the US-East-1 region by default. Follow the links under About This Site to check the status of Sysdig in other regions. Not sure of your region? See SaaS Regions and IP Ranges for details.\n","url":"https://docs.sysdig.com/en/administration/sysdig_app_status/"},{"id":654,"title":"Troubleshooting Metrics","content":" These metrics have a reduced retention, and are designed for troubleshooting. They are not to related with metrics available in Troubleshooting Mode.\nTo learn more about data retention, see Sysdig Monitor Metric Retention Limits.\nProgram Level MetricsProgram level metrics are defined on program level.\nsysdig_program_cpu_cores_used sysdig_program_cpu_cores_used_percent sysdig_program_cpu_used_percent sysdig_program_memory_used_bytes sysdig_program_net_in_bytes sysdig_program_net_out_bytes sysdig_program_net_connection_in_count sysdig_program_net_connection_out_count sysdig_program_net_connection_total_count sysdig_program_net_error_count sysdig_program_net_request_count sysdig_program_net_request_in_count sysdig_program_net_request_out_count sysdig_program_net_request_time sysdig_program_net_request_in_time sysdig_program_net_tcp_queue_len sysdig_program_proc_count sysdig_program_thread_count sysdig_program_up In addition to the user-defined labels and standard set of labels Sysdig provides, you can use the labels program_cmd_line and program_name to segment program metrics.\nConnection-Level Network MetricsConnection level metrics are based on individual TCP connections. Aggregated network traffic metrics, such as those beginning sysdig_container_net_, do not fall under this category.\nsysdig_connection_net_in_bytes sysdig_connection_net_out_bytes sysdig_connection_net_total_bytes sysdig_connection_net_connection_in_count sysdig_connection_net_connection_out_count sysdig_connection_net_connection_total_count sysdig_connection_net_request_in_count sysdig_connection_net_request_out_count sysdig_connection_net_request_count sysdig_connection_net_request_in_time sysdig_connection_net_request_out_time sysdig_connection_net_request_time In addition to the user-defined labels and standard set of labels Sysdig provides, you can use following labels to segment connection level metrics: net_local_service, net_remote_service, net_local_endpoint, net_remote_endpoint, net_client_ip, net_server_ip, net_protocol\nKubernetes Troubleshooting MetricsKubernetes metrics relate to kubernetes itself, such as the workings of pods, containers and workloads. They are similar to OSS KSM Prometheus metrics, but are enriched by Sysdig for easy querying.\nkube_workload_status_replicas_misscheduled kube_workload_status_replicas_scheduled kube_workload_status_replicas_updated kube_pod_container_status_last_terminated_reason kube_pod_container_status_ready kube_pod_container_status_restarts_total kube_pod_container_status_running kube_pod_container_status_terminated kube_pod_container_status_terminated_reason kube_pod_container_status_waiting kube_pod_container_status_waiting_reason kube_pod_init_container_status_last_terminated_reason kube_pod_init_container_status_ready kube_pod_init_container_status_restarts_total kube_pod_init_container_status_running kube_pod_init_container_status_terminated kube_pod_init_container_status_terminated_reason kube_pod_init_container_status_waiting kube_pod_init_container_status_waiting_reason HTTP URL MetricsHTTP URL metrics relate to individual HTTP aggregated per individual URL.\nsysdig_host_net_http_url_error_count sysdig_host_net_http_url_request_count sysdig_host_net_http_url_request_time sysdig_container_net_http_url_error_count sysdig_container_net_http_url_request_count sysdig_container_net_http_url_request_time In addition to the user-defined labels and standard set of labels Sysdig provides, you can use the label net_http_url to segment HTTP URL level metrics.\nSQL Query MetricsSQL Query metrics are created per SQL query. Sysdig agent detects SQL query requests in network traffic and calculates metrics. This metric does not calculate queries on encrypted connections (for example, TLS).\nsysdig_host_net_sql_query_error_count sysdig_host_net_sql_query_request_count sysdig_host_net_sql_query_request_time sysdig_host_net_sql_querytype_error_count sysdig_host_net_sql_querytype_request_count sysdig_host_net_sql_querytype_request_time sysdig_container_net_sql_query_error_count sysdig_container_net_sql_query_request_count sysdig_container_net_sql_query_request_time sysdig_container_net_sql_querytype_error_count sysdig_container_net_sql_querytype_request_count sysdig_container_net_sql_querytype_request_time In addition to the user-defined labels and standard set of labels Sysdig provides, you can use the label net_sql_querytype to segment SQL Query metrics by query type.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/troubleshooting-metrics/"},{"id":655,"title":"(Legacy) Collecting Prometheus Metrics from Remote Hosts","content":" This feature is not supported with Promscrape V2. For information on different versions of Promscrape and migrating to the latest version, see Migrating from Promscrape V1 to V2.\nThe collected Prometheus metrics are reported under and associated with the Agent that performed the scraping as opposed to associating them with a process.\nPreparing the Configuration FileMultiple Agents can share the same configuration. Therefore, determine which one of those Agents scrape the remote endpoints with the dragent.yaml file. This is applicable to both\nCreate a separate configuration section for remote services in the Agent configuration file under the prometheus configuration.\nInclude a configuration section for each remote endpoint, and add either a URL or host/port (and an optional path) parameter to each section to identify the endpoint to scrape. The optional path identifies the resource at the endpoint. An empty path parameter defaults to the \u0026quot;/metrics\u0026quot; endpoint for scraping.\nOptionally, add custom tags for each endpoint configuration for remote services. In the absence of tags, metric reporting might not work as expected when multiple endpoints are involved. Agents cannot distinguish similar metrics scraped from multiple endpoints unless those metrics are uniquely identified by tags.\nTo help you get started, an example configuration for Kubernetes is given below:\nprometheus: remote_services: - prom_1: kubernetes.node.annotation.sysdig.com/region: europe kubernetes.node.annotation.sysdig.com/scraper: true conf: url: \u0026#34;https://xx.xxx.xxx.xy:5005/metrics\u0026#34; tags: host: xx.xxx.xxx.xy service: prom_1 scraping_node: \u0026#34;{kubernetes.node.name}\u0026#34; - prom_2: kubernetes.node.annotation.sysdig.com/region: india kubernetes.node.annotation.sysdig.com/scraper: true conf: host: xx.xxx.xxx.yx port: 5005 use_https: true tags: host: xx.xxx.xxx.yx service: prom_2 scraping_node: \u0026#34;{kubernetes.node.name}\u0026#34; - prom_3: kubernetes.pod.annotation.sysdig.com/prom_3_scraper: true conf: url: \u0026#34;{kubernetes.pod.annotation.sysdig.com/prom_3_url}\u0026#34; tags: service: prom_3 scraping_node: \u0026#34;{kubernetes.node.name}\u0026#34; - haproxy: kubernetes.node.annotation.yourhost.com/haproxy_scraper: true conf: host: \u0026#34;mymasternode\u0026#34; port: 1936 path: \u0026#34;/metrics\u0026#34; username: \u0026#34;{kubernetes.node.annotation.yourhost.com/haproxy_username}\u0026#34; password: \u0026#34;{kubernetes.node.annotation.yourhost.com/haproxy_password}\u0026#34; tags: service: router In the above example, scraping is triggered by node and pod annotations. You can add annotations to nodes and pods by using the kubectl annotate command as follows:\nkubectl annotate node mynode --overwrite sysdig.com/region=india sysdig.com/scraper=true haproxy_scraper=true yourhost.com/haproxy_username=admin yourhost.com/haproxy_password=admin In this example, you set annotation on a node to trigger scraping of the prom2 and haproxy services as defined in the above configuration.\nPreparing Container EnvironmentsAn example configuration for Docker environment is given below:\nprometheus: remote_services: - prom_container: container.label.com.sysdig.scrape_xyz: true conf: url: \u0026#34;https://xyz:5005/metrics\u0026#34; tags: host: xyz service: xyz In order for remote scraping to work in a Docker-based container environment, set the com.sysdig.scrape_xyz=true label to the Agent container. For example:\ndocker run -d --name sysdig-agent --restart always --privileged --net host --pid host -e ACCESS_KEY=\u0026lt;KEY\u0026gt; -e COLLECTOR=\u0026lt;COLLECTOR\u0026gt; -e SECURE=true -e TAGS=example_tag:example_value -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro --shm-size=512m sysdig/agent Substitute \u0026lt;KEY\u0026gt;, \u0026lt;COLLECTOR\u0026gt;, TAGS with your account key, collector, and tags respectively.\nSyntax of the RulesThe syntax of the rules for the remote_services is almost identical to those of process_filter with an exception to the include/exclude rule. The remote_services section does not use include/exclude rules. The process_filter uses include and exclude rules of which only the first match against a process is applied, whereas, in the remote_services section, each rule has a corresponding service name and all the matching rules are applied.\nRule ConditionsThe rule conditions work the same way as those for the process_filter. The only caveat is that the rules will be matched against the Agent process and container because the remote process/context is unknown. Therefore, matches for container labels and annotations work as before but they must be applicable to the Agent container as well. For instance, node annotations will apply because the Agent container runs on a node.\nFor annotations, multiple patterns can be specified in a single rule, in which case all patterns must match for the rule to be a match (AND operator). In the following example, the endpoint will not be considered unless both the annotations match:\nkubernetes.node.annotation.sysdig.com/region_scraper: europe kubernetes.node.annotation.sysdig.com/scraper: true That is, Kubernetes nodes belonging to only the Europe region are considered for scraping.\nAuthenticating Sysdig AgentSysdig Agent requires necessary permissions on the remote host to scrape for metrics. The authentication methods for local scraping works for authenticating agents on remote hosts as well, but the authorization parameters work only in the agent context.\nAuthentication based on certificate-key pair requires it to be constructed into Kubernetes secret and mounted to the agent.\nIn token-based authentication, make sure the agent token has access rights on the remote endpoint to do the scraping.\nUse annotation to retrieve username/password instead of passing them in plaintext. Any annotation enclosed in curly braces will be replaced by the value of the annotation. If the annotation doesn\u0026rsquo;t exist the value will be an empty string. Token substitution is supported for all the authorization parameters. Because authorization works only in the Agent context, credentials cannot be automatically retrieved from the target pod. Therefore, use an annotation in the Agent pod to pass them. To do so, set the password into an annotation for the selected Kubernetes object.\nIn the following example, an HAProxy account is authenticated with the password supplied in the yourhost.com/haproxy_password annotation on the agent node.\n- haproxy: kubernetes.node.annotation.yourhost.com/haproxy_scraper: true conf: host: \u0026#34;mymasternode\u0026#34; port: 1936 path: \u0026#34;/metrics\u0026#34; username: \u0026#34;{kubernetes.node.annotation.yourhost.com/haproxy_username}\u0026#34; password: \u0026#34;{kubernetes.node.annotation.yourhost.com/haproxy_password}\u0026#34; tags: service: router ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycollect-prometheus-metrics/collecting-prometheus-metrics-from-remote-hosts/"},{"id":656,"title":"(Legacy) Create a Custom App Check","content":" We are sunsetting application checks in favor of Monitoring Integrations. Custom App Checks are no longer supported from Host Shield version 14.0.0.\nIf your application is not already supported though, you have a few options:\nUtilize Prometheus, StatsD, or JMX to collect custom metrics:\nSend a request at support@sysdig.com, and we\u0026rsquo;ll do our best to add support for your application.\nCreate your own check by following the instructions below.\nIf you do write a custom check, let us know. We love hearing about how our users extend Sysdig Monitor, and we can also consider embedding your app check automatically in the Sysdig agent.\nSee also Understanding the Agent Config Files for details on accessing and editing the agent configuration files in general.\nCheck AnatomyEssentially, an app check is a Python Class that extends AgentCheck :\nfrom checks import AgentCheck class MyCustomCheck(AgentCheck): # namespaces of the monitored process to join # right now we support \u0026#39;net\u0026#39;, \u0026#39;mnt\u0026#39; and \u0026#39;uts\u0026#39; # put there the minimum necessary namespaces to join # usually \u0026#39;net\u0026#39; is enough. In this case you can also omit the variable # NEEDED_NS = ( \u0026#39;net\u0026#39;, ) # def __init__(self, name, init_config, agentConfig): # \u0026#39;\u0026#39;\u0026#39; # Optional, define it if you need custom initialization # remember to accept these parameters and pass them to the superclass # \u0026#39;\u0026#39;\u0026#39; # AgentCheck.__init__(self, name, init_config, agentConfig) # self.myvar = None def check(self, instance): \u0026#39;\u0026#39;\u0026#39; This function gets called to perform the check. Connect to the application, parse the metrics and add them to aggregation using superclass methods like `self.gauge(metricname, value, tags)` \u0026#39;\u0026#39;\u0026#39; server_port = instance[\u0026#39;port\u0026#39;] self.gauge(\u0026#34;testmetric\u0026#34;, 1) Put this file into /opt/draios/lib/python/checks.custom.d (create the directory if not present) and it will be available to the Sysdig agent. To run your checks, you need to supply configuration information in the agent\u0026rsquo;s config file, dragent.yaml as is done with bundled checks:\napp_checks: - name: voltdb # check name, must be unique # name of your .py file, if it\u0026#39;s the same of the check name you can omit it # check_module: voltdb pattern: # pattern to match the application comm: java arg: org.voltdb.VoltDB conf: port: 21212 # any key value config you need on `check(self, instance_conf)` function Check Interface DetailAs you can see, the most important piece of the check interface is the check function. The function declaration is:\ndef check(self, instance) instance is a dict containing the configuration of the check. It will contain all the attributes found in the conf: section in dragent.yaml plus the following:\nname: The check unique name.\nports: An array of all listening ports of the process.\nport: The first listening port of the process.\nThese attributes are available as defaults and allow you to automatically configure your check. The conf: section as higher priority on these values.\nInside the check function you can call these methods to send metrics:\nself.gauge(metric_name, value, tags) # Sample a gauge metric self.rate(metric_name, value, tags) # Sample a point, with the rate calculated at the end of the check self.increment(metric_name, value, tags) # Increment a counter metric self.decrement(metric_name, value, tags) # Decrement a counter metric self.histogram(metric_name, value, tags) # Sample a histogram metric self.count(metric_name, value, tags) # Sample a raw count metric self.monotonic_count(metric_name, value, tags) # Sample an increasing counter metric Usually the most used are gauge and rate . Besides metric_name and value parameters that are quite obvious, you can also add tags to your metric using this format:\ntags = [ \u0026#34;key:value\u0026#34;, \u0026#34;key2:value2\u0026#34;, \u0026#34;key_without_value\u0026#34;] It is an array of string representing tags in both single or key/value approach. They will be useful in Sysdig Monitor for graph segmentation.\nYou can also send service checks which are on/off metrics, using this interface:\nself.service_check(name, status, tags) Where status can be:\nAgentCheck.OK\nAgentCheck.WARNING\nAgentCheck.CRITICAL\nAgentCheck.UNKNOWN\nTestingTo test your check you can launch Sysdig App Checks from the command line to avoid running the full agent and iterate faster:\n# from /opt/draios directory ./bin/sdchecks runCheck \u0026lt;check_unique_name\u0026gt; \u0026lt;process_pid\u0026gt; [\u0026lt;process_vpid\u0026gt;] [\u0026lt;process_port\u0026gt;] check_unique_name: The check name as on config file.\npid: Process pid seen from host.\nvpid: Optional, process pid seen inside the container, defaults to 1.\nport: Optional, port where the process is listening, defaults to None.\nExample:\n./bin/sdchecks runCheck redis 1254 1 6379 5658:INFO:Starting 5658:INFO:Container support: True 5658:INFO:Run AppCheck for {\u0026#39;ports\u0026#39;: [6379], \u0026#39;pid\u0026#39;: 5625, \u0026#39;check\u0026#39;: \u0026#39;redis\u0026#39;, \u0026#39;vpid\u0026#39;: 1} Conf: {\u0026#39;port\u0026#39;: 6379, \u0026#39;socket_timeout\u0026#39;: 5, \u0026#39;host\u0026#39;: \u0026#39;127.0.0.1\u0026#39;, \u0026#39;name\u0026#39;: \u0026#39;redis\u0026#39;, \u0026#39;ports\u0026#39;: [6379]} Metrics: # metrics array Checks: # metrics check Exception: None # exceptions The output is intentionally raw to allow you to better debug what the check is doing.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycreate-a-custom-app-check/"},{"id":657,"title":"Classic Agent Installation","content":"To understand what each component does, see Feature Overview.\nFor System Requirements, see Installation Requirements.\nKubernetes ClustersA Kubernetes install can be accomplished through the Quick Integrations Wizard.\nKubernetes installations use a Helm chart, and the array of components are all included under the sysdig-deploy chart.\nTo obtain all the Sysdig Secure features, install the following components in Kubernetes clusters:\nSysdig Agent Vulnerability Host Scanner Kubernetes Security Posture Management (KSPM) Rapid Response Install on a Kubernetes cluster\nHostsHost-based installations using containers support a subset of Sysdig Secure features. Install the following components on Hosts with containers:\nSysdig Agent Vulnerability Host Scanner Posture Host Analyzer Rapid Response Host-based installations using packages support a subset of Sysdig Secure features. Install the following components on Hosts with packages:\nSysdig Agent Host Scanner Install on a Host\nECS on EC2ECS on EC2 supports a subset of Sysdig Secure features. Install the following components on ECS on EC2:\nSysdig Agent Install on an ECS cluster on EC2 ServerlessA subset of Sysdig Secure features are supported on various Serverless environments. Install the following components on Serverless:\nServerless Agent Install on Serverless ","url":"https://docs.sysdig.com/en/sysdig-secure/install-agent-components/classic/"},{"id":658,"title":"Classic Installation","content":"Sysdig recommends installing Cluster Shield and Host Shield to simplify the installation process and access the latest features.\nSysdig AgentSysdig Agent is a lightweight daemon that collects system metrics and events from your containers, Kubernetes, and the cloud. The agent sends this data to the Sysdig backend for processing and analysis, where it is used for monitoring and troubleshooting purposes.\nSysdig Agent has the following deployment options. The deployment method you choose will depend on your specific use case and environment.\nKubernetes DaemonSet via Helm Standalone binary on Linux Container Alternatively, you can use Prometheus Remote Write, or Integrations, or both, to collect data from environments where Sysdig Agent is not available.\nPrometheus Remote WriteYou can use Prometheus Remote Write to collect Prometheus metrics from your Prometheus servers. This is best suited for environments where the Sysdig Agent is not available. However, if you choose to use Prometheus Remote Write, the following features of Sysdig Monitor will not be available as it does not collect syscall() events.\nSystem metrics Extended Label Sets The Scope Tree IntegrationsIntegrations for Sysdig Monitor include application integrations, cloud integrations, and custom integrations.\nAdd Cloud Accounts Configure Monitoring Integrations Next Steps Install Sysdig Agent Install Prometheus Remote Write Configure Integrations ","url":"https://docs.sysdig.com/en/sysdig-monitor/classic-agent/"},{"id":659,"title":"Control Disk Usage by Agent Logs","content":"Use the following configuration to control the space taken up by agent logs:\nmax_size: Sets a limit to the size of a single agent log file, in megabytes. When the log file reaches this size, a new log file will be created. The old log will be renamed with a timestamp. The default size is 10 megabytes.\nrotate: The rotate configuration determines how many old log files are kept on the disk. The default is 10 log files.\nWhen the log file reaches this size, a new log file, draios.log will be created, and the old log will be renamed with a timestamp.\nlog: max_size: 10 rotate: 10 For example, if the current log file reaches the size limit of 10 megabytes and the number of log files reaches the limit of 10, the oldest will be removed. The last log file will be renamed with a timestamp and added to the list of old log files.\nIncreasing these values can provide more logs for troubleshooting at the expense of more space.\n","url":"https://docs.sysdig.com/en/sysdig-secure/control-disk-usage-classic-agent-logs/"},{"id":660,"title":"File System","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nfs.used.percentSpecifies what percentage of the file system has been used.\nMetadata\nDescription\nMetric Type\nGauge\nValue Type\nPercent\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Sum, Minimum, Maximum\nfs.free.percentSpecifies what percentage of the file system is free.\nMetadata\nDescription\nMetric Type\nGauge\nValue Type\nPercent\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Sum, Minimum, Maximum\nfs.bytes.freeThe number of bytes free in the file system.\nMetadata\nDescription\nMetric Type\ngauge\nValue Type\nByte\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Sum, Minimum, Maximum\nfs.bytes.usedThe number of bytes used in the file system.\nMetadata\nDescription\nMetric Type\nGauge\nValue Type\nByte\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Sum, Minimum, Maximum\nfs.bytes.totalThe size of the file system.\nMetadata\nDescription\nMetric Type\nGauge\nValue Type\nByte\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nfs.inodes.total.countThe number of inodes in the file system.\nMetadata\nDescription\nMetric Type\nGauge\nValue Type\nInteger\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Sum, Minimum, Maximum\nfs.inodes.used.countThe number of inodes used in the file system.\nMetadata\nDescription\nMetric Type\nGauge\nValue Type\nInteger\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Sum, Minimum, Maximum\nfs.inodes.used.percentPercentage of filesystem inodes usage.\nMetadata\nDescription\nMetric Type\nGauge\nValue Type\nPercent\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Sum, Minimum, Maximum\nfs.root.used.percentPercentage of root filesystem usage.\nMetadata\nDescription\nMetric Type\nGauge\nValue Type\nPercent\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Sum, Minimum, Maximum\nfs.largest.used.percentPercentage of the largest filesystem.\nMetadata\nDescription\nMetric Type\nGauge\nValue Type\nPercent\nScope\nHost, Container\nSegment By\nagent.tag\ncloudProvider.account.id\ncloudProvider.availabilityZone\ncloudProvider.region\ncloudProvider.tag\ncontainer.id\ncontainer.image\ncontainer.name\necs.clusterName\necs.serviceName\necs.taskFamilyName\nfs.device\nfs.mountDir\nfs.type\nhost.hostName\nhost.mac\nDefault Time Aggregation\nAverage\nAvailable Time Aggregation Formats\nAverage, Rate, Sum, Minimum, Maximum\nDefault Group Aggregation\nAverage\nAvailable Group Aggregation Formats\nAverage, Sum, Minimum, Maximum\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/file-system/"},{"id":661,"title":"GitHub Policy","content":" Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nCreate a GitHub PolicyTo create a GitHub policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select GitHub.\nConfigure a GitHub PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate personnel.\nSee Set Up Notification Channels for more information.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and GitHub.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose GitHub to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/github_policy/"},{"id":662,"title":"Go","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nGo_expvar SetupYou will need to create a custom entry in the user settings config file for your Go application, due to the difficulty in determining if an application is written in Go by looking at process names or arguments. Be sure your app has expvars enabled, which means importing the expvar module and having an HTTP server started from inside your app, as follows:\nimport ( ... \u0026#34;net/http\u0026#34; \u0026#34;expvar\u0026#34; ... ) // If your application has no http server running for the DefaultServeMux, // you\u0026#39;ll have to have a http server running for expvar to use, for example // by adding the following to your init function func init() { go http.ServeAndListen(\u0026#34;:8080\u0026#34;, nil) } // You can also expose variables that are specific to your application // See http://golang.org/pkg/expvar/ for more information var ( exp_points_processed = expvar.NewInt(\u0026#34;points_processed\u0026#34;) ) func processPoints(p RawPoints) { points_processed, err := parsePoints(p) exp_points_processed.Add(points_processed) ... } See also the following blog entry: How to instrument Go code with custom expvar metrics.\nSysdig Agent Configuration\nReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationNo default configuration for Go is provided in the Sysdig agent dragent.default.yaml file. You must edit the agent config file as described in Example 1.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExampleAdd the following code sample to dragent.yaml to collect Go metrics.\napp_checks: - name: go-expvar check_module: go_expvar pattern: comm: go-expvar conf: expvar_url: \u0026#34;http://localhost:8080/debug/vars\u0026#34; # automatically match url using the listening port # Add custom metrics if you want metrics: - path: system.numberOfSeconds type: gauge # gauge or rate alias: go_expvar.system.numberOfSeconds - path: system.lastLoad type: gauge alias: go_expvar.system.lastLoad - path: system.numberOfLoginsPerUser/.* # You can use / to get inside the map and use .* to match any record inside type: gauge - path: system.allLoad/.* type: gauge Metrics AvailableSee Go Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/go/"},{"id":663,"title":"Go Metrics","content":"See Application Integrations for more information.\ngo_expvar.memstats.allocThe number of bytes allocated and not yet freed.\ngo_expvar.memstats.freesThe number of free bytes.\ngo_expvar.memstats.heap_allocgo_expvar.memstats.heap_idleThe number of bytes in idle spans.\ngo_expvar.memstats.heap_inuseThe number of bytes in non-idle spans.\ngo_expvar.memstats.heap_objectsThe total number of allocated objects.\ngo_expvar.memstats.heap_releasedThe number of bytes released to the OS.\ngo_expvar.memstats.heap_sysThe number of bytes obtained from the system.\ngo_expvar.memstats.lookupsThe number of pointer lookups.\ngo_expvar.memstats.mallocsThe number of mallocs.\ngo_expvar.memstats.num_gcThe number of garbage collections.\ngo_expvar.memstats.pause_ns.avgThe average of recent GC pause durations.\ngo_expvar.memstats.pause_ns.countThe number of submitted GC pause durations.\ngo_expvar.memstats.pause_ns.maxThe max GC pause duration.\ngo_expvar.memstats.pause_ns.medianThe median GC pause duration.\ngo_expvar.memstats.pause_total_nsThe total GC pause duration over the lifetime of process.\ngo_expvar.memstats.total_allocThe bytes allocated (even if freed).\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/go-metrics/"},{"id":664,"title":"Host Scanning","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nBy default, host scanning:\nIs triggered every 24 hours\nIncludes a default list of directories that are scanned by the analyzer.\nIt is possible to configure the schedule and/or the list of directories to be scanned using the Host Scanning Configuration Options if needed.\nThe feature is installed using the Node Analyzer component and is currently available for Sysdig Secure.\nSupported Operating SystemsSupported OSs:\nUbuntu 16.04, 18.04, 20.04, 22.10\nRedHat Enterprise Linux 7, 8\nDebian 8, 9, 10\nAmazon Linux 2\nUnsupported OSs:\nRedHat CoreOS (currently not supported)\nGoogle COS (this system does not have a package manager or standard packages and therefore cannot be supported)\nAccess Host Scanning Follow the steps for the Node Analyzer: Multi-Feature Installation.\nLog in to Sysdig Secure with at least Advanced User privileges.\nThe results you can see in the Host Scanning list are affected by your user and team privileges.\nSelect Scanning \u0026gt; Hosts. The Host Scanning list page is displayed.\nFrom here you can:\nSearch Results or Filter by Scope\nPurge Disabled Hosts\nReview Host Vulnerabilities on the Host Results page.\nClick to see the runtime scanning results for images on that host\nSearch Results or Filter by ScopeOn the Host Scanning landing page, you can:\nSearch: by hostname, mac, cluster name\nFilter by Team Scope: Your active team scope is applied when viewing Host Scanning results, but you can further narrow down from Entire Infrastructure using the scope filters.\nYou can compose a scope filter using various operators (in, not-in, equal, not-equal, etc.).\nThen proceed to review the vulnerabilities.\nPurge Disabled HostsOn the Host Scanning list page, click the three dot selector on the far right to access the Purge Disabled Hosts from Scope button.\nUse this feature for hosts that have been removed from your cluster, to ensure they are also removed from the host scan list page.\nReview Host VulnerabilitiesThere are multiple ways to access the result details:\nSelect a host (line item) from the landing page, or\nChoose View Vulnerabilities from the expanded selector at the end of a line item\nEither choice opens a Host Results page.\nFrom the Host Results page, you can:\nFilter by severity and whether the vulnerability has a fix\nSelect a vulnerability to review details and remediation steps in a pull-out\nCompare earlier results and/or view the diff\nBy default, host scans are run every 24 hours, so you can view the Current results, the Previous (one day ago) results, or the Difference in findings between the two.\nIf nothing was changed or fixed between the two scans, the findings will look the same. The summary is displayed.\nDownload report as a CSV or JSON file\nSee Scanning Results for Containers on the HostFor any given host, you can also check the image scan results of its containers from the Host Scanning landing page.\nSelect Scanning \u0026gt; Hosts.\nHover over a line item and choose View Runtime Images from the far-right selector.\nThe Scanning Results page is displayed, showing the detailed runtime scanning results for the containers on your selected host.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/host-scanning/"},{"id":665,"title":"Legacy Advanced Metric Alerts","content":"Convert an Advanced Alert to a Prometheus AlertAdvanced alerts are deprecated in favour of Prometheus Alerts. You cannot create an advanced alert in the Sysdig Monitor UI. However, you can open an existing advanced alerts, and save it as a Prometheus Alert.\nTo save an advanced metric alert as a Prometheus alert:\nOpen the advanced alert and click Edit.\nThe Advanced Metric Alert page will display an option to copy the alert to a PromQL alert.\nAdjust the time window as necessary, select one or more notification channels, and configure alert settings. Alternatively, you can do the configuration after copying to Prometheus alert page.\nClick Copy to Prometheus alert.\nThe PromQL alert editor page will be displayed.\nClick Save.\nLearn MoreSee Advanced alerts for more details.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/advanced-alerts/"},{"id":666,"title":"Legacy Anomaly Detection Alerts","content":" Define an Anomaly Detection AlertGuidelines Set a unique name and description: Set a meaningful name and description that help recipients easily identify the alert\nSeverity: Set a severity level for your alert. The Priority: High, Medium, Low, and Info are reflected in the Alert list, where you can sort by the severity by using the top navigation pane. You can use severity as a criterion when creating events and alerts, for example: if there are more than 10 high severity events, notify.\nSpecify multiple segments: Selecting a single segment might not always supply enough information to troubleshoot. Enrich the selected entity with related information by adding additional related segments. Enter hierarchical entities so you have the bottom-down picture of what went wrong and where. For example, specifying a Kubernetes Cluster alone does not provide the context necessary to troubleshoot. In order to narrow down the issue, add further contextual information, such as Kubernetes Namespace, Kubernetes Deployment, and so on.\nSpecify EntitySelect one or more metrics whose behavior you want to monitor.\nConfigure ScopeFilter the environment on which this alert will apply. An alert will fire when the value returned by one of the selected metrics does not follow the pattern in the availability zone, us-east-1b.\nYou can also create alerts directly from Explore and Dashboards for automatically populating this scope.\nConfigure TriggerTrigger gives you control over how notifications are created and help prevent flooding your notification channel with notifications. For example, you may want to receive a notification for every violation, or only want a single notification for a series of consecutive violations.\nDefine the threshold and time window for assessing the alert condition. Supported time scales are minute, hour, or day.\nIf the monitored host or Kubernetes cluster is not available or not responding for the last 5 minutes, recipients will be notified.\nYou can set any value for % and a value greater than 1 for the time window. For example, If you choose 50% instead of 100%, a notification will be triggered when the entity is down for 2.5 minutes in the selected time window of 5 minutes.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/-legacy-alerts-editor/legacy-anomaly-detection-alerts/"},{"id":667,"title":"Network","content":"sysdig_host_sockstat_udp_inuse Prometheus ID sysdig_host_sockstat_udp_inuse Legacy ID none Metric Type gauge Unit number Description UDP socket in use metric name Additional Notes - sysdig_host_sockstat_udp6_inuse Prometheus ID sysdig_host_sockstat_udp6_inuse Legacy ID none Metric Type gauge Unit number Description UDP socket in use metric name Additional Notes - sysdig_host_sockstat_tcp_inuse Prometheus ID sysdig_host_sockstat_tcp_inuse Legacy ID none Metric Type gauge Unit number Description TCP socket in use metric name Additional Notes - sysdig_host_sockstat_tcp6_inuse Prometheus ID sysdig_host_sockstat_tcp6_inuse Legacy ID none Metric Type gauge Unit number Description TCP6 socket in use metric name Additional Notes - sysdig_connection_net_connection_in_count Prometheus ID sysdig_connection_net_connection_in_count Legacy ID net.connection.count.in Metric Type counter Unit number Description The number of currently established client (inbound) connections. Additional Notes net_connection* metric is especially useful when segmented by protocol, port or process. This is the TCP-level connection counts. Sysdig also performs heuristics to present UDP packets as connections based on src and dst IP for these. These calculation is depend on syscalls such as connect and accept. This is different from the net_request* metrics. They are calculated based on our classification of data by parsing read /write buffers associated with read/write and send/receive syscalls into request and response. Even though buffers are not evaluated to determine protocol-level info, Sysdig can determine that a request (for example, a certain server process has received a read syscall or a client process has sent a write syscall) has been made and an associated response has been sent. Using this information, Sysdig generates the metrics without protocol-level segmentation. The latency is determined using the time delta between a request and a response. sysdig_connection_net_connection_out_count Prometheus ID sysdig_connection_net_connection_out_count Legacy ID net.connection.count.out Metric Type counter Unit number Description The number of currently established server (outbound) connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_connection_net_connection_total_count Prometheus ID sysdig_connection_net_connection_total_count Legacy ID net.connection.count.total Metric Type counter Unit number Description The number of currently established connections. This value may exceed the sum of the inbound and outbound metrics since it represents client and server inter-host connections as well as internal only connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_connection_net_in_bytes Prometheus ID sysdig_connection_net_in_bytes Legacy ID net.bytes.in Metric Type counter Unit data Description The number of inbound network bytes. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_connection_net_out_bytes Prometheus ID sysdig_connection_net_out_bytes Legacy ID net.bytes.out Metric Type counter Unit data Description The number of outbound network bytes. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_connection_net_request_count Prometheus ID sysdig_connection_net_request_count Legacy ID net.request.count Metric Type counter Unit number Description The total number of network requests. Note, this value may exceed the sum of inbound and outbound requests, because this count includes requests over internal connections. Additional Notes sysdig_connection_net_request_in_count Prometheus ID sysdig_connection_net_request_in_count Legacy ID net.request.count.in Metric Type counter Unit number Description The number of inbound network requests. Additional Notes sysdig_connection_net_request_in_time Prometheus ID sysdig_connection_net_request_in_time Legacy ID net.request.time.in Metric Type counter Unit time Description The average time to serve an inbound request. Additional Notes sysdig_connection_net_request_out_count Prometheus ID sysdig_connection_net_request_out_count Legacy ID net.request.count.out Metric Type counter Unit number Description The number of outbound network requests. Additional Notes sysdig_connection_net_request_out_time Prometheus ID sysdig_connection_net_request_out_time Legacy ID net.request.time.out Metric Type counter Unit time Description The number of average time spent waiting for an outbound request. Additional Notes sysdig_connection_net_request_time Prometheus ID sysdig_connection_net_request_time Legacy ID net.request.time Metric Type counter Unit time Description The number of average time to serve a network request. Additional Notes sysdig_connection_net_total_bytes Prometheus ID sysdig_connection_net_total_bytes Legacy ID net.bytes.total Metric Type counter Unit data Description The total network bytes, including both inbound and outbound connections. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/network/"},{"id":668,"title":"Review Events","content":" The Event Details panel is displayed on the right side of the screen.\nHere you can see detailed information about the event, such as the time of occurrence, and details of its exact location in your infrastructure.\nThe Event Details PanelThe Event Details panel contains detailed information about the event. The details shown depend depend on the event type. Details will vary between Alert, Custom, Container, and Kubernetes events.\nAlert EventsThe example given below is of an Alert Event:\nMetadata Description Event ID A 19-character unique identifier for the event in the event feed. Note: This is different from the 6-character alert occurrence ID used to identify a specific alert occurrence. Severity The severity of the event (High, Medium, Low, Info). Status The current state of the event (Triggered, Resolved) Fired For Duration the alert has been active. This starts when the alert condition is met and stops once the condition is no longer true. Acknowledged Indicates whether the event has been acknowledged by a user. Alert Rule The name of the alert rule that generated the event. Alert Type The type of alert. For example, Threshold, Prometheus, Event, Group Outlier Query The expression defined in the alert rule that was satisfied when the alert rule was triggered Count Events that Match (Alert on Events only) The specific search criteria that matched one or more events, triggering this alert. Threshold (Optional) The threshold that was satisfied, resulting in the alert being triggered Triggered Value (Optional) The value of the expression at the time the alert was triggered Resolution Value (Optional) The value of the expression that caused the alert to resolve Segment The unique entity that triggered the alert rule. Scope Additional context derived from labels enriched by the Sysdig agent. These labels provide more precise identification of the entity or environment where the event occurred. Click Troubleshoot to open the PromQL Query page. The page is automatically populated with the alert rule’s expression at the exact time when the alert occurrence was triggered. Review the query result to investigate what caused the alert.\nInfrastructure Events: Includes Kubernetes Events, Container Events, and Custom EventsInfrastructure Events are any events that occur within your infrastructure. These include:\nKubernetes events Container events Custom events These events follow the same structure and are displayed using a consistent format in the Event Details panel.\nMetadata Description Event ID The unique ID of the event. Severity The severity of the event (High, Medium, Low, Info). Date / Time The date and time the event occurred. Source The source of the event (in this case, Kubernetes). Description The description of the event. Scope The scope of the event, identified as labelset Tags Any tags associated with the event ","url":"https://docs.sysdig.com/en/sysdig-monitor/review-events/"},{"id":669,"title":"Simple Queue Service (SQS)","content":"Amazon Simple Queue Service (Amazon SQS) is a pay-per-use web service for storing messages in transit between computers. Developers use SQS to build distributed applications with decoupled components without having to deal with the overhead of creating and maintaining message queues. For more information, see Amazon SQS Resources.\naws.sqs.ApproximateNumberOfMessagesDelayedThe number of messages in the queue that are delayed or currently unavailable for reading. Messages are stuck like this when the queue is configured as a delay queue or when a message has been sent with a delay parameter.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Avg Available Group Aggregation Formats Avg, Sum, Min, Max aws.sqs.ApproximateNumberOfMessagesNotVisibleThe number of undelivered messages. These messages are still in the queue, on their way to a client (in flight), but have not yet been deleted or have not yet reached the destination.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Avg Available Group Aggregation Formats Avg, Sum, Min, Max aws.sqs.ApproximateNumberOfMessagesVisibleThe number of messages available for retrieval from the queue. These are the messages which have not yet been locked by an SQS worker.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Avg Available Group Aggregation Formats Avg, Sum, Min, Max aws.sqs.NumberOfEmptyReceivesThe number of ReceiveMessage API calls that did not return a message. This metric is populated every 5 minutes.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.sqs.NumberOfMessagesDeletedThe number of messages deleted from the queue. Amazon SQS considers every successful deletion that uses a valid receipt handle, including duplicate deletions, to generate the NumberOfMessagesDeleted metric. Therefore, this number could include duplicate deletions.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.sqs.NumberOfMessagesReceivedThe number of messages returned by calls to the ReceiveMessage API action.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.sqs.NumberOfMessagesSentThe number of messages added to a queue.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max aws.sqs.SentMessageSizeThe size of messages in bytes added to a queue. The SentMessageSize does not display as an available metric in the CloudWatch console until at least one message is sent to the corresponding queue.\nMetadata Description Metric Type Counter Value Type Integer Segment By CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/sysdig-monitor/aws-metrics-legacy/simple-queue-service-sqs/"},{"id":670,"title":"Support Policy for Sysdig Shield","content":"Monthly Release CadenceSysdig updates Sysdig Shield approximately once a month. Each release may include new features, enhancements, defect fixes, performance improvements, and CVE fixes.\nVersioning SystemSysdig Shield uses semantic (X.Y.Z) versioning:\nMajor Versions (X): Often include major new features or functionality changes, and may also include bug fixes and CVE fixes. Significant updates may require changes to usage or configuration. Minor Versions (Y): Typically introduce new features and enhancements, expanding Sysdig Shield\u0026rsquo;s capabilities without disrupting existing configurations. May also include bug fixes and CVE fixes. Hoftix Versions (Z): Primarily focus on CVE fixes and bug fixes to improve the stability of major or minor releases. You can apply them without impacting current usage or configuration. Hotfix versions are rare and are only released to address any serious issues. Version SupportSysdig provides support for major and minor versions of Sysdig Shield for 12 months from their release date, regardless of whether the Shield is deployed with Sysdig SaaS or Sysdig on-premises. Support includes fixes for any issues, and If an issue is resolved in a later version of Shield, you must upgrade to that version to receive the fix.\nSysdig does not provide hotfixes, bug fixes, or CVE patches for any version other than the latest release. Customers using the on-premises version of Sysdig may be required to upgrade to the latest release to address certain issues.\nCustomers running Shield versions older than 12 months will not receive troubleshooting support for any issues and will be requested to upgrade to the latest versions of Sysdig before any troubleshooting is done. A patch version (Z) for a major or minor release will not reset the 12 month support clock.\nShield versions older than 12 months will no longer be compatible with the current Sysdig backend. You must upgrade to maintain connectivity and full feature support.\nVulnerabilitiesSysdig promptly addresses vulnerabilities in the Sysdig Agent and Shield. CVE fixes are provided in the a release within the following target timeframes (starting when a fix is available in a released package):\nCritical: 30 days High: 30 days Medium: 90 days Low: 180 days Sysdig does not provide CVE fixes as patches to older Shield releases.\nUpgrade OftenSysdig strongly recommends you upgrade Sysdig Shield at least once every 3 months to benefit from the latest enhancements, new features and CVE fixes.\nEnd of SupportAs part of our commitment to continuously improve the Sysdig platform, Sysdig may deprecate features or functionality over time.\nWhen a feature in Shield is scheduled for deprecation, Sysdig provides 12 months advance notice before the feature is removed. This notice period is intended to give you sufficient time to evaluate, plan, and transition to recommended alternatives, when available.\nFor details about deprecation, see Deprecation Policy.\n","url":"https://docs.sysdig.com/en/sysdig-secure/shield-support-policy/"},{"id":671,"title":"Troubleshooting CIEM","content":"SuggestionsCheck read AccessSysdig’s Identity and Access feature needs read access for specific resources such as Identity and Access Management (IAM) to function. Certain Amazon Web Services (AWS) policies block Sysdig from reading data:\nService control policies (SCP): Ensure there are no restrictions on read access to IAM. Certain region level policies that restrict everything to be read from that specific region. Check Role ProvisioningVerify the role provisioned for Sysdig is correct with this API.\nCheck Health of cloud-connectorFor AWS, verify the cloud-connector component is healthy by following these steps:\nIn the Sysdig Secure UI, navigate to Identity → Identity Overview.\nClick Learning Status in the top right corner.\nYour connected cloud accounts appear with the status of the cloud-connector and the last time Sysdig received an event listed.\nIf cloud-connector is Disconnected and the(Last Event Sent timestamp is older than a few hours, user activity will not be monitored. Please check logs and contact Sysdig support to help resolve the issue.\nLimitations Currently, only the identity-based policies (managed, inline, and group policies), Organization SCPs, and permission boundaries are considered for permission calculation. Resource-based, Access control lists (ACLs), and Session policies are not yet accounted for during permission calculations.\nAWS Last seen timeis based on GetServiceLastAccessedDetails. For more information, see Amazon\u0026rsquo;s documentation. The AWS permissions used by IAM identities is based on user activity observed in Cloudtrail logs. Currently, permissions used after assuming roles are not taken into account. ","url":"https://docs.sysdig.com/en/sysdig-secure/identity-troubleshooting/"},{"id":672,"title":"(Legacy) Create Per-Container Custom App Checks","content":" We are sunsetting application checks in favor of Monitoring Integrations.\nSee also Understanding the Agent Config Files for details on accessing and editing the agent configuration files in general.\nHow It WorksThe SYSDIG_AGENT_CONF variable stores a YAML-formatted configuration for your app check and will be used to match app check configurations.\nAll original app_checks are available, and the syntax is the same as for dragent.yaml. You can add the environment variable directly to the Docker file.\nExample with DockerfileThis example defines a per container app-check for Redis. Normally you would have a YAML formatted entry installed into the agent\u0026rsquo;s /opt/draios/etc/dragent.yaml file that would look like this:\napp_checks: - name: redis check_module: redisdb pattern: comm: redis-server conf: host: 127.0.0.1 port: \u0026#34;{port}\u0026#34; password: protected For the per-container method, convert and add the above entry to the Docker file via the SYSDIG_AGENT_CONF environment variable:\nFROM redis # This config file adds a password for accessing redis instance ADD redis.conf / ENV SYSDIG_AGENT_CONF { \u0026#34;app_checks\u0026#34;: [{ \u0026#34;name\u0026#34;: \u0026#34;redis\u0026#34;, \u0026#34;check_module\u0026#34;: \u0026#34;redisdb\u0026#34;, \u0026#34;pattern\u0026#34;: {\u0026#34;comm\u0026#34;: \u0026#34;redis-server\u0026#34;}, \u0026#34;conf\u0026#34;: { \u0026#34;host\u0026#34;: \u0026#34;127.0.0.1\u0026#34;, \u0026#34;port\u0026#34;: \u0026#34;6379\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;protected\u0026#34;} }] } ENTRYPOINT [\u0026#34;redis-server\u0026#34;] CMD [ \u0026#34;/redis.conf\u0026#34; ] Example with Docker CLIYou can add parameters starting a container with dockerrunusing-e/\u0026ndash;envflag or injecting it using orchestration systems like Kubernetes:\nPER_CONTAINER_CONF=\u0026#39;{ \u0026#34;app_checks\u0026#34;: [{ \u0026#34;name\u0026#34;: \u0026#34;redis\u0026#34;, \u0026#34;check_module\u0026#34;: \u0026#34;redisdb\u0026#34;, \u0026#34;pattern\u0026#34;: {\u0026#34;comm\u0026#34;: \u0026#34;redis-server\u0026#34;}, \u0026#34;conf\u0026#34;: { \u0026#34;host\u0026#34;: \u0026#34;127.0.0.1\u0026#34;, \u0026#34;port\u0026#34;: \u0026#34;6379\u0026#34;, \u0026#34;password\u0026#34;: \u0026#34;protected\u0026#34;} }] }\u0026#39; docker run --name redis -v /tmp/redis.conf:/etc/redis.conf -e SYSDIG_AGENT_CONF=\u0026#34;${PER_CONTAINER_CONF}\u0026#34; -d redis /etc/redis.conf ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacycreate-per-container-custom-app-checks/"},{"id":673,"title":"Airgapped Host Shield Installation","content":"However, if you are working in an airgapped environment, you will not be able to download these artifacts from the public internet. So before installing the Shield, you must compile sysdigcloud-probe-\u0026lt;suffix\u0026gt; for each kernel version in your environment and make it available to the installed Shield through an internally accessible URL.\nPrerequisites A machine with internet access where you can download the required artifacts A machine in your airgapped environment where you can build your probes Tool to transfer artifacts to the machine in your airgapped environment Docker installed OverviewSysdig provides a tool, named the probe builder, to help you build the probes for different kernels and for a specific Host Shield version. After downloading the required artifacts on a machine connected to the internet, you can copy them to an airgapped host, build your own probes, and make them available to your Host Shield installations.\nIf you are using Universal eBPF, skip probe building. You can directly install Host Shield based on your chosen product: Sysdig Monitor, Sysdig Secure, or both\nOperations in a Machine with Internet ConnectivityPrepare the Sysdig Probe Builder ImagesOn a machine with internet connectivity, build the Sysdig probe builder container images and create a tar file of the images.\nGet the probe builder source code from the repository:\n$ git clone https://github.com/draios/probe-builder Build the container image for the probe builder:\n$ docker build -t airgap/sysdig-probe-builder probe-builder/ Build the images for each supported distribution-compiler combination:\n$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock airgap/sysdig-probe-builder:latest -P -b airgap/ Running this command will create a different image tag for each supported combination of distribution-compiler, with the distro-compiler information suffixed to the image name, airgap/sysdig-probe-builder. For example, airgap/sysdig-probe-builder:centos-gcc4.8.\nSave all the above images to a tar archive:\n$ docker save airgap/sysdig-probe-builder | gzip \u0026gt; builders.tar.gz (optional) If you are building probes for the Ubuntu kernels, you will also need an ubuntu:latest image on your airgapped host. You can build it as follows:\n$ docker pull ubuntu $ docker save ubuntu | gzip \u0026gt; ubuntu.tar.gz Download the Kernel PackagesDownload your kernel packages. For more information, see Downloading Kernel Packages.\nDownload Probe Source CodeYou need to download the probe source code for a specific agent version you want to build your probes for.\nUpdate Agent 13.1.0\nStarting from Agent version 13.1.0 the probe source code has been separated into two archives, one for kmodule and the other one for ebpf (legacy eBPF). If you wish to build a legacy eBPF probe, for example for 13.1.0, use:\n$ AGENT_VERSION=13.1.0 $ curl -o agent-legacy-ebpf-${AGENT_VERSION}.tar.gz https://download.sysdig.com/stable/tgz/x86_64/draios-${AGENT_VERSION}-x86_64-agent-legacy-ebpf.tar.gz For example, for agent version 12.14.0 you would use:\n$ AGENT_VERSION=12.14.0 $ curl -o agent-kmodule-${AGENT_VERSION}.tar.gz https://download.sysdig.com/stable/tgz/x86_64/draios-${AGENT_VERSION}-x86_64-agent-kmodule.tar.gz Transfer the Downloaded FilesCopy the artifacts you have built and downloaded to the airgapped host machine:\nbuilders.tar.gz ubuntu.tar.gz (if needed, see above) agent-kmodule-${AGENT_VERSION}.tar.gz Downloaded kernel packages Operations in the Airgapped HostLoad the Builder Images$ zcat builders.tar.gz | docker load Unpack the Sysdig Source$ tar --transform=\u0026#39;s/^opt\\/draios\\/src\\///\u0026#39; -xzf agent-kmodule-${AGENT_VERSION}.tar.gz Running this command will create the draios-agent-${AGENT_VERSION}/ directory under the current directory (removing the opt/draios/src/ prefix from the path).\nMove the Kernel Packages to a Dedicated LocationMake sure you have all the downloaded kernel package artifacts in a single directory, /directory-containing-kernel-packages/, for each distribution you want to support.\nRun the Probe BuilderNow that you have all your requirements in place, you can run the main probe builder:\n$ AGENT_VERSION=12.14.0 $ docker run --rm \\ -v /var/run/docker.sock:/var/run/docker.sock \\ -v /a-directory-with-some-free-space/:/workspace \\ -v /wherever-you-unpacked/draios-agent-${AGENT_VERSION}/:/sysdig \\ -v /directory-containing-kernel-packages/:/kernels \\ airgap/sysdig-probe-builder:latest -B -b airgap/ -- \\ -p sysdigcloud-probe -v ${AGENT_VERSION} -k CustomCentOS The probes will appear in /a-directory-with-some-free-space/output. That directory must be served over HTTP or HTTPS. As an example, the following sections describe how you can deploy your own nginx server within your cluster and upload your probes there.\nServe Your Pre-Compiled ProbesSet up a local repository to host the pre-compiled kernel module. For example, use nginx with the following command:\n$ docker run --rm -v /a-directory-with-some-free-space/output:/usr/share/nginx/html/stable/sysdig-probe-binaries -p 80:80 nginx Note the host/port part of the URL and use it as the SYSDIG_PROBE_URL while installing the Host Shield.\nOperations on the HostsSysdig Host Shield Universal eBPF: If you\u0026rsquo;re using Universal eBPF, there\u0026rsquo;s no need to build probes. You can directly install Shield based on your chosen product: Sysdig Monitor , Sysdig Secure, or both. Kernel module (kmod): If you are using kmod: Prepare probe by following the instructions given in Operations in a Machine with Internet Connectivity Install Shield based on your chosen product: Sysdig Monitor , Sysdig Secure, or both. eBPF: If you are using legacy eBPF: Prepare probe by following the instructions given in Operations in a Machine with Internet Connectivity Install Shield based on your chosen product: Sysdig Monitor , Sysdig Secure, or both. For information on drivers, see Understand Agent Drivers.\nClassic AgentUse the Probes with the AgentTo use the probes with the Agent, you have to set the SYSDIG_PROBE_URL environment variable as the URL you\u0026rsquo;ve created above. This variable specifies the URL of the location where the Sysdig probes are available for download. This allows the Sysdig Shield to locate and download the locally compiled probe during startup.\nMake the necessary changes to the On-Prem Shield installation instructions as given below:\nHelm Docker Install Agent in a Kubernetes Environment Append the arguments below to your Helm install command.\nAgent Slim installation (default) --set agent.daemonset.kmodule.env.SYSDIG_PROBE_URL=http://www.mywebserver.net:80 Agent non-slim installation (\u0026ndash;set agent.slim.enabled=false) --set agent.daemonset.env.SYSDIG_PROBE_URL=http://www.mywebserver.net:80 Continue with the instructions in the On-Prem Agent Installation.\nInstall Agent in a Docker Environment Install Sysdig agent by pointing SYSDIG_PROBE_URL to the local repository:\nFor docker-based installations, add the following argument to the docker run command line:\n-e SYSDIG_PROBE_URL=http://www.mywebserver.net:80/ For instance, your docker run command line might look like the following:\ndocker run -d --name sysdig-agent --restart always --privileged --net host --pid host \\ -e ACCESS_KEY=WWWWW-YYYY-XXXX-ZZZZ-123456789 -e SECURE=true \\ -e SYSDIG_PROBE_URL=http://www.mywebserver.net:80/ \\ -v /var/run/docker.sock:/host/var/run/docker.sock \\ -v /dev:/host/dev \\ -v /proc:/host/proc:ro \\ -v /boot:/host/boot:ro \\ -v /lib/modules:/host/lib/modules:ro \\ -v /usr:/host/usr:ro \\ --shm-size=512m \\ sysdig/agent Where -e SYSDIG_PROBE_URL=http://www.mywebserver:80/ is the local nginx web server with the loaded module.\nNote: To use HTTPS communication with a self-signed or untrusted certificate, also add the -e SYSDIG_PROBE_INSECURE_DOWNLOAD=true environment variable to the above command line.\nCheck the agent log. If the installation is successful, you will see a message as follows:\nEvaluating override of environment variables Trying to download precompiled module from http://mywebserver:80/stable/sysdig-probe-binaries/sysdigcloud-probe-\u0026lt;version\u0026gt; Download succeeded ","url":"https://docs.sysdig.com/en/administration/onprem-airgapped-installation/"},{"id":674,"title":"Behavioral Analytics Changelog","content":" Commit Date\nRule Notes\nVersion\nMay 27, 2026\nRule Changes\nReduce FPs for WAF Enumeration Detected\nReduce FPs for Suspicious Actions After IAM Policy Enumeration Detected\nReduce FPs for Route53 Enumeration Detected\nReduce FPs for Resource Permissions Enumeration Detected\nReduce FPs for RDS Snapshot Enumeration\nReduce FPs for Network Enumeration Detected\nReduce FPs for Endpoint Enumeration Detected\nReduce FPs for EKS Clusters Enumeration Detected\nReduce FPs for EBS Volumes Enumeration Detected\nReduce FPs for CodeBuild Enumeration Detected\nstateful-1.29\nMay 05, 2026\nRule Changes\nReduce FPs for Suspicious SSM Parameters Retrieval Detected\nstateful-1.28\nApril 21, 2026\nRule Changes\nReduced FPs for Certificate Manager Enumeration Detected rule\nReduced FPs for CloudFormation Enumeration Detected rule\nReduced FPs for SNS Enumeration Detected rule\nReduced FPs for AWS Glue Enumeration Detected rule\nstateful-1.27\nMarch 18, 2026\nRelease update for JP1.\nstateful-1.26.1\nRule Changes\nReduce FPs for Route53 Enumeration Detected\nReduce FPs for Suspicious SSM Parameters Retrieval Detected\nstateful-1.26\nFebruary 24, 2026\nRule Changes\nReduce FPs for Route53 Enumeration Detected\nReduce FPs for Suspicious SSM Parameters Retrieval Detected\nstateful-1.26\nFebruary 03, 2026\nRule Changes\nReduce FPs for Suspicious SSM Parameters Retrieval Detected\nstateful-1.25\nJanuary 27, 2026\nRule Changes\nReduce FPs for AWS Transfer Family Enumeration Detected\nReduce FPs for High Number of Bedrock Model Invocations\nstateful-1.24\nJanuary 13, 2026\nRule Changes\nReduce FPs for S3 Storage Enumeration Detected\nReduce FPs for Endpoint Enumeration Detected\nstateful-1.23\nDecember 15, 2025\nstateful-1.22\nDecember 12, 2025\nRule Changes\nAdded Rule Possible EC2 Volume Exfiltration\nAdded Rule Suspicious RDS Snapshot Exported to S3\nstateful-1.21\nDecember 09, 2025\nRule Changes\nAdded Rule Possible EC2 Volume Exfiltration\nAdded Rule Suspicious RDS Snapshot Exported to S3\nstateful-1.21\nSeptember 11, 2025\nRule Changes\nReduced false positives for the following rules:\nSuspicious Actions After IAM Policy Enumeration Detected\nNetwork Enumeration Detected\nEndpoint Enumeration Detected\nLambda Enumeration Detected\nIAM Enumeration Detected\nSuspicious Fargate Cluster Created\nSuspicious SES Activity Detected\nstateful-1.20.2\nSeptember 09, 2025\nRule Changes\nFix Quotation Syntax with Escaped Characters\nstateful-1.20.1\nAugust 26, 2025\nRule Changes\nReduced false positives for the following rules:\nResource Permissions Enumeration Detected\nSuspicious Actions After IAM Policy Enumeration Detected\nIAM Enumeration Detected\nEKS Clusters Enumeration Detected\nSNS Enumeration Detected\nRDS Snapshot Enumeration\nLambda Enumeration Detected\nEndpoint Enumeration Detected\nEBS Volumes Enumeration Detected\nCognito Enumeration Detected\nAWS Glue Enumeration Detected\nstateful-1.19\nAugust 22, 2025\nRule Changes\nReduced false positives for the following rules:\nOrganization Enumeration Detected\nAccess Key Enumeration Detected\nNetwork Enumeration Detected\nEBS Volumes Enumeration Detected\nEndpoint Enumeration Detected\nHigh number of DescribeInstanceAttribute API calls for userData\nSuspicious Fargate Cluster Created\nSuspicious Actions After IAM Policy Enumeration Detected\nIAM Enumeration Detected\nSuspicious SES Activity Detected\nSuspicious SSM Parameters Retrieval Detected\nECS Tasks Enumeration Detected\nRoute53 Enumeration Detected\nSuspicious Secrets Retrieval from AWS Secrets Manager Detected\nstateful-1.18.1\nAugust 18, 2025\nRule Changes\nImproved condition for the following rules:\nLateral Movement using Roles for Privilege Escalation\nSuspicious OrganizationRole Cross-Account S3 Activity\nstateful-1.18\nAugust 05, 2025\nRule Changes\nImprove Condition for Route53 Enumeration Detected\nImprove Tags in Behavior Analysis rules\nstateful-1.17\nJuly 22, 2025\nRule Changes\nAdded rule AWS Transfer Family Enumeration Detected\nstateful-1.16\nJuly 22, 2025\nRule Changes\nAdded rule AWS Transfer Family Enumeration Detected\nstateful-1.16\nJuly 16, 2025\nRule Changes\nReduce false positives for Suspicious Files Deletion Activity on S3 Bucket Detected.\nstateful-1.15\nJuly 08, 2025\nRule Changes\nImproved output for cross-account stateful rules.\nstateful-1.14.0\nJune 17, 2025\nRule Changes\nAdded the following rules:\nSuspicious OrganizationRole Cross-Account S3 Activity\nLateral Movement using Roles for Privilege Escalation\nAWS VPN Enumeration Detected\nDefault Policy Changes\nAdded the following rules:\nSuspicious OrganizationRole Cross-Account S3 Activity\nLateral Movement using Roles for Privilege Escalation\nAWS VPN Enumeration Detected\nstateful-1.13\nJune 06, 2025\nRule Changes\nReduced false positives for Suspicious Actions After IAM Policy Enumeration Detected rule.\nstateful-1.12.1\nJune 02, 2025\nRule Changes\nReduce false positives for Stateful Rules:\nCognito Enumeration Detected\nSuspicious Actions After IAM Policy Enumeration Detected\nSuspicious SSM Parameters Retrieval Detected\nCertificate Manager Enumeration Detected\nRoute53 Enumeration Detected\nstateful-1.12\nMay 20, 2025\nRule Changes\nAdded the following rules:\nRDS Snapshot Enumeration\nSNS Enumeration Detected\nReduce false positives for Stateful Rules\nDefault Policy Changes\nAdded the following rules:\nRDS Snapshot Enumeration\nSNS Enumeration Detected\nstateful-1.11.0\nMay 14, 2025\nRule Changes\nReduced false positives related to Synk Cloud\nstateful-1.10.2\nApril 08, 2025\nRule Changes\nReduced security vendors FPs\nstateful-1.10.1\nApril 01, 2025\nWhat's Changed\nAdded the following rules:\nCertificate Manager Enumeration Detected\nEKS Clusters Enumeration Detected\nstateful-1.10.0\nMarch 27, 2025\nDefault Policy Changes\nRemoved rule IAM User Created Without Password Reset Enforcement from managed policy\nstateful-1.9.1\nMarch 25, 2025\nRule Changes\nAdded the following rules:\nAWS Glue Enumeration Detected\nECS Tasks Enumeration Detected\nDefault Policy Changes\nAdded the following rules:\nAWS Glue Enumeration Detected\nECS Tasks Enumeration Detected\nstateful-1.9.0\nMarch 18, 2025\nRule Changes\nAdded the following rules:\nDynamoDB Enumeration Detected\nECS Clusters Enumeration Detected\nEBS Volumes Enumeration Detected\nCodeBuild Enumeration Detected\nCognito Enumeration Detected\nDefault Policy Changes\nAdded the following rules:\nDynamoDB Enumeration Detected\nECS Clusters Enumeration Detected\nEBS Volumes Enumeration Detected\nCodeBuild Enumeration Detected\nCognito Enumeration Detected\nstateful-1.8.0\nMarch 11, 2025\nRule Changes\nImproved condition for the following rules:\nSuspicious Fargate Cluster Created/p\u003e Backup Enumeration Detected\nCloudFormation Enumeration Detected\nAPI Gateway Enumeration Detected\nAdded rule Route53 Enumeration Detected\nDefault Policy Changes\nAdded rule Route53 Enumeration Detected\nstateful-1.7.0\nFebruary 18, 2025\nRule Changes\nAdded the following rules:\nAccess Key Enumeration Detected\nAPI Gateway Enumeration Detected\nImproved condition for Suspicious Simulate Principal Policy Detected\nDefault Policy Changes\nAdded the following rules:\nAccess Key Enumeration Detected\nAPI Gateway Enumeration Detected\nChanged Managed Policy Simulate Principal Policy Detected\nstateful-1.6.0\nFebruary 13, 2025\nRule Changes\nAdded exceptions to stateful rules\nstateful-1.5.1\nFebruary 11, 2025\nRule Changes\nAdded the following rules:\nSuspicious Files Deletion Activity on S3 Bucket Detected\nHigh Number of Bedrock Model Invocations\nOrganization Enumeration Detected\nBackup Enumeration Detected\nIAM User Created Without Password Reset Enforcement\nImproved condition for the following rules:\nS3 Storage Enumeration Detected\nSuspicious SSM Parameters Retrieval Detected\nIAM Enumeration Detected\nWorkload Enumeration Detected\nHigh number of DescribeInstanceAttribute API calls for userData\nSuspicious Secrets Retrieval from AWS Secrets Manager Detected\nDefault Policy Changes\nAdded Managed Policy Sysdig AWS Behavioral Analytics Notable Events\nAdded the following rules:\nSuspicious Files Deletion Activity on S3 Bucket Detected\nHigh Number of Bedrock Model Invocations\nOrganization Enumeration Detected\nBackup Enumeration Detected\nIAM User Created Without Password Reset Enforcement\nstateful-1.5.0\nFebruary 04, 2025\nRule Changes\nImproved condition for Suspicious SES Activity Detected rule\nAdded the following rules:\nSuspicious Secrets Retrieval from AWS Secrets Manager Detected\nSuspicious Files Encryption Activity on S3 Bucket Detected\nSuspicious SSM Parameters Retrieval Detected\nHigh number of DescribeInstanceAttribute API calls for userData\nExecute Commands on EC2 Instance using User Data\nDefault Policy Changes\nAdded the following rules:\nSuspicious Secrets Retrieval from AWS Secrets Manager Detected\nSuspicious Files Encryption Activity on S3 Bucket Detected\nSuspicious SSM Parameters Retrieval Detected\nHigh number of DescribeInstanceAttribute API calls for userData\nExecute Commands on EC2 Instance using User Data\nstateful-1.4.0\nJanuary 28, 2025\nRule Changes\nAdded the following rules:\nSuspicious IAM Roles Anywhere Trust Anchor Created\nBedrock Enable and Invoke Model Detected\nSSM Shell Command Execution Detected\nImproved condition for the following rules:\nEndpoint Enumeration Detected\nSuspicious Actions After IAM Policy Enumeration Detected\nService Enumeration Detected\nNetwork Enumeration Detected\nCloudFormation Enumeration Detected\nDefault Policy Changes\nAdded the following rules:\nSuspicious IAM Roles Anywhere Trust Anchor Created\nBedrock Enable and Invoke Model Detected\nSSM Shell Command Execution Detected\nstateful-1.3.0\nJanuary 28, 2025\nRule Changes\nAdded the following rules:\nSuspicious IAM Roles Anywhere Trust Anchor Creation Detected\nBedrock Enable and Invoke Model Detected\nSSM Shell Command Execution Detected\nImproved condition for the following rules:\nEndpoint Enumeration Detected\nSuspicious Actions After IAM Policy Enumeration Detected\nService Enumeration Detected\nNetwork Enumeration Detected\nImproved condition CloudFormation Enumeration Detected\nDefault Policy Changes\nAdded the following rules:\nSuspicious IAM Roles Anywhere Trust Anchor Created\nBedrock Enable and Invoke Model Detected\nSSM Shell Command Execution Detected\nstateful-1.3.0\nJanuary 15, 2025\nRule Changes\nImproved condition for Suspicious Fargate Cluster Created.\nReduced false positives for CloudFormation Enumeration Detected.\nstateful-1.2.0\nNovember 26, 2024\nRule Changes\nMinor Reduce False Positives changes\nstateful-1.1.2\nNovember 14, 2024\nRule Changes\nImproved the Suspicious Actions after IAM Enumeration condition.\nstateful-1.1.1\nNovember 05, 2024\nRule Changes\nAdded the High number of GetPasswordData API callsrule.\nDefault Policy Changes\nAdded the High number of GetPasswordData API callsrule.\nstateful-1.1.0\nOctober 15, 2024\nRule Changes\nReduced false positives for enumeration rules.\nstateful-1.0.2\nOctober 05, 2024\nRule Changes\nRemoved false positives for multiple Behavioral Analytics rules.\nstateful-1.0.1\nOctober 02, 2024\nRule Changes\nAdded the following rules:\nSuspicious SES Activity Detected\nService Enumeration Detected\nSuspicious Privileged User Created\nSuspicious Fargate Cluster Created\nIAM Enumeration Detected\nWAF Enumeration Detected\nS3 Storage Enumeration Detected\nLambda Enumeration Detected\nCloudFormation Enumeration Detected\nSuspicious User with Static Password Created\nSuspicious Actions After IAM Policy Enumeration Detected\nEnvironment Variable Enumeration Detected\nEndpoint Enumeration Detected\nNetwork Enumeration Detected\nWorkload Enumeration Detected\nSuspicious Simulate Principal Policy Detected\nResource Permissions Enumeration Detected\nstateful-1.0.0\nSeptember 30, 2024\nThe first release of Behavioral Analytics.\n1.0.0\n","url":"https://docs.sysdig.com/en/release-notes/behavioral-analytics-changelog/"},{"id":675,"title":"Captures (Monitor)","content":"LimitationsThe Sysdig Agent can record only one capture per host at a time due to the volume of data collected. If multiple alerts, each configured to create a capture, are triggered simultaneously on the same host, only the first capture will be taken. This issue also occurs with overlapping captures, often caused by lengthy capture durations.\nAccess CapturesTo access the Captures:\nLog in to Sysdig Monitor.\nSelect Captures from the left navigation bar.\nNavigate CapturesThe Captures page contains a table listing the:\nStatus: When the status is Ok, the file has been successfully transmitted from the Sysdig agent to the storage bucket, and is available for download and analysis. Name: The capture file name. Time: The time the capture was taken. Duration: The period of time captured. Trigger: The cause that triggered the capture. Infrastructure: The host the capture was retrieved from. You can also search for captures using the search bar, or filter them by Error or Expiring.\nTake a CaptureThere are two ways to create a capture file:\nManually From an alert Take a Capture ManuallyTo take a capture manually:\nSelect Captures from the left navigation bar.\nSelect Take Capture from the top right corner.\nThe Take Capture window appears.\nSpecify the following information:\nName: Define the Name of the capture, also used as capture file name. Host Name: Specify the Host where you want to take a capture Container ID: Configure the Container ID to set as a predefined filter when you open the Capture using Sysdig Inspect. Storage: Choose your storage options. The default is Sysdig Storage, where captures are stored for 90 days. To configure alternative storage options, see Configure Capture Storage. Duration: Define the duration of the capture. The default time is 5 seconds; the maximum capture time available is 300 seconds (five minutes). The capture file size limit is 100MB.\nSysdig recommends using the default time to ensure captures are small and manageable. Filter: Optionally, set a filter for the capture. This restricts the data streaming captured (syscalls, i/o streams), while it doesn\u0026rsquo;t apply to the inspector tables (file descriptors, network connections, open ports, thread table, process list, containers). Applicable filters match the syntax for Falco conditions. See Condition Syntax. Click Start.\nThe capture is taken.\nAfter the capture is complete, select whether to Keep it or Discard the capture. Capture you keep are displayed in the Captures report page.\nTake a Capture from an AlertTo configure a capture to be taken when an alert triggers:\nSelect Alerts from the left navigation bar.\nSelect New Alert and select Threshold, Group Outlier or Downtime.\nCaptures cannot be configured for other alert types.\nAlternatively, edit an existing Threshold, Group Outlier, or Downtime alert.\nComplete the configuration under the Capture section:\nCapture Enabled: Toggle on or off. Capture Duration: The period of time captured. The default time is 15 seconds; the maximum capture time available is 24 hours. The capture file size limit is 100MB. The capture time starts from the time the alert threshold was breached. It does not capture syscalls from before the alert was triggered. We recommend using the default time to ensure captures are small and manageable. Capture Storage: The storage location for the capture files. The default is Sysdig Storage, where captures are stored for 90 days. To configure alternative storage options, see Configure Capture Storage. Capture Name: The name of the capture file. The default name includes the date and time stamp the capture was created. Capture Filter: Restricts the amount of trace information collected. The filter uses Falco syntax. For example, you can use container.id or container.name as a filter in the format container.id=123b12345678. The resulting capture would contain syscalls only for the specified container. The filter restricts only the data streaming captured (syscalls, i/o streams), while it doesn\u0026rsquo;t apply to the inspector tables (file descriptors, network connections, open ports, thread table, process list, containers). When the alert triggers, a capture will be taken. The capture can be viewed in the Sysdig Monitor Captures page.\nReview a CaptureFrom the Captures page you can perform multiple operations on the previously taken Captures:\nOpen with Sysdig Inspect Open Explore Go to the triggering Notification Download Delete Review a Capture with Sysdig InspectTo review the capture file with Sysdig Inspect:\nFrom the Captures page, navigate to the target capture file.\nHover your cursor over the target capture file.\nClick on the Sysdig Inspect button to open Sysdig Inspect in a new browser tab.\nExplore a Capture FileTo open a capture in Explore:\nFrom the Captures page, navigate to the target capture file.\nSelect the three-dot menu icon from the right hand side of the capture listing.\nSelect the Open in Explore button.\nYou will be directed to the Explore tab view of the capture.\nGo to the Capture related NotificationTo open the Notification related to the Capture:\nFrom the Captures page, navigate to the target capture file.\nSelect the three-dot menu icon from the right hand side of the capture listing.\nSelect the Open Notification button.\nYou will be directed to the Events page, where you will see the Notification that triggered the Capture.\nDownload a Capture FileTo download a capture file:\nFrom the Captures page, select the three-dot menu on the side of a capture listing.\nSelect Download File.\nThe capture downloads in .scap format. You can open this with:\nSysdig Inspect sysdig or csysdig Delete a Capture FileYou can delete a single capture file or multiple files.\nTo delete a single file:\nFrom the Captures page, navigate to the target capture file.\nHover your cursor over the target capture file.\nSelect the three-dot menu icon from the right hand side of the capture listing.\nSelect the Delete (trash can) button.\nClick Delete to confirm deleting the capture, or No to cancel.\nTo delete multiple files:\nFrom the Captures page, select the capture files to be deleted.\nSelect the option Delete next to the number of selected captures in the top right corner.\nOn the Delete Captures prompt, click the Yes button to confirm, or the No button to cancel.\nDelete Capture FilesCaptures saved in the Sysdig Storage older than 90 days will be automatically deleted. For longer storage, configure a custom S3 storage bucket. See Configure AWS Capture File Storage.\nYou can also delete Captures manually.\nDisable Capture FunctionalitySometimes, security requirements dictate that capture functionality should not be triggered at all (for example, PCI compliance for payment information).\nTo disable Captures altogether, edit the agent configuration file as described in Disable Captures.\nCapture Files StorageSysdig capture files are stored in Sysdig\u0026rsquo;s storage (for SaaS environments), or in the Cassandra DB (for on-premises environments) by default. Captures saved in the Sysdig Storage (SaaS environments) for more than 90 days are automatically deleted. Both environments have the option to use a S3-compatible custom storage, such as Minio or IBM Cloud Object Storage. This lets you store captures for longer periods of time. To configure a custom storage, see S3 Capture Storage.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/captures/"},{"id":676,"title":"Deprecation Notes","content":" Application Deprecated functionality Announcement Deprecation date Sysdig Platform cloud-connector May 26, 2026 May 26, 2027 Host Shield \u0026amp; Agent Legacy eBPF driver Dec 4, 2025 Dec 4, 2026 Host Shield \u0026amp; Agent Agent Secure mode Dec 4, 2025 Dec 4, 2026 Host Shield \u0026amp; Agent container_engines Dec 4, 2025 Dec 4, 2026 Host Shield \u0026amp; Agent Support for Mesos metrics August 28, 2025 August 28, 2026 Host Shield \u0026amp; Agent Agent Monitor Light mode Aug 27, 2025 Aug 27, 2026 SaaS - Sysdig Secure Terraform properties in AWS \u0026amp; GCP Onboard Jul 1, 2025 Nov 30, 2025 Host Shield \u0026amp; Agent Linux Kernel prior to 3.10 Feb 1, 2025 June 17, 2025 Host Shield \u0026amp; Agent Custom App Checks Feb 1, 2025 June 17, 2025 Host Shield \u0026amp; Agent Support for Python 2.7 Feb 1, 2025 June 17, 2025 Serverless Agent Serverless Orchestrator Agent Dec 17, 2024 Aug 1, 2025 SaaS - Sysdig Secure Legacy Scanning Engine July 18, 2025 July 18, 2025 Host Shield Support for RHEL6 and CentOS6 Feb 1, 2024 March 1, 2024 For migration support and guidance, contact Customer Success.\nThe dates below refer to the deprecation date of features and applications.\nMay 26, 2027Cloud ConnectorCloud connector has been replaced by Cloud Account Threat detection.\nMarch 31, 2027Zones Public API v1 and Terraform Zones v1 modelZones Public API v1 endpoints at /v1/zones are now deprecated and will be removed on this date. All integrations should use /v2/zones instead, as documented in the Zones section of the Sysdig Public API documentation.\nThe Zones v1 model in the Terraform provider is also deprecated. Any sysdig_secure_zone configuration that relies on legacy rules-based scopes with v1-only fields (for example, labels, labelValues, agentTags) will no longer be supported. Instead, use the expression-based v2 model in sysdig_secure_zone as documented in the Terraform provider.\nFor migration guidance, contact Sysdig Support.\nDecember 04, 2026Legacy eBPF DriverStarting with version 14.3.0, no new features will be introduced for the Legacy eBPF driver. The driver will retire on December 04, 2026.\nSecure ModeSecure Mode is deprecated and will retire on December 04, 2026. To ensure continued support and improved performance, migrate to Secure_Light mode.\nConfiguration KeysThe following configuration keys are deprecated and will be removed in an upcoming release:\ncontainer_engines.docker container_engines.podman container_engines.cri container_size_request.enabled Replace these keys with the following:\ncontainer_runtime.docker.enabled container_runtime.podman.enabled container_runtime.cri.enabled container_runtime.size_request_enabled In accordance with our support policy, support for these keys will be fully removed within 12 months. Update your configurations to ensure compatibility with future releases.\nFebruary 28, 2026List Matching Policies and Rules SupportList matching Policies and Rules will not be supported anymore. Starting from this date, all the List matching Policies and Rules will be deleted.\nIn place of List matching, you can use Falco Workload Policies and rules. You can convert existing List matching Policies and Rules using the guide here.\nDecember 15, 2025List Matching Policies and Rules CreationYou will not be able to create new List matching Policies and Rules. In place of those, we suggest using Falco. It\u0026rsquo;s more versatile and helps you create more valuable detections.\nExisting Policies and rules will continue working until further notice. It is also possible to continue modifying existing policies and rules.\nWe encourage you to start converting your existing List matching Policies and Rules to rely on Falco using the guide here.\nNov 30, 2025Terraform properties in AWS \u0026amp; GCP OnboardIf you onboarded your AWS accounts before Selective Cloud Account Onboarding was introduced, your Terraform or CFT configuration may include organizational_unit_ids or org_units. Contact your Sysdig support representative for guidance on transitioning to include_ouids and exclude_ouids.\nIf you onboarded your GCP accounts before Selective Cloud Account Onboarding was introduced, your Terraform configuration may include management_group_ids. Contact your Sysdig support representative for guidance on transitioning to include_folders and exclude_folders.\nCLI Scanners version 1.3.0 and earlierSysdig CLI Scanner versions 1.3.0 and earlier will no longer be able to submit scan results to the Sysdig backend. All external-facing endpoints that support these scanners will be decommissioned across all regions. Upgrade your CLI scanner to the latest available version to have continuous support.\nSept 30, 2025Container ID as Primary Identifier in Vulnerability Management Scanning:We are deprecating the use of Container ID as the unique identifier for vulnerabilities within Host Scanning when Container Scanning is enabled.\nPreviously, vulnerabilities were tracked and counted using Container ID. This meant that even if the same container image or workload was restarted, each new Container ID would be counted separately and generate a new scan result.\nNow, vulnerabilities are correlated using a combination of Hostname, Container Name, and Image ID. This provides a stable identifier across restarts and ensures more accurate correlation of Software Bill of Materials (SBOM) to running container workloads.\nImpactAs the change rolls out, the following impact is expected:\nVulnerability counts in dashboards will change. They may temporarily spike due to the changeover and new identification of vulnerabilities and resources. This will normalize after the switch and the old results drop off. Once the change is fully in effect, vulnerability counts will appear lower, as duplicate entries tied to container restarts or redeploys are eliminated. BenefitsThis update grants the following benefits:\nReduced noise and clearer vulnerability data, as containers will no longer be overcounted. Improved accuracy as vulnerabilities will be tied to Host, Container Name, and Image ID. TimelineSeptember 30th, 2025: Container ID support will be fully deprecated and begin rollout to all environments. After this date, all vulnerability identifiers will use Hostname + Container Name + Image ID.\nRecommended ActionsNo customer action is required. Dashboards and reports will automatically reflect the new identifier model by the deprecation date.\nAug 1, 2025Serverless Orchestrator AgentThe Orchestrator Agent entered its deprecation phase with Serverless Agent 5.3.0 and is set to be fully deprecated by Aug 1, 2025.\nAfter this date, it will no longer receive updates, including development, maintenance, bug fixes, or security patches. For guidance on migrating from the Orchestrator, please refer to Migrating from Orchestrator.\nJuly 18, 2025Legacy Scanning EngineAs part of our ongoing efforts to improve performance, security, and reliability, we are officially deprecating the Legacy Scanning Engine.\nOn July 18, 2025, the following actions will take place:\nThe Legacy Scanning Engine UX pages will be removed from the platform.\nAll related backend services will begin shutting down.\nWe will no longer provide support for the Legacy Scanning Engine in any SaaS region after this date.\nNo further maintenance, updates, or bug fixes will be delivered.\nSaaS users will no longer have access to Legacy Scanning Engine functionality via the user interface or APIs.\nAny workflows or integrations that depend on this engine will cease to function.\nWe recommend all customers transition to our current scanning solution as soon as possible to ensure uninterrupted service and continued support. For details, see Vulnerability Management.\nJune 17, 2025Linux Kernel prior to 3.10The minimum supported Linux kernel version is 3.10.\nUsers running older kernel versions should plan to upgrade to maintain compatibility and support.\nSupport for Python 2.7Python 2.7 reached its official End of Life in January 2020, to enhance security, stability, and performance, support for Python 2.7 has been discontinued.\nSysdig recommends updating to a supported Python version.\nCustom App ChecksTo improve Sysdig Monitor\u0026rsquo;s functionality and streamline integrations, Sysdig has now sunset Custom App Checks\nSysdig strongly recommends transitioning to Monitoring Integrations for better performance and support.\nMarch 1, 2024Support for RHEL6 and CentOS6As part of Sysdig Agent 13.0.0 release Sysdig dropped the support for RHEL6 and CentOS6, all the customer that are affected has received communication from their Sysdig rappresentative.\nOn-prem installations remain supported until individual account contracts are expired. Sysdig is also committed to supporting feeds for those environments.\n","url":"https://docs.sysdig.com/en/deprecation/"},{"id":677,"title":"Feeds Status","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nTo review the Feeds Status:\nNavigate to the Settings menu in the Sysdig Secure UI.\nSelect Feeds Status.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/feeds-status/"},{"id":678,"title":"Forwarding to Google PubSub","content":"PrerequisitesEvent forwards originate from region-specific IPs. For the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle event forwarding.\nNOTE: The permissions for the service account must be either Editor or Admin. Publisher is not sufficient.\nConfigure Standard Integration Log in to Sysdig Secure as Admin and go to Integrations \u0026gt; Add Integrations.\nSearch and choose Google Pub/Sub.\nConfigure the required options:\nIntegration Name: Define an integration name.\nProject: Enter the Cloud Console project name you created in Google Pub/Sub.\nTopic: Enter the Topic Name you created.\nJSON Credentials: Enter the Service Account credentials you created.\nAttributes: If you have chosen to embed custom attributes as metadata in Pub/Sub messages, enter them here.\nOrdering Key: If you chose to have subscribers receive messages in order, enter the ordering key information you set up.\nData to Send: Select from the drop-down the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled.\nToggle the enable switch as necessary. Remember that you will need to \u0026ldquo;Test Integration\u0026rdquo; with the button below before enabling the integration.\nClick Save. Configure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description PUBSUB project yes string project hosting the target pub/sub PUBSUB topic yes string pub/sub topic onto which publish the data PUBSUB credentialsJSON yes string credentials JSON file content used to authenticate as a service account in the project PUBSUB attributes no sequence of mappings Extra headers to add to the request. Each header mapping requires 2 keys: “key” for the header key and “value” for its value PUBSUB orderingKey no string The key to use to order the messages. Required to enable ordered delivery ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forward-to-google-pubsub/"},{"id":679,"title":"HAProxy","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nHAProxy SetupThe stats feature must be enabled on your HAProxy instance. This can be done by adding the following entry to the HAProxy configuration file /etc/haproxy/haproxy.cfg\nlisten stats bind :1936 mode http stats enable stats hide-version stats realm Haproxy\\ Statistics stats uri /haproxy_stats stats auth stats:stats Sysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with HAProxy and collect haproxy metrics:\napp_checks: - name: haproxy pattern: comm: haproxy port: 1936 conf: username: stats password: stats url: http://localhost:1936/ collect_aggregates_only: True log_errors: false You can get a few additional status metrics by editing the configuration in dragent.yaml,as in the following examples.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml\nExample: Collect Status Metrics Per ServiceEnable the collect_status_metrics flag to collect the metrics haproxy.count_per_status, and haproxy.backend_hosts.\napp_checks: - name: haproxy pattern: comm: haproxy port: 1936 conf: username: stats password: stats url: http://localhost:1936/haproxy_stats collect_aggregates_only: True collect_status_metrics: True log_errors: false Example: Collect Status Metrics Per HostEnable:\ncollect_status_metrics_by_host: Instructs the check to collect status metrics per host, instead of per service. This only applies if `collect_status_metrics` is true.\ntag_service_check_by_host: When this flag is set, the hostname is also passed with the service check \u0026lsquo;haproxy.backend_up\u0026rsquo;.\nBy default, only the backend name and service name are associated with it.\napp_checks: - name: haproxy pattern: comm: haproxy port: 1936 conf: username: stats password: stats url: http://localhost:1936/haproxy_stats collect_aggregates_only: True collect_status_metrics: True collect_status_metrics_by_host: True tag_service_check_by_host: True log_errors: false Example: Collect HAProxy Stats by UNIX SocketIf you\u0026rsquo;ve configured HAProxy to report statistics to a UNIX socket, you can set the url in dragent.yaml to the socket\u0026rsquo;s path (e.g., unix:///var/run/haproxy.sock).\nSet up HAProxy Config FileEdit your HAProxy configuration file ( /etc/haproxy/haproxy.cfg ) to add the following lines to the global section:\nglobal [snip] stats socket /run/haproxy/admin.sock mode 660 level admin stats timeout 30s [snip] Edit dragent.yaml urlAdd the socket URL from the HAProxy config to the dragent.yaml file:\napp_checks: - name: haproxy pattern: comm: haproxy conf: url: unix:///run/haproxy/admin.sock log_errors: True Metrics Available\nSee HAProxy Metrics.\nExample: Enable Service CheckRequired: Agent 9.6.0+\nenable_service_check: Enable/Disable service check haproxy.backend.up.\nWhen set to false , all service checks will be disabled.\napp_checks: - name: haproxy pattern: comm: haproxy port: 1936 conf: username: stats password: stats url: http://localhost:1936/haproxy_stats collect_aggregates_only: true enable_service_check: false Example: Filter Metrics Per ServiceRequired: Agent 9.6.0+\nservices_exclude (Optional): Name or regex of services to be excluded.\nservices_include (Optional): Name or regex of services to be included\nIf a service is excluded with services_exclude, it can still be be included explicitly by services_include. The following example excludes all services except service_1 and service_2.\napp_checks: - name: haproxy pattern: comm: haproxy port: 1936 conf: username: stats password: stats url: http://localhost:1936/haproxy_stats collect_aggregates_only: true services_exclude: - \u0026#34;.*\u0026#34; services_include: - \u0026#34;service_1\u0026#34; - \u0026#34;service_2\u0026#34; Additional Options: active_tag, headersRequired: Agent 9.6.0+\nThere are two additional configuration options introduced with agent 9.6.0:\nactive_tag (Optional. Default: false):\nAdds tag active to backend metrics that belong to the active pool of connections.\nheaders (Optional):\nExtra headers such as auth-token can be passed along with requests.\napp_checks: - name: haproxy pattern: comm: haproxy port: 1936 conf: username: stats password: stats url: http://localhost:1936/haproxy_stats collect_aggregates_only: true active_tag: true headers: \u0026lt;HEADER_NAME\u0026gt;: \u0026lt;HEADER_VALUE\u0026gt; \u0026lt;HEADER_NAME\u0026gt;: \u0026lt;HEADER_VALUE\u0026gt; Result in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/haproxy/"},{"id":680,"title":"Heuristic Metrics","content":"Additional heuristic metric details are listed below:\nMetric Metric in Legacy Format host_net_http_request_time container_net_http_request_time net.http.request.time host_net_http_request_count\ncontainer_net_http_request_count net.http.request.count host_net_http_error_count container_net_http_error_count net.http.error.count host_net_sql_request_time container_net_sql_request_time net.sql.request.time host_net_sql_request_count container_net_sql_request_count net.sql.request.count host_net_sql_error_count container_net_sql_error_count net.sql.error.count host_net_mongodb_request_time container_net_mongodb_request_time net.mongodb.request.time host_net_mongodb_request_count container_net_mongodb_request_count net.mongodb.request.count host_net_mongodb_error_count container_net_mongodb_error_count net.mongodb.error.count sysdig_host_net_request_time\nsysdig_container_net_request_time\nsysdig_program_net_request_time sysdig_connection_net_request_time net.request.time sysdig_host_net_request_in_time\nsysdig_container_net_request_in_time\nsysdig_program_net_request_in_time\nsysdig_connection_net_request_in_time net.request.time.in sysdig_host_net_request_out_time\nsysdig_container_net_request_out_time\nsysdig_program_net_request_out_time sysdig_connection_net_request_out_time net.request.time.out sysdig_host_net_request_count\nsysdig_container_net_request_count sysdig_program_net_request_count sysdig_connection_net_request_count net.request.count sysdig_host_net_request_in_count sysdig_container_net_request_in_count sysdig_program_net_request_in_count sysdig_connection_net_request_in_count net.request.count.in ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/heuristic-metrics/"},{"id":681,"title":"Host","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nagent.id Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A agent.modeFor more information on agent modes, see Configure Agent Modes.\nMetadata Description Metric Type String Value Type String Segment By Host Default Time Aggregation concat Available Time Aggregation Formats concat, distinct, count Default Group Aggregation concat Available Group Aggregation Formats concat, distinct, count agent.version Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cpu.core Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.container.mappings Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.count Metadata Description Metric Type Gauge Value Type Integer Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max host.domain Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.hostName Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.ip.all Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.ip.private Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.ip.public Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.isClientServer Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.isInstrumented Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.isInternal Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.mac Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.procList.main Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A host.unamehost.uname provides the following system information:\nkernel name\nkernel release number\nkernel version\nmachine hardware name\nAgents send this metric along with a number of labels that map with the uname information. host.uname is supported on agent versions 10.1 and above.\nMetrics Details Metadata Description Metric Type Gauge Value Type Integer Segment By See Segmentation Details. Default Time Aggregation Average Available Time Aggregation Average, Rate, Sum, Min, Max, Rate of Change Default Group Aggregation Average Available Group Rollup Average, Sum, Min, Max Segmentation DetailsThe labels are given below:\nLabel Description Mapping to the uname tooling Example host.uname.kernel.name The kernel name uname -s Linux host.uname.kernel.release The kernel release uname -r 5.4.0-31-generic host.uname.kernel.version The kernel version uname -v #35-Ubuntu SMP Thu May 7 20:20:34 UTC 2020 host.machine The hardware name of the machine uname -m x86_64 Example: Kernel Versions in the InfrastructureThe image depicts host.uname being segmented by host.uname.kernel.version. The resulting dashboard gives the distribution of kernel versions in the infrastructure.\nCount Limits StasD MetricsThe count limits metrics report the upper limit of the number of metrics of the same type. The values the metrics report can be changed by modifying the dragent.yaml file.\nMetric Name Configuration Parameter in the dragent.yaml file Default Value metricCount.limit.appCheck app_checks_limit 500 metricCount.limit.statsd statsd.limit 100 metricCount.limit.jmx jmx.limit 500 metricCount.limit.prometheus prometheus.max+metrics 3000 metricCount.appCheck Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A metricCount.jmx Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A metricCount.statsd Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A metricCount.prometheus Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/host/"},{"id":682,"title":"HTTP Metrics","content":"See Application Integrations for more information.\nhttp.ssl.days_leftThe number of days until the SSL certificate expires.\nnetwork.http.response_timeThe response time of a HTTP request to a specified URL.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/http-metrics/"},{"id":683,"title":"Identity Overview","content":" Deprecation Notice Upcoming Changes to Sysdig Product Line\nThe legacy Identity pages are now deprecated and will be phased out over a transition period. During this time, both the legacy and new experiences will remain available. We encourage you to start using the new Attack Surface \u0026gt; Identity Findings pages to become familiar with the updated experience.\nAccess the OverviewTo access Identity Findings, log in to Sysdig Secure and select Attack Surface \u0026gt; Identity Findings from the left navigation bar.\nLearning StatusThe Learning Status panel in the upper right corner indicates several possible states for each registered account:\nDisconnected: A cloud account is Disconnected if no successful scan has ever occurred. In Progress: A cloud account is In Progress when the account was connected less than 90 days prior. This ensures that the user activity has been profiled for a meaningful amount of time. Completed: If not disconnected nor in progress, the account learning status is Completed. FilterFilter by Zones, Platforms and Cloud Accounts.\nUse of the Region scope may result in more data being shown to users in the Identity pages than defined in the Zone.\nReviewUse the graphic displays to get a birds-eye view of the most important identity and access findings in your environment. Each panel highlights a particular focus area and is interactively linked to the appropriate sub-page to take action.\nThe highlights are grouped by:\nIdentity Posture overall, featuring Inactive Groups, Roles, Policies, and Resources; Admin Groups and Admin Roles, and Users without MFA (multi-factor authentication).\nPermissions featuring top unused permissions to remediate, by Groups, Policies, Roles, and Users\nRisk by User Findings\nAccess Distribution for Read/Write/Admin access for Roles, Users, Groups, and Policies\nCSV DownloadUse the Download CSV button given in each page of the Identity module to retrieve the page data in a spreadsheet.\nIf your Chrome browser is set to disallow downloading multiple files from a site, you may only get one CSV download and then a “blocked” message in the Chrome address bar.\nYou can click the message to access and change the browser setting.\n","url":"https://docs.sysdig.com/en/sysdig-secure/identity-overview/"},{"id":684,"title":"Integrate JMX Metrics from Java Virtual Machines","content":"The following applications are supported by default:\nActiveMQ Cassandra Elasticsearch HBase Kafka Tomcat Zookeeper The agent can also be easily configured to extract custom JMX metrics coming from your own Java processes. Metrics extracted are shown in the pre-defined Application views or under the Metrics \u0026gt; JVM and JMX menus.\nThe module java.management must be loaded for the Sysdig agent to collect both JVM and JMX metrics.\nThe default JMX metrics configuration is found in the /opt/draios/etc/dragent.default.yaml file. When customizing existing entries, copy the complete application\u0026rsquo;s bean listing from that defaults yaml file into the user settings file /opt/draios/etc/dragent.yaml. The Sysdig agent will merge configurations of both files.\nJava versions 7 - 10 are currently supported by the Sysdig agents.\nFor Java 11-14 you must be running minimum agent version 10.1.0 and must run the app with the JMX Remote option.\nHere is what your dragent.yaml file might look like for a customized entry for the Spark application:\ncustomerid: 07c948-your-key-here-006f3b tags: local:nyc,service:db3 jmx: per_process_beans: spark: pattern: \u0026#34;spark\u0026#34; beans: - query: \u0026#34;metrics:name=Spark shell.BlockManager.disk.diskSpaceUsed_MB\u0026#34; attributes: - name: VALUE alias: spark.metric Include the jmx: and per_process_beans: section headers at the beginning of your application/bean list. For more information on adding parameters to a container agent\u0026rsquo;s configuration file, see Configure Sysdig Agent.\nBean ConfigurationBasic JVM metrics are pre-defined inside the default_beans: section. This section is defined in the agent\u0026rsquo;s default settings file and contains beans and attributes that are going to be polled for every Java process, like memory and garbage collector usage:\njmx: default_beans: - query: \u0026#34;java.lang:type=Memory\u0026#34; attributes: - HeapMemoryUsage - NonHeapMemoryUsage - query: \u0026#34;java.lang:type=GarbageCollector,*\u0026#34; attributes: - name: \u0026#34;CollectionCount\u0026#34; type: \u0026#34;counter\u0026#34; - name: \u0026#34;CollectionTime\u0026#34; type: \u0026#34;counter\u0026#34; Metrics specific for each application are specified in sections named after the applications. For example, this is the Tomcat section:\nper_process_beans: tomcat: pattern: \u0026#34;catalina\u0026#34; beans: - query: \u0026#34;Catalina:type=Cache,*\u0026#34; attributes: - accessCount - cacheSize - hitsCount - . . . The key name, tomcat in this case, will be displayed as a process name in the Sysdig Monitor user interface instead of just java. The pattern: parameter specifies a string that is used to match a java process name and arguments with this set of JMX metrics. If the process main class full name contains the given text, the process is tagged and the metrics specified in the section will be fetched.\nThe class names are matched against the process argument list. If you implement JMX metrics in a custom manner that does not expose the class names on the command line, you will need to find a pattern which conveniently matches your java invocation command line.\nThe beans: section contains the list of beans to be queried, based on JMX patterns. JMX patterns are explained in details in the Oracle documentation, but in practice, the format of the query line is pretty simple: you can specify the full name of the bean like java.lang:type=Memory , or you can fetch multiple beans in a single line using the wildcard * as in: java.lang:type=GarbageCollector,* (note that this is just a wildcard, not a regex).\nTo get the list of all the beans and attributes that your application exports, you can use JVisualVM, Jmxterm, JConsole or other similar tools. Here is a screenshot from JConsole showing where to find the namespace, bean and attribute (metric) information (JConsole is available when you install the Java Development Kit):\nFor each query, you have to specify the attributes that you want to retrieve, and for each of them a new metric will be created. We support the following JMX attributes types (For these attributes, all the subattributes will be retrieved):\nNumeric\nCompositeDataSupport\nAttributes may be absolute values or rates. For absolute values, we need to calculate a per second rate before sending them. In this case, you can specify type: counter , the default is rate which can be omitted, so usually you can simply write the attribute name.\nLimitsThe total number of JMX metrics polled per host is limited to 500. The maximum number of beans queried per process is limited to 300. If more metrics are needed please contact your sales representative with your use case.\nIn agents 0.46 and earlier, the limit was 100 beans for each process.\nAliasesJMX beans and attributes can have very long names. To avoid interface cluttering we added support for aliasing, you can specify an alias in the attribute configuration. For example:\ncassandra: pattern: \u0026#34;cassandra\u0026#34; beans: - query: \u0026#34;org.apache.cassandra.db:type=StorageProxy attributes: - name: RecentWriteLatencyMicros alias: cassandra.write.latency - name: RecentReadLatencyMicros alias: cassandra.read.latency In this way the alias will be used in Sysdig Monitor instead of the raw bean name. Aliases can be dynamic as well, getting data from the bean name - useful where you use pattern bean queries. For example, here we are using the attribute name to create different metrics:\n- query: \u0026#34;java.lang:type=GarbageCollector,*\u0026#34; attributes: - name: CollectionCount type: counter alias: jvm.gc.{name}.count - name: CollectionTime type: counter alias: jvm.gc.{name}.time This query will match multiple beans (All Garbage collectors) and the metric name will reflect the name of the Garbage Collector. For example: jvm.gc.ConcurrentMarkSweep.count . General syntax is: {\u0026lt;bean_property_key\u0026gt;} , to get all beans properties you can use a JMX explorer like JVisualVM or Jmxterm.\nTo use these metrics in promQL queries, you have to add the prefix jmx_ and replace the dots (.) from metrics name by underscores (_). For example, the metric name jvm.gc.ConcurrentMarkSweep.count will be jmx_jvm_gc_ConcurrentMarkSweep_count in promQL.\nCollect JMX LabelsYou can configure dragent.yaml to collect labels from Java processes.\njmx: per_process_beans: equinoxTest: pattern: org.eclipse.equinox beans: - query: java.lang:type=Memory attributes: - name: \u0026#34;*\u0026#34; alias: test_attributes_{sysdigAttribute} subattributes: - name: \u0026#34;*\u0026#34; labels: - key: type value: \u0026#34;{type}\u0026#34; - key: attribute value: \u0026#34;{sysdigAttribute}\u0026#34; - key: subattribute value: \u0026#34;{sysdigSubattribute}\u0026#34; - key: foo value: bar where org.eclipse.equinox is a string in the main class of a Java process.\nFor each attribute of the java.lang:type=Memory bean, there is an associated alias in the format test_attributes_{sysdigAttribute}, where {sysdigAttribute} represents the attribute name. Additionally, several labels are attached to each subattribute when the attribute is a CompositeData. The agent substitutes the placeholders such as {type}, {sysdigAttribute}, and {sysdigSubattribute} with the actual values.\nTroubleshooting: Why Can\u0026rsquo;t I See Java (JMX) Metrics?The Sysdig agent normally auto-discovers Java processes running on your host and enables the JMX extensions for polling them.\nJMX RemoteIf your Java application is not discovered automatically by the agent, try adding the following parameter on your application\u0026rsquo;s command line:\n-Dcom.sun.management.jmxremote For more information, see Oracle\u0026rsquo;s web page on monitoring using JMXvtechnology.\nJava Versions Java versions 7 - 10 are currently supported by the Sysdig agents.\nFor Java 11-14 you must be running minimum agent version 10.1.0 and must run the app with the JMX Remote option.\nJava-Based Applications and JMX AuthenticationFor Java-based applications (Cassandra, Elasticsearch, Kafka, Tomcat, Zookeeper and etc.), the Sysdig agent requires the Java runtime environment (JRE) to be installed to poll for metrics (beans).\nThe Sysdig agent does not support JMX authentication.\nIf the Docker-container-based Sysdig agent is installed, the JRE is installed alongside the agent binaries and no further dependencies exist. However, if you are installing the service-based agent (non-container) and you do not see the JVM/JMX metrics reporting, your host may not have the JRE installed or it may not be installed in the expected location: usr/bin/java\nTo confirm if the Sysdig agent is able to find the JRE, restart the agent with service dragent restart and check the agent\u0026rsquo;s /opt/draios/logs/draios.log file for the two Java detection and location log entries recorded during agent startup.\nExample if Java is missing or not found:\n2017-09-08 23:19:27.944, Information, java detected: false 2017-09-08 23:19:27.944, Information, java_binary: Example if Java is found:\n2017-09-08 23:19:27.944, Information, java detected: true 2017-09-08 23:19:27.944, Information, java_binary: /usr/bin/java If Java is not installed, the resolution is to install the Java Runtime Environment. If your host has Java installed but not in the expected location ( /usr/bin/java ) you can install a symlink from /usr/bin/java to the actual binary OR set the java_home: variable in the Sysdig agent\u0026rsquo;s configuration file: /opt/draios/etc/dragent.yaml\njava_home: /usr/my_java_location/ Add Arbitrary Java Command NamesYou can specify the command names to launch Java processes. This helps agent to detect Java processes for JMX metric collection.\nFor example, if you want the agent to detect a process by the name of jsivm , while still detecting the other commands, you should add the following to dragent.yaml:\njmx: java_commands: - java - jsvc - jsivm The values specified in dragent.yaml will override the default values, therefore, you need to include the defaults if you wish to continue detecting them.\nDisabling JMX PollingIf you do not need it or otherwise want to disable JMX metrics reporting, you can add the following two lines to the agent\u0026rsquo;s user settings configuration file /opt/draios/etc/dragent.yaml:\njmx: enabled: false After editing the file, restart the native Linux agent via service dragent restart or restart the container agent to make the change take effect.\nIf using our containerized agent, instead of editing the dragent.yaml file, you can add this extra parameter in the docker run command when starting the agent:\n-e ADDITIONAL_CONF=\u0026#34;jmx:\\n enabled: false\\n\u0026#34; ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/custom-integrations/integrate-jmx-metrics-from-java-virtual-machines/"},{"id":685,"title":"Kubernetes Audit Policy","content":" Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nPrerequisites Sysdig Agent version 11.0.0 or greater.\nKubernetes audit logging. See Kubernetes Audit Logging.\nCreate a Kubernetes Audit PolicyTo create a Kubernetes Audit policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select Kubernetes Audit.\nConfigure a Kubernetes Audit PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate personnel.\nSee also: Set Up Notification Channels.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and List Matching.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, choose the Kubernetes Audit to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/k8s_audit_policy/"},{"id":686,"title":"Legacy Group Outlier Alerts","content":" Define a Group Outlier AlertGuidelines Set a unique name and description: Set a meaningful name and description that help recipients easily identify the alert\nSeverity: Set a severity level for your alert. The Priority: High, Medium, Low and Info are reflected in the Alert list, where you can sort by the severity by using the top navigation pane. You can use severity as a criterion when creating events and alerts, for example: if there are more than 10 high severity events, notify.\nSpecify EntitySelect one or more metrics whose behavior you want to monitor.\nConfigure ScopeFilter the environment on which this alert will apply. An alert will fire when the value returned by one of the selected metrics does not follow the pattern in the availability zone, us-east-1b.\nYou can also create alerts directly from Explore and Dashboards for automatically populating this scope.\nConfigure TriggerTrigger gives you control over how notifications are created and help prevent flooding your notification channel with notifications. For example, you may want to receive a notification for every violation, or only want a single notification for a series of consecutive violations.\nDefine the threshold and time window for assessing the alert condition. Supported time scales are minute, hour, or day.\nIf the monitored host or Kubernetes cluster is not available or not responding for the last 5 minutes, recipients will be notified.\nYou can set any value for % and a value greater than 1 for the time window. For example, If you choose 50% instead of 100%, a notification will be triggered when the entity is down for 2.5 minutes in the selected time window of 5 minutes.\nUsecases Load balancer servers have uneven workloads\nChanges in applications or instances deployed in different availability zones.\nNetwork hogging hosts in a cluster\n","url":"https://docs.sysdig.com/en/sysdig-monitor/-legacy-alerts-editor/legacy-group-outlier-alerts/"},{"id":687,"title":"Process Kubernetes Events","content":"Process Kubernetes EventsCluster shieldTo manage the collection of Kubernetes events on Sysdig Monitor using Cluster Shield, apply the following configuration:\nfeatures: monitor: kubernetes_events: enabled: false Classic AgentTo streamline Sysdig agent processing times and reduce CPU load, you can use an updated processing engine written in Go.\nTo do so, edit the following code in dragent.yaml:\ngo_k8s_user_events: true Kubernetes Audit EventsThe agent listens on /k8s-audit for Kubernetes audit events. Configure the path using the following configuration option:\nsecurity:{k8s_audit_server_path_uris: [path1, path2]} For more information, see Kubernetes Audit Logging.\nWorking with containerd in K3SIf you have containerd using a custom socket, you can specify this parameter in the agent configuration to correctly capture the containers\u0026rsquo; metadata:\ncri: socket_path: /run/k3s/containerd/containerd.sock ","url":"https://docs.sysdig.com/en/sysdig-monitor/process-kubernetes-events/"},{"id":688,"title":"Program","content":"sysdig_program_cpu_cores_used Prometheus ID sysdig_program_cpu_cores_used Legacy ID cpu.cores.used Metric Type gauge Unit number Description The CPU core usage of each program is obtained from cgroups, and is equal to the number of cores used by the program. For example, if a program uses two of an available four cores, the value of sysdig_program_cpu_cores_used will be two. Additional Notes sysdig_program_cpu_cores_used_percent Prometheus ID sysdig_program_cpu_cores_used_percent Legacy ID cpu.cores.used.percent Metric Type gauge Unit percent Description The CPU core usage percent for each program is obtained from cgroups, and is equal to the number of cores multiplied by 100. For example, if a program uses three cores, the value of sysdig_program_cpu_cores_used_percent would be 300%. Additional Notes sysdig_program_cpu_used_percent Prometheus ID sysdig_program_cpu_used_percent Legacy ID cpu.used.percent Metric Type gauge Unit percent Description The CPU usage for each program is obtained from cgroups, and normalized by dividing by the number of cores to determine an overall percentage. For example, if the environment contains six cores on a host, and the processes are assigned two cores, Sysdig will report CPU usage of 2/6 * 100% = 33.33%. This metric is calculated differently for hosts and containers. Additional Notes sysdig_program_fd_used_percent Prometheus ID sysdig_program_fd_used_percent Legacy ID fd.used.percent Metric Type gauge Unit percent Description The percentage of used file descriptors out of the maximum available. Additional Notes Usually, when a process reaches its FD limit it will stop operating properly and possibly crash. As a consequence, this is a metric you want to monitor carefully, or even better use for alerts. sysdig_program_file_error_open_count Prometheus ID sysdig_program_file_error_open_count Legacy ID file.error.open.count Metric Type counter Unit number Description The number of errors caused by opening files. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_file_error_total_count Prometheus ID sysdig_program_file_error_total_count Legacy ID file.error.total.count Metric Type counter Unit number Description The number of error caused by file access. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_file_in_bytes Prometheus ID sysdig_program_file_in_bytes Legacy ID file.bytes.in Metric Type counter Unit data Description The number of bytes read from file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_file_in_iops Prometheus ID sysdig_program_file_in_iops Legacy ID file.iops.in Metric Type counter Unit number Description The number of file read operations per second. Additional Notes This is calculated by measuring the actual number of read and write requests made by a process. Therefore, it can differ from what other tools show, which is usually based on interpolating this value from the number of bytes read and written to the file system. sysdig_program_file_in_time Prometheus ID sysdig_program_file_in_time Legacy ID file.time.in Metric Type counter Unit time Description The time spent in file reading. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_file_open_count Prometheus ID sysdig_program_file_open_count Legacy ID file.open.count Metric Type counter Unit number Description The number of time the file has been opened. Additional Notes sysdig_program_file_out_bytes Prometheus ID sysdig_program_file_out_bytes Legacy ID file.bytes.out Metric Type counter Unit data Description The number of bytes written to file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_file_out_iops Prometheus ID sysdig_program_file_out_iops Legacy ID file.iops.out Metric Type counter Unit number Description The number of file write operations per second. Additional Notes This is calculated by measuring the actual number of read and write requests made by a process. Therefore, it can differ from what other tools show, which is usually based on interpolating this value from the number of bytes read and written to the file system. sysdig_program_file_out_time Prometheus ID sysdig_program_file_out_time Legacy ID file.time.out Metric Type counter Unit time Description The time spent in file writing. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_file_total_bytes Prometheus ID sysdig_program_file_total_bytes Legacy ID file.bytes.total Metric Type counter Unit data Description The number of bytes read from and written to file. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_file_total_iops Prometheus ID sysdig_program_file_total_iops Legacy ID file.iops.total Metric Type counter Unit number Description The number of read and write file operations per second. Additional Notes This is calculated by measuring the actual number of read and write requests made by a process. Therefore, it can differ from what other tools show, which is usually based on interpolating this value from the number of bytes read and written to the file system. sysdig_program_file_total_time Prometheus ID sysdig_program_file_total_time Legacy ID file.time.total Metric Type counter Unit time Description The time spent in file I/O. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_info Prometheus ID sysdig_program_info Legacy ID info Metric Type gauge Unit number Description Additional Notes sysdig_program_memory_used_bytes Prometheus ID sysdig_program_memory_used_bytes Legacy ID memory.bytes.used Metric Type gauge Unit data Description The amount of physical memory currently in use. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, the metric can also be segmented by using \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_memory_used_percent Prometheus ID sysdig_program_memory_used_percent Legacy ID memory.used.percent Metric Type gauge Unit percent Description The percentage of physical memory in use. Additional Notes By default, this metric shows the average value for the selected scope. For instance, if you apply it to a group of machines, you will see the average value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_net_connection_in_count Prometheus ID sysdig_program_net_connection_in_count Legacy ID net.connection.count.in Metric Type counter Unit number Description The number of currently established client (inbound) connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_program_net_connection_out_count Prometheus ID sysdig_program_net_connection_out_count Legacy ID net.connection.count.out Metric Type counter Unit number Description The number of currently established server (outbound) connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_program_net_connection_total_count Prometheus ID sysdig_program_net_connection_total_count Legacy ID net.connection.count.total Metric Type counter Unit number Description The number of currently established connections. This value may exceed the sum of the inbound and outbound metrics since it represents client and server inter-host connections as well as internal only connections. Additional Notes This metric is especially useful when segmented by protocol, port or process. sysdig_program_net_error_count Prometheus ID sysdig_program_net_error_count Legacy ID net.error.count Metric Type counter Unit number Description The total number of network errors occurred in a second. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_net_in_bytes Prometheus ID sysdig_program_net_in_bytes Legacy ID net.bytes.in Metric Type counter Unit data Description The number of inbound network bytes. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_net_out_bytes Prometheus ID sysdig_program_net_out_bytes Legacy ID net.bytes.out Metric Type counter Unit data Description The number of outbound network bytes. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_net_request_count Prometheus ID sysdig_program_net_request_count Legacy ID net.request.count Metric Type counter Unit number Description The total number of network requests. Note, this value may exceed the sum of inbound and outbound requests, because this count includes requests over internal connections. Additional Notes sysdig_program_net_request_in_count Prometheus ID sysdig_program_net_request_in_count Legacy ID net.request.count.in Metric Type counter Unit number Description The number of inbound network requests. Additional Notes sysdig_program_net_request_in_time Prometheus ID sysdig_program_net_request_in_time Legacy ID net.request.time.in Metric Type counter Unit time Description The average time to serve an inbound request. Additional Notes sysdig_program_net_request_out_count Prometheus ID sysdig_program_net_request_out_count Legacy ID net.request.count.out Metric Type counter Unit number Description The number of outbound network requests. Additional Notes sysdig_program_net_request_out_time Prometheus ID sysdig_program_net_request_out_time Legacy ID net.request.time.out Metric Type counter Unit time Description The average time spent waiting for an outbound request. Additional Notes sysdig_program_net_request_time Prometheus ID sysdig_program_net_request_time Legacy ID net.request.time Metric Type counter Unit time Description Average time to serve a network request. Additional Notes sysdig_program_net_tcp_queue_len Prometheus ID sysdig_program_net_tcp_queue_len Legacy ID net.tcp.queue.len Metric Type counter Unit number Description The length of the TCP request queue. Additional Notes sysdig_program_net_total_bytes Prometheus ID sysdig_program_net_total_bytes Legacy ID net.bytes.total Metric Type counter Unit data Description The total network bytes, including inbound and outbound connections, in a program. Additional Notes By default, this metric shows the total value for the selected scope. For instance, if you apply it to a group of machines, you will see the total value for the whole group. However, you can easily segment the metric to see it by host, process, container, and so on. Just use \u0026lsquo;Segment by\u0026rsquo; in the UI. sysdig_program_proc_count Prometheus ID sysdig_program_proc_count Legacy ID proc.count Metric Type counter Unit number Description The number of processes on a host or container. Additional Notes sysdig_program_syscall_count Prometheus ID sysdig_program_syscall_count Legacy ID syscall.count Metric Type gauge Unit number Description The total number of syscalls seen Additional Notes Syscalls are resource intensive. This metric tracks how many have been made by a given process or container sysdig_program_thread_count Prometheus ID sysdig_program_thread_count Legacy ID thread.count Metric Type counter Unit number Description The total number of threads running in a program. Additional Notes sysdig_program_timeseries_count_appcheck Prometheus ID sysdig_program_timeseries_count_appcheck Legacy ID metricCount.appCheck Metric Type gauge Unit number Description The number of app check custom metrics. Additional Notes sysdig_program_timeseries_count_jmx Prometheus ID sysdig_program_timeseries_count_jmx Legacy ID metricCount.jmx Metric Type gauge Unit number Description The number of JMS custom metrics. Additional Notes sysdig_program_timeseries_count_prometheus Prometheus ID sysdig_program_timeseries_count_prometheus Legacy ID metricCount.prometheus Metric Type gauge Unit number Description The number of Prometheus custom metrics. Additional Notes sysdig_program_up Prometheus ID sysdig_program_up Legacy ID uptime Metric Type gauge Unit number Description The percentage of time the selected entity was down during the visualized time sample. This can be used to determine if a machine (or a group of machines) went down. Additional Notes ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/program/"},{"id":689,"title":"SaaS Regions and IP Ranges","content":"Sysdig SaaS applications are deployed in five data center regions:\nUS East (Virginia) US West AWS (Oregon) US West GCP (Dallas) AP Australia (Sydney) EU Central (Frankfurt) EU North (Stockholm) Middle East (Dammam) AP South (Mumbai) AP Japan (Tokyo) At the data centers, Sysdig ensures the best security and compliance standards for your data.\nOverviewCode-based AccessThe endpoints for Sysdig Monitor and Sysdig Secure are the same in the US West (Amazon Web Services and Google Cloud Platform), AP Australia, and EU regions. When configuring code-based access to Sysdig Secure, use the endpoint rather than the website URL.\nSingle Sign-OnSysdig SaaS users require the website address to reach the Sysdig applications. Use the appropriate website URL when configuring a single sign-on (SSO).\nCollectorSysdig agents in a SaaS-based deployment need to be able to reach the Sysdig collector. Depending on your network configuration, you may need to modify your firewall configuration to permit outbound connections from agents to the collector.\nInbound IP AddressesThe traffic originating from the Sysdig agent to the Sysdig backend is known as Sysdig SaaS inbound traffic. Allow the agent to send communication outbound on TCP 6443 to the inbound IP ranges associated with your SaaS region.\nOutbound IP AddressesAlso known as source IP addresses, all the traffic originating from the Sysdig backend hosted in each region flows through one of the corresponding source IP addresses. Event Forwarding and Alert Notifications are examples of communication originating from the Sysdig backend.\nGuidelines for AllowlistChoose what to allowlist, based on the Sysdig products and features you use. The allowlist values vary based on the Sysdig Platform region you use.\nEnsure that you add download.sysdig.com to the set of URLs in the allowlist for all the Sysdig SaaS regions.\nIf you run:\nMonitor OnlyAllow:\nMonitor Domain (optional, if needed to communicate with API for, as an example, an on-prem Jenkins job)\nIP Ranges\nCollector (endpoints and ports)\nPrometheus endpoint\nIf you are using Prometheus remote write or on-prem Grafana.\nSecure Vulnerability Management and ScanningAllow:\nSecure Endpoint\nThe Secure endpoint communicates to the API.\nS3 Bucket where the Vulnerability database is stored.\nNode analyzer\nFor the legacy engine host scanner; the new engine does not require you to allow the runtime scanner.\nSecure Threat DetectionAllow:\nSecure Endpoint Collector (endpoints and ports) Actionable Compliance KSPMAllow:\nSecure Endpoint On-Premises Vulnerability FeedsAllow:\nSecure Endpoint\nThe Secure endpoint communicates to the API.\nS3 Bucket where Vulnerability database is stored.\nNote: This is only necessary for the Vulnerability Management engine until airgapped support is available.\nSysdig Platform RegionsUS East (North Virginia) Sysdig Application Domain IP Range Sysdig Monitor https://app.sysdigcloud.com All the traffic originating from the US East data center will have one of the following source IP addresses:54.82.115.350.19.72.12318.207.87.189The Sysdig SaaS inbound IP addresses are:18.214.168.1933.210.216.12444.196.252.240 Sysdig Secure Endpoint: https://secure.sysdig.comWebsite URL: https://secure.sysdig.com All the traffic originating from the US East data center will have one of the following source IP addresses:54.82.115.350.19.72.12318.207.87.189The Sysdig SaaS inbound IP addresses are:18.214.168.1933.210.216.12444.196.252.240 Sysdig Collector collector.sysdigcloud.com (Collector port: 6443) 18.214.168.1933.210.216.12444.196.252.240 Sysdig Collector Alt collector-alt.sysdigcloud.com (Collector port: 443) Node Analyzer https://collector.sysdigcloud.com/internal/scanning/scanning-analysis-collector S3 URLs for Vulnerability Management https://secure-feeds-production-us-east-1-761931097553.s3.us-east-1.amazonaws.com Current API Docs Secure: https://secure.sysdig.com/swagger.html Monitor: https://app.sysdigcloud.com/api/public/docs/index.html Next Gen API Docs Secure: https://secure.sysdig.com/apidocs/secure?_product=SDS\nMonitor: https://app.sysdigcloud.com/apidocs/monitor?_product=SDC US West (Oregon) Sysdig Application Domain IP Range Sysdig Monitor https://us2.app.sysdig.com All the traffic originating from the US West data center will have one of the following source IP addresses:54.218.164.21554.244.190.18044.232.85.27The Sysdig SaaS inbound IP addresses are:54.190.202.10854.203.169.5354.70.9.188 Sysdig Secure Endpoint: https://us2.app.sysdig.comWebsite URL: https://us2.app.sysdig.com/secure/ All the traffic originating from the US West data center will have one of the following source IP addresses:54.218.164.21554.244.190.18044.232.85.27The Sysdig SaaS inbound IP addresses are:54.190.202.10854.203.169.5354.70.9.188 Sysdig Collector ingest-us2.app.sysdig.com (Collector port: 6443) 54.190.202.10854.203.169.5354.70.9.188 Sysdig Collector Alt ingest-alt-us2.app.sysdig.com (Collector port: 443) Node Analyzer https://us2.app.sysdig.com/internal/scanning/scanning-analysis-collector S3 URLs for Vulnerability Management https://secure-feeds-production-us-west-2-263844535661.s3.us-west-2.amazonaws.com API Docs Secure:https://us2.app.sysdig.com/secure/swagger.html\nMonitor:https://us2.app.sysdig.com/api/public/docs/index.html Next Gen API Docs Secure: https://us2.app.sysdig.com/apidocs/secure?_product=SDS\nMonitor: https://us2.app.sysdig.com/apidocs/monitor?_product=SDC US West (GCP) Sysdig Application Domain IP Range Sysdig Monitor https://app.us4.sysdig.com All the traffic originating from the US West (GCP) data center will have one of the following source IP addresses: 34.105.1.7\n34.127.13.141The Sysdig SaaS inbound IP addresses are:34.145.19.124 Sysdig Secure Endpoint: https://app.us4.sysdig.com/ Website URL: https://app.us4.sysdig.com/secure/ All the traffic originating from the US West (GCP) data center will have one of the following source IP addresses: 34.105.1.7\n34.127.13.141The Sysdig SaaS inbound IP address is:34.145.19.124 Sysdig Collector ingest.us4.sysdig.com (Collector port: 6443) 34.145.123.253 Sysdig Collector Alt ingest-alt.us4.sysdig.com (Collector port: 443) Node Analyzer https://app.us4.sysdig.com/internal/scanning/scanning-analysis-collector S3 URLs for Vulnerability Management https://storage.googleapis.com/us4-prod-usw1-e33c-us-west1-us-secure-feeds API Docs Secure:https://app.us4.sysdig.com/secure/swagger.html\nhttps://app.us4.sysdig.com/api/public/docs/index.html Next Gen API Docs Secure: https://app.us4.sysdig.com/apidocs/secure?_product=SDS\nMonitor: https://app.us4.sysdig.com/apidocs/monitor?_product=SDC EU Central (Frankfurt) Sysdig Application Domain IP Range Sysdig Monitor https://eu1.app.sysdig.com All traffic originating from the European Union (EU) data center will have one of the following source IP addresses:3.127.3.2053.127.111.4218.157.104.82The Sysdig SaaS inbound IP addresses are:18.156.190.12618.157.62.503.126.167.54 Sysdig Secure Endpoint: https://eu1.app.sysdig.comWebsite URL: https://eu1.app.sysdig.com/secure/ All traffic originating from the European Union (EU) data center will have one of the following source IP addresses:3.127.3.2053.127.111.4218.157.104.82The Sysdig SaaS inbound IP addresses are:18.156.190.12618.157.62.503.126.167.54 Sysdig Collector ingest-eu1.app.sysdig.com (Collector port: 6443) The Sysdig SaaS inbound IP addresses are: 3.126.167.54, 18.157.62.50, 18.156.190.126 Sysdig Collector Alt ingest-alt-eu1.app.sysdig.com (Collector port: 443) Node Analyzer https://eu1.app.sysdig.com/internal/scanning/scanning-analysis-collector S3 URLs for Vulnerability Management https://secure-feeds-production-eu-central-1-263844535661.s3.eu-central-1.amazonaws.com API Docs Secure: https://eu1.app.sysdig.com/secure/swagger.html\nMonitor: https://eu1.app.sysdig.com/api/public/docs/index.html Next Gen API Docs Secure: https://eu1.app.sysdig.com/apidocs/secure?_product=SDS\nMonitor: https://eu1.app.sysdig.com/apidocs/monitor?_product=SDC EU North (Stockholm) Sysdig Application Domain IP Range Sysdig Monitor https://app.eu2.sysdig.com All traffic originating from the EU North data center will have one of the following source IP addresses:13.60.109.2916.16.11.20751.21.99.78The Sysdig SaaS inbound IP addresses are:13.49.213.5651.20.13.1013.50.217.227 Sysdig Secure Endpoint: https://app.eu2.sysdig.comWebsite URL: https://app.eu2.sysdig.com/secure/ All traffic originating from the EU North data center will have one of the following source IP addresses:13.60.109.2916.16.11.20751.21.99.78The Sysdig SaaS inbound IP addresses are:13.49.213.5651.20.13.1013.50.217.227 Sysdig Collector ingest.eu2.sysdig.com (Collector Port: 6443) 13.49.213.56\n51.20.13.10\n13.50.217.227\nSysdig Collector Alt ingest-alt.eu2.sysdig.com (Collector Port: 443) S3 URLs for Vulnerability Management https://secure-feeds-production-eu-north-1-058264271928.s3.eu-north-1.amazonaws.com API Docs Secure: https://app.eu2.sysdig.com/apidocs/secure/ Monitor: https://app.eu2.sysdig.com/apidocs/monitor/ Asia Pacific (Sydney) Sysdig Application Domain IP Range Sysdig Monitor https://app.au1.sysdig.com All traffic originating from the Asia Pacific (AP) data center will have one of the following source IP addresses: 13.236.248.8413.236.151.3813.54.145.96 The Sysdig SaaS inbound IP addresses are:13.238.59.195 52.62.57.59 52.64.82.29 Sysdig Secure Endpoint: https://app.au1.sysdig.com Website URL: https://app.au1.sysdig.com/secure/ All traffic originating from the Asia Pacific (AP) data center will have one of the following source IP addresses: 13.236.248.8413.236.151.3813.54.145.96 The Sysdig SaaS inbound IP addresses are:13.238.59.195 52.62.57.59 52.64.82.29 Sysdig Collector ingest.au1.sysdig.com (Collector port: 6443) 13.238.59.195 52.62.57.59 52.64.82.29 Sysdig Collector Alt ingest-alt.au1.sysdig.com (Collector port: 443) Node Analyzer https://app.au1.sysdig.com/internal/scanning/scanning-analysis-collector S3 URLs for Vulnerability Management https://secure-feeds-production-ap-southeast-2-263844535661.s3.ap-southeast-2.amazonaws.com API Docs Secure: https://app.au1.sysdig.com/secure/swagger.html\nMonitor: https://app.au1.sysdig.com/api/public/docs/index.html Next Gen API Docs Secure: https://app.au1.sysdig.com/apidocs/secure?_product=SDS\nMonitor: https://app.au1.sysdig.com/apidocs/monitor?_product=SDC Middle East (GCP) Sysdig Application Domain IP Range Sysdig Monitor https://app.me2.sysdig.com All the traffic originating from the Dammam (GCP) data center will have the following source IP addresses: 34.166.37.127The Sysdig SaaS inbound IP addresses is:34.166.29.55 Sysdig Secure Endpoint: https://app.me2.sysdig.com Website URL: https://app.me2.sysdig.com/secure/ All the traffic originating from the Dammam (GCP (GCP) data center will have the following source IP addresses:\n34.166.37.127The Sysdig SaaS inbound IP address is:34.166.29.55 Sysdig Collector ingest.me2.sysdig.com (Collector port: 6443) 34.166.32.4 Sysdig Collector Alt ingest-alt.me2.sysdig.com (Collector port: 443) Node Analyzer https://app.me2.sysdig.com/internal/scanning/scanning-analysis-collector S3 URLs for Vulnerability Management https://storage.googleapis.com/me2-prod-mec2-6642-me-central2-secure-feeds API Docs https://app.me2.sysdig.com/api/public/docs/index.html https://app.me2.sysdig.com/secure/swagger.html Next Gen API Docs Secure: https://app.me2.sysdig.com/apidocs/secure?_product=SDS\nMonitor: https://app.me2.sysdig.com/apidocs/monitor?_product=SDC Asia Pacific South (Mumbai) Sysdig Application Domain IP Range Sysdig Monitor https://app.in1.sysdig.com All the traffic originating from the Mumbai data center will have the following source IP addresses: 13.232.18.255\n3.111.123.4965.2.7.2\nThe Sysdig SaaS inbound IP addresses are:\n13.201.147.2 3.6.182.175\n43.205.223.39 Sysdig Secure Endpoint: https://app.in1.sysdig.com Website URL: https://app.in1.sysdig.com/secure/ All the traffic originating from the Mumbai data center will have the following source IP addresses:\n13.232.18.255\n3.111.123.49\n65.2.7.2\nThe Sysdig SaaS inbound IP addresses are:13.201.147.2 3.6.182.17543.205.223.39 Sysdig Collector ingest.in1.sysdig.com (Collector port: 6443) 13.201.147.2 3.6.182.17543.205.223.39 Sysdig Collector Alt ingest-alt.in1.sysdig.com (Collector port: 443) S3 URLs for Vulnerability Management https://secure-feeds-production-ap-south-1-975050200984.s3.ap-south-1.amazonaws.com API Docs https://app.in1.sysdig.com/apidocs/monitor/ https://app.in1.sysdig.com/apidocs/secure/ Asia Pacific Japan (Tokyo) Sysdig Application Domain IP Range Sysdig Monitor https://app.jp1.sysdig.com The Sysdig SaaS inbound IP addresses are:162.133.128.157128.168.142.30165.192.134.255 Sysdig Secure Endpoint: https://app.jp1.sysdig.com Website URL: https://app.jp1.sysdig.com/secure/ The Sysdig SaaS inbound IP addresses are:162.133.128.157128.168.142.30165.192.134.255 Sysdig Collector ingest.jp1.sysdig.com (Collector port: 6443) 162.133.128.157128.168.142.30165.192.134.255 Node Analyzer https://app.jp1.sysdig.com/#/internal/scanning/scanning-analysis-collector S3 URLs for Vulnerability Management https://s3.jp-tok.cloud-object-storage.appdomain.cloud API Docs Secure: https://app.jp1.sysdig.com/secure/swagger.html\nMonitor: https://app.jp1.sysdig.com/api/public/docs/index.html Next Gen API Docs Secure: https://app.jp1.sysdig.com/apidocs/secure?_product=SDS\nMonitor: https://app.jp1.sysdig.com/apidocs/monitor?_product=SDC Service-Specific ConnectionsProtocols HTTPS (Hypertext Transfer Protocol Secure) WSS (Web Socket Secure) TLS (Transport Layer Security) Sysdig Collector PortsSysdig Agent uses the following ports to communicate with the Sysdig Collector.\nRegions Port US East Collector: SSL/TLS 6443Collector Alt: SSL/TLS 443UI/API: HTTPS 443 US West Collector: SSL/TLS 6443Collector Alt: SSL/TLS 443UI/API: HTTPS 443 US West (GCP) Collector: SSL/TLS 6443Collector Alt: SSL/TLS 443UI/API: HTTPS 443 EU Central (Frankfurt) Collector: SSL/TLS 6443Collector Alt: SSL/TLS 443UI/API: HTTPS 443 EU North (Stockholm) Collector: SSL/TLS 6443 Collector Alt: SSL/TLS 443UI/API: HTTPS 443 Asia Pacific (Sydney) Collector: SSL/TLS 6443Collector Alt: SSL/TLS 443UI/API: HTTPS 443 Middle East - Dammam (GCP) Collector: SSL/TLS 6443Collector Alt: SSL/TLS 443UI/API: HTTPS 443 AP South (Mumbai) Collector: SSL/TLS 6443Collector Alt: SSL/TLS 443UI/API: HTTPS 443 AP Japan (Tokyo) Collector: SSL/TLS 6443UI/API: HTTPS 443 Sysdig API Endpoints Regions URL US East (North Virginia) Monitor: app.sysdigcloud.comSecure: secure.sysdig.com US West (Oregon) us2.app.sysdig.com US West (GCP) app.us4.sysdig.com EU Central (Frankfurt) eu1.app.sysdig.com EU North (Stockholm) app.eu2.sysdig.com Asia Pacific (Sydney) app.au1.sysdig.com Middle East (Dammam - GCP) app.me2.sysdig.com AP South (Mumbai) app.in1.sysdig.com AP Japan (Tokyo) app.jp1.sysdig.com Sysdig Next-Gen API Endpoints Region Hostname US East (North Virginia) https://api.us1.sysdig.com US West (Oregon) https://api.us2.sysdig.com US-3 https://api.us3.sysdig.com US West (GCP) https://api.us4.sysdig.com EU Central (Frankfurt) https://api.eu1.sysdig.com EU North (Stockholm) https://api.eu2.sysdig.com Asia Pacific (Sydney) https://api.au1.sysdig.com Middle East (Dammam - GCP) https://api.me2.sysdig.com Asia Pacific South (Mumbai) https://api.in1.sysdig.com Asia Pacific Japan (Tokyo) https://api.jp1.sysdig.com When configuring the agent parameter sysdig_api_endpoint, use one of the following Secure endpoints:\nAWS Account IDs Regions AWS Account IDs US East 761931097553 US West (Oregon) 263844535661 US West (GCP) 481025487701 EU Central (Frankfurt) 263844535661 EU North (Stockholm) 058264271928 Asia Pacific 263844535661 AP South (Mumbai) 975050200984 Redirect URLs for Authentication Region Protocol URLs US East (North Virgina) SAML Sysdig MonitorACS URL / Sign on URL: https://app.sysdigcloud.com/api/saml/authEntity ID: https://app.sysdigcloud.comSysdig SecureACS URL / Sign on URL: https://secure.sysdig.com/api/saml/secureAuthEntity ID: https://secure.sysdig.com US East (North Virgina) OpenID Sysdig MonitorRedirect URL:\nhttps://app.sysdigcloud.com/api/oauth/openid/authSysdig Secure\nRedirect URL:\nhttps://secure.sysdig.com/api/oauth/openid/secureAuth US East (North Virgina) Google OAuth Sysdig Monitor: https://app.sysdigcloud.com/api/oauth/google/authSysdig Secure:https://secure.sysdig.com/api/oauth/google/secureAuth US West (Oregon) SAML Sysdig MonitorACS URL / Sign on URL: https://us2.app.sysdig.com/api/saml/authEntity ID: https://us2.app.sysdig.comSysdig SecureACS URL / Sign on URL: https://us2.app.sysdig.com/api/saml/secureAuthEntity ID: https://us2.app.sysdig.com/secure/ US West (Oregon) OpenID Sysdig MonitorRedirect URL:\nhttps://us2.app.sysdig.com/api/oauth/openid/authSysdig Secure\nRedirect URL:\nhttps://us2.app.sysdig.com/api/oauth/openid/secureAuth US West (Oregon) Google OAuth Sysdig Monitor: https://us2.app.sysdig.com/api/oauth/google/authSysdig Secure: https://us2.app.sysdig.com/api/oauth/google/secureAuth US West (GCP) SAML Sysdig Monitor\nACS URL / Sign on URL: https://app.us4.sysdig.com/api/saml/auth\nEntity ID: https://app.us4.sysdig.com\nSysdig Secure\nACS URL / Sign on URL: https://app.us4.sysdig.com/api/saml/secureAuth\nEntity ID: https://app.us4.sysdig.com/secure/ US West (GCP) OpenID Sysdig Monitor\nRedirect URL: https://app.us4.sysdig.com/api/oauth/openid/auth\nSysdig Secure\nRedirect URL: https://app.us4.sysdig.com/api/oauth/openid/secureAuth US West (GCP) Google OAuth Sysdig Monitor: https://app.us4.sysdig.com/api/oauth/google/auth\nSysdig Secure: https://app.us4.sysdig.com/api/oauth/google/secureAuth EU Central (Frankfurt) SAML Sysdig Monitor\nACS URL / Sign on URL: https://eu1.app.sysdig.com/api/saml/auth\nEntity ID: https://eu1.app.sysdig.com\nSysdig Secure\nACS URL / Sign on URL: https://eu1.app.sysdig.com/api/saml/secureAuth\nEntity ID: https://eu1.app.sysdig.com/secure/ EU Central (Frankfurt) OpenID Sysdig Monitor\nRedirect URL: https://eu1.app.sysdig.com/api/oauth/openid/auth\nSysdig Secure\nRedirect URL: https://eu1.app.sysdig.com/api/oauth/openid/secureAuth EU Central (Frankfurt) Google OAuth Sysdig Monitor: https://eu1.app.sysdig.com/api/oauth/google/auth\nSysdig Secure: https://eu1.app.sysdig.com/api/oauth/google/secureAuth EU North (Stockholm) SAML Sysdig Monitor\nACS URL / Sign on URL: https://app.eu2.sysdig.com/api/saml/auth\nEntity ID: https://app.eu2.sysdig.com\nSysdig Secure\nACS URL / Sign on URL: https://app.eu2.sysdig.com/api/saml/secureAuth\nEntity ID: https://app.eu2.sysdig.com/secure/ EU North (Stockholm) OpenID Sysdig Monitor\nRedirect URL: https://app.eu2.sysdig.com/api/oauth/openid/auth\nSysdig Secure\nRedirect URL: https://app.eu2.sysdig.com/api/oauth/openid/secureAuth EU North (Stockholm) Google OAuth Sysdig Monitor: https://app.eu2.sysdig.com/api/oauth/google/auth\nSysdig Secure: https://app.eu2.sysdig.com/api/oauth/google/secureAuth Asia Pacific (Sydney) SAML Sysdig Monitor\nACS URL / Sign on URL:https://app.au1.sysdig.com/api/saml/auth\nEntity ID: https://app.au1.sysdig.com\nSysdig Secure\nACS URL / Sign on URL: https://app.au1.sysdig.com/api/saml/secureAuth\nEntity ID: https://app.au1.sysdig.com/secure/ Asia Pacific (Sydney) OpenID Sysdig Monitor\nRedirect URL: https://app.au1.sysdig.com/api/oauth/openid/auth\nSysdig Secure\nRedirect URL: https://app.au1.sysdig.com/api/oauth/openid/secureAuth Asia Pacific (Sydney) Google OAuth Sysdig Monitor: https://app.au1.sysdig.com/api/oauth/google/auth\nSysdig Secure: https://app.au1.sysdig.com/api/oauth/google/secureAuth Asia Pacific South (Mumbai) SAML Sysdig Monitor\nACS URL / Sign on URL: https://app.in1.sysdig.com/api/saml/auth\nEntity ID: https://app.in1.sysdig.com\nSysdig Secure\nACS URL / Sign on URL:https://app.in1.sysdig.com/api/saml/secureAuth\nEntity ID: https://app.in1.sysdig.com/secure/ Asia Pacific South (Mumbai) OpenID Sysdig Monitor\nRedirect URL: https://app.in1.sysdig.com/api/oauth/openid/auth\nSysdig Secure\nRedirect URL: https://app.in1.sysdig.com/api/oauth/openid/secureAuth Asia Pacific South (Mumbai) Google OAuth Sysdig Monitor: https://app.in1.sysdig.com/api/oauth/google/auth\nSysdig Secure: https://app.in1.sysdig.com/api/oauth/google/secureAuth Middle East (GCP) SAML Sysdig Monitor\nACS URL / Sign on URL: https://app.me2.sysdig.com/api/saml/auth\nEntity ID: https://app.me2.sysdig.com\nSysdig Secure\nACS URL / Sign on URL: https://app.me2.sysdig.com/api/saml/secureAuth\nEntity ID: https://app.me2.sysdig.com/secure/ Middle East (GCP) OpenID Sysdig Monitor\nRedirect URL: https://app.me2.sysdig.com/api/oauth/openid/auth\nSysdig Secure\nRedirect URL: https://app.eu2.sysdig.com/api/oauth/openid/secureAuth Middle East (GCP) Google OAuth Sysdig Monitor: https://app.eu2.sysdig.com/api/oauth/google/auth\nSysdig Secure: https://app.me2.sysdig.com/api/oauth/openid/secureAuth Prometheus Endpoints and RegionsPrometheus Remote WritePrometheus Remote Write resides in the ingest endpoints for each region under /prometheus/remote/write. The public Prometheus Remote Write endpoints for each region are listed below:\nRegion Endpoints US East https://api.sysdigcloud.com/prometheus/remote/write US West https://us2.app.sysdig.com/prometheus/remote/write US West (GCP) https://app.us4.sysdig.com/prometheus/remote/write EU Central (Frankfurt) https://eu1.app.sysdig.com/prometheus/remote/write EU North (Stockholm) https://app.eu2.sysdig.com/prometheus/remote/write Asia Pacific (Sydney) https://app.au1.sysdig.com/prometheus/remote/write Middle East - Dammam (GCP) https://app.me2.sysdig.com/prometheus/remote/write AP South (Mumbai) https://app.in1.sysdig.com/prometheus/remote/write AP Japan (Tokyo) https://app.jp1.sysdig.com/prometheus/remote/write Grafana IntegrationsUse the following Prometheus endpoints for Grafana integrations.\nRegion Endpoint US East https://app.sysdigcloud.com/prometheus US West https://us2.app.sysdig.com/prometheus US West (GCP) https://app.us4.sysdig.com/prometheus EU Central https://eu1.app.sysdig.com/prometheus EU North https://app.eu2.sysdig.com/prometheus Asia Pacific (Sydney) https://app.au1.sysdig.com/prometheus Middle East - Dammam (GCP) https://app.me2.sysdig.com/prometheus AP South (Mumbai) https://app.in1.sysdig.com/prometheus AP Japan (Tokyo) https://app.jp1.sysdig.com/prometheus ","url":"https://docs.sysdig.com/en/administration/saas-regions-and-ip-ranges/"},{"id":690,"title":"Custom Webhook for ServiceNow","content":"Configure ServiceNowPrerequisites Have a ServiceNow account set up and working.\nSee the ServiceNow developer documentation.\nCreate Scripted Rest API Details in ServiceNow GUI Login to ServiceNow (developer entry) and create a Scripted REST API:\nClick New and submit the form with the following:\nName: Specify the Sysdig alert associated with the notification.\nAPI ID: Specify the API ID.\nReturn to the Scripted REST APIs and open the resource just created.\nScroll down to the related list area, select Resources, and click New. This will create a new Scripted REST API resource.\nFill in the Name field. In this example, we chose \u0026ldquo;Demo\u0026rdquo;.\nScroll down to Security and clear the checkbox that requires authentication.\nChange the HTTP method from GET to POST.\nThe resource is created.\nAdd Code to the New Scripted APINow give the resource the code to execute.\nThe default objects to work with in a Scripted REST API Resource are response and request.\nFor more details on request and response see Scripted Rest APIs.\nThe created resource will already have some example code:\n(function process(/*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) { // implement resource here })(request, response); Change this default code to:\n(function process(/*RESTAPIRequest*/ request, /*RESTAPIResponse*/ response) { gs.info(request.body.dataString); })(request, response); Note the following resource path to this newly created resource is now visible: /api/snc/sysdigalert.\nThe url to this resource would be https://yourInstance.service-now.com/resource-path or https://yourInstance.service-now.com/api/snc/sysdigalert\nClick Submit/Update on this resource.\nConfigure Sysdig WebhookNow that the custom API endpoint in ServiceNow is created, you can configure Sysdig alerts to use a custom webhook to trigger the ServiceNow integration.\nIn Sysdig Monitor, complete steps 1-3 in Set Up a Notification Channel and choose Custom Webhook.\nFill out the form.\nURL: Your instance name URL.\nName: Choose a meaningful name, for example, \u0026ldquo;ServiceNow\u0026rdquo;.\nNotify when Resolved: Use this toggle to choose whether you want to receive a notification when the alert condition is no longer triggered.\nNotify when Acknowledged: Use this toggle to choose whether you want to receive a notification when the alert is manually acknowledged.\nTest Notification: Use this toggle and/or set up a test alert as described in the following section.\nTest IntegrationTo test if this ServiceNow integration is working correctly, you can set up a test alert to trigger.\nFor example, you could create an alert for CPU usage:\nIn ServiceNow, navigate to System Log \u0026gt; All to see a sample triggered webhook.\n","url":"https://docs.sysdig.com/en/administration/custom-webhook-servicenow/"},{"id":691,"title":"Admission Controller","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nFeaturesInstalling admission controller will enable the following:\nImage Scanning Capabilities: Sysdig\u0026rsquo;s Admission Controller (UI-based) builds upon Kubernetes and enhances the capacity of the image scanner to check images for Common Vulnerabilities and Exposures (CVEs), misconfigurations, outdated images, etc., elevating the scan policies from detection to actual prevention. Container images that do not fulfill the configured admission policies will be rejected from the cluster before being assigned to a node and allowed to run.\nKubernetes Audit Logging Capabilities: Enable the features.k8sAuditDetections=true option to use Kubernetes audit logging features with the admission controller. (See also: Kubernetes Audit Logging.)\nInstallationFollow the standard helm installation. Replace helm install with helm upgrade --install.\nTo enable the admission controller (scanning legacy engine) in your existing Sysdig Secure Helm install command, add the following flags:\n--set admissionController.enabled=true \\ --set admissionController.sysdig.secureAPIToken=\u0026lt;my key\u0026gt; \\ --set admissionController.scanner.enabled=true \\ For additional configuration options, including on-premises, using a proxy, etc., see the admission-controller readme.\nUsage Create Admission Controller policies as you see fit for your use cases Assign the policies to the connected clusters Enable the Admission Controller for the cluster Create Admission Controller PoliciesAdmission Controller Policies define the criteria to accept or reject a given container image at admission time. Remember that Policies must be assigned to a cluster to be enforced.\nLog in as Administrator to Sysdig Secure and select Image Scanning\u0026gt; Admission Controller|Policies.\nThe Admission Controller Policies page displays a list of any previously defined policies.\nClick +Policy and enter a meaningful Name and Description.\nDefine the policy Rules:\nEvaluation Failure: Whether to reject images that are failing scanning policy evaluation. Images matching a policy assignment without scan results will also be rejected.\nEvaluation Age: Whether to reject images when the evaluation is older than X days. You might set this condition to force a new vulnerability check, for example.\nUnscanned Image: Whether to reject images that do not have an existing evaluation at admission time. Choose from three options:\nIgnore:Ignore this condition\nReject:Reject the request\nReject and Scan:Reject the request and scan the image in parallel.\nTypically, Kubernetes will retry creating the pending image, so eventually, the image will have a valid evaluation and then the other conditions will apply. Since scanning during admission can potentially slow down the deployment process, we don’t recommend this option unless you are confident that most images will have an evaluation before admission (i.e. instrumenting the CI/CD pipelines).\nClick Save. Understanding: How Policy Conditions are AppliedPolicy conditions are applied using an AND operator.\nFor example, if I set Evaluation Fail to Reject AND Evaluation Age to Reject for older than 15 days, then if I receive an image with an existing evaluation that is passing and that evaluation is 20 days old, the request will be rejected.\nAssign Admission Controller Policies Log in as Administrator to Sysdig Secure and select Image Scanning\u0026gt; Admission Controller|Policy Assignment.\nThe admission controller policy assignment page displays the list of Kubernetes clusters with Admission Controllers, and their current status.\nConnected/disconnected clusters: Clusters where the admission controller was never installed and will not appear at all. Otherwise:\nConnected: Clusters with a connected and healthy admission controller will show under the \u0026ldquo;Connected\u0026rdquo; label.\nDisconnected: A Kubernetes cluster that had an admission controller installed, but the admission controller component is not reporting back to the Sysdig backend, will appear under the \u0026ldquo;Disconnected\u0026rdquo; label.\nEnabled/disabled Admission Controllers: You enable/ disable the admission controller for each cluster using the switch on the top right.\nEnabled: A green dot by the cluster name shows the admission controller is enabled (enforcing)\nDisabled: A grey dot means the admission controller is disabled.\nClick +Add Assignment and enter the basic assignment details.\nA cluster can have multiple assignments at different levels of granularity and the policies are evaluated from top to bottom.\nNamespace: Leave blank to match any namespace, or add a regular expression to match the namespace ex.: | field | value matches | | \u0026mdash; | \u0026mdash; | | dev | any namespace containing \u0026lsquo;dev\u0026rsquo;| | ^dev | any namespace starting with \u0026lsquo;dev\u0026rsquo; | | ^dev$ | a namespace with the exact name \u0026lsquo;dev\u0026rsquo; |\nPrefix: Leave blank to match any image name, or limit by entering a particular prefix. For example, the redis prefix would match images declared as redis:latest or redis:v2 in the container creation request.\nPolicy: Select a policy from the drop-down list.\nChoose Default policy if no other assignment matches: Select to Allow by default or Reject by default.\nBe very careful with the Reject by default option. Be sure to explicitly allow critical workloads in your system.\nClick Save. Saved changes are pulled from the Admission Controller every 5 minutes\nOptional: Drag the new assignment to a different position in the evaluation list if it should be applied before another assignment. Understanding: Evaluation OrderAssignments are evaluated from top to bottom. The first match dictates which policy will be applied.\nThe default cluster action will be applied if no assignment matches.\nFor example:\nGiven the following assignments: The policies that apply would be the following\nkube-system namespace, container with image path docker.io/myimage -\u0026gt; will apply Policy1 mynamespace namespace, container with image path quay.io/myimage -\u0026gt; will apply Policy2 mynamespace namespace, container with image path docker.io/myimage -\u0026gt; will apply default policy Rejected Enable and Disable Admission ControllerIt is recommended to develop the policies and assignments while the Admission Controller is Disabled. Enable it on a staging cluster to test before enabling it in production.\nWhen you are happy with the defined behavior:\nLog in as Administrator to Sysdig Secure and select Image Scanning\u0026gt; Admission Controller|Policy Assignment.\nSelect the relevant cluster from the left side menu.\nSlide the Admission Controller to Enabled.\nMonitor any resulting events as usual.\nThe Disable function can also be used to quickly stop the Admission Controller if unexpected behavior is detected that adversely affects the function of a cluster.\nVerify Image Scanning Is Working Install the Admission Controller on your Kubernetes cluster.\nThis feature is enabled by default through the scanner.enabled value.\nEnable Admission Controller using Sysdig Secure \u0026gt; Image Scanning \u0026gt; Admission Controller \u0026gt; Policy Assignments.\nThis section can only be accessed by a user with Administrator permissions.\nAdd an assignment to Allow or Deny images within a namespace.\nTail to the logs from the Admission Controller:\nkubectl logs -f -n sysdig-admission-controller -l app.kubernetes.io/component=webhook Push some deployment into your Kubernetes Cluster to watch the result, for example an nginx image\nkubectl run nginx --image=nginx ​ If policy is set to allow, the deployment will be successful.\n​ Either way, you should see some logs in Admission Controller tail:\n```console -- allow assignment result {\u0026quot;level\u0026quot;:\u0026quot;info\u0026quot;,\u0026quot;component\u0026quot;:\u0026quot;scanning-evaluator\u0026quot;,\u0026quot;message\u0026quot;:\u0026quot;checking pod=nginx in namespace=default\u0026quot;} {\u0026quot;level\u0026quot;:\u0026quot;info\u0026quot;,\u0026quot;component\u0026quot;:\u0026quot;scanning-evaluator\u0026quot;,\u0026quot;message\u0026quot;:\u0026quot;evaluating container with name=nginx and image=nginx\u0026quot;} {\u0026quot;level\u0026quot;:\u0026quot;info\u0026quot;,\u0026quot;component\u0026quot;:\u0026quot;scanning-evaluator\u0026quot;,\u0026quot;time\u0026quot;:\u0026quot;\u0026quot;,\u0026quot;message\u0026quot;:\u0026quot;matched policy=Allow always for namespace=default and image=nginx\u0026quot;} {\u0026quot;level\u0026quot;:\u0026quot;info\u0026quot;,\u0026quot;component\u0026quot;:\u0026quot;scanning-evaluator\u0026quot;,\u0026quot;message\u0026quot;:\u0026quot;allowing container with name=nginx and image=nginx\u0026quot;} -- reject assignment result {\u0026quot;level\u0026quot;:\u0026quot;info\u0026quot;,\u0026quot;component\u0026quot;:\u0026quot;scanning-evaluator\u0026quot;,\u0026quot;message\u0026quot;:\u0026quot;checking pod=nginx in namespace=default\u0026quot;} {\u0026quot;level\u0026quot;:\u0026quot;info\u0026quot;,\u0026quot;component\u0026quot;:\u0026quot;scanning-evaluator\u0026quot;,\u0026quot;message\u0026quot;:\u0026quot;evaluating container with name=nginx and image=nginx\u0026quot;} {\u0026quot;level\u0026quot;:\u0026quot;info\u0026quot;,\u0026quot;component\u0026quot;:\u0026quot;scanning-evaluator\u0026quot;,\u0026quot;message\u0026quot;:\u0026quot;matched policy=Reject Allways for namespace=default and image=nginx\u0026quot;} {\u0026quot;level\u0026quot;:\u0026quot;info\u0026quot;,\u0026quot;component\u0026quot;:\u0026quot;scanning-evaluator\u0026quot;,\u0026quot;message\u0026quot;:\u0026quot;denying container with name=nginx and image=nginx reason=\\\\\u0026quot;Reject Always\\\\\u0026quot;\u0026quot;} ``` TroubleshootingPolicy Rules Are Not HonoredSee Admission Controller - Understanding How Policy Conditions Are applied.\nPolicy Assignments order Are Not honoredIt may be that you\u0026rsquo;re using the same namespace and image prefix on more than one assignment.\nChanges on Policy Assignments Are Not Applied to the ClusterAdmission Controller pulls changes from the Sysdig Secure platform every 5 minutes. You can wait five minutes, or force the admission controller webhook to restart:\nkubectl rollout restart deployment -n sysdig-admission-controller sysdig-admission-controller-webhook ka.sourceips Not SupportedAdmission Controller will not be able to retrieve the source IP of the events when this information is not provided by the Kubernetes Admission Controller. If you really require this field, as a workaround, you can use the legacy Sysdig Agent + Kubernetes Audit.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/admission-controller/"},{"id":692,"title":"Blacklist Ports","content":" Access the agent configuration file, using one of the options listed.\nAdd blacklisted_ports with desired port numbers.\nExample (YAML):\nblacklisted_ports:\n- 6443\n- 6379\nRestart the agent (if editing dragent.yaml file directly), using either the service dragent restart or docker restart sysdig-agent command as appropriate.\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-agent-blacklist-ports/"},{"id":693,"title":"Cleanup Event Data","content":"Time-Based ExpirationThe purpose of time-based expirations is to automatically delete old events that have exceeded their retention period.\nWhat Gets DeletedWhen this is triggered, the system deletes the following event types:\nCustom Events: All custom events older than the retention period Resolved Alert Events: Alert events marked as resolved OK State Alerts: Alert events with the OK state Retention PeriodsDefault Retention: 30 days All events older than 30 days (matching the criteria above) are automatically deleted This applies to all users unless you have created custom retention settings Per-Customer Custom Retention: You can configure custom retention periods Custom retention periods override the 30-day default For more information on various retention limits, see Data Retention.\nWhat’s Protected Active (triggering) alert events: Unresolved alerts continue to be retained regardless of age Critical alert states: Alert events that are not in the OK state or marked as resolved Count-Based LimitingThe purpose of count-based limiting is to ensure your event storage stays within configured count limits. This happens by deleting older, lower-priority events when your storage thresholds are exceeded.\nEvent Count Threshold The data from the last 48 hours is exempt from this cleanup.\nDefault limit: 2 million events Cleanup trigger: It will take action when your organization exceeds 110% of your limit Example: With the default 2 million limit, cleanup starts at 2.2 million events Target after cleanup: Events are reduced back to the configured limit (2 million) Per-customer overrides: You can create custom retention settings For more information on various retention limits, see Data Retention.\nPriority-Based Deletion StrategyWhen cleanup is needed, events are deleted in order of increasing priority (least important first):\nPriority Event Type Severity Category Description 0 Any Informational INFORMATIONAL Informational events (lowest priority) 1 Custom Low LOW_INFRASTRUCTURE Low severity infrastructure events (no team assignment) 2 Custom Low LOW_CUSTOM Low severity custom events (with team assignment) 3 Custom Medium MEDIUM_INFRASTRUCTURE Medium severity infrastructure events 4 Custom Medium MEDIUM_CUSTOM Medium severity custom events 5 Alert Low LOW_ALERT Low severity alert events 7 Custom High HIGH_INFRASTRUCTURE High severity infrastructure events 8 Custom High HIGH_CUSTOM High severity custom events 9 Alert Medium MEDIUM_ALERT Medium severity alert events 11 Alert High HIGH_ALERT High severity alert events (highest priority) Within each priority category, older events (by timestamp) are deleted first.\nCombined ExecutionThe cleanup job runs both methods sequentially:\nFirst: Removes old events based on time retention Second: Enforces count-based limits on remaining events This two-phase approach ensures that:\nTime-expired events are removed first (freeing space efficiently) Count-based cleanup only processes events within the retention window The most critical and recent events are preserved ","url":"https://docs.sysdig.com/en/sysdig-monitor/events-cleanup-service/"},{"id":694,"title":"Configure a Custom Webhook Channel","content":"The custom webhook notification channel lets you customize payload from within Sysdig Monitor, based on alert properties, by dynamically referencing alert variables and scope labels. To create the payload, Sysdig provides you with the Sysdig Templating Language that enables variable interpolation and basic conditional logic.\nSupportCustom Webhook notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts Custom Webhook notification channels are not in Sysdig Secure.\nSysdig Secure users can continue using the Webhook channel.\nEnable WebhookBasic Configuration Log in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channel \u0026gt; Custom Webhook.\nEnter the webhook channel configuration options:\nURL: The destination URL to which alert notifications will be sent.\nChannel Name: Add a meaningful name, such as Trello, Moogsoft, and so on.\nEnabled: Toggle enabling and disabling the webhook channel.\nNotification options: Send notifications when alerts are resolved or acknowledged.\nTest notification: Send a test notification upon saving to confirm that the webhook URL is reachable.\nShared With: Choose whether to apply this channel globally (All Teams) or to the team you are currently logged in as.\nComplete the steps described in Method and Headers, Payload, and Configure Test Notification.\nClick Save.\nWhen the channel is created, you can use it on any alerts that you create. When the alert fires, the notification will be sent as an HTTP request of the specified method in JSON format to your webhook endpoint.\nFor testing purposes, you can use a third-party site to create a temporary endpoint to see exactly what a Sysdig alert will send in any specific notification.\nMethod and Headers HTTP Method: You can choose an HTTP method for the request to be sent.\nPOST: Used for the creating resources. PUT: Used for the editing an existing resource. PATCH: Used for partially modifying an existing resource. DELETE: Used for deleting a resource. Content Type: For the custom webhook channel, application/json will always be the value of the content-type header for the request, even if this header does not appear on the headers list.\nAllow insecure connections: Check this option to skip TLS verification over HTTPS.\nCustom headers: Add custom headers to your alert notification.\nIf your webhook integrations require additional headers you can specify them by using a custom header. For example, Ansible uses token-based authentication, which requires an entry for the bearer token. This entry is not included in the default header, but you can add it using a custom header, such as Authorization: Bearer mytoken. Use this component to specify suitable header names and header values.\nNote that any Content type, Accept, and User-Agent header specified in this component will be discarded, as the default header value of Content-type:application/json cannot be overridden.\nPayloadEditor: The custom webhook channel allows you to fully customize the JSON payload that you want to send. The content of the editor represents the request body of the HTTP call you are sending to the third-party webhook. The data must be a valid JSON document. Systems that receive webhook alerts can parse the data and take action based on the contents.\nWhen triggered, the webhook channel allows dynamic referencing to properties of the alert and event which were created using the Sysdig Templating Language. Using the same system, basic conditional logic can also be written.\nConfigure Test NotificationAs an alternative to sending a test notification upon creating the channel, you can also test the channel before creating it. Use the Configure Test Notification editor to do so.\nIn the editor, you must pick the severity and alert type that best suits your scenario, and optionally trigger a test notification to the destination webhook URL.\nBuild PayloadsUse the Sysdig Templating Language to customize your payload using variable interpolation and basic conditional logic:\nReference alert variables with {{@alert_, for instance {{@alert_name}} Reference event variables with {{@event_, for instance {{@event_state}} Use conditional logic with {{#if_, for instance {{#if_metric_alert}}{{/if}} Reference labels with {{@event_labels}} for all, or specifically with for instance {{@event_labels.kube_cluster_name}} See Reference for all the allowed syntax parameters.\nAny text not matching the above keywords is accepted and dynamically rendered when the alert is triggered.\nFor more information, browse the on-screen documentation and examples that are provided in the form of snippets next to the code editor.\nReferenceSysdig Templating Language contains two types of constructs: statements and variables. Both of them are accessed from within {{ }} brackets, which are the only special characters in the payload that you define. Everything else is interpreted as plain text and passed along as is.\nStatementsStatements let you perform basic conditional logic. The common use case would be sending a different JSON payload in case of a high severity alert, such as:\n{ {{#if_severity_high}} \u0026#34;code\u0026#34;: \u0026#34;incident\u0026#34; {{#else}} \u0026#34;code\u0026#34;: \u0026#34;warning\u0026#34; {{/if}} } Whenever an alert triggers on this notification channel, the template is evaluated. In the presence of a high severity alert, the following payload is sent:\n{ \u0026#34;code\u0026#34;: \u0026#34;incident\u0026#34; } Whereas for all other cases, the following is sent:\n{ \u0026#34;code\u0026#34;: \u0026#34;warning\u0026#34; } Statements thus allow for conditional rendering of different sections of the payload.\nAll statementsif_severity_highConditional statement that matches an alert that was set with high severity.\nif_severity_mediumConditional statement that matches an alert that was set with medium severity.\nif_severity_lowConditional statement that matches an alert that was set with low severity.\nif_severity_infoConditional statement that matches an alert that was set with info severity.\nif_metric_alertConditional statement that matches a Threshold Alert. Threshold Alerts were formerly known as Metric Alerts, and if_metric_alert remains valid syntax for backwards compatibility.\nif_downtime_alertConditional statement that matches a downtime alert.\nif_prometheus_alertConditional statement that matches a prometheus alert.\nif_event_alertConditional statement that matches an event alert.\nif_anomaly_alertConditional statement that matches an anomaly detection alert.\nif_outlier_alertConditional statement that matches an outlier alert.\nif_resolved_eventConditional statement that matches an event which has been resolved.\nif_main_thresholdConditional statement that matches an event triggered on a main alert threshold.\nif_warning_thresholdConditional statement that matches an event triggered on a warning alert threshold.\nescapeAn escape block can be used to insert the grammar restricted characters, such as {{, anywhere in the payload. For example:\n{ \u0026#34;text\u0026#34;: \u0026#34;{{#escape}}a string with special {{ chars{{/escape}}\u0026#34; } An escape block can also spread between multiple lines, like so:\n{ \u0026#34;text\u0026#34;: \u0026#34; {{#escape}} a string with special {{ chars {{/escape}} \u0026#34; } VariablesVariables allow you to access alert and event properties. These are dynamically substituted upon rendering with the underlying properties of the configured alert or triggered event.\nVariables of type string are automatically escaped, but you can enclose them in quotes in order to generate a valid JSON payload.\nYou can enrich your alert data by adding segments to your alerts. Use the Group By field to add segments to an alert. The segments obtained from the Group By field are accessible from the @event_labels variable.\nAdd the variables to your Notification Channel\u0026rsquo;s payload:\nAlert Variablesalert_idType: Number.\nThe auto-generated unique alert identifier.\nExample: 1.\nalert_nameType: String.\nThe configured alert name.\nExample: High CPU Usage alert.\nalert_descriptionType: String.\nThe configured alert description.\nExample: Alert for when cpu load goes over 75%.\nalert_scopeType: String.\nThe configured alert scope.\nExample: kube_pod_name in ('backend-api').\nalert_severityType: String.\nThe configured alert severity label.\nPossible values: HIGH, MEDIUM, LOW, NONE.\nExample: HIGH.\nalert_group_byType: JSON String Array.\nA JSON String array with all the labels on which the alert has been grouped by.\nThis applies only to metric and event alerts.\nExample: ['kube_cluster_name', 'agent_id']'.\nalert_conditionType: String.\nThe configured alert main condition.\nThis applies only to metric and event alerts.\nExample: avg(avg(sysdig_container_cpu_used_percent)) \u0026gt; 75.0.\nalert_warning_conditionType: String,\nThe configured alert warning condition.\nThis applies only to metric and even alerts.\nExample: avg(avg(sysdig_container_cpu_used_percent)) \u0026gt; 50.0.\nalert_timespanType: Number.\nThe configured alert timespan.\nExample: 600000000.\nalert_urlType: String\nThe link to Sysdig Monitor\u0026rsquo;s Alert edit page.\nExample: https://app.sysdigcloud.com/#/alerts/rules/123456.\nEvent Variablesevent_stateType: String.\nPossible values: ACTIVE for triggered conditions and renotifications. OK for resolved conditions.\nExample: ACTIVE.\nevent_trigger_timestampType: Number.\nThe microseconds timestamp in which the event fired.\nExample: 1674140923000000.\nevent_resolved_timestampType: Number.\nThe microseconds timestamp in which the event resolved.\nExample: 1674140923000000.\nevent_trigger_metadataType: JSON Object.\nA JSON object, with metadata related to the triggering or renotification event, including the metric value that generated the event.\nExample:\n{ \u0026#34;entity\u0026#34;: \u0026#34;host_mac = \u0026#39;08:00:27:70:1a:03\u0026#39; and container_name = \u0026#39;container1_0\u0026#39;\u0026#34;, \u0026#34;metricValues\u0026#34;: [ { \u0026#34;metric\u0026#34;: \u0026#34;sysdig_container_cpu_used_percent\u0026#34;, \u0026#34;aggregation\u0026#34;: \u0026#34;avg\u0026#34;, \u0026#34;groupAggregation\u0026#34;: \u0026#34;avg\u0026#34;, \u0026#34;value\u0026#34;: 93.2359617776846 } ] } event_resolved_metadataType: JSON Object.\nA JSON object, with metadata related to the resolve event, including the metric value that cleared the alert condition.\nExample:\n{ \u0026#34;entity\u0026#34;: \u0026#34;host_mac = \u0026#39;08:00:27:70:1a:03\u0026#39; and container_name = \u0026#39;container1_0\u0026#39;\u0026#34;, \u0026#34;metricValues\u0026#34;: [ { \u0026#34;metric\u0026#34;: \u0026#34;sysdig_container_cpu_used_percent\u0026#34;, \u0026#34;aggregation\u0026#34;: \u0026#34;avg\u0026#34;, \u0026#34;groupAggregation\u0026#34;: \u0026#34;avg\u0026#34;, \u0026#34;value\u0026#34;: 33.2359617776846 } ] } event_labelsType: JSON Object.\nA JSON String to String object, mapping label names from the event\u0026rsquo;s context to their values.\nExample:\n{ \u0026#34;kube_cluster_name\u0026#34;: \u0026#34;my-cluster\u0026#34;, \u0026#34;agent_id\u0026#34;: \u0026#34;123\u0026#34; } event_titleType: String.\nThe configured title for the event.\nExample: High CPU Usage is Triggered on my-cluster.\nevent_bodyType: String\nThe body text for the event.\nExample:\nTEST ALERT: Testing Notification Channel dasdads Event Generated: Severity: Low Metric: sysdig_container_cpu_used_percent = 93.236 % Segment: container_name = \u0026#39;container1_0\u0026#39; and host_mac = \u0026#39;08:00:27:70:1a:03\u0026#39; Scope: host_hostname = \u0026#39;Host-0 (08:00:27:70:1a:03)\u0026#39; Time: 01/19/2023 03:10 PM UTC State: Triggered Notification URL: https://app-staging.sysdigcloud.com/#/events/notifications/l:2419200/2168/details ------ Triggered by Alert: Name: TEST ALERT: Testing Notification Channel dasdads Description: Alert description Team: Team for standard users. Scope: host_hostname = \u0026#39;Host-0 (08:00:27:70:1a:03)\u0026#39; Segment by: host_mac, container_name Alert When: avg(sysdig_container_cpu_used_percent) \u0026gt; 85 For at least: 10 m Alert URL: https://app-staging.sysdigcloud.com/#/alerts/rules?alertId=4322 event_conditionType: String.\nThe condition that made the event trigger or resolve.\nExample: avg(avg(sysdig_container_cpu_used_percent)) \u0026gt; 75.0.\nevent_condition_valueType: String.\nThe condition value that made the alert trigger or resolve formatted as a String.\nNote: For No Data triggering alerts this variable will be populated with \u0026ldquo;No Data\u0026rdquo;.\nExample: For an alert with condition avg(avg(sysdig_container_cpu_used_percent)) \u0026gt; 75.0 and an alert triggering at 80%, this variable will be populated with 80 %.\nevent_entityType: String.\nThe triggering alert segment (labels and values).\nExample: container_name = 'container1_0' and host_mac = '08:00:27:70:1a:03'.\nsysdig_event_idType: String.\nThe sysdig_event_id refers to the identifier associated with an event in the event feed. Unlike the event_id, which pertains specifically to alert occurrences, the sysdig_event_id allows you to directly reference and retrieve detailed information about an event recorded in the event feed.\nExample: 1234567891234567891.\nevent_idType: Number.\nThe event_id is a unique identifier associated with each alert occurrence. Unlike the sysdig_event_id, which is unique for every event in the event feed, the event_id remains constant across the entire lifecycle of an alert occurrence. You can use it as an incident key in incident management systems to acknowledge and resolve an alert notification.\nExample: 123456.\nevent_usernameType: String.\nThe username of the user responsible for triggering the event, if applicable, such as in the cases of test notifications.\nExample: user.name@sysdig.com.\nevent_urlType: String.\nThe url to the event details page within Sysdig Monitor.\nExample: https://appsysdigcloud.com/#/event-feed?last=3600\u0026amp;eventId=123456.\nevent_thresholdType: String.\nPossible values: MAIN for main condition triggering events, WARNING for warning condition triggering events.\nLearn More Integrate with Trello Integrate with Moogsoft ","url":"https://docs.sysdig.com/en/administration/configure-a-custom-webhook-channel/"},{"id":695,"title":"HAProxy Metrics","content":"See Application Integrations for more information.\nhaproxy.backend_hostsThe number of backend hosts.\nhaproxy.backend.bytes.in_rateThe rate of bytes in on backend hosts.\nhaproxy.backend.bytes.out_rateThe rate of bytes out on backend hosts.\nhaproxy.backend.connect.timeThe average connect time over the last 1024 requests.\nhaproxy.backend.denied.req_rateThe number of requests denied due to security concerns.\nhaproxy.backend.denied.resp_rateThe number of responses denied due to security concerns.\nhaproxy.backend.errors.con_rateThe rate of requests that encountered an error trying to connect to a backend server.\nhaproxy.backend.errors.resp_rateThe rate of responses aborted due to error.\nhaproxy.backend.queue.currentThe number of requests without an assigned backend.\nhaproxy.backend.queue.timeThe average queue time over the last 1024 requests.\nhaproxy.backend.response.1xxThe backend HTTP responses with 1xx code.\nhaproxy.backend.response.2xxThe backend HTTP responses with 2xx code.\nhaproxy.backend.response.3xxThe backend HTTP responses with 3xx code.\nhaproxy.backend.response.4xxThe backend HTTP responses with 4xx code.\nhaproxy.backend.response.5xxThe backend HTTP responses with 5xx code.\nhaproxy.backend.response.otherThe backend HTTP responses with another code (protocol error).\nhaproxy.backend.response.timeThe average response time over the last 1024 requests (0 for TCP).\nhaproxy.backend.session.currentThe number of active backend sessions.\nhaproxy.backend.session.limitThe configured backend session limit.\nhaproxy.backend.session.pctThe percentage of sessions in use. The formula used for this metric is backend.session.current / backend.session.limit * 100.\nhaproxy.backend.session.rateThe number of backend sessions created per second.\nhaproxy.backend.session.timeThe average total session time over the last 1024 requests.\nhaproxy.backend.uptimeThe number of seconds since the last UP\u0026lt;-\u0026gt;DOWN transition.\nhaproxy.backend.warnings.redis_rateThe number of times a request was redispatched to another server.\nhaproxy.backend.warnings.retr_rateThe number of times a connection to a server was retried.\nhaproxy.count_per_statusThe number of hosts by status (UP/DOWN/NOLB/MAINT).\nhaproxy.frontend.bytes.in_rateThe rate of bytes in on frontend hosts.\nhaproxy.frontend.bytes.out_rateThe rate of bytes out on frontend hosts.\nhaproxy.frontend.denied.req_rateThe number of requests denied due to security concerns.\nhaproxy.frontend.denied.resp_rateThe number of responses denied due to security concerns.\nhaproxy.frontend.errors.req_rateThe rate of request errors.\nhaproxy.frontend.requests.rateThe number of HTTP requests per second.\nhaproxy.frontend.response.1xxThe frontend HTTP responses with 1xx code.\nhaproxy.frontend.response.2xxThe frontend HTTP responses with 2xx code.\nhaproxy.frontend.response.3xxThe frontend HTTP responses with 3xx code.\nhaproxy.frontend.response.4xxThe frontend HTTP responses with 4xx code.\nhaproxy.frontend.response.5xxThe frontend HTTP responses with 5xx code.\nhaproxy.frontend.response.otherThe frontend HTTP responses with another code (protocol error).\nhaproxy.frontend.session.currentThe number of active frontend sessions.\nhaproxy.frontend.session.limitThe configured backend session limit.\nhaproxy.frontend.session.pctThe percentage of sessions in use. The formula used for this metric is frontend.session.current / frontend.session.limit * 100.\nhaproxy.frontend.session.rateThe number of frontend sessions created per second.\nAgent 9.6.0 Additional HAProxy Metrics haproxy.backend.requests.tot_rate\nRate of total number of HTTP requests\nhaproxy.frontend.connections.rate\nNumber of connections per second\nhaproxy.frontend.connections.tot_rate\nRate of total number of connections\nhaproxy.frontend.requests.intercepted\nNumber of intercepted requests per second\nhaproxy.frontend.requests.tot_rate\nRate of total number of HTTP requests\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/haproxy-metrics/"},{"id":696,"title":"HTTP","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nHTTP SetupYou do not need to configure anything on HTTP-based applications for the Sysdig agent to connect.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationNo default entry is present in the dragent.default.yaml for the HTTP check. You need to add an entry in dragent.yaml as shown in following examples.\nNever edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1First you must identify the process pattern (comm:). It must match an actively running process for the HTTP check to work. Sysdig recommends the process be the one that is serving the URL being checked.\nIf the URL is is remote from the agent, the user should use a process that is always running, such as \u0026ldquo;systemd\u0026rdquo;.\nConfirm the \u0026ldquo;comm\u0026rdquo; value using the following command:\ncat /proc/1/comm Add the following entry to the dragent.yaml file and modify the 'name:''comm:' and 'url:' parameters as needed:\napp_checks: - name: EXAMPLE_WEBSITE check_module: http_check pattern: comm: systemd conf: url: https://www.MYEXAMPLE.com Example 2There are multiple configuration options available with the HTTP check. A full list is provided in the table following Example 2. These keys should be listed under the conf: section of the configuration in Example 1.\napp_checks: - name: EXAMPLE_WEBSITE check_module: http_check pattern: comm: systemd conf: url: https://www.MYEXAMPLE.com # timeout: 1 # method: get # data: # \u0026lt;KEY\u0026gt;: \u0026lt;VALUE\u0026gt; # content_match: \u0026#39;\u0026lt;REGEX\u0026gt;\u0026#39;\u0026#39; # reverse_content_match: false # username: \u0026lt;USERNAME\u0026gt; # ntlm_domain: \u0026lt;DOMAIN\u0026gt; # password: \u0026lt;PASSWORD\u0026gt; # client_cert: /opt/client.crt # client_key: /opt/client.key # http_response_status_code: (1|2|3)\\d\\d # include_content: false # collect_response_time: true # disable_ssl_validation: true # ignore_ssl_warning: false # ca_certs: /etc/ssl/certs/ca-certificates.crt # check_certificate_expiration: true # days_warning: \u0026lt;THRESHOLD_DAYS\u0026gt; # check_hostname: true # ssl_server_name: \u0026lt;HOSTNAME\u0026gt; # headers: # Host: alternative.host.example.com # X-Auth-Token: \u0026lt;AUTH_TOKEN\u0026gt; # skip_proxy: false # allow_redirects: true # include_default_headers: true # tags: # - \u0026lt;KEY_1\u0026gt;:\u0026lt;VALUE_1\u0026gt; # - \u0026lt;KEY_2\u0026gt;:\u0026lt;VALUE_2\u0026gt; Key\nDescription\nurl\nThe URL to test.\ntimeout\nThe time in seconds to allow for a response.\nmethod\nThe HTTP method. This setting defaults to GET, though many other HTTP methods are supported, including POST and PUT.\ndata\nThe data option is only available when using the POST method. Data should be included as key-value pairs and will be sent in the body of the request.\ncontent_match\nA string or Python regular expression. The HTTP check will search for this value in the response and will report as DOWN if the string or expression is not found.\nreverse_content_match\nWhen true, reverses the behavior of the content_matchoption, i.e. the HTTP check will report as DOWN if the string or expression in content_match IS found. (default is false)\nusername \u0026amp; password\nIf your service uses basic authentication, you can provide the username and password here.\nhttp_response_status_code\nA string or Python regular expression for an HTTP status code. This check will report DOWN for any status code that does not match. This defaults to 1xx, 2xx and 3xx HTTP status codes. For example: 401 or 4\\d\\d.\ninclude_content\nWhen set to true, the check will include the first 200 characters of the HTTP response body in notifications. The default value is false.\ncollect_response_time\nBy default, the check will collect the response time (in seconds) as the metric network.http.response_time. To disable, set this value to false.\ndisable_ssl_validation\nThis setting will skip SSL certificate validation and is enabled by default. If you require SSL certificate validation, set this to false. This option is only used when gathering the response time/aliveness from the specified endpoint. Note this setting doesn't apply to the check_certificate_expirationoption.\nignore_ssl_warning\nWhen SSL certificate validation is enabled (see setting above), this setting allows you to disable security warnings.\nca_certs\nThis setting allows you to override the default certificate path as specified in init_config\ncheck_certificate_expiration\nWhen check_certificate_expiration is enabled, the service check will check the expiration date of the SSL certificate.\nNote that this will cause the SSL certificate to be validated, regardless of the value of the disable_ssl_validation setting.\ndays_warning\nWhen check_certificate_expiration is enabled, these settings will raise a warning alert when the SSL certificate is within the specified number of days from expiration.\ncheck_hostname\nWhen check_certificate_expiration is enabled, this setting will raise a warning if the hostname on the SSL certificate does not match the host of the given URL.\nheaders\nThis parameter allows you to send additional headers with the request. e.g. X-Auth-Token: \u0026lt;AUTH_TOKEN\u0026gt;\nskip_proxy\nIf set, the check will bypass proxy settings and attempt to reach the check URL directly. This defaults to false.\nallow_redirects\nThis setting allows the service check to follow HTTP redirects and defaults to true.\ntags\nA list of arbitrary tags that will be associated with the check.\nMetrics AvailableHTTP metrics concern response time and SSL certificate expiry information.\nSee HTTP Metrics.\nService Checkshttp.can_connect:\nReturns DOWN when any of the following occur:\nthe request to URL times out\nthe response code is 4xx/5xx, or it doesn\u0026rsquo;t match the pattern provided in the http_response_status_code\nthe response body does not contain the pattern in content_match\nreverse_content_match is true and the response body does contain the pattern in content_match\nURI contains https and disable_ssl_validation is false, and the SSL connection cannot be validated\nOtherwise, returns UP.\nSegmentation of the http.can_connect can be done by URL.\nhttp.ssl_cert:\nThe check returns:\nDOWN if the URL\u0026rsquo;s certificate has already expired\nWARNING if the URL\u0026rsquo;s certificate expires in less than days_warning days\nOtherwise, returns UP.\nTo disable this check, set check_certificate_expiration to false.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/http/"},{"id":697,"title":"Integrate Keda for HPA","content":"This option replaces the legacy custom metric server for HPA.\nInstall KedaRequirements: Helm Keda v2.3 or above (Endpoint authentication) Install Keda with helm by running the following command:\nhelm repo add kedacore https://kedacore.github.io/charts helm repo update helm install keda kedacore/keda --namespace keda --create-namespace \\ --set image.metricsApiServer.tag=2.4.0 --set image.keda.tag=2.4.0 \\ --set prometheus.metricServer.enabled=true Create Authentication for Sysdig Prometheus EndpointDo the following in each namespace where you want to use Keda. This example uses the namespace, keda.\nCreate the secret with the API key as the bearer token:\nkubectl create secret generic keda-prom-secret --from-literal=bearerToken=\u0026lt;API_KEY\u0026gt; -n keda Create the triggerAuthentication.yaml file:\napiVersion: keda.sh/v1alpha1 kind: TriggerAuthentication metadata: name: keda-prom-creds spec: secretTargetRef: - parameter: bearerToken name: keda-prom-secret key: bearerToken Apply the configurations in the triggerAuthentication.yaml file :\nkubectl apply -f -n keda triggerAuthentication.yaml Configure HPAYou can configure HPA for a Deployment, StatefulSet, or CRD. Keda uses a CRD to configure the HPA. You create a ScaledObject and it automatically sets up the metrics server and the HPA object under the hood.\nTo create a ScaledObject, specify the following:\nspec.scaleTargetRef.name: The unique name of the Deployment. spec.scaleTargetRef.kind: The kind of object to be scaled: Deployment, SStatefulSet, CustomResource. spec.minReplicaCount: The minimum number of replicas that the Deployment should have. spec.maxReplicaCount: The maximum number of replicas that the Deployment should have. In the ScaledObject, use a trigger of type prometheus to get the metrics from your Sysdig Monitor account. To do so, specify the following:\ntriggers.metadata.serverAddress: The address of the Prometheus endpoint. It is the Sysdig Monitor URL with prefix /prometheus. For example: https://app.sysdigcloud.com/prometheus. triggers.metadata.query: The PromQL query that will return a value. Ensure that the query returns a vector/scalar single element response. triggers.metadata.metricName: The name of the metric that will be created in the kubernetes API endpoint, /apis/external.metrics.k8s.io/v1beta1. triggers.metadata.threshold: The threshold that will be used to scale the Deployment. Ensure that you add the authModes and authenticationRef to the trigger.\nCheck the ScaledObject. Here is an example of a ScaledObject:\napiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: keda-web spec: scaleTargetRef: kind: Deployment name: web minReplicaCount: 1 maxReplicaCount: 4 triggers: - type: prometheus metadata: serverAddress: https://app.sysdigcloud.com/prometheus metricName: sysdig_container_cpu_cores_used query: sum(sysdig_container_cpu_cores_used{kube_cluster_name=\u0026#34;my-cluster-name\u0026#34;, kube_namespace_name=\u0026#34;keda\u0026#34;, kube_workload_name = \u0026#34;web\u0026#34;} * 10 threshold: \u0026#34;5\u0026#34; authModes: \u0026#34;bearer\u0026#34; authenticationRef: name: keda-prom-creds The HPA will divide the value of the metric by the number of current replicas, therefore, try to avoid using the AVERAGE aggregation. Use SUM instead to aggregate the metrics by workload. For example, if the sum of all the values of all the pods is 100 and there are 5 replicas, the HPA will calculate that the value of the metric is 20.\nAdvanced ConfigurationsThe ScaledObject permits additional options:\nspec.pollingInterval:\nSpecify the interval to check each trigger on. By default KEDA will check each trigger source on every ScaledObject every 30 seconds.\nWarning: setting this to a low value will cause Keda to make frequent API calls to the Prometheus endpoint. The minimum value for pollingInterval is 10 seconds. The scraping frequency of the Sysdig Agent is 10 seconds.\nspec.cooldownPeriod:\nThe wait period between the last active trigger reported and scaling the resource back to 0. By default the value is 5 minutes (300 seconds).\nspec.idleReplicaCount:\nEnabling this property allows KEDA to scale the resource down to the specified number of replicas. If some activity exists on the target triggers, KEDA will scale the target resource immediately to the value of minReplicaCount and scaling is handed over to HPA. When there is no activity, the target resource is again scaled down to the value specified by idleReplicaCount. This setting must be less than minReplicaCount.\nspec.fallback:\nThis property allows you to define a number of replicas if consecutive connection errors happens with the Prometheus endpoint of your Sysdig account.\nspec.fallback.failureThreshold: The number of consecutive errors to apply the fallback. spec.fallback.replicas: The number of replicas to apply in case of connection error. spec.advanced.horizontalPodAutoscalerConfig.behavior:\nThis property allows you to define the behavior of the Kubernetes HPA Object. See the Kubernetes documentation for more information.\nLearn More Trigger a Kubernetes HPA with Prometheus Metrics Trigger a Kubernetes HPA with Sysdig Metrics ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/custom-integrations/configure-keda/"},{"id":698,"title":"JVM","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\njvm.class.loadedThe number of classes currently loaded in the JVM. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\njvm.class.unloadedjvm.gc.ConcurrentMarkSweep.countThe number of times the Concurrent Mark-Sweep garbage collector has run.\njvm.gc.ConcurrentMarkSweep.timeThe total time the Concurrent Mark-Sweep garbage collector has run.\njvm.gc.Copy.countjvm.gc.Copy.timejvm.gc.G1_Old_Generation.countjvm.gc.G1_Old_Generation.timejvm.gc.G1_Young_Generation.countjvm.gc.G1_Young_Generation.timejvm.gc.global.timeThe total time the garbage collection has run.\njvm.gc.MarkSweepCompact.countjvm.gc.MarkSweepCompact.timejvm.gc.PS_MarkSweep.countThe number of times the parallel scavenge Mark-Sweep old generation garbage collector has run.\njvm.gc.PS_MarkSweep.timeThe total time the parallel scavenge Mark-Sweep old generation garbage collector has run.\njvm.gc.PS_Scavenge.countThe number of times the parallel eden/survivor space garbage collector has run.\njvm.gc.PS_Scavenge.timeThe total time the parallel eden/survivor space garbage collector has run.\njvm.gc.ParNew.countThe number of times the parallel garbage collector has run.\njvm.gc.ParNew.timeThe total time the parallel garbage collector has run.\njvm.gc.scavenge.timeThe total time the scavenge collector has run.\njvm.heap.committedThe amount of memory that is currently allocated to the JVM for heap memory. Heap memory is the storage area for Java objects. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\nThe JVM may release memory to the system and Heap Committed could decrease below Heap Init; but Heap Committed can never increase above Heap Max.\njvm.heap.initThe initial amount of memory that the JVM requests from the operating system for heap memory during startup (defined by the –Xms option).The value of Heap Init may be undefined. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\nThe JVM may request additional memory from the operating system and may also release memory to the system over time.\njvm.heap.maxThe maximum size allocation of heap memory for the JVM (defined by the –Xmx option). By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\nAny memory allocation attempt that would exceed this limit will cause an OutOfMemoryError exception to be thrown.\njvm.heap.usedThe amount of allocated heap memory (ie Heap Committed) currently in use. The number of classes currently loaded in the JVM. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\nHeap memory is the storage area for Java objects.\nAn object in the heap that is referenced by another object is ’live’, and will remain in the heap as long as it continues to be referenced. Objects that are no longer referenced are garbage and will be cleared out of the heap to reclaim space.\njvm.heap.used.percentThe ratio between Heap Used and Heap Committed. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\njvm.nonHeap.committedThe amount of memory that is currently allocated to the JVM for non-heap memory. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\nNon-heap memory is used by Java to store loaded classes and other meta-data.\nThe JVM may release memory to the system and Non-Heap Committed could decrease below Non-Heap Init; but Non-Heap Committed can never increase above Non-Heap Max.\njvm.nonHeap.initThe initial amount of memory that the JVM requests from the operating system for non-heap memory during startup. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\nThe value of Non-Heap Init may be undefined.\nThe JVM may request additional memory from the operating system and may also release memory to the system over time.\njvm.nonHeap.maxThe maximum size allocation of non-heap memory for the JVM. This memory is used by Java to store loaded classes and other meta-data. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\njvm.nonHeap.usedThe amount of allocated non-heap memory (Non-Heap Committed) currently in use. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\nNon-heap memory is used by Java to store loaded classes and other meta-data.\njvm.nonHeap.used.percentThe ratio between Non-Heap Used and Non-Heap Committed. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\njvm.thread.countThe current number of live daemon and non-daemon threads. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\njvm.thread.daemonThe current number of live daemon threads. By default, this metric shows the total value of the selected scope. For example, if applied to a group of machines, the value will be the total value for the whole group.\nDaemon threads are used for background supporting tasks and are only needed while normal threads are executing.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/jvm/"},{"id":699,"title":"List Matching Policy","content":" List Matching Policies and rules are being retired on February 28, 2026. Read more in the deprecation notice.\nEvent notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nConvert to Falco rulesList-matching rules can be implemented as simple Falco rules, allowing you to:\nCreate exceptions, useful to fine-tune detections based on expected behaviors Create narrower conditions, to spot more precise behaviors, identifying detections more precisely Define a personalized output, based on the attributes you\u0026rsquo;re interested in and better explaining the event being displayed In the following sections we describe a programmatic way to approach that.\nContainer Rule ConversionA Container List matching rule detects container events when the image has a match, positive or negative, with respect to a list of images. You can specify the images by name, optionally using the repository url, the tag and the digest.\nWhile this is possible in Falco, you would need to build a complex rule using different attributes (container.image, container.image.repository, container.image.tag, container.image.digest). More simply, you can use the contains operator against the container.image field and obtain a coarser match. Unless you\u0026rsquo;re looking for an exact match, it\u0026rsquo;s not possible to use list operators, so the list of images specified in the list-matching rules needs to be exploded in OR-ed comparisons. Using the contains approach as reference, a list \u0026ldquo;image1, image2, image3\u0026rdquo; would be expanded as:\ncontainer.image contains \u0026#34;image1\u0026#34; or container.image contains \u0026#34;image2\u0026#34; or container.image contains \u0026#34;image3\u0026#34; Original rule: Overall the resulting rule, with a positive-matching pattern, can be written as the following Falco rule:\n- rule: my-container-list-matching-rule description: ... condition: \u0026gt;- evt.type = container and (container.image contains \u0026#34;image1\u0026#34; or container.image contains \u0026#34;image2\u0026#34; or container.image contains \u0026#34;image3\u0026#34;) output: \u0026#39;%container.id %container.name %container.image %container.image.id\u0026#39; source: syscall priority: info The matching can be made negative by prepending not to the container.image-related expression, wrapping it between parenthesis.\nFile system rule conversionA File system List matches file open events against:\nA list of read/write files (see rw_files), with a positive/negative matching pattern A list of read files (see r_files), with a positive/negative matching pattern Original rule: This can be equivalently written, with positive-matching patterns, as:\n- rule: my-file-list-matching-rule description: ... condition: \u0026gt;- evt.type in (open, openat) and evt.dir=\u0026lt; and evt.rawres \u0026gt; 0 and ( evt.is_open_write = true and fd.name pmatch (\u0026lt;rw_files\u0026gt;)) or ( evt.is_open_read = true and evt.is_open_write=false and fd.name pmatch (\u0026lt;r_files\u0026gt;)) output: \u0026#39;%evt.type %fd.name %evt.arg[1] %evt.arg[2] %evt.abspath %evt.abspath.dst\u0026#39; source: syscall priority: info You might want to cover additional use cases by adding other file-related events:\nmkdir mkdirat rmdir rename renameat unlink unlinkat The matching pattern can be made negative by prepending not to fd.name pmatch (...). Network Rule ConversionA Network List matching rule can detect inbound and/or outbound connections, based on the enabling or disabling of the direction (Deny means it\u0026rsquo;s enabled). That detection applies only to the TCP and UDP server ports specified.\nOriginal rule: This can be equivalently written with positive-matching patterns, as:\n- rule: my-network-list-matching-rule description: ... condition: \u0026gt;- (inbound or outbound) and (fd.l4proto = tcp and fd.sport in (\u0026lt;tcp_ports\u0026gt;)) or (fd.l4proto = udp and fd.sport in (\u0026lt;udp_ports\u0026gt;)) ) output: \u0026#39;%fd.l4proto %fd.cip %fd.cport %fd.sip %fd.sport\u0026#39; source: syscall priority: info The matching patterns can be made negative by prepending not to fd.sport in (...). The example above matches both inbound and outbound connections. This can be configured as in the List-matching rule by removing \u0026ldquo;allowed\u0026rdquo;. inbound and outbound are Macros available out of the box. Read more about macros here.\nProcess Rule ConversionA Process List matching rule generates events for process executions, when the process is (or is not) in a list of processes that you specify (see proc_list).\nOriginal rule: This can be equivalently written as:\n- rule: my-process-list-matching-rule description: ... condition: evt.type in (execve) and proc.name in (\u0026lt;proc_list\u0026gt;) output: \u0026#39;%proc.name\u0026#39; source: syscall priority: info The matching pattern can be made negative by prepending not to proc.name in (...).\nSyscall Rule ConversionA Syscall List matching rule has a list of syscalls it matches against, with a positive or negative matching pattern.\nThis rule can be extremely noisy, so it’s not recommended to use it in production environments. It can still be useful to learn about Falco and experimenting with the Sysdig’s detections.\nOriginal rule: This can be equivalently written, with positive-matching pattern, as:\n- rule: my-syscall-list-matching-rule description: ... condition: evt.type in (\u0026lt;values\u0026gt;) output: \u0026#39;%evt.type\u0026#39; source: syscall priority: info The matching pattern can be made negative by prepending not to evt.type in (...).\nCreate a List Matching PolicyTo create a List Matching policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select List Matching.\nConfigure a List Matching PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so it generates events.\nSeverity: Choose the appropriate severity level you would like to see in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nKill ProcessToggle Kill Process on to have the policy automatically kill the process that triggered the event. This works for container events and hosts, and honors the agent flag to ignore actions at the agent.\nContainersSelect what should happen to affected containers if the policy rules are breached:\nNo container action: Do not change the container behavior; send a notification according to Notification Channel settings. Kill: Kill one or more running containers immediately. Stop: Allow a graceful shutdown (10-seconds) before killing the container. Pause: Suspend all processes in the specified containers. For details, see Available Response Actions.\nThe agent can be configured to prevent Kill, Pause or Stop actions regardless of the policy.\nSee Ignore Container Actions at the Agent Level.\nCaptureToggle Capture on if you want to create a capture in case of an event, and define the number of seconds before and after the event that should be in the snapshot.\nAs of June 2021, you can add the Capture option to policies affecting events from both the Sysdig agent and Fargate Serverless Agents Fargate serverless agents.\nNote that for serverless agents, manual captures are not supported; you must toggle on the Capture option in the policy definition.\nSee also: Captures.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate members of your staff or team.\nSee also: Set Up Notification Channels.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and List Matching.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, choose List Matching to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/list_matching_policy/"},{"id":700,"title":"On-Premises Deployments","content":"Oversight Services for Installations and Upgrades Sysdig offers oversight services for all on-premises installs and upgrades. Your Technical Account Manager (TAM), in conjunction with our support organization and Professional Services [where applicable], will work with you to:\nAssess your environment to ensure it is configured correctly.\nReview your infrastructure to validate the appropriate storage capacities are available.\nReview and provide recommendations for backing up your Sysdig data.\nProvide the software for the install.\nAssist you during the install and upgrade process to ensure a successful deployment.\nYou can always review the process in the on-prem repository or documentation site.\nIf you are a new user looking to explore Sysdig, contact us directly.\nLearn More Install and Upgrade Documentation ","url":"https://docs.sysdig.com/en/administration/on-premises-deployments/"},{"id":701,"title":"Prometheus Metrics Types","content":"Calculated MetricsThe Prometheus metrics that are scraped by the Sysdig agent and transformed into the traditional StatsD model are called calculated metrics. In calculated metrics, the delta is stored with the previous value. This delta is what Sysdig uses on the classic backend for metrics analyzing and visualization. While generating the calculated metrics, the gauge metrics are kept as they are, but the counter metrics are transformed.\nPrometheus calculated metrics cannot be used in PromQL.\nThe Histogram and Summary metrics are transformed into a different format called Prometheus histogram and summary metrics respectively. The transformations include:\nAll of the quantiles are transformed into a different metric, with the quantile added as a suffix.\nThe count and sum of these summary metrics are exposed as different metrics with names slightly changed. _ (underscore) in the name is replaced with a period .. For more information, see Mapping Classic Metrics and PromQL Metrics.\nPrometheus calculated metrics (legacy metrics) are scheduled to be deprecated in the coming months.\nRaw MetricsIn Sysdig parlance, the Prometheus metrics that are scraped (by the Sysdig agent), collected, sent, stored, visualized, and presented exactly as Prometheus exposes them are called raw metrics. Raw metrics are used with PromQL.\nSysdig counter is a StatsD type counter, where the difference in value is kept, but not the raw value of the counter, whereas Prometheus raw metrics are counters that are always monotonically increasing. A rate function needs to be applied on Prometheus raw metrics to make sense of it.\nTime Aggregations Over Prometheus MetricsThe following time aggregations are supported for both the metric types:\nAverage: Returns an average of a set of data points, keeping all the labels.\nMaximum and Minimum: Returns a maximal or minimal value, keeping all the labels.\nSum: Returns a sum of the values of data points, keeping all the labels.\nRate (timeAvg): Returns a sum of changes to the counter across data points in a given time period and divides by time, keeping all the labels as they are. For Prometheus raw metrics, timeAvg is calculated by taking the difference and dividing it by time.\nPrometheus Calculated MetricsPrometheus calculated metrics are treated as gauges by Sysdig, and there the following time aggregations are available:\nAverage\nSum\nMinimum\nMaximum\nRate (timeAvg) is not available because they are not applicable to gauge metrics.\nPrometheus Raw MetricsFor the gauge type, the following types are available:\nAverage\nMinimum\nMaximum\nFor the counter type, the following types are available:\nRate: Calculates the first derivative of the counter (change over time).\nSum: Calculates a complete change of the counter over a period of time.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/prometheus-metrics-types/"},{"id":702,"title":"Provider","content":"sysdig_cloud_provider_info Prometheus ID sysdig_cloud_provider_info Legacy ID info Metric Type gauge Unit number Description The metrics will always have the value of 1. Additional Notes ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/provider/"},{"id":703,"title":"Sysdig Sage for Monitor","content":" Sysdig Sage for Monitor is in Controlled Availability. Contact your Sysdig representative to request access.\nEnable Sysdig SageSysdig Sage for Monitor must first be enabled on your account. Contact your Customer Success Engineer (CSE) to request activation.\nOnce activated, a Sysdig Monitor administrator must grant Sysdig Sage permissions to the desired teams:\nCreate a Custom Role for Sysdig SageTo use Sysdig Sage, create a custom role and assign the required permissions:\nLog in to Sysdig Monitor as an Admin. Go to Settings \u0026gt; Roles. Click New Role. Scroll down to the Monitor section and locate Sysdig Sage. From the Sysdig Sage dropdown, select Full Access. Click Save. For more information about creating roles, see Create a Custom Role.\nCreate a Team for Sysdig SageCreate a team to group the users who need access to Sysdig Sage. You will assign this team the custom role in the next step.\nSelect Settings \u0026gt; Teams. Click Add team. Configure the team and select Save. For more information about team creation, see Create a Team.\nAssign Users to the Sysdig Sage RoleAssign users to the Sysdig Sage team and grant them the custom role you created:\nLog in to Sysdig Monitor as an Admin. Go to Settings \u0026gt; Teams. Select the team you configured for Sysdig Sage. In the Team Users tab, click Assign User. From the User dropdown, select the user. From the Role dropdown, select the Sysdig Sage role you created. Click Save. The user now has access to Sysdig Sage.\nGet Started with Sysdig Sage Log in to Sysdig Monitor. Click the Sysdig Sage icon on the right side of the screen. Enter your question or request in plain language. What You Can Ask Sysdig Sage Use case Description Troubleshoot Kubernetes issues From the events page, click Ask Sysdig Sage. Sysdig Sage investigates the incident using metrics, events, and live logs to provide a diagnosis with remediation steps. Translate natural language to PromQL Enter a question in plain language and Sysdig Sage generates and runs the corresponding PromQL query. For example: \u0026ldquo;What is the CPU usage of my nginx pods?\u0026rdquo; or \u0026ldquo;Show me memory consumption by namespace.\u0026rdquo; Explore your environment Ask about cluster health, workload status, or resource utilization, and Sysdig Sage correlates signals across your infrastructure. Data SourcesSysdig Sage queries the following data sources to build context for each conversation:\nData source Description Metrics PromQL queries for CPU, memory, disk, network, and node-level health signals. Dashboards and alerts Sysdig Sage correlates queries from your existing alerts and dashboards, and suggests relevant dashboards to help identify the root cause. Kubernetes events Deployment events, pod lifecycle events, and scheduling decisions. Kubernetes Advisories Active advisories surfaced from Kubernetes Advisor. Live logs Stack traces, panics, and configuration errors from pod output. Disable Sysdig SageRemove User AccessTo revoke Sysdig Sage access for a specific user:\nGo to Settings \u0026gt; Teams. Select the team you created for Sysdig Sage users. Click the Team Users tab. Click the options menu (⋮) on the user\u0026rsquo;s row and select Remove User. Disable Sysdig Sage for Your AccountTo fully disable Sysdig Sage across your account, contact your Sysdig representative.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/sysdig-sage/"},{"id":704,"title":"Sysdig Sage","content":"Enable Sysdig SageTo enable Sysdig Sage:\nLog in to Sysdig Secure as an Admin and choose Settings \u0026gt; Terms \u0026amp; Conditions \u0026gt; Activation and T\u0026amp;C\nSlide the toggle to enable Sysdig Sage.\nIf you are not an Admin, contact your Admin to enable Sysdig Sage for you.\nTo enable Sysdig Sage for another user, you must create a custom role and team:\nCreate a Custom Role for Sysdig SageTo use Sysdig Sage, create a custom role and assign the required permissions:\nLog in to Sysdig Secure as an Admin.\nSelect Settings \u0026gt; Roles.\nClick New Role.\nScroll down and find Captures/Investigate, Threats and Sysdig Sage.\nGrant the following permissions:\nPermissions Settings Sysdig Sage: Full Access Threats: Read only Captures and Investigate: Custom Click Save. For more information about creating roles, see Create a Custom Role.\nNext, you must create a team for Sysdig Sage Users.\nCreate a Team for Sysdig SageWe recommend you create a team for Sysdig Sage users for ease of operations:\nSelect Settings \u0026gt; Teams.\nClick Add team.\nConfigure the team and select Save.\nFor more information about team creation, see Create a Team.\nAssign Users to the Sysdig Sage RoleAdd users to the Team you set up for Sysdig Sage users and assign them the custom role you created for Sysdig Sage. See Assign a User to a Team for more information.\nLog in to Sysdig Secure as an Admin.\nSelect Settings \u0026gt; Teams.\nFrom the Teams page, select the team you configured.\nIn the Team Users tab and click Assign User.\nFor User, select the user from the drop-down. For Role, select the Sysdig Sage role you configured.\nSelect Save.\nThe user now has access to Sysdig Sage.\nGet Started with Sysdig Sage Log in to Sysdig Secure.\nClick the Sysdig Sage icon or bar on the right side of the screen.\nEnter your prompt.\nSee Example Prompts for more information.\nOptionally, you can perform the following operations:\nOperations Settings Clear Chat Close the Sysdig Sage window Expand the Sysdig Sage window Minimize the Sysdig Sage window Disable Sysdig SageAs an account administrator, you can disable Sysdig Sage from Settings \u0026gt; Sysdig Sage | Activation and T\u0026amp;C. Once disabled, Sysdig Sage will be deactivated for all users in your account.\nTo remove specific users:\nNavigate to Settings \u0026gt; Teams. Select the team you created for Sysdig Sage users. Click the Team Users tab and locate individual users for removal. Select the three-dot menu on each row and click Remove user. ","url":"https://docs.sysdig.com/en/sysdig-sage/"},{"id":705,"title":"Configure Theme Preference","content":"To configure a theme:\nLog in to Sysdig Secure or Sysdig Monitor.\nNavigate to the user menu in the bottom left corner of the screen.\nDo one of the following:\nSelect Theme from the upper right corner of the user menu. Click Settings and choose User Profile. Under Appearance, select the desired theme from the Theme Preferences drop-down.\nMatch OS Preferences: The theme will be aligned with that of your operating system. For example, if your Desktop theme is Dark, the app theme will also be set to Dark.\nYour OS theme will override the application theme preferences. For example, changing the OS theme to Dark while your application theme preference is Light will automatically switch the application theme to Dark.\n","url":"https://docs.sysdig.com/en/administration/configure_theme_preference/"},{"id":706,"title":"Custom Webhook for Moogsoft","content":" Prerequisites Review Custom Webhook.\nRetrieve the Moogsoft API key:\nLog in to Moogsoft and select Settings \u0026gt; API Key Management.\nOn the API Key Management page, create a new API key for your Sysdig webhook integration.\nCopy the key.\nThe key will be displayed only once; therefore, store it safely for later use.\nFrom Integrations \u0026gt; Ingestion Services \u0026gt; Events API, copy the events endpoint.\nhttps://api.moogsoft.ai/v1/integrations/events\nYou use this endpoint to configure the webhook in Sysdig Monitor.\nConfiguration Complete steps 1-3 in Set Up a Notification Channel and select Custom Webhook.\nEnter the Webhook channel configuration options:\nURL: Enter the Moogsoft events endpoint: https://api.moogsoft.ai/v1/integrations/events Channel Name: Add a meaningful name, such as \u0026ldquo;Moogsoft Incident\u0026rdquo;. For the Method and Headers, specify the following:\nHeader: apiKey Value: The API key you copied from the Moogsoft API Key Management page. In the Payload Editor, use Sysdig Templating Language to customize the alert notification payload.\nUnlike Sysdig Monitor, Moogsoft uses integer-based severity, which means the severity must be translated.\nFor example:\n{ \u0026#34;check\u0026#34;: \u0026#34;{{@alert_name}}\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;{{@alert_description}}\u0026#34;, \u0026#34;source\u0026#34;: \u0026#34;Sysdig Monitor\u0026#34;, {{#if_resolved_event}} \u0026#34;severity\u0026#34;: 0, {{#else}} {{#if_severity_high}} \u0026#34;severity\u0026#34;: 5, {{#else if_severity_medium}} \u0026#34;severity\u0026#34;: 4, {{#else if_severity_low}} \u0026#34;severity\u0026#34;: 3, {{#else if_severity_info}} \u0026#34;severity\u0026#34;: 2, {{/if}} {{/if}} \u0026#34;tags\u0026#34;: {{@event_labels}} } Click Save.\n","url":"https://docs.sysdig.com/en/administration/configure-a-custom-webhook-channel/moogsoft/"},{"id":707,"title":"Custom Webhook for Trello","content":" Prerequisites Review Custom Webhook.\nLog in to your Trello account with admin rights and do the following:\nObtain your trello apiKey and token.\nFor more information, see the REST API Authorization guide.\nCreate a Trello board on your account and ensure that you create at least one list on it.\nPerform the following request in order to obtain the ID of one of the lists existing on the board:\ncurl --request GET --url \u0026#39;https://api.trello.com/1/boards/\u0026lt;boardId\u0026gt;/lists?key=\u0026lt;key\u0026gt;\u0026amp;token=\u0026lt;token\u0026gt;\u0026#39; Where boardId is the ID present on the URL in the browser when accessing the board\u0026rsquo;s main page, and key and token are the authentication requirements obtained in step 2.\nAn example response is given below:\n[{\u0026quot;id\u0026quot;:\u0026quot;63c68794fb31c10334ab443b\u0026quot;,\u0026quot;name\u0026quot;:\u0026quot;Escalations\u0026quot;,\u0026quot;closed\u0026quot;:false,\u0026quot;idBoard\u0026quot;:\u0026quot;63c68794fb31c10334ab4434\u0026quot;,\u0026quot;pos\u0026quot;:16384,\u0026quot;subscribed\u0026quot;:false,\u0026quot;softLimit\u0026quot;:null},...]\nWhere you can see that the board contains a list named Escalations.\nCopy and save the ID for the webhook configuration.\nConfigurationWith all prerequisites met you can now configure a webhook that uses Trello\u0026rsquo;s REST API to create a card on a list.\nURL: Type the following:\nhttps://api.trello.com/1/cards?idList=\u0026lt;idList\u0026gt;\u0026amp;key=\u0026lt;apiKey\u0026gt;\u0026amp;token=\u0026lt;token\u0026gt;\nThis is the REST route for creating a card.\nName: Enter Trello Escalation Card.\nMethod: Make sure that you select the POST method.\nEditor: Type the following content on the editor and define the structure of the card you want to create:\n{ \u0026#34;name\u0026#34;: \u0026#34;Escalation: {{@alert_name}} on {{@event_labels.kube_cluster_name}}\u0026#34;, \u0026#34;desc\u0026#34;: \u0026#34;{{@event_body}}\u0026#34;, \u0026#34;pos\u0026#34;: \u0026#34;top\u0026#34; } This snippet creates a card whose name suggests that an escalation for the given alert name just triggered. It also informs you in which cluster the incident occurred by directly accessing the kube_cluster_name variable from within event_labels. Note that in order to reference this variable, the original alert that was fired needs to be grouped or filtered by this variable.\nFor the description field, provide the standard Sysdig event body, which is similar to the default message produced by an email notification channel.\n\u0026quot;pos\u0026quot;: \u0026quot;top\u0026quot; indicates that you want this new card to be created on top.\nTest the ChannelExperiment with different testing configurations to see how the resulting card appears to the recipient. Save the channel and configure an alert that triggers on it.\n","url":"https://docs.sysdig.com/en/administration/custom-webhook-trello/"},{"id":708,"title":"Windows Container Image Scanning [BETA]","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nOverviewFeatures Identify Windows container image vulnerabilities from:\nWindows OS CVEs Windows or Linux hosts\nReports in JSON and PDF\nPolicy support\nSeverity\nFix available\nDays since fixed\nUsageYou can integrate the Windows Scanning Inspector into the continuous integration and continuous delivery (CI/CD) pipeline or deploy ad hoc during development.\nCI/CD PipelineThe image below shows how the Scanning Inspector fits within a development pipeline. A policy can pass or fail the workflow and provide a PDF or JSON report for each CI/CD job.\nAd Hoc ScanningDevelopers can run the Windows Scanning Inspector anywhere Docker can be run: a machine (Mac, Windows, or Linux), virtual machine, or cloud. It provides immediate feedback on Windows OS or .NET vulnerabilities, allowing quick mitigation of known security vulnerabilities.\nInstallationPrerequisites Request a Quay secret from your Sysdig representative.\nThe beta build was developed on Windows Server 2019 (build 17763). Sysdig recommends you use this build for beta evaluation.\nConfigure Docker to support Windows containers.\nInstall Scanning Inspector Use the provided secret to authenticate with Quay:\nPULL_SECRET=\u0026#34;enter secret\u0026#34; AUTH=$(echo $PULL_SECRET | base64 --decode | jq -r \u0026#39;.auths.\u0026#34;quay.io\u0026#34;.auth\u0026#39;| base64 --decode) QUAY_USERNAME=${AUTH%:*} QUAY_PASSWORD=${AUTH#*:} docker login -u \u0026#34;$QUAY_USERNAME\u0026#34; -p \u0026#34;$QUAY_PASSWORD\u0026#34; quay.io Pull the Scanning Inspector component for Windows or Linux:\nWindow Host/Kernel: quay.io/sysdig/scanning-inspector-windows:latest Linux Host/Kernel: :quay.io/sysdig/scanning-inspector-linux:latest\nRun the --help command to see the parameters available for the Scanning Inspector.\ndocker run --rm -v $(pwd):/outdir quay.io/sysdig/scanning-inspector-linux:latest --help Parameters for Scanning InspectorThe --help command lists the available parameters and their usage. They can be divided into those related to scanning for vulnerabilities and generating a report, and those related to creating policies.\nFlag Description Required Argument Type -f string output format yes pdf or json Vuln scan -i or -image_identifier string identifier of the image yes [my_image:my_tag] Vuln scan -image_type string image type yes tar, daemon, pull Vuln scan -o string or -output string output file path yes Vuln scan -output_format string output format yes pdf or json Vuln scan -fix_available policy check for fix no Policy creation -min_days_fix int Minimum number of days once a fix for the specific vulnerability is available no default -1 Policy Creation -min_severity string Minimum severity to fail for policy evaluation no Policy creation t-string The image type yes tar, daemon, pull Use CasesScan Remote Image and Save PDF ReportIn this example, the Inspector should scan a remote image on a Linux host and save the resulting report as a PDF to ./scanResults.pdf\ndocker run --rm -v $(pwd):/outdir quay.io/sysdig/scanning-inspector-linux:latest \\ -t pull \\ # pull image from remote repo -i mcr.microsoft.com/windows/nanoserver:10.0.17763.1518 \\ # inspect container name -f pdf \\ # format -o /outdir/scanResults.pdf # output name Scan Local Image Apply Policy Conditions and Generate JSON ReportIn this example, the Inspector should:\nScan a local image on a Windows host\nMount the Docker socket to access the local image. This can be done with -v \u0026quot;//./pipe/docker_engine://./pipe/docker_engine\u0026quot; in Windows\nApply a policy to specify vulnerabilities with a minimum severity of high and a minimum number of days after the vulnerability fix is available set to 7.\nIf the scan does not pass, the container will have an exit 1 error.\nThe report is in JSON\ndocker run --rm -v $pwd/outdir:c:/outdir quay.io/sysdig/scanning-inspector-windows:latest -t pull #Pulls a public image for evaluation. Authentication credentials are not (yet) supported. -i mcr.microsoft.com/windows/nanoserver:10.0.17763.1518 # local image name -min_severity high # Any sev high or greater CVEs will fail the image scan policy -min_days_fix 7 # Only fail scan if found vulnerabilities have a fix for more than 7 days -f json # format -o outdir/scanResults.json # output name The code above should be run in Windows Powershell as $(pwd) is a Powershell expression\nTo scan images residing locally downloaded into Windows Docker (those visible via “docker image list”), the -t daemon option needs to be used. For this to work the local socket needs to be mounted with -v //./pipe/docker_engine://./pipe/docker_engine\ndocker run --rm -v $pwd/outdir:c:/outdir -v //./pipe/docker_engine://./pipe/docker_engine quay.io/sysdig/scanning-inspector-windows:latest -t daemon -i mcr.microsoft.com/windows/nanoserver:10.0.17763.1518 -min_severity high -min_days_fix 7 -f json -o outdir/scanResults.json ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/windows-container-image-scanning-beta/"},{"id":709,"title":"Group Mappings for Azure Active Directory","content":" Log in to the Microsoft Entra ID portal.\nSelect Microsoft Entra ID, then click Enterprise Applications.\nSelect the Sysdig application to which you want to add or modify group information.\nOn the menu, select Single sign-on.\nClick Attributes \u0026amp; Claims.\nSelect Add a group claim from the top menu if you are adding group information for the first time, otherwise select the correct attribute from the Additional claims list.\nSpecify the following:\nWhich groups associated with the user should be returned in the claim?: You must select which groups should be returned for each user that logs in. Source attribute: This attribute can be configured only for groups synchronized from an on-premises Active Directory using Microsoft Entra ID Connect Sync 1.2.70.0 or above. The default is Group ID. Expand Advanced Options: Select Customize the name of the group claim Enter Name: The value must match configured Group Attribute Name, for example, \u0026ldquo;groups\u0026rdquo;. Group Claim Name\nIf you don\u0026rsquo;t customize the Group Claim name, Azure will default to http://schemas.microsoft.com/ws/2008/06/identity/claims/groups and this value must be entered as the Group Attribute Name on the Sysdig side. Save your settings. Learn More“To learn more about the available Group Claim settings, see Add group claims to tokens for SAML applications using SSO configuration.\n","url":"https://docs.sysdig.com/en/administration/group-mappings-azure_saml/"},{"id":710,"title":"Configuration and Troubleshooting","content":"Kubernetes Network ConfigurationTo access the Configuration page:\nLog in to Sysdig Secure and select Inventory \u0026gt; Network.\nSelect a cluster and namespace to display the Network page.\nClick Configuration in the top right corner to display the Configuration page.\nIt contains:\nWorkload labels Unresolved IPs Cluster CIDR configurations Workload LabelsThe Sysdig agent automatically detects labels used for the Kubernetes objects in a cluster. Sometimes, there are many more labels than are required for network security purposes. In such cases, you can select the two or three most meaningful labels and use include or exclude namespace or workload labels to avoid clutter in both the UI and your network security policies. For example you can exclude labels inherited by helm, and only include the labels that are required for each object (such as app and name).\nUnresolved IP ConfigurationIf the Sysdig agent cannot resolve an IP to a higher-level structure (such as Service, Deployment, Daemonset) it will be displayed as \u0026ldquo;unresolved\u0026rdquo; in the ingress/egress tables. You can also add unresolved IPs from the ingress or egress tabs by clicking the @ and creating a new alias or assigning it to an existing alias You can manually enter such IPs or CIDRs in the configuration panel, label them with an alias, and optionally set them to \u0026ldquo;allowed\u0026rdquo; status. Note that grouping IPs under a single alias helps declutter the Topography view.\nThe following figure shows pod communication without an alias: The following figure shows pod communication with IP aliases: Cluster CIDR ConfigurationUnresolved IP addresses are listed and categorized as \u0026ldquo;internal\u0026rdquo; (inside the cluster), \u0026ldquo;external\u0026rdquo; (outside the cluster) or \u0026ldquo;unknown,\u0026rdquo; (subnet information incomplete). For unknowns, Sysdig prompts you with an error message to help you resolve it.\nThe simplest resolution is to manually specify cluster and service CIDRs for the clusters.\nTroubleshootingTips to resolve common error messages:\nError message: Namespaces without labelsProblem: Namespaces must be labeled for the Kubernetes Network Policies (KNPs) to define ingress/egress rules. If non-labeled namespaces are detected in the targeted communications, the Ui displays the \u0026ldquo;Namespaces without labels\u0026rdquo; error message.\nResolution: Simply assign a label to the relevant namespace and wait a few minutes for the system\u0026rsquo;s auto-detection to catch up.\nError Message: Cluster subnet is incompleteIssue To categorize unresolved IPs as inside or outside the cluster, the agent must know which CIDR ranges belong to the cluster. By default, the agent tries to discover the ranges by examining the command line arguments of the kube-apiserver and kube-controller-manager processes.\nIf it cannot auto-discover the cluster subnets, the UI displays the \u0026ldquo;cluster subnet is incomplete\u0026rdquo; error message.\nResolution:\nPreferred: Use the Configuration panel to add the CIDR entries.\nIn rare cases, you may need to configure the agent to look for the CIDR ranges in other processes than the default kube-apiserver, kube-controller-manager processes. In this case, append the following to the agent configmap:\nnetwork_topology: pod_prefix_for_cidr_retrieval: [\u0026lt;PROCESS_NAME\u0026gt;, \u0026lt;PROCESS_NAME\u0026gt;] ","url":"https://docs.sysdig.com/en/sysdig-secure/network-configuration/"},{"id":711,"title":"Cost","content":"sysdig_costs_cloud_account_private_billing_info Prometheus ID sysdig_costs_cloud_account_private_billing_info Legacy ID sysdig.cost.sysdig_costs_cloud_account_private_billing_info Metric Type gauge Unit number Description Info metric containing labels for the private billing account. Additional Notes sysdig_costs_cluster_details_info Prometheus ID sysdig_costs_cluster_details_info Legacy ID sysdig.cost.sysdig_costs_cluster_details_info Metric Type gauge Unit number Description Info metric containing labels describing the cluster and its cloud provider. Additional Notes sysdig_costs_cluster_management_fees_cost_total Prometheus ID sysdig_costs_cluster_management_fees_cost_total Legacy ID sysdig.cost.sysdig_costs_cluster_management_fees_cost_total Metric Type counter Unit number Description The total cost associated with the management fee for each cluster. This metric is reported on an hourly basis. Additional Notes sysdig_costs_node_cost_total Prometheus ID sysdig_costs_node_cost_total Legacy ID sysdig.cost.sysdig_costs_node_cost_total Metric Type counter Unit number Description The total cost incurred by the node. This metric is reported on an hourly basis. Additional Notes sysdig_costs_node_cpu_capacity_cost_total Prometheus ID sysdig_costs_node_cpu_capacity_cost_total Legacy ID sysdig.cost.sysdig_costs_node_cpu_capacity_cost_total Metric Type counter Unit number Description The total cost per CPU on the node. This metric is reported on an hourly basis. Additional Notes sysdig_costs_node_gpu_capacity_cost_total Prometheus ID sysdig_costs_node_gpu_capacity_cost_total Legacy ID sysdig.cost.sysdig_costs_node_gpu_capacity_cost_total Metric Type counter Unit number Description The total cost per GPU on the node. This metric is reported on an hourly basis. Additional Notes sysdig_costs_node_memory_capacity_cost_total Prometheus ID sysdig_costs_node_memory_capacity_cost_total Legacy ID sysdig.cost.sysdig_costs_node_memory_capacity_cost_total Metric Type counter Unit number Description The total cost per GiB of RAM memory on the node. This metric is reported on an hourly basis. Additional Notes sysdig_costs_service_load_balancer_cost_total Prometheus ID sysdig_costs_service_load_balancer_cost_total Legacy ID sysdig.cost.sysdig_costs_service_load_balancer_cost_total Metric Type counter Unit number Description The cost incurred by the load balancer. This metric is reported on an hourly basis. Additional Notes sysdig_costs_pv_cost_total Prometheus ID sysdig_costs_pv_cost_total Legacy ID sysdig.cost.sysdig_costs_pv_cost_total Metric Type counter Unit number Description The total cost of a PV. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_cpu_allocated_cores_total Prometheus ID sysdig_costs_workload_cpu_allocated_cores_total Legacy ID sysdig.cost.sysdig_costs_workload_cpu_allocated_cores_total Metric Type counter Unit number Description The total number of CPU cores allocated to the workload, calculated hourly. It is determined by taking the greater value between the number of cores requested and the number of cores actually utilized. Additional Notes sysdig_costs_workload_cpu_allocated_cost_total Prometheus ID sysdig_costs_workload_cpu_allocated_cost_total Legacy ID sysdig.cost.sysdig_costs_workload_cpu_allocated_cost_total Metric Type counter Unit number Description The cost associated with the CPU cores allocated to the workload. Allocation is calculated as a higher value between the cores requested and cores utilized, and it is represented via metric sysdig_costs_workload_cpu_allocated_cores_total. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_cpu_used_cores_total Prometheus ID sysdig_costs_workload_cpu_used_cores_total Legacy ID sysdig.cost.sysdig_costs_workload_cpu_used_cores_total Metric Type counter Unit number Description The number of CPU cores used by the workload. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_cpu_used_cost_total Prometheus ID sysdig_costs_workload_cpu_used_cost_total Legacy ID sysdig.cost.sysdig_costs_workload_cpu_used_cost_total Metric Type counter Unit number Description The cost incurred by the number of CPU cores used by the workload. We use the average to calculate the utilization, which is represented via metric sysdig_costs_workload_cpu_used_cores_total. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_gpu_allocated_cores_total Prometheus ID sysdig_costs_workload_gpu_allocated_cores_total Legacy ID sysdig.cost.sysdig_costs_workload_gpu_allocated_cores_total Metric Type counter Unit number Description The total number of GPU cores allocated to the workload, calculated hourly. It is determined by taking the number of cores requested. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_gpu_allocated_cost_total Prometheus ID sysdig_costs_workload_gpu_allocated_cost_total Legacy ID sysdig.cost.sysdig_costs_workload_gpu_allocated_cost_total Metric Type counter Unit number Description The cost associated with the GPU cores allocated to the workload. Allocation is calculated by taking the number of cores requested. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_gpu_used_cores_total Prometheus ID sysdig_costs_workload_gpu_used_cores_total Legacy ID sysdig.cost.sysdig_costs_workload_gpu_used_cores_total Metric Type counter Unit number Description The number of GPU cores used by the workload. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_gpu_used_cost_total Prometheus ID sysdig_costs_workload_gpu_used_cost_total Legacy ID sysdig.cost.sysdig_costs_workload_gpu_used_cost_total Metric Type counter Unit number Description The cost incurred by the number of GPU cores used by the workload. We use the average to calculate the utilization, which is represented via metric sysdig_costs_workload_gpu_used_cores_total. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_memory_allocated_bytes_total Prometheus ID sysdig_costs_workload_memory_allocated_bytes_total Legacy ID sysdig.cost.sysdig_costs_workload_memory_allocated_bytes_total Metric Type counter Unit number Description The total amount of RAM allocated to the workload, calculated hourly. It is determined by taking the greater value between the amount of RAM requested and the amount of RAM actually utilized. Additional Notes sysdig_costs_workload_memory_allocated_cost_total Prometheus ID sysdig_costs_workload_memory_allocated_cost_total Legacy ID sysdig.cost.sysdig_costs_workload_memory_allocated_cost_total Metric Type counter Unit number Description The cost of RAM memory allocated to the workload. The allocation is calculated as the maximum value between the amount of RAM memory requested and utilized, and it is represented via metric sysdig_costs_workload_memory_allocated_bytes_total. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_memory_used_bytes_total Prometheus ID sysdig_costs_workload_memory_used_bytes_total Legacy ID sysdig.cost.sysdig_costs_workload_memory_used_bytes_total Metric Type counter Unit number Description The amount of RAM memory used by the workload. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_memory_used_cost_total Prometheus ID sysdig_costs_workload_memory_used_cost_total Legacy ID sysdig.cost.sysdig_costs_workload_memory_used_cost_total Metric Type counter Unit number Description The cost incurred by the amount of RAM memory utilized by the workload. We use the average to calculate the utilization, which is represented via metric sysdig_costs_workload_memory_used_bytes_total. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_storage_used_cost_total Prometheus ID sysdig_costs_workload_storage_used_cost_total Legacy ID sysdig.cost.sysdig_costs_workload_storage_used_cost_total Metric Type counter Unit number Description The cost incurred by the amount of storage utilized by each workload from a PVC. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_storage_allocated_bytes_total Prometheus ID sysdig_costs_workload_storage_allocated_bytes_total Legacy ID sysdig.cost.sysdig_costs_workload_storage_allocated_bytes_total Metric Type counter Unit number Description The amount of storage claimed by each workload from a PVC. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_storage_allocated_cost_total Prometheus ID sysdig_costs_workload_storage_allocated_cost_total Legacy ID sysdig.cost.sysdig_costs_workload_storage_allocated_cost_total Metric Type counter Unit number Description The cost associated with the amount of storage claimed by each workload from a PVC. The claimed storage is represented via metric sysdig_costs_workload_storage_allocated_bytes_total. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_storage_capacity_bytes_total Prometheus ID sysdig_costs_workload_storage_capacity_bytes_total Legacy ID sysdig.cost.sysdig_costs_workload_storage_capacity_bytes_total Metric Type counter Unit number Description The capacity of the PV that the PVC is utilizing, measured in bytes. This metric is reported on an hourly basis. Additional Notes sysdig_costs_workload_storage_capacity_cost_total Prometheus ID sysdig_costs_workload_storage_capacity_cost_total Legacy ID sysdig.cost.sysdig_costs_workload_storage_capacity_cost_total Metric Type counter Unit number Description The cost associated with the capacity of the PV that a PVC is utilizing. The storage capacity is represented via metric sysdig_costs_workload_storage_capacity_bytes_total This metric is reported on an hourly basis. Additional Notes ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics/metricslibrary/cost/"},{"id":712,"title":"Deprecation Policy: Shield, CLI Scanner, and Registry Scanner","content":"Feature Deprecation PolicyWhen a feature in Sysdig Shield, Sysdig CLI Scanner, or Registry Scanner is scheduled for deprecation, Sysdig provides 12 months advance notice before the feature is removed. This notice period is intended to give you sufficient time to evaluate, plan, and transition to recommended alternatives, when available.\nSysdig communicates deprecation notices through:\nOfficial documentation, such as the Release Notes. The Sysdig UI Support notifications Direct communication, such as email, for high-impact changes Once a feature reaches its end-of-support date, it will be removed. We strongly encourage you to migrate to supported alternatives before the deprecation period ends.\nPre-Deprecation PhaseThe pre-deprecation phase is a period of 12 months from the date of the deprecation notice. During this period, prepare to migrate away from the version of the application to be deprecated. During this period, Sysdig ensures provides:\nStandard support (bug fixes, security patches) for deprecated components. No new features or enhancements for the deprecated feature. Future enhancements focus on the replacement. Updated documentation with deprecation warnings and migration guidance. Post-Deprecation PhaseIn the three months after a version of Sysdig Shield is deprecated, Sysdig provides:\nAccess to Shield, Sysdig CLI Scanner and Registry Scanner images via Docker repositories. Access to CLI Scanner binaries. The associated Helm chart is removed from active registries but remains archived. All remaining documentation, including migration guides and scripts, is removed by the end of this 3-month period. ","url":"https://docs.sysdig.com/en/deprecation-shield/"},{"id":713,"title":"Sysdig Documentation Hub","content":"","url":"https://docs.sysdig.com/en/docs/"},{"id":714,"title":"Email Notifications","content":"SupportEmail notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts Silence Rule Notifications Cost Advisor Reports Email notification channels are supported for the following use cases in Sysdig Secure:\nRuntime Policies Reporting Risks Threats Vulnerabilities Accepted Risk: Vulnerabilities Create an Email Notification Channel Log in to Sysdig Monitor or Sysdig Secure as an Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channel \u0026gt; Email.\nEnter the relevant details for the email notification:\nFrom Shared With: Choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nClick Save.\nIf you enabled Test notification, a test email will be sent.\nTo use email notifications, you can now configure an alert.\nFor on-premises environments, you may need to have pre-configured your SMTP parameters in your Kubernetes installation configmap.\n","url":"https://docs.sysdig.com/en/administration/email-notifications/"},{"id":715,"title":"Export Events","content":"OverviewSysdig Monitor allows you to export the events currently displayed in the Events feed as a CSV file. The export respects all active filters, scope, severity selections, and the selected time range, so what you see in the feed is what gets exported.\nTo access the export options, select Export in the top-right corner of the Events page. Two options are available:\nExport CSV: Generate and download a CSV file of the current event feed. Export History: View a list of previously generated exports. Export CSVEvent LimitExport CSV is limited to 25,000 events. If the current event count exceeds this limit, the Export CSV option is disabled and a warning tooltip is shown.\nTo enable the export, reduce the number of matching events by applying additional filters or narrowing the time range. See Filter and Search Events for guidance.\nConfigure the ExportWhen the event count is within the limit, select Export CSV to open the export configuration dialog.\nName\nThe export file name is auto-generated using a timestamp (for example, Sysdig_Events_2026-04-03T14:11:28.019Z). You can edit this field to give the file a meaningful name before downloading.\nExport Fields\nThe Export Fields section controls which event attributes are included as columns in the CSV. Each row in the table maps an event attribute (Value) to a column header name (Field Name) in the output file.\nColumn Description Value The event attribute to export. Select from the dropdown, which groups available fields into three categories (see below). Field Name The column header label used in the CSV file. Defaults to the attribute name, but can be customized. To add a column, use the Select Value\u0026hellip; row at the bottom of the table and choose an attribute. To remove a column, select the trash icon on the corresponding row.\nAvailable Field ValuesThe Value dropdown groups available attributes into three categories:\nCommon Event Fields (8)\nThese core event attributes are available for all event types:\nId Version Name Description Severity Timestamp Type Source Alert Event Fields\nThese fields are specific to Alert Events and are only populated when the event originates from an alert rule:\nAlert Id Alert State Alert Acknowledgment Notification Title Resolution Timestamp Event Specific Labels\nLabels that apply specifically to events and are used for event-level categorization:\nalertname sysdig_severity Suggested Labels\nScope labels commonly used to identify the infrastructure context of an event, including:\ncloud_provider_region container_name host_hostname kube_cluster_name kube_cronjob_name kube_daemonset_name kube_deployment_name kube_hpa_name kube_job_name kube_statefulset_name kube_storageclass_name kube_workload_name kube_workload_type All Labels\nThe full set of available labels, including environment-specific and custom labels such as Hostname, UUID, _sysdig_custom_metric, and _sysdig_datasource.\nDownload the FileOnce you have configured the name and fields, select Export to generate and download the CSV file.\nExport HistorySelect Export History to open a dialog listing previously generated CSV exports. Each entry can be downloaded again without re-generating the export.\nIf no exports have been generated yet, the dialog displays: No reports are currently available.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/export-events/"},{"id":716,"title":"Feature Management","content":"The Sysdig Serverless Workload Agent supports optional features that are disabled by default. You can enable and configure them through the SYSDIG_EXTRA_CONF environment variable under the relevant heading.\nFor more information, see:\nMalware Detection ","url":"https://docs.sysdig.com/en/sysdig-secure/serverless-feature-management/"},{"id":717,"title":"FIM Policy","content":"Prerequisites Sysdig Secure Universal eBPF probe enabled. See more in the dedicated page. Agent 14.3+ Configure the Sysdig ShieldTo enable the feature, you need to customize enable in your Sysdig Shield setup, setting features.detections.file_integrity_monitoring=true. For additional installation instructions, see:\nInstall Shield on Linux Nodes Install Shield as a Container Install Shield as Package Create a FIM Policy Log in to Sysdig Secure.\nSelect Policies \u0026gt; Runtime Policies to display the Runtime Policies page.\nClick +Add Policy and select FIM policy type.\nConfigure the policy as given in Configure a FIM Policy.\nClick Save.\nConfigure a FIM PolicyBasic ParametersName: Enter a unique policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled: Toggle to enable or disable the policy. The policy must be enabled to generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI.\nThe available severities are High, Medium, Low, or Info.\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Choose the scope to which the policy will apply. You can select Hosts Only, Containers Only, or define a Custom Scope.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you provide a value here, a View Runbook option will appear in the corresponding event with a link to your Runbook.\nPolicy RulesTurn on one or both rules, to detect different operations performed on files:\nModification: Triggers when a file content is modified. This doesn\u0026rsquo;t trigger upon file creation.\nDeletion: Triggers when a file is removed.\nRules ConfigurationUse Regex: If this is enabled, you can use Google RE2-compatible regular expressions when specifying the monitored and excluded directory paths. This will significantly increase the usage of CPU.\nMonitored Directories: A comma-separated list of folders to be monitored for changes. The files existing in these folders at policy loading will trigger detections. For symlinks, the actual path is to be considered here. The longer the list, the higher the amount of resources used.\nExcluded Directories: A comma-separated list of folders to be excluded from monitoring. These are absolute paths of subfolders of any of the list above.\nActionsNotifySelect a notification channel from the drop-down list for sending notification of events to appropriate personnel.\nEvent notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\n","url":"https://docs.sysdig.com/en/sysdig-secure/fim-policy/"},{"id":718,"title":"Forwarding to IBM QRadar","content":"PrerequisitesEvent forwards originate from region-specific IPs. For the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle event forwarding.\nConfigure Standard IntegrationTo forward event data to IBM QRadar:\nLog in to Sysdig Secure as Admin and go to Integrations \u0026gt; Add Integrations.\nSearch and choose IBM QRadar.\nAlthough QRadar receives Syslog messages, it uses LEEF format. Using Syslog as the source type will potentially generate incompatible messages with IBM QRadar.\nConfigure the required options:\nIntegration Name: Define an integration name.\nAddress: Specify the DNS address of the QRadar installation endpoint.\nPort: TCP Port to send data. 514 is the default\nData to Send: Select from the drop-down the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled.\nAllow insecure connections: Toggle on if you want to allow insecure connections (i.e. invalid or self-signed certificate on the receiving side).\nToggle the enable switch as necessary. Remember that you will need to \u0026ldquo;Test Integration\u0026rdquo; with the button below before enabling the integration.\nClick Save.\nConfigure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description QRADAR address yes string DNS name or IP of the QRadar instance QRADAR port yes int Port exposed to receive Syslog events. 6514 or 514 by default. QRADAR insecure no bool false Doesn’t verify TLS certificate QRADAR tls no bool false Learn MoreSee IBM Documentation for information on log sources.\n","url":"https://docs.sysdig.com/en/sysdig-secure/event-forward-to-ibm-qradar/"},{"id":719,"title":"Global Service Accounts","content":"PrerequisitesTo create, manage, and delete global service accounts, you must:\nLog in as an Admin user (ROLE-ADMIN).\nRetrieve the Sysdig API Token from the Sysdig UI to use with the API.\nManage Global Service AccountsAdmins can create or delete a global service account by performing an API call. For instructions, access the Next Gen API documentation and go to the Service Accounts section.\nHere, you can find API calls to:\nRetrieve a list of all service accounts. Create a new global service account. Delete a global service account. When you create a global service account, select one of Sysdig\u0026rsquo;s pre-configured roles from the list of Available Global Service Accounts Roles.\nAvailable Global Service Accounts RolesA number of preset global service accounts exist, each with its own set of unique permissions. They include the following:\nRuntime InsightsROLE_RUNTIME_INSIGHTS allows risk spotlight integration. The role contains these permissions:\nsecure.risk-spotlight-integrations.read Cloud Ingestion - OktaROLE_CLOUDINGESTION_OKTA allows cloud ingestion from Okta. The role contains these permissions:\ncloudingestion-okta-ingest.write Cloud Ingestion - GitHubROLE_CLOUDINGESTION_GITHUB allows cloud ingestion from GitHub. The role contains these permissions:\ncloudingestion-github-ingest.write Cloud Ingestion - GCPROLE_CLOUDINGESTION_GCP allows cloud ingestion from GCP. The role contains these permissions:\ncloudingestion-gcp-ingest.write Prometheus Remote WriteROLE_PROM_REMOTE_WRITE allows ingestion of Prometheus remote write metrics. The role contains these permissions:\ningest.prws Access KeysROLE_MANAGE_ACCESS_KEYS allows you to manage access keys. The role contains these permissions:\naccess-keys.read access-keys.edit Custom RolesROLE_MANAGE_CUSTOM_ROLES allows you to manage custom team roles. The role contains these permissions:\npermissions.read custom-team-roles.read custom-team-roles.create custom-team-roles.update custom-team-roles.delete Group MappingsROLE_MANAGE_GROUP_MAPPINGS allows you to manage group mappings. The role contains these permissions:\npermissions.read custom-team-roles.read custom-team-roles.create custom-team-roles.update custom-team-roles.delete Single Sign On SettingsROLE_MANAGE_SSO_SETTINGS allows you to manage single sign on settings. The role contains these permissions:\nsso-active.edit sso.config User ProvisioningROLE_USER_PROVISONING allows you to manage users and teams. The role contains these permissions:\ncustomer-teams.read teams.create teams.edit teams.delete memberships.read memberships.edit memberships-roles.edit users.create users.read users.edit group-mappings.read group-mappings.edit User and Zone ProvisioningROLE_USER_ZONE_PROVISIONING allows you to manage users, teams, and zones. The role contains these permissions:\ncustomer-teams.read teams.create teams.edit teams.delete memberships.read memberships.edit memberships-roles.edit users.create users.read users.edit group-mappings.read group-mappings.edit zones.read zones.edit Team Service Accounts managementROLE_MANAGE_TEAM_SERVICE_ACCOUNTS allows you to manage team service accounts. The role contains these permissions:\nservice-accounts.read service-accounts.create service-account-role.edit service-account-notification-settings.edit Platform AuditROLE_PLATFORM_AUDIT_READ allows you to read platform audit logs. The role contains these permissions:\naudit-trail-events.read ","url":"https://docs.sysdig.com/en/developer-tools/global-service-accounts/"},{"id":720,"title":"Integrate Node.js Application Metrics","content":"The example below shows a node.js application that exports metrics using the Prometheus protocol:\n{ \u0026#34;name\u0026#34;: \u0026#34;node-example\u0026#34;, \u0026#34;version\u0026#34;: \u0026#34;1.0.0\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;Node example exporting metrics via Prometheus\u0026#34;, \u0026#34;main\u0026#34;: \u0026#34;index.js\u0026#34;, \u0026#34;scripts\u0026#34;: { \u0026#34;test\u0026#34;: \u0026#34;echo \\\u0026#34;Error: no test specified\\\u0026#34; \u0026amp;\u0026amp; exit 1\u0026#34; }, \u0026#34;license\u0026#34;: \u0026#34;BSD-2-Clause\u0026#34;, \u0026#34;dependencies\u0026#34;: { \u0026#34;express\u0026#34;: \u0026#34;^4.14.0\u0026#34;, \u0026#34;gc-stats\u0026#34;: \u0026#34;^1.0.0\u0026#34;, \u0026#34;prom-client\u0026#34;: \u0026#34;^6.3.0\u0026#34;, \u0026#34;prometheus-gc-stats\u0026#34;: \u0026#34;^0.3.1\u0026#34; } } The index.js library function is shown below:\n// Use express as HTTP middleware // Feel free to use your own var express = require(\u0026#39;express\u0026#39;) var app = express() // Initialize Prometheus exporter const prom = require(\u0026#39;prom-client\u0026#39;) const prom_gc = require(\u0026#39;prometheus-gc-stats\u0026#39;) prom_gc() // Sample HTTP route app.get(\u0026#39;/\u0026#39;, function (req, res) { res.send(\u0026#39;Hello World!\u0026#39;) }) // Export Prometheus metrics from /metrics endpoint app.get(\u0026#39;/metrics\u0026#39;, function(req, res) { res.end(prom.register.metrics()); }); app.listen(3000, function () { console.log(\u0026#39;Example app listening on port 3000!\u0026#39;) }) Integrate a Node.js ApplicationTo integrate a Node.js application:\nAdd an appcheck in the dockerfile:\nFROM node:latest WORKDIR /app ADD package.json ./ RUN npm install ENV SYSDIG_AGENT_CONF \u0026#39;app_checks: [{name: node, check_module: prometheus, pattern: {comm: node}, conf: { url: \u0026#34;http://localhost:{port}/metrics\u0026#34; }}]\u0026#39; ADD index.js ./ ENTRYPOINT [ \u0026#34;node\u0026#34;, \u0026#34;index.js\u0026#34; ] Run the application:\nuser@host:~$ docker build -t node-example user@host:~$ docker run -d node-example Once the Sysdig agent is deployed, Node.js metrics will be automatically retrieved. The image below shows an example of key Node.js metrics visible on the Sysdig Monitor UI:\nFor code and configuration examples, refer to the GitHub repository.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/custom-integrations/integrate-node.js-application-metrics/"},{"id":721,"title":"Jenkins","content":"This page describes the default configuration settings, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nJenkins SetupRequires the standard Jenkins server setup with one or more Jenkins Jobs running on it.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with Jenkins and collect basic metrics.\n- name: jenkins pattern: comm: java port: 50000 conf: name: default jenkins_home: /var/lib/jenkins #this depends on your environment Jenkins Folders PluginBy default, the Sysdig agent does not monitor jobs under job folders created using Folders plugin.\nSet jobs_folder_depth to monitor these jobs. Job folders are scanned recursively for jobs until the designated folder depth is reached. The default value = 1.\napp_checks: - name: jenkins pattern: comm: java port: 50000 conf: name: default jenkins_home: /var/lib/jenkins jobs_folder_depth: 3 Metrics AvailableThe following metrics will be available only after running one or more Jenkins jobs. They handle queue size, job duration, and job waiting time.\nSee Jenkins Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/jenkins/"},{"id":722,"title":"Jenkins Metrics","content":"See Application Integrations for more information.\njenkins.job.durationThe duration of a job, measured in seconds.\njenkins.job.successThe status of a successful job.\njenkins.job.failureThe status of a failed job.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/jenkins-metrics/"},{"id":723,"title":"Malware Control Policy","content":"Prerequisites Sysdig Secure For hosts and kubernetes: Kernel 5.x+ Agent 13.0.1+ Agent version 13.6.0 is required to use Regex. For ECS Fargate: Serverless Agent 6.2.0+ Configure the Sysdig Agent for Kubernetes and HostMalware Control, also called Malware Detection and Prevention, is enabled by default.\nYou can optionally configure the dragent.yaml file to:\nDisable Malware Control globally. Enable Malware Control for the underlying host node. For agent configuration options, see Configure Malware Control.\nConfigure the Serverless agent for ECS FargateMalware Detection is disabled by default in Serverless Container. See the dedicated documentation to learn how this can enabled.\nCreate a Malware Policy Log in to Sysdig Secure.\nSelect Policies \u0026gt; Runtime Policies to display the Runtime Policies page.\nClick +Add Policy and select Malware policy type.\nConfigure the policy as given in Configure a Malware Policy.\nClick Save.\nConfigure a Malware PolicyBasic Parameters Name: Enter a unique policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled: Toggle to enable or disable the policy. The policy must be enabled to generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI.\nThe available severities are High, Medium, Low, or Info.\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Choose the scope to which the policy will apply. You can select Hosts Only, Containers Only, or define a Custom Scope.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you provide a value here, a View Runbook option will appear in the corresponding event with a link to your Runbook.\nDetectMalware detection coverage map:\nPlatform Malware Detection Kubernetes - Linux ✅ Kubernetes - Windows ❌ Hosts - Linux Containers ✅ Hosts - Linux Packages ✅ Hosts - Windows ❌ Hosts - ECS on EC2 ❌ Serverless - Azure Container Apps ❌ Serverless - Cloud Run Service ❌ Serverless - ECS on Fargate ✅ Additional hashes: (Optional) Enter hashes of binaries in a SHA-256 format to have them evaluated by the policy. Comma-separate your entries.\nUse known hashes: Sysdig maintains a list of known hashes which it checks against the executing binary. This option is enabled by default.\nUse YARA rules: Toggle to enable or disable detection with YARA rules provided by Sysdig\u0026rsquo;s Threat Research Teams. YARA rules help to classify and identify malware samples by creating descriptions of malware families based on textual or binary patterns. Some malware add random bytes to the generated binary to generate unique hashes. This allows them to bypass detection based on hash-matching. YARA rules can detect such malware by inspecting the binary for known sequence of bytes. Detection with YARA rules is enabled by default.\nExceptionsHash exceptions: (Optional) Enter hashes in a SHA-256 format for which you do not want the policy to trigger an event. Comma-separate your entries.\nFile Based ExceptionsThe File Based Exceptions feature allows you to exclude specific files or file paths from malware scanning, helping reduce false positives and optimize scanning performance.\nUse Regex for exceptions: Toggle to enable or disable pattern matching using regular expressions. When disabled, the system uses exact string matching for file paths.\nRegex allows you to create patterns for matching file names or process paths. For example, .*\\.log$ matches any file ending with “.log”. You can use regex to identify drifted files or processes that should be allowed or blocked by matching their names or paths the the regex pattern defined. To learn more about regex syntax, see Regular Expression Syntax. Agent version 13.6.0 or above is required for this feature. Exceptions: Enter complete file paths that should be excluded from malware scanning. For example: /usr/bin/test, /usr/local/scan, /opt/trusted/*. Multiple paths can be specified using comma separation.\nBest practices include:\nUse specific paths rather than broad patterns to maintain security. Document all exceptions for audit purposes. Regularly review excluded paths to ensure they remain necessary. ActionsPreventEnable the toggle to have Sysdig Secure prevent the execution of detected binaries. This option is disabled by default. When Prevent is disabled, malware detection triggers an event at any configured notifications.\nContainersContainer policy actions coverage map:\nEnvironment Container Policy Action Supported? Kubernetes - Linux ✅ Kubernetes - Windows ❌ Hosts - Linux Containers ✅ Hosts - Linux Packages ✅ Hosts - Windows ❌ Hosts - ECS on EC2 ❌ Serverless - Azure Container Apps ❌ Serverless - Cloud Run Service ❌ Serverless - ECS on Fargate ❌ Choose which action the policy should take when the event occurs in a container. Options include:\nNo container action: Do not change container behavior; send a notification according to notification channel settings. Kill: Kills one or more running containers immediately. Stop: Allows a graceful shutdown (10-seconds) before killing the container. Pause: Suspends all processes in the specified containers. For details, see Available Response Actions.\nCapturesCreate a capture when the policy triggers.\nNotifySelect a notification channel from the drop-down list for sending notification of events to appropriate personnel.\nEvent notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\n","url":"https://docs.sysdig.com/en/sysdig-secure/malware_policy/"},{"id":724,"title":"Marathon Metrics","content":"See Application Integrations for more information.\nmarathon.appsThe total number of applications.\nmarathon.backoffFactorThe multiplication factor for the delay between each consecutive failed task. This value is multiplied by the value of marathon.backoffSeconds each time the task fails until the maximum delay is reached, or the task succeeds.\nmarathon.backoffSecondsThe period of time between attempts to run a failed task. This value is multiplied by marathon.backoffFactor for each consecutive task failure, until either the task succeeds or the maximum delay is reached.\nmarathon.cpusThe number of CPUs configured for each application instance.\nmarathon.diskThe amount of disk space configured for each application instance.\nmarathon.instancesThe number of instances of a specific application.\nmarathon.memThe total amount of configured memory for each instance of a specific application.\nmarathon.tasksRunningThe number of tasks running for a specific application.\nmarathon.tasksStagedThe number of tasks staged for a specific application.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/marathon-metrics/"},{"id":725,"title":"PromQL Query","content":"To access the PromQL Query Explorer:\nLog in to Sysdig Monitor.\nSelect Explore \u0026gt; PromQL Query.\nThe PromQL Query Explorer appears.\nQuery with PromQLTo query with PromQL in the PromQL Query Explorer:\nManually build PromQL queries in the PromQL field. They can be as simple or as complex as you like.\nAlternatively, to use a template, navigate to PromQL Library and select Try me on an out-of-the-box query.\nAfter you populate the field with a query, select Run Query.\nOptionally, select Create to build a dashboards or create alerts based on the query.\nYou can run up to five queries simultaneously in the PromQL Query Explorer.\nExplore metrics and labels available in your infrastructureFor example, calculate the number of bytes received in a selected host:\nsysdig_host_net_total_bytes{host_mac=\u0026#34;0a:e2:e8:b4:6c:1a\u0026#34;} Calculate the number of bytes received in all the hosts except one:\nsysdig_host_net_total_bytes{host_mac!=\u0026#34;0a:a3:4b:3e:db:a2\u0026#34;} Compare current data with historical data:\nsysdig_host_net_total_bytes offset 7d Use arithmetic operators to perform calculations on one or more metrics or labelsFor example, calculate the rate of incoming bytes and convert it to bits:\nrate(sysdig_host_net_total_bytes[5m]) * 8 Build complex PromQL queriesFor example, return summary ingress traffic across all the network interfaces grouped by instances\nsum(rate(sysdig_host_net_total_bytes[5m])) by (container_id) Label Filtering Steps Preview Label filtering to automatically identify common labels between queries for vector matching. In the given example, you can see that A and B queries have 8 labels in common as highlighted in the [A∩B] section. Filter by using the relational operators available in the time series table. Simply click the operator for it to be automatically applied to the queries. Run the queries again to visualize the metrics. Explore labels, view documentation, and perform filtering by using rational operators from the label selector. Toggle Query Results Steps Preview Click the respective query buttons, for example, A or B, to show or hide query results. Learn MoreTo take the exploration further, you can:\nCreate an Alert that enables you to craft a Prometheus Alert based on one of the selected queries. Create Dashboard Panel which lets you add the selected metrics to a new dashboard panel. ","url":"https://docs.sysdig.com/en/sysdig-monitor/using-promql-query/"},{"id":726,"title":"Integrate with ServiceNow","content":"Sysdig CVR Plugin for ServiceNowThis integration is done using the Sysdig Container Vulnerability Response (CVR) plugin for ServiceNow, which is provided free of charge by Sysdig and available in the ServiceNow store.\nPrerequisites Sysdig SaaS account\nServiceNow instance with both VR and CVR modules installed\nInstall and Configure the IntegrationOn the ServiceNow Integrations marketplace, find the Sysdig Container Vulnerability Response Integration.\nThe downloadable Install Guide there describes:\nPrerequisites\nObtaining the integration\nPermissions and role creation in ServiceNow\nConfiguration use cases and profiles\nViewing results in the ServiceNow interface\nTroubleshooting\n","url":"https://docs.sysdig.com/en/sysdig-secure/servicenow-integration/"},{"id":727,"title":"Sysdig Sage for Search","content":"By leveraging natural language processing (NLP) and SysQL query translation, Sysdig Sage lets you retrieve security insights, inventory data, and compliance findings without needing deep technical knowledge of query languages or cloud security frameworks.\nWith Sysdig Sage for Search, you can:\nSearch cloud inventory across AWS, GCP, and Azure for resources like EC2 instances, Kubernetes workloads, IAM roles, and S3 buckets. Identify security posture findings including failed controls, vulnerabilities, and compliance violations. Ask questions in natural language while the AI generates SysQL queries automatically Get contextual insights of query results to simplify investigation and troubleshooting. Key FeaturesSysdig Sage for Search combines two integrated capabilities:\n1. Sysdig Sage for Search (SysQL Translation)Automatically converts natural language questions into structured SysQL queries. This makes the Sysdig inventory more accessible to users with varying levels of expertise.\nKey capabilities: Translates questions like Show my EC2 instances into executable SysQL. Supports graph-based queries to analyze relationships between cloud and Kubernetes resources. Reduces the SysQL learning curve for security teams, DevOps engineers, and cloud architects. 2. Sysdig Sage for Search (Assistant)Sysdig Sage for Search (Assistant) enhances SysQL Translation by delivering intelligent interpretation of query results. Rather than simply returning raw data, this assistant does the following:\nInterprets search results Identifies Relationships and maps connections between entities (for example, Which IAM roles have access to specific S3 buckets) Allows interactive follow-ups to analyze results (for example, Show only production resources) Key capabilities Explains SysQL query results in plain language Highlights security findings and compliance details for returned resources Enables query refinement through follow-up questions (for example, Show me only the EC2 instances with critical vulnerabilities.) By providing interpretation of query results with contextual insights, Sysdig Sage for Search (Assistant) bridges the gap between raw security data and actionable insights.\nExample Use Cases Inventory search: Count all S3 buckets in us-east-1 Risk assessment: List resources with critical vulnerabilities Compliance review: List cloud assets with failing security controls Threat analysis: Which EC2 instances have access to exposed S3 buckets? Benefits Simplified search: Retrieve cloud assets without writing queries in SysQL Multi-cloud visibility: Unified search across AWS, GCP, and Azure Security insights: Get details to vulnerabilities, misconfiguration, and compliance risks Data analysis: Understand relationships between resources, workloads, and security events AI-Powered Assistance: Refine searches interactively for deeper investigation Sysdig Sage for Search combines AI-powered natural language processing with structured query capabilities to make cloud security data more accessible and actionable.\n","url":"https://docs.sysdig.com/en/sysdig-sage/sysdig-sage-for-search/"},{"id":728,"title":"Sysdig Sage for Threat Detection","content":" Sysdig Sage for Threat Detection primarily targets users working in security operations responsible for incident response and forensics. It helps you reduce response time and speed up investigations. For example, Sysdig Sage can:\nExplain command lines Explain rules Interpret data Suggest areas to investigate for a particular issue Recommend next steps Sysdig Sage\u0026rsquo;s multi-level conversation is characterized by:\nSummarization: Offers top statistics for runtime security events based on various groupings such as policy name, rule, event type, severity, and more. Explainability: Provides in-depth information about specific security events. Example Prompts PROMPT VALUE What are the most critical events on my cloud infrastructure?\nWhat are my noisiest rules? Which containers are generating the most events? What are my top 3 high severity events\nWhat are the most critical events on my cloud infrastructure?\nHow many events do I have for each severity? Sysdig Sage can help you quickly summarize events on the Events Feed UI instead of analyzing them one by one. What process generated the selected runtime event?\nHelp me understand the selected runtime event\nExplain the rule that generated the selected runtime event Sysdig Sage is context aware. For example, Sysdig Sage is aware that the process that generated the selected runtime event. Sysdig Sage helps reduce analysis time down to a few seconds to get to the core interesting concepts. Can you explain the command line option in this event? Sysdig Sage gets you the right context with rich information and explanations. You no longer need to leave Sysdig Secure and search on the Internet. What cloud users are associated with runtime events? What users are associated with critical events? Sysdig Sage gives you insight into the users who are associated with a selected event. ","url":"https://docs.sysdig.com/en/sysdig-secure/sysdig-sage-for-cdr/"},{"id":729,"title":"Using the Agent Console","content":"Access Agent Console Select Integrations \u0026gt; Data Sources \u0026gt; Sysdig Agent. On the Sysdig Agents page, locate the agent you want to explore. Select the three-dot menu on the right-hand side of the view. Click Agent Console. Agent Console CommandsView HelpThe ? command displays the commands to manage Prometheus configuration and targets monitored by the Sysdig agent.\n$ prometheus ? $ prometheus config ? $ prometheus config show ? Command SyntaxThe syntax of the Agent Console commands is as follows:\ndirectory command directory sub-directory command directory sub-directory sub-sub-directory command View VersionRun the following to find the version of the agent running in your environment:\n$ version An example output:\n12.0.0 Troubleshoot Prometheus Metrics CollectionThese commands help troubleshoot Prometheus targets configured in your environment.\nFor example, the following commands display and scrape the Prometheus endpoints respectively.\n$ prometheus target show $ prometheus target scrape Sub-Directory CommandsThe Promscrape CLI consists of the following sections.\nconfig: Manages Sysdig agent-specific Prometheus configuration.\nmetadata: Manages metadata associated with the Prometheus targets monitored by the Sysdig agent.\nstats: Helps view the global- and job-specific Prometheus statistics.\ntarget: Manages Prometheus endpoints monitored by Sysdig agent.\nPrometheus CommandsShowThe show command displays the information about the subsection. For example, the following example displays the configuration of the Prometheus server.\n$ prometheus config show 5 Configuration Value 6 Enabled True 7 Target discovery Prometheus service discovery 8 Scraper Promscrape v2 9 Ingest raw True 10 Ingest calculated True 11 Metric limit 2000 ScrapeThe scrape command scrapes a Prometheus target and displays the information. The syntax is:\n$ prometheus target scrape -url \u0026lt;URL\u0026gt; For example:\n$ prometheus target scrape -url http://99.99.99.3:10055/metrics # HELP go_gc_duration_seconds A summary of the GC invocation durations. 7 # TYPE go_gc_duration_seconds summary 8 go_gc_duration_seconds{quantile=\u0026#34;0\u0026#34;} 7.5018e-05 9 go_gc_duration_seconds{quantile=\u0026#34;0.25\u0026#34;} 0.000118155 10 go_gc_duration_seconds{quantile=\u0026#34;0.5\u0026#34;} 0.000141586 11 go_gc_duration_seconds{quantile=\u0026#34;0.75\u0026#34;} 0.000171626 12 go_gc_duration_seconds{quantile=\u0026#34;1\u0026#34;} 0.00945638 13 go_gc_duration_seconds_sum 0.114420898 14 go_gc_duration_seconds_count 607 View Agent ConfigurationThe Agent configuration commands have a different syntax.\nRun the following to view the configuration of the agent running in your environment:\n$ configuration show-default-yaml $ configuration show-backend-yaml # docker environments $ configuration show-dragent-yaml # Kubernetes environments $ configuration show-configmap-yaml The output displays the configuration file. Sensitive data, such as the credentials, are obfuscated.\ncustomerid: \u0026#34;********\u0026#34; watchdog: max_memory_usage_mb: 2048 Security Considerations User-sensitive configuration is obfuscated and not visible through the CLI.\nAll the information is read-only. You cannot currently change any configuration by using the Agent console.\nRuns completely inside the agent. It does not use bash or any other Linux terminals to prevent the risk of command injection.\nRuns only via a TLS connection with the Sysdig backend.\nDisable Agent ConsoleThis is currently turned on by default. To turn off Agent Console for a particular team:\nNavigate to Settings \u0026gt; Teams.\nSelect the team that you want to disable Agent Console for.\nFrom Additional Permissions, Deselect Agent CLI.\nClick Save.\nTo turn it off in your environment, edit the following in the dragent.yaml file:\ncommand_line: enabled: false ","url":"https://docs.sysdig.com/en/sysdig-monitor/using-agent-console/"},{"id":730,"title":"Configure a Webhook Channel","content":" The new Custom Webhook with customizable payload option is currently available only in Monitor.\nPrerequisites Webhooks via HTTPS only work if a signed/valid certificate is in use.\nHave your destination URL on hand.\nSupportWebhook notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts Webhook notification channels are supported for the following use cases in Sysdig Secure:\nRuntime Policies Risks Threats Vulnerabilities Accepted Risk: Vulnerabilities Enable Webhook Log in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channel \u0026gt; Webhook.\nEnter the webhook channel configuration options:\nURL: The destination URL to which notifications will be sent.\nChannel Name: Add a meaningful name, such as Ansible.\nEnabled: Toggle on and off notifications.\nNotification options: Toggle for notifications when alerts are resolved or acknowledged.\nTest notification: Toggle to be notified that the configured URL is working.\nShared With: Choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nAllow insecure connections: Enable if you want to skip the TLS verification.\nCustom headers: Add custom headers to your alert notification.\nIf your webhook integrations require additional headers you specify them by using a custom header.\nFor example, Ansible uses token-based authentication, which requires an entry for the bearer token. This entry is not included in the default header, but you can add it using a custom header.\nAlternatively, you can choose to add custom headers programmatically as described in Configure Custom Headers and Custom Data Programmatically.\nCustom Data: Specify the custom data you want to attach to the alert notification. The data must be a valid JSON document. This information will be included in the request body of the HTTP call. Systems that receive these webhook alerts can parse the data and take action based on the contents.\nClick Save.\nWhen the channel is created, you can use it on any alerts you create.\nThen, when the alert fires, the notification will be sent as a POST in JSON format to your webhook endpoint. See Alert Output, below.\nFor testing purposes, you can use a third-party site to create a temporary endpoint to see exactly what a Sysdig alert will send in any specific notification.\nConfigure Custom Headers and Custom Data ProgrammaticallyBy default, alert notifications follow a standard format. See Description of POST Data, below.\nHowever, some integrations require additional headers and/or data, which you can append to the alert format using a custom header or custom data entry.\nFor example, Ansible uses token-based authentication, which requires an entry for the bearer token. This entry is not included in the default alert template built into Sysdig, but you can add it using a custom header.\nIn addition to the Webhook UI option, you can do this from the command line, as described below.\nadditionalHeaders is usually used for authentication\ncustomData is used to add values to the alert\nAfter it has been created via the API, any manipulation will mangle the notification channel. Use with care.\nSample Use CaseThis example adds two custom headers and defines additional custom data, as well as the format for that data.\nUse the curl command to retrieve all configured notification channels:\ncurl -X GET https://app.sysdigcloud.com/api/notificationChannels -H \u0026#39;Authorization: Bearer API-KEY\u0026#39; Add the custom headers and execute the request:\ncurl -X PUT https://app.sysdigcloud.com/api/notificationChannels/1 -H \u0026#39;Authorization: Bearer API-KEY\u0026#39; -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{ \u0026#34;notificationChannel\u0026#34;: { \u0026#34;id\u0026#34;: 1, \u0026#34;version\u0026#34;: 1, \u0026#34;type\u0026#34;: \u0026#34;WEBHOOK\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;name\u0026#34;: \u0026#34;Test-Sysdig\u0026#34;, \u0026#34;options\u0026#34;: { \u0026#34;notifyOnOk\u0026#34;: true, \u0026#34;url\u0026#34;: \u0026#34;https://hookb.in/v95r78No\u0026#34;, \u0026#34;notifyOnResolve\u0026#34;: true, \u0026#34;customData\u0026#34;: { \u0026#34;String-key\u0026#34;: \u0026#34;String-value\u0026#34;, \u0026#34;Double-key\u0026#34;: 2.3, \u0026#34;Int-key\u0026#34;: 23, \u0026#34;Null-key\u0026#34;: null, \u0026#34;Boolean-key\u0026#34;: true }, \u0026#34;additionalHeaders\u0026#34;: { \u0026#34;Header-1\u0026#34;: \u0026#34;Header-Value-1\u0026#34;, \u0026#34;Header-2\u0026#34;: \u0026#34;Header-Value-2\u0026#34; } } } }\u0026#39; Standard Alert OutputAlerts that use a custom webhook for notification send a JSON-format with the following data.\nDescription of POST Data{ \u0026#34;timestamp\u0026#34;: 1620222000000000, // Time when the alert triggered in microseconds \u0026#34;timespan\u0026#34;: 60000000, // range of the alert in microseconds (Period of time that the alert queries) \u0026#34;alert\u0026#34;: { \u0026#34;severity\u0026#34;: 2, // severity from 0 to 7, use severityLabel for a human readable version \u0026#34;editUrl\u0026#34;: \u0026#34;https://app-staging.sysdigcloud.com/#/alerts/21998727\u0026#34;, // alert edit URL \u0026#34;severityLabel\u0026#34;: \u0026#34;Medium\u0026#34;, // human readable version of severity \u0026#34;subject\u0026#34;: \u0026#34;CPU temp is High on homebridge:9100 is Triggered\u0026#34;, // Alert subject \u0026#34;scope\u0026#34;: null, // scope of the alert if set from the UI \u0026#34;name\u0026#34;: \u0026#34;CPU temp is High\u0026#34;, // name of the alert \u0026#34;description\u0026#34;: null, // description, not used ATM \u0026#34;id\u0026#34;: 21998727, // alert id \u0026#34;body\u0026#34;: \u0026#34;CPU temp is High on homebridge:9100 is Triggered\\n\\n\\nEvent Generated:\\n\\nSeverity: Medium\\n Metric:\\n node_hwmon_temp_celsius = 65.8121\\nSegment:\\n instance = \u0026#39;homebridge:9100\u0026#39;\\nScope:\\n Everywhere\\n\\nTime: 05/05/2021 01:40 PM UTC\\nState: Triggered\\nNotification URL: https://app-staging.sysdigcloud.com/#/events/notifications/l:2419200/14918845/details\\n\\n------\\n\\nTriggered by Alert:\\n\\nName: CPU temp is High\\nTeam: Monitor Operations\\nScope:\\n Everywhere\\nSegment by: instance\\nWhen: avg(avg(node_hwmon_temp_celsius)) \u0026gt; 40\\nFor at least: 1 m\\nAlert URL: https://app-staging.sysdigcloud.com/#/alerts/21998727\\n\\n\\n\u0026#34; }, \u0026#34;event\u0026#34;: { \u0026#34;id\u0026#34;: 14918845, // id of the generated event \u0026#34;url\u0026#34;: \u0026#34;https://app-staging.sysdigcloud.com/#/events/notifications/l:604800/14918845/details\u0026#34; // url of the event in the feed }, \u0026#34;state\u0026#34;: \u0026#34;ACTIVE\u0026#34;, // status of the alert, can be ACTIVE or OK \u0026#34;resolved\u0026#34;: true, \u0026#34;entities\u0026#34;: [ // list of entities that triggered the alert, at the moment we send a notification per entity, so this array will always contain a single object { \u0026#34;entity\u0026#34;: \u0026#34;instance = \u0026#39;homebridge:9100\u0026#39;\u0026#34;, // segment that triggered \u0026#34;metricValues\u0026#34;: [ // value of the metric at the time of triggering { \u0026#34;metric\u0026#34;: \u0026#34;node_hwmon_temp_celsius\u0026#34;, \u0026#34;aggregation\u0026#34;: \u0026#34;avg\u0026#34;, \u0026#34;groupAggregation\u0026#34;: \u0026#34;avg\u0026#34;, \u0026#34;value\u0026#34;: 65.812167 } ] } ], \u0026#34;endEntities\u0026#34;: [ // list of entities when the alert was resolved (same as \u0026#34;entities\u0026#34;) { \u0026#34;entity\u0026#34;: \u0026#34;instance = \u0026#39;homebridge:9100\u0026#39;\u0026#34;, \u0026#34;metricValues\u0026#34;: [ { \u0026#34;metric\u0026#34;: \u0026#34;node_hwmon_temp_celsius\u0026#34;, \u0026#34;aggregation\u0026#34;: \u0026#34;avg\u0026#34;, \u0026#34;groupAggregation\u0026#34;: \u0026#34;avg\u0026#34;, \u0026#34;value\u0026#34;: 39.812167 } ] } ], \u0026#34;condition\u0026#34;: \u0026#34;avg(avg(node_hwmon_temp_celsius)) \u0026gt; 40\u0026#34;, // alert condition in string form \u0026#34;source\u0026#34;: \u0026#34;Sysdig Cloud\u0026#34;, // source of the event \u0026#34;labels\u0026#34;: { // list of labels associated to this event (they strongly depend on the segmentation and scope of the alert) \u0026#34;instance\u0026#34;: \u0026#34;homebridge:9100\u0026#34; } } Example of Failure$ curl -X GET https://app.sysdigcloud.com/api/notificationChannels -H \u0026#39;authorization: Bearer dc1a42cc-2a5a-4661-b4d9-4ba835fxxxxx\u0026#39; {\u0026#34;timestamp\u0026#34;:1543419336542,\u0026#34;status\u0026#34;:401,\u0026#34;error\u0026#34;:\u0026#34;Unauthorized\u0026#34;,\u0026#34;message\u0026#34;:\u0026#34;Bad credentials\u0026#34;,\u0026#34;path\u0026#34;:\u0026#34;/api/notificationChannels\u0026#34;} Example of Success$ curl -X GET https://app.sysdigcloud.com/api/notificationChannels -H \u0026#39;Authorization: Bearer dc1a42cc-2a5a-4661-b4d9-4ba835fxxxxx\u0026#39; {\u0026#34;notificationChannels\u0026#34;:[{\u0026#34;id\u0026#34;:18968,\u0026#34;version\u0026#34;:2,\u0026#34;createdOn\u0026#34;:1543418691000,\u0026#34;modifiedOn\u0026#34;:1543419020000,\u0026#34;type\u0026#34;:\u0026#34;WEBHOOK\u0026#34;,\u0026#34;enabled\u0026#34;:true,\u0026#34;sendTestNotification\u0026#34;:false,\u0026#34;name\u0026#34;:\u0026#34;robin-webhook-test\u0026#34;,\u0026#34;options\u0026#34;:{\u0026#34;notifyOnOk\u0026#34;:true,\u0026#34;url\u0026#34;:\u0026#34;https://postb.in/6dtwzz7l\u0026#34;,\u0026#34;notifyOnResolve\u0026#34;:true}}]} $ The webhook feature is used to integrate the following channels:\nConfigure ServiceNow ","url":"https://docs.sysdig.com/en/administration/configure-a-webhook-channel/"},{"id":731,"title":"Which Scanning Engine to Use","content":" End of Life Notice: The Sysdig Legacy Scanning Engine reached its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\n","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/new-scanning-engine/"},{"id":732,"title":"Microsoft Entra Policy","content":" Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nCreate an Entra PolicyTo create an Entra policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select Microsoft Entra.\nConfigure an Entra PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate personnel.\nSee also: Set Up Notification Channels.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and Microsoft Entra.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose Microsoft Entra to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/ms_entra_policy/"},{"id":733,"title":"Event Scope (Legacy)","content":"Labels refer to a set of meaningful key-value pairs (whitelist) that are defined by Sysdig Monitor. As a user, you can configure the whitelist. For example, if you are using Elastic Container Service (ECS) and have defined custom container labels, you can configure the whitelist to add the labels you need. Once done, all the infrastructure events related to containers will be enriched with these labels and display associated metadata.\nFor more information on scoping, refer to the Using Labels documentation.\nConfigure Event ScopeTo configure the events feed scope:\nFrom the Events page, click the Edit Events Scope.\nExpand the drop-down menu.\nSelect the desired label, either by scrolling through the list, or by typing the name/partial name into the search bar, and selecting it.\nOpen the Operator drop-down menu, and select the relevant option.\nOpen the Value drop-down menu, and select the relevant options.\nOptional: Open the next level drop-down menu, and repeat steps 3-5.\nOptional: Repeat step 6 for each additional layer of scope required.\nIndividual layers of the scope can be removed if necessary, by clicking the Delete (x) icon beside the relevant layer.\nClick the Apply button to save the new scope.\nFilter Events by ScopeEvents are by default filtered by scope in Dashboards and Explore to show the most relevant events associated with the selected scope. This capability enables you to quickly narrow down the potential problems in the area under purview. However, you can turn the filtering off and see Events from the complete scope. To do so in Explore:\nFrom the Dashboard menu, select a dashboard of your choice.\nClick the Options (ellipsis icon) and select Events Display.\nThe Events panel appears. you can do the following:\nDetermine whether to show events or not.\nFilter events by\nScope: Determine whether to show events by scope. Supported scopes are Team Scope and Dashboard Scope. Select an option to see only the relevant events. Severity: The supported severity levels are all severity types, high severity, and both high and medium levels. See Severity and Status for more information. Types: The types of events supported are custom events and alerts. See Event Types for more information. Status: The supported statuses include triggered, resolved, acknowledged, and unacknowledged. See Severity and Status for more information. Click Save.\nReset the Environment ScopeTo reset the scope to the entire environment:\nFrom the Events page, click the Edit Events Scope.\nClick Clear All.\nClick the Apply to save the changes.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/event-scope-legacy/"},{"id":734,"title":"Configure a Google Chat Channel","content":"Prerequisites Have a Google Workspace account with access to Google Chat.\nHave access to Sysdig Monitor.\nSupportGoogle Chat notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts Configure Google ChatTo automatically push Sysdig Monitor alerts to the Google Chat, register the webhook in the Google Chat space where you want to receive messages, then copy the URL:\nOpen Google Chat in a web browser.\nClick New Chat, then Create a space you want to use for the webhook notifications.\nSelect the space that you have created for the webhook.\nClick the drop-down arrow next to the name of the space, and select Apps \u0026amp; Integrations, then Add webhooks.\nSpecify the following:\nName: Specify a unique name for your webhook. For example, Sysdig.\nAvatar URL: Optional: Specify the URL of an avatar image you might want to add to the webhook.\nClick Save.\nYour new webhook will appear under Webhooks.\nCopy the full webhook link. You can click the three-dot menu icon and then Copy link.\nConfigure Sysdig Monitor Log in to Sysdig Monitor or Sysdig Secure as an Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channel \u0026gt; Google Chat.\nEnter the Google Chat channel configuration options:\nURL: Paste the full webhook link.\nChannel Name: Enter a descriptive name.\nEnabled: Toggle to turn the channel on or off.\nNotify when Resolved: Toggle to send a notification when the alert condition is no longer triggered.\nNotify when Acknowledged: Toggle to send a notification when the alert is manually acknowledged by a user.\nTest notification: Toggle to send a test notification when saving changes.\nShared With: Choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nConfigure Test Notification: Select the severity and alert type of the test notification.\nClick Save.\n","url":"https://docs.sysdig.com/en/administration/google-chat-channel/"},{"id":735,"title":"Kubernetes State","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nkubernetes.hpa.replicas.minThe lower limit for the number of pods that can be set by the Horizontal Pod Autoscaler. The default value is 1.\nThe lower limit determines the minimum number of replicas that the autoscaler can periodically adjust in a replication controller or deployment to the target specified by the user in order to match the observed average CPU utilization.\nMetric Type: Gauge\nSegmented by:\nkubernetes.hpa.name\nkubernetes.cluster.id\nkubernetes.cluster.name\nkubernetes.namespace.name\nkubernetes.hpa.replicas.maxThe upper limit for the number of pods that can be set by the Horizontal Pod Autoscaler. This value cannot be smaller than that of kubernetes.hpa.replicas.min.\nThe upper limit determines the maximum number of replicas that the autoscaler can periodically adjust in a replication controller or deployment to the target specified by the user in order to match the observed average CPU utilization .\nMetric Type: Gauge\nSegmented by:\nkubernetes.hpa.name\nkubernetes.cluster.id\nkubernetes.cluster.name\nkubernetes.namespace.name\nkubernetes.hpa.replicas.currentThe current number of replicas of pods managed by the Horizontal Pod Autoscaler.\nMetric Type: Gauge\nSegmented by:\nkubernetes.hpa.name\nkubernetes.cluster.id\nkubernetes.cluster.name\nkubernetes.namespace.name\nkubernetes.hpa.replicas.desiredThe desired number of replicas of pods managed by the Horizontal Pod Autoscaler.\nMetric Type: Gauge\nSegmented by:\nkubernetes.hpa.name\nkubernetes.cluster.id\nkubernetes.cluster.name\nkubernetes.namespace.name\nkubernetes.resourcequota.configmaps.hardThe number of config maps that can be created in each Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.configmaps.usedThe current number of config maps in each Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.limits.cpu.hardThe total CPU limit across all pods in a non-terminal state in the cluster, determined by adding each pod\u0026rsquo;s CPU limit together.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.limits.cpu.usedThe current amount of CPU used across all cluster pods in a non-terminal state.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.limits.memory.hardThe total memory limit across all cluster pods in a non-terminal state.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.limits.memory.usedThe current amount of memory used across all cluster pods in a non-terminal state.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.persistentvolumeclaims.hardThe maximum number of persistent volume claims that can exist in the Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.persistentvolumeclaims.usedThe current number of persistent volume claims that exist in the Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.cpu.hardThe maximum number of CPU cores assigned in the namespace or at the resource quota scope level. Across all the pods in a non-terminal state, the sum of CPU requests cannot exceed this value.\nMetric Type: Gauge - Integer\nSegmented by:\nkubernetes.cluster\nkubernetes.namespace\nkubernetes.resourcequota\nkubernetes.resourcequota.memory.hardThe maximum memory assigned in the namespace or at the resource quota scope level. Across all the pods in a non-terminal state, the sum of memory requests cannot exceed this value\nMetric Type: Gauge - Integer\nSegmented by:\nkubernetes.cluster\nkubernetes.namespace\nkubernetes.resourcequota\nkubernetes.resourcequota.pods.hardThe maximum number of pods in a non-terminal state that can exist in the Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.pods.usedThe current number of pods in a non-terminal state that exists in the Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.replicationcontrollers.hardThe maximum number of replication controllers that can exist in the Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.replicationcontrollers.usedThe current number of replication controllers that can exist in the Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.requests.cpu.hardThe maximum number of CPU requests allowed across all cluster pods in a non-terminal state.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.requests.cpu.usedThe current number of CPU requests across all cluster pods in a non-terminal state.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.requests.memory.hardThe maximum number of memory requests allowed across all cluster pods in a non-terminal state.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.requests.memory.usedThe current total number of memory requests across all cluster pods in a non-terminal state.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.requests.storage.hardThe maximum number of storage requests allowed across all persistent volume claims in the cluster.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.requests.storage.usedThe current total number of storage requests across all persistent volume claims.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.resourcequotas.hardThe maximum number of resource quotas that can exist in the Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.resourcequotas.usedThe current number of resource quotas that exist in the Kubernetes namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.secrets.hardThe maximum number of secrets that can exist in the namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.secrets.usedThe current number of secrets that exist in the namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.services.hardThe maximum number of services that can exist in the namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.services.usedThe current number of services that exist in the namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.services.loadbalancers.hardThe maximum number of load balancer services that can exist in the namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.services.loadbalancers.usedThe current number of load balancer services that exist in the namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.services.nodeports.hardThe maximum number of node port services that can exist in the namespace.\nMetric Type: Gauge - Integer\nkubernetes.resourcequota.services.nodeports.usedThe current number of node port services that exist in the namespace.\nMetric Type: Gauge - Integer\nkubernetes.daemonSet.pods.desiredThe number of nodes that should be running the daemon pod.\nkubernetes.daemonSet.pods.misscheduledThe number of nodes running a daemon pod but are not supposed to.\nkubernetes.daemonSet.pods.readyThe number of nodes that should be running the daemon pod and have one or more of the daemon pod running and ready.\nkubernetes.daemonSet.pods.scheduledThe number of nodes that running at least one daemon pod and are supposed to.\nkubernetes.deployment.replicas.availableThe number of available pods per deployment.\nkubernetes.deployment.replicas.desiredThe number of desired pods per deployment.\nkubernetes.deployment.replicas.pausedThe number of paused pods per deployment. These pods will not be processed by the deployment controller.\nkubernetes.deployment.replicas.runningThe number of running pods per deployment.\nkubernetes.deployment.replicas.unavailableThe number of unavailable pods per deployment.\nkubernetes.deployment.replicas.updatedThe number of updated pods per deployment.\nkubernetes.job.completionsThe desired number of successfully finished pods that the job should be run with.\nkubernetes.job.numFailedThe number of pods which reached Phase Failed.\nkubernetes.job.numSucceededThe number of pods which reached Phase Succeeded.\nkubernetes.job.parallelismThe maximum desired number of pods that the job should run at any given time.\nkubernetes.job.status.activeThe number of actively running pods.\nkubernetes.namespace.countThe number of namespaces.\nkubernetes.namespace.deployment.countThe number of deployments per namespace.\nkubernetes.namespace.job.countThe number of jobs per namespaces.\nkubernetes.namespace.pod.status.countSupported by Sysdig Agent 9.5.0 and above.\nThe metric gives the number of pods in each aggregate state per Namespace. This is the value that the kubectl get pods command returns in the STATUS column. This metric does not represent the pod condition or the pod phase.\nSegmentable by kubernetes.namespace.name and kubernetes.namespace.pod.status.name.\nDue to performance implications, Sysdig Monitor shows only a subset of the pod aggregate statuses. The statuses displayed on the UI are:\nEvicted\nDeadlineExceeded\nError\nContainerCreating\nCrashLoopBackOff\nPending\nRunning\nTo view other statuses, override the default list by adding the following property in dragent.yaml\nk8s_pod_status_reason_strings: - Pending - ImagePullBackOff kubernetes.namespace.pod.running.countRequired: agent 9.6.0+\nThe number of all the running pods in a Namespace. The metric takes free pods also into account, that is, pods that do not belong to any controller. Therefore, its value is not the sum of (statefulset|daemonset|deployment).pod.running.count.\nkubernetes.namespace.pod.running.count is supported by Agent v9.6.0 and above.\nMetric Type: Gauge\nSegmented by: Namespace\nkubernetes.namespace.replicaSet.countThe number of replicaSets per namespace.\nkubernetes.namespace.service.countThe number of services per namespace.\nkubernetes.node.allocatable.cpuCoresThe CPU resources of a node that are available for scheduling.\nkubernetes.node.allocatable.memBytesThe memory resources of a node that are available for scheduling.\nkubernetes.node.allocatable.podsThe pod resources of a node that are available for scheduling.\nkubernetes.node.capacity.cpuCoresThe maximum CPU resources of the node.\nkubernetes.node.capacity.memBytesThe maximum memory resources of the node.\nkubernetes.node.capacity.podsThe maximum number of pods of the node.\nkubernetes.node.diskPressureThe number of nodes with disk pressure.\nkubernetes.node.memoryPressureThe number of nodes with memory pressure.\nkubernetes.node.networkUnavailableThe number of nodes with network unavailable.\nkubernetes.node.outOfDiskThe number of nodes that are out of disk space.\nkubernetes.node.readyThe number of nodes that are ready.\nkubernetes.node.unschedulableThe number of nodes unavailable to schedule new pods.\nkubernetes.pod.containers.waitingThe number of containers waiting for a pod.\nkubernetes.pod.resourceLimits.cpuCoresThe limit on CPU cores to be used by a container.\nkubernetes.pod.resourceLimits.memBytesThe limit on memory to be used by a container in bytes.\nkubernetes.pod.resourceRequests.cpuCoresThe number of CPU cores requested by containers in the pod.\nkubernetes.pod.resourceRequests.memBytesThe number of memory bytes requested by containers in the pod.\nkubernetes.pod.status.readyThe number of pods ready to serve requests.\nkubernetes.replicaSet.replicas.fullyLabeledThe number of fully labeled pods per ReplicaSet.\nkubernetes.replicaSet.replicas.readyThe number of ready pods per ReplicaSet.\nkubernetes.statefulset.replicasThe desired number of pods per StatefulSet.\nkubernetes.statefulset.status.replicasThe total number of pods created by the StatefulSet.\nkubernetes.statefulset.status.replicas.currentThe number of pods created by the current version of the StatefulSet.\nkubernetes.statefulset.status.replicas.readyThe number of ready pods created by this StatefulSet.\nkubernetes.statefulset.status.replicas.updatedThe number of pods updated to the new version of this StatefulSet.\n","url":"https://docs.sysdig.com/en/kubernetes-state/"},{"id":736,"title":"Lighttpd","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nAt this time, the Sysdig app check for Lighttpd supports Lighttpd version 1.x.x only.\nLighttpd SetupFor Lighttpd, the status page must be enabled. Add mod_status in the /etc/lighttpd/lighttpd.conf config file:\nserver.modules = ( ..., \u0026#34;mod_status\u0026#34;, ... ) Then configure an endpoint for it. If (for security purposes) you want to open the status page only to users from the local network, it can be done by adding the following lines in the /etc/lighttpd/lighttpd.conf file :\n$HTTP[\u0026#34;remoteip\u0026#34;] == \u0026#34;127.0.0.1/8\u0026#34; { status.status-url = \u0026#34;/server-status\u0026#34; } If you want an endpoint to be open for remote users based on authentication, then the mod_auth module should be enabled in the /etc/lighttpd/lighttpd.conf config file:\nserver.modules = ( ..., \u0026#34;mod_auth\u0026#34;, ... ) Then you can add the auth.require parameter in the /etc/lighttpd/lighttpd.conf config file:\nauth.require = ( \u0026#34;/server-status\u0026#34; =\u0026gt; ( \u0026#34;method\u0026#34; =\u0026gt; ... , \u0026#34;realm\u0026#34; =\u0026gt; ... , \u0026#34;require\u0026#34; =\u0026gt; ... ) ) For more information on the auth.require parameter, see the Lighttpd documentation..\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with Lighttpd and collect basic metrics.\napp_checks: - name: lighttpd pattern: comm: lighttpd conf: lighttpd_status_url: \u0026#34;http://localhost:{port}/server-status?auto\u0026#34; log_errors: false Metrics AvailableThese metrics are supported for Lighttpd version 1.x.x only. Lighttpd version 2.x.x is being built and is NOT ready for use as of this publication.\nSee Lighttpd Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/lighttpd/"},{"id":737,"title":"Lighttpd Metrics","content":"See Application Integrations for more information.\nlighttpd.net.bytesThe total number of bytes sent and received.\nlighttpd.net.bytes_per_sThe number of bytes sent and received per second.\nlighttpd.net.hitsThe total number of hits since the start.\nlighttpd.net.request_per_sThe number of requests per second.\nlighttpd.performance.busy_serversThe number of active connections.\nlighttpd.performance.idle_serverThe number of idle connections.\nlighttpd.performance.uptimeThe amount of time the server has been up and running.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/lighttpd-metrics/"},{"id":738,"title":"Manage Agent Privileges","content":"Benefits of Setting privileged: false Enhanced Security: By setting the privileged parameter to false, you can limit Linux capabilities, minimizing the attack surface. Mitigating Risk: Restricting the Sysdig Agent’s permissions helps mitigate risks associated with container privilege escalations. Prerequisites Sysdig Agent version 13.3.0 and later. The Sysdig Agent operates exclusively with eBPF drivers (either universal eBPF or eBPF based on kernel requirements). Ensure your environment is compatible with eBPF for optimal functionality. The Sysdig Agent does not support Google Kubernetes Engine (GKE) Autopilot. The Sysdig Agent does not support AWS Bottlerocket on ARM architecture. Disable the Privileged ParameterTo set the privileged parameter to false with Helm, use the sysdig-deploy Helm chart, and specify agent.privileged=false. See Sysdig Deploy.\nTo learn more about agent configuration, see Configure the Agent.\n","url":"https://docs.sysdig.com/en/sysdig-secure/classic-agent-privileges/"},{"id":739,"title":"Mesos Agent Metrics","content":"See Application Integrations for more information.\nmesos.slave.cpus_percentThe percentage of CPUs allocated to the slave.\nmesos.slave.cpus_totalThe total number of CPUs.\nmesos.slave.cpus_usedThe number of CPUs allocated to the slave.\nmesos.slave.disk_percentThe percentage of disk space allocated to the slave.\nmesos.slave.disk_totalThe total disk space available.\nmesos.slave.disk_usedThe amount of disk space allocated to the slave.\nmesos.slave.executors_registeringThe number of executors registering.\nmesos.slave.executors_runningThe number of executors currently running.\nmesos.slave.executors_terminatedThe number of terminated executors.\nmesos.slave.executors_terminatingThe number of terminating executors.\nmesos.slave.frameworks_activeThe number of active frameworks.\nmesos.slave.invalid_framework_messagesThe number of invalid framework messages.\nmesos.slave.invalid_status_updatesThe number of invalid status updates.\nmesos.slave.mem_percentThe percentage of memory allocated to the slave.\nmesos.slave.mem_totalThe total memory available.\nmesos.slave.mem_usedThe amount of memory allocated to the slave.\nmesos.slave.recovery_errorsThe number of errors encountered during slave recovery.\nmesos.slave.tasks_failedThe number of failed tasks.\nmesos.slave.tasks_finishedThe number of finished tasks.\nmesos.slave.tasks_killedThe number of killed tasks.\nmesos.slave.tasks_lostThe number of lost tasks.\nmesos.slave.tasks_runningThe number of running tasks.\nmesos.slave.tasks_stagingThe number of staging tasks.\nmesos.slave.tasks_startingThe number of starting tasks.\nmesos.slave.valid_framework_messagesThe number of valid framework messages.\nmesos.slave.valid_status_updatesThe number of valid status updates.\nmesos.state.task.cpuThe task CPU.\nmesos.state.task.diskThe disk space available for the task.\nmesos.state.task.memThe amount of memory used by the task.\nmesos.stats.registeredDefines whether this slave is registered with a master.\nmesos.stats.system.cpus_totalThe total number of CPUs available.\nmesos.stats.system.load_1minThe average load for the last minute.\nmesos.stats.system.load_5minThe average load for the last five minutes.\nmesos.stats.system.load_15minThe average load for the last 15 minutes.\nmesos.stats.system.mem_free_bytesThe amount of free memory.\nmesos.stats.system.mem_total_bytesThe total amount of memory.\nmesos.stats.uptime_secsThe current uptime for the slave.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/mesos-agent-metrics/"},{"id":740,"title":"Use Node Leases","content":"The Sysdig agent uses Kubernetes Lease to control how and when connections are made to the Kubernetes API Server. This mechanism prevents overloading the Kubernetes API server with connection requests during agent bootup.\nKubernetes node leases are automatically created for agent version 12.0.0 and above. On versions prior to 12.0.0, you must configure node leases as given in the KB article.\nPrerequisites Sysdig Agent v11.3.0 or above\nKubernetes v1.14 or above\nTypes of LeasesThe agent creates the following leases:\nCold StartDuring boot up, the Sysdig agent connects to the Kubernetes API server to retrieve Kubernetes metadata and build a cache. The cold-start leases control the number of agents that build up this cache at any given time. An agent will grab a lease, build its cache, and then release the lease so that another agent can build its cache. This mechanism prevents agents from creating a \u0026ldquo;boot storm\u0026rdquo; which can overwhelm the API server in large clusters.\nDelegationIn Kubernetes environments, two agents are marked as delegated in each cluster. The delegated agents are the designated agents to request more data from the API server and produce KubeState metrics. The delegation leases will not be released until the agent is terminated.\nView LeasesTo view the leases, run the following:\n$ kubectl get leases -n sysdig-agent You will see an output similar to the following:\nNAME HOLDER AGE cold-start-0 20m cold-start-1 20m cold-start-2 21m cold-start-3 ip-10-20-51-167 21m cold-start-4 21m cold-start-5 21m cold-start-6 20m cold-start-7 21m cold-start-8 20m cold-start-9 ip-10-20-51-166 21m delegation-0 ip-10-20-52-53 21m delegation-1 ip-10-20-51-98 21m Troubleshoot LeasesVerify ConfigurationWhen lease-based delegation is working as expected, the agent logs show one of the following:\nGetting pods only for node \u0026lt;node\u0026gt;\nGetting pods for all nodes.\nBoth (occasionally on the delegated nodes)\nRun the following to confirm that it is working:\n$ kubectl logs sysdig-agent-9l2gf -n sysdig-agent | grep -i \u0026#34;getting pods\u0026#34; The configuration is working as expected if the output on a pod is similar to the following:\n2021-05-05 02:48:32.877, 15732.15765, Information, cointerface[15738]: Only getting pods for node ip-10-20-51-166.ec2.internal Unable to Create LeasesThe latest Sysdig ClusterRole is required for the agent to create leases. If you do not have the latest ClusterRole or if you have not configured the ClusterRole correctly, the logs show the following error:\nError, lease_pool_manager[2989554]: Cannot access leases objects: leases.coordination.k8s.io is forbidden: User \u0026#34;system:serviceaccount:sysdig-agent:sysdig-agent\u0026#34; cannot list resource \u0026#34;leases\u0026#34; in API group \u0026#34;coordination.k8s.io\u0026#34; in the namespace \u0026#34;sysdig-agent\u0026#34; Contact Sysdig Support for help.\nOptional Agent ConfigurationSeveral configuration options exist for leases. It is recommended to not change the default settings unless prompted by Sysdig Customer Support.\nConfiguration\nDefault\nDescription\nk8s_coldstart: enabled: \u0026lt;true/false\u0026gt; true above agent versions 12.0.0\nWhen true, the agent will attempt to create cold-start leases to control the number of agents which are allowed to build their cache at one time.\nk8s_coldstart: max_parallel_cold_start: \u0026lt;int\u0026gt; 10\nThe number of cold-start leases to be created. This is the number of agents that can connect to the API Server simultaneously during agent initialization.\nk8s_coldstart: namespace: \u0026lt;string\u0026gt; sysdig-agent\nThe namespace to be created. This shouldn't be needed in agent version 12.0.0 because the DownwardAPI in the ClusterRole will provide the appropriate namespace.\nk8s_coldstart: enforce_leader_election: \u0026lt;true/false\u0026gt; false\nWhen true, the agent will not fall back to the previous method if it cannot create leases.This can be useful if the previous method caused API Server problems.\nk8s_delegation_election: \u0026lt;true/false\u0026gt; true above agent versions 12.0.0\nWhen true, the agent will create delegation leases to control which set of agents generate global cluster metrics.\n","url":"https://docs.sysdig.com/en/sysdig-secure/use-node-leases/"},{"id":741,"title":"Troubleshoot Notification Channels","content":"Message Throttling in Sysdig SecureIn Sysdig Secure, when notifications are working normally, there are situations in which not every event triggers a unique notification.\nWhen: If multiple events occur on the same policy-and-rule combination within a 5-minute window, only the first notification event is sent. This is done to avoid spamming Slack, email, or other channels.\nWhy: Notifications, even via the webhook channel, should be used as an alert that something has occurred, and the investigation should continue from the Events UI page in Sysdig Monitor or Sysdig Secure. They should not be relied upon to send data from the Events platform.\nIf you wish to generate a call to an external service for every instance of an event from Sysdig, Event Forwarding might be more appropriate to your use case. See Event Forwarding.\nNotification FailuresNotification failures occur when the system attempts to deliver a notification and receives any 4XX HTTP errors except the following:\n409 CONFLICT 408 TIMEOUT 423 LOCKED When other 4XX errors occur in a notification channel:\nSysdig puts the channel under observation for 24 hours, during which subsequent errors will not trigger any further behavior. This helps to control noise. If an error occurs after this 24 hour window has expired: In Sysdig Monitor, an event will appear in the event feed. The Sysdig platform can send notifications when an error occurs in a notification channel. See Notification Channel Failure Alerts. Another 24 hour observation period begins for the channel, during which additional errors will not trigger any further behavior. If, after this second 24 hour window, an error occurs again, another Monitor event and Platform email are generated, and a new 24 hour observation window begins. If five such error events occur, Sysdig disables the channel and sends an email to inform you of what has occurred. To reactivate, manually re-enable the channel after the underlying issues have been resolved.\nIf notifications begin to flow again during this process, the system resets to baseline, and treats subsequent incidents as new.\nFailure Alert FormatsEvents FeedA Sysdig Event occurs in the Events feed titled:\n\u0026ldquo;Warning: Notification attempt [Attempt #] of 5 through channel [Channel Name] failed\u0026rdquo;.\nEmailAdministrators are sent delivery failure emails titled:\n\u0026ldquo;Warning: Notification attempt [Attempt #] of 5 through channel [Channel Name] failed.\u0026rdquo;\n","url":"https://docs.sysdig.com/en/administration/troubleshoot-notifications-channels/"},{"id":742,"title":"Integrate StatsD Metrics","content":"The Sysdig agent contains an embedded StatsD server, so your custom metrics can now be sent to our collector and be relayed to the Sysdig Monitor backend for aggregation. Your application metrics and the rich set of metrics collected by our agent already can all be visualized in the same simple and intuitive graphical interface. Configuring alert notifications works in the same way.\nInstall and Configure StatsDThe Statsd server, embedded in Sysdig agent beginning with version 0.1.136, is pre-configured and starts by default so no additional user configuration is necessary. Install the agent in a supported distribution directly or install the Docker containerized version in your container server and you\u0026rsquo;re done.\nSend StatsD MetricsActive CollectionBy default, the Sysdig agent\u0026rsquo;s embedded StatsD collector listens on the standard StatsD port, 8125, both on TCP and UDP. StatsD is a text based protocol, where samples are separated by a \\n .\nSend metrics from your application to the collector:\necho \u0026#34;hello_statsd:1|c\u0026#34; \u0026gt; /dev/udp/127.0.0.1/8125 The example transmits the counter metric \u0026quot;hello_statsd\u0026quot; with a value of 1 to the Statsd collector listening on UDP port 8125. Here is a second example sending the output of a more complex shell command giving the number of established network connections:\necho \u0026#34;EstablishedConnections:`netstat -a | grep ESTAB | wc -l`|c\u0026#34; \u0026gt; /dev/udp/127.0.0.1/8125 The protocol format is as follows:\nMETRIC_NAME:METRIC_VALUE|TYPE[|@SAMPLING_RATIO] Metric names can be any string except reserved characters: |#:@ . Value is a number and depends on the metric type. Type can be any of: c, ms, g, s . Sampling ratio is a value between 0 (exclusive) and 1 and it\u0026rsquo;s used to handle subsampling. When sent, metrics will be available in the same display menu for the subviews as the built in metrics.\nPassive CollectionIn infrastructures already containing a third party StatsD collection server, StatsD metrics can be collected \u0026ldquo;out of band\u0026rdquo;. A passive collection technique is automatically performed by our agent by intercepting system calls - as is done for all the Sysdig Monitor metrics normally collected. This method does not require changing your current StatsD configuration and is an excellent way to \u0026rsquo;test drive\u0026rsquo; the Sysdig Monitor application without having to perform any modifications other than agent installation.\nThe passive mode of collection is especially suitable for containerized environments where simplicity and efficiency are essential. With the containerized version of the Sysdig Monitor agent running on the host, all other container applications can continue to transmit to any currently implemented collector. In the case where no collector exists, container applications can simply be configured to send StatsD metrics to the localhost interface (127.0.0.1) as demonstrated above - no actual StatsD server needs to be listening at that address.\nEffectively, each network transmission made from inside the application container, including statsd messages sent to a non existent destination, generates a system call. The Sysdig agent captures these system calls from its own container, where the statsd collector is listening. In practice, the Sysdig agent acts as a transparent proxy between the application and the StatsD collector, even if they are in different containers. The agent correlates which container a system call is coming from, and uses that information to transparently label the StatsD messages.\nThe above graphic demonstrates the components of the Sysdig agent and where metrics are actively or passively collected. Regardless of the method of collection, the number of StatsD metrics the agent can transmit is limited by your payment plan.\nNote 1: When using the passive technique, ICMP port unreachable events may be generated on the host network.\nNote 2: Some clients may use IPv6 addressing (::1) for the \u0026ldquo;localhost\u0026rdquo; address string. Metrics collection over IPv6 is not supported at this time. If your StatsD metrics are not visible in the Sysdig Monitor interface, please use \u0026ldquo;127.0.0.1\u0026rdquo; instead of \u0026ldquo;localhost\u0026rdquo; string to force IPv4. Another solution that may be required is adding the JVM option: java.net.preferIPv4Stack=true.\nNote 3: When StatsD metrics are not continuously transmitted by your application (once per second as in the case of all agent created metrics), the charts will render a \u0026lsquo;zero\u0026rsquo; or null value. Any alert conditions will only look at those Statsd values actually transmitted and ignore the nulls.\nSupported Metric TypesCounterA counter metric is updated with the value sent by the application, sent to the Sysdig Monitor backend, and then reset to zero. You can use it to count, for example, how many calls have been made to an API:\napi.login:1|c You can specify negative values to decrement a counter.\nGaugeA gauge is a single value that will be sent as is:\ntable_size:10000|g These are plotted as received, in the sense, they are at a point in time metrics. You can achieve relative increments or decrements on a counter by prepending the value with a + or a - respectively. As an example, these three samples will cause table_size to be 950:\ntable_size:1000|g table_size:-100|g table_size:+50|g In Sysdig Monitor, the gauge value is only rendered on the various charts when it is actually transmitted by your application. When not transmitted, a null is plotted on the charts which is not used in any calculations or alerts.\nSetA set is like a counter, but it counts unique elements. For example:\nactive_users:user1|s active_users:user2|sactive_users:user1|s Will cause the value of active_users to be 2.\nTimerTimer StatsD metrics types are not supported by default, but you can push them into sysdig by setting up prometheus/statsd_exporter as given in statsd exporter.\nMetric LabelsLabels are an extension of the StatsD specification offered by Sysdig Monitor to offer better flexibility in the way metrics are grouped, filtered and visualized. Labeling can be achieved by using the following syntax:\nenqueued_messages#az=eu-west-3,country=italy:10|c In general, this is the syntax you can use for labeling:\nMETRIC_NAME#LABEL_NAME=LABEL_VALUE,LABEL_NAME ... Labels can be simple strings or key/value pairs, separated by an = sign. Simple labels can be used for filtering in the Sysdig Monitor web interface. Key/value labels can be used for both filtering and segmentation.\nLabel names prefixed with ‘agent.label’ are reserved for Sysdig agent use only and any custom labels starting with that prefix will be ignored.\nLimitsThe number of StatsD metrics the agent can transmit is limited to 1000 for the host and 1000 for all running containers combined. If more metrics are needed please contact your sales representative with you use case.\nCollect StatsD Metrics Under LoadThe Sysdig agent can reliably receive StatsD metrics from containers, even while the agent is under load. This setting is controlled by the use_forwarder configuration parameter.\nThe Sysdig agent automatically parses and records StatsD metrics. Historically, the agent parsed the system call stream from the kernel in order to read and record StatsD metrics from containers. For performance reasons, the agent may not be able to collect all StatsD metrics using this mechanism if the load is high. For example, if the StatsD client writes more than 2kB worth of StatsD metrics in a single system call, the agent will truncate the StatsD message, resulting in loss of StatsD metrics.\nWith the introduction of the togglable use_forwarder option, the agent can collect StastsD metrics even under high load.\nThis feature is introduced in Sysdig agent v0.90.1. As of agent v10.4.0, the configuration is enabled by default.\nstatsd: use_forwarder: true To disable, set it to false:\nstatsd: use_forwarder: false When enabled, rather than use the system call stream for container StatsD messages, the agent listens for UDP datagrams on the configured StatsD port on the localhost within the container\u0026rsquo;s network namespace. This enables the agent to reliably receive StatsD metrics from containers, even while the agent is under load.\nThis option introduces a behavior change in the agent, both in the destination address and in port settings.\nWhen the option is disabled, the agent reads StatsD metrics that are destined to any remote address.\nWith the option is enabled, the agent receives only those metrics that are addressed to the localhost.\nWhen the option is disabled, the agent reads the container StatsD messages destined to only port 8125.\nWhen the option is enabled, the agent uses the configured StatsD port.\nStatsD Server Running in a Monitored ContainerUsing the forwarder is not a valid use case when a StatsD server is running in the container that you are monitoring.\nA StatsD server running in a container will already have a process bound to port 8125 or a configured StatsD port, so you can\u0026rsquo;t use that port to collect the metrics with the forwarder. A 10-second startup delay exists in the detection logic to allow any custom StatsD process to bind to that particular port before the forwarder. This ensures that the forwarder does not interrupt the operation.\nTherefore, for this particular use case, you will need to use the traditional method. Disable the forwarder and capture the metrics via the system call stream.\nCompatible ClientsEvery StatsD compliant client works with our implementation. Here is a quick list, it\u0026rsquo;s provided just as reference. We don\u0026rsquo;t support them, we support only the protocol specification compliance.\nNode.js\nJava\nPython\nPHP\nRuby\nGo\nA full list can be found at the StatsD GitHub page.\nTurning Off StatsD ReportingTo disable Sysdig agent\u0026rsquo;s embedded StatsD server, configure the agent with the following:\nstatsd: enabled: false If Sysdig Secure is used, a compliance check is enabled by default and it sends metrics via StatsD. When disabling StatsD, you need to disable the compliance check as well:\nsecurity: default_compliance_schedule: \u0026#34;\u0026#34; After modifying the configuration file, you will need to restart the agent with:\nservice dragent restart Changing the StatsD Listener Port and Transport ProtocolTo modify the port that the agent\u0026rsquo;s embedded StatsD server listens on, append the following lines to dragent.yaml:\nstatsd: tcp_port: #### udp_port: #### Replace \\#\\#\\#\\# with your port.\nCharacters Allowed For StatsD Metric NamesUse standard ASCII characters, we suggest also to use . namespaces as we do for all our metrics.\nAllowed characters: a-z A-Z 0-9 _ .\nLearn MoreFor more information on adding parameters to a container agent\u0026rsquo;s configuration file, see Configure the Agent.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/custom-integrations/integrate-statsd-metrics/"},{"id":743,"title":"Kubernetes Resource Usage","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nCompatibility MappingBefore using Kubernetes resource metrics, review their compatibility with Sysdig components. The newly supported Kubernetes metrics are not available to older versions of Sysdig Agent.\nNote also that you must edit the agent config file, dragent.yaml, to enable these metrics. See Enable Kube State Metrics Collection with K8s_extra_resources.\nMetric Name Agent Platform PVC metrics 0.89.3 and beyond Release 2172 Resource Quota metrics 0.87.1 and beyond Release 2172 HPA metrics 0.79.0 and beyond Release 2172 Kubernetes Resource Metrics Metric Name\nMetric Description\nMetric Type\nSegment By\nkubernetes.persistentvolumeclaim.storage\nThe storage capacity requested by the persistent volume claim.\nkubernetes.persistentvolumeclaim.storage provides Sysdig users with a single overarching metric for persistent volume claims (PVCs), rather than a series of metrics that often repeat/duplicate information. Each Kubernetes PVC metric is mapped to a kubernetes.persistentvolumeclaim.storage label, which can then be used to segment the overarching metric.\nSee Using Labels for more information on segmenting metrics.\nGauge\nkubernetes.namespace.name\nkubernetes.persistentvolumeclaim.label.accessmode\nkubernetes.persistentvolumeclaim.label.app\nkubernetes.persistentvolumeclaim.label.status.phase\nkubernetes.persistentvolumeclaim.label.storage\nkubernetes.persistentvolumeclaim.label.storageclassname\nkubernetes.persistentvolumeclaim.label.volumename\nkubernetes.pod.restart.count\nThe cumulative number of container restarts for the pod over its lifetime.\nThis metric is not useful for alerts. Sysdig recommends using kubernetes.pod.restart.rate instead.\nCounter - Integer\nKubernetes\nkubernetes.pod.restart.rate\nThe number of container restarts for the pod within the defined scope/time period.\nGauge - Integer\nKubernetes\nkubernetes.replicaSet.replicas.desired\nThe number of replica pods the replicaSet is configured to maintain.\nGauge - Integer\nKubernetes\nkubernetes.replicaSet.replicas.running\nThe current number of replica pods running in the replicaSet.\nGauge - Integer\nKubernetes\nkubernetes.replicationController.replicas.desired\nThe number of replica pods the replicationController is configured to maintain.\nGauge - Integer\nKubernetes\nkubernetes.replicationController.replicas.running\nThe current number of replica pods running in the replication controller.\nGauge - Integer\nKubernetes\n","url":"https://docs.sysdig.com/en/resource-usage/"},{"id":744,"title":"Memcached","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nMemcached SetupMemcached will automatically expose all metrics. You do not need to add anything on Memcached instance.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with Memcached and collect basic metrics:\napp_checks: - name: memcached check_module: mcache pattern: comm: memcached conf: url: localhost port: \u0026#34;{port}\u0026#34; Additional metrics can be collected by editing Sysdig\u0026rsquo;s configuration file dragent.yaml. If SASL is enabled, authentication parameters must be added to dragent.yaml.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1: Additional Metrics memcache.items.* and memcache.slabs.* can be collected by setting flags in the options section, as follows . Either value can be set to false if you do not want to collect metrics from them.\napp_checks: - name: memcached check_module: mcache pattern: comm: memcached conf: url: localhost port: \u0026#34;{port}\u0026#34; options: items: true # Default is false slabs: true # Default is false Example 2: SASLSASL authentication can be enabled with Memcached (see instructions here). If enabled, credentials must be provided against username and password fields as shown in Example 2.\napp_checks: - name: memcached check_module: mcache pattern: comm: memcached conf: url: localhost port: \u0026#34;{port}\u0026#34; username: \u0026lt;username\u0026gt; # Some memcached version will support \u0026lt;username\u0026gt;@\u0026lt;hostname\u0026gt;. # If memcached is installed as a container, hostname of memcached container will be used as username password: \u0026lt;password\u0026gt; Metrics AvailableSee Memcached Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/memcached/"},{"id":745,"title":"Memcached Metrics","content":"See Application Integrations for more information.\nmemcache.avg_item_sizeThe average size of an item.\nmemcache.bytesThe current number of bytes used by this server to store items.\nmemcache.bytes_read_rateThe rate of bytes read from the network by this server.\nmemcache.bytes_written_rateThe rate of bytes written to the network by this server.\nmemcache.cas_badval_rateThe rate at which keys are compared and swapped where the comparison (original) value did not match the supplied value.\nmemcache.cas_hits_rateThe rate at which keys are compared and swapped and found present.\nmemcache.cas_misses_rateThe rate at which keys are compared and swapped and not found present.\nmemcache.cmd_flush_rateThe rate of flush_all commands.\nmemcache.cmd_get_rateThe rate of get commands.\nmemcache.cmd_set_rateThe rate of set commands.\nmemcache.connection_structuresThe number of connection structures allocated by the server.\nmemcache.curr_connectionsThe number of open connections to this server.\nmemcache.curr_itemsThe current number of items stored by the server.\nmemcache.delete_hits_rateThe rate at which delete commands result in items being removed.\nmemcache.delete_misses_rateThe rate at which delete commands result in no items being removed.\nmemcache.evictions_rateThe rate at which valid items are removed from cache to free memory for new items.\nmemcache.fill_percentThe amount of memory being used by the server for storing items as a percentage of the max allowed.\nmemcache.get_hit_percentThe percentage of requested keys that are found present since the start of the Memcached server.\nmemcache.get_hits_rateThe rate at which keys are requested and found present.\nmemcache.get_misses_rateThe rate at which keys are requested and not found.\nmemcache.items.ageThe age of the oldest item in the LRU.\nmemcache.items.crawler_reclaimed_rateThe rate at which items freed by the LRU Crawler.\nmemcache.items.direct_reclaims_rateThe rate at which worker threads had to directly pull LRU tails to find memory for a new item.\nmemcache.items.evicted_nonzero_rateThe rate at which nonzero items which had an explicit expire time set had to be evicted from the LRU before expiring.\nmemcache.items.evicted_rateThe rate st which items had to be evicted from the LRU before expiring.\nmemcache.items.evicted_timeThe number of seconds since the last access for the most recent item evicted from this class.\nmemcache.items.evicted_unfetched_rateThe rate at which valid items evicted from the LRU which were never touched after being set.\nmemcache.items.expired_unfetched_rateThe rate at which expired items reclaimed from the LRU which were never touched after being set.\nmemcache.items.lrutail_reflocked_rateThe rate at which items found to be refcount locked in the LRU tail.\nmemcache.items.moves_to_cold_rateThe rate at which items were moved from HOT or WARM into COLD.\nmemcache.items.moves_to_warm_rateThe rate at which items were moved from COLD to WARM.\nmemcache.items.moves_within_lru_rateThe rate at which active items were bumped within HOT or WARM.\nmemcache.items.numberThe number of items presently stored in this slab class.\nmemcache.items.number_coldThe number of items presently stored in the COLD LRU.\nmemcache.items.number_hotThe number of items presently stored in the HOT LRU.\nmemcache.items.number_noexpThe number of items presently stored in the NOEXP class.\nmemcache.items.number_warmThe number of items presently stored in the WARM LRU.\nmemcache.items.outofmemory_rateThe rate at which the underlying slab class was unable to store a new item.\nmemcache.items.reclaimed_rateThe rate at which entries were stored using memory from an expired entry.\nmemcache.items.tailrepairs_rateThe rate at which Memcached self-healed a slab with a refcount leak.\nmemcache.limit_maxbytesThe number of bytes this server is allowed to use for storage.\nmemcache.listen_disabled_num_rateThe rate at which the server has reached the max connection limit.\nmemcache.pointer_sizeThe default size of pointers on the host OS (generally 32 or 64).\nmemcache.rusage_system_rateThe fraction of user time the CPU spent executing this server process.\nmemcache.rusage_user_rateThe fraction of time the CPU spent executing kernel code on behalf of this server process.\nmemcache.slabs.active_slabsThe total number of slab classes allocated.\nmemcache.slabs.cas_badval_rateThe rate at which CAS commands failed to modify a value due to a bad CAS ID.\nmemcache.slabs.cas_hits_rateThe rate at which CAS commands modified this slab class.\nmemcache.slabs.chunk_sizeThe amount of space each chunk uses.\nmemcache.slabs.chunks_per_pageThe number of chunks that exist within one page.\nmemcache.slabs.cmd_set_rateThe rate at which set requests stored data in this slab class.\nmemcache.slabs.decr_hits_rateThe rate at which decrs commands modified this slab class.\nmemcache.slabs.delete_hits_rateThe rate at which delete commands succeeded in this slab class.\nmemcache.slabs.free_chunksThe number of chunks not yet allocated to items or freed via delete.\nmemcache.slabs.free_chunks_endThe number of free chunks at the end of the last allocated page.\nmemcache.slabs.get_hits_rateThe rate at which get requests were serviced by this slab class.\nmemcache.slabs.incr_hits_rateThe rate at which incrs commands modified this slab class.\nmemcache.slabs.mem_requestedThe number of bytes requested to be stored in this slab.\nmemcache.slabs.total_chunksThe total number of chunks allocated to the slab class.\nmemcache.slabs.total_mallocedThe total amount of memory allocated to slab pages.\nmemcache.slabs.total_pagesThe total number of pages allocated to the slab class.\nmemcache.slabs.touch_hits_rateThe rate of touches serviced by this slab class.\nmemcache.slabs.used_chunksThe number of chunks that have been allocated to items.\nmemcache.slabs.used_chunks_rateThe rate at which chunks have been allocated to items.\nmemcache.threadsThe number of threads used by the current Memcached server process.\nmemcache.total_connections_rateThe rate at which connections to this server are opened.\nmemcache.total_itemsThe total number of items stored by this server since it started.\nmemcache.uptimeThe number of seconds this server has been running.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/memcached-metrics/"},{"id":746,"title":"Okta ML Policy","content":"This policy:\nLeverages machine learning to continuously monitor your cloud environment for unusual login activities, and notifies you when they happen.\nDetects and alerts you of anomalies in your Okta logs.\nExtends the functionality of Falco rules, providing a second layer of defense.\nPrerequisites Okta must be integrated into Sysdig Secure. See Okta Integration.\nCustomer Data Analytics collection must be enabled under Privacy Settings. See Privacy Settings.\nConfigure Okta ML Custom PolicyIn the Sysdig Secure UI:\nSelect Policies \u0026gt; Runtime Policies.\nClick +Add Policy (at the top right of the page).\nSelect Okta ML policy type.\nConfigure the policy:\nBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description or keep the default one.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI:\nHigh, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance.\nNote: There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nDetectAnomalous Login: Toggle on or off and select the confidence level at which the policy should be triggered: Default, Higher, or Highest.\nDefault: This is the value at which the model is tested by Sysdig\u0026rsquo;s Threat Research Team. Higher and Highest: The higher the value chosen, the lower the chance of false positives, but the higher the chance of false negatives (i.e. missed anomalous behaviors). ActionsNotify: Select a notification channel from the drop-down list for sending notifications of events to appropriate personnel.\nSee Set Up Notification Channels.\n","url":"https://docs.sysdig.com/en/sysdig-secure/okta_ml_policy/"},{"id":747,"title":"Process","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nfd.used.percentThe percentage of used file descriptors out of the maximum available. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nThis metric should be monitored carefully, and used for alerts, as when a process reaches its file descriptor limit, the process will stop operating correctly, and potentially crash.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max proc.commandLineCommand line used to start the process.\nMetadata Description Metric Type Gauge Value Type String Segment By Process Default Time Aggregation N/a Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A proc.countThe number of processes on host or container, excluding any processes that do not have .exe or command line parameters in the process table. These processes typically are kernel or system level, and are typically identified by square brackets (for example, [kthreadd]).\nAs some processes are excluded, the host level proc.count value will be lower than the value reported by the ps -ef command on the host.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max proc.nameName of the process.\nMetadata Description Metric Type Gauge Value Type String Segment By Process Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A proc.name.clientName of the Client process.\nMetadata Description Metric Type Gauge Value Type String Segment By Process Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A proc.name.serverName of the server process.\nMetadata Description Metric Type Gauge Value Type String Segment By Process Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A proc.start.countNumber of process starts on host or container.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/process/"},{"id":748,"title":"Using PromQL Library","content":"Using the examples, you can also perform complex queries against your metrics with one click and get insight into your infrastructure problems which was not previously possible with Sysdig querying.\nYou’ll find PromQL Library on the Explore slider menu on the Sysdig Monitor UI. To access it, click Explore \u0026gt; PromQL Library.\nUse PromQL LibraryClick Try me to open PromQL Query Explore. A visualization corresponding to the query will be displayed.\nSee PromQL Query Explorer for more information.\nTo copy a query, click the copy icon next to the query.\nFilter PromQL QueriesAutomatic tag filtering identifies common tags in the given examples. You can use the following to filter queries:\nVisual label filtering: Simply click the desired color-coded label to filter queries based on tags.\nText search: Use the Text Search bar on the top-left navigation pane.\nLabel search: Use the Label drop-down list on the top-left navigation pane.\nFilter using categories: Use the All Categories checkboxes.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/using-promql-library/"},{"id":749,"title":"Third-Party Integrations","content":"Sysdig has been designed to work seamlessly with a number of third-party applications. You can turn a Sysdig Secure event into a Jira ticket through the Sysdig UI, or use Sysdig to scan Git Pull Requests to ensure they meet your security policies.\nFollow the links below to integrate third-party applications with Sysdig:\nSysdig Secure IntegrationsIn Sysdig Secure, the following integrations are available:\nGit Jira Risk Spotlight tools, such as Snyk and Docker Scout Sysdig Monitor IntegrationsIn Sysdig Monitor, the following integrations are available:\nGrafana ","url":"https://docs.sysdig.com/en/administration/third-party_integrations/"},{"id":750,"title":"Mesos Master Metrics","content":"See Application Integrations for more information.\nmesos.cluster.cpus_percentThe percentage of CPUs allocated to the cluster.\nmesos.cluster.cpus_totalThe total number of CPUs.\nmesos.cluster.cpus_usedThe number of CPUs used by the cluster.\nmesos.cluster.disk_percentThe percentage of disk space allocated to the cluster.\nmesos.cluster.disk_totalThe total amount of disk space.\nmesos.cluster.disk_usedThe amount of disk space used by the cluster.\nmesos.cluster.dropped_messagesThe number of dropped messages.\nmesos.cluster.event_queue_dispatchesThe number of dispatches in the event queue.\nmesos.cluster.event_queue_http_requestsThe number of HTTP requests in the event queue.\nmesos.cluster.event_queue_messagesThe number of messages in the event queue.\nmesos.cluster.frameworks_activeThe number of active frameworks.\nmesos.cluster.frameworks_connectedThe number of connected frameworks.\nmesos.cluster.frameworks_disconnectedThe number of disconnected frameworks.\nmesos.cluster.frameworks_inactiveThe number of inactive frameworks.\nmesos.cluster.gpus_totalThe total number of GPUs.\nmesos.cluster.invalid_framework_to_executor_messagesThe number of invalid messages between the framework and the executor.\nmesos.cluster.invalid_status_update_acknowledgementsThe number of invalid status update acknowledgements.\nmesos.cluster.invalid_status_updatesThe number of invalid framework messages.\nmesos.cluster.mem_percentThe percentage of memory allocated to the cluster.\nmesos.cluster.mem_totalThe total amount of memory available.\nmesos.cluster.mem_usedThe amount of memory the cluster is using.\nmesos.cluster.outstanding_offersThe number of outstanding resource offers.\nmesos.cluster.slave_registrationsThe number of slaves able to rejoin the cluster after a disconnect.\nmesos.cluster.slave_removalsThe number of slaves that have been removed for any reason, including maintenance.\nmesos.cluster.slave_reregistrationsThe number of slaves that have re-registered.\nmesos.cluster.slave_shutdowns_canceledThe number of slave shutdowns processes that have been cancelled.\nmesos.cluster.slave_shutdowns_scheduledThe number of slaves that have failed health checks and are scheduled for removal.\nmesos.cluster.slaves_activeThe number of active slaves.\nmesos.cluster.slaves_connectedThe number of connected slaves.\nmesos.cluster.slaves_disconnectedThe number of disconnected slaves.\nmesos.cluster.slaves_inactiveThe number of inactive slaves.\nmesos.cluster.tasks_errorThe number of cluster tasks that resulted in an error.\nmesos.cluster.tasks_failedThe number of failed cluster tasks.\nmesos.cluster.tasks_finishedThe number of completed cluster tasks.\nmesos.cluster.tasks_killedThe number of killed cluster tasks.\nmesos.cluster.tasks_lostThe number of lost cluster tasks.\nmesos.cluster.tasks_runningThe number of cluster tasks currently running.\nmesos.cluster.tasks_stagingThe number of cluster tasks currently staging.\nmesos.cluster.tasks_startingThe number of cluster tasks starting.\nmesos.cluster.valid_framework_to_executor_messagesThe number of valid framework messages.\nmesos.cluster.valid_status_update_acknowledgementsThe number of valid status update acknowledgements.\nmesos.cluster.valid_status_updatesThe number of valid status updates.\nmesos.framework.cpuThe CPU of the Mesos framework.\nmesos.framework.diskThe total disk space of the Mesos framework, measured in mebibytes.\nmesos.framework.memThe total memory of the Mesos framework, measured in mebibytes.\nmesos.registrar.queued_operationsThe number of queued operations.\nmesos.registrar.registry_size_bytesThe size of the Mesos registry in bytes.\nmesos.registrar.state_fetch_msThe Mesos registry\u0026rsquo;s read latency, in bytes.\nmesos.registrar.state_store_msThe Mesos registry\u0026rsquo;s write latency, in bytes.\nmesos.registrar.state_store_ms.countThe Mesos registry\u0026rsquo;s write count, in bytes.\nmesos.registrar.state_store_ms.maxThe maximum write latency for the registry, in milliseconds.\nmesos.registrar.state_store_ms.minThe minimum write latency for the registry, in miliseconds.\nmesos.registrar.state_store_ms.p50The median registry write latency, in milliseconds.\nmesos.registrar.state_store_ms.p90The 90th percentile registry write latency, in milliseconds.\nmesos.registrar.state_store_ms.p95The 95th percentile registry write latency, in milliseconds.\nmesos.registrar.state_store_ms.p99The 99th percentile registry write latency, in milliseconds.\nmesos.registrar.state_store_ms.p999The 99.9th percentile registry write latency, in milliseconds.\nmesos.registrar.state_store_ms.p9999The 99.99th percentile registry write latency, in milliseconds.\nmesos.role.cpuThe CPU capacity of the configured role.\nmesos.role.diskThe total disk space available to the Mesos role, in mebibytes.\nmesos.role.memThe total memory available to the Mesos role, in mebibytes.\nmesos.stats.electedDefines whether this is the elected master or not.\nmesos.stats.system.cpus_totalThe total number of CPUs in the system.\nmesos.stats.system.load_1minThe average load for the last minute.\nmesos.stats.system.load_5minThe average load for the last five minutes.\nmesos.stats.system.load_15minThe average load for the last fifteen minutes.\nmesos.stats.system.mem_free_bytesThe total amount of free system memory, in bytes.\nmesos.stats.system.mem_total_bytesThe total cluster memory in bytes.\nmesos.stats.uptime_secsThe current uptime of the cluster.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/mesos-master-metrics/"},{"id":751,"title":"Mesos/Marathon","content":"Marathon is a production-grade container orchestration platform for Apache Mesos.\nIf Mesos and Marathon are installed in your environment, the Sysdig agent will automatically connect and start collecting metrics.\nThis page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nMesos/Marathon SetupBoth Mesos and Marathon will automatically expose all metrics. You do not need to add anything to the Mesos/Marathon instance.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nThe Sysdig agent has different entries for mesos-master, mesos-slave and marathon in its configuration file. Default entries are present in Sysdig\u0026rsquo;s dragent.default.yaml file and collect all metrics for Mesos. For Marathon, it collects basic metrics. You may need add configuration to collect additional metrics.\nDefault ConfigurationIn the URLs for mesos-master and mesos-slave, {mesos_url} will be replaced with either the hostname of the auto-detected mesos master/slave (if auto-detection is enabled), or with an explicit value from mesos_state_uri otherwise.\nIn the URLs for marathon, {marathon_url} will be replaced with the hostname of the first configured/discovered Marathon framework.\nFor all Mesos and Marathon apps, {auth_token} will either be blank or an auto-generated token obtained via the /acs/api/v1/auth/login endpoint.\nMesos Masterapp_checks: - name: mesos-master check_module: mesos_master interval: 30 pattern: comm: mesos-master conf: url: \u0026#34;http://localhost:5050\u0026#34; auth_token: \u0026#34;{auth_token}\u0026#34; mesos_creds: \u0026#34;{mesos_creds}\u0026#34; Mesos Agent\napp_checks: - name: mesos-slave check_module: mesos_slave interval: 30 pattern: comm: mesos-slave conf: url: \u0026#34;http://localhost:5051\u0026#34; auth_token: \u0026#34;{auth_token}\u0026#34; mesos_creds: \u0026#34;{mesos_creds}\u0026#34; Marathon\napp_checks: - name: marathon check_module: marathon interval: 30 pattern: arg: mesosphere.marathon.Main conf: url: \u0026#34;{marathon_url}\u0026#34; auth_token: \u0026#34;{auth_token}\u0026#34; marathon_creds: \u0026#34;{marathon_creds}\u0026#34; Remember! Never edit dragent.default.yaml directly; always edit dragent.yaml.\nMarathonEnable the flag full_metrics to collect all metrics for marathon.\nThe following additional metrics are collected with this configuration:\nmarathon.cpus\nmarathon.disk\nmarathon.instances\nmarathon.mem\napp_checks: - name: marathon check_module: marathon interval: 30 pattern: arg: mesosphere.marathon.Main conf: url: \u0026#34;{marathon_url}\u0026#34; auth_token: \u0026#34;{auth_token}\u0026#34; marathon_creds: \u0026#34;{marathon_creds}\u0026#34; Metrics AvailableSee Mesos Master Metrics.\nSee Mesos Agent Metrics.\nSee Marathon Metrics.\nResult in the Monitor UIMesos Master Mesos Agent Marathon ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/mesos-marathon/"},{"id":752,"title":"Okta Policy","content":" Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nCreate an Okta PolicyTo create an Okta policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select Okta.\nConfigure an Okta PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate personnel.\nSee also: Set Up Notification Channels.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and Okta.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, and choose Okta to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/okta_policy/"},{"id":753,"title":"RedisDB Metrics","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nSee RedisDB integration information.\nredis.aof.buffer_lengthThe size of the AOF buffer.\nredis.aof.last_rewrite_timeThe duration of the last AOF rewrite.\nredis.aof.rewriteA flag indicating that a AOF rewrite operation is on-going.\nredis.clients.biggest_input_bufThe biggest input buffer among current client connections.\nredis.clients.blockedThe number of connections waiting on a blocking call.\nredis.clients.longest_output_listThe longest output list among current client connections.\nredis.command.callsThe number of times a redis command has been called. The commands are tagged with command (for example, command:append).\nredis.command.usec_per_callThe CPU time consumed per redis command call. The commands are tagged with command (for example, command:append).\nredis.cpu.sysThe system CPU consumed by the Redis server.\nredis.cpu.sys_childrenThe system CPU consumed by the background processes.\nredis.cpu.userThe user CPU consumed by the Redis server.\nredis.cpu.user_childrenThe user CPU consumed by the background processes.\nredis.expiresThe number of keys that have expired.\nredis.expires.percentThe percentage of total keys that have been expired.\nredis.info.latency_msThe latency of the redis INFO command.\nredis.key.lengthThe number of elements in a given key. Each element is tagged by key (for example, key:mykeyname).\nredis.keysThe total number of keys.\nredis.keys.evictedThe total number of keys evicted due to the maxmemory limit.\nredis.keys.expiredThe total number of keys expired from the database.\nredis.mem.fragmentation_ratioThe ratio between used_memory_rss and used_memory.\nredis.mem.luaThe amount of memory used by the Lua engine.\nredis.mem.maxmemoryThe maximum amount of memory allotted to the RedisDB system.\nredis.mem.overheadSum of all the overheads allocated by Redis for managing its internal data structures.\nSupported by Sysdig Agent v9.7.0 and above.\nredis.mem.peakThe peak amount of memory used by Redis.\nredis.mem.startupAmount of memory consumed by Redis while initializing.\nSupported by Sysdig Agent v9.7.0 and above.\nredis.mem.rssThe amount of memory that Redis allocated as seen by the operating system.\nredis.mem.usedThe amount of memory allocated by Redis.\nredis.net.clientsThe number of connected clients (excluding slaves).\nredis.net.commandsThe number of commands processed by the server.\nredis.net.commands.instantaneous_ops_per_secThe number of commands processed by the server per second.\nredis.net.rejectedThe number of rejected connections.\nredis.net.slavesThe number of connected slaves.\nredis.perf.latest_fork_usecThe duration of the latest fork.\nredis.persistThe number of keys persisted. The formula for this metric is redis.keys - redis.expires.\nredis.persist.percentPercentage of total keys that are persisted.\nredis.pubsub.channelsThe number of active pubsub channels.\nredis.pubsub.patternsThe number of active pubsub patterns.\nredis.rdb.bgsaveDetermines whether a bgsave is in progress. The value is one if a bgsave is in progress, and zero at all other times.\nredis.rdb.changes_since_lastThe number of changes since the last background save.\nredis.rdb.last_bgsave_timeThe duration of the last bg_save operation.\nredis.replication.backlog_histlenThe amount of data in the backlog sync buffer.\nredis.replication.delayThe replication delay in offsets.\nredis.replication.last_io_seconds_agoThe amount of time since the last interaction with master.\nredis.replication.master_link_down_since_secondsThe amount of time that the master link has been down.\nredis.replication.master_repl_offsetThe replication offset reported by the master.\nredis.replication.slave_repl_offsetThe replication offset reported by the slave.\nredis.replication.syncDetermines whether a sync is in progress. The value is one if a sync is in progress, and zero at all other times.\nredis.replication.sync_left_bytesThe amount of data left before syncing is complete.\nredis.slowlog.micros.95percentileThe 95th percentile of the duration of queries reported in the slow log.\nredis.slowlog.micros.avgThe average duration of queries reported in the slow log.\nredis.slowlog.micros.countThe rate of queries reported in the slow log.\nredis.slowlog.micros.maxThe maximum duration of queries reported in the slow log.\nredis.slowlog.micros.medianThe median duration of queries reported in the slow log.\nredis.stats.keyspace_hitsThe total number of successful lookups in the database.\nredis.stats.keyspace_missesThe total number of missed lookups in the database.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/redisdb-metrics/"},{"id":754,"title":"Install Falco Rules On-Premises (Legacy)","content":"For airgapped deployments, the instructions vary slightly. See Airgapped Environments.\nDownload the Container ImageSysdig provides a container image on Quay.io to install Falco Rules on the Sysdig Platform. See Falco Rules Installer.\nThis container image allows easy installation and upgrades of the Falco rules files for Sysdig Secure. The file contains the following:\nThe rule files.\nThe latest version of Falco.\nThe sysdig-sdk-python wrappers that deploy the rule files to a Sysdig platform deployment.\nThe image is tagged with new versions as new sets of rules files are released, and the latest tag always points to the latest version.\nWhen a container is run with this image, it does the following:\nValidates the rules.\nFetches the custom rules file and verifies compatibility with the to-be-deployed default Falco rules file.\nDeploys the rules to the configured Sysdig Platform backend component.\nThe Falco Rules Updater can be run from ANY machine on the same network as the backend that has Docker installed. It does not have to be the backend server.\nInstall Falco RulesPrerequisites On-prem version 5.x or earlier Starting from 6.x, the rules installer is included in on-premises installations by default. It checks for rules updates daily and installs the rules automatically, unless disabled.\nNon-Airgapped EnvironmentIf the installation machine has network access to pull the image from the Docker hub:\nDownload the container image:\ndocker pull quay.io/sysdig/falco-rules-installer:latest Use the docker run to install the Falco Rules. For example:\ndocker run --rm --name falco-rules-installer --network host -it -e DEPLOY_HOSTNAME=https://my-sysdig-backend.com -e DEPLOY_USER_NAME=test@sysdig.com -e DEPLOY_USER_PASSWORD=\u0026lt;my password\u0026gt; -e VALIDATE_RULES=yes -e DEPLOY_RULES=yes -e CREATE_NEW_POLICIES=no -e SDC_SSL_VERIFY=True -e ENV_TYPE=onprem quay.io/sysdig/falco-rules-installer:latest Airgapped EnvironmentIf the installation machine does not have the network access to pull the image from the Docker hub:\nDownload the container image on a machine that is connected to the network:\ndocker pull quay.io/sysdig/falco-rules-installer:latest Create an archive file for the image:\ndocker save quay.io/sysdig/falco-rules-installer:latest -o falco-rules-installer.tar Transfer the tar file to the airgapped machine.\nUntar the image file:\ndocker load -i falco-rules-installer.tar It restores both images and tags.\nUse the docker run to install the Falco Rules. For example:\ndocker run --rm --name falco-rules-installer --network host -it -e DEPLOY_HOSTNAME=https://my-sysdig-backend.com -e DEPLOY_USER_NAME=test@sysdig.com -e DEPLOY_USER_PASSWORD=\u0026lt;my password\u0026gt; -e VALIDATE_RULES=yes -e DEPLOY_RULES=yes -e CREATE_NEW_POLICIES=no -e SDC_SSL_VERIFY=True -e ENV_TYPE=onprem sysdig/falco_rules_installer:latest Use Falco RulesYou can run this container from any host with access to the server that hosts the Sysdig backend API endpoint. The hostname is specified in the DEPLOY_HOSTNAME variable. The container doesn\u0026rsquo;t need to run on the hosts where the Sysdig Platform backend components are running.\nThe container depends on the following environment variables to run:\nVariables Description DEPLOY_HOSTNAME The server that hosts the Sysdig API endpoints. The default is https://secure.sysdig.com. ENV_TYPE The environment deploying to. Set to onprem unless deploying to SaaS. DEPLOY_USER_NAME The username for the account that has the admin-level access to the Sysdig API endpoints. The value defaults to a meaningless user, nobody@nobody.com. DEPLOY_USER_PASSWORD The password for the admin user. The value defaults to a meaningless password nopassword. VALIDATE_RULES If set to yes, ensure that the rules file is compatible with your user rules file. Otherwise, skip this validation step. The value defaults to yes. DEPLOY_RULES If set to yes, the falco rules file is deployed. Otherwise, skip deploying the falco rules file. The value defaults to yes. CREATE_NEW_POLICIES If set to yes, will fetch new DEFAULT runtime policies, and restore any missing/deleted DEFAULT runtime policies. This will NOT overwrite any of your existing runtime policies. The value default is no. SDC_SSL_VERIFY If set to false, allow certificate validation failures when deploying the rules. The value defaults to true. SKIP_FALCO_VERSION_0 If set to yes, will not deploy falco rules file version 0, only deploys version 8. (Recommended for on-prem customers with version 5.x). Default value is yes. SKIP_K8_VERSION_2 If set to yes, will not deploy k8 audit rules file version 2, only deploy version 8 (Recommended for on-prem customers with version 5.x. Default value is yes. BEARER_TOKEN If set to the value of the Secure API token for an admin account, will skip logging in and retrieving token through API calls. If not set, will use username and password to retrieve token. Default value is \u0026rsquo;notset'. Learn MoreFor the latest information about the image and usage, see Falco Rules Installer on Quay.io\n","url":"https://docs.sysdig.com/en/sysdig-secure/legacy-install_falco_rules_onprem/"},{"id":755,"title":"MongoDB","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nMongoDB SetupCreate a read-only user for the Sysdig agent.\n# Authenticate as the admin user. use admin db.auth(\u0026#34;admin\u0026#34;, \u0026#34;\u0026lt;YOUR_MONGODB_ADMIN_PASSWORD\u0026gt;\u0026#34;) # On MongoDB 2.x, use the addUser command. db.addUser(\u0026#34;sysdig-cloud\u0026#34;, \u0026#34;sysdig-cloud-password\u0026#34;, true) # On MongoDB 3.x or higher, use the createUser command. db.createUser({ \u0026#34;user\u0026#34;:\u0026#34;sysdig-cloud\u0026#34;, \u0026#34;pwd\u0026#34;: \u0026#34;sysdig-cloud-password\u0026#34;, \u0026#34;roles\u0026#34; : [ {role: \u0026#39;read\u0026#39;, db: \u0026#39;admin\u0026#39; }, {role: \u0026#39;clusterMonitor\u0026#39;, db: \u0026#39;admin\u0026#39;}, {role: \u0026#39;read\u0026#39;, db: \u0026#39;local\u0026#39; } ] }) Sysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with MongoDB.\napp_checks: - name: mongodb check_module: mongo pattern: comm: mongod conf: server: \u0026#34;mongodb://localhost:{port}/admin\u0026#34; The default MongoDB entry should work for without modification if authentication is not configured. If you have enabled password authentication, the entry will need to be changed.\nSome metrics are not available by default. Additional configuration needs to be provided to collect them as shown in following examples.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1: With AuthenticationReplace \u0026lt;username\u0026gt; and \u0026lt;password\u0026gt; with actual username and password.\napp_checks: - name: mongodb check_module: mongo pattern: comm: mongod conf: server: mongodb://\u0026lt;username\u0026gt;:\u0026lt;password\u0026gt;@localhost:{port}/admin replica_check: true Example 2: Additional MetricsSome metrics are not collected by default. These can be collected by adding additional_metrics section in the dragent.yaml file under the app_checks mongodb configuration.\nAvailable options are:\ncollection - Metrics of the specified collections\nmetrics.commands - Use of database commands\ntcmalloc - TCMalloc memory allocator\ntop - Usage statistics for each collection\napp_checks: - name: mongodb check_module: mongo pattern: comm: mongod conf: server: mongodb://\u0026lt;username\u0026gt;:\u0026lt;password\u0026gt;@localhost:{port}/admin replica_check: true additional_metrics: - collection - metrics.commands - tcmalloc - top List of metrics with respective entries in dragent.yaml:\nmetric prefix Entry under additional_metrics mongodb.collection collection mongodb.usage.commands top mongodb.usage.getmore top mongodb.usage.insert top mongodb.usage.queries top mongodb.usage.readLock top mongodb.usage.writeLock top mongodb.usage.remove top mongodb.usage.total top mongodb.usage.update top mongodb.usage.writeLock top mongodb.tcmalloc tcmalloc mongodb.metrics.commands metrics.commands Example 3: Collections MetricsMongoDB stores documents in collections. Collections are analogous to tables in relational databases. The Sysdig agent by default does not collect the following collections metrics:\ncollections: List of MongoDB collections to be polled by the agent. Metrics will be collected for the specified set of collections. This configuration requires the additional_metrics.collection section to be present with an entry for collection in the dragent.yaml file. The collection entry under additional_metrics is a flag that enables the collection metrics.\ncollections_indexes_stats: Collect indexes access metrics for every index in every collection in the collections list. The default value is false.\nThe metric is available starting MongoDB v3.2.\nFor the agent to poll them, you must configure the dragent.yaml file and add an entry corresponding to the metrics to the conf section as follows.\napp_checks: - name: mongodb check_module: mongo pattern: comm: mongod conf: server: mongodb://\u0026lt;username\u0026gt;:\u0026lt;password\u0026gt;@localhost:{port}/admin replica_check: true additional_metrics: - collection - metrics.commands - tcmalloc - top collections: - \u0026lt;LIST_COLLECTIONS\u0026gt; collections_indexes_stats: true Configure SSL for MongoDB App CheckYou can tighten the security measure of the app check connection with MongoDB by establishing an SSL connection. To enable secure communication, you need to set the SSL configuration in dragent.yaml to true. In an advanced deployment with multi-instances of MongoDB, you need to include a custom CA certificate or client certificate and other additional configurations.\nBasic SSL ConnectionIn a basic SSL connection:\nA single MongoDB instance is running on the host.\nAn SSL connection with no advanced features, such as the use of a custom CA certificate or client certificate.\nTo establish a basic SSL connection between the agent and the MongoDB instance:\nOpen the dragent.yaml file.\nConfigure the SSL entries as follows:\napp_checks: - name: mongodb check_module: mongo pattern: comm: mongod conf: server: \u0026#34;mongodb://\u0026lt;HOSTNAME\u0026gt;:{port}/admin\u0026#34; ssl: true # ssl_cert_reqs: 0 # Disable SSL validation To disable SSL validation, set ssl_cert_reqs to 0. This setting is equivalent to ssl_cert_reqs=CERT_NONE.\nAdvanced SSL ConnectionIn an advanced SSL connection:\nAdvanced features, such as custom CA certificate or client certificate, are configured.\nSingle or multi-MongoDB instances are running on the host. The agent is installed as one of the following:\nContainer\nService\nPrerequisitesSet up the following:\nCustom CA certificate\nClient SSL verification\nSSL validation\n(Optional ) SSL Configuration Parameters Parameters\nDescription\nssl_certfile\nThe certificate file that is used to identify the local connection with MongoDB.\nssl_keyfile\nThe private keyfile that is used to identify the local connection with MongoDB. Ignore this option if the key is included with ssl_certfile.\nssl_cert_reqs\nSpecifies whether a certificate is required from the MongoDB server, and whether it will be validated if provided. Possible values are:\n0 for ssl.CERT_NONE. Implies certificates are ignored.\n1 for ssl.CERT_OPTIONAL. Implies certificates are not required, but validated if provided.\n2 for ssl.CERT_REQUIRED. Implies certificates are required and validated.\nssl_ca_certs\nThe ca_certs file contains a set of concatenated certification authority certificates, which are used to validate certificates used by MongoDB server. Mostly used when server certificates are self-signed.\nSysdig Agent as a Container If Sysdig agent is installed as a container, start it with an extra volume containing the SSL files mentioned in the agent configuration. For example:\n# extra parameter added: -v /etc/ssl:/etc/ssl docker run -d --name sysdig-agent --restart always --privileged --net host --pid host -e ACCESS_KEY=xxxxxxxxxxxxx -e SECURE=true -e TAGS=example_tag:example_value -v /var/run/docker.sock:/host/var/run/docker.sock -v /dev:/host/dev -v /proc:/host/proc:ro -v /boot:/host/boot:ro -v /lib/modules:/host/lib/modules:ro -v /usr:/host/usr:ro -v /etc/ssl:/etc/ssl --shm-size=512m sysdig/agent Open the dragent.yaml file and configure the SSL entries:\napp_checks: - name: mongodb check_module: mongo pattern: comm: mongod conf: server: \u0026#34;mongodb://\u0026lt;HOSTNAME\u0026gt;:{port}/admin\u0026#34; ssl: true # ssl_ca_certs: \u0026lt;/path/to/ca/certificate\u0026gt; # ssl_cert_reqs: 0 # Disable SSL validation # ssl_certfile: \u0026lt;/path/to/client/certfile\u0026gt; # ssl_keyfile: \u0026lt;/path/to/client/keyfile\u0026gt; Sysdig Agent as a Process If Sysdig agent is installed as a process, store the SSL files on the host and provide the path in the agent configuration.\napp_checks: - name: mongodb check_module: mongo pattern: comm: mongod conf: server: \u0026#34;mongodb://\u0026lt;HOSTNAME\u0026gt;:{port}/admin\u0026#34; ssl: true # ssl_ca_certs: \u0026lt;/path/to/ca/certificate\u0026gt; # ssl_cert_reqs: 0 # Disable SSL validation # ssl_certfile: \u0026lt;/path/to/client/certfile\u0026gt; # ssl_keyfile: \u0026lt;/path/to/client/keyfile\u0026gt; See [optional SSL configuration parameters](/en/integrate-applications-default-app-checks/ for information on SSL certificate files.\nMulti-MongoDB SetupIn a multi-MongoDB setup, multiple MongoDB instances are running on a single host. You can configure either a basic or an advanced SSL connection individually for each MongoDB instance.\nStore SSL FilesIn an advanced connection, different SSL certificates are used for each instance of MongoDB on the same host and are stored in separate directories. For instance, the SSL files corresponding to two different MongoDB instances can be stored at a mount point as follows:\nMount point is /etc/ssl/\nFiles for instance 1 are stored in /etc/ssl/mongo1/\nFiles for instance 2 are stored in /etc/ssl/mongo2/\nConfigure the Agent Open the dragent.yaml file.\nConfigure the SSL entries as follows:\napp_checks: - name: mongodb-ssl-1 check_module: mongo pattern: comm: mongod args: ssl_certificate-1.pem conf: server: \u0026#34;mongodb://\u0026lt;HOSTNAME|Certificate_CN\u0026gt;:{port}/admin\u0026#34; ssl: true ssl_ca_certs: /etc/ssl/mongo1/ca-cert-1 tags: - \u0026#34;instance:ssl-1\u0026#34; - name: mongodb-ssl-2 check_module: mongo pattern: comm: mongod args: ssl_certificate-2.pem conf: server: \u0026#34;mongodb://\u0026lt;HOSTNAME|Certificate_CN\u0026gt;:{port}/admin\u0026#34; ssl: true ssl_ca_certs: /etc/ssl/mongo2/ca-cert-2 tags: - \u0026#34;instance:ssl-2\u0026#34; Replace the names of the instances and certificate files with the names that you prefer.\nMetrics AvailableSee MongoDB Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/mongodb/"},{"id":756,"title":"MongoDB Metrics","content":"See Application Integrations for more information.\nMetrics Introduced with Agent v9.7.0The following metrics are supported by Sysdig Agent v9.7.0 and above.\nMetric Name Description mongodb.tcmalloc.generic.current_allocated_bytes The number of bytes used by the application. mongodb.tcmalloc.generic.heap_size Bytes of system memory reserved by TCMalloc. mongodb.tcmalloc.tcmalloc.aggressive_memory_decommit Status of aggressive memory de-commit mode. mongodb.tcmalloc.tcmalloc.central_cache_free_bytes The number of free bytes in the central cache. mongodb.tcmalloc.tcmalloc.current_total_thread_cache_bytes The number of bytes used across all thread caches. mongodb.tcmalloc.tcmalloc.max_total_thread_cache_bytes The upper limit on the total number of bytes stored across all per-thread caches. mongodb.tcmalloc.tcmalloc.pageheap_free_bytes The number of bytes in free mapped pages in page heap. mongodb.tcmalloc.tcmalloc.pageheap_unmapped_bytes The number of bytes in free unmapped pages in page heap. mongodb.tcmalloc.tcmalloc.spinlock_total_delay_ns Gives the spinlock delay time. mongodb.tcmalloc.tcmalloc.thread_cache_free_bytes The number of free bytes in thread caches. mongodb.tcmalloc.tcmalloc.transfer_cache_free_bytes The number of free bytes that are waiting to be transferred between the central cache and a thread cache. mongodb.asserts.msgpsNumber of message assertions raised per second.\nmongodb.asserts.regularpsNumber of regular assertions raised per second.\nmongodb.asserts.rolloverspsNumber of times that the rollover counters roll over per second. The counters rollover to zero every 2^30 assertions.\nmongodb.asserts.userpsNumber of user assertions raised per second.\nmongodb.asserts.warningpsNumber of warnings raised per second.\nmongodb.backgroundflushing.average_msAverage time for each flush to disk.\nmongodb.backgroundflushing.flushespsNumber of times the database has flushed all writes to disk.\nmongodb.backgroundflushing.last_msAmount of time that the last flush operation took to complete.\nmongodb.backgroundflushing.total_msTotal number of time that the `mongod` processes have spent writing (i.e. flushing) data to disk.\nmongodb.connections.availableNumber of unused available incoming connections the database can provide.\nmongodb.connections.currentNumber of connections to the database server from clients.\nmongodb.connections.totalcreatedTotal number of connections created.\nmongodb.cursors.timedoutTotal number of cursors that have timed out since the server process started.\nmongodb.cursors.totalopenNumber of cursors that MongoDB is maintaining for clients\nmongodb.dbsTotal number of existing databases\nmongodb.dur.commitsNumber of transactions written to the journal during the last journal group commit interval.\nmongodb.dur.commitsinwritelockCount of the commits that occurred while a write lock was held.\nmongodb.dur.compressionCompression ratio of the data written to the journal.\nmongodb.dur.earlycommitsNumber of times MongoDB requested a commit before the scheduled journal group commit interval.\nmongodb.dur.journaledmbAmount of data written to journal during the last journal group commit interval.\nmongodb.dur.timems.commitsAmount of time spent for commits.\nmongodb.dur.timems.commitsinwritelockAmount of time spent for commits that occurred while a write lock was held.\nmongodb.dur.timems.dtAmount of time over which MongoDB collected the `dur.timeMS` data.\nmongodb.dur.timems.preplogbufferAmount of time spent preparing to write to the journal.\nmongodb.dur.timems.remapprivateviewAmount of time spent remapping copy-on-write memory mapped views.\nmongodb.dur.timems.writetodatafilesAmount of time spent writing to data files after journaling.\nmongodb.dur.timems.writetojournalAmount of time spent writing to the journal\nmongodb.dur.writetodatafilesmbAmount of data written from journal to the data files during the last journal group commit interval.\nmongodb.extra_info.page_faultspsNumber of page faults per second that require disk operations.\nmongodb.fsynclockedNumber of fsynclocked performed on a mongo instance.\nmongodb.globallock.activeclients.readersCount of the active client connections performing read operations.\nmongodb.globallock.activeclients.totalTotal number of active client connections to the database.\nmongodb.globallock.activeclients.writersCount of active client connections performing write operations.\nmongodb.globallock.currentqueue.readersNumber of operations that are currently queued and waiting for the read lock.\nmongodb.globallock.currentqueue.totalTotal number of operations queued waiting for the lock.\nmongodb.globallock.currentqueue.writersNumber of operations that are currently queued and waiting for the write lock.\nmongodb.globallock.locktimeTime since the database last started that the globalLock has been held.\nmongodb.globallock.ratioRatio of the time that the globalLock has been held to the total time since it was created.\nmongodb.globallock.totaltimeTime since the database last started and created the global lock.\nmongodb.indexcounters.accessespsNumber of times that operations have accessed indexes per second.\nmongodb.indexcounters.hitspsNumber of times per second that an index has been accessed and mongod is able to return the index from memory.\nmongodb.indexcounters.missespsNumber of times per second that an operation attempted to access an index that was not in memory.\nmongodb.indexcounters.missratioRatio of index hits to misses.\nmongodb.indexcounters.resetspsNumber of times per second the index counters have been reset.\nmongodb.locks.collection.acquirecount.exclusivepsNumber of times the collection lock type was acquired in the Exclusive (X) mode.\nmongodb.locks.collection.acquirecount.intent_exclusivepsNumber of times the collection lock type was acquired in the Intent Exclusive (IX) mode.\nmongodb.locks.collection.acquirecount.intent_sharedpsNumber of times the collection lock type was acquired in the Intent Shared (IS) mode.\nmongodb.locks.collection.acquirecount.sharedpsNumber of times the collection lock type was acquired in the Shared (S) mode.\nmongodb.locks.collection.acquirewaitcount.exclusivepsNumber of times the collection lock type acquisition in the Exclusive (X) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.collection.acquirewaitcount.sharedpsNumber of times the collection lock type acquisition in the Shared (S) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.collection.timeacquiringmicros.exclusivepsWait time for the collection lock type acquisitions in the Exclusive (X) mode.\nmongodb.locks.collection.timeacquiringmicros.sharedpsWait time for the collection lock type acquisitions in the Shared (S) mode.\nmongodb.locks.database.acquirecount.exclusivepsNumber of times the database lock type was acquired in the Exclusive (X) mode.\nmongodb.locks.database.acquirecount.intent_exclusivepsNumber of times the database lock type was acquired in the Intent Exclusive (IX) mode.\nmongodb.locks.database.acquirecount.intent_sharedpsNumber of times the database lock type was acquired in the Intent Shared (IS) mode.\nmongodb.locks.database.acquirecount.sharedpsNumber of times the database lock type was acquired in the Shared (S) mode.\nmongodb.locks.database.acquirewaitcount.exclusivepsNumber of times the database lock type acquisition in the Exclusive (X) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.database.acquirewaitcount.intent_exclusivepsNumber of times the database lock type acquisition in the Intent Exclusive (IX) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.database.acquirewaitcount.intent_sharedpsNumber of times the database lock type acquisition in the Intent Shared (IS) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.database.acquirewaitcount.sharedpsNumber of times the database lock type acquisition in the Shared (S) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.database.timeacquiringmicros.exclusivepsWait time for the database lock type acquisitions in the Exclusive (X) mode.\nmongodb.locks.database.timeacquiringmicros.intent_exclusivepsWait time for the database lock type acquisitions in the Intent Exclusive (IX) mode.\nmongodb.locks.database.timeacquiringmicros.intent_sharedpsWait time for the database lock type acquisitions in the Intent Shared (IS) mode.\nmongodb.locks.database.timeacquiringmicros.sharedpsWait time for the database lock type acquisitions in the Shared (S) mode.\nmongodb.locks.global.acquirecount.exclusivepsNumber of times the global lock type was acquired in the Exclusive (X) mode.\nmongodb.locks.global.acquirecount.intent_exclusivepsNumber of times the global lock type was acquired in the Intent Exclusive (IX) mode.\nmongodb.locks.global.acquirecount.intent_sharedpsNumber of times the global lock type was acquired in the Intent Shared (IS) mode.\nmongodb.locks.global.acquirecount.sharedpsNumber of times the global lock type was acquired in the Shared (S) mode.\nmongodb.locks.global.acquirewaitcount.exclusivepsNumber of times the global lock type acquisition in the Exclusive (X) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.global.acquirewaitcount.intent_exclusivepsNumber of times the global lock type acquisition in the Intent Exclusive (IX) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.global.acquirewaitcount.intent_sharedpsNumber of times the global lock type acquisition in the Intent Shared (IS) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.global.acquirewaitcount.sharedpsNumber of times the global lock type acquisition in the Shared (S) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.global.timeacquiringmicros.exclusivepsWait time for the global lock type acquisitions in the Exclusive (X) mode.\nmongodb.locks.global.timeacquiringmicros.intent_exclusivepsWait time for the global lock type acquisitions in the Intent Exclusive (IX) mode.\nmongodb.locks.global.timeacquiringmicros.intent_sharedpsWait time for the global lock type acquisitions in the Intent Shared (IS) mode.\nmongodb.locks.global.timeacquiringmicros.sharedpsWait time for the global lock type acquisitions in the Shared (S) mode.\nmongodb.locks.metadata.acquirecount.exclusivepsNumber of times the metadata lock type was acquired in the Exclusive (X) mode.\nmongodb.locks.metadata.acquirecount.sharedpsNumber of times the metadata lock type was acquired in the Shared (S) mode.\nmongodb.locks.mmapv1journal.acquirecount.intent_exclusivepsNumber of times the MMAPv1 storage engine lock type was acquired in the Intent Exclusive (IX) mode.\nmongodb.locks.mmapv1journal.acquirecount.intent_sharedpsNumber of times the MMAPv1 storage engine lock type was acquired in the Intent Shared (IS) mode.\nmongodb.locks.mmapv1journal.acquirewaitcount.intent_exclusivepsNumber of times the MMAPv1 storage engine lock type acquisition in the Intent Exclusive (IX) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.mmapv1journal.acquirewaitcount.intent_sharedpsNumber of times the MMAPv1 storage engine lock type acquisition in the Intent Shared (IS) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.mmapv1journal.timeacquiringmicros.intent_exclusivepsWait time for the MMAPv1 storage engine lock type acquisitions in the Intent Exclusive (IX) mode.\nmongodb.locks.mmapv1journal.timeacquiringmicros.intent_sharedpsWait time for the MMAPv1 storage engine lock type acquisitions in the Intent Shared (IS) mode.\nmongodb.locks.oplog.acquirecount.intent_exclusivepsNumber of times the oplog lock type was acquired in the Intent Exclusive (IX) mode.\nmongodb.locks.oplog.acquirecount.sharedpsNumber of times the oplog lock type was acquired in the Shared (S) mode.\nmongodb.locks.oplog.acquirewaitcount.intent_exclusivepsNumber of times the oplog lock type acquisition in the Intent Exclusive (IX) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.oplog.acquirewaitcount.sharedpsNumber of times the oplog lock type acquisition in the Shared (S) mode encountered waits because the locks were held in a conflicting mode.\nmongodb.locks.oplog.timeacquiringmicros.intent_exclusivepsWait time for the oplog lock type acquisitions in the Intent Exclusive (IX) mode.\nmongodb.locks.oplog.timeacquiringmicros.sharedpsWait time for the oplog lock type acquisitions in the Shared (S) mode.\nmongodb.mem.bitsSize of the in-memory storage engine.\nmongodb.mem.mappedAmount of mapped memory by the database.\nmongodb.mem.mappedwithjournalThe amount of mapped memory, including the memory used for journaling.\nmongodb.mem.residentAmount of memory currently used by the database process.\nmongodb.mem.virtualAmount of virtual memory used by the mongod process.\nmongodb.metrics.commands.count.failedNumber of times count failed\nmongodb.metrics.commands.count.totalNumber of times count executed\nmongodb.metrics.commands.createIndexes.failedNumber of times createIndexes failed\nmongodb.metrics.commands.createIndexes.totalNumber of times createIndexes executed\nmongodb.metrics.commands.delete.failedNumber of times delete failed\nmongodb.metrics.commands.delete.totalNumber of times delete executed\nmongodb.metrics.commands.eval.failedNumber of times eval failed\nmongodb.metrics.commands.eval.totalNumber of times eval executed\nmongodb.metrics.commands.findAndModify.failedNumber of times findAndModify failed\nmongodb.metrics.commands.findAndModify.totalNumber of times findAndModify executed\nmongodb.metrics.commands.insert.failedNumber of times insert failed\nmongodb.metrics.commands.insert.totalNumber of times insert executed\nmongodb.metrics.commands.update.failedNumber of times update failed\nmongodb.metrics.commands.update.totalNumber of times update executed\nmongodb.metrics.cursor.open.notimeoutNumber of open cursors with the option `DBQuery.Option.noTimeout` set to prevent timeout after a period of inactivity.\nmongodb.metrics.cursor.open.pinnedNumber of pinned open cursors.\nmongodb.metrics.cursor.open.totalNumber of cursors that MongoDB is maintaining for clients.\nmongodb.metrics.cursor.timedoutpsNumber of cursors that time out, per second.\nmongodb.metrics.document.deletedpsNumber of documents deleted per second.\nmongodb.metrics.document.insertedpsNumber of documents inserted per second.\nmongodb.metrics.document.returnedpsNumber of documents returned by queries per second.\nmongodb.metrics.document.updatedpsNumber of documents updated per second.\nmongodb.metrics.getlasterror.wtime.numpsNumber of getLastError operations per second with a specified write concern (i.e. w) that wait for one or more members of a replica set to acknowledge the write operation.\nmongodb.metrics.getlasterror.wtime.totalmillispsFraction of time (ms/s) that the mongod has spent performing getLastError operations with write concern (i.e. w) that wait for one or more members of a replica set to acknowledge the write operation.\nmongodb.metrics.getlasterror.wtimeoutspsNumber of times per second that write concern operations have timed out as a result of the wtimeout threshold to getLastError\nmongodb.metrics.operation.fastmodpsNumber of update operations per second that neither cause documents to grow nor require updates to the index.\nmongodb.metrics.operation.idhackpsNumber of queries per second that contain the _id field.\nmongodb.metrics.operation.writeconflictspsNumber of times per second that write concern operations has encounter a conflict.\nmongodb.metrics.operation.scanandorderpsNumber of queries per second that return sorted numbers that cannot perform the sort operation using an index.\nmongodb.metrics.queryexecutor.scannedpsNumber of index items scanned per second during queries and query-plan evaluation.\nmongodb.metrics.record.movespsNumber of times per second documents move within the on-disk representation of the MongoDB data set.\nmongodb.metrics.repl.apply.batches.numpsNumber of batches applied across all databases per second.\nmongodb.metrics.repl.apply.batches.totalmillispsFraction of time (ms/s) the mongod has spent applying operations from the oplog.\nmongodb.metrics.repl.apply.opspsNumber of oplog operations applied per second.\nmongodb.metrics.repl.buffer.countNumber of operations in the oplog buffer.\nmongodb.metrics.repl.buffer.maxsizebytesMaximum size of the buffer.\nmongodb.metrics.repl.buffer.sizebytesCurrent size of the contents of the oplog buffer.\nmongodb.metrics.repl.network.bytespsAmount of data read from the replication sync source per second.\nmongodb.metrics.repl.network.getmores.numpsNumber of getmore operations per second.\nmongodb.metrics.repl.network.getmores.totalmillispsFraction of time (ms/s) required to collect data from getmore operations.\nmongodb.metrics.repl.network.opspsNumber of operations read from the replication source per second.\nmongodb.metrics.repl.network.readerscreatedpsNumber of oplog query processes created per second.\nmongodb.metrics.repl.preload.docs.numpsNumber of documents loaded during the pre-fetch stage of replication.\nmongodb.metrics.repl.preload.docs.totalmillispsAmount of time spent loading documents as part of the pre-fetch stage of replication.\nmongodb.metrics.repl.preload.indexes.numpsNumber of index entries loaded by members before updating documents as part of the pre-fetch stage of replication.\nmongodb.metrics.repl.preload.indexes.totalmillispsAmount of time spent loading documents as part of the pre-fetch stage of replication.\nmongodb.metrics.ttl.deleteddocumentspsNumber of documents deleted from collections with a ttl index per second.\nmongodb.metrics.ttl.passespsNumber of times per second the background process removes documents from collections with a ttl index.\nmongodb.network.bytesinpsThe number of bytes that reflects the amount of network traffic received by this database.\nmongodb.network.bytesoutpsThe number of bytes that reflects the amount of network traffic sent from this database.\nmongodb.network.numrequestspsNumber of distinct requests that the server has received.\nmongodb.opcounters.commandpsTotal number of commands per second issued to the database.\nmongodb.opcounters.deletepsNumber of delete operations per second.\nmongodb.opcounters.getmorepsNumber of getmore operations per second.\nmongodb.opcounters.insertpsNumber of insert operations per second.\nmongodb.opcounters.querypsTotal number of queries per second.\nmongodb.opcounters.updatepsNumber of update operations per second.\nmongodb.opcountersrepl.commandpsTotal number of replicated commands issued to the database per second.\nmongodb.opcountersrepl.deletepsNumber of replicated delete operations per second.\nmongodb.opcountersrepl.getmorepsNumber of replicated getmore operations per second.\nmongodb.opcountersrepl.insertpsNumber of replicated insert operations per second.\nmongodb.opcountersrepl.querypsTotal number of replicated queries per second.\nmongodb.opcountersrepl.updatepsNumber of replicated update operations per second.\nmongodb.oplog.logsizembTotal size of the oplog.\nmongodb.oplog.timediffOplog window: difference between the first and last operation in the oplog.\nmongodb.oplog.usedsizembTotal amount of space used by the oplog.\nmongodb.replset.healthMember health value of the replica set: conveys if the member is up (i.e. 1) or down (i.e. 0).\nmongodb.replset.replicationlagDelay between a write operation on the primary and its copy to a secondary.\nmongodb.replset.stateState of a replica that reflects its disposition within the set.\nmongodb.replset.votefractionFraction of votes a server will cast in a replica set election.\nmongodb.replset.votesThe number of votes a server will cast in a replica set election.\nmongodb.stats.datasizeTotal size of the data held in this database including the padding factor.\nmongodb.stats.indexesTotal number of indexes across all collections in the database.\nmongodb.stats.indexsizeTotal size of all indexes created on this database.\nmongodb.stats.objectsNumber of objects (documents) in the database across all collections.\nmongodb.stats.storagesizeTotal amount of space allocated to collections in this database for document storage.\nmongodb.uptimeNumber of seconds that the mongos or mongod process has been active.\nmongodb.wiredtiger.cache.bytes_currently_in_cacheSize of the data currently in cache.\nmongodb.wiredtiger.cache.failed_eviction_of_pages_exceeding_the_in_memory_maximumpsNumber of failed eviction of pages that exceeded the in-memory maximum, per second.\nmongodb.wiredtiger.cache.in_memory_page_splitsIn-memory page splits.\nmongodb.wiredtiger.cache.maximum_bytes_configuredMaximum cache size.\nmongodb.wiredtiger.cache.maximum_page_size_at_evictionMaximum page size at eviction.\nmongodb.wiredtiger.cache.modified_pages_evictedNumber of pages, that have been modified, evicted from the cache.\nmongodb.wiredtiger.cache.pages_currently_held_in_cacheNumber of pages currently held in the cache.\nmongodb.wiredtiger.cache.pages_evicted_by_application_threadspsNumber of page evicted by application threads per second.\nmongodb.wiredtiger.cache.pages_evicted_exceeding_the_in_memory_maximumpsNumber of pages evicted because they exceeded the cache in-memory maximum, per second.\nmongodb.wiredtiger.cache.tracked_dirty_bytes_in_cacheSize of the dirty data in the cache.\nmongodb.wiredtiger.cache.unmodified_pages_evictedNumber of pages, that were not modified, evicted from the cache.\nmongodb.wiredtiger.concurrenttransactions.read.availableNumber of available read tickets (concurrent transactions) remaining.\nmongodb.wiredtiger.concurrenttransactions.read.outNumber of read tickets (concurrent transactions) in use.\nmongodb.wiredtiger.concurrenttransactions.read.totalticketsTotal number of read tickets (concurrent transactions) available.\nmongodb.wiredtiger.concurrenttransactions.write.availableNumber of available write tickets (concurrent transactions) remaining.\nmongodb.wiredtiger.concurrenttransactions.write.outNumber of write tickets (concurrent transactions) in use.\nmongodb.wiredtiger.concurrenttransactions.write.totalticketsTotal number of write tickets (concurrent transactions) available.\nmongodb.collection.sizeThe total size in bytes of the data in the collection plus the size of every indexes on the mongodb.collection.\nmongodb.collection.avgObjSizeThe size of the average object in the collection in bytes.\nmongodb.collection.countTotal number of objects in the collection.\nmongodb.collection.cappedWhether or not the collection is capped.\nmongodb.collection.maxMaximum number of documents in a capped collection.\nmongodb.collection.maxSizeMaximum size of a capped collection in bytes.\nmongodb.collection.storageSizeTotal storage space allocated to this collection for document storage.\nmongodb.collection.nindexesTotal number of indices on the collection.\nmongodb.collection.indexSizesSize of index in bytes.\nmongodb.collection.indexes.accesses.opsNumber of time the index was used.\nmongodb.usage.commands.countpsNumber of commands per second\nmongodb.usage.commands.countNumber of commands since server start (deprecated)\nmongodb.usage.commands.timeTotal time spent performing commands in microseconds\nmongodb.usage.getmore.countpsNumber of getmore per second\nmongodb.usage.getmore.countNumber of getmore since server start (deprecated)\nmongodb.usage.getmore.timeTotal time spent performing getmore in microseconds\nmongodb.usage.insert.countpsNumber of inserts per second\nmongodb.usage.insert.countNumber of inserts since server start (deprecated)\nmongodb.usage.insert.timeTotal time spent performing inserts in microseconds\nmongodb.usage.queries.countpsNumber of queries per second\nmongodb.usage.queries.countNumber of queries since server start (deprecated)\nmongodb.usage.queries.timeTotal time spent performing queries in microseconds\nmongodb.usage.readLock.countpsNumber of read locks per second\nmongodb.usage.readLock.countNumber of read locks since server start (deprecated)\nmongodb.usage.readLock.timeTotal time spent performing read locks in microseconds\nmongodb.usage.remove.countpsNumber of removes per second\nmongodb.usage.remove.countNumber of removes since server start (deprecated)\nmongodb.usage.remove.timeTotal time spent performing removes in microseconds\nmongodb.usage.total.countpsNumber of operations per second\nmongodb.usage.total.countNumber of operations since server start (deprecated)\nmongodb.usage.total.timeTotal time spent performing operations in microseconds\nmongodb.usage.update.countpsNumber of updates per second\nmongodb.usage.update.countNumber of updates since server start (deprecated)\nmongodb.usage.update.timeTotal time spent performing updates in microseconds\nmongodb.usage.writeLock.countpsNumber of write locks per second\nmongodb.usage.writeLock.countNumber of write locks since server start (deprecated)\nmongodb.usage.writeLock.timeTotal time spent performing write locks in microseconds\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/mongodb-metrics/"},{"id":757,"title":"Security Policy Metrics","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nMetrics\nDescription\nType\nSegmented by\nMinimum Agent Version\nsecurity.evts.k8s_audit The total number of policy events from a Kubernetes audit policy.\nGauge\nhost.mac\nhost.hostname\n0.86.0\nsecurity.policy_evts.syscall\nThe total number of policy events from a syscall policy.\nsecurity.policies.enabled\nThe number of security policies enabled for a user.\nsecurity.policies.total\nThe number of security policies that exist for a user.\nsecurity.policy_evts.container\nThe total number of policy events from a container policy.\nsecurity.policy_evts.falco\nThe total number of policy events from a Falco policy.\nsecurity.policy_evts.filesystem\nThe total number of policy events from a filesystem policy.\nsecurity.policy_evts.high\nThe number of policy events from a policy with high severity.\nsecurity.policy_evts.low\nThe number of policy events from a policy with low severity.\nsecurity.policy_evts.medium\nThe number of policy events from a policy with medium severity.\nsecurity.policy_evts.network\nThe total number of policy events from a network policy.\nsecurity.policy_evts.process\nThe total number of policy events from a process policy.\nsecurity.policy_evts.total\nThe total number of policy events across all policy types.\nsecurity_policy_evts.by_name\nThe number of events triggered with segment name available.\nname\nhost.mac\nhost.hostname\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/security-policy-metrics/"},{"id":758,"title":"Windows Workload Policy","content":"Whereas Linux Workload Policies are designed for Linux, Windows Workload Policies are designed for workloads running on Windows.\nThe Windows Workload policy comes pre-installed in Sysdig Secure. As it is a managed policy, you cannot create new instances of the policy. To read about the differences between managed and custom policies, see Types of Threat Detection Policies.\nFalco rule exceptions are supported out of the box.\nEvent notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nEnable or Disable a Windows Workload PolicyTo enable or disable a Windows Workload Policy:\nLog in to Sysdig Secure.\nSelect Policies \u0026gt; Runtime Policies from the left navigation bar.\nThe Runtime Policies page appears.\nLocate a Windows Workload policy by selecting Windows Workload from the Select policy type drop-down.\nUse the toggle on the left to enable or disable the policy.\nConfigure a Windows Workload PolicyTo configure a Windows Workload Managed Policy:\nLog in to Sysdig Secure.\nSelect Policies \u0026gt; Runtime Policies.\nThe Runtime Policies page appears.\nLocate a Windows Workload policy by selecting Windows Workload from the Select policy type drop-down.\nSelect the edit (pencil) icon on a policy listing, or select the policy to open the detail pane, and then select the edit icon.\nThe Policy Detail page appears. Here you can configure the following:\nEnabled: Use the toggle to enable or disable the managed policy.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy Rules: Use the toggles to disable or enable individual rules. You cannot delete rules, or add additional rules to managed policies. Select a rule to open the detail panel. Here, you can select the edit icon to edit the rule.\nNotify: Select a notification channel to receive alerts when the policy triggers and generates an event. See Set Up Notification Channels.\n","url":"https://docs.sysdig.com/en/sysdig-secure/windows_policy/"},{"id":759,"title":"Monitor SaaS Release Notes 2020","content":"December 16, 2020Statement RE: Solarwinds and Sysdig\u0026rsquo;s SecurityWe have seen requests for statements regarding tooling in the wake of the Solarwinds and related compromises. Sysdig does not use these tools internally. To maintain a secure SDLC process for own product we use Sysdig Secure as well as source code analysis tools. We also maintain our own branch of key OSS components to ensure software is fully vetted before it\u0026rsquo;s delivered to customers.\nNovember 19, 2020Explore Workflow EnhancementsThe Explore interface has been improved to allow faster troubleshooting.\nYou are now launched directly into the drill-down view when you navigate to Explore. You will still be able to group and navigate your infrastructure by using the hierarchical scope tree.\nThe new Grouping editor helps you create and manage your infrastructure groupings.\nFor more information, see Explore.\nTransfer Dashboard OwnershipAdministrators have now the ability to transfer dashboard ownership to another user. For more information, see Transfer Dashboard Ownership.\nEnhancements for Navigating DashboardsYou can now pin the dashboard menu to the sidebar in the Sysdig Monitor UI. Pinning makes it easier to navigate and browse different Dashboards. In addition, the Dashboard interface has been enhanced to retain your preference for open or closed categories to help you locate the desired items faster.\nOctober 22, 2020Visualizing Missing Data on DashboardsDashboards now show null or missing data values as gaps instead of zero. Optionally, missing data can be displayed as a dotted or solid line in both Form-based and PromQL panels. StatsD metrics will continue to show null values as zero unless overridden by the settings.\nTime Navigation in Events FeedYou can now browse and find historic events easily by using time navigation.\nZooming Out DashboardsYou now have the ability to zoom out Dashboards. This feature doubles the selected timeframe by 2x for a better context surrounding a problem when troubleshooting an incident.\nJuly 27, 2020Sysdig EssentialsWe have introduced a new product tier, Sysdig Essentials. This tier includes everything required to achieve the five essential requirements for practicing Secure DevOps:\nImage Scanning\nRuntime Security\nCompliance\nKubernetes and container monitoring\nApplication and cloud service monitoring\nTo learn more about Essentials, register for our webinar, Deploy Faster by Automating Container Security, Monitoring and Compliance.\nWith the introduction of Essentials, It\u0026rsquo;s also easier to get started with a trial program and manage your Sysdig subscription.\nLearn the difference between Essentials and Enterprise, including pricing and features, at Pricing.\nRebranded Login PageThe login page has been updated with the Sysdig Kraken and the new logo.\nSysdig Monitor EnhancementsHosts OverviewTo complement Sysdig Kubernetes Overviews, Hosts Overview has been released. Host Overview provides a unified view of the performance and health of physical hosts in your infrastructure.\nNew and Improved Empty StatesA number of different splash screens have been introduced to guide you through getting up and running with features across the application.\nSysdig Platform EnhancementsSAML Single Sign-OnThe initial email to the following types of users will take them directly to the Single-Sign-On URL, and not the registration page.\nSAML SSO Users\nThe users that are invited to the platform (as opposed to having them automatically created via Sysdig on-demand provisioning for SSO)\nEarlier, landing on the registration page was confusing to users because they had to set up their initial password.\nJune 17, 2020This 3.2.6 release focuses on the general availability of New Dashboard with a rich set of features and enhancements. Learn more about the release from the blog post, New and improved dashboards .\nNew Dashboards is GASysdig Monitor offers a new version of dashboards. Its improved editing experience provides you with more flexibility and the new set of functionalities offers additional ways to visualize and consume your Sysdig data.\nFeatures and EnhancementsImproved User ExperienceThe New Dashboard offers a more fluid, natural dashboard building experience. The UI has been redesigned to introduce two types of panels—form-based and PromQL-based— to make visualizing your metrics effortless. Use a PromQL-based panel to build dashboards for Prometheus raw metrics and custom metrics. The form-based panel for legacy queries.\nDashboard SharingYou can now share your dashboard with members within your Sysdig team or share it across teams with fine-grained access controls. Define who should be able to see the dashboards and what level of access they should be granted: view only or collaborator with edit privileges.\nTime Series Name TemplatingCustomize the time series names on the legend on the panel editor by using the labels associated with Prometheus metrics and segments to gain context faster.\nMulti-Metric, Multi-Segmentation OptionsConfigure multiple queries within a single panel, and configure each query with multiple segmentation and scoping options. Individual queries can be customized to render as a line or stacked area. For more information, see Using PromQL.\nEvent OverlayContextualize metrics and understand the \u0026ldquo;why\u0026rdquo; faster with a unified view of both metrics and events. Configure event overlay to display events from Kubernetes environments as well as alert events, and any other events ingested using Sysdig\u0026rsquo;s open REST API. For more information.\nDashboard TemplatesYou can quickly view your infrastructure through the lens of one of Sysdig\u0026rsquo;s curated dashboards, or use it as a base to start building your own. You can find dashboard templates for managing Kubernetes capacity and health, hosts and server performance, applications and services telemetry, and the security posture of your infrastructure with data fed from Sysdig Secure. See Dashboard Templates to learn more.\nMapping Values to TextInstantly understand what\u0026rsquo;s going on by mapping number panel values to text. If you have a metric that returns 1 for up, and 0 for down, map those values to \u0026ldquo;UP\u0026rdquo; and \u0026ldquo;DOWN\u0026rdquo; respectively. By defining thresholds and mapping to text, you don\u0026rsquo;t need to be concerned about the values. This is critically valuable when dashboards are shared between team members. For more information, see Text.\nGranular Axes and Legend ControlsYou have more flexibility when customizing the axes, as well as better support for time series with long names. You can now configure the legend by toggling its visibility and moving it to the bottom of the panel.\nMajor ChangesSignificant changes have been introduced to enhance the usability of the existing functionalities. Review the changes before you explore the functionalities.\nTopology MapsTopology maps are no longer available in Dashboard. Access Topology maps through Explore, as you explore your microservices and Kubernetes applications.\nDashboard WizardMy Dashboards are no longer accessible in Explore. Additionally, Dashboard Wizard has been removed. Instead, the concept of Templates has been introduced in Dashboards to help you get started with a library of templates addressing key use cases.\nHistogram and Summary Metric TypeHistogram and summary metrics are no longer supported in the Histogram panel type. You can continue to use them within Explore. If you have enabled PromQL, we encourage you to use Prometheus functions for visualizing histograms.\nUse the new Prometheus histograms with the histogram_quantile metrics on a time-series graph.\nAPIs and IntegrationsAPI endpoints for the legacy dashboards (v2) will soon be deprecated. If you are directly integrating into the API, please contact Sysdig for guidance. Additionally, our Python SDK and CLI have been updated to support the new dashboards APIs.\nPromQL SupportPromQL support for querying Prometheus metrics has been rolled out to a subset of Sysdig Monitor users. See Using PromQL.\nIntelligent $__intervalUse $__interval within a PromQL query and Sysdig will intelligently use the most appropriate sampling depending on the time range you have selected. This configuration ensures that we balance providing access to the most granular data available while downsampling when you select a long time range to panels load as fast as possible.\nScope variablesConfigure scope variables at the dashboard level to quickly filter metrics based on cluster, namespace, workload, and more. When using PromQL queries, the scope can be injected by using dynamic variables. This configuration is significant when troubleshooting as it allows you to switch context quickly without reconfiguring queries.\nSmart Autocompletion and Syntax HighlightingAutocomplete suggests metrics, operators, and functions, while syntax highlighting helps keep you on the right path and helps highlight problems within a PromQL query. This is invaluable in dynamic environments and allows you to craft the right queries faster.\nConfigurable Default Team RoleYou can now define the default user role to apply when a new member is added to the team. The Admin can change this default on a per-team basis. See also: Create a Team.\nRBAC and Team Assignment for Notification ChannelsPreviously, notification channels in Sysdig Secure and Monitor were treated as global entities, visible and editable for most users of the platform regardless of team configurations.\nWe are enhancing the management and RBAC controls in the following ways:\nNotification channels can now be \u0026ldquo;global\u0026rdquo; or limited to a particular team\nGlobal channels can be managed by admins and can be viewed/used by other roles, while team-limited channels are available only to team members\nTeam Manager , Advanced User, and Service Manager (Secure) roles can create/update/delete team-scoped notification channels, they can also read and use the global ones\nStandard and View Only roles can read team-limited and global notification channels\nAdmins will be able to create global notification channels and migrate channels from \u0026ldquo;global\u0026rdquo; to \u0026ldquo;team-limited\u0026rdquo;, and also from one team to another.\nSee also: Set Up Notification Channels and the Share With field in each individual channel setting page.\nMay 15, 2020The New Get Started PageThe Get Started page provides the key steps to ensure that you are getting the most value out of Sysdig Monitor. We\u0026rsquo;ll update this page with new steps as we add new features to Sysdig Monitor.\nThe Get Started page also serves as a linking page for:\nDocumentation\nRelease Notes\nThe Sysdig Blog\nSelf-Paced Training\nSupport\nYou can access the page at any time by clicking the rocket ship icon in the left navigation bar.\nAWS Role DelegationSysdig Monitor can now utilize the Amazon Web Service (AWS) AssumeRole functionality and discover cloud assets, grab CloudWatch metrics from your AWS account, and use custom S3 bucket for storing captures. Upon integrating with an AWS role, you can delegate access to AWS resources that are not associated with your Sysdig AWS account.\nRole delegation is an alternative to the existing integration method using the access keys. This method is considered secure as sharing developer access keys with third-parties is not recommended by Amazon.\nFor more information, see Integrate with AWS Role Delegation.\nApril 16, 2020Default Dashboards for Istio 1.5Default dashboards (Overview and Services dashboards) are now available for Istio v1.5 in addition to the existing ones for Istio v1.0.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-monitor-release-notes/2020-archive/"},{"id":760,"title":"Forwarding to Google Security Command Center","content":" Supported data\nAt this time, only GCP Audit Log events can be forwarded to this integration. Prerequisites Handle region-specific items: Event forwarders originate from region-specific IPs. For the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle event forwarding.\nEnable integration from GCP console: Select Enable APIs and Services, and enable the following APIs:\nSecurity Command Center API Identity and Access Management (IAM) API Handle Service Account: A service account with the right permissions is required. The following example illustrates how to do it automatically from the terminal. The values PROJECT_ID and ORG_ID must be provided. SERVICE_ACCOUNT refers to the desired name for the account. KEY_LOCATION refers to the desired name for the JSON output file that will need to be uploaded into the Sysdig UI in the next step.\nexport SERVICE_ACCOUNT=scc-servaccount export PROJECT_ID=elevated-web-872901 export KEY_LOCATION=scckey.json export ORG_ID=494436833222 gcloud iam service-accounts create $SERVICE_ACCOUNT \\ --display-name \u0026#34;Service Account for USER\u0026#34; \\ --project $PROJECT_ID gcloud iam service-accounts keys create $KEY_LOCATION \\ --iam-account $SERVICE_ACCOUNT@$PROJECT_ID.iam.gserviceaccount.com gcloud beta organizations add-iam-policy-binding $ORG_ID \\ --member=\u0026#34;serviceAccount:$SERVICE_ACCOUNT@$PROJECT_ID.iam.gserviceaccount.com\u0026#34; \\ --role=\u0026#39;roles/securitycenter.admin\u0026#39; Configure Standard IntegrationTo forward event data to Google SCC:\nLog in to Sysdig Secure as Admin and go to Integrations \u0026gt; Add Integrations. Search and choose Google SCC. Configure the required options: Integration Name: Define an integration name. Organization: Set the ID of your GCP organization. JSON credentials: Upload JSON credentials that you previously generated from a service account or user. Data to Send: Select from the drop-down the types of Sysdig data that should be forwarded. Note that since only GCP Audit Log events can be forwarded, only Runtime Policy events are shown. Toggle the enable switch as necessary. Remember that you will need to \u0026ldquo;Test Integration\u0026rdquo; with the button below before enabling the integration. Click Save. Configure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description SCC organization yes string GCP organization ID SCC credentialsJSON yes string credentials JSON file content used to authenticate as a service account in the project ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forward-to-google-security-command-center/"},{"id":761,"title":"Integrations for Sysdig Monitor","content":"The Integrations module of Sysdig Monitor features four Data Sources:\nMonitoring Integrations: Manage the collection of metrics across multiple environments via Monitoring Integrations. Cloud Accounts: Collect metrics from cloud providers such as AWS, GCP, and Azure. Sysdig Platform Audit: Review audit logs of activity on Sysdig Platform. See Sysdig Platform Audit. Sysdig Agents: Check the status of Sysdig agents. See Sysdig Agents. This page covers the basic concepts behind Integrations.\nWhat is an Integration?An integration refers to the process of connecting Sysdig with other applications and platforms. An integration enables the Sysdig agent to scrape an application, such as Nginx, Kubelet, or HAProxy, for metrics. Integrations can also refer to cloud accounts, the Activity Audit, or the Sysdig Agents pages.\nWhat is a Metric?A metric is a logical collection of time series sharing the same name, such as workqueue_depth, kube_job_complete, or http_requests. Many applications make dozens of metrics available for collection. Sysdig Integrations prioritize collection of the most valuable metrics for use in modules such as Dashboards, and Alerts.\nWhat is a Time Series?A metric is identified by its unique name, such as http_requests. A time series is defined by both the metric name and a distinct set of label key-value pairs, for example http_requests{method=\u0026quot;GET\u0026quot;, endpoint=\u0026quot;/api/v2/users\u0026quot;}. Every time series is unique, since no two can have an identical combination of labels.\nMetric Times Series Value Description http_requests http_requests{method=\u0026quot;GET\u0026quot;, endpoint=\u0026quot;/api/v2/users\u0026quot;} 100 number of GET HTTP requests to /api/v2/users http_requests http_requests{method=\u0026quot;POST\u0026quot;, endpoint=\u0026quot;/api/v2/users\u0026quot;} 250 number of POST HTTP requests to /api/v2/users http_requests http_requests{status=\u0026quot;500\u0026quot;, endpoint=\u0026quot;/api/v2/users\u0026quot;} 10 Number of HTTP requests returning 500 to /api/v2/users Default and Custom MetricsSysdig Agent collects thousand of metrics at no additional cost, such as sysdig_container_net_server_in_bytes or kube_pod_info; these are called default metrics.\nOn the other hand, there are custom metrics, which do count towards your Time Series entitlement limit. They can be identified with the _sysdig_custom_metric=\u0026quot;true\u0026quot; label. Any metric without this label is a default metrics that doesn’t count towards your entitlement limit.\nHow Are Metrics Collected?The Sysdig Agent will begin collecting and reporting metrics as soon as it is installed. See Install Sysdig Agent\nFor applications in environments where the agent is not installed, you can send metrics to Sysdig with Prometheus Remote Write. See Configure Prometheus Remote Write.\nCloud accounts start sending metrics as soon as they are connected to Sysdig. See Cloud Accounts.\nCustomize Metrics CollectionOnce an integration is set up, the Sysdig agent will begin to collect metrics. To configure metrics collection:\nEnable an integration to collect metrics from that integration. See Enable and Disable Integrations. For metrics collected by the Sysdig Agent, you can exclude clusters from collection through the UI. For metrics collected via Prometheus Remote Write, edit the prometheus.yaml file to exclude the collection of certain metrics. Edit the annotation of a pod to prevent the collection of metrics by the Sysdig Agent. See Exclude Workloads from Collection. For Cloud Account metrics, modify metrics collection from the Cloud Accounts module. See Understand Cloud Accounts UI. See Reduce Metrics Consumption. These methods let you add new metrics or drop metrics from being collected.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/"},{"id":762,"title":"MySQL","content":"Supported DistributionThe MySQL AppCheck is supported for following MySQL versions.\nIf the Sysdig agent is installed as a Process:\nHost with Python 2.7: MySQL versions supported - 5.5 to 8\nHost with Python 2.6: MySQL versions supported - 4.1 to 5.7 (tested with v5.x only)\nNOTE: This implies that MySQL 5.5, 5.6 and 5.7 are supported on both the Python 2.6 and 2.7 environments.\nIf the Sysdig agent is installed as a Docker container:\nThe Docker container of the Sysdig agent has Python 2.7 installed. If it is installed, respective versions against Python 2.7 will be supported.\nThe following environments have been tested and are supported. Tests environments include both the Host/Process and Docker environment.\nPython MySQL 2.7 (Ubuntu 16/ CentOS 7) No Yes Yes Yes Yes 2.6 (CentOS 6) Yes Yes Yes Yes No MySQL SetupA user must be created on MySQL so the Sysdig agent can collect metrics. To configure credentials, run the following commands on your server, replacing the sysdig-clouc-password parameter.\nMySQL version-specific commands to create a user are provided below.\n# MySQL 5.6 and earlier CREATE USER \u0026#39;sysdig-cloud\u0026#39;@\u0026#39;127.0.0.1\u0026#39; IDENTIFIED BY \u0026#39;sysdig-cloud-password\u0026#39;; GRANT PROCESS, REPLICATION CLIENT ON *.* TO \u0026#39;sysdig-cloud\u0026#39;@\u0026#39;127.0.0.1\u0026#39; WITH MAX_USER_CONNECTIONS 5; ## OR ## # MySQL 5.7 and 8 CREATE USER \u0026#39;sysdig-cloud\u0026#39;@\u0026#39;127.0.0.1\u0026#39; IDENTIFIED BY \u0026#39;sysdig-cloud-password\u0026#39; WITH MAX_USER_CONNECTIONS 5; GRANT PROCESS, REPLICATION CLIENT ON *.* TO \u0026#39;sysdig-cloud\u0026#39;@\u0026#39;127.0.0.1\u0026#39;; Sysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nThere is no default configuration for MySQL, as a unique user and password are required for metrics polling.\nAdd the entry for MySQL into dragent.yaml , updating the user and pass field credentials.\napp_checks: - name: mysql pattern: comm: mysqld conf: server: 127.0.0.1 user: sysdig-cloud pass: sysdig-cloud-password Metrics AvailableSee MySQL Metrics.\nResult in the Monitor UIDefault Dashboard Additional Views ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/mysql/"},{"id":763,"title":"MySQL Metrics","content":"See Application Integrations for more information.\nmysql.galera.wsrep_cluster_sizeThe current number of nodes in the Galera cluster.\nmysql.innodb.buffer_pool_freeThe number of free pages in the InnoDB Buffer Pool.\nmysql.innodb.buffer_pool_totalThe total number of pages in the InnoDB Buffer Pool.\nmysql.innodb.buffer_pool_usedThe number of used pages in the InnoDB Buffer Pool.\nmysql.innodb.buffer_pool_utilizationThe utilization of the InnoDB Buffer Pool.\nmysql.innodb.current_row_locksThe number of current row locks.\nmysql.innodb.data_readsThe rate of data reads.\nmysql.innodb.data_writesThe rate of data writes.\nmysql.innodb.mutex_os_waitsThe rate of mutex OS waits.\nmysql.innodb.mutex_spin_roundsThe rate of mutex spin rounds.\nmysql.innodb.mutex_spin_waitsThe rate of mutex spin waits.\nmysql.innodb.os_log_fsyncsThe rate of fsync writes to the log file.\nmysql.innodb.row_lock_timeThe fraction of time spent (ms/s) acquring row locks.\nmysql.innodb.row_lock_waitsThe number of times per second a row lock had to be waited for.\nmysql.net.connectionsThe rate of connections to the server.\nmysql.net.max_connectionsThe maximum number of connections that have been in use simultaneously since the server started.\nmysql.performance.com_deleteThe rate of delete statements.\nmysql.performance.com_delete_multiThe rate of delete-multi statements.\nmysql.performance.com_insertThe rate of insert statements.\nmysql.performance.com_insert_selectThe rate of insert-select statements.\nmysql.performance.com_replace_selectThe rate of replace-select statements.\nmysql.performance.com_selectThe rate of select statements.\nmysql.performance.com_updateThe rate of update statements.\nmysql.performance.com_update_multiThe rate of update-multi.\nmysql.performance.created_tmp_disk_tablesThe rate of internal on-disk temporary tables created by second by the server while executing statements.\nmysql.performance.created_tmp_filesThe rate of temporary files created by second.\nmysql.performance.created_tmp_tablesThe rate of internal temporary tables created by second by the server while executing statements.\nmysql.performance.kernel_timeThe percentage of CPU time spent in kernel space by MySQL.\nmysql.performance.key_cache_utilizationThe key cache utilization ratio.\nmysql.performance.open_filesThe number of open files.\nmysql.performance.open_tablesThe number of of tables that are open.\nmysql.performance.qcache_hitsThe rate of query cache hits.\nmysql.performance.queriesThe rate of queries.\nmysql.performance.questionsThe rate of statements executed by the server.\nmysql.performance.slow_queriesThe rate of slow queries.\nmysql.performance.table_locks_waitedThe total number of times that a request for a table lock could not be granted immediately and a wait was needed.\nmysql.performance.table_locks_waited.gaugemysql.performance.threads_connectedThe number of currently open connections.\nmysql.performance.threads_runningThe number of threads that are not sleeping.\nmysql.performance.user_timeThe percentage of CPU time spent in user space by MySQL.\nmysql.replication.seconds_behind_masterThe lag in seconds between the master and the slave.\nmysql.replication.slave_runningA boolean showing if this server is a replication slave that is connected to a replication master.\nmysql.replication.slaves_connectedThe number of slaves connected to a replication master.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/mysql-metrics/"},{"id":764,"title":"Network","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nnet.bytes.inInbound network bytes. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.bytes.outOutbound network bytes. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.bytes.totalTotal network bytes. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.client.ipThe client IP address.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.connection.count.inThe number of currently established client (inbound) connections.\nThis metric is especially useful when segmented by port, process, or protocol.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Protocol, Port, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.connection.count.outThe number of currently established server (outbound) connections.\nThis metric is especially useful when segmented by port, process, or protocol.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Port, Protocol, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.connection.count.totalThe number of currently established connections. This value may exceed the sum of the inbound and outbound metrics since it represents client and server inter-host connections as well as internal only connections.\nThis metric is especially useful when segmented by port, process, or protocol.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Port, Protocol, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.error.countThe number of errors encountered by network system calls, such as connect(), send(), and recv(). By default, this metric displays the total value for the defined scope. For example, if the scope is defined as a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.http.error.count net.http.error.count is a heuristic metric.\nThe number of failed HTTP requests, determined by the total number of 4xx/5xx status codes.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.http.methodThe HTTP request method.\nMetadata Description Metric Type Gauge Value Type String Segment By host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.http.request.count net.http.request.count is a heuristic metric.\nHTTP request count.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.http.request.time net.http.request.time is a heuristic metric.\nAverage HTTP request time.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.http.request.time.worstThe maximum time for HTTP requests.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.http.statusCodeThe HTTP response status code.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.http.urlThe HTTP request URL.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.link.clientServer.bytesThe number of bytes passing through the link from client to server.\nMetadata Description Metric Type Counter Value Type Byte Segment By Host Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.link.delay.perRequestAverage delay in the network link per request.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.link.serverClient.bytesThe number of bytes passing through the link from server to client.\nMetadata Description Metric Type Counter Value Type Byte Segment By Host Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.local.endpointThe local endpoint for a connection. This metric is resolved to a user-friendly host name, if available.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.local.service Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.mongodb.collectionThe MongoDB collection.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.mongodb.error.count net.mongodb.error.count is a heuristic metric.\nThe number of Failed MongoDB requests.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.mongodb.operationThe MongoDB operation.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.mongodb.request.count net.mongodb.request.count is a heuristic metric.\nThe total number of MongoDB requests.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.mongodb.request.time net.mongodb.request.time is a heuristic metric.\nThe average time to complete a MongoDB request.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.mongodb.request.time.worst (deprecated)The maximum time to complete a MongoDB request.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.protocolThe network protocol of a request (for example, HTTP or MySQL).\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.remote.endpointThe remote endpoint of a connection. This metric automatically resolves as a user-friendly host name, if available.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.remote.serviceService (port number) of a remote node.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.request.count net.request.count is a heuristic metric.\nTotal number of network requests.\nThis value may exceed the sum of inbound and outbound requests, because this count includes requests over internal connections.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.request.count.in net.request.count.in is a heuristic metric.\nNumber of inbound network requests.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.request.count.outNumber of outbound network requests.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time net.request.time is a heuristic metric.\nA measure of response time which includes app + network latency. For server side it is purely a measure of app latency. This is calculated by measuring when we see the arrival of the last request buffer to when we see the departure of the first response buffer.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.file (deprecated)The amount of time for serving a request that is spent doing file I/O. See also net.request.time.net (network I/O time) and net.request.time.processing (CPU processing time).\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.file.percent net.request.time.file.percent is a heuristic metric.\nThe percentage of time for serving a request that is spent doing file I/O. See also net.request.time.net (network I/O time) and net.request.time.processing (CPU processing time).\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.in net.request.time.in is a heuristic metric.\nAverage time to serve an inbound request.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.local (deprecated)Average per request delay introduced by this node when it serves requests coming from the previous tiers. In other words, this is the time spent serving incoming requests minus the time spent waiting for outgoing requests to complete.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.local.percent net.request.time.local.percent is a heuristic metric.\nThe percentage of time spent in the local node versus the next tiers, when serving requests that come from previous tiers.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.net (deprecated)The amount of time for serving a request that is spent doing network I/O. See also net.request.time.file (file I/O time) and net.request.time.processing (CPU processing time).\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.net.percent net.request.time.net.percent is a heuristic metric.\nThe percent of time for serving a request that is spent doing network I/O. See also net.request.time.file (file I/O time) and net.request.time.processing (CPU processing time).\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.nextTiers (deprecated)Delay introduced by the successive tiers when serving requests.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.nextTiers.percent net.request.time.nextTiers.percent is a heuristic metric.\nThe percentage of time spent in the next tiers versus the local node, when serving requests that come from previous tiers.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.out net.request.time.out is a heuristic metric.\nAverage time spent waiting for an outbound request.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.processing (deprecated)The amount of time for serving a request that is spent doing CPU processing. See also net.request.time.file (file I/O time) and net.request.time.net (network I/O time).\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.processing.percent net.request.time.processing.percent is a heuristic metric.\nThe percent of time for serving a request that is spent doing CPU processing. See also net.request.time.file (file I/O time) and net.request.time.net (network I/O time).\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.worst.in net.request.time.worst.in is a heuristic metric.\nMaximum time to serve an inbound request.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.request.time.worst.out net.request.time.worst.out is a heuristic metric.\nMaximum time spent waiting for an outbound request.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.role Metadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.server.ip\nServer IP address.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.server.port\nTCP/UDP Server port number.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.sql.error.count net.sql.error.count is a heuristic metric.\nThe number of Failed SQL requests.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.sql.queryThe full SQL query. If the query string is longer than 512 characters, it will be truncated to 512 characters.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.sql.query.typeThe SQL query type (for example, SELECT, INSERT, or DELETE).\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.sql.request.count net.sql.request.count is a heuristic metric.\nThe number of SQL requests.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max net.sql.request.time net.sql.request.time is a heuristic metric.\nAverage time to complete an SQL request.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.sql.request.time.worst (deprecated)Maximum time to complete a SQL request.\nMetadata Description Metric Type Counter Value Type relativeTime Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max net.sql.tableThe SQL query table name.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A net.tcp.queue.lenThe length of the TCP request queue.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/network/"},{"id":765,"title":"Sysdig Support","content":"See Submit a Support Ticket for information on supplementing your case with relevant logs.\nCheck the Status of Scheduled MaintenanceScheduled maintenance can cause disruptions of service.\nYou can check the status of scheduled maintenance and subscribe for updates.\nClick SUBSCRIBE TO UPDATES to receive automated notifications.\nReach SupportFor your convenience, Sysdig provides multiple methods to reach Sysdig Support.\nFill Out a Web-Based FormOpen a support ticket by filling in the web-based form.\nUse the Product UITo access Sysdig Support from the UI:\nClick your account name in the bottom left panel to open the User menu.\nUnder Help, click Support Website to open the Sysdig Support website.\nScroll down to the bottom of the page and under Submit a Ticket, click Contact Support.\nFill out the ticketing page and click Save.\nA case number is assigned to your ticket. Support will review your case and contact you.\nChat with SupportTo contact the Customer Success team from the Sysdig Monitor or Sysdig Secure UI, select the the Chat with Us icon from the bottom of the left navigation bar.\nThis button may be unresponsive if you have disabled Usage Data in your Privacy Settings. See Individual User Settings\nEmail SupportEmail support@sysdig.com with the details of your problem to open a support case.\nUse Slack (Premium Only)If you have a premium subscription, you can contact Sysdig Support through Slack Connect for no extra fee.\n","url":"https://docs.sysdig.com/en/docs/support/"},{"id":766,"title":"System","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\ncapacity.estimated.request.stolen.count (deprecated)The number of requests the node cannot serve due to CPU steal time. This metric is calculated by measuring the current number of requests the machine is serving, and calculating how many more requests could be served if there was no steal time.\nThis metric can be used to understand how steal time impacts the ability to serve user requests.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Process Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max capacity.estimated.request.total.count (deprecated)The estimated number of requests the node serves at full capacity. This metric is calculated by measuring the number of requests that a machine is serving, and the resources each request is using, and combining the values to project how many requests the machine can serve.\nThis metric can help users determine if/when the infrastructure capacity should be increased.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Process Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max capacity.stolen.percent (deprecated)The lost service request capacity due to stolen CPU. This metric reflects the impact on other resource usage capabilities, including disk I/O and network I/O.\ncapacity.stolen.percent is non-zero only if cpu.stolen.percent is also non-zero.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Process Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max capacity.total.percent (deprecated)The estimated current capacity usage, based on CPU and disk/network utilization, with CPU stolen time added back in.\ncapacity.total.percent can be used to show how the system would perform with dedicated CPU usage.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Process Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max capacity.used.percent (deprecated)The estimated current capacity usage, based on CPU and disk/network utilization. This metric is calculated by adding the value of how many resources each request coming to the machine is using, creating a score that indicates how saturates the machine resources are.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Process Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max cpu.idle.percentThe percentage of time that the CPU/s were idle and the system did not have an outstanding disk I/O request. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max cpu.iowait.percentThe percentage of time that the CPU/s were idle during which the system had an outstanding disk I/O request. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max cpu.nice.percentThe percentage of CPU utilization that occurred while executing at the user level with Nice priority. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max cpu.stolen.percentMeasures the percentage of time that a virtual machine\u0026rsquo;s CPU is in a state of involuntary wait due to the fact that the physical CPU is shared among virtual machines. In calculating steal time, the operating system kernel detects when it has work available but does not have access to the physical CPU to perform that work.\nIf the percent of steal time is consistently high, you may want to stop and restart the instance (since it will most likely start on different physical hardware) or upgrade to a virtual machine with more CPU power. Also see capacity.total.percent to see how steal time directly impacts the number of server requests that could not be handled. On AWS EC2, steal time does not depend on the activity of other virtual machine neighbors. EC2 is simply making sure your instance is not using more CPU cycles than paid for.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max cpu.system.percentThe percentage of CPU utilization that occurred while executing at the system level (kernel). By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max cpu.cores.usedThe CPU core usage of each container is obtained from cgroups, and is equal to the number of cores used by the container. For example, if a container uses two of an available four cores, the value of cpu.cores.used will be two.\nMetadata Description Metric Type Gauge Value Type Number Segment By Host, Container Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max, RateofChange Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max cpu.cores.used.percentThe CPU core usage percent for each container is obtained from cgroups, and is equal to the number of cores multiplied by 100. For example, if a container uses three cores, the value of cpu.cores.used.percent would be 300%.\nThis metric is comparable to the CPU usage metric in docker stats.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container Default Time Aggregation Average Available Time Aggregation Formats Average, Rate, Sum, Min, Max, rateOfChange Default Group Aggregation Average Available Group Aggregation Formats Average, Sum, Min, Max cpu.used.percentContainersThe CPU usage for each container is obtained from cgroups, and normalized by dividing by the number of cores to determine an overall percentage.\nFor example, if the environment contains six cores on a host, and the container or processes are assigned two cores, Sysdig will report CPU usage as:\n2/6 * 100% = 33.33% By comparison, the docker stats command would report the CPU usage as 200%, as each individual core is assigned a value of 100%.\nFor service or orchestrator constructs, the container CPU is aggregated based on container labels.\nHostsThe CPU usage for each host is obtained from /proc, and measured as the sum of the CPU usage of all cores, normalized by dividing by the number of cores.\nThe CPU usage for each host is the sum of cpu.user.percent, cpu.nice.percent, cpu.stolen.percent, and cpu.system.percent.\nThe Linux command top can be used to review these values as well.\nProcessesThe CPU usage for each process is obtained from /proc, and normalized by dividing by the number of cores.\nWhen cpu.used.percent is segmented by process at the host level, the sum of the CPU usage of each process may not always add up to the CPU usage of the host. The most common reasons for this are:\nThere are short-lived processes that spike for less than two seconds.\nGranular data is retained for the highest CPU usage processes, rather than all processes.\nThe kernel thread CPU usage is not reported as a process.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max cpu.user.percentThe percentage of CPU utilization that occurred while executing at the user level (application). By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.bytes.freeAvailable filesystem space.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.bytes.totalTotal filesystem size.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.bytes.usedUsed filesystem space.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.deviceFilesystem device.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A fs.free.percentThe percentage of free filesystem space.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.inodes.total.count Metadata Description Metric Type Gauge Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.inodes.used.count Metadata Description Metric Type Gauge Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.inodes.used.percent Metadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.largest.used.percentThe percentage of filesystem space used by the largest filesystem.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.mountDirThe filesystem mount directory.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A fs.root.used.percentThe percentage of root filesystem space used.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max fs.typeFilesystem type.\nMetadata Description Metric Type Gauge Value Type String Segment By Host Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A fs.used.percentThe amount of space written by a single container instance. This value is provided by the container engine and is not supported for some versions of CRIO. For example, CRIO-1.15 which is used in OpenShift 4.2. crictl stats not showing the size indicates that this feature is not supported.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max host.error.countThe number of system call errors. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max load.average.15mThe 15 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 15 minutes for all cores. The value should correspond to the third (and last) load average value displayed by the \u0026lsquo;uptime\u0026rsquo; command.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max load.average.1mThe 1 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 1 minute for all cores. The value should correspond to the third (and last) load average value displayed by the \u0026lsquo;uptime\u0026rsquo; command.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max load.average.5mThe 5 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 5 minutes for all cores. The value should correspond to the third (and last) load average value displayed by the \u0026lsquo;uptime\u0026rsquo; command.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max load.average.percpu.15mThe 15 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 15 minutes, divided by number of system CPUs.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max load.average.percpu.1mThe 1 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 1 minute, divided by number of system CPUs.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max load.average.percpu.5mThe 5 minute system load average represents the average number of jobs in (1) the CPU run queue or (2) waiting for disk I/O averaged over 5 minutes, divided by number of system CPUs.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max memory.bytes.availableThe amount of available memory. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nAn estimate of how much memory is available for starting new applications, without swapping.\nmemory.bytes.available may not be directly available on older systems using kernel versions older than 3.14. In these instances, the metric is an approximate value, determined by adding the free and cached memory values.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max memory.bytes.totalThe total memory of a host, in bytes. This value is obtained from /proc. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max memory.bytes.usedThe amount of physical memory currently in use. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nThe formula for determining memory.bytes.used is slightly different depending on whether you are examining processes or containers. For containers, the formula is rss+cache-inactive_file. This means that the total amount of page cache memory (inactive_file) is subtracted from the total number of bytes of page cache memory, and the total number of bytes of anonymous and swap cache memory, combined.\nThis is different to the docker stats approach, and may result in different results.\nFor processes, the formula is the total value of the size of the resident anonymous memory, the size of the resident file mappings, and the size of the resident shared memory.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max memory.bytes.virtualThe virtual memory size of the process, in bytes. This value is obtained from Sysdig events. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max memory.pageFault.majorA count of the condition that occurs when a program accesses a memory page that is mapped in the virtual address space, but not loaded in physical memory. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nA major or ‘hard’ page fault is handled by using a disk I/O operation (e.g., memory mapped file or page replacement causing a page swapping). For instance, when starting an application, the Linux kernel will search physical memory and the CPU cache, and, if data does not exist, a major page fault occurs. Generally, adjusting application source code or making more physical memory available reduces major page faults.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max memory.pageFault.minorA count of the condition in which a memory page had been loaded in memory at the time the page fault was generated, but was not marked in the memory management unit as being loaded in memory. By default, this metric displays the total value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the total value for the whole group.\nIf the page is loaded in memory at the time the fault is generated, but is not marked in the memory management unit as being loaded in memory, then it is called a minor or ‘soft’ page fault. A minor page fault is handled without using a disk I/O operation (e.g., allocated by malloc().). The effect of minor page faults depends on system load and other factors, but are typically short and have very little impact.\nMetadata Description Metric Type Counter Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Sum Available Group Aggregation Formats Avg, Sum, Min, Max memory.swap.bytes.availableThe swap memory available. This metric is determined by the sum of the free and cached swap memory. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max memory.swap.bytes.totalThe total amount of swap memory. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max memory.swap.bytes.usedThe amount of swap memory used. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type Byte Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max memory.swap.used.percentThe percentage of swap memory used. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max memory.used.percentThe percentage of physical memory in use. By default, this metric displays the average value for the defined scope. For example, if the scope is set to a group of machines, the metric value will be the average value for the whole group.\nRefer to memory.bytes.used for information on the calculation formulas.\nMetadata Description Metric Type Gauge Value Type % Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Average Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max system.uptimeThe system uptime.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max thread.count Metadata Description Metric Type Gauge Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max uptimeThe percentage of time one or more selected entities were up over the defined time window.\nWhile this metric is a percentage value, the value is presented as an integer between 0 and 1, rather than a percentage between 0% and 100%.\nMetadata Description Metric Type Gauge Value Type Integer Segment By Host, Container, Process, Kubernetes, Mesos, Swarm, CloudProvider Default Time Aggregation Rate Available Time Aggregation Formats Avg, Rate, Sum, Min, Max Default Group Aggregation Average Available Group Aggregation Formats Avg, Sum, Min, Max ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/system/"},{"id":767,"title":"(Legacy) Heuristic and Deprecated Metrics","content":"Heuristic Metrics Existing alerts using these metrics will not be modified or disabled. However, these alerts cannot be updated.\nAdditional heuristic metric details are listed below:\nMetric Set New Alerts net.http.request.time Yes net.http.request.count Yes net.http.error.count Yes net.sql.request.time Yes net.sql.request.count Yes net.sql.error.count Yes net.mongodb.request.time Yes net.mongodb.request.count Yes net.mongodb.error.count Yes net.request.time.file.percent Yes net.request.time.local.percent Yes net.request.time.net.percent Yes net.request.time.nextTiers.percent Yes net.request.time.processing.percent Yes net.request.time No net.request.time.in No net.request.time.out No net.request.time.worst.in No net.request.time.worst.out No net.request.count No net.request.count.in No Deprecated MetricsBased on low usage patterns, Sysdig has decided to deprecate the following metrics on August 1, 2018. Users will continue to have the ability to collect similar data using Prometheus, or another method of code instrumentation (i.e. StatsD or JMX for Java applications).\nThe table below shows the current metrics and options for similar functionality.\nCurrent Metric Alternative Starting August 1, 2018 capacity.estimated.request.stolen.count Create your application metrics using Prometheus, StatsD or JMX for Java applications. capacity.estimated.request.total.count capacity.stolen.percent capacity.total.percent capacity.used.percent net.request.time.file net.request.time.local net.request.time.net net.request.time.nextTiers net.request.time.processing net.sql.request.time.worst Max aggregation (net.sql.request.time) net.mongodb.request.time.worst Max aggregation (net.mongodb.request.time) net.http.request.time.worst Max aggregation (net.http.request.time) ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/using-monitor/metrics/metrics-library/sysdig-legacy-format/heuristic-and-deprecated-metrics/"},{"id":768,"title":"NGINX and NGINX Plus","content":"NGINX Plus is a software load balancer, web server, and content cache built on top of open source NGINX. NGINX Plus has exclusive enterprise‑grade features beyond what\u0026rsquo;s available in the open-source offering, including session persistence, configuration via API, and active health checks.\nThe Sysdig agent has a default configuration to collect metrics for open-source NGINX, provided that you have the HTTP stub status module enabled. NGINX exposes basic metrics about server activity on a simple status page with this status module. If NGINX Plus is installed, a wide range of metrics is available with the NGINX Plus API.\nThis page describes the setup steps for NGINX/NGINX Plus, the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and sample results in the Sysdig Monitor UI.\nNGINX/ NGINX Plus SetupThis section describes the configuration required on the NGINX server.\nThe Sysdig agent will not collect metrics until the required endpoint is added to the NGINX configuration, per one of the following methods:\nFor NGINX (Open Source): use the stub status module\nFor NGINX Plus: use the Plus API\nConfiguration examples of each are provided below\nNGINX Stub Status Module ConfigurationThe ngx_http_stub_status_module provides access to basic status information. It is compiled by default on most distributions. If not, it should be enabled with the --with-http_stub_status_module configuration parameter.\nTo check if the module is already compiled, run the following command:\nnginx -V 2\u0026gt;\u0026amp;1 | grep -o with-http_stub_status_module If with-http_stub_status_module is listed, the status module is enabled. (For more information, see http://nginx.org/en/docs/http/ngx_http_stub_status_module.html.)\nUpdate the NGINX configuration file with /nginx_status endpoint as follows. The default NGINX configuration file is present at /etc/nginx/nginx.conf or /etc/nginx/conf.d/default.conf. # HTTP context server { ... # Enable NGINX status module location /nginx_status { # freely available with open source NGINX stub_status; access_log off; # for open source NGINX \u0026lt; version 1.7.5 # stub_status on; } ... } NGINX Plus API ConfigurationWhen NGINX Plus is configured, the Plus API can be enabled by adding /api endpoint in the NGINX configuration file as follows.\nThe default NGINX configuration file is present at /etc/nginx/nginx.conf or /etc/nginx/conf.d/default.conf.\n# HTTP context server { ... # Enable NGINX Plus API location /api { api write=on; allow all; } ... } Sysdig Agent Configuration Configuration Examples:\nExample 1 (Default): When only open-source Nginx is configured.\nExample 2: When only NginxPlus node is configured.\nExample 3: When Nginx and NginxPlus are installed in different containers on same host.\nFlag use_plus_api and is used for differentiating NGINX \u0026amp; NGINXPlus metrics.\nNGINXPlus metrics are differentiated with prefix nginx.plus.*\nWhen use_plus_api = true,\nnginx_plus_api_url is used to fetch NginxPlus metrics from the NginxPlus node.\nnginx_status_url is used to fetch Nginx metrics from the Nginx node (If single host is running two separate containers for Nginx and NginxPlus).\nExample 1: Default ConfigurationWith the default configuration, only NGINX metrics will be available once the ngx_http_stub_status_module is configured.\napp_checks: - name: nginx check_module: nginx pattern: exe: \u0026#34;nginx: worker process\u0026#34; conf: nginx_status_url: \u0026#34;http://localhost:{port}/nginx_status\u0026#34; log_errors: true Example 2: NGINX Plus onlyWith this example only NGINX Plus Metrics will be available.\napp_checks: - name: nginx check_module: nginx pattern: exe: \u0026#34;nginx: worker process\u0026#34; conf: nginx_plus_api_url: \u0026#34;http://localhost:{port}/api\u0026#34; use_plus_api: true user: admin password: admin log_errors: true Example 3: NGINX and NGINX PlusThis is special case where NGINX open-source and NGINX PLUS are installed on same host but in different containers. With this configuration, respective metrics will be available for NGINX and NGINX Plus containers.\napp_checks: - name: nginx check_module: nginx pattern: exe: \u0026#34;nginx: worker process\u0026#34; conf: nginx_plus_api_url: \u0026#34;http://localhost:{port}/api\u0026#34; nginx_status_url: \u0026#34;http://localhost:{port}/nginx_status\u0026#34; use_plus_api: true user: admin password: admin log_errors: true List of Metrics\nNGINX (Open Source)See NGINX Metrics.\nNGINX PlusSee NGINX Plus Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/nginx-and-nginx-plus/"},{"id":769,"title":"Workload ML Policy","content":"Key Features Machine learning collects low-level activities from your Linux workloads, aggregating them over time and applying algorithms. With machine learning policies, you can configure the detections you want to use and their thresholds. Machine learning detection algorithms estimate the probability that those activities are related to the detection subjects, i.e. miners. The Sysdig Workload ML detections don\u0026rsquo;t rely on mere program names or executable checksums matching. Instead, they are based on runtime behaviors. Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nConfigure Workload ML Custom PolicyTo configure a Workload ML Custom Policy in the Sysdig Secure UI:\nSelect Policies \u0026gt; Runtime Policies.\nClick +Add Policy (at the top right of the page).\nSelect the Workload ML policy type.\nConfigure the policy by specifying the basic parameters:\nBasic ParametersName: Enter a policy name\nDescription: Provide a meaningful and searchable description\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance.\nNote: There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nDetectYou can choose what type of Machine Learning-based detections you want enable in your policy. We support only Crypto Mining Detection at this time.\nCrypto Mining Detection: The supported detection type\nConfidence Level Enablement: Fine-tune the policy to choose at which certainty level the detection should trigger an event.\nSeverity defined at detection level, so that you can have a different severity for each detection type.\nActionsNotify: Select a notification channel from the drop-down list for sending notification of events to appropriate personnel.\nSee also: Set Up Notification Channels.\n","url":"https://docs.sysdig.com/en/sysdig-secure/workload_ml_policy/"},{"id":770,"title":"Forwarding to Sentinel","content":"PrerequisitesEvent forwards originate from region-specific IPs. For the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle event forwarding.\nTo successfully integrate Sentinel with Sysdig\u0026rsquo;s event forwarding, you must have access to a configured Log Analytics Workspace. Go there to retrieve the workspace ID and secret you will need for the integration:\nOpen your Log Analytics Workspace. Navigate to Agents management and select Linux servers. Copy the workspace ID and primary key. Configure Standard Integration Log in to Sysdig Secure as Admin and go to Integrations \u0026gt; Add Integrations.\nSearch and choose Microsoft Sentinel.\nConfigure the required options:\nIntegration Name: Define an integration name.\nWorkspace ID: Enter the workspace Id you copied from the Log Analytics Workspace.\nSecret: Enter the Primary key you copied from the Log Analytics Workspace.\nData to Send: Select from the drop-down the types of Sysdig data that should be forwarded to Sentinel. The available list depends on the Sysdig features and products you have enabled.\nToggle the enable switch as necessary. Remember that you will need to \u0026ldquo;Test Integration\u0026rdquo; with the button below before enabling the integration.\nClick Save.\nConfigure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description SENTINEL workspaceId yes string Log Analytics workspace ID SENTINEL secret yes string Log analytics primary key ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forwarding-to-sentinel/"},{"id":771,"title":"Linux Workload Policy","content":" Event notifications are generally limited to a frequency of once every five minutes. For details, see Message Throttling in Sysdig Secure.\nLinux Workload Policies OverviewSysdig provides a set of managed Linux Workload Policies for out-of-the-box threat detection in dynamic environments:\nSysdig Runtime Behavioral Analytics Sysdig Runtime Threat Detection Sysdig Runtime Threat Intelligence Sysdig Runtime Notable Events Sysdig Runtime Activity Logs Sysdig Runtime Behavioral AnalyticsRuntime Behavioral Analytics (BA) is an exceptional type of Linux Workload Policy. Powered by Observations, it correlates a sequence of actions to detect multi-stage attacks often missed by event-driven security.\nThese include:\nReverse Shell: Scenarios where a staged binary spawns a shell and connects to an attacker’s machine. Process Injection (PTRACE): Attempts to inject code into a running process. Multi-Event Chains: Writes to a file after a container execution, and subsequent attempts to execute that file in the same session. Prerequisites Sysdig agent version 13.6.1 or higher. For optimal performance of all analytics features, we recommend the latest version of the agent. Limitations Only Linux workload (syscall) events are eligible. Cloud and Kubernetes Audit events are not covered by Observations.\nOnly Managed Policies support Observations. You cannot use Observations in managed ruleset or custom policies. For the different types of policies, see Types of Threat Detection Policies.\nReview Runtime Behavioral Analytics Policy and RulesTo review the Runtime Behavioral Analytics policy and the rules it enforces:\nLog in to Sysdig Secure.\nSelect Policies \u0026gt; Runtime Policies.\nFind Sysdig Runtime Behavioral Analytics.\nYou can use search and filters to locate it. For example:\nManaged type = Managed Policy Select policy type = Linux Workload By default, it is scoped to Entire Infrastructure. Edit the policy to change the scope.\nSelect the policy to open the detail panel.\nHere, you can see the policy type, description, scope, last update, rules, and more.\nSelect any rule from the rule list to expand its full logic and coverage.\nCreate a Linux Workload PolicyTo create a Linux Workload policy:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nClick Add Policy and select Linux Workload.\nConfigure a Linux Workload PolicyBasic ParametersName: Enter a policy name.\nDescription: Provide a meaningful and searchable description.\nEnabled/Disabled: Toggle to enable the policy so that it generates events.\nSeverity: Choose the appropriate severity level as you would like to see it in the Runtime Policies UI: High, Medium, Low, Info\nPolicy severity is subjective and is used to group policies within a Sysdig Secure instance. There is no inheritance between the underlying rule priorities and the severity you assign to the policy.\nScope: Define the scope to which the policy will apply, based on the type-dependent options listed.\nLink to Runbook: (Optional) Enter the URL of a company procedure that should be followed for events resulting from this policy. For example: https://www.mycompany.com/our-runbook-link.\nIf you enter a value here, then a View Runbook option will be displayed in any corresponding Event.\nPolicy RulesAdd or edit policy rules as needed. You can choose to Import from Library or to create a New Rule. To learn more about rules, see Manage Threat Detection Rules.\nActionsDetermine what should be done if a Policy is violated.\nKill ProcessToggle Kill Process on to have the policy automatically kill the process that triggered the event. This works for container events and hosts, and honors the agent flag to ignore actions at the agent.\nContainersContainer policy actions coverage map:\nEnvironment Container Policy Action Supported? Kubernetes - Linux ✅ Kubernetes - Windows ❌ Hosts - Linux Containers ✅ Hosts - Linux Packages ✅ Hosts - Windows ❌ Hosts - ECS on EC2 ❌ Serverless - Azure Container Apps ❌ Serverless - Cloud Run Service ❌ Serverless - ECS on Fargate ❌ Select what should happen to affected containers if the policy rules are breached:\nNothing (alert only): Do not change the container behavior; send a notification according to Notification Channel settings. Kill: Kills one or more running containers immediately. Stop: Allows a graceful shutdown (10-seconds) before killing the container. Pause: Suspends all processes in the specified containers. For details, see Available Response Actions.\nThe agent can be configured to prevent Kill, Pause and Stop actions, regardless of the policy.\nSee Ignore Container Actions at the Agent Level.\nCaptureToggle Capture on if you want to create a capture in case of an event, and define the number of seconds before and after the event that should be in the snapshot.\nAs of June, 2021, you can add the Capture option to policies affecting events from both the Sysdig agent and Fargate Serverless Agents Fargate serverless agents.\nNote that for serverless agents, manual captures are not supported; you must toggle on the Capture option in the policy definition.\nSee also: Captures.\nNotifySelect a notification channel from the drop-down list to send notifications of events to appropriate personnel.\nSee also: Set Up Notification Channels.\nSearch for Existing PoliciesTo review the existing policies:\nLog in to Sysdig Secure and select Policies \u0026gt; Runtime Policies.\nFilter for Managed Policy and Linux Workload.\nYou can edit a managed policy, duplicate it to create a custom policy, or click + Add Policy, choose Linux Workload to configure it from scratch.\n","url":"https://docs.sysdig.com/en/sysdig-secure/linux-workload-policy/"},{"id":772,"title":"NTP","content":"If the NTP check is enabled in the Sysdig agent, it reports the time offset of the local agent from an NTP server.\nThis page describes how to edit the configuration to collect information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig's dragent.default.yaml does not provide any configuration for NTP.\nAdd the configuration in Example 1 to the dragent.yaml file to enable NTP checks.\nNever edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample- name: ntp interval: 60 pattern: comm: systemd conf: host: us.pool.ntp.org offset_threshold: 60 host : (mandatory) provides the host name of NTP server.\noffset_threshold: (optional) provides the difference (in seconds) between the local clock and the NTP server, when the ntp.in_sync service check becomes CRITICAL. The default is 60 seconds.\nMetrics Availablentp.offset, the time difference between the local clock and the NTP reference clock, is the primary NTP metric.\nSee also NTP Metrics.\nService Checks\nntp.in_sync:\nReturns CRITICAL if the NTP offset is greater than the threshold specified in dragent.yaml, otherwise OK.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/ntp/"},{"id":773,"title":"NTP Metrics","content":"See Application Integrations for more information.\nntp.offsetThe time difference between the local clock and the NTP reference clock, in seconds.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/ntp-metrics/"},{"id":774,"title":"PGBouncer","content":"This page describes the configuration settings, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nPgBouncer SetupPgBouncer does not ship with a default stats user configuration. To configure it, you need to add a user allowed to access PgBouncer stats. Do so by adding following line in pgbouncer.ini. The default file location is /etc/pgbouncer/pgbouncer.ini\nstats_users = sysdig_cloud For the same user you need the following entry in userlist.txt. The default file location is /etc/pgbouncer/userlist.txt\n\u0026#34;sysdig_cloud\u0026#34; \u0026#34;sysdig_cloud_password\u0026#34; Sysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationNo default configuration is present in Sysdig\u0026rsquo;s dragent.default.yaml file for PgBouncer, as it requires a unique username and password. You must add a custom entry in dragent.yaml as follows:\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExampleapp_checks: - name: pgbouncer pattern: comm: pgbouncer conf: host: localhost # set if the bind ip is different port: 6432 # set if the port is not the default username: sysdig_cloud password: sysdig_cloud_password #replace with appropriate password Metrics AvailableSee PGBouncer Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/pgbouncer/"},{"id":775,"title":"Forwarding to Splunk","content":"PrerequisitesEvent forwards originate from region-specific IPs. For the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle Splunk event forwarding.\nSet up an HEC on Splunk. Have the following on hand:\nThe URL of the HTTP Event Collector that forwards events to a Splunk deployment. The token generated when you create the Splunk Event Collector. Configure Standard Event ForwardingTo forward event data to Splunk:\nLog in to Sysdig Secure as Admin and navigate to Integrations \u0026gt; Add Integrations.\nSearch and choose HEC (Splunk) .\nConfigure the required options:\nIntegration Name: Define an integration name.\nURL: Define the URL of the Splunk service. This is the HTTP Event Collector that forwards events to a Splunk deployment. Be sure to use the format scheme://host:port.\nToken: This is the token that Sysdig uses to authenticate the connection to the HTTP Event Collector. This token is created when you create the Splunk Event Collector.\nCertificate: If you have configured a Certificates Management tool, you can select one of your uploaded certs here.\nIndex: The index where events are stored. Specify the Index if you have selected one while configuring the HTTP Event Collector.\nSource Type: Identifies the data structure of the event. For more information, see Source Type.\nFor more information on these parameters, see the Splunk documentation.\nIf left empty, each data type will have a source type. See Appendix: Data Categories Mapped to Source Types for details.\nData to Send: Select from the drop-down the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled.\nSelect whether or not you want to Allow insecure connections, such as invalid or self-signed certificate on the receiving side.\nToggle the Enabled switch as necessary. You will need to Test Integration with the button below before enabling the integration.\nClick Save.\nHere is an example of how policy events forwarded from Sysdig Secure are displayed on Splunk:\nConfigure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description SPLUNK ServiceToken yes string HTTP Event Collector Token SPLUNK ServiceURL yes string URL of the Splunk instance SPLUNK Index no string index to send data to. If unspecified, it will be used the index specified on the HTTP Event Collector configuration on Splunk. SPLUNK ServiceType no string tcp, udp tcp protocol, tcp or udp (case insensitive) SPLUNK insecure no bool true Doesn’t verify TLS certificate Reference: Data Categories Mapped to Source Types Sysdig Data Type Splunk Source Type Monitor Events SysdigMonitor Policy Events (Legacy) SysdigPolicy Sysdig Platform Audit SysdigAuditTrail Benchmark Events (Legacy) SysdigSecureEvents Secure events compliance (Legacy) SysdigSecureEvents Host Vulnerabilities (Legacy) SysdigSecureEvents Runtime Policy Events SysdigSecureEvents Activity Audit SysdigActivityAudit ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forwarding-to-splunk/"},{"id":776,"title":"PHP-FPM","content":"The Sysdig agent automatically collects all metrics with default configuration.\nThis page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nPHP-FPM SetupThis check has a default configuration that should suit most use cases. If it does not work for you, verify that you have added these lines to your php-fpm.conf file. The default location is /etc/\npm.status_path = /status ping.path = /ping Sysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with PHP-FPM and collect all metrics:\napp_checks: - name: php-fpm check_module: php_fpm retry: false pattern: exe: \u0026#34;php-fpm: master process\u0026#34; If you have a configuration other than those for PHP-FPM in php-fpm.conf, you can edit the Sysdig agent configuration in dragent.yaml, as shown in Example 1.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExampleReplace the values of status_url and ping_url below with the values set against pm.status_path and ping.path respectively in your php-fpm.conf:\napp_checks: - name: php-fpm check_module: php_fpm pattern: exe: \u0026#34;php-fpm: master process\u0026#34; conf: status_url: /mystatus ping_url: /myping ping_reply: mypingreply Metrics AvailableSee PHP-FPM Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/php-fpm/"},{"id":777,"title":"Monitor SaaS Release Notes 2019","content":"November 21, 2019Overview Is GAOverview is now generally available. Overview leverages Sysdig\u0026rsquo;s unified Kubernetes data platform to monitor, secure, and troubleshoot your Kubernetes clusters and workloads.\nCluster Overview Major highlights of Overview GA include but are not limited to:\nMulti-cloud view of the health, risk, and capacity of your Kubernetes infrastructure— a single pane of glass for Kubernetes Clusters, Nodes, Namespaces, and Workloads across a multi- and hybrid-cloud environment. You can easily filter by any of these entities and view associated events and health data. View the infrastructure organized by Clusters, Nodes, Workloads\nShows metrics prioritized by event count and severity, allowing you to get to the root cause of the problem faster.\nDrill down to Dashboards for instant insights.\nTo learn about the capabilities of the Overview feature, see Overview.\nBeta Features: Prometheus and New DashboardsIntroducing Prometheus and New Dashboards available in Beta. Contact sales@sysdig.com to join the Beta Program.\n[BETA] Prometheus CapabilitiesSysdig now supports native Prometheus time series ingestion. Run Prometheus queries inside Sysdig Monitor and create visualization by using the new Beta Dashboards that support it. This enables you to use Sysdig Monitor as a standard Prometheus data source for other visualization tools, such as Grafana. For more information, see Using PromQL.\nPromQL Dashboard With this support, Prometheus and Sysdig metrics can now be supported in regular Prometheus expressions.\n[BETA] New DashboardsSysdig Monitor provides an enhanced New Dashboard to use with Prometheus. For more information, see Dashboards.\nNew Dashboards The New Dashboards offer:\nFlexibility to position the Legend.\nAbility to run multiple queries.\nInherit the Dashboard scope to individual panels.\nMulti-select items in the Legend to narrow down the lines you want to focus on. Use command-click on Mac and Control-click on non-Mac machines.\nFeatures new query types: Form-based and PromQL expressions with the easy toggling facility.\nEnhanced auto-layout with the ability to re-position panels.\nTo access the New Dashboards:\nClick the Dashboards tab on the left navigation panel.\nClick Add Dashboard (+)\nClick Beta Dashboards.\nEnhanced Out-of-the-box DashboardsIn an attempt to improve the Dashboards experience, the following changes have been introduced:\nThe following Dashboards are added:\nKubernetes Cluster Overview: Provides nodes and workloads availability and highlights the high-level health of your Clusters. It also summarizes resources consumption (CPU, memory) across Nodes and Namespaces to pinpoint possible anomalies and node disk utilization\nKubernetes Node Overview: Provides availability of the Nodes, indicating potential issues reported by Kubernetes; a summary of resource (CPU and Memory) allocation and utilization, as well as Network and Disk utilization.\nKubernetes Namespace Overview: Provides a high-level summary of availability, and resource allocation and utilization across all the Workloads in the selected Namespace.\nKubernetes Deployment Overview: Provides a detailed summary of pod status, pod restarts, as well as resource allocation and utilization across pods for each Workload.\nKubernetes StatefulSet Overview: Provides a detailed summary of pod status, pod restarts, as well as resource allocation and utilization across pods for each StatefulSet.\nKubernetes DaemonSet Overview: Provides a detailed summary of pod status, pod restarts, as well as resource allocation and utilization across pods.\nKubernetes Job Overview: Provides a detailed summary of job status, completion trend, pod restarts, as well as resource allocation and utilization across pods.\nKubernetes ReplicaSet Overview: Provides a detailed summary of pod status, pod restarts, as well as resource allocation and utilization across pods for each ReplicaSet.\nKubernetes Pod Overview: Provides a detailed summary of pod status, pod restarts, and resource allocation and utilization in a selected pod.\nKubernetes Workloads CPU Usage and Allocation: Helps you verify that CPU requests are properly configured and actual utilization is expected.\nKubernetes Workloads Memory Usage and Allocation: Helps you verify that memory requests are properly configured and actual utilization is expected.\nKubernetes CPU Allocation Optimization: Helps you verify that infrastructure resources are available for future needs and are not wasted.\nKubernetes Memory Allocation Optimization: Helps you verify that infrastructure resources are available for future needs and are not wasted.\nThe following Dashboards are retained:\nHealth Overview (applicable to all the objects in the environment)\nHorizontal Pod Autoscaler (the default Dashboard when selecting an HPA)\nResource Quota\nService Health (the default dashboard when selecting a service)\nCluster and Node Capacity\nThe following Dashboards are removed:\nState Overview\nDaemonset State\nNamespace State\nStateful State\nNodes State\nDeployment State\nDeployment Health\nNodes Health\nNamespace Health\nPod State\nPod Health\nReplica Set Health\nFor more information, see Dashboard Templates.\nWhat\u0026rsquo;s n/a?The Sysdig Monitor UI displays n/a in several scenarios associated with labeling. The Explore UI has now been enhanced to add a tooltip for n/a to help you understand the scenario. See The Meaning of n/a for more information.\nFiltering Events by ScopeEvents are now filtered by Scope to show the most relevant Events in Explore and Dashboards. This is an extension of the existing Event Scope functionality. You can toggle between showing Event feed from the entire infrastructure and only from the particular scope you are interested in within the infrastructure. Event scoping for Dashboards and Explore is enabled by default.\nBy default, Events are filtered to show only the relevant ones. However, you can turn the filtering off and see Events from the complete scope. To do so:\nClick the Dashboard Settings (three dots) icon and select Events.\nUse the toggle button to turn off Filter events by dashboard Scope.\nClick Save.\nSimilarly, you can filter Events by Scope in Explore.\nKnown Issues Time Chart may encounter some response time delays\nNot all the functionality from the existing dashboards will be available in the new dashboards. The following functionalities are not yet fully functional or not yet available:\nGauge chart\nText Panel\nTop Chart\nTable\nOctober 11, 2019Ability to \u0026ldquo;Favorite\u0026rdquo; a DashboardUsers can click the star icon to mark a \u0026ldquo;Favorite\u0026rdquo; dashboard, which will then be listed under \u0026ldquo;My Favorites\u0026rdquo; in the Dashboard view.\nEnhancement: Additional Metrics SegmentationThis change enables Sysdig Monitor to segment metrics file.bytes.in and file.bytes.out by file.mount and file.name.\nEnhancement: New Documentation Site at docs.sysdig.comSysdig\u0026rsquo;s documentation platform has been upgraded and moved to docs.sysdig.com.\nImprovements include:\nLook and feel: Updated to match the rest of the Sysdig branding\nSearch: Enhanced search speed, accuracy, and ease\nStructure and content: Enhancements to content have been added and are being continuously updated\nFeedback: Buttons on each page enable users to communicate directly with the documentation team.\nAugust 14, 2019New Default Kubernetes GroupingGroupings for Kubernetes have been modified. This updated Grouping is available to new teams. Default groupings are immutable–-they cannot be modified or deleted other than by copying. Modifying a copy is allowed.\nNew Groupings:\nClusters and Nodes (cluster.name \u0026gt; node.name \u0026gt; pod.name \u0026gt; container.name)\nDeployments (cluster.name \u0026gt; namespace.name \u0026gt; deployment.name \u0026gt; pod.name \u0026gt; container.name)\nServices ( cluster.name \u0026gt; namespace.name \u0026gt; service.name \u0026gt; pod.name \u0026gt; container.name)\nStatefulsets (cluster.name \u0026gt; namespace.name \u0026gt; statefulset.name \u0026gt; pod.name \u0026gt; container.name)\nDaemonsets (cluster.name \u0026gt; namespace.name \u0026gt; daemonset.name \u0026gt; pod.name \u0026gt; container.name)\nReplicaSets (cluster.name \u0026gt; namespace.name \u0026gt; deployment.name \u0026gt; replicaset.name \u0026gt; pod.name)\nHPAs (cluster.name \u0026gt; namespace.name \u0026gt; hpa.name \u0026gt; pod.name \u0026gt; container.name)\nFor more information, see Grouping, Scoping, and Segmenting Metrics.\nEnhanced Event NotificationThe ability to customize the subject and body of alert notifications with variables has been extended to Event notifications. Event titles and notification messages are in sync in the following cases:\nEvent feed on the Events page\nEvent overlay on Dashboards page\nFor more information, see Events.\nUnits for MetricsThe format of metric units are the same for the following:\nThe CPU and Memory metrics for Host and Container.\nKube-state CPU and Memory metrics.\nIntroducing the same format now makes the comparison of those metrics easier on a chart.\nContainer SegmentationSysdig now supports segmenting all net.* metrics at container or pod level by low level net.* dimensions, such as net.http.url or net.http.status.code. Container-based teams now display segmentations for net.http.* metrics as expected. The net.http.url and net.http.status.codes are displayed if you select a container-based team as it does for a host-based team for the same cluster.\nDisplay Instance NameInstance name in the Sysdig Monitor UI is now visible during creating and editing it. Instance names are displayed right below the username in the user dialog for switching teams.\nDefault Dashboard for Cluster and Node CapacityKubernetes Cluster and Node Capacity Dashboard has been refreshed to add actual usage of CPU and Memory compared to Requests, Limits and Allocatable capacity.\nAggregation for Kubernetes Nodes HealthAggregation method has been refreshed for Kubernetes Node metrics. The Kubernetes Node Health dashboard has been updated with metric aggregations that are \u0026lsquo;summed\u0026rsquo; across all containers running on the node to reflect accurate node level data.\nJuly 11, 2019Enhanced Dashboard MenuThe Dashboard menu features a drawer-style popover that displays a list of Dashboards you own and those shared by your team. With the popover menu, you can add new Dashboards and search for existing ones. Click a Dashboard name to access the relevant Dashboard page where you can continue with the regular Dashboard settings.\nCustomize Alert Notification TemplateSysdig Monitor alerts now provide an option to customize the messages that are sent with alert notifications in email and other channels, such as Pagerduty and Webhook.\nUse the Alert Editor to input dynamic variables, such as hostname, or a hyperlink, and to add custom messages in plain text to the notifications for intended recipients. You can modify both the subject and the body of the alert notification with a hyperlink or a variable. For example, you can add an agent id or a link to a Dashboard to the message. This can help provide context for troubleshooting the errors that triggered the alert.\nFor more information, see Customizing Alert Notification.\nPrometheus Remote ScrapingSysdig Monitor can now collect Prometheus metrics from remote endpoints with minimal configuration.\nRemote endpoints (remote hosts) refer to hosts where the Sysdig agent cannot be deployed, e.g., a Kubernetes master node on managed Kubernetes services such as GKE and EKS, where user workload cannot be deployed. To enable remote scraping on such hosts, simply identify an agent to perform the scraping and declare the endpoint configurations in the agent configuration file.\nThe collected Prometheus metrics are reported under and associated with the agent that performed the scraping, rather than with a process.\nEnhancements to Kafka AppCheckKafka integrations can now support authentication and SSL/TLS. If authentication or SSL/TLS are enabled in Kafka, see Apache Kafka Example 5 for how to enable configuration details on the Sysdig side.\nTwo New Metrics for Accurate Pod CountsTwo new Kubernetes metrics, kubernetes.namespace.pod.desired.count and kubernetes.namespace.pod.available.count, have been added at the Namespace level to track desired and available pod counts.\nFor earlier release notes, please see Sysdig Monitor SaaS Release Notes, here.\n","url":"https://docs.sysdig.com/en/release-notes/saas-sysdig-monitor-release-notes/2019-archive/"},{"id":778,"title":"Explore (Legacy)","content":" This feature is now deprecated. See the Explore documentation to learn about the latest Explore functionalities.\nSwitch GroupingsSysdig Monitor detects and collects the metrics associated with your infrastructure once the agent is deployed in your environment. Use the Explore UI to search, group, and troubleshoot your infrastructure components.\nTo switch between available data sources:\nOn the Explore tab, click the My Groupings drop-down menu:\nSelect the desired grouping from the drop-down list.\nGroupings EditorThe Groupings Editor helps you create and manage your infrastructure groupings.\nUse Drill-Down MenuSysdig Monitor users can drill down into the infrastructure by using the numerous dashboards and metrics available for display in the Explore UI. These displays can be found by selecting an infrastructure object, and opening the drill-down menu.\nSysdig Monitor only displays the metrics and dashboards that are relevant to the selected infrastructure object.\nMetricsSysdig Monitor users can view specific metrics for an infrastructure object by navigating the drill-down menu:\nOn the Explore tab, open the drill-down menu.\nNavigate to Search Metrics and Dashboard.\nSelect the desired metrics.\nThe metric will now be presented on the Explore UI, until the user navigates away from it.\nThe scope of the metric, when viewed via the drill-down menu, is set to the infrastructure object that you have selected.\nTroubleshooting ViewsThe drill-down menu displays all the default dashboard templates relevant to the selected infrastructure object. These Troubleshooting Views are broken into the following sections:\nThe scope of the Troubleshooting View, when viewed via the drill-down menu, is set to the infrastructure object that you have selected from the drill-down.\nApplication Dashboards\nAWS CloudWatch Dashboards\nCompliance \u0026amp; Security Dashboards\nContainers Dashboards\nDocker Dashboards\nHosts Infrastructure Dashboards\nKubernetes Control Plane Dashboards\nKubernetes Dashboards\nMarathon Dashboards\nMesos Dashboards\nOpenShift Dashboards\nRancher Dashboards\nSysdig Secure Dashboards\nTroubleshooting Dashboards\nTo navigate to the Troubleshooting Views:\nOn the Explore tab, select an infrastructure object.\nOpen the drill-down menu and select the desired infrastructure element\nNavigate to Search Metrics and Dashboard.\nSelect the desired troubleshooting view.\nThe selected dashboard will now be presented on the screen, until you navigate away from it.\nPin and Unpin the Drill-Down Menu On the Explore tab, select an infrastructure object.\nOpen the drill-down menu.\nClick Pin Menu to pin the menu to the Explore tab.\nTo unpin the menu, click Unpin Menu at the bottom of the menu.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/legacy-explore/"},{"id":779,"title":"Group Mappings for Google Workspace","content":" Log in to the Google Workspace portal and access the Admin console.\nSelect Menu \u0026gt; Apps \u0026gt; Web and mobile apps.\nAccess the Attribute mapping section.\nOn the Group Attribute Statements (optional) screen in the Group membership (optional) section, specify the following:\nGoogle groups: Select all the groups that users can join as members. Only groups the user is a member of will be sent a SAML response at login. App attribute: The name of the attribute to use, for example, \u0026ldquo;groups\u0026rdquo;. Click Save.\n","url":"https://docs.sysdig.com/en/administration/group-mappings-google_workspace_saml/"},{"id":780,"title":"Manage Host Shield Privileges","content":"You can modify Host Shield privileges to enhance the security of your Linux deployments. Host Shield can operate with the host.privileged parameter set to false, enhancing your deployment\u0026rsquo;s security posture without interrupting essential monitoring and security functions. We recommend configuring Host Shield with host.privileged: false to reduce the attack surface and align with container security best practices.\nBenefits of Setting host.privileged: falseEnhanced Security: By setting host.privileged to false, you can limit Linux capabilities, minimizing the attack surface.\nPrerequisites Host Shield version 14.6.0 and later.\nKubernetes deployment managed with the shield Helm chart version \u0026gt;= 1.38.0.\nHost Shield requires the Universal eBPF driver.\nLimitation Host Shield does not support Google Kubernetes Engine (GKE) Autopilot.\nHost Shield does not support AWS Bottlerocket on ARM architecture.\nConfigure Least Privileged ModeTo set host.privileged to false using the shield Helm chart, specify shield.host.privileged=false.\nThe Helm chart automatically detects whether OpenShift is in use and applies the appropriate set of permissions.\n","url":"https://docs.sysdig.com/en/sysdig-secure/host-shield-privileges/"},{"id":781,"title":"Metrics","content":"Metrics DictionaryFor a list of all metrics supported by the Sysdig product suite, as well as kube state and cloud provider metrics see:\nMetrics Library in Prometheus Format: Prometheus-compatible notation. Application Metrics in Sysdig Legacy Format: Sysdig legacy notation. To see a mapping between Prometheus notation and Sysdig notation, see Metrics and Label Mapping.\nDifference between a Metric and a Time Series A metric is a name representing a particular set of data. A time series is a combination of a metric name associated with a unique set of label values. Metric Time Series Value Description http_requests http_requests{method=\u0026quot;GET\u0026quot;, endpoint=\u0026quot;/api/v2/users\u0026quot;} 100 number of GET HTTP requests to /api/v2/users http_requests{method=\u0026quot;POST\u0026quot;, endpoint=\u0026quot;/api/v2/users\u0026quot;} 250 number of POST HTTP requests to /api/v2/users http_requests{status=\u0026quot;500\u0026quot;, endpoint=\u0026quot;/api/v2/users\u0026quot;} 10 Number of HTTP requests returning 500 to /api/v2/users Default MetricsDefault metrics are generated by the Sysdig Agent based on its observation of the system. These metrics provide essential monitoring data for hosts, containers, and processes. Examples of default metrics include:\nSystem metrics for hosts, containers, and processes, such as CPU usage (ex: sysdig_host_cpu_cores_total). Orchestrator metrics from platforms like Kubernetes or Mesos, such as workload status (ex: kube_workload_status_ready). Network metrics that capture network traffic details (ex: sysdig_connection_net_in_bytes). HTTP metrics, such as HTTP request counts by status code (ex: sysdig_container_net_http_statuscode_request_count). These default metrics are primarily collected from two sources: system calls (syscalls) and Kubernetes.\nCustom MetricsCustom metrics on the other hand, refer to any metrics that are not natively generated by Sysdig. There are three main types of custom metrics:\nMetrics collected by the Sysdig Agent: This includes StatsD metrics, JMX metrics, App Checks, and Prometheus metrics. For more details, see Prometheus Metrics, Monitoring Integrations, JMX Metrics, and StatsD Metrics.\nMetrics received via Prometheus Remote Write: These are metrics sent directly to Sysdig Monitor without using the Sysdig Agent. See Prometheus Remote Write for more information.\nMetrics from cloud integrations: Metrics received through cloud service integrations. See Cloud Accounts for more information.\nTime series generated by custom metrics count towards your time series usage. See Time Series Billing for more information.\nCharacter LimitsSysdig places character limits on metrics to prevent performance degradation. The default limits are:\nMetric name: 1024 characters.\nLabel Name: 255 characters.\nLabel Value: 255 characters.\nIf we take sysdig_connection_net_request_count{cmd_line=\u0026quot;/lib/systemd/systemd-timesyncd\u0026quot;} for example:\nThe metric name is sysdig_connection_net_request_count. The label name is cmd_line. The label value is /lib/systemd/systemd-timesyncd. If a metric name, label name, or label value exceeds the character limit, it will be rejected by the backend and will not appear in queries.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/metrics/"},{"id":782,"title":"NGINX Metrics","content":"See Application Integrations for more information.\nnginx.net.conn_dropped_per_sThe rate of connections dropped.\nnginx.net.conn_opened_per_sThe rate of connections opened.\nnginx.net.connectionsThe total number of active connections.\nnginx.net.readingThe number of connections reading client requests.\nnginx.net.request_per_sThe rate of requests processed.\nnginx.net.waitingThe number of keep-alive connections waiting for work.\nnginx.net.writingThe number of connections waiting on upstream responses and/or writing responses back to the client.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/nginx-metrics/"},{"id":783,"title":"PostgreSQL","content":"If PostgreSQL is installed in your environment, the Sysdig agent will automatically connect in most cases. In some conditions, you may need to create a specific user for Sysdig and edit the default entries to connect.\nSee the Default Configuration section, below. The Sysdig agent automatically collects all metrics with the default configuration when correct credentials are provided.\nThis page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nPostgreSQL SetupPostgreSQL will be auto-discovered and the agent will connect through the Unix socket using the Default Configuration with the **postgres **default user. If this does not work, you can create a user for Sysdig Monitor and give it enough permissions to read Postgres stats. To do this, execute the following example statements on your server:\ncreate user sysdig-cloud with password \u0026#39;password\u0026#39;; grant SELECT ON pg_stat_database to sysdig_cloud; Sysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s default.dragent.yaml uses the following code to connect with Postgres.\napp_checks: - name: postgres pattern: comm: postgres port: 5432 conf: unix_sock: \u0026#34;/var/run/postgresql/\u0026#34; username: postgres If a special user for Sysdig is created, then update dragent.yaml file with the Expanded Example, below.\nNever edit default.dragent.yaml directly; always edit only dragent.yaml.\nExample 1: Special UserUpdate the username and password created for the Sysdig agent in the respective fields, as follows:\napp_checks: - name: postgres pattern: comm: postgres port: 5432 conf: username: sysdig-cloud password: password Example 2: Connecting on Unix SocketIf Postgres is listening on Unix socket /tmp/.s.PGSQL.5432, set value of unix_sock to /tmp/\napp_checks: - name: postgres pattern: comm: postgres port: 5432 conf: unix_sock: \u0026#34;/tmp/\u0026#34; username: postgres Example 3: RelationsLists of relations/tables can be specified to track per-relation metrics.\nA single relation can be specified in two ways:\nSingle relation with exact name against relation_name.\nRegex to include all matching relation against relation_regex.\nIf schemas are not provided, all schemas will be included. dbname is to be provided if relations is specified.\napp_checks: - name: postgres pattern: comm: postgres port: 5432 conf: username: \u0026lt;username\u0026gt; password: \u0026lt;password\u0026gt; dbname: \u0026lt;user_db_name\u0026gt; relations: - relation_name: \u0026lt;table_name_1\u0026gt; schemas: - \u0026lt;schema_name_1\u0026gt; - relation_regex: \u0026lt;table_pattern\u0026gt; Example 4: Other Optional Parametersapp_checks: - name: postgres check_module: postgres pattern: comm: postgres port: 5432 conf: username: postgres unix_sock: \u0026#34;/var/run/postgresql\u0026#34; dbname: \u0026lt;user_db_name\u0026gt; #collect_activity_metrics: true #collect_default_database: true #tag_replication_role: true Optional Parameters Config Parameter\nDescription\nDefault Value\ncollect_activity_metrics\nWhen set to true, it will enable metrics from pg_stat_activity. New metrics added will be:\npostgresql.active_queries\npostgresql.transactions.idle_in_transaction\npostgresql.transactions.open\npostgresql.waiting_queries\nfalse\ncollect_default_database\nWhen set to true, it will collect statistics from default database which is postgres. All metrics from postgres database will have tag db:postgres\nfalse\ntag_replication_role\nWhen set to true, metrics and checks will be tagged with replication_role:\u0026lt;master|standby\u0026gt;\nfalse\nOptional Parameters\nExample 5: Custom Metrics Using Custom QueriesPersonalized custom metrics can be collected from Postgres using custom queries.\napp_checks: - name: postgres pattern: comm: postgres port: 5432 conf: unix_sock: \u0026#34;/var/run/postgresql/\u0026#34; username: postgres custom_queries: - metric_prefix: postgresql.custom query: \u0026lt;QUERY\u0026gt; columns: - name: \u0026lt;COLUNMS_1_NAME\u0026gt; type: \u0026lt;COLUMNS_1_TYPE\u0026gt; - name: \u0026lt;COLUNMS_2_NAME\u0026gt; type: \u0026lt;COLUMNS_2_TYPE\u0026gt; tags: - \u0026lt;TAG_KEY\u0026gt;:\u0026lt;TAG_VALUE\u0026gt; Option Required Description metric_prefix Yes Each metric starts with the chosen prefix. query Yes This is the SQL to execute. It can be a simple statement or a multi-line script. All of the rows of the results are evaluated. Use the pipe if you require a multi-line script columns Yes This is a list representing each column ordered sequentially from left to right. The number of columns must equal the number of columns returned in the query. There are 2 required pieces of data:- name: This is the suffix to append to the metric_prefix to form the full metric name. If the type is specified as tag, the column is instead applied as a tag to every metric collected by this query.- type: This is the submission method (gauge, count, rate, etc.). This can also be set to \u0026rsquo;tag\u0026rsquo; to tag each metric in the row with the name and value of the item in this column tags No A list of tags to apply to each metric (as specified above). Optional Parameters\nMetrics AvailableSee PostgreSQL Metrics.\nResult in the Monitor UIDefault DashboardThe default PostgreSQL dashboard includes combined metrics and individual metrics in an overview page.\nOther ViewsYou can also view individual metric charts from a drop-down menu in an Explore view.\n","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/postgresql/"},{"id":784,"title":"Prometheus Public API","content":"Prometheus API Endpoint Support in Sysdig MonitorSysdig Monitor exposes a subset of the Prometheus HTTP API, allowing users to query and ingest metrics using familiar Prometheus-compatible endpoints. The table below outlines which endpoints are currently supported, along with their required permissions.\nEndpoint Path Supported Required Permission Instant Query /prometheus/api/v1/query ✅ metrics-data.read Range Query /prometheus/api/v1/query_range ✅ metrics-data.read Series Query /prometheus/api/v1/series ✅ metrics-data.read Labels Query /prometheus/api/v1/labels ✅ metrics-data.read Label Values Query /prometheus/api/v1/label/{labelName}/values ✅ metrics-data.read Metric Metadata /prometheus/api/v1/metadata ✅ metrics-data.read Rules /prometheus/api/v1/rules ✅ alerts.read Alerts /prometheus/api/v1/alerts ✅ alerts.read Remote Write Ingestion /prometheus/api/v1/write ✅ ingest.prws Format Query /prometheus/api/v1/format_query ❌ – Parse Query /prometheus/api/v1/parse_query ❌ – Query Exemplars /prometheus/api/v1/query_exemplars ❌ – Targets /prometheus/api/v1/targets ❌ – Target Metadata /prometheus/api/v1/targets/metadata ❌ – Alertmanagers /prometheus/api/v1/alertmanagers ❌ – Config /prometheus/api/v1/status/config ❌ – Flags /prometheus/api/v1/status/flags ❌ – Runtime Information /prometheus/api/v1/status/runtimeinfo ❌ – Build Information /prometheus/api/v1/status/buildinfo ❌ – TSDB Stats /prometheus/api/v1/status/tsdb ❌ – WAL Replay /prometheus/api/v1/status/walreplay ❌ – Snapshot /prometheus/api/v1/admin/tsdb/snapshot ❌ – Delete Series /prometheus/api/v1/admin/tsdb/delete_series ❌ – Clean Tombstones /prometheus/api/v1/admin/tsdb/clean_tombstones ❌ – Active Notifications /prometheus/api/v1/notifications ❌ – Live Notifications /prometheus/api/v1/notifications/live ❌ – Access Next Gen API DocsFor further detail regarding API usage, Access Next Gen API docs.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/prometheuspublicapi/"},{"id":785,"title":"Prometheus Public API Service Limits","content":"Service LimitsThe following limits apply to Prometheus query endpoints in Sysdig Monitor:\nLimit Category Value Applies To Notes Maximum number of different metrics a query can scan 10 /query, /query_range A query that scans more than this number of different metrics (e.g. using a regex with the name label) will be rejected. Maximum number of samples returned per time series 1500 /query If the combination of the start, end and step parameters results in more than this number of samples per time series, the query will be rejected. Number of time series returned for queries not using PromQL aggregations. 1000 /query, /query_range If a query is not leveraging any PromQL function (e.g. max(), avg_over_time()), the number of returned time series will be limited to this number. A warning message will be returned as a part of the response. Maximum resulting segments 100k /query, /query_range For queries that utilize an aggregation operator (e.g. avg()), the number of segments returned will be capped at this number Maximum concurrent queries 200 /query, /query_range, /series Excess queries may be queued or rejected. Maximum rate of samples scanned per minute 4 Billion samples per minute /query, /query_range Queries after this rate has been exceed will be rejected. Query timeout 2 minutes All query endpoints A global timeout for all queries. Best PracticesTo ensure stable performance and avoid hitting service limits:\nScope queries narrowly using label filters to reduce the number of returned time series. Limit time ranges to avoid querying wide historical windows unless needed. Use appropriate step values to reduce result size when querying large time ranges. ","url":"https://docs.sysdig.com/en/sysdig-monitor/prometheuspublicapiservicelimits/"},{"id":786,"title":"Integrate with Splunk","content":"The official Sysdig Splunk Technical Add-on (TA), available from the Splunk app store (Splunkbase), leverages the Sysdig APIs to extract the Vulnerability Management runtime findings for Workloads and Hosts. This allows Security Operation Centers to ingest vulnerability information produced by Sysdig into Splunk natively.\nSee Sysdig VM Splunk TA on Splunkbase for more information.\nThe Splunk TA for Sysdig Vulnerabilities is distinct from the one used for Event Forwarding. See Forwarding to Splunk.\nPrerequisites Splunk Enterprise 9.1.1+ Sysdig SaaS Platform with Vulnerability Management Scanning in Runtime (Workload and Host) Secure API token with Vulnerability Management Scan Results authorization. See Service Accounts. Configure the IntegrationInstall from the Splunkbase Marketplace Log in to Splunk and search for Sysdig in Splunkbase.\nSelect Sysdig VM Splunk TA and click Download, agreeing to the required terms and conditions.\nThe .tgz file will be downloaded.\nIn Splunk, click Apps and then Manage Apps from the dropdown.\nClick Install App from File.\nClick Choose File and select the .tgz file you downloaded from Splunkbase. If you are upgrading, select Upgrade app.\nThe add-on will be imported. Splunk may need to restart.\nFrom Splunk\u0026rsquo;s main navigation menu, select Settings and then Indexes from the dropdown. Click on New Index.\nEnter an Index name, for example, app_sysdig, and ensure App is set to Sysdig VM Splunk TA.\nClick Save.\nSysdig VM Splunk TA should now be available under Apps in Splunk.\nSelect Apps \u0026gt; Sysdig VM Splunk TA \u0026gt; Inputs \u0026gt; Create New Input.\nSpecify the following:\nInterval: The input frequency. Since it pulls a lot of data, Sysdig recommends using 86400 seconds (once per day).\nIndex: Enter the Index name you chose earlier. For example, app_sysdig.\nSysdig Secure Token: Add the access key mentioned in the Prerequisites.\nNVD API Key: Provide a NVD API Key to retrieve vulnerability descriptions.\nSysdig Secure URL: Enter your Sysdig Secure URL based on your region (must include https://).\nExamples:\nhttps://secure.sysdig.com https://us2.app.sysdig.com https://eu1.app.sysdig.com \u0026hellip; Vulnerability details: Select the type of vulnerability details to include in the events. Available values:\npackage_data: Package data nvd_data: NVD Data vuln_description: Vulnerability Description, fetched from NVD Click Add. View the Splunk events by entering index=\u0026quot;app_sysdig\u0026quot; in the search bar.\n","url":"https://docs.sysdig.com/en/sysdig-secure/splunk-integration/"},{"id":787,"title":"NGINX Plus Metrics","content":"See Application Integrations for more information.\nnginx.plus.cache.bypass.bytesThe total number of bytes read from the proxied server.\nnginx.plus.cache.bypass.bytes_writtenThe total number of bytes written to the cache.\nnginx.plus.cache.bypass.responsesThe total number of responses from the cache.\nnginx.plus.cache.bypass.responses_writtenThe total number of responses written to the cache.\nnginx.plus.cache.coldBoolean. Defines whether the cache loader process is still loading data from the disk into the cache or not.\nnginx.plus.cache.expired.bytesThe total number of bytes read from the proxied server.\nnginx.plus.cache.expired.bytes_writtenThe total number of bytes written to the cache.\nnginx.plus.cache.expired.responsesThe total number of responses not taken from the cache\nnginx.plus.cache.expired.responses_writtenThe total number of responses written to the cache\nnginx.plus.cache.hit.bytesThe total number of bytes read from the cache\nnginx.plus.cache.hit.responsesThe total number of responses read from the cache\nnginx.plus.cache.max_sizeThe limit on the maximum size of the cache specified in the configuration\nnginx.plus.cache.miss.bytesThe total number of bytes read from the proxied server\nnginx.plus.cache.miss.bytes_writtenThe total number of bytes written to the cache\nnginx.plus.cache.miss.responsesThe total number of responses not taken from the cache\nnginx.plus.cache.miss.responses_writtenThe total number of responses written to the cache\nnginx.plus.cache.revalidated.bytesThe total number of bytes read from the cache\nnginx.plus.cache.revalidated.responseThe total number of responses read from the cache\nnginx.plus.cache.sizeThe current size of the cache\nnginx.plus.cache.stale.bytesThe total number of bytes read from the cache\nnginx.plus.cache.stale.responsesThe total number of responses read from the cache\nnginx.plus.cache.updating.bytesThe total number of bytes read from the cache\nnginx.plus.cache.updating.responsesThe total number of responses read from the cache\nnginx.plus.connections.acceptedThe total number of accepted client connections.\nnginx.plus.connections.activeThe current number of active client connections.\nnginx.plus.connections.droppedThe total number of dropped client connections.\nnginx.plus.connections.idleThe current number of idle client connections.\nnginx.plus.generationThe total number of configuration reloads\nnginx.plus.load_timestampTime of the last reload of configuration (time since Epoch).\nnginx.plus.pidThe ID of the worker process that handled status request.\nnginx.plus.plus.upstream.peers.failsThe total number of unsuccessful attempts to communicate with the server.\nnginx.plus.ppidThe ID of the master process that started the worker process\nnginx.plus.processes.respawnedThe total number of abnormally terminated and re-spawned child processes.\nnginx.plus.requests.currentThe current number of client requests.\nnginx.plus.requests.totalThe total number of client requests.\nnginx.plus.server_zone.discardedThe total number of requests completed without sending a response.\nnginx.plus.server_zone.processingThe number of client requests that are currently being processed.\nnginx.plus.server_zone.receivedThe total amount of data received from clients.\nnginx.plus.server_zone.requestsThe total number of client requests received from clients.\nnginx.plus.server_zone.responses.1xxThe number of responses with 1xx status code.\nnginx.plus.server_zone.responses.2xxThe number of responses with 2xx status code.\nnginx.plus.server_zone.responses.3xxThe number of responses with 3xx status code.\nnginx.plus.server_zone.responses.4xxThe number of responses with 4xx status code.\nnginx.plus.server_zone.responses.5xxThe number of responses with 5xx status code.\nnginx.plus.server_zone.responses.totalThe total number of responses sent to clients.\nnginx.plus.server_zone.sentThe total amount of data sent to clients.\nnginx.plus.slab.pages.freeThe current number of free memory pages\nnginx.plus.slab.pages.usedThe current number of used memory pages\nnginx.plus.slab.slots.failsThe number of unsuccessful attempts to allocate memory of specified size\nnginx.plus.slab.slots.freeThe current number of free memory slots\nnginx.plus.slab.slots.reqsThe total number of attempts to allocate memory of specified size\nnginx.plus.slab.slots.usedThe current number of used memory slots\nnginx.plus.ssl.handshakesThe total number of successful SSL handshakes.\nnginx.plus.ssl.handshakes_failedThe total number of failed SSL handshakes.\nnginx.plus.ssl.session_reusesThe total number of session reuses during SSL handshake.\nnginx.plus.stream.server_zone.connectionsThe total number of connections accepted from clients\nnginx.plus.stream.server_zone.connectionsThe total number of connections accepted from clients\nnginx.plus.stream.server_zone.discardedThe total number of requests completed without sending a response.\nnginx.plus.stream.server_zone.discardedThe total number of requests completed without sending a response.\nnginx.plus.stream.server_zone.processingThe number of client requests that are currently being processed.\nnginx.plus.stream.server_zone.processingThe number of client requests that are currently being processed.\nnginx.plus.stream.server_zone.receivedThe total amount of data received from clients.\nnginx.plus.stream.server_zone.receivedThe total amount of data received from clients.\nnginx.plus.stream.server_zone.sentThe total amount of data sent to clients.\nnginx.plus.stream.server_zone.sentThe total amount of data sent to clients.\nnginx.plus.stream.server_zone.sessions.1xxThe number of responses with 1xx status code.\nnginx.plus.stream.server_zone.sessions.2xxThe number of responses with 2xx status code.\nnginx.plus.stream.server_zone.sessions.3xxThe number of responses with 3xx status code.\nnginx.plus.stream.server_zone.sessions.4xxThe number of responses with 4xx status code.\nnginx.plus.stream.server_zone.sessions.5xxThe number of responses with 5xx status code.\nnginx.plus.stream.server_zone.sessions.totalThe total number of responses sent to clients.\nnginx.plus.stream.upstream.peers.activeThe current number of connections\nnginx.plus.stream.upstream.peers.backupA boolean value indicating whether the server is a backup server.\nnginx.plus.stream.upstream.peers.connectionsThe total number of client connections forwarded to this server.\nnginx.plus.stream.upstream.peers.downstartThe time (time since Epoch) when the server became \u0026ldquo;unavail\u0026rdquo; or \u0026ldquo;checking\u0026rdquo; or \u0026ldquo;unhealthy\u0026rdquo;\nnginx.plus.stream.upstream.peers.downtimeTotal time the server was in the \u0026ldquo;unavail\u0026rdquo; or \u0026ldquo;checking\u0026rdquo; or \u0026ldquo;unhealthy\u0026rdquo; states.\nnginx.plus.stream.upstream.peers.failsThe total number of unsuccessful attempts to communicate with the server.\nnginx.plus.stream.upstream.peers.health_checks.checksThe total number of health check requests made.\nnginx.plus.stream.upstream.peers.health_checks.failsThe number of failed health checks.\nnginx.plus.stream.upstream.peers.health_checks.last_passedBoolean indicating if the last health check request was successful and passed tests.\nnginx.plus.stream.upstream.peers.health_checks.unhealthyHow many times the server became unhealthy (state \u0026ldquo;unhealthy\u0026rdquo;).\nnginx.plus.stream.upstream.peers.idThe ID of the server.\nnginx.plus.stream.upstream.peers.receivedThe total number of bytes received from this server.\nnginx.plus.stream.upstream.peers.selectedThe time (time since Epoch) when the server was last selected to process a connection.\nnginx.plus.stream.upstream.peers.sentThe total number of bytes sent to this server.\nnginx.plus.stream.upstream.peers.unavailHow many times the server became unavailable for client connections (state \u0026ldquo;unavail\u0026rdquo;).\nnginx.plus.stream.upstream.peers.weightWeight of the server.\nnginx.plus.stream.upstream.zombiesThe current number of servers removed from the group but still processing active client connections.\nnginx.plus.timestampCurrent time since Epoch.\nnginx.plus.upstream.keepaliveThe current number of idle keepalive connections.\nnginx.plus.upstream.peers.activeThe current number of active connections.\nnginx.plus.upstream.peers.backupA boolean value indicating whether the server is a backup server.\nnginx.plus.upstream.peers.downstartThe time (since Epoch) when the server became \u0026ldquo;unavail\u0026rdquo; or \u0026ldquo;unhealthy\u0026rdquo;.\nnginx.plus.upstream.peers.downtimeTotal time the server was in the \u0026ldquo;unavail\u0026rdquo; and \u0026ldquo;unhealthy\u0026rdquo; states.\nnginx.plus.upstream.peers.health_checks.checksThe total number of health check requests made.\nnginx.plus.upstream.peers.health_checks.failsThe number of failed health checks.\nnginx.plus.upstream.peers.health_checks.last_passedBoolean indicating if the last health check request was successful and passed tests.\nnginx.plus.upstream.peers.health_checks.unhealthyHow many times the server became unhealthy (state \u0026ldquo;unhealthy\u0026rdquo;).\nnginx.plus.upstream.peers.idhe ID of the server.\nnginx.plus.upstream.peers.receivedThe total amount of data received from this server.\nnginx.plus.upstream.peers.requestsThe total number of client requests forwarded to this server.\nnginx.plus.upstream.peers.responses.1xxThe number of responses with 1xx status code.\nnginx.plus.upstream.peers.responses.1xx_countThe number of responses with 1xx status code (shown as count).\nnginx.plus.upstream.peers.responses.2xxThe number of responses with 2xx status code.\nnginx.plus.upstream.peers.responses.2xx_countThe number of responses with 2xx status code (shown as count).\nnginx.plus.upstream.peers.responses.3xxThe number of responses with 3xx status code.\nnginx.plus.upstream.peers.responses.3xx_countThe number of responses with 3xx status code (shown as count).\nnginx.plus.upstream.peers.responses.4xxThe number of responses with 4xx status code.\nnginx.plus.upstream.peers.responses.4xx_countThe number of responses with 4xx status code (shown as count).\nnginx.plus.upstream.peers.responses.5xxThe number of responses with 5xx status code.\nnginx.plus.upstream.peers.responses.5xx_countThe number of responses with 5xx status code (shown as count).\nnginx.plus.upstream.peers.responses.totalThe total number of responses obtained from this server.\nnginx.plus.upstream.peers.selectedThe time (since Epoch) when the server was last selected to process a request (1.7.5).\nnginx.plus.upstream.peers.sentThe total amount of data sent to this server.\nnginx.plus.upstream.peers.unavailHow many times the server became unavailable for client requests (state \u0026ldquo;unavail\u0026rdquo;) due to the number of unsuccessful attempts reaching the max_fails threshold.\nnginx.plus.upstream.peers.weightThe weight of the server.\nnginx.plus.versionThe NGINX version.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/nginx-plus-metrics/"},{"id":788,"title":"RabbitMQ","content":"The Sysdig agent automatically collects all metrics with the default configuration. You may need to edit the dragent.yaml file if a metrics limit is reached.\nThis page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nRabbitMQ SetupEnable the RabbitMQ management plugin. See RabbitMQ\u0026rsquo;s documentation to enable it.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with RabbitMQ and collect all metrics.\napp_checks: - name: rabbitmq pattern: port: 15672 conf: rabbitmq_api_url: \u0026#34;http://localhost:15672/api/\u0026#34; rabbitmq_user: guest rabbitmq_pass: guest The RabbitMQ app check tracks various entities, such as exchanges, queues and nodes. Each of these entities has its maximum limits. If the limit is reached, metrics can be controlled by editing the dragent.yaml file, as in the following examples.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1: Manage logging_intervalWhen a maximum limit is exceeded, the app check will log an info message:\nrabbitmq: Too many \u0026lt;entity type\u0026gt; (\u0026lt;number of entities\u0026gt;) to fetch and maximum limit is (\u0026lt;configured limit\u0026gt;). You must choose the \u0026lt;entity type\u0026gt; you are interested in by editing the dragent.yaml configuration file This message is suppressed by a configuration parameter, logging_interval.\nIts default value is 300 seconds. This can be altered by specifying a different value in dragent.yaml.\napp_checks: - name: rabbitmq pattern: port: 15672 conf: rabbitmq_api_url: \u0026#34;http://localhost:15672/api/\u0026#34; rabbitmq_user: guest rabbitmq_pass: guest logging_interval: 10 # Value in seconds. Default is 300 Example 2: Specify Nodes, Queues, or ExchangesEach of the tracked RabbitMQ entities has its maximum limits. As of Agent v10.5.1, the default limits are as follows:\nExchanges: 16 per-exchange metrics\nQueues: 20 per-queue metrics\nNodes: 9 per-node metrics\nThe max_detailed_* settings for the RabbitMQ app check do not limit the reported number of queues, exchanges, and node, but the number of generated metrics for the objects. For example, a single queue might report up to 20 metrics, and therefore, set max_detailed_queues to 20 times the actual number of queues.\nThe metrics for these entities are tagged. If any of these entities are present but no transactions have occurred for them, the metrics are still reported with 0 values, though without tags. Therefore, when segmenting these metrics, the tags will show as unset in the Sysdig Monitor Explore view. However, all such entities are still counted against the maximum limits. In such a scenario, you can specify the entity names for which you want to collect metrics in the dragent.yaml file.\napp_checks: - name: rabbitmq pattern: port: 15672 conf: rabbitmq_api_url: \u0026#34;http://localhost:15672/api/\u0026#34; rabbitmq_user: guest rabbitmq_pass: guest tags: [\u0026#34;queues:\u0026lt;queuename\u0026gt;\u0026#34;] nodes: - rabbit@localhost - rabbit2@domain nodes_regexes: - bla.* queues: - queue1 - queue2 queues_regexes: - thisqueue-.* - another_\\d+queue exchanges: - exchange1 - exchange2 exchanges_regexes: - exchange* Example 3: Custom tagsOptional tags can be applied to every emitted metric, service check, and/or event.\nNames can be specified by exact name or regular expression.\napp_checks: - name: rabbitmq pattern: port: 15672 conf: rabbitmq_api_url: \u0026#34;http://localhost:15672/api/\u0026#34; rabbitmq_user: guest rabbitmq_pass: guest tags: [\u0026#34;some_tag:some_value\u0026#34;] Example 4: filter_by_nodeUse filter_by_node: true if you want each node to report information localized to the node. Without this option, each node reports cluster-wide info (as presented by RabbitMQ itself). This option makes it easier to view the metrics in the UI by removing redundant information reported by individual nodes.\nDefault: false.\nPrerequisite: Sysdig agent v. 92.3 or higher.\napp_checks: - name: rabbitmq pattern: port: 15672 conf: rabbitmq_api_url: \u0026#34;http://localhost:15672/api/\u0026#34; rabbitmq_user: guest rabbitmq_pass: guest filter_by_node: true Metrics AvailableSee RabbitMQ Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/rabbitmq/"},{"id":789,"title":"RabbitMQ Metrics","content":"See Application Integrations for more information.\nrabbitmq.connectionsThe number of current connections to a given rabbitmq vhost. Each connection is tagged as rabbitmq_vhost:\u0026lt;vhost_name\u0026gt;.\nrabbitmq.connections.stateThe number of connections in the specified connection state.\nrabbitmq.exchange.messages.ack.countThe number of messages delivered to clients and acknowledged.\nrabbitmq.exchange.messages.ack.rateThe rate of messages delivered to clients and acknowledged per second.\nrabbitmq.exchange.messages.confirm.countThe number of messages confirmed.\nrabbitmq.exchange.messages.confirm.rateThe rate of messages confirmed per second.\nrabbitmq.exchange.messages.deliver_get.countThe sum of messages delivered in acknowledgement mode to consumers, in no-acknowledgement mode to consumers, in acknowledgement mode in response to basic.get, and in no-acknowledgement mode in response to basic.get.\nrabbitmq.exchange.messages.deliver_get.rateThe rate per second of the sum of messages delivered in acknowledgement mode to consumers, in no-acknowledgement mode to consumers, in acknowledgement mode in response to basic.get, and in no-acknowledgement mode in response to basic.get.\nrabbitmq.exchange.messages.publish_in.countThe number of messages published from channels into this exchange.\nrabbitmq.exchange.messages.publish_in.rateThe amount of messages published from channels into this exchange per second.\nrabbitmq.exchange.messages.publish_out.countThe number of messages published from this exchange into queues.\nrabbitmq.exchange.messages.publish_out.rateThe amount of messages published from this exchange into queues per second.\nrabbitmq.exchange.messages.publish.countThe number of messages published.\nrabbitmq.exchange.messages.publish.rateThe amount of messages published per second.\nrabbitmq.exchange.messages.redeliver.countThe number of subset of messages in deliver_get which had the redelivered flag set.\nrabbitmq.exchange.messages.redeliver.rateThe amount of subset of messages in deliver_get which had the redelivered flag set per second.\nrabbitmq.exchange.messages.return_unroutable.countThe number of messages returned to the publisher as unroutable.\nrabbitmq.exchange.messages.return_unroutable.rateThe amount of messages returned to publisher as unroutable per second.\nrabbitmq.node.disk_alarmDefines whether the node has a disk alarm configured.\nrabbitmq.node.disk_freeThe current free disk space.\nrabbitmq.node.fd_usedUsed file descriptors.\nrabbitmq.node.mem_alarmDefines whether the node has a memory alarm configured.\nrabbitmq.node.mem_usedThe total memory used in bytes.\nrabbitmq.node.partitionsThe number of network partitions this node is seeing.\nrabbitmq.node.run_queueThe average number of Erlang processes waiting to run.\nrabbitmq.node.runningDefines whether the node is running or not.\nrabbitmq.node.sockets_usedThe number of file descriptors used as sockets.\nrabbitmq.overview.messages.ack.countThe number of messages delivered to clients and acknowledged.\nrabbitmq.overview.messages.ack.rateThe rate of messages delivered to clients and acknowledged per second.\nrabbitmq.overview.messages.confirm.countThe number of messages confirmed.\nrabbitmq.overview.messages.confirm.rateThe rate of messages confirmed per second.\nrabbitmq.overview.messages.deliver_get.countThe sum of messages delivered in acknowledgement mode to consumers, in no-acknowledgement mode to consumers, in acknowledgement mode in response to basic.get, and in no-acknowledgement mode in response to basic.get.\nrabbitmq.overview.messages.deliver_get.rateThe rate per second of the sum of messages delivered in acknowledgement mode to consumers, in no-acknowledgement mode to consumers, in acknowledgement mode in response to basic.get, and in no-acknowledgement mode in response to basic.get.\nrabbitmq.overview.messages.publish_in.countThe number of messages published from channels into this overview.\nrabbitmq.overview.messages.publish_in.rateThe rate of messages published from channels into this overview per second.\nrabbitmq.overview.messages.publish_out.countThe number of messages published from this overview into queues.\nrabbitmq.overview.messages.publish_out.rateThe rate of messages published from this overview into queues per second.\nrabbitmq.overview.messages.publish.countThe number of messages published.\nrabbitmq.overview.messages.publish.rateThe rate of messages published per second.\nrabbitmq.overview.messages.redeliver.countThe number of subset of messages in deliver_get which had the redelivered flag set.\nrabbitmq.overview.messages.redeliver.rateThe rate of subset of messages in deliver_get which had the redelivered flag set per second.\nrabbitmq.overview.messages.return_unroutable.countThe number of messages returned to publisher as unroutable.\nrabbitmq.overview.messages.return_unroutable.rateThe rate of messages returned to publisher as unroutable per second.\nrabbitmq.overview.object_totals.channelsThe total number of channels.\nrabbitmq.overview.object_totals.connectionsThe total number of connections.\nrabbitmq.overview.object_totals.consumersThe total number of consumers.\nrabbitmq.overview.object_totals.queuesThe total number of queues.\nrabbitmq.overview.queue_totals.messages_ready.countThe number of messages ready for delivery.\nrabbitmq.overview.queue_totals.messages_ready.rateThe rate of messages ready for delivery.\nrabbitmq.overview.queue_totals.messages_unacknowledged.countThe number of unacknowledged messages.\nrabbitmq.overview.queue_totals.messages_unacknowledged.rateThe rate of unacknowledged messages.\nrabbitmq.overview.queue_totals.messages.countThe total number of messages (ready plus unacknowledged).\nrabbitmq.overview.queue_totals.messages.rateThe rate of messages (ready plus unacknowledged).\nrabbitmq.queue.active_consumersThe number of active consumers, consumers that can immediately receive any messages sent to the queue.\nrabbitmq.queue.bindings.countThe number of bindings for a specific queue.\nrabbitmq.queue.consumer_utilisationThe ratio of time that a queue\u0026rsquo;s consumers can take new messages.\nrabbitmq.queue.consumersThe number of consumers.\nrabbitmq.queue.memoryThe number of bytes of memory consumed by the Erlang process associated with the queue, including stack, heap and internal structures.\nrabbitmq.queue.messagesThe total number of messages in the queue.\nrabbitmq.queue.messages_readyThe number of messages ready to be delivered to clients.\nrabbitmq.queue.messages_ready.rateThe number of messages ready to be delivered to clients per second.\nrabbitmq.queue.messages_unacknowledgedThe number of messages delivered to clients but not yet acknowledged.\nrabbitmq.queue.messages_unacknowledged.rateThe number of messages delivered to clients but not yet acknowledged per second.\nrabbitmq.queue.messages.ack.countThe number of messages delivered to clients and acknowledged.\nrabbitmq.queue.messages.ack.rateThe number of messages delivered to clients and acknowledged per second.\nrabbitmq.queue.messages.deliver_get.countThe sum of messages delivered in acknowledgement mode to consumers, in no-acknowledgement mode to consumers, in acknowledgement mode in response to basic.get, and in no-acknowledgement mode in response to basic.get.\nrabbitmq.queue.messages.deliver_get.rateThe sum of messages delivered in acknowledgement mode to consumers, in no-acknowledgement mode to consumers, in acknowledgement mode in response to basic.get, and in no-acknowledgement mode in response to basic.get per second.\nrabbitmq.queue.messages.deliver.countThe number of messages delivered in acknowledgement mode to consumers.\nrabbitmq.queue.messages.deliver.rateThe number of messages delivered in acknowledgement mode to consumers.\nrabbitmq.queue.messages.publish.countThe number of messages published.\nrabbitmq.queue.messages.publish.rateThe rate of messages published per second.\nrabbitmq.queue.messages.rateThe total number of messages in the queue per second.\nrabbitmq.queue.messages.redeliver.countThe number of subset of messages in deliver_get which had the redelivered flag set.\nrabbitmq.queue.messages.redeliver.rateThe rate per second of subset of messages in deliver_get which had the redelivered flag set.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/rabbitmq-metrics/"},{"id":790,"title":"RedisDB","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nApplication SetupRedis will automatically expose all metrics. You do not need to configure anything in the Redis instance.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with Redis and collect basic metrics:\napp_checks: - name: redis check_module: redisdb pattern: comm: redis-server conf: host: 127.0.0.1 port: \u0026#34;{port}\u0026#34; Some additional metrics can be collected by editing the configuration file as shown in following examples. The options shown in Example 2 are relevant if Redis requires authentication or if a Unix socket is used.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1: Key LengthsThe following example entry results in the metric redis.key.length in the Sysdig Monitor UI, displaying the length of specific keys (segmented by: key). To enable, provide the key names in dragent.yaml as follows.\nNote that length is 0 (zero) for keys that have a type other than list, set, hash, or sorted set. Keys can be expressed as patterns; see https://redis.io/commands/keys.\nSample entry in dragent.yaml:\napp_checks: - name: redis check_module: redisdb pattern: comm: redis-server conf: host: 127.0.0.1 port: \u0026#34;{port}\u0026#34; keys: - \u0026#34;list_1\u0026#34; - \u0026#34;list_9*\u0026#34; Example 2: Additional Configuration Options unix_socket_path (Optional) - Can be used if your Redis uses a socket instead of host and port.\npassword (Optional) - Can be used if your Redis requires a password\napp_checks: - name: redis check_module: redisdb pattern: comm: redis-server conf: host: 127.0.0.1 port: \u0026#34;{port}\u0026#34; # unix_socket_path: /var/run/redis/redis.sock # can be used in lieu of host/port # password: mypassword # if your Redis requires auth Example 3: COMMANDSTATS MetricsYou can also collect the INFO COMMANDSTATS result as metrics (redis.command.*). This works with Redis \u0026gt;= 2.6\nSample implementation:\napp_checks: - name: redis check_module: redisdb pattern: comm: redis-server conf: host: 127.0.0.1 port: \u0026#34;{port}\u0026#34; command_stats: true Metrics AvailableSee RedisDB Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/redisdb/"},{"id":791,"title":"Supervisord Metrics","content":"See Application Integrations for more information.\nsupervisord.process.countThe number of supervisord monitored processes.\nsupervisord.process.uptimeThe process uptime.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/supervisord-metrics/"},{"id":792,"title":"SNMP","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nSNMP OverviewSNMP has three primary versions ( SNMPv1, SNMPv2c and SNMPv3) and SNMPv2c is most widely used.\nSNMP allows device vendors to expose management data in the form of variables on managed systems organized in a management information base (MIB), which describe the system status and configuration. The devices can be queried as well as configured remotely using these variables. Certain MIBs are generic and supported by the majority of the device vendors. Additionally, each vendor can have their own private/enterprise MIBs for vendor-specific information.\nSNMP MIB is a collection of objects uniquely identified by an Object Identifier (OID). OIDs are represented in the form of x.0, where x is the name of object in the MIB definition.\nFor example, suppose one wanted to identify an instance of the variable sysDescr The object class for sysDescr is: iso org dod internet mgmt mib system sysDescr 1 3 6 1 2 1 1 1 Hence, the object type, x, would be 1.3.6.1.2.1.1.1 SNMP Agent ConfigurationTo monitor the servers with the Sysdig agent, the SNMP agent must be installed on the servers to query the system information.\nFor Ubuntu-based servers, use the following commands to install the SNMP Daemon:\n$sudo apt-get update $sudo apt-get install snmpd Next, configure this SNMP agent to respond to queries from the SNMP manager by updating the configuration file located at /etc/snmp/snmpd.conf\nBelow are the important fields that must be configured:\nsnmpd.conf\n# Listen for connections on all interfaces (both IPv4 *and* IPv6) agentAddress udp:161,udp6:[::1]:161 ## ACCESS CONTROL ## system + hrSystem groups only view systemonly included .1.3.6.1.2.1.1 view systemonly included .1.3.6.1.2.1.25.1 view systemonly included .1.3.6.1.2.1.31.1 view systemonly included .1.3.6.1.2.1.2.2.1.1 # Default access to basic system info rocommunity public default -V systemonly # rocommunity6 is for IPv6 rocommunity6 public default -V systemonly After making changes to the config file, restart the snmpd service using:\n$sudo service snmpd restart Sysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationNo default configuration is present for SNMP check.\nYou must specify the OID/MIB for every parameter you want to collect, as in the following example.\nThe OIDs configured in dragent.yaml are included in the snmpd.conf configuration under the \u0026lsquo;ACCESS CONTROL\u0026rsquo; section\nEnsure that the community_string is same as configured in the system configuration (rocommunity).\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExampleapp_checks: - name: snmp pattern: comm: python arg: /opt/draios/bin/sdchecks interval: 30 conf: mibs_folder: /usr/share/mibs/ietf/ ip_address: 52.53.158.103 port: 161 community_string: public # Only required for snmp v1, will default to 2 # snmp_version: 2 # Optional tags can be set with each metric tags: - vendor:EMC - array:VNX5300 - location:front metrics: - OID: 1.3.6.1.2.1.25.2.3.1.5 name: hrStorageSize - OID: 1.3.6.1.2.1.1.7 name: sysServices - MIB: TCP-MIB symbol: tcpActiveOpens - MIB: UDP-MIB symbol: udpInDatagrams - MIB: IP-MIB table: ipSystemStatsTable symbols: - ipSystemStatsInReceives metric_tags: - tag: ipversion index: 1 # specify which index you want to read the tag value from - MIB: IF-MIB table: ifTable symbols: - ifInOctets - ifOutOctets metric_tags: - tag: interface column: ifDescr # specify which column to read the tag value from The Sysdig agent allows you to monitor the SNMP counters and gauge of your choice. For each device, specify the metrics that you want to monitor in the metrics subsection using one of the following methods:\nSpecify a MIB and the symbol that you want to export\nmetrics: - MIB: UDP-MIB symbol: udpInDatagrams Specify an OID and the name you want the metric to appear under in Sysdig Monitor:\nmetrics: - OID: 1.3.6.1.2.1.6.5 name: tcpActiveOpens #The name here is the one specified in the MIB but you could use any name. Specify an MIB and a table from which to extract information:\nmetrics: - MIB: IF-MIB table: ifTable symbols: - ifInOctets metric_tags: - tag: interface column: ifDescr Metrics AvailableThe SNMP check does not have default metrics. All metrics mentioned in dragent.yaml file will be seen with snmp.* prefix/\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/snmp/"},{"id":793,"title":"TCP Metrics","content":"See Application Integrations for more information.\nnetwork.tcp.response_timeThe response time of a given host and TCP port.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/tcp-metrics/"},{"id":794,"title":"Forwarding to Amazon Kinesis Data Streams","content":"PrerequisitesTo forward events to Amazon Kinesis Data Streams you will need:\nA Kinesis Data Stream An Identity and Access Management (IAM) user An Access Key and Secret to authenticate Sysdig as that IAM user Permission for the IAM user to publish on that stream. Configure on AWSPrepare your AWS Console for Event Forwarding to Amazon Kinesis Data Streams. You will need an IAM User, an Access Key and Secret for authentication, and a Kinesis Data Stream.\nCreate or identify a target Kinesis Data Stream. See Create and manage Kinesis data streams.\nTake note of:\nThe Amazon Resource Name (ARN) for the Kinesis Data Stream. Its format will resemble arn:aws:kinesis:us-west-2:222222222222:stream/sysdig. You will need to input this later in the Sysdig UI. The Maximum record size. You can customize this in the Sysdig UI. If the max record size is lower than the size of a Sysdig payload, the payload will be discarded, consequently raising an error in the integration.\nCreate or identify a target AWS IAM User you want to have Sysdig access. We recommend creating a new user for security reasons. See Creating an IAM user in your AWS account.\nTake note of the Amazon Resource Name (ARN) for the IAM User. Its format will resemble arn:aws:iam::111111111111:user/sysdig-efo-user.\nAttach an IAM Policy to allow publishing to the Kinesis Data Stream:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;Sysdig0\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: [ \u0026#34;kinesis:PutRecord\u0026#34;, \u0026#34;kinesis:PutRecords\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:kinesis:us-west-2:222222222222:stream/sysdig\u0026#34; ] } ] } Create an Access Key and Secret Key for the user. See Managing access keys for IAM users.\nTake note of the Access Key and Secret Key. You will need to input these later in the Sysdig UI.\nIf the Data Stream and the IAM User are on different accounts, go back to the Kinesis Data Stream and configure the Access Policy for the stream to allow the target AWS IAM User to perform kinesis:PutRecord and kinesis:PutRecords on that stream. See Example resource-based policies for Kinesis Data Streams.\nThe resulting policy will have Amazon Resource Names (ARNs) referencing different accounts. For example:\n111111111111 is the AWS IAM user account. 222222222222 is the Data Stream ownerAccount. { \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;Sysdig0\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: { \u0026#34;AWS\u0026#34;: \u0026#34;arn:aws:iam::111111111111:user/sysdig-efo-user\u0026#34; }, \u0026#34;Action\u0026#34;: [ \u0026#34;kinesis:PutRecord\u0026#34;, \u0026#34;kinesis:PutRecords\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:kinesis:us-west-2:222222222222:stream/sysdig\u0026#34; ] } ] } Configure Event Forwarding Log in to Sysdig Secure as Admin and select Integrations \u0026gt; SIEM \u0026amp; Data Platforms.\nClick +Add Integration and choose Amazon Kinesis Data Streams from the dropdown.\nConfigure the required options:\nIntegration Name: Choose an integration name, for example, sysdig-efo-kds. Owner Account: Enter the AWS account where the Data Stream is. If unspecified, Sysdig assumes it\u0026rsquo;s the same account as that of the IAM user. Access Key: Enter your IAM user\u0026rsquo;s Access Key. Access Secret: Enter your IAM user\u0026rsquo;s Secret Key. Region: Enter the AWS region where you created the Data Stream, for example, us-west-2. Stream Name: Enter the name of the target Amazon Data Stream. Note, this is not the full URL or the ARN, but just the name. For example: sysdig-efo-queue. Max Record Size: This is the maximum size for a single entry sent to the Stream. It must not be higher than what\u0026rsquo;s set in the Data Stream settings in AWS. Records bigger than this size will be discarded. Defaults to 1 MB. Data to Send: Select from the dropdown the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled. Toggle the Enabled switch. You will need to Test Integration with the button below before enabling the integration.\nClick Save.\nConfigure Agent Local ForwardingReview the Agent Local Forwarding configuration steps and use the following parameters for this integration.\nThis integration requires Host Shield 14.4.0 or higher.\nType Attribute Required? Type Allowed values Default Description KINESIS_DATA_STREAMS accessKey yes string Access Key for authenticating on AWS to send data on the stream KINESIS_DATA_STREAMS accessSecret yes string Access Secret for authenticating on AWS to send data on the stream KINESIS_DATA_STREAMS ownerAccount no string The AWS Account where the stream is. If unspecified, Sysdig assumes it’s the same account as that of the IAM user. KINESIS_DATA_STREAMS token no string Session token for authenticating on AWS to send data on the stream KINESIS_DATA_STREAMS region yes string Region in which the stream is hosted KINESIS_DATA_STREAMS streamName yes string Kinesis Data Stream name KINESIS_DATA_STREAMS maxRecordSize no int \u0026gt;= 1048576, \u0026lt;= 10485760 1048576 Maximum record size, according to what\u0026rsquo;s in AWS (or lower). ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forward-to-amazon-kinesis-data-streams/"},{"id":795,"title":"Forwarding to Amazon Kinesis Firehose","content":"PrerequisitesTo forward events to Amazon Kinesis Firehose you will need:\nA Kinesis Firehose Stream An Identity and Access Management (IAM) user An Access Key and Secret to authenticate Sysdig as that IAM user Permission for the IAM user to publish on that stream. Configure on AWSPrepare your AWS Console for Event Forwarding to Amazon Kinesis Firehose. You will need an IAM User, an Access Key and Secret for authentication, and a Kinesis Firehose stream.\nCreate or identify a target Kinesis Firehose Stream. See Tutorial: Create a Firehose stream from console. The stream Source must be \u0026ldquo;Direct PUT\u0026rdquo;.\nTake note of the Amazon Resource Name (ARN) for the Kinesis Firehose stream. Its format will resemble arn:aws:firehose:us-west-2:222222222222:deliverystream/sysdig. You will need to input this later in the Sysdig UI.\nCreate or identify a target AWS IAM User you want to give Sysdig access to. We recommend creating a new user for security reasons. See Creating an IAM user in your AWS account.\nTake note of the Amazon Resource Name (ARN) for the IAM User. Its format will resemble arn:aws:iam::111111111111:user/sysdig-efo-user. You will need to input these later to configure the permissions to access the Kinesis Firehose stream.\nAttach an IAM Policy to allow publishing to the Kinesis Firehose Stream:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;Sysdig0\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: [ \u0026#34;firehose:PutRecord\u0026#34;, \u0026#34;firehose:PutRecordBatch\u0026#34; ], \u0026#34;Resource\u0026#34;: [ \u0026#34;arn:aws:firehose:us-west-2:111111111111:deliverystream/sysdig\u0026#34; ] } ] } Create an Access Key and Secret Key for the user. See Managing access keys for IAM users.\nTake note of the Access Key and Secret Key. You will need to input these later in the Sysdig UI.\nConfigure Event Forwarding Log in to Sysdig Secure as Admin and select Integrations \u0026gt; SIEM \u0026amp; Data Platforms.\nClick +Add Integration and choose Amazon Kinesis Firehose from the dropdown.\nConfigure the required options:\nIntegration Name: Choose an integration name, for example, sysdig-efo-firehose. Access Key: Enter your IAM user\u0026rsquo;s Access Key. Access Secret: Enter your IAM user\u0026rsquo;s Secret Key. Region: Enter the AWS region where you created Amazon Kinesis Firehose Stream, for example, us-west-2. Stream Name: Enter the name of the target Amazon Kinesis Firehose Stream. Note, this is not the full URL or the ARN, but just the name. For example: sysdig. Data to Send: Select from the dropdown the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled. Toggle the Enabled switch. You will need to Test Integration with the button below before enabling the integration.\nClick Save.\nConfigure Agent Local ForwardingReview the Agent Local Forwarding configuration steps and use the following parameters for this integration.\nThis integration requires Host Shield 14.4.0 or higher.\nType Attribute Required? Type Allowed values Default Description KINESIS_FIREHOSE accessKey yes string Access Key for authenticating on AWS to send data to the stream KINESIS_FIREHOSE accessSecret yes string Access Secret for authenticating on AWS to send data to the stream KINESIS_FIREHOSE token no string Session token for authenticating on AWS to send data to the stream KINESIS_FIREHOSE region yes string Region in which the Kinesis Firehose stream is hosted KINESIS_FIREHOSE streamName yes string Kinesis Firehose Stream name ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forward-to-amazon-kinesis-firehose/"},{"id":796,"title":"Forwarding to Amazon SQS","content":"PrerequisitesTo forward events to Amazon SQS you will need:\nAn SQS queue An Identity and Access Management (IAM) user An Access Key and Secret to authenticate Sysdig as that IAM user Permission for the IAM user to write messages on the target queue Configure on AWSPrepare your AWS Console for Event Forwarding to Amazon SQS. You will need an IAM User, an Access Key and Secret for authentication, and an SQS queue.\nCreate or identify a target SQS Queue. See Getting started with Amazon SQS.\nTake note of the Amazon Resource Name (ARN) for the SQS Queue. Its format will resemble arn:aws:sqs:us-west-2:222222222222:sysdig-efo-queue. You will need to input this later in the Sysdig UI.\nCreate or identify a target AWS IAM User you want to give Sysdig access to. We recommend creating a new user for security reasons. See Creating an IAM user in your AWS account.\nTake note of the Amazon Resource Name (ARN) for the IAM User. Its format will resemble arn:aws:iam::111111111111:user/sysdig-efo-user. You will need to input these later to configure the permissions to access the SQS queue.\nAttach an IAM Policy to allow sending messages on the SQS queue:\n{ \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;Sysdig0\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Action\u0026#34;: [ \u0026#34;sqs:GetQueueUrl\u0026#34;, \u0026#34;sqs:SendMessage\u0026#34; ], \u0026#34;Resource\u0026#34;: \u0026#34;arn:aws:sqs:us-east-1:222222222222:efo-queue\u0026#34; } ] } Create an Access Key and Secret Key for the user. See Managing access keys for IAM users.\nTake note of the Access Key and Secret Key. You will need to input these later in the Sysdig UI.\nIf the SQS queue and the IAM User are on different accounts, go back on the SQS queue and configure the Access Policy for the queue to allow the target AWS IAM User to perform SQS:SendMessage, sqs:ListQueues and sqs:GetQueueUrl on that queue. See Configuring access policy.\nThe resulting policy will have Amazon Resource Names (ARNs) referencing different accounts. For example:\n111111111111 is the AWS IAM user account. 222222222222 is the SQS queue ownerAccount. { \u0026#34;Version\u0026#34;: \u0026#34;2012-10-17\u0026#34;, \u0026#34;Id\u0026#34;: \u0026#34;__default_policy_ID\u0026#34;, \u0026#34;Statement\u0026#34;: [ { \u0026#34;Sid\u0026#34;: \u0026#34;__sender_statement\u0026#34;, \u0026#34;Effect\u0026#34;: \u0026#34;Allow\u0026#34;, \u0026#34;Principal\u0026#34;: { \u0026#34;AWS\u0026#34;: \u0026#34;arn:aws:iam::111111111111:user/sysdig-efo-user\u0026#34; }, \u0026#34;Action\u0026#34;: [ \u0026#34;sqs:GetQueueUrl\u0026#34;, \u0026#34;sqs:SendMessage\u0026#34; ], \u0026#34;Resource\u0026#34;: \u0026#34;arn:aws:sqs:us-east-1:222222222222:efo-queue\u0026#34; } ] } Configure Event Forwarding Log in to Sysdig Secure as Admin and select Integrations \u0026gt; Add Integrations.\nSearch and choose Amazon SQS.\nLog in to Sysdig Secure as Admin and select Integrations \u0026gt; SIEM \u0026amp; Data Platforms.\nClick +Add Integration and choose Amazon SQS from the dropdown.\nConfigure the required options:\nIntegration Name: Choose an integration name, for example, sysdig-efo-queue. Access Key: Enter your IAM user\u0026rsquo;s Access Key. Owner Account: Enter the AWS account that includes the SQS queue. If unspecified, Sysdig assumes it\u0026rsquo;s the same account as that of the IAM user. Access Secret: Enter your IAM user\u0026rsquo;s Secret Key. Region: Enter the AWS region where you created you Amazon SQS, for example, us-west-2. Queue: Enter the name of the target Amazon SQS queue. Note, this is not the full URL or the ARN, but just the name. For example: sysdig-efo-queue. FIFO Optional: Checking this box will enable first-in-first-out streams. Delay Optional: Enter a value (in seconds) between 0 and 900 that a message delivery should be delayed. Metadata Optional: Set up to 10 key value headers with which the messages should be tagged. Entries can be string values. Data to Send: Select from the dropdown the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled. Toggle the Enabled switch. You will need to Test Integration with the button below before enabling the integration.\nClick Save.\nConfigure Agent Local ForwardingReview the Agent Local Forwarding configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description SQS accessKey yes string Access Key for authenticating on AWS to send data to the queue SQS accessSecret yes string Access Secret for authenticating on AWS to send data to the queue SQS ownerAccount no string The AWS Account with the SQS queue. If unspecified, Sysdig assumes it’s the same account as that of the IAM user. SQS token no string Session token for authenticating on AWS to send data to the queue SQS region yes string Region in which the SQS queue is hosted SQS queue yes string SQS queue name SQS delay no int 0-900 0 Delay, in seconds, applied to the data SQS headers no sequence of mappings Extra headers to add to the payload. Each header mapping requires 2 keys: “key” for the header key and “value” for its value ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forward-to-amazon-sqs/"},{"id":797,"title":"Supervisord","content":"No default configuration is provided for the Supervisor check; you must provide the configuration in the dragent.yaml file for the Sysdig agent to collect the data provided by Supervisor.\nThis page describes the setup steps required on Supervisor, how to edit the Sysdig agent configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nSupervisor SetupConfigurationThe Sysdig agent can collect data from Supervisor via HTTP server or UNIX socket. The agent collects the same data regardless of the configured collection method.\nUn-comment the following or add them if they are not present in /etc/supervisor/supervisord.conf\n[inet_http_server] port=localhost:9001 username=user # optional password=pass # optional ... [supervisorctl] serverurl=unix:///tmp/supervisor.sock ... [unix_http_server] file=/tmp/supervisor.sock chmod=777 # make sure chmod is set so that non-root users can read the socket. ... [program:foo] command=/bin/cat The programs controlled by Supervisor are given by different [program] sections in the configuration. Each program you want to manage by Supervisor must be specified in the Supervisor configuration file, with its supported options in the [program] section. See Supervisor\u0026rsquo;s sample.conf file for details.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml does not have any configuration to connect the agent with Supervisor. Edit dragent.yaml following the Examples given to connect with Supervisor and collect supervisor.* metrics.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1: Connect by UNIX Socket - name: supervisord pattern: comm: supervisord conf: socket: \u0026#34;unix:///tmp/supervisor.sock\u0026#34; Example 2: Connect by Host Name and Port, Optional Authentication- name: supervisord pattern: comm: supervisord conf: host: localhost port: 9001 # user: user # Optional. Required only if a username is configured. # pass: pass # Optional. Required only if a password is configured. Metrics Available Metric Name\nMetric Description\nsupervisord.process.count\n(gauge)\nThe number of supervisord monitored processes\nshown as process\nsupervisord.process.uptime\n(gauge)\nThe process uptime\nshown as second\nSee also Supervisord Metrics.\nService Checksupervisored.can.connect:Returns CRITICAL if the Sysdig agent cannot connect to the HTTP server or UNIX socket configured, otherwise OK.\nsupervisord.process.status: SUPERVISORD STATUS SUPERVISORD.PROCESS.STATUS STOPPED CRITICAL STARTING UNKNOWN RUNNING OK BACKOFF CRITICAL STOPPING CRITICAL EXITED CRITICAL FATAL CRITICAL UNKNOWN UNKNOWN Result in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/supervisord/"},{"id":798,"title":"TCP","content":"This page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nTCP Application SetupAny application listening on a TCP port can be monitored with tcp_check.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationNo default configuration is provided in the default settings file; you must add the entries in Example 1 to the user settings config file dragent.yaml.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample - name: tcp_check check_module: tcp_check pattern: comm: httpd arg: DFOREGROUND conf: port: 80 collect_response_time: true This example shows monitoring a TCP check on an Apache process running on the host on port 80.\ncomm: is the command for running the Apache server on port 80.\nIf you want the response time for your port, meaning the amount of time the process takes to accept the connection, you can add the collect_response_time: true parameter under the conf: section and the additional metric network.tcp.response_time will appear in the Metrics list.\nDo not use port: under the pattern: section in this case, because if the process is not listening it will not be matched and the metric will not be sent to Sysdig Monitor.\nMetrics Available Metric Name\nMetric Description\nnetwork.tcp.response_time\n(gauge)\nThe response time of a given host and TCP port, tagged with url, e.g. 'url:192.168.1.100:22'.\nshown as second\nSee TCP Metrics.\nService Checkstcp.can_connect :\nDOWN if the agent cannot connect to the configured host and port, otherwise UP.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/tcp/"},{"id":799,"title":"Varnish","content":"The Sysdig Agent automatically collects all metrics. You can also edit the configuration to emit service checks for the back end.\nThis page describes the default configuration settings, how to edit the configuration to collect additional information, the metrics available for integration, and a sample result in the Sysdig Monitor UI.\nVarnish SetupVarnish will automatically expose all metrics. You do not need to add anything to the Varnish instance.\nSysdig Agent ConfigurationReview how to Edit dragent.yaml to Integrate or Modify Application Checks.\nDefault ConfigurationBy default, Sysdig\u0026rsquo;s dragent.default.yaml uses the following code to connect with Varnish and collect all but the VBE metrics. See Example 2 Enable Varnish VBE Metrics.\nmetrics_filter: - exclude: varnish.VBE.* app_checks: - name: varnishapp_checks: interval: 15 pattern: comm: varnishd conf: varnishstat: /usr/bin/varnishstat Optionally, if you want to submit service checks for the health of each back end, you can configure varnishadm and edit dragent.yaml as in Example 1.\nRemember! Never edit dragent.default.yaml directly; always edit only dragent.yaml.\nExample 1 Service Health Checks with varnishadmWhen varnishadm is configured, the Sysdig agent requires privileges to execute the binary with root privileges. Add the following to your /etc/sudoers file:\nsysdig-agent ALL=(ALL) NOPASSWD:/usr/bin/varnishadm Then edit dragent.yaml as follows. Note: If you have configured varnishadm and your secret file is NOT /etc/varnish/secret, you can comment out secretfile.\napp_checks: - name: varnish interval: 15 pattern: comm: varnishd conf: varnishstat: /usr/bin/varnishstat varnishadm: /usr/bin/varnishadm secretfile: /etc/varnish/secret This example will enable following service check.\nvarnish.backend_healthy: The agent submits a service check for each Varnish backend, tagging each with backend:\u0026lt;backend_name\u0026gt;.\nExample 2 Enable Varnish VBE MetricsVarnish VBE metrics are dynamically generated (and therefore are not listed in the Metrics Dictionary). Because they generate unique metric names with timestamps, they can clutter metric handling and are filtered out by default. If you want to collect these metrics, use include in the metrics_filter in dragent.yaml:\nmetrics_filter: - include: varnish.VBE.* app_checks: - name: varnishapp_checks: interval: 15 pattern: comm: varnishd conf: varnishstat: /usr/bin/varnishstat Metrics AvailableSee Varnish Metrics.\nResult in the Monitor UI ","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/integrations/legacy-integrations/legacyintegrate-applications-default-app-checks/varnish/"},{"id":800,"title":"Forwarding to Syslog","content":"Sysdig Event Forwarding allows you to send events gathered by Sysdig Secure to a Syslog server.\nPrerequisitesEvent forwards originate from region-specific IPs. For the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle event forwarding.\nConfigure Standard Event ForwardingTo forward event data to a Syslog Server:\nLog in to Sysdig Secure as Admin and go to Integrations \u0026gt; Add Integrations.\nSearch and choose Syslog.\nConfigure the required options:\nIntegration Name: Define an integration name.\nAddress: Specify the Syslog server where the events are forwarded. Enter a domain name or IP address. If a domain name resolves to several IP addresses, the first resolved address is used.\nPort: Specify the port number.\nProtocol: Choose the protocol depending on the server you are sending the logs to:\nRFC 3164: RFC 3164 is the older version of the protocol, default port and transport is 514/UDP.\nRFC 5424: RFC 5424 is the current version of the protocol, default port and transport is 514/UDP\nRFC 5425 (TLS): RFC 5425 (TLS) is an extension to RFC 5424 to use an encrypted channel, default port and transport is 6514/TCP. Select this option if you want to use a certificate uploaded via Sysdig\u0026rsquo;s Certificates Management tool.\nUDP/TCP (Deprecated): Define the Transport Layer Protocol. From 20 May 2025, new integrations can only use TCP. UDP is supported for existing integrations until June 20, 2025. For details, see Deprecation Notice for Syslog Events Forwarding Using UDP.\nNOTE: RFC 5425 (TLS) only supports TCP. Certificate: (Optional) Select a certificate you\u0026rsquo;ve uploaded via Sysdig\u0026rsquo;s Certificates Management tool. Note that the RFC 5425 (TLS) protocol is required for you to see this field.\nData to Send: Select from the drop-down the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled.\nAllow insecure connections: Toggle on if you want to allow insecure connections, such as invalid or self-signed certificate on the client side.\nToggle the enable switch as necessary. Remember that you will need to \u0026ldquo;Test Integration\u0026rdquo; with the button below before enabling the integration.\nClick Save.\nConfigure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description SYSLOG ServiceURL yes string URL of the syslog server SYSLOG ServicePort yes int port of the syslog server SYSLOG ServiceType no string tcp, udp tcp protocol, tcp or udp (case insensitive) SYSLOG insecure no bool true Doesn’t verify TLS certificate SYSLOG MessageFormat yes string RFC_3164, RFC_5424, RFC_5425 The syslog message format. RFC5425 is TLS only SYSLOG formatter no string JSON, LEEF, CEF JSON The message content format ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forwarding-to-syslog/"},{"id":801,"title":"PGBouncer Metrics","content":"See Application Integrations for more information.\npgbouncer.pools.cl_activeThe number of client connections linked to a server connection and able to process queries.\npgbouncer.pools.cl_waitingThe number of client connections waiting on a server connection.\npgbouncer.pools.maxwaitThe age of the oldest unserved client connection.\npgbouncer.pools.sv_activeThe number of server connections linked to a client connection.\npgbouncer.pools.sv_idleThe number of server connections idle and ready for a client query.\npgbouncer.pools.sv_loginThe number of server connections currently in the process of logging in.\npgbouncer.pools.sv_testedThe number of server connections currently running either server_reset_query or server_check_query.\npgbouncer.pools.sv_usedThe number of server connections idle more than server_check_delay, needing server_check_query.\npgbouncer.stats.avg_queryThe average query duration.\npgbouncer.stats.avg_recvThe average amount of client network traffic received.\npgbouncer.stats.avg_reqThe average number of requests per second in the last stat period.\npgbouncer.stats.avg_sentThe average amount of client network traffic sent.\npgbouncer.stats.bytes_received_per_secondThe total network traffic received.\npgbouncer.stats.bytes_sent_per_secondThe total network traffic sent.\npgbouncer.stats.requests_per_secondThe request rate.\npgbouncer.stats.total_query_timeThe time spent by PgBouncer actively querying PostgreSQL.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/pgbouncer-metrics/"},{"id":802,"title":"PHP-FPM Metrics","content":"See Application Integrations for more information.\nphp_fpm.listen_queue.sizeThe size of the socket queue of pending connections.\nphp_fpm.processes.activeThe total number of active processes.\nphp_fpm.processes.idleThe total number of idle processes.\nphp_fpm.processes.max_reachedThe number of times the process limit has been reached.\nphp_fpm.processes.totalThe total number of processes.\nphp_fpm.requests.acceptedThe total number of accepted requests.\nphp_fpm.requests.slowThe total number of slow requests.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/php-fpm-metrics/"},{"id":803,"title":"Risk Acceptance for Vulnerabilities","content":"PrerequisitesRisk acceptance can apply to all stages; Pipeline, Registry, Admission and Runtime. In order for Risk Acceptance to be properly respected in your environment and operate as expected, all minimum versions of the following components must be met:\nSysdig Cluster Shield: v1.13.0 Sysdig Host Shield:v0.9.0 Sysdig Registry Scanner: v0.7.4 Sysdig CLI Scanner: It is always recommended to use the latest version of the CLI scanner for the most consistent experience with Risk Acceptance. Risk Acceptance in Vulnerability ManagementBy leveraging Risk Acceptance in Sysdig Vulnerability Management you can achieve the following:\nReduce alert fatigue by silencing known, well-understood, or mitigated vulnerabilities. Document security decisions for auditability and compliance purposes. Focus remediation efforts on vulnerabilities that are truly relevant to their environment and risk posture. Allow well known and accepted issues on vulnerabilities, configurations, and other criteria into your workloads where absolutely necessary. Accepted risks remain visible in the Sysdig platform, clearly labeled with the acceptance reason, scope and stages of acceptance.\nUse Cases for Risk Acceptance A vulnerability has been assessed as a false positive by the security team. The vulnerability is not exploitable due to environmental or configuration factors. A business-critical deployment requires postponing remediation, with risk formally documented. Vulnerabilities are mitigated by other controls (e.g., network segmentation, runtime policies). Accepting risk does not remove the vulnerability from scan results; it suppresses the related policy violation and clarifies why no action is currently required.\nRisk Acceptance EntitiesRisk acceptance in Sysdig Vulnerability Management can be scoped to several types of entities. The following list of entities are supported for Risk Acceptance and each has specific conditions Sysdig Vulnerability management can consider for flexible acceptance creations, follow the links for each to learn more.\nEntity Description Example Vulnerabilities A specific CVE identifier CVE-2023-12345 Images All or specific vulnerabilities in a container image nginx:1.23.1 Host Vulnerabilities detected on a particular host host-123.acme.local Policy Rule Findings from a specific vulnerability management policy rule Critical Severity Only Packages A software package, by name, version, or path openssl@1.1.1 /usr/lib/openssl Common Fields for Risk AcceptanceWhen creating or editing a risk acceptance, you must specify the following fields, regardless of the entity:\nField Description Example Where Where you would like to accept the current context of the Risk Acceptance. Available options depend on the context of the risk acceptance, and include Global, Image, Host or Package. See Risk Acceptance Entities for more info Global Stage Where the acceptance is enforced: Pipeline, Registry, Runtime (Applies to Admission Controller), All Stages. Runtime Reason The justification for accepting the risk. For more details, see Standard Risk Acceptance Reasons. Risk Mitigated Additional Details Free-form notes or further justification for audit or documentation purposes. False positive, not applicable to my application. Expires In Duration until the acceptance expires, after which enforcement resumes, allows for custom selection of date and additional default options. 30 days Risk Acceptance on Runtime stage also applies to the Sysdig Admission Controller evaluations of Kubernetes workloads and their associated Vulnerability Policy evaluations.\nRisk Acceptance Reason Examples Risk Avoided: Compensating controls exist that render the risk non-exploitable. Risk Mitigated: The risk is mitigated through other means. Risk Not Relevant: The vulnerability does not apply in this environment. Risk Owned: The risk is accepted as-is by the organization. Risk Transferred: The risk has been transferred (e.g., to a vendor). Custom: User-defined reason. VulnerabilitiesAccepting the Risk of a Vulnerability provides several scoping options and important considerations:\nGlobal Acceptance: Accepting risk for a vulnerability globally means the selected CVE is accepted across your entire environment, regardless of where it appears. Use with caution, as this suppresses risk for all assets and workloads. Image or Host Context: Accepting risk within a specific image or host restricts acceptance to those occurrences only. Package Context: Accepting risk for a vulnerability on a specific package (by version or path) enables fine-grained targeting—ideal when risk is managed for that specific software component. When you accept risk for a CVE on a container image, acceptance applies to all instances of that image, across all clusters and hosts. Consider your image re-use and deployment footprint before applying.\nYou can initiate vulnerability-based risk acceptance from the Pipeline, Registry, Runtime, and Findings views.\nInteraction with Common Fields Where: Choose the scope you wish to apply the Policy Rule Risk Acceptance. Globally; apply across your entire environment. Image you enable similar available to the Images options Host you enable choices available to Hosts options. Package you enable choices available to the Packages options. Stage: As defined above in Common Fields for Risk Acceptance Reason, Additional Details, Expires In: As defined above in Common Fields for Risk Acceptance Best Practice: Always use the most targeted scope appropriate for your use case to avoid unnecessarily broad exceptions.\nImagesAccepting risk at the image level focuses acceptance on a specific container image and all its deployments:\nWhen you accept risk on an image, all vulnerabilities matching your acceptance criteria for that image will be suppressed, regardless of where the image is deployed. This is useful for images that are managed externally, regularly patched, or that have unique risk characteristics. Interaction with Common Fields Where: The Image scope you wish to apply the Risk Acceptance to, with 2 sub-obtions available. This Image: The current Image you are initiating the Risk Acceptance from. Image Name Contains Specified Value: Enables an additional field of Value to accept user input for a contains level match. Stage: As defined above in Common Fields for Risk Acceptance Reason, Additional Details, Expires In: As defined above in Common Fields for Risk Acceptance Best Practice: Only use image-level acceptance for images you control and monitor. If the same image is deployed across multiple environments, acceptance will apply everywhere.\nHostsRisk acceptance at the host level is scoped to vulnerabilities detected on a specific host (VM or node):\nThis is appropriate for hosts with unique configurations, isolated workloads, or mitigations not present elsewhere. Interaction with Common Fields Where: The Host scope you wish to apply the Risk Acceptance to, with 2 sub-options available. This Host: The current Host you are initiating the Risk Acceptance from. Host Name Contains Specified Value: Enables an additional field of Value to accept user input for a contains level match on the Host name. Stage: As defined above in Common Fields for Risk Acceptance Reason, Additional Details, Expires In: As defined above in Common Fields for Risk Acceptance Best Practice: Host-based acceptance should be used sparingly. Review host-specific risk regularly, as host roles or workloads may change over time.\nPolicy RulesAccepting risk for findings from a specific policy rule allows you to override enforcement when business requirements demand exceptions:\nUse this when an automated policy is too restrictive or when compensating controls exist. Interaction with Common Fields Where: Choose the scope you wish to apply the Policy Rule Risk Acceptance. Globally; apply across your entire environment. Image you enable similar available to the Images options Host you enable choices available to Hosts options. Stage: As defined above in Common Fields for Risk Acceptance Reason, Additional Details, Expires In: As defined above in Common Fields for Risk Acceptance Best Practice: Document the business or technical justification clearly, and review exceptions when policy logic changes.\nPackagesRisk acceptance at the package level enables targeted suppression for a specific package (by name, version, or path):\nUseful when a package is widely used but the risk is well understood and managed for a particular version or deployment path. Additional Fields:\nVersion: The version of the specific package you wish to Accept as a Risk. There are 3 sub-options to choose from. This Version: You can choose to specify the version of the package you have specifically started the Risk Acceptance on Exact Version: match a string of an exact version detected, limisted between 2 and 256 characters. We do not validate the version against any known good practices so please use with caution. Any Version: of the selected package. File Path: The path of the package you wish to Accept as a Risk, there are 2 sub-options to choose from. This File Path: The exact file path of the Package you have initiated the Risk Acceptance on Any File Path: Any file path the package is detected on, use to accept any location of the affected package. Interaction with Common Fields Where: Choose the scope you wish to apply the Policy Rule Risk Acceptance. You can apply this Globally, or by choosing Image you enable similar available to the Images options and by choosing Host you enable choices available to Hosts options. Stage: As defined above in Common Fields for Risk Acceptance Reason, Additional Details, Expires In: As defined above in Common Fields for Risk Acceptance Best Practice: Regularly review package-level acceptances to ensure ongoing relevance, especially after upgrades or dependency changes.\nEdit a Risk AcceptanceAfter a risk acceptance is created you can modify certain attributes.\nYou can edit the attributes Reason, Addtional Details, and Expiry Date.\nYou can edit a Risk Acceptance on the individual Scan Result for an Image, a Host, or on the Risk Acceptance page.\n","url":"https://docs.sysdig.com/en/sysdig-secure/vulnerabilities/accepted-risk/"},{"id":804,"title":"Forwarding to Webhook","content":"Sysdig Secure leverages webhooks to support integrations that are not covered by any other particular integration/protocol present in the Event Forwarder list.\nPrerequisitesEvent forwards originate from region-specific IPs. For the full list of outbound IPs by region, see SaaS Regions and IP Ranges. Update your firewall and allow inbound requests from these IP addresses to enable Sysdig to handle event forwarding.\nConfigure Standard IntegrationTo forward secure data to a Webhook:\nLog in to Sysdig Secure as Admin and go to Integrations \u0026gt; Add Integrations.\nSearch and choose Webhook - SIEM \u0026amp; Data Platforms.\nConfigure the required options:\nIntegration Name: Define an integration name.\nEndpoint: Webhook endpoint following the schema protocol (i.e.https://)hostname:port\nAuthentication: Four different methods are supported. Select the method your endpoint uses:\nBasic authentication: If you select this method, you must fill the Secret field with the desired user:password. No whitespaces, semicolon character as separation.\nBearer token: If you select this method, you must fill the Secret field with the desired token. No whitespaces, semicolon character as separation.\nSignature header: If you select this method, you must fill the Secret field with the cryptographic key provided by the software on the other end.\nCertificate: Select this option if you want to use a certificate uploaded via Sysdig\u0026rsquo;s Certificates Management tool.\nThe Certificate field will then appear; select the appropriate cert from the drop-down menu. Custom Headers Any number of custom headers defined by the user to accommodate additional parameters required on the receiving end.\nTo avoid interfering with the regular webhook protocol and expected headers, the following headers cannot be set using this form.\nData to Send: Select from the drop-down the types of Sysdig data that should be forwarded. The available list depends on the Sysdig features and products you have enabled.\nDue to the heavy connection establishment overhead imposed by the HTTP protocol, the Secure policy events are grouped by time proximity into batches and sent together in a single request as a JSON array. In other words, every HTTP request will contain a JSON array containing one or more policy runtime events.\nSelect whether or not you want to allow insecure connections (i.e., an invalid or self-signed certificate on the receiving side).\nToggle the enable switch as necessary. Remember that you will need to \u0026ldquo;Test Integration\u0026rdquo; with the button below before enabling the integration.\nClick Save.\nConfigure Agent Local ForwardingReview the configuration steps and use the following parameters for this integration.\nType Attribute Required? Type Allowed values Default Description WEBHOOK endpoint yes string The webhook URL WEBHOOK secret no string Secret to use, according to the “auth” value. Required if auth is set WEBHOOK insecure no bool false Doesn’t verify TLS certificate WEBHOOK auth no string BASIC_AUTH, BEARER_TOKEN, SIGNATURE Authentication methodology to use, optionally. WEBHOOK headers no sequence of mappings Extra headers to add to the request. Each header mapping requires 2 keys: “key” for the header key and “value” for its value WEBHOOK output no string json, ndjson json Payload format WEBHOOK timestampFormat no string seconds, milliseconds, microseconds, nanoseconds nanoseconds The resolution of the “timestamp” field in the payload ","url":"https://docs.sysdig.com/en/sysdig-secure/event-forwarding-to-webhook/"},{"id":805,"title":"Internal Agents Dashboard","content":"Prerequisites Sysdig Secure on-premises v 6.2.1+\nThe Cloudsec service must be enabled through a flag in the on-prem Installer:\nsysdig.secure.cloudsec.enabled = true.\nReview EnvironmentSelect Integrations \u0026gt; Sysdig Agents.\nYou can:\nFilter and SortFilter by cluster, node, or agent version to find which agents in your environment match the criteria.\nSee at a Glance The agent versions you have installed\nHostnames\nAgent modes you defined during agent installation\nMAC addresses\nReview Kubernetes Metadata Up to Date Review Internal CountsThese panels display:\nKernels Agent Flush Time Container Count System Calls Processed/Dropped Agent Sampling Ratio CPU and Memory Usage ","url":"https://docs.sysdig.com/en/administration/internal-agent-dashboard/"},{"id":806,"title":"PostgreSQL Metrics","content":"See Application Integrations for more information.\nMetric Name Type Description postgresql.seq_scans gauge The number of sequential scans initiated on this table. postgresql.index_scans gauge The number of index scans initiated on this table. postgresql.index_rows_fetched gauge The number of live rows fetched by index scans. postgresql.rows_hot_updated gauge The number of rows HOT updated, meaning no separate index update was needed. postgresql.live_rows gauge The estimated number of live rows. postgresql.dead_rows gauge The estimated number of dead rows. postgresql.index_rows_read gauge The number of index entries returned by scans on this index. postgresql.table_size gauge The total disk space used by the specified table. Includes TOAST, free space map, and visibility map. Excludes indexes. postgresql.index_size gauge The total disk space used by indexes attached to the specified table. postgresql.total_size gauge The total disk space used by the table, including indexes and TOAST data. postgresql.heap_blocks_read gauge The number of disk blocks read from this table. postgresql.heap_blocks_hit gauge The number of buffer hits in this table. postgresql.index_blocks_read gauge The number of disk blocks read from all indexes on this table. postgresql.index_blocks_hit gauge The number of buffer hits in all indexes on this table. postgresql.toast_blocks_read gauge The number of disk blocks read from this table\u0026rsquo;s TOAST table. postgresql.toast_blocks_hit gauge The number of buffer hits in this table\u0026rsquo;s TOAST table. postgresql.toast_index_blocks_read gauge The number of disk blocks read from this table\u0026rsquo;s TOAST table index. postgresql.toast_index_blocks_hit gauge The number of buffer hits in this table\u0026rsquo;s TOAST table index. postgresql.active_queries gauge The number of active queries in this database. postgresql.archiver.archived_count gauge The number of WAL files that have been successfully archived. postgresql.archiver.failed_count gauge The number of failed attempts for archiving WAL files. postgresql.before_xid_wraparound gauge The number of transactions that can occur until a transaction wraparound. postgresql.index_rel_rows_fetched rate The number of live rows fetched by index scans. postgresql.transactions.idle_in_transaction gauge The number of \u0026lsquo;idle in transaction\u0026rsquo; transactions in this database. postgresql.transactions.open gauge The number of open transactions in this database. postgresql.waiting_queries gauge The number of waiting queries in this database. postgresql.waiting_queries gauge The number of buffers allocated postgresql.bgwriter.buffers_backend gauge The number of buffers written directly by a backend. postgresql.bgwriter.buffers_backend_fsync gauge The of times a backend had to execute its own fsync call instead of the background writer. postgresql.bgwriter.buffers_checkpoint gauge The number of buffers written during checkpoints. postgresql.bgwriter.buffers_clean gauge The number of buffers written by the background writer. postgresql.bgwriter.checkpoints_requested gauge The number of requested checkpoints that were performed. postgresql.bgwriter.checkpoints_timed gauge The number of scheduled checkpoints that were performed. postgresql.bgwriter.maxwritten_clean gauge. The number of times the background writer stopped a cleaning scan due to writing too many buffers. postgresql.bgwriter.sync_time gauge The total amount of checkpoint processing time spent synchronizing files to disk. postgresql.bgwriter.write_time gauge The total amount of checkpoint processing time spent writing files to disk. postgresql.buffer_hit gauge The number of times disk blocks were found in the buffer cache, preventing the need to read from the database. postgresql.commits gauge The number of transactions that have been committed in this database. postgresql.connections gauge The number of active connections to this database. postgresql.database_size gauge The disk space used by this database. postgresql.deadlocks gauge The number of deadlocks detected in this database postgresql.disk_read gauge The number of disk blocks read in this database. postgresql.locks gauge The number of locks active for this database. postgresql.max_connections gauge The maximum number of client connections allowed to this database. postgresql.percent_usage_connections gauge The number of connections to this database as a fraction of the maximum number of allowed connections. postgresql.replication_delay gauge The current replication delay in seconds. Only available with PostgreSQL 9.1 and newer. postgresql.replication_delay_bytes gauge The current replication delay in bytes. Only available with PostgreSQL 9.2 and newer. postgresql.rollbacks gauge The number of transactions that have been rolled back in this database. postgresql.rows_deleted gauge The number of rows deleted by queries in this database. postgresql.rows_fetched gauge The number of rows fetched by queries in this database. postgresql.rows_inserted gauge The number of rows inserted by queries in this database. The metrics can be segmented by \u0026lsquo;db\u0026rsquo; or \u0026rsquo;table\u0026rsquo; and can be viewed per-relation. postgresql.rows_returned gauge The number of rows returned by queries in this database. The metrics can be segmented by \u0026lsquo;db\u0026rsquo; or \u0026rsquo;table\u0026rsquo; and can be viewed per-relation. postgresql.rows_updated gauge The number of rows updated by queries in this database. postgresql.rows_deleted gauge The number of rows deleted by queries in this database. The metrics can be segmented by \u0026lsquo;db\u0026rsquo; or \u0026rsquo;table\u0026rsquo; and can be viewed per-relation. postgresql.table.count gauge The number of user tables in this database. postgresql.temp_bytes gauge The amount of data written to temporary files by queries in this database. postgresql.temp_files gauge The number of temporary files created by queries in this database. postgresql.toast_blocks_read gauge The number of disk blocks read from this table\u0026rsquo;s TOAST table. postgresql.transactions.idle_in_transaction gauge The number of \u0026lsquo;idle in transaction\u0026rsquo; transactions in this database. postgresql.transactions.open gauge The number of open transactions in this database. ","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/postgresql-metrics/"},{"id":807,"title":"Integrate AWS CloudWatch Metrics (Legacy)","content":" Integrating an AWS account using the Settings page has been removed from Secure and is getting deprecated in Monitor. See CloudWatch Metric Streams for the latest information.\nHere are the different ways to integrate an AWS account into Sysdig:\nCloudWatch Metric Streams\nBy manually entering an AWS access key and secret key, and manually managing/rotating them as needed.\nBy passing a parameter that allows Sysdig to autodetect an AWS Elastic Container Service (ECS) role and its permissions, passing an \u0026ldquo;implicit key\u0026rdquo; (On-Prem only).\nThe implicit option requires no manual key rotation as AWS handles those permissions behind the scenes.\nUsing AWS Role delegation. Role delegation is an alternative to the existing integration methods using the access keys. This method is considered secure as sharing developer access keys with third parties is not recommended by Amazon.\nThe Sysdig Monitor UI includes links to help easily integrate CloudWatch metrics into Sysdig Monitor, as described below.\nAfter integrating with an AWS account, data will become visible in the Sysdig UI after a 10-15 minute delay.\nEntry Point in the Sysdig Monitor UIThe Sysdig interface prompts you to perform this integration from the administrator\u0026rsquo;s Settings menu.\nAccess from the Settings MenuOnce an agent has been installed, log in to Sysdig Monitor as administrator to perform integration steps or review/modify existing AWS settings.\nSelect Settings from the user menu.\nClick AWS under Outbound Integrations.\nClick Add Account.\nA page showing manual key integration, with access key and secret key fields displayed.\nIntegrate AWS Account ManuallyHave your AWS Elastic Compute Cloud (EC2) account details available. Integration begins on the AWS side and is completed in the Sysdig Monitor UI, using an Identity and Access Management (IAM) Policy.\nIn AWSCreate an IAM Policy for Sysdig Access You could use the existing IAMReadOnly policy instead, but creating a Sysdig-specific policy provides more granular access control, the activity can be easily distinguished in CloudTrail, and it is considered best practice.\nIn AWS, select IAM and create a policy to be used for Sysdig. (Sample policy name: SysdigMonitorPolicy.)\nUsing the JSON editor view, copy/paste the Sysdig-specific policy code into the new policy and save it.\nYou can review the policy in the Visual Editor.\nWhen reviewing the completed policy in the Visual editor, you should see something like:\nCreate an IAM User and Grant Programmatic AccessUse an existing IAM user, or (best practice) create a specific IAM user for the Sysdig Backend to programmatically access CloudWatch and use its data.\nIn the IAM Console, add a User.\nSelect AWS Access Type: Programmatic Access.\nSelect Attach existing policies directly, and then select the newly created policy.\nFor example, SysdigMonitorPolicy.\nSelect the Create User option.\nCopy and save the resulting access key and secret key.\nThe Secret is only displayed once, so make sure to download the credentials file or store the key securely so that you can reference it again.\nIn the Sysdig Monitor UIEnter the Access and Secret Key Log in to Sysdig Monitor as the administrator and select Settings from the user menu.\nSelect AWS.\nAdd an account by entering the User Access Key and Secret Key, then clicking Save.\nThe credentials will be listed with a Status of OK checked.\nShould an Error occur, double-check the credentials entered. Mis-typing is the most common cause of errors.\nEnable CloudWatch Integration Navigate to the AWS page in the Sysdig Monitor UI, if you are not already there.\nToggle the CloudWatch Integration Status to Enabled.\nSysdig Monitor will poll the CloudWatch API every five minutes. Note that this incurs additional charges from AWS.\nAfter integrating with an AWS account, data will become visible in the Sysdig UI after a 10-15 minute delay.\nRefetch CredentialsIf the integrated AWS account changes on the AWS side, an Error will be listed in the Credentials Status on the Settings \u0026gt; AWS page.\nUse the Refetch Now button to re-establish the integration.\nIntegrate AWS Account Using the Implicit Key (On-Prem Only)If Sysdig is installed in an EC2 instance, you can take advantage of the existing EC2 IAM role of that instance. This can simplify administration, as you do not have to manually rotate public and private keys provided to the Sysdig backend.\nUse Implicit KeyPrerequisitesHave your on-premises Sysdig platform installed in an AWS EC2 instance that has a proper IAM role.\nFor this option, you cannot use the AWS Integration step in the Welcome Wizard.\nTo enable implicit key, you must set the following parameter:\n-Ddraios.providers.aws.implicitProvider=true Use the parameter either during initial installation, or, if you already entered keys manually, to switch to an implicit key.\nIf switching, you must then restart the API, worker, and collector components in the backend.\nIn the Settings \u0026gt; AWS page, the former credentials will be overwritten it will show implicit key.\nEnablement steps depend on whether you are using Kubernetes or Replicated as your orchestrator.\nKubernetes Edit the config.yaml to add to the following entries (in the Data section of config.yaml):\nsysdigcloud.jvm.api.options: sysdigcloud.jvm.worker.options: sysdigcloud.jvm.collector.options: If you are switching from manual to implicit keys, you must also restart the API, worker, and collector components.\nSee Apply Configuration Changes for details.\nEnable Cloudwatch integration in the Sysdig UI.\nChange the AWS Services that are PolledSysdig is designed to collect metadata for particular AWS services, which are reflected in the IAM policy code.\nThe services are:\nDynamoDB\nEC2 hosts\nECS\nElasticache\nRDS\nSQS\nWhen you implement the code and integration steps as described above, it will trigger two types of collection: first the metadata for each service is collected, and then Sysdig will poll for the metrics about the metadata returned. So, if the service is not enabled in your environment, no metadata (and no metrics) are collected about it. If it is enabled, but you do not want to poll metrics, then delete the lines of code related to that service from the IAM policy. This will avoid potential unwanted AWS API requests and potential AWS charges.\nSecurity GroupsIf you have an on-premises Sysdig Backend, and have restricted outbound security groups, you may need to allow HTTPS \u0026amp; DNS access in order for the Sysdig Backend components to make connection to the Amazon APIs. As Amazon API endpoints are referenced by name and have a large number of IP\u0026rsquo;s, this may need to be full 0.0.0.0/0 outbound access for HTTPS \u0026amp; DNS.\nIf you need to filter just to Amazon IP ranges, you can use the following as a guide: https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html\nRetrieving CloudWatch Data for Particular AWS RegionsTo enable metrics collection from only certain AWS regions in your environment, it is necessary to open a ticket with Sysdig Support. See Contact Support for details.\nLearn MoreFor information on the resulting AWS services visible in Sysdig Monitor, see the AWS-related information in the Metrics Dictionary (also available from within the Sysdig Monitor UI).\nFor information on how licensing affects AWS service views, see About AWS Cloudwatch Licensing.\n","url":"https://docs.sysdig.com/en/administration/integrate-cloudwatch-metrics-legacy/"},{"id":808,"title":"Billing Profiles","content":"OverviewNo explicit configuration is required for Costs if you solely intend to view the expenses based on public, on-demand pricing, which is available for all major cloud providers.\nAWSConfigure the AWS integration to accurately reconcile costs in Sysdig with your AWS saving plans, reserved instances, spot usage, and enterprise discount programs. Without this configuration, cost data will default to publicly available on-demand pricing.\nTo setup the AWS cost integration, see AWS Cost and Usage Reporting.\nCost reconciliation may take up to 24 hours the first time you configure your AWS account. Note that Sysdig does not currently reconcile historical cost data.\nDefault PricingDefault Pricing is applied when Sysdig is unable to detect the cloud provider of a specific Kubernetes Cluster. This scenario commonly occurs with on-premises clusters, where the unit cost cannot be automatically determined.\nClusters with Sysdig Default Pricing use an indicative unit price that closely resembles the public on-demand prices of major cloud providers.\nCustom PricingCost Advisor now supports Custom Pricing, enabling you to define custom cost configurations for your on-premises Kubernetes clusters. This feature enhances cost management accuracy, especially when the Default Pricing figures are not precise.\nUsageViewing the Billing Profile of a Cluster In Cost Advisor, the Details tab displays information about the the Billing Profile currently in use by a cluster. Leveraging Custom Pricing When Default Pricing is enabled, you can see the unit prices for costs in the Details tab and access guidance on overriding them through the API. See API documentation for more information. ","url":"https://docs.sysdig.com/en/sysdig-monitor/billing-profiles/"},{"id":809,"title":"Data Aggregation","content":"Data Aggregation ConceptsData SamplingSysdig agents collect 1-second samples and reports data at a 10-second resolution. This is the finest resolution at which Sysdig Monitor stores data. The agent accomplishes this by downsampling from 1-second to 10-second samples.\nThis is true for all the metrics, except Prometheus. For Prometheus metrics, data is sampled every 1 second, but what is reported in the 10-second interval is the latest value, not the downsample.\nSamples are stored at 10-second resolution. As new data arrives, samples are rolled up to higher downsampled timelines periodically. For example, the data registered every 10 seconds is rolled up in blocks of 1-minute intervals, and the data stored in blocks of 1-minute is rolled up to 10-minute blocks.\nDownsamplingDownsampling refers to the process of aggregating multiple samples, on a defined time interval into a set of values which can provide estimation for aggregated time ranges. In Sysdig parlance, downsampling is nothing but the data aggregation performed before exposing it as time aggregation on the UI or by the API. In effect, the data available for time aggregation during query evaluation is not the raw data, but the values that represent the estimated values for the given time range.\nDownsampling reduces data retention costs as well as improves query performance by reducing the amount of data loaded during query evaluation.\nDownsampled data is used only for longer time ranges. If you are viewing the most recent data, such as 10 minutes or the last 1 hour, raw data is used for evaluation.\nData RollupSysdig Monitor rolls up historical data over time. For example, the data collected every 10 seconds is aggregated and rolled up in blocks of 1-minute intervals. From the recorded values in 1-minute rollups, data is rolled up again for a block of 10-minute intervals.\nSysdig downsampling produces data rollups of aggregated samples. In each data rollup, Sysdig calculates and records 4 values: maximum, minimum, sum, and count. These values form the basis for the following time aggregations in the UI and APIs:\nmax min sum count avg rate rateOfChange Data ResolutionData resolution is the frequency with which the data is displayed. Sysdig Monitor supports the data resolution of 10 seconds, 1 minute, 10 minutes, 1 hour, and 1 day.\nTime and Group AggregationsThere are two forms of aggregation used for metrics in Sysdig: time aggregation and group aggregation. Time aggregation is always performed before group aggregation.\nTime AggregationTime aggregation comes into effect in two situations (that can sometimes overlap):\nAggregation: Graphs can only render a limited number of data points. To look at a wide range of data, Sysdig Monitor aggregates granular data into larger blocks of samples for visualization as given in Data Downsampling. Data Rollup: Sysdig retains rollups based on each aggregation type to allow users to choose which data points to utilize when evaluating older data. Aggregation Types Aggregation Type Description average The average of the retrieved metric values across the time period. rate The average value of the metric across the time period evaluated. maximum The highest value during the time period evaluated. minimum The lowest value during the time period evaluated. sum The combined sum of the metric across the time period evaluated. Difference Between Rate and average Rate and average are very similar and often provide the same result. However, the calculation of each is different.\nIf time aggregation is set to one minute, the agent is supposed to retrieve six samples (one every 10 seconds).\nIn some cases, samples may not be there, due to disconnections or other circumstances. For this example, four samples are available. If this was the case, the average would be calculated by dividing by four, while the rate would be calculated by dividing by six.\nMost metrics are sampled once for each time interval, resulting in average and rate returning the same value. However, there will be a distinction for any metrics not reported at every time interval. For example, some custom statsd metrics.\nRate is currently referred to as timeAvg in the Sysdig Monitor API and advanced alerting language.\nBy default, average is used when displaying data points for a time interval.\nTime Aggregation on the UIOn the Sysdig Monitor UI, you select the time aggregation from the Metric drop-down.\nDepending on the time range you have selected, how old the data is, and what the resolution is, panels display data at a granularity of 10 seconds, 1 minute, 10 minutes, 1 hour, and 1 day.\nThe number of data points displayed in Timecharts across Sysdig Monitor will vary depending on two factors:\nThe time interval (the number of seconds between the requested start and end time) The underlying metric granularity (the frequency at which the metric was scrapped) Visualization panels are built to maximize the number of data points displayed within the requested time interval while making it user-friendly.\nTo learn more about this concept, check Sampling.\nGroup AggregationMetrics applied to a group of items (for example, several containers, hosts, or nodes) are averaged between the members of the group by default. For example, three hosts report different CPU usage for one sample interval. The three values will be averaged, and reported on the chart as a single datapoint for that metric.\nThere are several different types of group aggregation:\nAggregation Type Description average The average value of the interval\u0026rsquo;s samples. maximum The maximum value of the interval\u0026rsquo;s samples. minimum The minimum value of the interval\u0026rsquo;s samples. sum The sum of values of all of the interval\u0026rsquo;s samples. If a chart or alert is segmented, the group aggregation settings will be utilized for both aggregations across the whole group, and aggregation within each individual segmentation.\nFor example, the image below shows a chart for CPU% across the infrastructure:\nWhen segmented by proc_name, the chart shows one CPU% line for each process:\nEach line provides the average value for every process with the same name. To see the difference, change the group aggregation type to sum:\nThe metric aggregation value showed beside the metric name is for the time aggregation. While the screenshot shows AVG, the group aggregation is set to SUM.\nAggregation ExamplesThe tables below provide an example of how each type of aggregation works. The first table provides the metric data, while the second displays the resulting value for each type of aggregation.\nIn the example below, the CPU% metric is applied to a group of servers called webserver. The first chart shows metrics using average aggregation for both time and group. The second chart shows the metrics using maximum aggregation for both time and group.\nFor each one minute interval, the second chart renders the highest CPU usage value found from the servers in the webserver group and from all of the samples reported during the one minute interval. This view can be useful when searching for transient spikes in metrics over long periods of time, that would otherwise be missed with average aggregation.\nThe group aggregation type is dependent on the segmentation. For a view showing metrics for a group of items, the current group aggregation setting will revert to the default setting, if the Segment By selection is changed.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/data-aggregation/"},{"id":810,"title":"Risk Spotlight (In Use)","content":"OverviewRisk Spotlight determines which packages are effectively loaded during execution and are therefore a direct security threat to your infrastructure.\nPrioritizing vulnerabilities that represent imminent risks to your organization is vital to a successful vulnerability management program. Images often contain hundreds of vulnerabilities. Multiplying this by the number of workloads running for any non-trivial infrastructure deployment, it is easy to see that the total number of potential vulnerabilities to fix is very large.\nMany prioritization criteria are commonly used and accepted to start filtering the list: Severity and CVSS scoring, Exploitability metrics, Runtime scope, and other environmental considerations. Risk Spotlight is a new criterion, supported by observed runtime behavior, to add to the vulnerability management tool belt. Risk Spotlight can considerably reduce the working set of vulnerabilities that must be addressed as a priority.\nTerminology EVE: Effective Vulnerability Exposure, an earlier term. The installation settings may still refer to the eveConnector and eveEnablement. Risk Spotlight: Profiling insights applied to vulnerability prioritization and the In Use feature. Technology DetailsTo understand how Risk Spotlight is architected:\nThe Sysdig Agent components deployed for every instrumented node (host) continuously observe the behavior of runtime workloads. Some of the information collected includes:\nImage runtime behavior profile: accessed files, processes in execution, system calls. The Software Bill Of Material (SBOM) associated with container images used by runtime containers, including used packages and versions and the vulnerabilities matched by those. The combination of the SBOM and the Packages/Libraries identified as running make a Runtime Bill of Materials (RBOM). By correlating these three pieces of information, we can differentiate between packages installed in the image and packages loaded at execution time. Sysdig propagates this information to vulnerability scan results, and can share it with partner integrations.\nEnable and Disable Risk SpotlightRisk Spotlight requires the Vulnerability Management engine in Sysdig Secure. Make sure you are using the correct documentation: Which Scanning Engine to Use.\nRisk Spotlight works with all packages and formats that Vulnerability Management supports. See Supported Operating Systems, Packages and Languages.\nSupported environments for In-Use prioritization include:\nKubernetes Workloads Linux Hosts Non-Kubernetes Containers (Docker, Podman) Understand the In Use ColumnRisk Spotlight insights show up in the Vulnerabilities Runtime page in the In Use column.\nThe In Use designation lets you focus first on the packages containing vulnerabilities that are actually being executed at runtime. If an image has 180 packages and 160 have vulnerabilities, but only 45 are used at runtime, then much of the vulnerability notification noise can be reduced by focusing on the latter.\nData will appear in the In Use column approximately 12 hours after the feature is deployed.\nTo use Risk Spotlight:\nLog in to Sysdig Secure.\nSelect Attack Surface \u0026gt; Vuln Runtime Findings.\nThe Runtime Vulnerabilities page will appear.\nSelect the In Use button to filter the list by vulnerabilities being executed at runtime.\nIn each a particular listing, the number of Critical, High, and Medium severity In Use vulnerabilities is highlighted in the In Use column.\nSelect any one of the severities to drill down.\n","url":"https://docs.sysdig.com/en/sysdig-secure/risk-spotlight/"},{"id":811,"title":"Varnish Metrics","content":"See Application Integrations for more information.\nvarnish.accept_failAccept failures. This metric is only provided by varnish 3.x.\nvarnish.backend_busyMaximum number of connections to a given backend.\nvarnish.backend_connSuccessful connections to a given backend.\nvarnish.backend_failFailed connections for a given backend.\nvarnish.backend_recycleBackend connections with keep-alive that are returned to the pool of connections.\nvarnish.backend_reqBackend requests.\nvarnish.backend_retryBackend connection retries.\nvarnish.backend_reuseRecycled connections that has were reused.\nvarnish.backend_toolateBackend connections closed because they were idle too long.\nvarnish.backend_unhealthyBackend connections not tried because the backend was unhealthy.\nvarnish.bansBans in system, including bans superseded by newer bans and bans already checked by the ban-lurker. This metric is only provided by varnish 4.x.\nvarnish.bans_addedBans added to ban list. This metric is only provided by varnish 4.x.\nvarnish.bans_completedBans which are no longer active, either because they got checked by the ban-lurker or superseded by newer identical bans. This metric is only provided by varnish 4.x.\nvarnish.bans_deletedBans deleted from ban list. This metric is only provided by varnish 4.x.\nvarnish.bans_dupsBans replaced by later identical bans. This metric is only provided by varnish 4.x.\nvarnish.bans_lurker_contentionTimes the ban-lurker waited for lookups. This metric is only provided by varnish 4.x.\nvarnish.bans_lurker_obj_killedObjects killed by ban-lurker. This metric is only provided by varnish 4.x.\nvarnish.bans_lurker_testedBans and objects tested against each other by the ban-lurker. This metric is only provided by varnish 4.x.\nvarnish.bans_lurker_tests_testedTests and objects tested against each other by the ban-lurker. \u0026lsquo;ban req.url == foo \u0026amp;\u0026amp; req.http.host == bar\u0026rsquo; counts as one in \u0026lsquo;bans_tested\u0026rsquo; and as two in \u0026lsquo;bans_tests_tested\u0026rsquo;. This metric is only provided by varnish 4.x.\nvarnish.bans_objBans which use obj.* variables. These bans can possibly be washed by the ban-lurker. This metric is only provided by varnish 4.x.\nvarnish.bans_obj_killedObjects killed by bans during object lookup. This metric is only provided by varnish 4.x\nvarnish.bans_persisted_bytesBytes used by the persisted ban lists. This metric is only provided by varnish 4.x.\nvarnish.bans_persisted_fragmentationExtra bytes accumulated through dropped and completed bans in the persistent ban lists. This metric is only provided by varnish 4.x.\nvarnish.bans_reqBans which use req.* variables. These bans can not be washed by the ban-lurker. This metric is only provided by varnish 4.x.\nvarnish.bans_testedBans and objects tested against each other during hash lookup. This metric is only provided by varnish 4.x.\nvarnish.bans_tests_testedTests and objects tested against each other during lookup. \u0026lsquo;ban req.url == foo \u0026amp;\u0026amp; req.http.host == bar\u0026rsquo; counts as one in \u0026lsquo;bans_tested\u0026rsquo; and as two in \u0026lsquo;bans_tests_tested\u0026rsquo;. This metric is only provided by varnish 4.x.\nvarnish.busy_sleepRequests sent to sleep without a worker thread because they found a busy object. This metric is only provided by varnish 4.x.\nvarnish.busy_wakeupRequests taken off the busy object sleep list and rescheduled. This metric is only provided by varnish 4.x.\nvarnish.cache_hitRequests served from the cache.\nvarnish.cache_hitpassRequests passed to a backend where the decision to pass them found in the cache.\nvarnish.cache_missRequests fetched from a backend server.\nvarnish.client_connClient connections accepted. This metric is only provided by varnish 3.x.\nvarnish.client_dropClient connection dropped, no session. This metric is only provided by varnish 3.x.\nvarnish.client_drop_lateClient connection dropped late. This metric is only provided by varnish 3.x.\nvarnish.client_reqParseable client requests seen.\nvarnish.client_req_400Requests that were malformed in some drastic way. This metric is only provided by varnish 4.x.\nvarnish.client_req_411Requests that were missing a Content-Length: header. This metric is only provided by varnish 4.x.\nvarnish.client_req_413Requests that were too big. This metric is only provided by varnish 4.x.\nvarnish.client_req_417Requests with a bad Expect: header. This metric is only provided by varnish 4.x.\nvarnish.dir_dns_cache_fullDNS director full DNS cache. This metric is only provided by varnish 3.x.\nvarnish.dir_dns_failedDNS director failed lookup. This metric is only provided by varnish 3.x.\nvarnish.dir_dns_hitDNS director cached lookup hit. This metric is only provided by varnish 3.x.\nvarnish.dir_dns_lookupsDNS director lookups. This metric is only provided by varnish 3.x.\nvarnish.esi_errorsEdge Side Includes (ESI) parse errors.\nvarnish.esi_warningsEdge Side Includes (ESI) parse warnings.\nvarnish.exp_mailedObjects mailed to expiry thread for handling. This metric is only provided by varnish 4.x.\nvarnish.exp_receivedObjects received by expiry thread for handling. This metric is only provided by varnish 4.x.\nvarnish.fetch_1xxBack end response with no body because of 1XX response (Informational).\nvarnish.fetch_204Back end response with no body because of 204 response (No Content).\nvarnish.fetch_304Back end response with no body because of 304 response (Not Modified).\nvarnish.fetch_badBack end response\u0026rsquo;s body length could not be determined and/or had bad headers.\nvarnish.fetch_chunkedBack end response bodies that were chunked.\nvarnish.fetch_closeFetch wanted close.\nvarnish.fetch_eofBack end response bodies with EOF.\nvarnish.fetch_failedBack end response fetches that failed.\nvarnish.fetch_headBack end HEAD requests.\nvarnish.fetch_lengthBack end response bodies with Content-Length.\nvarnish.fetch_no_threadBack end fetches that failed because no thread was available. This metric is only provided by varnish 4.x.\nvarnish.fetch_oldhttpNumber of responses served by backends with http \u0026lt; 1.1\nvarnish.fetch_zeroNumber of responses that have zero length.\nvarnish.hcb_insertHCB inserts.\nvarnish.hcb_lockHCB lookups with lock.\nvarnish.hcb_nolockHCB lookups without lock.\nvarnish.LCK.backend.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.backend.creatCreated locks.\nvarnish.LCK.backend.destroyDestroyed locks.\nvarnish.LCK.backend.locksLock operations.\nvarnish.LCK.ban.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.ban.creatCreated locks.\nvarnish.LCK.ban.destroyDestroyed locks.\nvarnish.LCK.ban.locksLock operations.\nvarnish.LCK.busyobj.creatCreated locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.busyobj.destroyDestroyed locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.busyobj.locksLock operations. This metric is only provided by varnish 4.x.\nvarnish.LCK.cli.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.cli.creatCreated locks.\nvarnish.LCK.cli.destroyDestroyed locks.\nvarnish.LCK.cli.locksLock operations.\nvarnish.LCK.exp.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.exp.creatCreated locks.\nvarnish.LCK.exp.destroyDestroyed locks.\nvarnish.LCK.exp.locksLock operations.\nvarnish.LCK.hcb.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.hcb.creatCreated locks.\nvarnish.LCK.hcb.destroyDestroyed locks.\nvarnish.LCK.hcb.locksLock operations.\nvarnish.LCK.hcl.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.hcl.creatCreated locks.\nvarnish.LCK.hcl.destroyDestroyed locks.\nvarnish.LCK.hcl.locksLock operations.\nvarnish.LCK.herder.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.herder.creatCreated locks.\nvarnish.LCK.herder.destroyDestroyed locks.\nvarnish.LCK.herder.locksLock operations.\nvarnish.LCK.hsl.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.hsl.creatCreated locks.\nvarnish.LCK.hsl.destroyDestroyed locks.\nvarnish.LCK.hsl.locksLock operations.\nvarnish.LCK.lru.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.lru.creatCreated locks.\nvarnish.LCK.lru.destroyDestroyed locks.\nvarnish.LCK.lru.locksLock operations.\nvarnish.LCK.mempool.creatCreated locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.mempool.destroyDestroyed locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.mempool.locksLock operations. This metric is only provided by varnish 4.x.\nvarnish.LCK.nbusyobj.creatCreated locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.nbusyobj.destroyDestroyed locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.nbusyobj.locksLock operations. This metric is only provided by varnish 4.x.\nvarnish.LCK.objhdr.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.objhdr.creatCreated locks.\nvarnish.LCK.objhdr.destroyDestroyed locks.\nvarnish.LCK.objhdr.locksLock operations.\nvarnish.LCK.pipestat.creatCreated locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.pipestat.destroyDestroyed locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.pipestat.locksLock operations. This metric is only provided by varnish 4.x.\nvarnish.LCK.sess.creatCreated locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.sess.destroyDestroyed locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.sess.locksLock operations. This metric is only provided by varnish 4.x.\nvarnish.LCK.sessmem.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.sessmem.creatCreated locks.\nvarnish.LCK.sessmem.destroyDestroyed locks.\nvarnish.LCK.sessmem.locksLock operations.\nvarnish.LCK.sma.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.sma.creatCreated locks.\nvarnish.LCK.sma.destroyDestroyed locks.\nvarnish.LCK.sma.locksLock operations.\nvarnish.LCK.smf.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.smf.creatCreated locks.\nvarnish.LCK.smf.destroyDestroyed locks.\nvarnish.LCK.smf.locksLock operations.\nvarnish.LCK.smp.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.smp.creatCreated locks.\nvarnish.LCK.smp.destroyDestroyed locks.\nvarnish.LCK.smp.locksLock operations.\nvarnish.LCK.sms.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.sms.creatCreated locks.\nvarnish.LCK.sms.destroyDestroyed locks.\nvarnish.LCK.sms.locksLock operations.\nvarnish.LCK.stat.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.stat.creatCreated locks. This metric is only provided by varnish 3.x.\nvarnish.LCK.stat.destroyDestroyed locks. This metric is only provided by varnish 3.x.\nvarnish.LCK.stat.locksLock operations. This metric is only provided by varnish 3.x.\nvarnish.LCK.vbe.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.vbe.creatCreated locks. This metric is only provided by varnish 3.x.\nvarnish.LCK.vbe.destroyDestroyed locks. This metric is only provided by varnish 3.x.\nvarnish.LCK.vbe.locksLock operations. This metric is only provided by varnish 3.x.\nvarnish.LCK.vbp.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.vbp.creatCreated locks.\nvarnish.LCK.vbp.destroyDestroyed locks.\nvarnish.LCK.vbp.locksLock operations.\nvarnish.LCK.vcapace.creatCreated locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.vcapace.destroyDestroyed locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.vcapace.locksLock operations. This metric is only provided by varnish 4.x.\nvarnish.LCK.vcl.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.vcl.creatCreated locks.\nvarnish.LCK.vcl.destroyDestroyed locks.\nvarnish.LCK.vcl.locksLock operations.\nvarnish.LCK.vxid.creatCreated locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.vxid.destroyDestroyed locks. This metric is only provided by varnish 4.x.\nvarnish.LCK.vxid.locksLock operations. This metric is only provided by varnish 4.x.\nvarnish.LCK.wq.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.wq.creatCreated locks.\nvarnish.LCK.wq.destroyDestroyed locks.\nvarnish.LCK.wq.locksLock operations.\nvarnish.LCK.wstat.collsCollisions. This metric is only provided by varnish 3.x.\nvarnish.LCK.wstat.creatCreated locks.\nvarnish.LCK.wstat.destroyDestroyed locks.\nvarnish.LCK.wstat.locksLock operations.\nvarnish.losthdrHTTP header overflows.\nvarnish.MEMPOOL.busyobj.allocsAllocations. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.freesFrees. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.liveIn use. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.poolIn pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.randryPool ran dry. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.recycleRecycled from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.surplusToo many for pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.sz_neededSize allocated. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.sz_wantedSize requested. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.timeoutTimed out from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.busyobj.toosmallToo small to recycle. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.allocsAllocations. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.freesFrees. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.liveIn use. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.poolIn pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.randryPool ran dry. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.recycleRecycled from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.surplusToo many for pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.sz_neededSize allocated. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.sz_wantedSize requested. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.timeoutTimed out from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req0.toosmallToo small to recycle. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.allocsAllocations. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.freesFrees. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.liveIn use. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.poolIn pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.randryPool ran dry. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.recycleRecycled from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.surplusToo many for pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.sz_neededSize allocated. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.sz_wantedSize requested. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.timeoutTimed out from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.req1.toosmallToo small to recycle. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.allocsAllocations. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.freesFrees. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.liveIn use. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.poolIn pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.randryPool ran dry. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.recycleRecycled from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.surplusToo many for pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.sz_neededSize allocated. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.sz_wantedSize requested. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.timeoutTimed out from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess0.toosmallToo small to recycle. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.allocsAllocations. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.freesFrees. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.liveIn use. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.poolIn pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.randryPool ran dry. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.recycleRecycled from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.surplusToo many for pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.sz_neededSize allocated. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.sz_wantedSize requested. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.timeoutTimed out from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.sess1.toosmallToo small to recycle. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.allocsAllocations. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.freesFrees. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.liveIn use. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.poolIn pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.randryPool ran dry. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.recycleRecycled from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.surplusToo many for pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.sz_neededSize allocated. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.sz_wantedSize requested. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.timeoutTimed out from pool. This metric is only provided by varnish 4.x.\nvarnish.MEMPOOL.vbc.toosmallToo small to recycle. This metric is only provided by varnish 4.x.\nvarnish.MGT.child_diedChild processes that died due to signals. This metric is only provided by varnish 4.x.\nvarnish.MGT.child_dumpChild processes that produced core dumps. This metric is only provided by varnish 4.x.\nvarnish.MGT.child_exitChild processes the were cleanly stopped. This metric is only provided by varnish 4.x.\nvarnish.MGT.child_panicChild processes that panicked. This metric is only provided by varnish 4.x.\nvarnish.MGT.child_startChild processes that started. This metric is only provided by varnish 4.x.\nvarnish.MGT.child_stopChild processes that exited with an unexpected return code. This metric is only provided by varnish 4.x.\nvarnish.MGT.uptimeThis metric is only provided by varnish 4.x.\nvarnish.n_backendNumber of backends.\nvarnish.n_banActive bans. This metric is only provided by varnish 3.x.\nvarnish.n_ban_addNew bans added. This metric is only provided by varnish 3.x.\nvarnish.n_ban_dupsDuplicate bans removed. This metric is only provided by varnish 3.x.\nvarnish.n_ban_obj_testObjects tested. This metric is only provided by varnish 3.x.\nvarnish.n_ban_re_testRegexps tested against. This metric is only provided by varnish 3.x.\nvarnish.n_ban_retireOld bans deleted. This metric is only provided by varnish 3.x.\nvarnish.n_expiredObjects that expired from cache because of TTL.\nvarnish.n_gunzipGunzip operations.\nvarnish.n_gzipGzip operations.\nvarnish.n_lru_moved\nMove operations done on the LRU list.\nvarnish.n_lru_nukedObjects forcefully evicted from storage to make room for new objects.\nvarnish.n_obj_purgedPurged objects. This metric is only provided by varnish 4.x.\nvarnish.n_objectobject structs made.\nvarnish.n_objectcoreobjectcore structs made.\nvarnish.n_objectheadobjecthead structs made.\nvarnish.n_objoverflowObjects overflowing workspace. This metric is only provided by varnish 3.x.\nvarnish.n_objsendfileObjects sent with sendfile. This metric is only provided by varnish 3.x.\nvarnish.n_objwriteObjects sent with write. This metric is only provided by varnish 3.x.\nvarnish.n_purgesPurges executed. This metric is only provided by varnish 4.x.\nvarnish.n_sesssess structs made. This metric is only provided by varnish 3.x.\nvarnish.n_sess_memsess_mem structs made. This metric is only provided by varnish 3.x.\nvarnish.n_vampireobjectUnresurrected objects.\nvarnish.n_vbcvbc structs made. This metric is only provided by varnish 3.x.\nvarnish.n_vclTotal VCLs loaded.\nvarnish.n_vcl_availAvailable VCLs.\nvarnish.n_vcl_discardDiscarded VCLs.\nvarnish.n_waitinglistwaitinglist structs made.\nvarnish.n_wrkWorker threads. This metric is only provided by varnish 3.x.\nvarnish.n_wrk_createWorker threads created. This metric is only provided by varnish 3.x.\nvarnish.n_wrk_dropDropped work requests. This metric is only provided by varnish 3.x.\nvarnish.n_wrk_failedWorker threads not created. This metric is only provided by varnish 3.x.\nvarnish.n_wrk_lqueueWork request queue length. This metric is only provided by varnish 3.x.\nvarnish.n_wrk_maxWorker threads limited. This metric is only provided by varnish 3.x.\nvarnish.n_wrk_queuedQueued work requests. This metric is only provided by varnish 3.x.\nvarnish.poolsThread pools. This metric is only provided by varnish 4.x.\nvarnish.s_bodybytesTotal body size. This metric is only provided by varnish 3.x.\nvarnish.s_fetchBackend fetches.\nvarnish.s_hdrbytesTotal header size. This metric is only provided by varnish 3.x.\nvarnish.s_passPassed requests.\nvarnish.s_pipePipe sessions seen.\nvarnish.s_pipe_hdrbytesTotal request bytes received for piped sessions. This metric is only provided by varnish 4.x.\nvarnish.s_pipe_inTotal number of bytes forwarded from clients in pipe sessions. This metric is only provided by varnish 4.x.\nvarnish.s_pipe_outTotal number of bytes forwarded to clients in pipe sessions. This metric is only provided by varnish 4.x.\nvarnish.s_reqRequests.\nvarnish.s_req_bodybytesTotal request body bytes received. This metric is only provided by varnish 4.x.\nvarnish.s_req_hdrbytesTotal request header bytes received. This metric is only provided by varnish 4.x.\nvarnish.s_resp_bodybytesTotal response body bytes transmitted. This metric is only provided by varnish 4.x.\nvarnish.s_resp_hdrbytesTotal response header bytes transmitted. This metric is only provided by varnish 4.x.\nvarnish.s_sessClient connections.\nvarnish.s_synthSynthetic responses made. This metric is only provided by varnish 4.x.\nvarnish.sess_closedClient connections closed.\nvarnish.sess_connClient connections accepted. This metric is only provided by varnish 4.x.\nvarnish.sess_dropClient connections dropped due to lack of worker thread. This metric is only provided by varnish 4.x.\nvarnish.sess_droppedClient connections dropped due to a full queue. This metric is only provided by varnish 4.x.\nvarnish.sess_failFailures to accept a TCP connection. Either the client changed its mind, or the kernel ran out of some resource like file descriptors. This metric is only provided by varnish 4.x.\nvarnish.sess_herd varnish.sess_lingerThis metric is only provided by varnish 3.x.\nvarnish.sess_pipe_overflowThis metric is only provided by varnish 4.x.\nvarnish.sess_pipeline varnish.sess_queuedClient connections queued to wait for a thread. This metric is only provided by varnish 4.x.\nvarnish.sess_readahead varnish.shm_contSHM MTX contention.\nvarnish.shm_cyclesSHM cycles through buffer.\nvarnish.shm_flushesSHM flushes due to overflow.\nvarnish.shm_recordsSHM records.\nvarnish.shm_writesSHM writes.\nvarnish.SMA.s0.c_bytesTotal space allocated by this storage.\nvarnish.SMA.s0.c_failTimes the storage has failed to provide a storage segment.\nvarnish.SMA.s0.c_freedTotal space returned to this storage.\nvarnish.SMA.s0.c_reqTimes the storage has been asked to provide a storage segment.\nvarnish.SMA.s0.g_allocStorage allocations outstanding.\nvarnish.SMA.s0.g_bytesSpace allocated from the storage.\nvarnish.SMA.s0.g_spaceSpace left in the storage.\nvarnish.SMA.Transient.c_bytesTotal space allocated by this storage.\nvarnish.SMA.Transient.c_failTimes the storage has failed to provide a storage segment.\nvarnish.SMA.Transient.c_freedTotal space returned to this storage.\nvarnish.SMA.Transient.c_reqTimes the storage has been asked to provide a storage segment.\nvarnish.SMA.Transient.g_allocStorage allocations outstanding.\nvarnish.SMA.Transient.g_bytesSpace allocated from the storage.\nvarnish.SMA.Transient.g_spaceSpace left in the storage.\nvarnish.sms_ballocSMS space allocated.\nvarnish.sms_bfreeSMS space freed.\nvarnish.sms_nbytesSMS outstanding space.\nvarnish.sms_nobjSMS outstanding allocations.\nvarnish.sms_nreqSMS allocator requests.\nvarnish.thread_queue_lenLength of session queue waiting for threads. This metric is only provided by varnish 4.x.\nvarnish.threadsNumber of threads. This metric is only provided by varnish 4.x.\nvarnish.threads_createdThreads created. This metric is only provided by varnish 4.x.\nvarnish.threads_destroyedThreads destroyed. This metric is only provided by varnish 4.x.\nvarnish.threads_failedThreads that failed to get created. This metric is only provided by varnish 4.x.\nvarnish.threads_limitedThreads that were needed but couldn\u0026rsquo;t be created because of a thread pool limit. This metric is only provided by varnish 4.x.\nvarnish.uptimevarnish.vmodsLoaded VMODs. This metric is only provided by varnish 4.x.\nvarnish.vsm_coolingSpace which will soon (max 1 minute) be freed in the shared memory used to communicate with tools like varnishstat, varnishlog etc. This metric is only provided by varnish 4.x.\nvarnish.vsm_freeFree space in the shared memory used to communicate with tools like varnishstat, varnishlog etc. This metric is only provided by varnish 4.x.\nvarnish.vsm_overflowData which does not fit in the shared memory used to communicate with tools like varnishstat, varnishlog etc. This metric is only provided by varnish 4.x.\nvarnish.vsm_overflowedTotal data which did not fit in the shared memory used to communicate with tools like varnishstat, varnishlog etc. This metric is only provided by varnish 4.x.\nvarnish.vsm_usedUsed space in the shared memory used to communicate with tools like varnishstat, varnishlog etc. This metric is only provided by varnish 4.x.\nvarnish.n_purgespsPurges executed. This metric is only provided by varnish 4.x.\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/varnish-metrics/"},{"id":812,"title":"Metrics in Sysdig Legacy Format","content":"The metrics listed in this section follows the statsd-compatible Sysdig naming convention. To see a mapping between Prometheus notation and Sysdig notation, see Metrics and Label Mapping.\nFor the metrics collected using Monitoring Integration, see Integration Library.\nOverviewEach metric in the dictionary has several pieces of metadata listed to provide greater context for how the metric can be used within Sysdig products. An example layout is displayed below:\nMetric NameMetric definition. For some metrics, the equation for how the value is determined is provided.\nMetadata\nDefinition\nMetric Type\nMetric type determines whether the metric value is a counter metric or a gauge metric. Sysdig Monitor offers two Metric types:\nCounter: The metric whose value keeps on increasing and is reliant on previous values. It helps you record how many times something has happened, for example, a user login.\nGauge: Represents a single numerical value that can arbitrarily fluctuate over time. Each value returns an instantaneous measurement, for example, CPU usage.\nValue Type\nThe type of value the metric can have. The possible values are:\nPercent (%)\nByte\nDate\nDouble\nInteger (int)\nrelativeTime\nString\nSegment By\nThe levels within the infrastructure that the metric can be segmented at:\nHost\nContainer\nProcess\nKubernetes\nMesos\nSwarm\nCloudProvider\nDefault Time Aggregation\nThe default time aggregation format for the metric.\nAvailable Time Aggregation Formats\nThe time aggregation formats the metric can be aggregated by:\nAverage (Avg)\nRate\nSum\nMinimum (Min)\nMaximum (Max)\nDefault Group Aggregation\nThe default group aggregation format for the metric.\nAvailable Group Aggregation Formats\nThe group aggregation formats the metric can be aggregated by:\nAverage (Avg)\nSum\nMinimum (Min)\nMaximum (Max)\n","url":"https://docs.sysdig.com/en/metrics-library/sysdig-legacy-format/"},{"id":813,"title":"Application Metrics in Sysdig Legacy Format","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nLearn MoreSee Integrate Applications (Default App Checks).\nFor the application metrics collected using Monitoring Integration, see Integration Library\n","url":"https://docs.sysdig.com/en/sysdig-monitor/app-metrics-legacy/"},{"id":814,"title":"AWS Metrics in Sysdig Legacy Format","content":" Sysdig follows the Prometheus-compatible naming convention for both metrics and labels as opposed to the previous statsd-compatible, legacy Sysdig naming convention. This page shows metrics in the legacy Sysdig naming convention. See Metrics and Label Mapping for the mapping between Sysdig legacy and Prometheus naming conventions.\nFor information about how Sysdig licensing affects the AWS metrics displayed in the Monitor UI, see About AWS Cloudwatch Licensing.\nAt this time, all cloudProvider metrics are AWS-related.\ncloudProvider.account.idThe cloud provider instance account number.\nThis metric is useful if there are multiple accounts linked with Sysdig Monitor.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.availabilityZoneThe AWS Availability Zone where the entity or entities are located. Each availability zone is an isolated subsection of an AWS region. See cloudProvider.region.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.host.ip.privateThe private IP address allocated by the cloud provider for the instance. This address can be used for communication between instances in the same network.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.host.ip.publicPublic IP address of the selected host.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.host.nameThe name of the host as reported by the cloud provider.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.idThe ID number as assigned and reported by the cloud provider.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.instance.typeThe type of instance (for example, AWS or Rackspace).\nThis metric is extremely useful to segment instances and compare their resource usage and saturation. You can use it as a grouping criteria for the explore table to quickly explore AWS usage on a per-instance-type basis. You can also use it to compare things like CPU usage, number of requests or network utilization for different instance types.\nUse this grouping criteria in conjunction with the host.count metric to easily create a report on how many instances of each type you have.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.nameThe name of the instance (for example, AWS or Rackspace).\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.regionThe region the cloud provider host (or group of hosts) is located in.\nUse this grouping criteria in conjunction with the host.count metric to easily create a report on how many instances you have in each region.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.resource.endPointThe DNS name for which the resource can be accessed.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.resource.nameThe cloud provider service name (for example, Amazon EC2 or Amazon ELB).\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.resource.typeThe cloud provider service type (for example, INSTANCE, LOAD_BALANCER, DATABASE).\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A cloudProvider.statusResource status.\nMetadata Description Metric Type Gauge Value Type String Segment By CloudProvider Default Time Aggregation N/A Available Time Aggregation Formats N/A Default Group Aggregation N/A Available Group Aggregation Formats N/A ","url":"https://docs.sysdig.com/en/sysdig-monitor/aws-metrics-legacy/"},{"id":815,"title":"Metrics and Labels Mapping","content":"","url":"https://docs.sysdig.com/en/docs/sysdig-monitor/metrics-and-labels-mapping/"},{"id":816,"title":"Microsoft Teams Notifications","content":" Microsoft has announced the deprecation of Office 365 Connectors, which are used for sending notifications to Microsoft Teams. To migrate, see Migrate from Office 365 Connectors to Power Automate.\nAbout Incoming WebhooksIncoming Webhooks are a type of Connector in Teams that provide a simple way for an external app to share content in team channels. They are often used as tracking and notification tools. Microsoft Teams provides a unique URL to which you can send a JSON payload with the message that you want to POST, typically in a card format. Cards are UI containers that contain content and actions related to a single topic and are a way to present message data in a consistent way.\nYou will need to enter the URL that you copied from the Connector. Sysdig will format a message by using a custom card template and send it to the channel. The message will show up as a new notification in the Microsoft application.\nPrerequisites Have the destination URL handy. You can copy it from the Connectors \u0026gt; Incoming Webhook window on the Microsoft Teams UI. For more information, see Add an incoming Webhook to a Teams channel.\nNote: Webhooks via HTTPS work only when a signed or valid certificate is in use.\nSupportMicrosoft Team notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts Microsoft Team notification channels are supported for the following use cases in Sysdig Secure:\nRuntime Policies: Standard and shortened messages. Risks Threats Vulnerabilities Accepted Risk: Vulnerabilities Enable Microsoft Teams Log in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channel \u0026gt; Microsoft Teams.\nEnter the configuration options:\nURL: The destination URL you have copied from Microsoft Teams UI.\nChannel Name: Add a meaningful name for your channel.\nEnabled: Toggle on or off.\nNotification options: Toggle for notifications when alerts are resolved or acknowledged.\nTest notification: Toggle to be notified that the configured URL is working.\nShared With: Choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nClick Save.\nChoose Message Format (Secure Only)The \u0026ldquo;Configure Channel Sections\u0026rdquo; option applies only to notifications sent from Sysdig Secure events governed by Threat Detection policies. Here you can choose whether the message should be:\nShortened: (Default) Includes a summary of the event giving the rule, policy name, and contextual information about where the event took place. When available, a Runbook Link and Action Taken are displayed. Detailed: Includes full event details, as shown. Migrate from Office 365 Connectors to Power AutomateMicrosoft has announced the deprecation of Office 365 Connectors, which are used for sending notifications to Microsoft Teams. According to their notice, new notification channels using the Office 365 Connector cannot be created after August 15th, 2024, and existing connectors will require a URL update to function after December 31st, 2024.\nYou can find more details in the official Microsoft retirement notice.\nTo ensure uninterrupted notification delivery to Microsoft Teams, it is essential to migrate from Office 365 Connectors to Power Automate for both Sysdig Secure and Sysdig Monitor before Microsoft’s full deprecation of Office 365 Connectors.\nCreate an Automate Workflow to Replace Office 365 ConnectorPower Automate is an automation platform that replaces Office 365 Connectors. To transition from Office 365 connectors, you must create a Power Automate Workflow endpoint. This new endpoint will replace the current Office 365 Connectors endpoints that forwards to Microsoft Teams.\nPower Automate does not support forwarding to private channels. See Known Issues and Limitations.\nSteps Preview 1. From your Microsoft Teams UI, create a Workflow and select Post to a channel when a webhook request is received. 2. Give a name to the Workflow. 3. Retrieve the new endpoint. 4. Replace the endpoint of your Microsoft Teams Notification channel. To ensure a successful migration to Power Automate, send a test notification. ","url":"https://docs.sysdig.com/en/microsoft-teams-notifications/"},{"id":817,"title":"OpsGenie Notifications","content":"SupportOpsGenie notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts OpsGenie notification channels are supported for the following use cases in Sysdig Secure:\nThreat Detection Runtime Policies Create an OpsGenie Notification Channel Open OpsGenie Integrations to configure the integration on the OpsGenie side.\nOpsGenie maintains documentation on how to integrate with Sysdig products (formerly called Sysdig Cloud)here.\nCopy your OpsGenie integration API key for later use.\nLog in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channel \u0026gt; OpsGenie.\nSpecify the following:\nRegion: The Sysdig region associated with your account. See SaaS Regions and IP Ranges. API Key: Paste your OpsGenie integration API key. Channel Name: Specify a channel name. Adjust the enablement and notification toggles as appropriate.\nFrom Shared With, choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nClick Save.\n","url":"https://docs.sysdig.com/en/administration/opsgenie-notifications/"},{"id":818,"title":"PagerDuty Notifications","content":"SupportPagerDuty notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts PagerDuty notification channels are supported for the following use cases in Sysdig Secure:\nRuntime Policies Risks Threats Vulnerabilities Accepted Risk: Vulnerabilities Prerequisites Have an account configured at PagerDuty.com.\nHave your PagerDuty credentials available (account, password, and service).\nHave the base user role of Manager. With this permission, you can auto-fetch the service information during the Sysdig/PagerDuty integration process.\nCheck your team and base user permissions. If your PagerDuty team permissions are Manager but base user permissions are Responder or lower, you can enter the necessary data in the Sysdig UI manually.\nBase user roles in the PagerDuty UI.\nConfigure PagerDuty Log in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channel \u0026gt; PagerDuty.\nDo one of the following:\nSelect Auto-fetch when prompted. Ensure that you have the base user role of Manager or higher in PagerDuty.\nSelect Manual and enter the necessary configuration parameter. Skip to Step 5 for details.\nOnce you complete the pre-configuration, the PagerDuty Integration screen is displayed.\nDo one of the following:\nEnter the email and password associated with your PagerDuty account, and click Sign In.\nEnter the appropriate PagerDuty subdomain for single sign-on and click Sign In Using Your Identity Provider.\nA PagerDuty service selection screen is displayed.\nOption 1: If you have never integrated before, you are prompted to choose a PagerDuty Servicename.\nOption 2: If at least one service has already been integrated, you can select that one.\nClick Connect.\nOnce integration is authorized, the Sysdig page for a new PagerDuty notification channel is displayed, with the information auto-filled.\nFrom Shared With, choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nDo one of the following:\nConfirm the auto-populated information and click Save.\nIf you chose Manual entry in Step 2, then type the information and click Save.\nYou can now Add an Alert to use PagerDuty notifications.\nKnown IssuesIn Sysdig Monitor, there is a known issue whereby changing a notification from \u0026ldquo;Acknowledged\u0026rdquo; to \u0026ldquo;Unacknowledged\u0026rdquo; does not update correctly in PagerDuty.\nWhat occurs:\nEvent has triggered Notification, Notification is sent to PagerDuty.\nOpen Event and click on \u0026ldquo;Acknowledge\u0026rdquo; button in Sysdig.\nNotification is sent to PagerDuty, and status is changed to \u0026ldquo;Acknowledged.\u0026rdquo;\nOpen the relevant Event and click the Unacknowledge button in Sysdig.\nStatus is not changed in PagerDuty. It remains \u0026ldquo;Acknowledged\u0026rdquo; rather than changing to \u0026ldquo;Triggered\u0026rdquo; in PagerDuty.\nContact SupportFor other issues, see Sysdig Support.\n","url":"https://docs.sysdig.com/en/administration/pagerduty-notifications/"},{"id":819,"title":"Prometheus Alertmanager Notifications","content":"Prerequisites HTTPS webhooks only work when a signed/valid certificate is in use.\nHave your desired destination URL on hand.\nSupportPrometheus Alert Manager notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts Prometheus Alert Manager notification channels are not supported for Sysdig Secure.\nEnable Prometheus Alert Manager Log in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channels \u0026gt; Prometheus Alert Manager.\nEnter the Prometheus Alert Manager channel configuration options:\nURL: The destination URL to which notifications will be sent.\nChannel Name: Add a meaningful name, such as \u0026ldquo;Prometheus channel\u0026rdquo;.\nEnabled: Toggle notifications on and off.\nNotification options: Toggle for notifications when alerts are resolved or acknowledged.\nTest notification: Toggle to be notified that the configured URL is working.\nShared With: Choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nAllow insecure connections: Enable if you want to skip the TLS verification.\nCustom headers: Add custom headers to your alert notification. If your Alertmanager channel requires additional headers you can specify them by using a custom header.\nAlternatively, you can choose to add custom headers programmatically as described in Configure Custom Headers Programmatically.\nClick Save.\nWhen the channel is created, you can use it on any alerts you create.\nWhen the alert fires, the notification will be sent as a POST in JSON format to your webhook endpoint.\nFor testing purposes, you can use a third-party site to create a temporary endpoint to see exactly what a Sysdig alert will send in any specific notification.\nConfigure Custom Headers ProgrammaticallyAlert notifications, by default, follow a standard format. However, some integrations require additional headers which you can append to the alert format by using a custom header entry.\nFor example, some applications use token-based authentication, which requires an entry for the bearer token. This entry is not included in Sysdig\u0026rsquo;s default alert template, but you can add it using a custom header.\nThe following example adds two custom headers:\nUse the following curl command to retrieve all configured notification channels:\ncurl -X GET https://app.sysdigcloud.com/api/notificationChannels -H \u0026#39;Authorization: Bearer API-KEY\u0026#39; Add the custom headers and execute the request:\ncurl -X PUT https://app.sysdigcloud.com/api/notificationChannels/1 -H \u0026#39;Authorization: Bearer API-KEY\u0026#39; -H \u0026#39;Content-Type: application/json\u0026#39; -d \u0026#39;{ \u0026#34;notificationChannel\u0026#34;: { \u0026#34;id\u0026#34;: 1, \u0026#34;version\u0026#34;: 1, \u0026#34;type\u0026#34;: \u0026#34;PROMETHEUS_ALERT_MANAGER\u0026#34;, \u0026#34;enabled\u0026#34;: true, \u0026#34;name\u0026#34;: \u0026#34;Test-Sysdig\u0026#34;, \u0026#34;options\u0026#34;: { \u0026#34;notifyOnOk\u0026#34;: true, \u0026#34;url\u0026#34;: \u0026#34;https://hookb.in/v95r78No\u0026#34;, \u0026#34;notifyOnResolve\u0026#34;: true, \u0026#34;additionalHeaders\u0026#34;: { \u0026#34;Header-1\u0026#34;: \u0026#34;Header-Value-1\u0026#34;, \u0026#34;Header-2\u0026#34;: \u0026#34;Header-Value-2\u0026#34; } } } }\u0026#39; Learn More Alertmanager Alertmanager Configuration ","url":"https://docs.sysdig.com/en/administration/prometheus-alert-manager-notifications/"},{"id":820,"title":"Slack Notifications","content":"SupportSlack notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts Silence Rule Notifications Cost Advisor Reports Slack notification channels are supported for the following use cases in Sysdig Secure:\nRuntime Policies: Standard and shortened messages. Reporting Risks Threats Vulnerabilities Accepted Risk: Vulnerabilities ConfigurationTo create and configure a Slack Notification Channel:\nLog in to Sysdig Monitor or Sysdig Secure as Administrator.\nSelect Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channel \u0026gt; Slack.\nFrom Slack Instance, select either:\nCommercial Slack GovSlack Click Start Slack Integration.\nSelect a Slack channel from the drop-down list to be used for notifications and click Allow.\nEnter the Slack channel configuration options:\nChannel Name: Add a meaningful name, such as \u0026ldquo;Sysdig Notifications\u0026rdquo;.\nEnabled: Toggle notifications on and off.\nNotify when Resolved: Toggle to send a notification when the alert condition is no longer triggered.\nNotify when Acknowledged: Toggle to send a notification when the alert is manually acknowledged by a user.\nTest notification: Toggle to send a test notification when saving changes.\nShared With: Choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nIf you are using Monitor, see Customize Notifications for further configuration options. If you are using Secure, see Choose Notification Format.\nClick Save.\nYou can now configure an Alert to use Slack notifications.\nFor on-prem installations, use the Webhook method to configure a Slack notification channel by specifying the webhook URL and a unique name for the Slack channel.\nCustomize Notifications (Monitor)If you are using Sysdig Monitor, you can customize the sections used when Sysdig sends alert notifications to Slack. This gives you the ability the fine tune the contents and length of Slack notifications according to your preferences.\nToggle sections on or off to alter the length of messages. The preview on the right will respond to your changes.\nChoose Notification Format (Secure)If you are using Sysdig Secure, you can customize the sections used when Sysdig sends event notifications related to Secure Policy Events. Choose between:\nShortened View: (Default) Includes a summary of the event giving rule, policy name, and contextual information about where the event took place. When available, a Runbook link and Action taken are displayed. Detailed View: Includes full event details, including policy, rule, actions, runbook link, and other contextual details. Test a Slack ChannelTo test a Slack channel:\nNavigate to Notification Channels.\nFind the Slack channel in the list. Make use of the search bar if you have a large number of channels.\nClick on the three dots for your channel. A menu will open.\nSelect Test Channel.\nDelete a Slack Notification ChannelTo delete a Slack channel completely, delete it in the Sysdig UI, and also revoke the channel webhook in Slack.\nWebhooks are not invalidated upon deletion of the notification channel.\nIn the Sysdig UI:\nNavigate to Settings \u0026gt; Notification Channels.\nLocate the channel you want to delete. You can use the search bar.\nClick the three-dot menu icon on the right side of the channel listing.\nSelect Delete Channel, and confirm the deletion.\nThe channel disappears from the UI. However, the webhook still exists.\nTo delete the webhook:\nOpen Slack, and locate the Sysdig app. You can do this by locating the notification channel you used. Alternatively, from the Slack sidebar, select More \u0026gt; Automations \u0026gt; Apps \u0026gt; Sysdig.\nOn the Sysdig app page, select Configuration.\nYour browsers opens to the Slack Marketplace.\nClick Revoke on the webhook you want to delete.\nThe webhook has now been deleted.\n","url":"https://docs.sysdig.com/en/administration/slack-notifications/"},{"id":821,"title":"Sysdig Team Email Notifications","content":"SupportSysdig Team Email notification channels are supported for the following use cases in Sysdig Monitor:\nAlerts Sysdig Team Email notification channels are supported for the following use cases in Sysdig Secure:\nRuntime Policies PrerequisitesTo send an alert notification via email to a team, you must first:\nCreate a Team.\nTo do so, complete the steps in Create a Team.\nSet up the team email notification channel.\nTo do so, complete steps 1-3 in Set Up a Notification Channel\nCreate a Team Email Channel Select Team Email.\nEnter the relevant details for the email notification:\nSelect the Team Name and specify a Channel Name to identify the channel you are creating.\nFrom Shared With drop-down, choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nClick Save.\nIf you enabled Test notification, a test email will be sent to all members of the team.\nYou can now configure an alert to use team email notifications.\n","url":"https://docs.sysdig.com/en/administration/configure-team-email-notification/"},{"id":822,"title":"VictorOps Notifications","content":"SupportSysdig supports VictorOps notification channels for the following use cases in Sysdig Monitor:\nAlerts Sysdig supports VictorOps notification channels for the following use cases in Sysdig Secure:\nRuntime Policies Integrate a VictorOps Account Log in to VictorOps.\nGo to Settings \u0026gt; Alert Behavior \u0026gt; Integrations in the VictorOps interface.\nSelect REST from the list of featured Integrations.\nCreate a VictorOps ChannelTo create a notification channel for an integrated VictorOps account:\nLog in to Sysdig Monitor or Sysdig Secure.\nFrom the user menu in the bottom left, select Integrations \u0026gt; Notification Channels.\nSelect Add Notification Channel.\nSelect VictorOps.\nEnter the VictorOps parameters in the New VictorOps Channel fields, as follows:\nRouting Key: A VictorOps way of routing alerts to appropriate teams. See the VictorOps Routing Keys documentation for details.\nAPI Key: everything between \u0026quot;/alert/\u0026quot; and \u0026ldquo;/$routing_key\u0026rdquo; in the REST URL\nChannel Name: Choose a meaningful name for your channel.\nEnable the channel and desired notification types.\nFrom Shared With: Choose whether this channel can be used by All Teams or the Current Team you are logged in as.\nClick Save.\n","url":"https://docs.sysdig.com/en/administration/victorops-notifications/"},{"id":823,"title":"Falco Changelog 2025","content":"Subscribe to the RSS feed to stay updated with the latest Falco rules.\nCommit Date\nRule Notes\nVersion of the Falco Rules Installer (On-Prem)\nDecember 23, 2025\nRule Changes\nReduced FPs for Reverse Shell Spawned From Binary Through Pipes rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Fileless Malware Detected rule.\n0.231.5\nDecember 22, 2025\nRule Changes\nReduced FPs for K8s Namepace Created rule.\nReduced FPs for K8s ConfigMap Created rule.\n0.231.4\nDecember 19, 2025\nRule Changes\nReduced FPs for Memory Manipulation by Fileless Program rule.\nReduced FPs for Suspicious RC Script Modification rule.\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Anonymous Request Allowed rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Find GCP Credentials rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\n0.231.3\nDecember 18, 2025\nRule Changes\nReduced FPs for DNS Lookup for Miner Pool Domain Detected rule.\nReduced FPs for DNS Lookup for C2 Domain Detected rule.\nReduced FPs for DNS Lookup for Remote Access Domain Detected rule.\nReduced FPs for DNS Tunneling Activity Detected rule.\n0.231.2\nDecember 17, 2025\nRule Changes\nReduced FPs for Possible Backdoor using BPF rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Reconnaissance attempt to find SUID binaries rule.\nReduced FPs for Suspicious device created in container rule.\nReduced FPs for nsenter Container Escape rule.\nReduced FPs for Reconnaissance attempt to find SETGID binaries rule.\nReduced FPs for Find GCP Credentials rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\n0.231.1\nDecember 16, 2025\nRule Changes\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Perl Remote Command Execution Detected rule.\nReduced FPs for Hexadecimal string detected rule.\nReduced FPs for Possible Backdoor using BPF rule.\n0.231.0\nDecember 15, 2025\nRule Changes\nReduced FPs for DB program spawned process rule.\nReduced FPs for eBPF Program Loaded into Kernel rule.\nReduced FPs for Redirect STDOUT/STDIN to Network Connection in Container rule.\nReduced FPs for Possible Remote Command Execution Detected rule.\nReduced FPs for PTRACE anti-debug attempt rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\n0.230.3\nDecember 12, 2025\nRule Changes\nImproved condition for GCP Create API Keys for a Project.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nReduced FPs for Find GCP Credentials rule.\n0.230.2\nDecember 10, 2025\nRule Changes\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Find GCP Credentials rule.\n0.230.1\nDecember 09, 2025\nRule Changes\nReduced FPs for DNS Lookup for Uncommon TLD Domain Detected rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nNew Rules\nAdded Rule Azure Quota Request Created for ND-Family vCPUs.\nDefault Policy Changes\nAdded Rule Azure Quota Request Created for ND-Family vCPUs.\n0.230.0\nDecember 05, 2025\nRule Changes\nReduce FPs for Cloudtrail Management Events Disabled via Event Selectors rule.\nImproved detection for Suspicious Command Executed by Web Server rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\n0.229.0\nDecember 04, 2025\nRule Changes\nReduced FPs for Reconnaissance attempt to find SETGID binaries rule.\nReduced FPs for Reconnaissance attempt to find SUID binaries rule.\nReduced FPs for Network Relay Binary Exfiltration Activities Detected rule.\nReduced FPs for PTRACE anti-debug attempt rule.\nReduced FPs for Diamorphine Rootkit Activity rule.\n0.228.2\nDecember 04, 2025\nRule Changes\nReduced FPs for Launch Excessively Capable Container rule.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for Network Relay Binary Exfiltration Activities Detected rule.\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Unprivileged Delegation of Page Faults Handling to a Userspace Process rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\n0.228.1\nDecember 02, 2025\nRule Changes\nReduced FPs for JVM Attach Attempt using Unix Socket rule.\nImproved condition for Run Several XLarge EC2 Instances.\nAdded rule Request Several XLarge EC2 Spot Instances.\nDefault Policy Changes\n0.228.0\nDecember 01, 2025\nRule Changes\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Reconnaissance attempt to find SETGID binaries rule.\nReduced FPs for Reconnaissance attempt to find SUID binaries rule.\nReduced FPs for Read ssh information rule.\nReduced FPs for Modify Grub Configuration Files rule.\nReduced FPs for Suspicious RC Script Modification rule.\nReduced FPs for Unprivileged Delegation of Page Faults Handling to a Userspace Process rule.\n0.227.3\nNovember 28, 2025\nRule Changes\nReduced FPs for Fileless Malware Detected (memfd) rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Clear Log Activities rule.\n0.227.2\nNovember 26, 2025\nRule Changes\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Unprivileged Delegation of Page Faults Handling to a Userspace Process rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\n0.227.1\nNovember 25, 2025\nRule Changes\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nReduced FPs for Reconnaissance attempt to find SETGID binaries rule.\nReduced FPs for Reconnaissance attempt to find SUID binaries rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nImprove output for the Instance Metadata Service Contacted During Package Install rule.\nDefault Policy Changes\nUpdated Policy for Create Symlink Over Procfs Files.\n0.227.0\nNovember 24, 2025\nRule Changes\nReduced FPs for Create Sensitive Mount Pod rule.\nReduced FPs for Malicious Powershell Cmdlet detected rule.\nReduced FPs for New Kernel Module Created and Loaded rule.\nReduced FPs for Suspicious Kernel Parameter Modification rule.\nReduced FPs for Create Privileged Pod rule.\nReduced FPs for Create HostNetwork Pod rule.\n0.226.3\nNovember 21, 2025\nRule Changes\nReduced FPs for Create Sensitive Mount Pod rule.\nReduced FPs for Malicious Powershell Cmdlet detected rule.\nReduced FPs for New Kernel Module Created and Loaded rule.\nReduced FPs for Suspicious Kernel Parameter Modification rule.\nReduced FPs for Create Privileged Pod rule.\nReduced FPs for Create HostNetwork Pod rule.\n0.226.3\nNovember 20, 2025\nRule Changes\nImproved output for Terminal shell in container rule.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nReduced FPs for DB program spawned process rule.\n0.226.2\nNovember 19, 2025\nRule Changes\nReduced FPs for Directory traversal monitored file read rule.\nReduced FPs for Memory Manipulation by Fileless Program rule.\nReduced FPs for Modify binary dirs rule.\nReduced FPs for Clear Log Activities rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Debugfs Launched in Privileged Container rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\n0.226.1\nNovember 18, 2025\nNew Rules\nAdded rule Create Symlink Over Procfs Files.\nAdded rule Possible Exploitation of Kernel Netfilter Vulnerability (CVE-2024-1086).\nRule Changes\nReduced FPs for Create Sensitive Mount Pod rule.\nReduced FPs for Create Privileged Pod rule.\nReduced FPs for Create HostNetwork Pod rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nReduced FPs for Sensitive File Access Attempt Detected During Package Install rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nDefault Policy Changes\n0.226.0\nNovember 17, 2025\nRule Changes\nReduced FPs for Modification of pam.d detected rule.\nReduced FPs for Contact Task Metadata Endpoint rule.\nReduced FPs for Contact GCP Instance Metadata Service from Container rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\n0.225.3\nNovember 14, 2025\nRule Changes\nReduced FPs for BPF Command Executed by Fileless Program rule.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\nReduced FPs for PTRACE anti-debug attempt rule.\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\nReduced FPs for System Group Files Modification Detected rule.\n0.225.2\nNovember 13, 2025\nRule Changes\nReduced FPs for Base64-encoded Shell Script Execution rule.\nReduced FPs for Fileless Malware Detected (memfd) rule.\nReduced FPs for BPF Command Executed by Fileless Program rule.\nReduced FPs for The docker client is executed in a container rule.\nReduced FPs for Suspicious RC Script Modification rule.\nReduced FPs for Tampering with Security Software in Container rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Execution from /dev/shm rule.\n0.225.1\nNovember 13, 2025\nWhat's Changed\nNew Rules\nAdded Rule AWS KMS Imported Key Material Deleted.\nAdded Rule AWS KMS Imported Key Material.\nRule Changes\nImproved condition for Log File Symlink to Null rule.\nImproved condition for fd_name_exists macro.\nImproved Exceptions for k8s_audit rules.\nImproved output in falco_rules.yaml file.\nReduced FPs System Group Files Modification Detected rule.\nReduced FPs for Potential User Addition to Sudo Group rule.\nReduced FPs for eBPF Program Loaded into Kernel rule.\nReduced FPs for Packet socket created in container rule.\nReduced FPs for Launch Package Management Process in Container rule.\nReduced FPs for Run shell untrusted rule.\nReduced FPs for Memory Manipulation by Fileless Program rule.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for DNS Lookup for Dynamic DNS Domain Detected rule.\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\nDefault Policy Changes\n0.225.0\nNovember 06, 2025\nRule Changes\nReduced FPs for Network Relay Binary Exfiltration Activities Detected rule.\nReduced FPs for Instance Metadata Service Contacted During Package Install rule.\n0.224.2\nNovember 04, 2025\nNew Rules\nAdded rule Disable Block Public Access for EBS Snapshots.\nAdded rule Disable Block Public Access for VPCs.\nAdded rule Deactivate MFA for IAM Identity Center.\nAdded rule Disable Cross-Account Backup.\nAdded rule Delete Backup Vault Lock Configuration.\nAdded rule Cancel Backup Legal Hold.\nAdded rule Route53 Transfer Domain to Another AWS Account.\nRule Changes\nReduced FPs for System Group Files Modification Detected rule.\nReduced FPs for Potential User Addition to Sudo Group rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for PTRACE attached to process rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for BPF Command Executed by Fileless Program rule.\nDefault Policy Changes\nPolicy update for Sensitive File Access Attempt Detected During Package Install rule.\nPolicy update for Instance Metadata Service Contacted During Package Install rule.\nPolicy update for Potential Secret Dump from etcd rule.\n0.224.0\nNovember 03, 2025\nRule Changes\nReduced FPs for eBPF Program Loaded into Kernel rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Fileless Malware Detected (memfd) rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Execution from /tmp rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for Delete or rename shell history rule.\n0.223.2\nOctober 30, 2025\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nFix exceptions typo in GuardDuty rules.\nReduced FPs for Unprivileged Delegation of Page Faults Handling to a Userspace Process rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Hexadecimal string detected rule.\nReduced FPs for Read K8s Service Account Token from Terminal rule.\nReduced FPs for DNS Lookup for IPFS Domain Detected rule.\n0.223.1\nOctober 28, 2025\nNew Rules\nAdded rule Possible Arbitrary Command Execution through CUPS.\nAdded rule System Group Files Modification Detected.\nAdded rule Potential User Addition to Sudo Group.\nRule Changes\nImprove Condition for GCP Update CloudSQL.\nImprove Condition for GCP Disable Automatic Backups for a Cloud SQL Instance.\nImprove Condition for GCP Disable the Requirement for All Incoming Connections to Use SSL for a Cloud SQL Instance.\nImprove Condition for GCP Set a Public IP for a Cloud SQL Instance.\nImprove Condition for GCP Cloud SQL Data Exfiltration.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for Debugfs Launched in Privileged Container rule.\nReduced FPs for Fileless Malware Detected (memfd) rule.\nReduced FPs for BPF Command Executed by Fileless Program rule.\nReduced FPs for BPFDoor Backdoor Activity Detected rule.\nReduced FPs for Read sensitive file untrusted rule.\nReplace exceptions for k8s_audit rules.\nDeprecate Possible Arbitrary Command Execution through CUPS (CVE-2024-47177) rule.\nDefault Policy Changes\n0.223.0\nOctober 24, 2025\nRule Changes\nReduced FPs for Launch Sensitive Mount Container rule.\nReduced FPs for Create Privileged Pod.\nReduced FPs for Reverse Shell Spawned From Interpreted or Compiled Program Through Pipes rule.\nReduced FPs for Dynamic Linker Hijacking Using ld.so Files rule.\nReduced FPs for Suspicious RC Script Modification rule.\nReduced FPs for DNS Lookup for Offensive Security Tool Domain Detected rule.\nReduced FPs for Network Relay Binary Exfiltration Activities Detected rule.\nUpdate Macros.\n0.222.2\nOctober 23, 2025\nRule Changes\nImprove exceptions for k8s_audit rules.\nReduced FPs for Reverse Shell Spawned From Interpreted or Compiled Program Through Pipes rule.\nReduced FPs for DNS Tunneling Activity Detected rule.\nReduced FPs for Run shell untrusted rule.\nReduced FPs for Clear Log Activities rule.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\nReduced FPs for Data Exfiltration using DNS rule.\n0.222.1\nOctober 21, 2025\nNew Rules\nAdded rule Instance Metadata Service Contacted During Package Install.\nAdded rule Sensitive File Access Attempt Detected During Package Install.\nAdded rule Potential Secret Dump from etcd.\nRule Changes\nImproved condition for Reverse Shell Redirects STDIN/STDOUT To Sibling Processes Using Named Pipe rule.\nReduced FPs for Clear Log Activities rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Reverse Shell Spawned From Interpreted or Compiled Program Through Pipes rule.\nDefault Policy Changes\nUpdated policy for Create RDS DB Instance with Public Access.\n0.222.0\nOctober 20, 2025\nRule Changes\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for PTRACE anti-debug attempt rule.\nReduced FPs for Reverse Shell Spawned From Binary Through Pipes rule.\nList trusted containers Added.\n0.221.6\nOctober 17, 2025\nRule Changes\nReduced FPs for Create Privileged Pod rule.\nReduced FPs for Reverse Shell Redirects STDIN/STDOUT Using UNIX Socket rule.\nImproved exception for Create Sensitive Mount Pod rule.\n0.221.4\nOctober 16, 2025\nRule Changes\nImproved exception comps for `k8s_audit` rules.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\nReduced FPs for Suspicious Home Directory Creation rule.\nReduced FPs for Fileless Malware Detected (memfd) rule.\nReduced FPs for Dump memory using /proc filesystem rule.\n0.221.3\nOctober 14, 2025\nRule Changes\nImproved output rules.\nReduced FPs for PTRACE anti-debug attempt rule.\nReduced FPs for Create Symlink Over Sensitive Files rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Drop and Execute /tmp Binary rule.\nReduced FPs for BPF Command Executed by Fileless Program rule.\nReduced FPs for Launch Privileged Container rule.\nReduced FPs for Contact K8S API Server From Container rule.\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\n0.221.2\nOctober 08, 2025\nRule Changes\nReduced FPs for Network Tool Executed During NPM Install rule.\nReduced FPs for Drop and execute new binary in container rule.\nReduced FPs for Launch Root User Container rule.\nImproved list azure_trusted_images_launch_root_list.\nReduced FPs for Read Sensitive File Untrusted rule.\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Contact K8S API Server From Container rule.\nReduced FPs for Redirect STDOUT/STDIN to Network Connection in Container rule.\n0.221.1\nOctober 07, 2025\nRule Changes\nReduced FPs for Network Tool Executed During NPM Install rule.\nReduced FPs for ECR Image Pushed rule.\nReduced FPs for List Buckets rule.\nImproved macro sysdig_images_endswith.\nAdded k8s_audit rule Pod Created To Debug Kubernetes Node.\nReduced FPs for Detect outbound connections to common miner pool ports rule.\nReduced FPs for Mkdir binary dirs rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nDefault Policy Changes\nAdded k8s_audit rule Pod Created To Debug Kubernetes Node.\nUpdated Policy for Network Tool Executed During NPM Install rule.\n0.221.0\nOctober 06, 2025\nRule Changes\nReduced FPs for Disable Powershell History rule.\nReduced FPs for Linux Kernel Module Injection Detected rule.\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\nReduced FPs for Launch Excessively Capable Container rule.\nReduced FPs for nsenter Container Escape rule.\nReduced FPs for PTRACE attach to process rule.\nReduced FPs for Packet socket created in container rule.\n0.220.4\nOctober 03, 2025\nRule Changes\nReduced FPs for Execution from /tmp rule.\nReduced FPs for Suspicious io_uring Activity Detected rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Dynamic Linker Hijacking Detected rule.\nFalco No-Driver List Added.\n0.220.3\nOctober 02, 2025\nRule Changes\nNew Falco List Added.\nAdding Sysdig images.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Launch Remote File Copy Tools on Host rule.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Dump Memory using /proc Filesystem rule.\n0.220.2\nOctober 01, 2025\nRule Changes\nReduced FPs for Suspicious Home Directory Creation rule.\nReduced FPs for Debugfs Launched in Privileged Container rule.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Mount Launched in Privileged Container rule.\n0.220.1\nSeptember 30, 2025\nRule Changes\nAdded obs rule Possible Exploitation of Kernel Netfilter Vulnerability (CVE-2024-53141).\nImproved condition for Suspicious System Service Modification rule.\nImproved condition for Network Tool Executed During NPM Install rule.\nReduced FPs for Write below root rule.\nReduced FPs for User Management Event Detected rule.\nReduced FPs for Password Policy Discovery Activity Detected rule.\nReduced FPs for Read sensitive file untrusted rule.\nReduced FPs for Reverse Shell Detected rule.\nReduced FPs for Offensive Security Tool Detected rule.\nReduced FPs for nsenter Container Escape rule.\nReduced FPs for DNS Tunneling Activity Detected rule.\nReduced FPs for Mount Launched in Privileged Container rule.\nReduced FPs for Cgroup Filesystem Mounted in Container rule.\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for New Kernel Module Created and Loaded rule.\nReduced FPs for Run shell untrusted rule.\nDefault Policy Changes\nPolicy Update.\nPolicy Update for Describe Instances.\nPolicy Update for Bedrock Invoke Model.\nPolicy Update for SSM Get Parameter.\nPolicy Update for Get Secret Value.\n0.220.0\nSeptember 29, 2025\nRule Changes\nReduced FPs for Suspicious Operations with Firewalls rule.\nReduced FPs for Possible Backdoor using BPF rule.\nReduced FPs for Redirect STDOUT/STDIN to Network Connection in Container rule.\nReduced FPs for Launch Sensitive Mount Container rule.\nReduced FPs for Reverse Shell Spawned From Binary Through Pipes rule.\nReduced FPs for Reverse Shell Detected rule.\n0.219.3\nSeptember 26, 2025\nRule Changes\nReduced false positives for the following rules:\nReconnaissance attempt to find SETGID binaries\nReconnaissance attempt to find SUID binaries\nSuspicious Operations with Firewalls\nPossible Backdoor using BPF\nLaunch Sensitive Mount Container\nExecution of binary using ld-linux\nExecution from /tmp\nModify Grub Configuration Files\nDump Memory using /proc Filesystem\n0.219.2\nSeptember 25, 2025\nRule Changes\nReduced false positives for the following rules:\nRun shell untrusted\nSuspicious Command Executed by Web Server\neBPF Program Loaded into Kernel\nSuspicious io_uring Activity Detected\nModify binary dirs\nDump Memory using /proc Filesystem\n0.219.1\nSeptember 23, 2025\nRule Changes\nReduced false positives for the following rules:\nReverse Shell Detected\nRead sensitive file untrusted\nReconnaissance attempt to find SETGID binaries\nReconnaissance attempt to find SUID binaries\nSuspicious Operations with Firewalls\nLaunch Sensitive Mount Container\nBPFDoor Backdoor Activity Detected\nClear Log Activities\n0.219.0\nSeptember 18, 2025\nRule Changes\nReduced false positives for the following rules:\nSet Custom Handler for Command History\nDNS Tunneling Activity Detected\nSuspicious io_uring Activity Detected\n0.218.7\nSeptember 17, 2025\nRule Changes\nReduced false positives for the following rules:\nReverse Shell Redirects STDIN/STDOUT Using UNIX Socket\nDynamic Linker Hijacking Using ld.so Files\nDynamic Linker Hijacking Detected\n0.218.6\nSeptember 16, 2025\nRule Changes\nReduced false positives for the following rules:\nDump Memory using /proc Filesystem\nReverse Shell Spawned From Binary Through Pipes\nDynamic Linker Hijacking Using ld.so Files\nDynamic Linker Hijacking Detected\n0.218.5\nSeptember 15, 2025\nRule Changes\nReduced false positives for the following rules:\nFileless Malware Detected (memfd)\nDynamic Linker Hijacking Using ld.so Files\nDynamic Linker Hijacking Detected\n0.218.4\nSeptember 11, 2025\nRule Changes\nReduced false positives for the following rules:\nRead sensitive file untrusted rule\nBase64-encoded Shell Script Execution\nDynamic Linker Hijacking Using ld.so Files\nDynamic Linker Hijacking Detected\nDump Memory using /proc Filesystem\n0.218.2\nSeptember 09, 2025\nRule Changes\nReduced false positives for the following rules:\nSymlinks created over sensitive files\nEntra Hard Delete Application\nDynamic Linker Hijacking Using ld.so Files\nRead K8s Service Account Token from Terminal\nDump Memory using /proc Filesystem\nReverse Shell Detected\n0.218.1\nSeptember 02, 2025\nRule Changes\nReduced false positives for the following rules:\nLocal Privilege Escalation Using SETGID Capability\nLocal Privilege Escalation Using SETUID Capability\nSystem Linker Corruption Detected\nPTRACE attached to process\nBPFDoor Backdoor Activity Detected\nSet Custom Handler for Command History\nReverse Shell Redirects STDIN/STDOUT Using UNIX Socket\nDynamic Linker Hijacking Using ld.so Files\nAdded rule Exfiltration of K8s Service Account Token.\nAdded rule ECS Task Run or Started with Command Override.\nImproved condition for File Created in System Directory rule.\nDefault Policy Changes\nAdded the following rules:\nExfiltration of K8s Service Account Token\nECS Task Run or Started with Command Override\n0.218.0\nAugust 28, 2025\nRule Changes\nUpdate description for Packet socket created in container rule.\nReduced false positives for the following rules:\nCreate Hardlink Over Sensitive Files\nSuspicious Home Directory Creation\nCreate Symlink Over Sensitive Files\nFileless Malware Detected (memfd)\nDynamic Linker Hijacking Using ld.so Files\nDump Memory using /proc Filesystem\n0.217.2\nAugust 27, 2025\nRule Changes\nReduced false positives for the following rules:\nOpenSSL Reverse Shell Detected\nReverse Shell Spawned From Binary Through Pipes\nEntra Add Member\nBPFDoor Backdoor Activity Detected\nDump Memory using /proc Filesystem\n0.217.1\nAugust 26, 2025\nRule Changes\nAdded the following rules:\nPossible Sudo Chroot Exploitation Attempt\nContainer Escape using PTRACE\nContainer Escape using Kernel Module\nReduced false positives for the following rules:\nRead K8s Service Account Token from Terminal\nLocal Privilege Escalation Using SETGID Capability\nFile Created in System Directory\nMalicious IPs or domains detected on command line\nDefault Policy Changes\nAdded the following rules:\nPossible Sudo Chroot Exploitation Attempt\nContainer Escape using PTRACE\nContainer Escape using Kernel Module\n0.217.0\nAugust 21, 2025\nRule Changes\nReduced false positives for the following rules:\nWindows Shell Spawned Inside Container\nFile Modified in System Directory\nPotential Application Shimming\nNetwork Relay Binary Exfiltration Activities Detected\nDynamic Linker Hijacking Detected\nBPF Command Executed by Fileless Program\ncode\u003eFileless Malware Detected (memfd)\nFind GCP Credentials\nDump Memory using /proc Filesystem\nDrop and Execute /tmp Binary\nNew Kernel Module Created and Loaded\nPTRACE anti-debug attempt\nReverse Shell Spawned From Binary Through Pipes\nSystem procs network activity\nArchive or Compression Activity Detected\nDynamic Linker Hijacking Using ld.so Files\n0.216.1\nAugust 19, 2025\nRule Changes\nImproved condition for the following rules:\nData Exfiltration using DNS\nRead K8s Service Account Token from Terminal\nReduced false positives for the following rules:\nFile Created in System Directory\nNetwork Relay Binary Exfiltration Activities Detected\nDump Memory using /proc Filesystem\nDNS Tunneling Activity Detected\nReverse Shell Detected\nDump Memory using /proc Filesystem\nCreate Symlink Over Sensitive Files\nSuspicious device created in container\nSuspicious RC Script Modification\nDynamic Linker Hijacking Using ld.so Files\nBPFDoor Backdoor Activity Detected\nSystem Linker Corruption Detected\n0.216.0\nAugust 14, 2025\nRule Changes\nReduced false positives for the following rules:\nSuspicious io_uring Activity Detected\nTerminal shell in container\nSuspicious Operations with Firewalls\neBPF Program Loaded into Kernel\nLaunch Suspicious Network Tool on Host\nSuspicious Home Directory Creation\nMount Launched in Privileged Container\nSystem procs network activity\n0.215.3\nAugust 13, 2025\nReduced false positives for the following rules:\nSystem Linker Corruption Detected\nDynamic Linker Hijacking Using ld.so Files\nDNS Fast Flux Activity Detected\nLaunch Ingress Remote File Copy Tools in Container\nSystem procs network activity\nCreate Symlink Over Sensitive Files\nDrop and Execute /tmp Binary\nRead K8s Service Account Token from Terminal\n0.215.2\nAugust 12, 2025\nRule Changes\nReduced false positives for Base64-encoded Shell Script Execution rule.\n0.215.1\nAugust 12, 2025\nRule Changes\nImproved condition for Suspicious Command Executed by Web Server rule.\nReduced false positives for the following rules:\nBase64-encoded Shell Script Execution\nData Exfiltration using DNS\nSuspicious io_uring Activity Detected\nSuspicious device created in container\nReverse Shell Detected\nDNS Lookup for Suspicious Domain Detected\nSystem Linker Corruption Detected\nDump Memory using /proc Filesystem\nRead K8s Service Account Token from Terminal\nDynamic Linker Hijacking Using ld.so Files\nReverse Shell Redirects STDIN/STDOUT Using UNIX Socket\nNew Kernel Module Created and Loaded\nBPF Command Executed by Fileless Program\nUpdated policy for Connection to IPFS Network Detected rule.\nDefault Policy Changes\nUpdated policy for Connection to IPFS Network Detected rule.\n0.215.0\nAugust 05, 2025\nRule Changes\nImproved output for Read K8s Service Account Token from Terminal rule.\nImproved condition for the following rules:\nDNS Lookup for Suspicious Domain Detected\nLocal Privilege Escalation Using SETGID Capability\nReduced false positives for the following rules:\nRead K8s Service Account Token from Terminal rule.\nSuspicious Home Directory Creation\nNew Kernel Module Created and Loaded\nDynamic Linker Hijacking Using ld.so Files\nCreate Symlink Over Sensitive Files\nDefault Policy Changes\nAdded rule System Linker Corruption Detected.\n0.214.0\nAugust 01, 2025\nRule Changes\nReduced false positives for the following rules:\nClear Log Activities\nSuspicious Access To Kerberos Secrets\nDB program spawned process\nCreate Privileged Pod\nAzure VM Activity using RunCommand\nSuspicious Operations with Firewalls\nCreate Symlink Over Sensitive Files\nBPFDoor Backdoor Activity Detected\nEncoded Powershell Execution\nBase64-encoded Shell Script Execution\nLocal Privilege Escalation Using SETUID Capability\nSensitive File Tampered Using Capabilities\n0.213.3\nJuly 30, 2025\nRule Changes\nReduced false positives for the following rules:\nMemory Manipulation by Fileless Program\nFileless Malware Detected (memfd)\n0.213.2\nJuly 30, 2025\nRule Changes\nReduced false positives for the following rules:\nDump Memory using /proc Filesystem\nRead K8s Service Account Token from Terminal\nPassword Policy Discovery Activity Detected\n0.213.1\nJuly 29, 2025\nRule Changes\nImproved condition for DNS Lookup for Canary Domain rule.\nReduced false positives for the following rules:\nBPFDoor Backdoor Activity Detected\nRun shell untrusted\nDump Memory using /proc Filesystem\nConnection with Suspicious User Agent Detected\nDefault Policy Changes\nAdded the following rules:\nSuspicious Domain Contacted During NPM Install\nRoute53 Remove Domain Transfer Lock\nBedrock Create Long-term API Keys\n0.213.0\nJuly 28, 2025\nRule Changes\nReduced false positives for the following rules:\nExecution from /tmp\nRead sensitive file untrusted\nRead K8s Service Account Token from Terminal\nBPFDoor Backdoor Activity Detected\nNew Kernel Module Created and Loaded\nDump Memory using /proc Filesystem\n0.212.10\nJuly 24, 2025\nRule Changes\nReduced false positives for the following rules:\nFileless Malware Detected (memfd)\nPTRACE anti-debug attempt\nReverse Shell Redirects STDIN/STDOUT Using UNIX Socket\nBPFDoor Backdoor Activity Detected\nRead K8s Service Account Token from Terminal\nDump Memory using /proc Filesystem\n0.212.9\nJuly 23, 2025\nRule Changes\nReduced false positives for the following rules:\nOpenSSL Reverse Shell Detected\nPerl Remote Command Execution Detected\nRun shell untrusted\nRead K8s Service Account Token from Terminal\nCreate Symlink Over Sensitive Files\n0.212.8\nJuly 21, 2025\nRule Changes\nImproved output for Entra Add Member to Administrative Role rule.\nReduced false positives for the following rules:\nBPFDoor Backdoor Activity Detected\nPossible Backdoor using BPF\nDisable or Modify Linux Audit System\nRead K8s Service Account Token from Terminal\n0.212.7\nJuly 18, 2025\nRule Changes\nAdd user.loginname exceptions to Windows rules.\nReduced false positives for the following rules:\nReverse Shell Detected\nFileless Malware Detected (memfd)\nHexadecimal string detected\nSuspicious Home Directory Creation\n0.212.6\nJuly 17, 2025\nRule Changes\nReduced false positives for the following rules:\nReverse Shell Detected\nCgroup Filesystem Mounted in Container\nPrivileged Shell Spawned Inside Container\n0.212.5\nJuly 16, 2025\nRule Changes\nAdd user-based exceptions to Windows rules.\nReduced false positives for the following rules:\nReverse Shell Detected\nReverse Shell Spawned From Binary Through Pipes\nContainer Launched In Host Network Namespace\nContainer Launched In Host PID Namespace\nRead K8s Service Account Token from Terminal\nLaunch Suspicious Network Tool on Host\nSuspicious RC Script Modification\nDump Memory using /proc Filesystem\n0.212.4\nJuly 11, 2025\nRule Changes\nReduced false positives for the following rules:\nBPFDoor Backdoor Activity Detected\nReverse Shell Detected\n0.212.3\nJuly 10, 2025\nRule Changes\nReduced false positives for the following rules:\nService Discovery Activity Detected\nJVM Attach Attempt using Unix Socket\nSuspicious io_uring Activity Detected\nRead sensitive file untrusted\nDynamic Linker Hijacking Using ld.so Files\nDump Memory using /proc Filesystem\nBPFDoor Backdoor Activity Detected\nExecution from Temporary Filesystem (tmpfs)\n0.212.2\nJuly 09, 2025\nRule Changes\nImproved condition for Create Internet-facing AWS Public Facing Load Balancer.\nReduced false positives for the following rules:\nHexadecimal string detected\nTerminal shell in container\nExecution from /tmp\nRead K8s Service Account Token from Terminal\nDNS Lookup for Proxy/VPN Domain Detected\nReverse Shell Detected\nJVM Attach Attempt using Unix Socket\nDynamic Linker Hijacking Using ld.so Files\nDump Memory using /proc Filesystem\n0.212.1\nJuly 08, 2025\nRule Changes\nImproved condition for Escape to host via command injection in process rule.\nReduced false positives for the following rules:\nRead K8s Service Account Token from Terminal\nDynamic Linker Hijacking Detected\nPassword Policy Discovery Activity Detected\nSet Setuid or Setgid bit\nBPFDoor Backdoor Activity Detected\nJVM Attach Attempt using Unix Socket\nExecution from /tmp\nClear Log Activities\nNetwork Relay Binary Exfiltration Activities Detected\nDump Memory using /proc Filesystem\nDefault Policy Changes\nUpdated policy for JVM Attach Attempt using Unix Socket rule.\n0.212.0\nJuly 04, 2025\nRule Changes\nReduced false positives for the following rules:\nClear Log Activities rules.\nSuspicious device created in container\nRun shell untrusted\nExecution from /tmp\nRead K8s Service Account Token from Terminal\nDump Memory using /proc Filesystem\n0.211.4\nJuly 03, 2025\nRule Changes\nReduced false positives for the following rules:\nContainer Launched In Host Network Namespace\nRead K8s Service Account Token from Terminal\n0.211.3\nJuly 03, 2025\nRule Changes\nReduced false positives for the following rules:\nJVM Attach Attempt using Unix Socket\nDNS Tunneling Activity Detected\nSystem procs network activity\nArchive or Compression Activity Detected\nLaunch Ingress Remote File Copy Tools in Container\nWrite below root\nWrite below etc\nRead K8s Service Account Token from Terminal\n0.211.2\nJuly 02, 2025\nRule Changes\nReduce false positives for GCP Rules.\nJVM Attach Attempt using Unix Socket\nSuspicious Access To Kerberos Secrets\nClear Log Activities\nExecution from /tmp\nDNS Tunneling Activity Detected\n0.211.1\nJuly 01, 2025\nRule Changes\nAdded the following rules:\nK8s Event Deleted.\nJVM Attach Attempt using Unix Socket.\nReduced false positives for the following rules:\nSystem procs network activity\nCreate Symlink Over Sensitive Files\nRead K8s Service Account Token from Terminal\nRead sensitive file untrusted\nNetwork Relay Binary Exfiltration Activities Detected\nSet Setuid or Setgid bit\nPassword Policy Discovery Activity Detected\nDefault Policy Changes\nAdded rule K8s Event Deleted.\nUpdated policy for JVM Attach Attempt using Unix Socket rule.\n0.211.0\nJune 30, 2025\nRule Changes\nReduced false positives for the following rules:\nSystem procs network activity\nReverse Shell Spawned From Binary Through Pipes\nFileless Malware Detected (memfd)\nBPFDoor Backdoor Activity Detected\nSet Setuid or Setgid bit\n0.210.3\nJune 27, 2025\nRule Changes\nReduced false positives for the following rules:\nReverse Shell Detected\nReverse Shell Spawned From Binary Through Pipes\nSuspicious RC Script Modification\nPacket Socket Created on Host\nClear Log Activities\nRead sensitive file untrusted\nNetwork Relay Binary Exfiltration Activities Detected\nDump Memory using /proc Filesystem\nRead K8s Service Account Token from Terminal\n0.210.2\nJune 25, 2025\nRule Changes\nReduce false positives for GCP Rules.\nReduced false positives for the following rules:\nModify binary dirs\nSensitive File Tampered Using Capabilities\n","url":"https://docs.sysdig.com/en/release-notes/falco-rules-changelog/2025-archive/"},{"id":824,"title":"Falco Changelog 2024","content":" Commit Date\nRule Notes\nVersion of the Falco Rules Installer (On-Prem)\nDecember 20, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nWrite below root\nNon sudo setuid\nModify ld.so.preload\nMount Launched in Privileged Container\nModification of pam.d detected\nCreate Privileged Pod\n0.184.2\nDecember 19, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nSuspicious Home Directory Creation\nNetcat Remote Code Execution in Container\nKernel Module Loaded by Unexpected Program\nSuspicious RC Script Modification\nLD_PRELOAD Library Injection\nFileless Malware Detected (memfd)\nDefault Policy Changes\nRemoved Untrusted Node Unsuccessfully Tried to Join the Cluster from managed policies.\nRemoved Untrusted Node Successfully Joined the Cluster from managed policies.\n0.184.1\nDecember 17, 2024\nRule Changes\nAdded the following rules:\nEntra Add Service Principal\nDNS Lookup for Canary Domain\nImproved condition for the DNS Lookup for Offensive Security Tool Domain Detected rule.\nImproved tags for the DNS Lookup for Offensive Security Tool Domain Detected rule.\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nClear Log Activities\nLinux Kernel Module Injection Detected\nKernel startup modules changed\nUnprivileged Delegation of Page Faults Handling to a Userspace Process\nSuspicious Home Directory Creation\nChange memory swap options\nDefault Policy Changes\nAdded the following rules:\nEntra Add Service Principal\nDNS Lookup for Canary Domain\n0.184.0\nDecember 16, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nLinux Kernel Module Injection Detected\nModification of pam.d detected\nFileless Malware Detected (memfd)\n0.183.3\nDecember 13, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nDump memory for credentials\nFileless Malware Detected (memfd)\nDetect release_agent File Container Escapes\nDNS Fast Flux Activity Detected\n0.183.2\nDecember 12, 2024\nRule Changes\nReduced false positives for the following rules:\nPotential IRC connection detected\nSuspicious Interaction with Container Socket\nModify ld.so.preload\nFileless Malware Detected (memfd)\nMount Launched in Privileged Container\nKernel Module Loaded by Unexpected Program\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.183.1\nDecember 10, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nAdded the following rules:\nRole/Clusterrole Bound To Kubernetes Anonymous User\nHighly Sensitive Clusterrole Bound To Kubernetes Anonymous User\nExecutable File Dropped in Container via Kubectl\nSuspicious Interaction with Container Socket\nImproved conditions for the following rules:\nOpenSSL Reverse Shell Detected\nAbuse Sudo for Privilege Escalation\nReduced false positives for the following rules:\nNon sudo setuid\nLaunch Privileged Container\nSet Setuid or Setgid bit\nModify ld.so.preload\nMount Launched in Privileged Container\nKernel startup modules changed\nDNS Lookup for Uncommon TLD Domain Detected\nDNS Fast Flux Activity Detected\nPTRACE anti-debug attempt\nDefault Policy Changes\nAdded the following rules:\nExecutable File Dropped in Container via Kubectl\nSuspicious Interaction with Container Socket\nRole/Clusterrole Bound To Kubernetes Anonymous User\nHighly Sensitive Clusterrole Bound To Kubernetes Anonymous User\n0.183.0\nDecember 05, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nOpenSSL Reverse Shell Detected\nKernel Module Loaded by Unexpected Program\nModify Grub Configuration Files\neBPF Program Loaded into Kernel\nImproved output for SSM Start Session.\n0.182.1\nDecember 03, 2024\nRule Changes\nAdded the following rules:\neBPF Program Loaded From Unexpected Location.\nSocat Reverse Shell Detected.\nModification of Container Image Cache.\nKnown Malicious eBPF Program Detected.\nOpenSSL Reverse Shell Detected.\nPossible Remote Command Execution Detected.\nUpdated policy for the following rules:\neBPF Program Loaded into Kernel\nProcess memory injection via process_vm_writev\nCreate Unencrypted EFS.\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nReverse Shell Detected\nFileless Malware Detected (memfd)\nDump memory for credentials\nFind GCP Credentials\nPTRACE anti-debug attempt\nSet Setuid or Setgid bit\nDefault Policy Changes\nUpdated policy for the following rules:\neBPF Program Loaded into Kernel\nProcess memory injection via process_vm_writev\nCreate Unencrypted EFS.\nAdded the following rules:\neBPF Program Loaded From Unexpected Location.\nSocat Reverse Shell Detected.\nModification of Container Image Cache.\nKnown Malicious eBPF Program Detected.\nOpenSSL Reverse Shell Detected.\nPossible Remote Command Execution Detected.\n0.182.0\nNovember 29, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nPTRACE anti-debug attempt\nGPG Key Reconnaissance\nImproved output for DNS rules.\nRemoved the following rules from managed policies:\nUnexpected K8s NodePort Connection\nGCP Super Admin Executing Command\nNetwork Connection outside Local Subnet from managed policies.\nReduced false positives for the following rules:\nFileless Malware Detected (memfd)\neBPF Program Loaded into Kernel\nDefault Policy Changes\nRemoved the following rules from managed policies:\nUnexpected K8s NodePort Connection\nGCP Super Admin Executing Command\nNetwork Connection outside Local Subnet\n0.181.1\nNovember 26, 2024\nRule Changes\nReduced false positives for Password Policy Discovery Activity Detected rule.\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nAdded the following rules:\nAzure VM Activity using RunCommand\nPersistence Across GitHub Runner Executions Detected\nAKS RunCommand Container Launched\nPerl Remote Command Execution Detected\nUpdated descriptions for:\nConnection to Instance Metadata through AWS SSM\nAKS RunCommand Container Launched\nUpdated policy for the following rules:\nDNS Lookup for Offensive Security Tool Domain Detected\nDNS Lookup for Remote Access Domain Detected\nAdded rule Connection to Instance Metadata through AWS SSM.\nImproved condition for Suspicious Access To Kerberos Secrets rule.\nDefault Policy Changes\nAdded the following rules:\nAzure VM Activity using RunCommand\nPersistence Across GitHub Runner Executions Detected\nAKS RunCommand Container Launched\nPerl Remote Command Execution Detected\nUpdated policies for the following rules:\nDNS Lookup for Offensive Security Tool Domain Detected\nDNS Lookup for Remote Access Domain Detected\n0.181.0\nNovember 25, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nCreate Symlink Over Sensitive Files\neBPF Program Loaded into Kernel\n0.180.4\nNovember 22, 2024\nRule Changes\nReduced false positives for the following rules:\nWrite below root\nCreate files below dev\nModify ld.so.preload\nKernel startup modules changed\nDNS Lookup for Tunneling Service Domain Detected\nDNS Fast Flux Activity Detected\nDNS Lookup for Remote Access Domain Detected\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.180.3\nNovember 21, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nWrite below root\nMount Launched in Privileged Container\nMount on Container Path Detected\neBPF Program Loaded into Kernel\nFileless Malware Detected (memfd)\n0.180.2\nNovember 20, 2024\nRule Changes\nUpdated policies for the following rules:\nDNS Lookup for Reconnaissance Service Detected\nDNS Lookup for Suspicious Domain Detected\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following:\nRansomware Filenames Detected\nNon sudo setuid\nDNS Lookup for Uncommon TLD Domain Detected\nModification of pam.d detected\nDNS Lookup for Reconnaissance Service Detected\nDNS Lookup for Suspicious Domain Detected\nDefault Policy Changes\nUpdated policies for the following rules:\nDNS Lookup for Reconnaissance Service Detected\nDNS Lookup for Suspicious Domain Detected\n0.180.1\nNovember 19, 2024\nRule Changes\nAdded the following rules:\nAzure Network Watcher Deleted\nAzure Firewall Policy Rule Collection Group Deleted\nAzure Firewall Policy Deleted\nAzure WAF Policy Deleted\nKernel or Physical Memory Dumped\nAzure Network Watcher Flow Log Deleted\nAzure Automation Watcher Job Action Created\nAzure Automation Runbook Scheduled\nAzure Firewall Deleted\nAzure Network Packet Capture Created\nAzure Automation Runbook Deleted\nAzure Automation Webhook URI Created\nAzure Automation Runbook Published\nEntra Add Service Principal Credentials\nAzure Execute RunCommand on Kubernetes Cluster\nAzure DDoS Protection Deleted\nAzure Event Hub Resource Deleted\nRun Command in VM Instances via Virtual Machine Scale Set\nConnect to VM via Serial Console\nImproved condition for DNS Lookup for Uncommon TLD Domain Detected rule.\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following:\nClear Log Activities\nNon sudo setuid\nCreate Privileged Pod\nModify ld.so.preload\nDNS Lookup for Uncommon TLD Domain Detected\nSuspicious RC Script Modification\neBPF Program Loaded into Kernel\nDefault Policy Changes\nAdded the following rules:\nAzure Network Watcher Deleted\nAzure Firewall Policy Rule Collection Group Deleted\nAzure Firewall Policy Deleted\nAzure WAF Policy Deleted\nKernel or Physical Memory Dumped\nAzure Network Watcher Flow Log Deleted\nAzure Automation Watcher Job Action Created\nAzure Automation Runbook Scheduled\nAzure Firewall Deleted\nAzure Network Packet Capture Created\nAzure Automation Runbook Deleted\nAzure Automation Webhook URI Created\nAzure Automation Runbook Published\nEntra Add Service Principal Credentials\nAzure Execute RunCommand on Kubernetes Cluster\nAzure DDoS Protection Deleted\nAzure Event Hub Resource Deleted\nRun Command in VM Instances via Virtual Machine Scale Set\nConnect to VM via Serial Console\n0.180.0\nNovember 19, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following:\neBPF Program Loaded into Kernel\nModification of pam.d detected\nSuspicious RC Script Modification\nDownload and launch remote file copy tools in container\n0.179.3\nNovember 15, 2024\nDefault Policy Changes\nUpdated policy for rule Launch Suspicious Network Tool.\n0.179.2\nNovember 14, 2024\nDefault Policy Changes\nRemoved rule Run Several XLarge EC2 Instances.\n0.179.1\nNovember 12, 2024\nRule Changes\nReduced false positives for the following:\nFileless Malware Detected (memfd)\neBPF Program Loaded into Kernel\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.179 Cloud Rules.\nImproved condition for Backdoored library loaded into SSHD (CVE-2024-3094) rule.\nAdded the following rules:\nDNS Lookup for Tunneling Service Domain Detected\nRun PowerShell Script in a VM via Desired State Configuration Extension\nRun PowerShell Script in a VM via Custom Script Extension\nAzure Delete Diagnostic Settings for Subscription\nEntra Add External User as Member\nEntra Add External User\nEntra Remove Service Principal\nDNS Lookup for Offensive Security Tool Domain Detected\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nDefault Policy Changes\n0.179 Cloud Rules.\nAdded rule DNS Lookup for Tunneling Service Domain Detected.\nUpdated policy for Azure rules.\nAdded the following rules:\nRun PowerShell Script in a VM via Desired State Configuration Extension\nRun PowerShell Script in a VM via Custom Script Extension\nAzure Delete Diagnostic Settings for Subscription\nEntra Add External User as Member\nEntra Add External User\nEntra Remove Service Principal\nDNS Lookup for Offensive Security Tool Domain Detected\n0.179.0\nNovember 11, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following:\nSuspicious RC Script Modification\nKernel startup modules changed\nContainer escape via discretionary access control\n0.178.5\nNovember 08, 2024\nRule Changes\nReduced false positives for the following:\nCreate Symlink Over Sensitive Files\neBPF Program Loaded into Kernel\nFile Created in System Directory\nKernel Module Loaded by Unexpected Program\nLaunch Package Management Process in Container\nFileless Malware Detected (memfd)\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.178.4\nNovember 07, 2024\nRule Changes\nReduced false positives for the following:\nDelete or rename shell history\nSet Setuid or Setgid bit\nWrite below root\nDNS Lookup for Uncommon TLD Domain Detected\neBPF Program Loaded into Kernel\nMount Launched in Privileged Container\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.178.3\nNovember 06, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following:\neBPF Program Loaded into Kernel\nDelete or rename shell history\nProgram run with disallowed http proxy env\nCreate Symlink Over Sensitive Files\n0.178.2\nNovember 05, 2024\nRule Changes\nImproved description for DNS Lookup for Remote Access Domain Detected rule.\nReduced false positives for the following rules:\nDelete or rename shell history\nProgram run with disallowed http proxy env\n0.178.1\nNovember 05, 2024\nRule Changes\nAdded the following rules:\nRun Several XLarge EC2 Instances\nSet 1-day Retention Policy on Bucket\nUpdate Lambda Function Layers\nAzure VM Reset Local Administrator Password\nDNS Lookup for Remote Access Domain Detected\nImproved conditions the following rules:\nProgram run with disallowed http proxy env\nDelete or rename shell history\nLD_PRELOAD Library Injection\nImproved the following lists:\nsensitive_file_names\ncode_compilers\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following:\nPotential IRC connection detected\nConnection with Suspicious User Agent Detected\nDefault Policy Changes\nAdded the following rules:\nDNS Lookup for Remote Access Domain Detected\nRun Several XLarge EC2 Instances\nSet 1-day Retention Policy on Bucket\nUpdate Lambda Function Layers\nAzure VM Reset Local Administrator Password\nImproved condition for Program run with disallowed http proxy env rule.\nUpdated policy for Update Lambda Function Code rule.\n0.178.0\nNovember 04, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following:\nChange thread namespace\nLD_PRELOAD Library Injection\nDNS Lookup for Uncommon TLD Domain Detected\nChange memory swap options\nSuspicious RC Script Modification\n0.177.3\nOctober 31, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following:\nModification of pam.d detected\nSuspicious RC Script Modification\nHexadecimal string detected\nLD_PRELOAD Library Injection\n0.177.2\nOctober 29, 2024\nRule Changes\nReduced false positives for LD_PRELOAD Library Injection rule.\n0.177.1\nOctober 29, 2024\nRule Changes\nImproved condition for DNS Lookup for Uncommon TLD Domain Detected rule.\nImproved the suspicious_domains_contains macro.\nAdded the following rules:\nLD_PRELOAD Library Injection\nEKS Pod Attach Policy to User\nEKS Pod Create Access Key for User\nEKS Pod Create User\nEKS Pod Attach Policy to User\nEKS Pod Create Access Key for User\nEKS Pod Create User\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following:\nDownload and launch remote file copy tools in container\neBPF Program Loaded into Kernel\nproc_exepath_exists macro\nDefault Policy Changes\nUpdated policy for the Clear Windows Event Log rule.\nAdded the following rules:\nLD_PRELOAD Library Injection\nEKS Pod Attach Policy to User\nEKS Pod Create Access Key for User\nEKS Pod Create User\nEKS Pod Attach Policy to User\nEKS Pod Create Access Key for User\nEKS Pod Create User\n0.177.0\nOctober 28, 2024\nRule Changes\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nDNS Lookup for C2 Domain Detected\nModify ld.so.preload\nHexadecimal string detected\nFileless Malware Detected (memfd)\nDump memory for credentials\nChange thread namespace\nLaunch Remote File Copy Tools in Container\n0.176.3\nOctober 25, 2024\nRule Changes\nReduced false positives for the following rules:\nDump memory for credentials\nMount Launched in Privileged Container\neBPF Program Loaded into Kernel\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.176.2\nOctober 24, 2024\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nDNS Lookup for Suspicious Domain Detected\nReverse Shell Detected\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.176.1\nOctober 22, 2024\nRule Changes\nImproved condition for Hexadecimal string detected rule.\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nClear Windows Event Log\neBPF Program Loaded into Kernel\nDNS Lookup for Uncommon TLD Domain Detected\nChange memory swap options\nFind GCP Credentials\nUpdated policy for the DNS Rogue Server Detected rule.\nImproved condition for the DNS Lookup for Suspicious Domain Detected rule.\nDefault Policy Changes\nUpdated policy for the DNS Rogue Server Detected rule.\n0.176.0\nOctober 21, 2024\nRule Changes\nReduced false positives for the following rules:\nClear Log Activities\nPTRACE attached to process\nContact Azure Instance Metadata Service from Host\nModification of pam.d detected\nFind GCP Credentials\nImproved output for Change memory swap options rule.\nImproved tags for Kill known malicious process rule.\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.175.4\nOctober 18, 2024\nRule Changes\nReduced false positives for the following rules:\nFileless Malware Detected (memfd)\nExecution from /tmp\nModification of pam.d detected\nTerminal shell in container\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.175.3\nOctober 17, 2024\nRule Changes\nReduced false positives for the following rules:\nKernel startup modules changed\nChange thread namespace\nnsenter Container Escape\nSuspicious RC Script Modification\nReverse Shell Detected\neBPF Program Loaded into Kernel\nCreate Symlink Over Sensitive Files\nModification of pam.d detected\nDNS Lookup for Uncommon TLD Domain Detected\nDNS Fast Flux Activity Detected\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.175.2\nOctober 16, 2024\nRule Changes\nReduced false positives for the eBPF Program Loaded into Kernel rule.\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nImproved output for Attach Full Access or Administrative Policy.\n0.175.1\nOctober 15, 2024\nRule Changes\nImproved condition for Clear Windows Event Log rule.\nImproved the output for Create IAM Policy that Allows All.\nAdded the Attach Full Access or Administrative Policy rule.\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\nReduced false positives for the following rules:\nWrite below etc\nRansomware Filenames Detected\nExecution from /tmp\nPTRACE anti-debug attempt\nModification of pam.d detected\nDump memory for credentials\nFind GCP Credentials\nSuspicious RC Script Modification\nModify ld.so.preload\nFind AWS Credentials\nDefault Policy Changes\nAdded the Attach Full Access or Administrative Policy rule .\n0.175.0\nOctober 10, 2024\nRule Changes\nReduced false positives for the following rules:\nDNS Lookup for Reconnaissance Service Detected\neBPF Program Loaded into Kernel\nPotential IRC connection detected\nPTRACE attached to process\nDNS Fast Flux Activity Detected\nInteractive Reconnaissance Activity Detected\nReverse Shell Detected\nDNS Lookup for C2 Domain Detected\nImproved output for Workload rules.\nUpdated Indicators of Compromise (IoCs) rulesets with new findings.\n0.174.2\nOctober 09, 2024\nRule Changes\nImproved output for GCP Create Route rule.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nReduced false positives for the following rules:\nModification of pam.d detected\nGPG Key Reconnaissance\nDNS Fast Flux Activity Detected\nReduced false positives for OpenShift - Workload.\n0.174.1\nOctober 08, 2024\nRule Changes\nAdded the following rules:\nACore Pattern Container Escape\nBatch Get Secret Value with Catch-All Filter\nBatch Get Secret Value\nUpdated policy for Interactive Reconnaissance Activity Detected rule Improved condition for the following rules:\nDelete or rename shell history\nJunk Data Padding Detected\nEscape to host via command injection in process\nImproved output for Outbound Connection to C2 Servers rule Reduced false positives for the following rules:\nModification of pam.d detected\nKernel startup modules changed\nSuspicious RC Script Modification\nFind GCP Credentials\nChange thread namespace\nDump memory for credentials\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nDefault Policy Changes\nAdded the following rules:\nCore Pattern Container Escape\nBatch Get Secret Value with Catch-All Filter\nBatch Get Secret Value\nUpdated policies for the following rules:\nInteractive Reconnaissance Activity Detected\nPassword Policy Discovery Detected\nCloudWatch Delete Alarms\nCodeBuild Start Build\nEC2 Get User Data\nDelete VPC Flow Log\n0.174.0\nOctober 04, 2024\nRule Changes\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nReduced false positives for Suspicious RC Script Modification rule.\n0.173.1\nOctober 03, 2024\nRule Changes\nAdded the following rules\nConnection to Instance Metadata through AWS SSM Suspicious Command Executed through AWS SSM Reduced false positives for Modify ld.so.preload rule Updated Indicators of Compromise (IoC) rulesets with new findings.\nDefault Policy Changes\nAdded the following rules\nConnection to Instance Metadata through AWS SSM Suspicious Command Executed through AWS SSM 0.173.0\nOctober 02, 2024\nRule Changes\nReduced false positives for the following rules:\nDump memory for credentials\nCreate Symlink Over Sensitive Files\nSuspicious RC Script Modification\nInteractive Reconnaissance Activity Detected\nClear Log Activities\nKernel Module Loaded by Unexpected Program\nPTRACE anti-debug attempt\nSuspicious Access To Kerberos Secrets\nStandardise all AWS rules output Updated Indicators of Compromise (IoC) rulesets with new findings.\n0.172.1\nOctober 01, 2024\nRule Changes\nAdded the following rules\nDNS Fast Flux Activity Detected AWS SSM Agent Activity using StartSession AWS SSM Agent Activity Using SendCommand RunShellScript or RunPowerShellScript DNS Rogue Server Detected Improved condition for the following rules:\nPossible SSH Hijacking Attempt Detected\nActive Directory Connection Detected\nShared Libraries Reconnaissance Activity Detected\nReduced false positives for the following rules:\nEscape to host via command injection in process\nModification of pam.d detected\nPossible Backdoor using BPF\nSuspicious RC Script Modification\nUpdated policy for Possible Backdoor using BPF and Shell Spawned with Inline Python Command rules Improved output for GCP Sensitive Role Added to User rule Updated Indicators of Compromise rulesets with new findings Default Policy Changes\nAdded the following rules\nDNS Fast Flux Activity Detected AWS SSM Agent Activity using StartSession AWS SSM Agent Activity Using SendCommand RunShellScript or RunPowerShellScript DNS Rogue Server Detected Updated policy for Possible Backdoor using BPF and Shell Spawned with Inline Python Command rules 0.172.0\nSeptember 30, 2024\nRule Changes\nReduced false positives for the following rules:\nMalicious filenames written rule Possible Backdoor using BPF rule Find GCP Credentials rule eBPF Program Loaded into Kernel rule Reverse Shell Detected rule Reduced false positives for OpenShift Workload.\nImproved tags for the following rules:\nSuspicious cups-browsed process listening on UDP Possible Arbitrary Command Execution through CUPS Improved tags for Workload rules.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nImproved output for Suspicious RC Script Modification rule.\nDefault Policy Changes\nAdded On-Premises policies for the following rules:\nSuspicious cups-browsed process listening on UDP Possible Arbitrary Command Execution through CUPS 0.171.1\nSeptember 29, 2024\nRule Changes\nAdded the following rules:\nSuspicious cups-browsed process listening on UDP Possible Arbitrary Command Execution through CUPS Default Policy Changes\nAdded the following rules:\nSuspicious cups-browsed process listening on UDP Possible Arbitrary Command Execution through CUPS 0.171.0\nSeptember 26, 2024\nRule Changes\nUpdated Indicators of Compromise rulesets with new findings 0.170.3\nSeptember 25, 2024\nRule Changes\nReduced false positives for the following rules:\nJunk Data Padding Detected\neBPF Program Loaded into Kernel\nModify ld.so.preload\nChange memory swap options\nDefault Policy Changes\nReduced false positives for Junk Data Padding Detected rule.\n0.170.1\nSeptember 24, 2024\nWhat's Changed\nRule Changes\nAdded the following rules:\nShell Spawned with Inline Python Command\nSystem Capabilities Configuration Updated\nEC2 Instance Attach Policy to User\nEC2 Instance Create Access Key for User\nAttach Administrator Policy to Role\nAttach Administrator Policy to Group\nGet Account Authorization Details\nImproved conditions the following rules:\nSuspicious Kernel Parameter Modification\nModify Timestamp attribute in File\nModification of pam.d detected\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nReduced false positives for the following rules:\nCreate Hardlink Over Sensitive Files\nSuspicious Process Loading Vault DLL\nMount Launched in Privileged Container\neBPF Program Loaded into Kernel\nJunk Data Padding Detected\nRead sensitive file untrusted\nAdded exceptions to GCP rules.\nDefault Policy Changes\nAdded the following rules:\nShell Spawned with Inline Python Command\nSystem Capabilities Configuration Updated\nEC2 Instance Attach Policy to User\nEC2 Instance Create Access Key for User\nAttach Administrator Policy to Role\nAttach Administrator Policy to Group\nGet Account Authorization Details\nUpdated policy for DNS Lookup for Reconnaissance Service Detected rule.\nUpdated policy for Junk Data Padding Detected rule.\n0.170.0\nSeptember 20, 2024\nRule Changes\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nReduced false positives for the following rules:\nTampering with Security Software on Host\nSuspicious Domain Contacted\nPossible Backdoor using BPF\nCreate Hardlink Over Sensitive Files\nReverse Shell Detected\n0.169.5\nSeptember 19, 2024\nRule Changes\nUpdated Indicators of Compromise rulesets with new findings Reduced false positives for the following rules:\nSuspicious RC Script Modification\nJunk Data Padding Detected\nPossible Backdoor using BPF\nDNS Lookup for Suspicious Domain Detected\nKernel startup modules changed\nPTRACE anti-debug attempt\nDNS Lookup for Dynamic DNS Domain Detected\nSuspicious Domain Contacted\nImproved output for Tampering with Security Software on Host rule Improved description for DNS Tunneling Activity Detected rule Default Policy Changes\nUpdated policy for the following rules:\nDNS Tunneling Activity Detected\nReverse Shell Detected\n0.169.4\nSeptember 18, 2024\nRule Changes\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nReduced false positives for the following rules:\nKernel startup modules changed\nDelete or rename shell history\nReverse Shell Detected\nDNS Lookup for Dynamic DNS Domain Detected\nJunk Data Padding Detected\nSuspicious RC Script Modification\nLaunch Ingress Remote File Copy Tools in Container\nRead ssh information\nImproved tags for DNS Lookup for Suspicious Domain Detected rule.\n0.169.2\nSeptember 18, 2024\nRule Changes\nReduced false positives for the following rules:\nReverse Shell Detected\nDNS Lookup for Reconnaissance Service Detected\nDNS Lookup for Dynamic DNS Domain Detected\n0.169.1\nSeptember 17, 2024\nRule Changes\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nAdded the following rules:\nReverse Shell Detected\nDNS Lookup for Reconnaissance Service Detected\nDNS Lookup for Dynamic DNS Domain Detected\nDNS Tunneling Activity Detected\nJunk Data Padding Detected\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nWrite below root\nPossible Backdoor using BPF\nKernel Module Loaded by Unexpected Program\nDefault Policy Changes\nAdded the following rules:\nDNS Lookup for Reconnaissance Service Detected\nDNS Lookup for Dynamic DNS Domain Detected\nDNS Tunneling Activity Detected\nJunk Data Padding Detected\nReverse Shell Detected\nUpdated policy for Connection with Suspicious User Agent Detected rule.\n0.169.0\nSeptember 16, 2024\nRule Changes\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nImproved tags for the Kubernetes rules Reduced false positives for the following rules:\nWrite below root\nDump memory for credentials\nDNS Lookup for Uncommon TLD Domain Detected\nDNS Lookup for Suspicious Domain Detected\n0.168.4\nSeptember 13, 2024\nRule Changes\nReduced false positives for the following rules:\nSuspicious RC Script Modification\neBPF Program Loaded into Kernel\nModify ld.so.preload\nEscape to host via command injection in process\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.168.3\nSeptember 12, 2024\nRule Changes\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nReduced false positives for the following rules:\nDump memory for credentials\nDNS Lookup for Uncommon TLD Domain Detected\nLinux Kernel Module Injection Detected\n0.168.2\nSeptember 11, 2024\nRule Changes\nReduced false positives for the following rules:\nPossible Backdoor using BPF\nPotential IRC connection detected\nDump memory for credentials\nRedirect STDOUT/STDIN to Network Connection in Host\nModification of Udev Rules Detected\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.168.1\nSeptember 10, 2024\nRule Changes\nAdded the Modification of Udev Rules Detected rule\nImproved conditions for the following rules:\nConnection with Suspicious User Agent Detected\nDump memory for credentials\nAdded eventSource to AWS rules - part 3 Improved tags for GitHub rules Improved MITRE tags - subtechniques Updated Indicators of Compromise (IoC) rulesets with new findings.\nReduced false positives for the following rules:\nFileless Malware Detected DNS Lookup for Uncommon TLD Domain Detected\nModification of pam.d detected\nMount Launched in Privileged Container\nDump memory for credentials\neBPF Program Loaded into Kernel\nDefault Policy Changes\nAdded theModification of Udev Rules Detected rule Updated policy for DNS Lookup for IPFS Domain Detected rule.\n0.168.0\nSeptember 09, 2024\nRule Changes\nUpdated Indicators of Compromise rulesets with new findings Reduced false positives for the following rules:\neBPF Program Loaded into Kernel rule DNS Lookup for Uncommon TLD Domain Detected rule Kernel startup modules changed rule Dump memory for credentials rule Improved output for Outbound rules 0.167.4\nSeptember 06, 2024\nRule Changes\nFixed DNS exceptions Default Policy Changes\nUpdated policy for the Tampering with Security Software on Host rule 0.167.3\nSeptember 05, 2024\nRule Changes\nReduced false positives for the following rules:\nNon sudo setuid rule Suspicious Capabilities Granted to File rule Possible Backdoor using BPF rule Suspicious RC Script Modification rule Escape to host via command injection in process rule Updated Indicators of Compromise rulesets with new findings 0.167.2\nSeptember 03, 2024\nRule Changes\nAdded the following rules:\nProcess memory injection via process_vm_writev DNS Lookup for Uncommon TLD Domain Detected Cgroup Filesystem Mounted in Container Added eventSource to AWS rules\nUpdated Indicators of Compromise rulesets with new findings Standardized output across Workload rules Reduced false positives for the following rules:\nKernel startup modules changed\nModification of pam.d detected\nLaunch Ingress Remote File Copy Tools in Container\nSuspicious Process Loading Vault DLL\nDefault Policy Changes\nAdded the following rules:\nProcess memory injection via process_vm_writev DNS Lookup for Uncommon TLD Domain Detected Cgroup Filesystem Mounted in Container Updated the policies for the following rules:\nDNS Lookup for C2 Domain Detected\nDNS Lookup for Miner Pool Domain Detected\nIngress NGINX Annotation Validation Potential Bypass 0.167.0\nAugust 30, 2024\nRule Changes\nUpdated Indicators of Compromise rulesets with new findings Reduced false positives for the following rules:\nDNS Lookup for Proxy/VPN Domain Detected\neBPF Program Loaded into Kernel\nDownload and launch remote file copy tools in container\nKernel startup modules changed\nPTRACE anti-debug attempt\nDNS Lookup for Miner Pool Domain Detected\nDNS Lookup for C2 Domain Detected\nDNS Lookup for Suspicious Domain Detected\nDNS Lookup for IPFS Domain Detected\n0.166.5\nAugust 29, 2024\nRule Changes\nUpdated Indicators of Compromise rulesets with new findings Reduced false positives for the following rules:\nFileless Malware Detected eBPF Program Loaded into Kernel\nSuspicious Process Loading Vault DLL\nNon sudo setuid\nModification of pam.d detected\nKernel Module Loaded by Unexpected Program\nPTRACE anti-debug attempt\nMount on Container Path Detected\n0.166.4\nAugust 29, 2024\nRule Changes\nReduced false positives for Non sudo setuid rule.\n0.166.3\nAugust 28, 2024\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nNon sudo setuid\n0.166.2\nAugust 28, 2024\nRule Changes\nUpdated Indicators of Compromise rulesets with new findings Reduced false positives for the following rules:\nNon sudo setuid\nWrite below root\nMount Launched in Privileged Container\n0.166.1\nAugust 27, 2024\nRule Changes\nAdded the following rules:\nDNS Lookup for C2 Domain Detected DNS Lookup for Miner Pool Domain Detected Ingress NGINX Annotation Validation Potential Bypass Reduced false positives for the following rules:\nibm_trusted_images macro Mount Launched in Privileged Container\nModification of pam.d detected\nDump memory for credentials\nModify ld.so.preload\nDNS Lookup for IPFS Domain Detected\nLaunch Suspicious Network Tool in Container\nLaunch Ingress Remote File Copy Tools in Container\nCreate Symlink Over Sensitive Files\nImproved condition for Data Split Activity Detected\nAdded eventSource to AWS rules\nUpdated the tags for the following:\nDNS Lookup for IPFS Domain Detected\nPossible SSH Hijacking Attempt Detected\nImproved output for the following:\nDNS Lookup for IPFS Domain Detected\nK8s Ingress Created/Modified\nUpdated Indicators of Compromise rulesets with new findings Default Policy Changes\nUpdated the following policies:\nDNS Lookup for Proxy/VPN Domain Detected\nDNS Lookup for Suspicious Domain Detected\nAdded the following rules:\nDNS Lookup for C2 Domain Detected DNS Lookup for Miner Pool Domain Detected Ingress NGINX Annotation Validation Potential Bypass 0.166.0\nAugust 26, 2024\nRule Changes\nReduced false positives for the following rules:\nFind Authentication Certificates\neBPF Program Loaded into Kernel\nPossible Backdoor using BPF\nHide Process with Mount\nSuspicious RC Script Modification\nDump memory for credentials\nModification of pam.d detected\nExecutable Created in Startup Location\nKernel startup modules changed\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.165.1\nAugust 20, 2024\nRule Changes\nAdded the following rules:\nDNS Lookup for Suspicious Domain Detected DNS Lookup for IPFS Domain Detected DNS Lookup for Proxy/VPN Domain Detected Updated Indicators of Compromise rulesets with new findings Reduced false positives for the following rules:\nEncoded Powershell Execution\nClear Windows Event Log\nFileless Malware Detected Reconnaissance attempt to find SUID binaries\nSuspicious RC Script Modification\nPTRACE anti-debug attempt\nPolicy Changes\nAdded the following rules:\nDNS Lookup for Suspicious Domain Detected DNS Lookup for IPFS Domain Detected DNS Lookup for Proxy/VPN Domain Detected 0.165.0\nAugust 13, 2024\nRule Changes\nReduced false positives for the following rules:\nLaunch Sensitive Mount Container\nLaunch Package Management Process in Container\nCreate Symlink Over Sensitive Files\nLaunch Suspicious Network Tool in Container\nMount Launched in Privileged Container\nLaunch Root User Container\nUpdated Indicators of Compromise rulesets with new findings Improved condition for Dump memory for credentials rule Added the following rules:\nGuardDuty High Severity Finding on Container\nGuardDuty High Severity Finding on EC2\nGuardDuty High Severity Finding on ECS\nGuardDuty High Severity Finding on EKS\nGuardDuty High Severity Finding on IAM\nGuardDuty High Severity Finding on Lambda\nGuardDuty High Severity Finding on RDS\nGuardDuty High Severity Finding on S3\nGuardDuty Medium Severity Finding on Container\nGuardDuty Medium Severity Finding on EC2\nGuardDuty Medium Severity Finding on ECS\nGuardDuty Medium Severity Finding on EKS\nGuardDuty Medium Severity Finding on IAM\nGuardDuty Medium Severity Finding on Lambda\nGuardDuty Medium Severity Finding on RDS\nGuardDuty Medium Severity Finding on S3\nGuardDuty Low Severity Finding on Container\nGuardDuty Low Severity Finding on EC2\nGuardDuty Low Severity Finding on ECS\nGuardDuty Low Severity Finding on EKS\nGuardDuty Low Severity Finding on IAM\nGuardDuty Low Severity Finding on Lambda\nGuardDuty Low Severity Finding on RDS\nGuardDuty Low Severity Finding on S3\nPolicy Changes\nAdded the following policies:\nSysdig AWS GuardDuty Threat Intelligence\nSysdig AWS GuardDuty Threat Detection\nSysdig AWS GuardDuty Notable Events\nSysdig AWS GuardDuty Activity Logs\nAdded the following rules:\nGuardDuty High Severity Finding on Container\nGuardDuty High Severity Finding on EC2\nGuardDuty High Severity Finding on ECS\nGuardDuty High Severity Finding on EKS\nGuardDuty High Severity Finding on IAM\nGuardDuty High Severity Finding on Lambda\nGuardDuty High Severity Finding on RDS\nGuardDuty High Severity Finding on S3\nGuardDuty Medium Severity Finding on Container\nGuardDuty Medium Severity Finding on EC2\nGuardDuty Medium Severity Finding on ECS\nGuardDuty Medium Severity Finding on EKS\nGuardDuty Medium Severity Finding on IAM\nGuardDuty Medium Severity Finding on Lambda\nGuardDuty Medium Severity Finding on RDS\nGuardDuty Medium Severity Finding on S3\nGuardDuty Low Severity Finding on Container\nGuardDuty Low Severity Finding on EC2\nGuardDuty Low Severity Finding on ECS\nGuardDuty Low Severity Finding on EKS\nGuardDuty Low Severity Finding on IAM\nGuardDuty Low Severity Finding on Lambda\nGuardDuty Low Severity Finding on RDS\nGuardDuty Low Severity Finding on S3\n0.164.0\nAugust 06, 2024\nRule Changes\nUpdated Indicators of Compromise rulesets with new findings Reduced false positives for the following rules:\nWrite below rpm database\nMalicious IPs or domains detected on command line\nRead sensitive file untrusted\nKernel startup modules changed\nAdded the following rules:\nAttach AWSCompromisedKeyQuarantineV2 Policy to User Personal Access Token Request Approved Default Policy Changes\nAdded the following rules:\nAttach AWSCompromisedKeyQuarantineV2 Policy to User Personal Access Token Request Approved 0.163.0\nAugust 05, 2024\nRule Changes\nUpdated Indicators of Compromise rulesets with new findings Reduced false positives for the following rules:\nMount on Container Path Detected\nDownload and launch remote file copy tools in container\nChange thread namespace\n0.162.4\nAugust 02, 2024\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nDump Cached Domain Credentials\nKernel Module Loaded by Unexpected Program\nsysdig_commercial_images\nReduced false positives for sysdig_images_endswith macro.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.162.3\nAugust 01, 2024\nRule Changes\nReduced false positives for the following rules:\nPossible Backdoor using BPF\nRun shell untrusted\nKernel Module Loaded by Unexpected Program\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.162.2\nJuly 31, 2024\nRule Changes\nReduced false positives for the following rules:\nWrite below etc\nWrite below root\nModify Snapshot Attribute\nDescribe Instances\nCreate Snapshot\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.162.1\nJuly 30, 2024\nRule Changes\nAdded the following rules:\nShare EBS Snapshot With Foreign Account Start EC2 Instances EC2 Modify Instance Attribute Share AMI With Foreign Account Added macro busybox_network_tools.\nImproved condition for EC2 Add User Data rule.\nImproved priority tags - Sysdig Runtime Notable Events.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nDefault Policy Changes\nAdded the following rules:\nShare EBS Snapshot With Foreign Account Start EC2 Instances EC2 Modify Instance Attribute Share AMI With Foreign Account 0.162.0\nJuly 29, 2024\nRule Changes\nReduced false positives for the following rules:\nSuspicious Access To Kerberos Secrets\neBPF Program Loaded into Kernel\nNon sudo setuid\nMount Launched in Privileged Container\nShare RDS Snapshot with Foreign Account\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.161.5\nJuly 26, 2024\nRule Changes\nReduced false positives for the following rules:\nWrite below etc\neBPF Program Loaded into Kernel\nKernel Module Loaded by Unexpected Program\nContact GCP Instance Metadata Service from Host\nazure_trusted_images_launch_root_list\nImproved output for Create AWS user rule.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.161.4\nJuly 24, 2024\nRule Changes\nUpdated Indicators of Compromise rulesets with new findings Reduced false positives for the following rules:\nChange thread namespace\nLaunch Sensitive Mount Container\nModification of pam.d detected\nDetection bypass by symlinked files\n0.161.2\nJuly 23, 2024\nRule Changes\nReduced false positives for the Read Shell Configuration File rule Reduced false positives for the Launch Suspicious Network Tool in Container rule 0.161.1\nJuly 23, 2024\nRule Changes\nReduced false positives for the following rules:\nPossible Backdoor using BPF\nModification of pam.d detected\nKernel startup modules changed\nPotential Application Shimming\nAdded the IP Forward Configuration Modification rule.\nImproved macro network_tool_procs Improved conditions for the following rules:\nRead Shell Configuration File\nPTRACE attached to process\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nDefault Policy Changes\nImproved condition for PTRACE attached to process rule.\nAdded theh IP Forward Configuration Modification rule.\nUpdated policies for the following rules:\nContact EC2 Instance Metadata Service From Container\nContact GCP Instance Metadata Service from Host\nContact Task Metadata Endpoint\nContact Azure Instance Metadata Service from Host\n0.161.0\nJuly 17, 2024\nRule Changes\nReduced false positives for the following rules:\nSuspicious Access To Kerberos Secrets\nLaunch Suspicious Network Tool on Host\nNon sudo setuid\nPossible Backdoor using BPF\nImproved tags for Dump memory for credentials rule.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nMarked T1555.002 as not coverable - out of scope.\n0.160.1\nJuly 16, 2024\nRule Changes\nReduced false positives for the following rules:\nLaunch Code Compiler Tool on Host\nCreate Symlink Over Sensitive Files\nNon sudo setuid\nChange thread namespace\nRead ssh information\nKernel startup modules changed\nAdded the following rules:\nBedrock Converse\nDump Cached Domain Credentials\nImproved condition for Delete or rename shell history rule Updated Indicators of Compromise (IoC) rulesets with new findings.\nDefault Policy Changes\nAdded the following rules:\nBedrock Converse\nDump Cached Domain Credentials\n0.160.0\nJuly 10, 2024\nRule Changes\nImproved tags for Enable Windows Remote Management rule.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nReduced false positives for the following rules:\nFileless Malware Detected Dump memory for credentials\n0.159.1\nJuly 09, 2024\nRule Changes\nReduced false positives for the following rules:\nRedirect STDOUT/STDIN to Network Connection in Container\neBPF Program Loaded into Kernel\nPTRACE attached to process\nMount on Container Path Detected\nSuspicious RC Script Modification\nCreate Hardlink Over Sensitive Files\nWrite below root\nPossible Backdoor using BPF\nPotential Application Shimming\nImproved condition for Delete or rename shell history and nsenter Container Escape rules Improved list container_entrypoints Updated Indicators of Compromise rulesets with new findings 0.159.0\nJuly 05, 2024\nRule Changes\nReduced false positives for Read sensitive file untrusted rule.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.158.1\nJuly 02, 2024\nRule Changes\nReduced false positives for the following rules:\nModification of pam.d detected\nModify ld.so.preload\nKernel startup modules changed\nImproved conditions for the following rules:\nRedirect STDOUT/STDIN to Network Connection in Host\nRedirect STDOUT/STDIN to Network Connection in Container\nAdded the following rules:\nSuspicious Capabilities Granted to File\nKernel module unloaded\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nDefault Policy Changes\nUpdated policy for Execute Process from Masqueraded Directory rule.\nAdded the following rules:\nSuspicious Capabilities Granted to File\nKernel module unloaded\n0.158.0\nJune 26, 2024\nRule Changes\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.157.2\nJune 26, 2024\nRule Changes\nReduced false positives for the following rules:\nMalicious IPs or domains detected on command line\nSuspicious RC Script Modification\neBPF Program Loaded into Kernel\nKernel startup modules changed\nRun shell untrusted\nSystem procs network activity\nWrite below monitored dir\nImproved tags for Gsutil cp used to copy files from/to GCP buckets rule Updated Indicators of Compromise rulesets with new findings 0.157.1\nJune 25, 2024\nRule Changes\nReduced false positives for the following rules:\nNon sudo setuid\nConnection to IPFS Network Detected\nKernel startup modules changed\nSystem procs network activity\nContact Azure Instance Metadata Service from Host\nChange thread namespace\nAdded the Mailbox Data Modificationrule\nImproved condition for GCP Sensitive Role Added to User rule.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\nDefault Policy Changes\nUpdated policies for the following rules:\nFind Authentication Certificates\nCurl Exfiltrating File\nSuspicious RC Script Modification\nAdded the Mailbox Data Modificationrule 0.157.0\nJune 21, 2024\nRule Changes\nReduced false positives for the following rules:\nFind Authentication Certificates\nCreate Symlink Over Sensitive Files\nKernel Module Loaded by Unexpected Program\nSuspicious Access To Kerberos Secrets\nNon sudo setuid\nExecution from /tmp\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.156.2\nJune 20, 2024\nRule Changes\nReduced false positives for the following rules:\nKernel startup modules changed\nLaunch Code Compiler Tool on Host\nPossible Backdoor using BPF\nHide Process with Mount\nWrite below root\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.156.1\nJune 19, 2024\nRule Changes\nImproved conditions for the following rules:\nSSM Send Command\nnsenter Container Escape\nLinux Kernel Module Injection Detected\nAdded the following rules:\nGsutil cp used to copy files from/to GCP buckets\nCurl Exfiltrating File\nFixed list rfc_1918_addresses Updated Indicators of Compromise (IoC) rulesets with new findings.\nDefault Policy Changes\nAdded the following rules:\nGsutil cp used to copy files from/to GCP buckets\nCurl Exfiltrating File\nImproved condition for nsenter Container Escape rule.\n0.156.0\nJune 14, 2024\nRule Changes\nReduced false positives for the following rules:\nRedirect STDOUT/STDIN to Network Connection in Host\nSet Setuid or Setgid bit\nPTRACE anti-debug attempt\neBPF Program Loaded into Kernel\nImproved output for Change thread namespace rule.\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.155.3\nJune 13, 2024\nRule Changes\nReduced false positives for the following rules:\nNon sudo setuid\nSuspicious Access To Kerberos Secrets\nWrite below root\nWrite below rpm database\nContact Task Metadata Endpoint\nUpdated Indicators of Compromise (IoC) rulesets with new findings.\n0.155.2\nJune 12, 2024\nRule Changes\nReduced false positives for the following rules:\nSuspicious Home Directory Creation\nKernel startup modules changed\nMount Launched in Privileged Container\nModify Grub Configuration Files\nDownload and launch remote file copy tools in container\nPTRACE anti-debug attempt\nMalicious IPs or domains detected on command line\nSuspicious RC Script Modification\nArchive or Compression Activity Detected\nClear Log Activities\nWrite below rpm database\n","url":"https://docs.sysdig.com/en/release-notes/falco-rules-changelog/2024-archive/"},{"id":825,"title":"Resource and Component Support","content":"Resource SupportKubernetes WorkloadsSysdig Secure provides runtime monitoring and vulnerability scanning for the following Kubernetes workload types using the Sysdig Cluster Shield:\nPods Deployments StatefulSets DaemonSets Jobs CronJobs ReplicaSets ReplicationController init Containers and Side Cars Kubernetes CronJobsStarting with Cluster Shield version 1.16.0, Sysdig supports vulnerability scanning of Kubernetes CronJobs that are scheduled within the Kubernetes API during the standard metadata collection cycle.\nOnce a CronJob is scanned, the results are retained as long as the CronJob definition remains in the Kubernetes API. The CronJob is marked as a Running workload, even if the job is no longer actively running.\nTo verify CronJob scheduling and review scheduling details through the CronJob’s metadata and following configuration, see Sysdig Kubernetes Security and Posture Management.\napiVersion: batch/v1 kind: CronJob metadata: labels: app: default name: example-trigger name: default-example-trigger namespace: default spec: concurrencyPolicy: Allow jobTemplate: metadata: creationTimestamp: null spec: template: metadata: creationTimestamp: null labels: app: default name: example-trigger ... schedule: \u0026#39;*/10 * * * *\u0026#39; Kubernetes Init ContainersStarting with Cluster Shield version 1.16.0, Sysdig supports vulnerability scanning of Kubernetes workload init containers. Kubernetes Init Containers are specialized containers that run before the application containers in a pod. These specialized containers always execute before the primary container of any replica within a Kubernetes workload.\nExample 1The following init container configuration runs pre-checks and waits for services to become available before the primary container starts. Additionally, there are also Kubernetes Sidecar Containers that continuously run throughout the lifecycle of the pod and its workloads across all replicas.\napiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app.kubernetes.io/name: MyApp spec: containers: - name: myapp-container image: busybox:1.28 command: [\u0026#39;sh\u0026#39;, \u0026#39;-c\u0026#39;, \u0026#39;echo The app is running! \u0026amp;\u0026amp; sleep 3600\u0026#39;] initContainers: - name: init-myservice image: busybox:1.28 command: [\u0026#39;sh\u0026#39;, \u0026#39;-c\u0026#39;, \u0026#34;until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done\u0026#34;] - name: init-mydb image: busybox:1.28 command: [\u0026#39;sh\u0026#39;, \u0026#39;-c\u0026#39;, \u0026#34;until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done\u0026#34;] Example 2A sidecar container can act as a log-shipping mechanism that runs throughout the entire lifecycle of the pod. As such, these vulnerabilities are associated with the workload and are included in the Runtime Vulnerability Findings for that workload on the individual container, even if the init container is no longer running. These vulnerability findings remain visible in the Sysdig Platform until the workload definition is removed from the Kubernetes API.\nInit containers inside Kubernetes workloads are often named with an -init suffix. However, it depends on your workload definition and naming conventions set by your development teams.\nFor best practices on using init containers and sidecar containers, refer to the Kubernetes Documentation.\nThe following example demonstrates this configuration:\napiVersion: batch/v1 kind: Job metadata: name: myjob spec: template: spec: containers: - name: myjob image: alpine:latest command: [\u0026#39;sh\u0026#39;, \u0026#39;-c\u0026#39;, \u0026#39;echo \u0026#34;logging\u0026#34; \u0026gt; /opt/logs.txt\u0026#39;] volumeMounts: - name: data mountPath: /opt initContainers: - name: logshipper image: alpine:latest restartPolicy: Always command: [\u0026#39;sh\u0026#39;, \u0026#39;-c\u0026#39;, \u0026#39;tail -F /opt/logs.txt\u0026#39;] volumeMounts: - name: data mountPath: /opt restartPolicy: Never volumes: - name: data emptyDir: {} Non-Orchestrated or Non-Kubernetes ContainersFor non-orchestrated or non-kubernetes containers, Sysdig supports scanning using the Host Scanner with Container Scanning enabled.\nSupported Container RuntimesHost Scanner Docker daemon ContainerD CRI-O Cluster ShieldThe Sysdig Cluster Shield supports any container runtime that Kubernetes will support. For supported Kubernetes runtimes, see the Kubernetes Supported Container Runtime documentation.\nStandalone HostsFor standalone hosts where a Supported Distributions is running, Sysdig Secure performs full host vulnerability scanning and monitoring. For more information, see Host Scanner Installation Guide.\nAgentless Scanning for Cloud HostsSysdig Secure provides agentless scanning capabilities for cloud providers, including:\nAWS: Amazon EC2 instances running supported distributions\nAzure: Microsoft Azure VM instances running supported distributions\nGoogle Cloud: Google Compute Engine (GCE) instances running supported distributions\nAgentless Scanning allows Sysdig Secure to discover vulnerabilities without the need to install agents directly on the hosts. To enable Agentless Scanning, see the Agentless Setup Guide.\nAdditionally, Sysdig Agentless scanning can also detect and scan running containers on Hosts Scanned Agentlessly that are running Supported Distributions.\nServerless Workloads (Agentless)Sysdig Agentless Workload Scanning supports vulnerability detection for the following serverless resources:\nAWS Lambda Functions Deployed as Container Images. Deployed as ZIP Archives (Application code and dependencies are analyzed alongside the AWS-managed runtime base image). CI/CD PipelineFor CI/CD pipeline scanning, Sysdig provides a CLI-based scanner that can be easily integrated into your build pipeline to scan container images. For more information, see Sysdig CLI Scanner.\nCLI Scanner Supported Container Image Formats and Loading Methods Prefix Name Description docker:// Docker Daemon Load the image from the Docker daemon, honoring the DOCKER_HOST environment variable or other Docker configuration files. podman:// Podman Load the image from the Podman daemon. file:// Docker Archive (tar) Load the image from a .tar file saved as a Docker image archive (Docker save command). containerd:// Containerd Load the image from the Containerd daemon, which manages container lifecycles on the host. crio:// CRI-O Load the image from the Containers Storage location used by CRI-O for Kubernetes environments. pull:// Docker Registry Force pulling the image from a remote repository, ignoring local images with the same name. Supported Container Image CPU Architectures linux/amd64 linux/arm64 linux/s390x VM Component Deprecation and SupportabilityLegacy Engine ComponentsAll V1 Engine Components will be deprecated on January 1st, 2025. After this date, Sysdig will not apply defect fixes or security patches. Below are the replacement components for the affected items:\nAffected Components Legacy Component Description Replacement Components Sysdig Image Analyzer Sysdig Legacy Engine Runtime Container scanner for Container Workloads Agent: Sysdig Cluster Shield or Sysdig Host Scanner Agentless: Agentless Host-Based Scanning Sysdig Host Analyzer Sysdig Legacy Engine Host Scanning Component for analyzing host-level vulnerabilities Agent: Sysdig Host Scanner Agentless: Agentless Host-Based Scanning Sysdig Inline Scanner Sysdig\u0026rsquo;s command line scanner for Container Images Command Line: Sysdig CLI Scanner Sysdig Registry Scanner Sysdig Legacy Scanning component for Container Registries Sysdig Helm Chart Version 1.0.0 introduced the new scanning engine functionality by default: Registry Scanner Scanning Engine ComponentsCertain components and versions used with the Sysdig Scanning Engine will reach end-of-life (EOL) or be considered out of support. Below are the affected components and their descriptions.\nAffected Components Component Description End of Support Sysdig Cluster Scanner Integrated into Sysdig Cluster Shield for an all-in-one deployable component for Kubernetes workloads. No longer supported as a standalone component. Yes - No longer supported as a standalone component. Use Sysdig Cluster Shield. Sysdig Host Scanner The scanner will continue to be supported, but Versions below v0.9.0 will no longer detect RedHat vulnerabilities due to the switch to CSAF-VEX on Jan 1st, 2025. Yes - Versions below v0.9.0, due to the switch to CSAF-VEX. Additionally please see Sysdig Host Shield No - Versions above v0.10.0 Sysdig Registry Scanner The scanner will continue to be supported, but Versions below v0.2.61 will no longer detect RedHat vulnerabilities due to the switch to CSAF-VEX on Jan 1st, 2025. Yes - Versions below v0.2.61, due to the switch to CSAF-VEX.\nNo - Versions above v0.2.62 Sysdig CLI Scanner The scanner will continue to be supported, but Versions \u0026lt; 1.11.0 will no longer detect RedHat vulnerabilities due to the switch to CSAF-VEX on Jan 1st, 2025. Yes - Versions below v1.11.0, due to the switch to CSAF-VEX No - Versions above v1.12.0 ","url":"https://docs.sysdig.com/en/sysdig-secure/vm-component_support/"},{"id":826,"title":"Falco Rules Changelog 2023 Archive","content":" Commit Date\nRule Notes\nVersion of the Falco Rules Installer (On-Prem)\nDecember 22, 2023\nRule Changes\nReduced false positives for the following rules:\nChange memory swap options\nPacket socket created in container\neBPF Program Loaded into Kernel\n0.133.10\nDecember 21, 2023\nRule Changes\nReduced false positives for the following rules:\nRead ssh information\neBPF Program Loaded into Kernel\nImproved condition for the Detect outbound connections to Proxy/VPN rule.\nUpdated the IoCs Ruleset with new findings.\n0.133.9\nDecember 20, 2023\nRule Changes\nReduced false positives for the following rules:\nSuspicious Cron Modification\nClear Log Activities\nPossible Backdoor using BPF\nImproved condition for the Detect outbound connections to TOR Entry Nodes rule.\nUpdated the IoCs Ruleset with new findings.\n0.133.8\nDecember 19, 2023\nRule Changes\nReduced false positives for the following rules:\nCreate Hidden Files or Directories\nSuspicious Cron Modification\neBPF Program Loaded into Kernel\nWrite below etc\nLaunch Sensitive Mount Container\nLaunch Root User Container\nImproved condition for the following rule:Connection to IPFS Network Detected\nUpdated the IoCs Ruleset with new findings.\n0.133.7\nDecember 18, 2023\nRule Changes\nReduced false positives for the following rules:\nNon sudo setuid\nLaunch Root User Container\nImproved condition for the following rules:\nUnprivileged Delegation of Page Faults Handling to a Userspace Process\nAWS CLI used with endpoint url parameter\nImproved output for the Connection to IPFS Network Detectedrule.\nUpdated the IoCs Ruleset with new findings.\n0.133.6\nDecember 15, 2023\nRule Changes\nReduced false postives for the following rules:\nLaunch Privileged Container\nSet Setuid or Setgid bit\nAWS CLI used with endpoint url parameter\nImproved output for the following rules:\nDetect outbound connections to TOR Entry Nodes\nDetect crypto miners using the Stratum protocol\nConnection to IPFS Network Detected\nUpdated the IoCs Ruleset with new findings.\nImproved coverage for the Inhibit System Recoverytechnique.\n0.133.5\nDecember 14, 2023\nRule Changes\nReduced false positives for the following rules:\nConnection to IPFS Network Detected\nPacket socket created in container\nPossible Backdoor using BPF\neBPF Program Loaded into Kernel\nUpdated the IoCs Ruleset with new findings.\n0.133.4\nDecember 11, 2023\nRule Changes\nReduced false positives for the following rules:\nSuspicious Cron Modification\neBPF Program Loaded into Kernel\nPossible Backdoor using BPF\nLaunch Root User Containerl\nLaunch Sensitive Mount Container\nFileless Malware Detected (memfd)F\nCreate Symlink Over Sensitive Files\nUpdated the IoCs Ruleset with new findings.\n0.133.1\nDecember 04, 2023\nRule Changes\nImproved condition for the following rules:\nRedirect STDOUT/STDIN to Network Connection in Container\nRedirect STDOUT/STDIN to Network Connection in Host\nImproved output for the following rules:\nSuspicious Home Directory Creation\nDetect outbound connections to Proxy/VPN\nAdded the following rules:\nNew GitHub Action Workflow Deployed\nOkta Multiple Application Requests with Invalid Credentials\nPush on GitHub Actions Detected\nOkta MFA Bypass Attempt\nRemove macro from the Detect outbound connections to common miner pool ports rule.\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nNew GitHub Action Workflow Deployed\nOkta Multiple Application Requests with Invalid Credentials\nPush on GitHub Actions Detected\nOkta MFA Bypass Attempt\n0.133.0\nDecember 03, 2023\nRule Changes\nReduced false positives for the following rules:\nModify binary dirs\nPacket socket created in container\nPossible Backdoor using BPF\neBPF Program Loaded into Kernel\nUpdated the IoCs Ruleset with new findings.\n0.132.5\nNovember 30, 2023\nRule Changes\nReduced false positives for the following rules:\nWrite below etc\nAzure RDP Access Is Allowed from The Internet\nPossible Backdoor using BPF\nAzure SSH Access Is Allowed from The Internet\nRead Shell Configuration File\nPacket socket created in container\nUpdated the IoCs Ruleset with new findings.\n0.132.4\nNovember 30, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Privileged Container\nPossible Backdoor using BPF\nModification of pam.d detected\nRead ssh information\nUpdated the IoCs Ruleset with new findings.\n0.132.2\nNovember 29, 2023\nRule Changes\nReduced false positives for the following rules:\nRead ssh information\nSuspicious Cron Modification\nPossible Backdoor using BPF\nNon sudo setuid\nUpdated the IoCs Ruleset with new findings.\n0.132.1\nNovember 28, 2023\nRule Changes\nReduced false positives for the following rules:\nPossible Backdoor using BPF\neBPF Program Loaded into Kernel\nFileless Malware Detected (memfd)\nModification of pam.d detected\nSuspicious Cron Modification\nAdded the following rules:\nUpdate Secret in Secrets Manager\nDelete Secret in Secrets Manager\nCreate Secret in Secrets Manager\nCancel Secret Rotation in Secrets Manager\nAzure Create/Update User Managed Identity\nAzure Create/Update a Public IP Address\nAzure Create/Update a Key Vault\nAzure Delete a Public IP Address\nAzure Delete a Key Vault\nAzure Delete User Managed Identity\nCODEOWNERS file modified\nOkta One-Time Token Reused\nImproved the network_tool_binaries list.\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nUpdate Secret in Secrets Manager\nDelete Secret in Secrets Manager\nCreate Secret in Secrets Manager\nCancel Secret Rotation in Secrets Manager\nAzure Create/Update User Managed Identity\nAzure Create/Update a Public IP Address\nAzure Create/Update a Key Vault\nAzure Delete a Public IP Address\nAzure Delete a Key Vault\nAzure Delete User Managed Identity\nCODEOWNERS file modified\nOkta One-Time Token Reused\n0.132.0\nNovember 27, 2023\nRule Changes\nRestored the Azure duplicated rules which were previously removed.\nDefault Policy Changes\nRestored the Azure duplicated rules which were previously removed.\n0.131.7\nNovember 25, 2023\nRule Changes\nReduced false positives for the following rules:\nContact EC2 Instance Metadata Service From Containe\nNon sudo setuid\nImproved condition for the following:\nAzure Delete a Run Command on the Virtual Machine rule.\nchmod macro.\nDefault Policy Changes\nUpdated policy for Azure duplicated rules.\n0.131.5\nNovember 24, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Sensitive Mount Container\nCreate Symlink Over Sensitive Files\nKernel startup modules changed\nExecution from /tmp\nChanged rule name Azure Terminate the Virtual Machine to Azure Stop a Virtual Machine\nUpdated the IoCs Ruleset with new findings.\nUpdated MITRE tags.\nDefault Policy Changes\nChange rule name Azure Terminate the Virtual Machine to Azure Stop a Virtual Machine.\n0.131.4\nNovember 23, 2023\nRule Changes\nReduced false positives for the following rules:\nSuspicious Cron Modification\nWrite below etc\nMount Launched in Privileged Container\nModification of pam.d detected\nRead Environment Variable from /proc files in Container\nUpdated the IoCs Ruleset with new findings.\nUpdated MITRE tags.\nDefault Policy Changes\nUpdated policy for the Azure Terminate the Virtual Machine rule.\n0.131.3\nNovember 22, 2023\nRule Changes\nReduced false positives for the following rules:\neBPF program loaded into kernel\nSuspicious Cron Modification\nWrite below root\nNon sudo setuid\nUpdated the IoCs Ruleset with new findings.\n0.131.2\nNovember 21, 2023\nDefault Policy Changes\nUpdated policy for the Assume Role performed by an Assumed Role Identity rule.\n0.131.1\nNovember 21, 2023\nRule Changes\nReduced false positive for the following rules:\neBPF program loaded into kernel\nSuspicious Cron Modification\nSet Setuid or Setgid bit\nWrite below root\nDetect outbound connections to common miner pool ports\nAdded the following rules:\nCloudtrail Management Events Disabled via Event Selectors\nAssume Role performed by an Assumed Role Identity\nUpdated the policy for the Contact K8S API Server From Container rule.\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nCloudtrail Management Events Disabled via Event Selectors\nAssume Role performed by an Assumed Role Identity\nUpdated the policy for following rules:\nContact K8S API Server From Container\nContact Task Metadata Endpoint\n0.131.0\nNovember 20, 2023\nRule Changes\nReduced false positives for the following rules:\neBPF program loaded into kernel\nPTRACE attached to process\nSet Setuid or Setgid bit\nNon sudo setuid\nPacket socket created in container\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nRemoved the Disallowed K8s User rule from Managed Policies.\n0.130.8\nNovember 17, 2023\nRule Changes\nReduced false positives for the following rules:\nModification of pam.d detected\nPossible Backdoor using BPF\nPacket socket created in container\nDump memory for credentials\nLaunch Remote File Copy Tools in Container\nSuspicious cron modification\nBase64-encoded Shell Script Execution\nFileless Malware Detected (memfd)\nFixed exception in Share RDS Snapshot with Foreign Account rule.\nImproved output for the GitHub Webhook Connected rule.\nUpdated the indicators of compromise (IoC) Ruleset with new findings.\n0.130.7\nNovember 16, 2023\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nLaunch Ingress Remote File Copy Tools in Container\nWrite below etc\nEscape to host via command injection in process\nUpdated the IoCs Ruleset with new findings.\n0.130.6\nNovember 15, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch root user container\neBPF program loaded into kernel\nPossible Backdoor using BPF\nNon sudo setuid\nModification of pam.d detected\nImproved output Okta ruleset.\nImproved tags for the AWS RDS Master Password Update. Updated the IoCs Ruleset with new findings.\n0.130.5\nNovember 14, 2023\nRule Changes\nReduced false positives for the following rules:\neBPF program loaded into kernel\nMount Launched in Privileged Containe\nChange thread namespace\nRemoved Sysdig images from the Terminal shell in container rule.\nImprove description for the Okta Admin Console Access Velocity Behavior rule.\nUpdated policy for the SSM Get Parameter rule.\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nUpdated the policy for the following rules:\nEC2 Instance Connect/SSH Public Key Uploaded\nSSM Get Parameter\n0.130.4\nNovember 13, 2023\nRule Changes\nReduced false positives for the following rules:\nNon sudo setuid\nSet Setuid or Setgid bit\nWrite below etc\nLaunch Sensitive Mount Container\nLaunch Root User Container\nWrite below root\nPacket socket created in container\nLaunch privileged container\neBPF program loaded into kernel\n0.130.3\nNovember 10, 2023\nRule Changes\nReduced false positives for the following rules:\nMount Launched in Privileged Container\nPossible Backdoor using BPF\nPacket socket created in container\nNon sudo setuid 0.130.2\nNovember 08, 2023\nRule Changes\nReduced false positives for the following rules:\nModification of pam.d detected\nDiamorphine Rootkit Activity\nWrite below root\neBPF program loaded into kernel\nWrite below etc\nUpdated the IoCs Ruleset with new findings.\n0.130.1\nNovember 07, 2023\nRule Changes\nReduced false positives for the following rules:\nSuspicious Cron Modification\nMount Launched in Privileged Container\neBPF Program Loaded into Kernel\nModification of pam.d detected\nAdded the following rules:\nContainer image built on host\nLeave Organization\nEC2 Add User Data\nSSM Get Parameter\nEC2 Get User Data\nImproved condition for the following rules:\nSystem procs network activity\nPotential UAC Bypass Using Registry Manipulation\nump memory for credentials\nImproved the Windows suspicious_network_binaries list.\nUpdated description for the Malicious C2 IPs or domains exploiting log4j rule.\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nContainer image built on host\nLeave Organization\nEC2 Add User Data\nSSM Get Parameter\nEC2 Get User Data\nUpdated the Remove MFA from user in Oktapolicy.\n0.130.0\nNovember 06, 2023\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nWrite below etc\nRead Environment Variable from /proc files in Container\nModification of pam.d detected\nNon sudo setuid\n0.129.4\nNovember 04, 2023\nRule Changes\nReduced false positives for the following rules:\nSearch Private Keys or Passwords\nFileless Malware Detected (memfd)\nMount Launched in Privileged Container\nModification of pam.d detected\nSSH keys added to authorized_keys\nNon sudo setuid\nPossible backdoor using BPF\nChange memory swap options\nKernel startup modules changed\nImproved output for the Shutdown or Reboot detected rule.\nUpdated MITRE tags.\nImproved condition for the Execution of binary using ld-linux rule.\n0.129.3\nNovember 02, 2023\nDefault Policy Changes\nUpdated theSysdig AWS Notable Events policy.\n0.129.2\nOctober 31, 2023\nRule Changes\nAdded the following rules:\nShutdown or Reboot detected\nGet Federation Token with Admin Policy\nFull Visibility on Federated Sessions\nGCP CloudRun Service Started\nCreate Key Pair\nStop EC2 Instances\nGet Lambda Function\nAttach IAM Policy to Group\nEscape to host via command injection in process\nUpdated the IoCs Ruleset with new findings.\nImproved the network_tool_binarieslist.\nImproved condition for the following rules:\nGLIBC \"Looney Tunables\" Local Privilege Escalation\nCVE-2023-4911\nPotential IRC connection detected\nPut Object in Watched Bucket\nDefault Policy Changes\nAdded the following rules:\nShutdown or Reboot detected\nGet Federation Token with Admin Policy\nFull Visibility on Federated Sessions\nGCP CloudRun Service Started\nCreate Key Pair\nStop EC2 Instances\nGet Lambda Function\nAttach IAM Policy to Group\nEscape to host via command injection in process\nUpdated the policy for the following rule:\nChange memory swap options\n0.129.0\nOctober 30, 2023\nRule Changes\nReduced false positives for the following rules:\nSuspicious cron modification\nPacket socket created in container\nFileless Malware Detected (memfd)\nModification of pam.d detected Write below etc\nRead SSH information\ndocker client is executed in a container\neBPF Program Loaded into Kernel\nWrite below rpm databasec\nUpdated the IoCs Ruleset with new findings.\nUpdated MITRE tags.\nImproved output for the following: Hexadecimal string detected\nOutput CloudRun Create Service\n0.128.7\nOctober 26, 2023\nAdded Windows support.\n0.128.6\nOctober 24, 2023\nRule Changes\nReduced false positives for the following rules:\nSuspicious Cron Modification\nPossible backdoor using BPF\nModification of pam.d detected\nSSH keys added to authorized_keys\nKernel startup modules changed\nUpdated the IoCs Ruleset with new findings.\nUpdated MITRE tags.\nImproved the condition for the Modification of pam.d detected rule.\n0.128.4\nOctober 23, 2023\nRule Changes\nUpdated Sysdig Mitre Attack Mapper.\nUpdated MITRE tags.\nReduced false positives for the following rules:\nFileless Malware Detected (memfd)\nModification of pam.d detected\nPossible Backdoor using BPF\nSuspicious Cron Modification\nPacket socket created in container\nKernel startup modules changed\nModification of pam.d detected\nFileless Malware Detected (memfd)\nModify ld.so.preload\n0.128.3\nOctober 18, 2023\nRule Changes\nReduced false positives for the following rules:\nMount launched in privileged container\nKernel startup modules changed\nRead SSH information\nPossible Backdoor using BPF\n0.128.2\nOctober 17, 2023\nRule Changes\nReduced false positives for the following preview rules:\nUnmount executed on host\nSystem Time Discovery Detected\nSystem Time Discovery Detected\nShutdown or Reboot detected\nUpdated MITRE tags.\nReduced false positives for the following rules:\nSuspicious Cron Modification\nFileless Malware Detected (memfd)\neBPF Program Loaded into Kernel\n0.128.1\nOctober 06, 2023\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel rule\nPossible Backdoor using BPF\nImproved condition for the GLIBC \"Looney Tunables\" Local Privilege Escalation (CVE-2023-4911) rule.\nUpdated the IoCs Ruleset with new findings.\n0.127.7\nOctober 04, 2023\nRule Changes\nAdded the following rules:\nCodeBuild Create Project with Miner\nCodeBuild Start Build with Miner\nCodeCommit Create Repository\nCodeCommit Git Push\nCodeBuild Create Project\nCloudFormation Create Stack\nSSH keys added to authorized_keys\nSageMaker Create Notebook Instance Lifecycle Configuration\nImage Builder Create Component\nAmplify Create App\nEC2 Create Auto Scaling Group\nPotential IRC connection detected\nCodeBuild Start Build\nECS Create Cluster\nEC2 Create Launch Template\nChange memory swap options\nAzure Update a Web App's configuration settings\nAzure Function App Create/Update a Connection\nAzure Create/Update Web Apps Hostname Bindings\nAzure Cosmos DB Delete MongoDB Database\nAzure Cosmos DB Delete SQL DB Container\nAzure Cosmos DB Delete Postgres Firewall Rule\nAzure Cosmos DB Delete Postgres Cluster\nAzure Cosmos DB Delete Service\nAzure Cosmos DB Delete MongoDB Role Definition\nAzure Cosmos DB Delete MongoDB User Definition\nAzure Cosmos DB Delete MongoDB Database Collection\nAzure Cosmos DB Delete Gramlin Database\nAzure Cosmos DB Delete Gremlin Database Graphs\nAzure Cosmos DB Delete Cassandra Keyspace\nAzure Cosmos DB Delete Cassandra Table\nAzure Cosmos DB Delete Database Account\nAzure Cosmos DB Delete Table\nAzure Cosmos DB Delete Postgres Role\nAzure Cosmos DB Delete SQL Assignment\nAzure Cosmos DB Delete SQL Database\nAzure Cosmos DB Delete SQL User Defined Function\nAzure Cosmos DB Delete SQL Trigger\nAzure Cosmos DB Delete SQL Stored Procedure\nAzure Cosmos DB Create SQL Assignment\nAzure Cosmos DB Create Postgres Role\nAzure Cosmos DB Create SQL Definition\nAzure Cosmos DB Create SQL Database\nAzure Cosmos DB Create SQL User Defined Function\nAzure Cosmos DB Create SQL Trigger\nAzure Cosmos DB Create SQL Stored Procedure\nAzure Cosmos DB Create SQL DB Container\nAzure Cosmos DB Create Postgres Firewall Rule\nAzure Cosmos DB Create MongoDB Database\nAzure Cosmos DB Create Postgres Cluster\nAzure Cosmos DB Create MongoDB Role Definition\nAzure Cosmos DB Create MongoDB User Definition\nAzure Cosmos DB Create MongoDB Database Collection\nAzure Cosmos DB Create Gramlin Database Azure Cosmos DB Create Gremlin Database Graphs\nAzure Cosmos DB Create Cassandra Keyspace\nAzure Cosmos DB Create Cassandra Table\nAzure Cosmos DB Create Database Account\nAzure Cosmos DB Create Table\nAzure Cosmos DB Create Service\nReduced false positivess for the following rules:\nRead Environment Variable from /proc files in Container\nSet Setuid or Setgid bit\nLaunch Suspicious Network Tool in Container\nNon sudo setuid\nClear log activities\neBPF Program Loaded into Kernel\nSearch Private Keys or Passwords\nImproved condition for the following rules:\nDetect curl Using Socks Proxy\nDetect cloned process by PRoot\nUpdated MITRE tags.\nUpdated policy for the Modification of pam.d detected rule.\nImproved log_files list.\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nCodeBuild Create Project with Miner\nCodeBuild Start Build with Miner\nCodeCommit Create Repository\nCodeCommit Git Push\nCodeBuild Create Project\nCloudFormation Create Stack\nSSH keys added to authorized_keys\nSageMaker Create Notebook Instance Lifecycle Configuration\nImage Builder Create Component\nAmplify Create App\nEC2 Create Auto Scaling Group\nPotential IRC connection detected\nCodeBuild Start Build\nECS Create Cluster\nEC2 Create Launch Template\nChange memory swap options\nUpdated policy for the following rules:\nSuspicious device created in container\nModification of pam.d detected\nAdded Simple Systems Manager (SSM) rules to awscloudtrail policy.\n0.128.0\nOctober 04, 2023\nRule Changes\nAdded the GLIBC \"Looney Tunables\" Local Privilege Escalation (CVE-2023-4911) rule.\nDefault Policy Changes\nAdded the GLIBC \"Looney Tunables\" Local Privilege Escalation (CVE-2023-4911) rule.\n0.127.6\nOctober 04, 2023\nRule Changes\nReduced false positives for the following rules:\nModify ld.so.preload\nContact EC2 Instance Metadata Service From Containe\nUpdated the IoCs Ruleset with new findings.\n0.127.5\nOctober 03, 2023\nRule Changes\nReduced false positives for the following rules:\nRead Environment Variable from /proc files in Container\nSet Setuid or Setgid bit\nLaunch Suspicious Network Tool in Container\nNon sudo setuid\nClear log activities\neBPF Program Loaded into Kernel\nSearch Private Keys or Passwords\nUpdated the IoCs Ruleset with new findings.\n0.127.4\nSeptember 29, 2023\nRule Changes\nReduced false positives for the following rules:\nPossible Backdoor using BPF\nAWS CLI used with endpoint url parameter\neBPF Program Loaded into Kernel\nNon sudo setuid\nUpdated the MITRE tags.\nAdded thedns_traffic macro.\nImproved the Okta rules.\nUpdated the IoCs Ruleset with new findings.\n0.127.3\nSeptember 28, 2023\nRule Changes\nReduced false positives for the following rules:\nSet Setuid or Setgid bit\nNon sudo setuid\nLaunch root user container\nPacket socket created in container\nRedirect STDOUT/STDIN to Network Connection in Container\nFileless Malware Detected (memfd)\nUpdated MITRE tags.\nAdded exception for the Suspicious Domain Contacted rule.\nUpdated the IoCs Ruleset with new findings.\n0.127.2\nSeptember 27, 2023\nRule Changes\nReduced false positives for the following rules:\nSet Setuid or Setgid bit\nLaunch excessively capable container\nPossible backdoor using BPF\nLaunch privileged container\nImproved output for the Fileless Malware Detected (memfd) rule.\nUpdated the IoCs Ruleset with new findings.\n0.127.1\nSeptember 26, 2023\nRule Changes\nAdded the following rules:\nGCP VPC Add Peering\nOkta Suspicious User Activity Report\nOkta Admin Console Access via New Device\nOkta FastPass Phishing Attempt\nModification of pam.d detected\nGCP Modified VPC Network\nGCP Create VPC Network\nGCP VPC Remove Peering\nOkta Admin Console Access Velocity Behavior\nGCP Create Role\nGCP Delete Route\nSuspicious device created in container\nGCP Update CloudSQL\nOkta Admin Console Access with New Behaviors\nGCP Create Route\nOkta Sign-in via Proxy\nOkta Create Identity Provider\nK8s Pod Deleted\nGCP Update Role\nGCP Modify Audit Policy SSM Start Session\nOkta Admin Console Access Failure\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nSet Setuid or Setgid bit\nMount Launched in Privileged Container\nSuspicious Cron Modification\nPossible Backdoor using BPF\nImproved condition for the following rules:\nOkta CAPTCHA Settings Updated\nOkta Suspicious IP Inbound Request\nUpdated MITRE tags.\nImproved output for the Packet socket created in container rule.\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nGCP VPC Add Peering\nOkta Suspicious User Activity Report\nOkta Admin Console Access via New Device\nOkta FastPass Phishing Attempt\nModification of pam.d detected\nGCP Modified VPC Network\nGCP Create VPC Network\nGCP VPC Remove Peering\nOkta Admin Console Access Velocity Behavior\nGCP Create Role\nGCP Delete Route\nSuspicious device created in container\nGCP Update CloudSQL\nOkta Admin Console Access with New Behaviors\nGCP Create Route\nOkta Sign-in via Proxy\nOkta Create Identity Provider\nK8s Pod Deleted\nGCP Update Role\nGCP Modify Audit Policy SSM Start Session\nOkta Admin Console Access Failure\nUpdated policy for the following rules:\nAWS CLI used with endpoint url parameter\nHexadecimal string detected\n0.127.0\nSeptember 22, 2023\nRule Changes\nReduced false positives for the following rules:\nKernel startup module changed\nLaunch root user container\nRead shell configuration file\nWrite below etc\nImproved output for the SSM Send Command rule.\nUpdated the IoCs Ruleset with new findings.\nUpdated MITRE tag.\n0.126.3\nSeptember 21, 2023\nRule Changes\nReduced false positives for the following rules:\nNon Sudo Setuid\nMount Launched in Privileged Container\nFileless Malware Detected (memfd)\nBase64-encoded Shell Script Execution\nMount Launched in Privileged Container\nPacket socket created in container\nWrite below etc\nLaunch sensitive mount container\nUpdated the IoCs Ruleset with new findings.\nUpdated MITRE tag.\n0.126.2\nSeptember 20, 2023\nRule Changes\nReduced false positives for the following rules:\nkernel startup module changed\nLaunch Privileged Container\nUpdated the IoCs Ruleset with new findings.\nFixed incorrect tags.\nDefault Policy Changes\nUpdated policy for the following rules:\nCloudWatch Delete Alarms\nSchedule Key Deletion\nCloudWatch Delete Log Group\n0.126.1\nSeptember 19, 2023\nRule Changes\nReduced false positives for the following rules:\nRedirect STDOUT/STDIN to Network Connection in Container\nLaunch Root User Container\nSuspicious Operations with Firewalls\nNon sudo setuid\nFileless Malware Detected (memfd)\nNon Sudo Setuid\nAdded the following rules:\nAWS CLI used with endpoint url parameter\nHexadecimal string detected\nImproved condition for the Packet socket created in container rule.\nDefault Policy Changes\nAdded the following files:\nAWS CLI used with endpoint url parameter\nHexadecimal string detected\nUpdated the policy for Container escape via discretionary access control.\nAdded the Sysdig Azure Threat Intelligencepolicy.\n0.126.0\nSeptember 14, 2023\nRule Changes\nReduced false positives for the following rule:\nSuspicious Operations with firewall\n0.125.3\nSeptember 13, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Root User Container\nSet Setuid or Setgid bit\nLaunch Suspicious Network Tool in Container\nUpdated the IoCs Ruleset with new findings.\n0.125.1\nSeptember 12, 2023\nRule Changes\nAdded the following files:\nUnexpected Unshare event in Container\nDisallowed SSH Connection Non Standard Port\nAzure Suspicious IP Inbound Request\nGCP Change Owner\nContainer escape via discretionary access control\nImproved condition for the following:\nLaunch Privileged Container\nWrite below etc\nSuspicious Operations with Firewalls\nLaunch Remote File Copy Tools in Container\nImproved the sysdig_commercial_images list.\nImproved the performance of the renamemacro.\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following files:\nUnexpected Unshare event in Container\nDisallowed SSH Connection Non Standard Port\nAzure Suspicious IP Inbound Request\nGCP Change Owner\nContainer escape via discretionary access control\n0.125.0\nSeptember 08, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Ingress Remote File Copy Tools in Container\nLaunch Root User Container\nPossible Backdoor using BPF\nFileless Malware Detected (memfd)\nPacket socket created in container\nChange thread namespace\nImproved host and container tags.\nUpdated the IoCs Ruleset with new findings.\n0.124.3\nSeptember 06, 2023\nRule Changes\nReduced false positives for the following rules:\nPTRACE attached to process\nMount Launched in Privileged Container\nLaunch Root User Container\nLaunch Sensitive Mount Container\nLaunch Privileged Container\nAdded the azure_trusted_images_launch_root_list list.\nUpdated the IoCs Ruleset with new findings.\n0.124.1\nSeptember 05, 2023\nRule Changes\nImproved condition for the following:\nPossible Backdoor using BPF\nCreate Symlink Over Sensitive Files\nSuspicious Home Directory Creation\ncontainer_entrypoint\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the rule to the AWS IAM Credential Report Requestpolicy.\nUpdate the policy for the Contact Task Metadata Endpoint rule.\n0.124.0\nSeptember 04, 2023\nRule Changes\nReduced false positives for the following rules:\nThe docker client is executed in a container\nPossible Backdoor using BPF\nFileless Malware Detected (memfd)\nImproved host and container tags.\nUpdated the IoCs Ruleset with new findings.\n0.123.3\nSeptember 02, 2023\nRule Changes\nReduced false positives for the following rules:\nThe docker client is executed in a container\nMount Launched in Privileged Container\nPacket Socket Created in Container\nLaunch Root User Container\nLaunch Privileged Container\nImproved condition for the following rule:\nGCP Default Service Account Activity\nUpdated the IoCs Ruleset with new findings.\nImproved the host and container tags.\n0.123.2\nAugust 30, 2023\nRule Changes\nReduced false positives for the following rules:\nPacket Socket Created in Container\nRead Shell Configuration File\nChange Thread Namespace\neBPF Program Loaded into Kernel\nPossible Backdoor using BPF\nUpdated the IoCs Ruleset with new findings.\n0.123.1\nAugust 29, 2023\nRule Changes\nReduced false positives for the following rules:\nWrite below root\nKernel startup modules changed\nImproved condition for the following rules: Contact Task Metadata Endpoint\nDetect reconnaissance scripts\nImproved output for the following rules: Update Package Repository\nPossible Backdoor using BPF\nUpdated the IoCs Ruleset with new findings.\nImproved the miner_portslist.\n0.123.0\nAugust 28, 2023\nRule Changes\nReduced false positives for the following rules:\nRead ssh information\nSuspicious System Service Modification\nSuspicious Cron Modification\nRead Shell Configuration File\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nReduced false positives for Put Object in Watched Bucket.\n0.122.5\nAugust 18, 2023\nRule Changes\nReduced false positives for the following rules:\nPacket socket created in container\nChange thread namespace\nAWS SSM Agent File Write\nDefault Policy Changes\nDowngraded AWS rules.\n0.122.4\nAugust 05, 2023\nRule Changes\nReduced false positives for the following rules:\nExecution from /tmp\nLaunch Privileged Container\nPacket socket created in container\nUpdated the IoCs Ruleset with new findings.\n0.122.3\nAugust 03, 2023\nRule Changes\nReduced false positives for the following rules:\nWrite below root\nSet Setuid or Setgid bit\nPossible Backdoor using BPF\nNon sudo setuid\nLaunch Sensitive Mount Container\nUpdated the IoCs Ruleset with new findings.\nImproved output for the Fileless Malware Detected (memfd) rule.\nDefault Policy Changes\nRemoved Packet socket created in container from the Sysdig Runtime Notable Events policy.\n0.122.2\nAugust 02, 2023\nRule Changes\nImproved condition for Azure RDP Access Is Allowed from The Internet rule.\nImproved condition for Azure SSH Access Is Allowed from The Internet rule.\nDefault Policy Changes\nRemove the AWS IAM Credential Report Request rule from policy.\n0.122.1\nAugust 01, 2023\nRule Changes\nReduced false positives for the Launch Root User Container rule.\nAdded the following rules:\nAWS ECS Create Task Definition\nAWS RDS Master Password Update\nAWS IAM Credential Report Request\nUpdated the IoCs Ruleset with new findings.\nImproved the network_tool_binaries list.\nAdded support for accept4 syscall.\nDefault Policy Changes\nAdded the following rules:\nAWS ECS Create Task Definition\nAWS RDS Master Password Update\nAWS IAM Credential Report Request\n0.122.0\nJuly 28, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Privileged Container\nWrite below rpm database\nWrite below binary dir\nUpdated the IoCs Ruleset with new findings.\n0.121.4\nJuly 27, 2023\nRule Changes\nReduced false positives for the following rules:\nFileless Malware Detected (memfd)\nRedirect STDOUT/STDIN to Network Connection in Container\nWrite below root\nPacket socket created in container\nExecution from /tmp\nIncreased the async limit to speed up validation times.\nUpdated the IoCs Ruleset with new findings.\n0.121.3\nJuly 26, 2023\nRule Changes\nReduced false positives for the following rules:\nFileless Malware Detected (memfd)\nContact GCP Instance Metadata Service from Container\nImproved performance for Contact Task Metadata Endpoint\nUpdated the IoCs Ruleset with new findings.\n0.121.2\nJuly 25, 2023\nRule Changes\nReduced false positives for the following rule: Fileless Malware Detected (memfd)\nTuned the preview rule:\nPotential IRC connection detected\u003c\nAdded the preview rule:\nContact AWS Fargate Task Metadata Endpoint\n0.121.1\nJuly 25, 2023\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nExecution from /tmp\nChange thread namespace Packet socket created in container\nAWS SSM Agent File Write Added the following rules:\nFileless Malware Detected (memfd)\nContact Azure Instance Metadata Service from Container Contact GCP Instance Metadata Service from Container\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nFileless Malware Detected (memfd)\nContact Azure Instance Metadata Service from Container Contact GCP Instance Metadata Service from Container\nUpdated the policy for the following rules:\nFind Azure Credentials\nFind GCP Credentials Download and launch remote file copy tools in container\nFind GCP Credentials\nRemoved the Contact cloud metadata service from container rule from policies.\n0.121.0\nJuly 24, 2023\nRule Changes\nReduced false positives for the following rules:\nPacket socket created in container\nUser Management Event Detected\nPossible Backdoor using BPF\nUpdated the IoCs Ruleset with new findings.\n0.120.4\nJuly 22, 2023\nRule Changes\nReduced false positives for the following rules:\nChange thread namespacer\nLaunch Privileged Container\nMount Launched in Privileged Container\nPossible Backdoor using BPF\nImproved outputs for the following rules:\nSuspicious Domain Contacted\nSuspicious Domain Contacted\nnon_system_user\nConnection to IPFS Network Detected\nAdded the following macros to Threat Intel:\nipfs_domains_in_args\nsuspicious_domains_connection_data\nUpdated the IoCs Ruleset with new findings.\n0.120.0\nJuly 21, 2023\nRule Changes\nReduced false positives for the following rules:\nSuspicious Domain Contacted\nThe docker client is executed in a container\neBPF Program Loaded into Kernel\nPacket socket created in container\nUpdated the IoCs Ruleset with new findings.\nTuned thePotential IRC connection detected preview rule.\n0.120.3\nJuly 20, 2023\nRule Changes\nReduced false positives for the following rules:\nConnection to IPFS Network Detected\nPacket socket created in container\nThe docker client is executed in a container\nLaunch Privileged Container\nUpdated the IoCs Ruleset with new findings.\n0.120.2\nJuly 18, 2023\nRule Changes\nReduced false positives for the following rules:\nRead Shell Configuration File\nRead sensitive file untrusted\nRead ssh information\nWrite below monitored dir\nAdded exception for the following rules:\nSuspicious Domain Contacted\nConnection to IPFS Network Detected\nImproved performance for Write below monitored dir\nUpdated the IoCs Ruleset with new findings.\n0.120.1\nJuly 17, 2023\nRule Changes\nReduced false positives for the following rules:\nWrite below etc\nThe docker client is executed in a container\nChange thread namespace\nPacket socket created in container\nPossible Backdoor using BPF\nAWS SSM Agent File Write\nUpdated the IoCs Ruleset with new findings.\n0.119.4\nJuly 13, 2023\nRule Changes\nReduced false positives for the following rules:\nAWS SSM Agent File Write\nPossible Backdoor using BPF\nChange thread namespace\nImproved performance for the following rules:\nShell binaries opening connections\nDrop and execute new binary in container\nUpdated the IoCs Ruleset with new findings.\n0.119.3\nJuly 12, 2023\nRule Changes\nReduced false positives for the following rules:\nPossible Backdoor using BPF\nPacket socket created in container\nChange thread namespace\nTerminal shell in container\neBPF Program Loaded into Kernel\nWrite below root\nImproved performance for the following rules:\nDump memory for credentials\nLastlog Files Cleared\nDiamorphine Rootkit Activity Updated the IoCs Ruleset with new findings.\nIntroduced retries for intermittent HTTP errors and improved logs.\n0.119.2\nJuly 11, 2023\nRule Changes\nReduced false positives for the following rules:\nPossible Backdoor using BPF\nNon sudo setuid\nRun shell untrusted\nFind GCP Credentials\nChange thread namespace\nImproved performance for the following rules:\nUnprivileged Delegation of Page Faults Handling to a Userspace Process\nWrite below rpm database\nDB program spawned process Delete or rename shell history Updated the IoCs Ruleset with new findings.\n0.119.1\nJuly 10, 2023\nRule Changes\nReduced false positives for the following rules:\nRedirect STDOUT/STDIN to Network Connection in Container\nWrite below etc\nPossible Backdoor using BPF Excluded local IPv6 from macros.\nImproved performance for the following rules:\nRead sensitive file trusted after startup\nWrite below etc\nSystem procs network activity Read sensitive file untrusted AWS SSM Agent Activity Added the following rules:\nEC2 Instance Connect System Access\nAWS SSM Agent File Write Removing MFA from Admin in Okta\nDownload and launch remote file copy tools in container\nFind GCP Credentials\nFind Azure Credentials\nUpdated the IoCs Ruleset with new findings.\nImproved condition for the following rule:\nKernel startup modules changed\nDefault Policy Changes\nAdded the following rules:\nEC2 Instance Connect System Access\nAWS SSM Agent File Write Removing MFA from Admin in Okta\nDownload and launch remote file copy tools in container\nFind GCP Credentials\nFind Azure Credentials\n0.119.0\nJuly 07, 2023\nRule Changes\nReduced false positives for the following rules:\nThe docker client is executed in a container\nSearch Private Keys and Passwords\nUpdated the IoCs Ruleset with new findings.\nImproved the network_tool_binaries list.\n0.118.3\nJuly 06, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Remote File Copy Tools in Container\nChange thread namespace rule\nSearch Private Keys or Passwords Packet socket created in container Updated the IoCs Ruleset with new findings.\n0.118.2\nJuly 05, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Remote File Copy Tools in Container\nPacket socket created in container\neBPF Program Loaded into Kernel Launch Sensitive Mount Containe Updated the IoCs Ruleset with new findings.\nFix exceptions for the AWS SSM Agent Activity rule.\n0.118.1\nJune 30, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Privileged Container\nLaunch Root User Container\nDetection bypass by symlinked files Launch Ingress Remote File Copy Tools in Container Possible Backdoor using BPF\nUpdated the IoCs Ruleset with new findings.\n0.117.8\nJune 28, 2023\nRule Changes\nReduced false positives for the following rules:\nDB program spawned process\nLaunch Sensitive Mount Container\nLaunch Root User Container Updated the IoCs Ruleset with new findings.\nImproved the falco_sensitive_mount_imageslist.\nAdded preview structure for rules.\nDefault Policy Changes\nAdded preview structure for rules.\n0.117.7\nJune 26, 2023\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nRedirect STDOUT/STDIN to Network Connection in Host\nLaunch Sensitive Mount Containe DB program spawned processt Read ssh information Non sudo Setuid Updated the IoCs Ruleset with new findings.\nImproved the process_name_exists macro.\n0.117.6\nJune 23, 2023\nRule Changes\nReduced false positives for the following rules:\nTerminal shell in container\nLaunch Sensitive Mount Container\nModify binary dirs Set Setuid or Setgid bit Updated the IoCs Ruleset with new findings.\n0.117.5\nJune 22, 2023\nRule Changes\nReduced false positives for the following rules:\nSuspicious System Service Modification\nWrite below root Change thread namespace Launch Sensitive Mount Container Updated the IoCs Ruleset with new findings.\nImproved performance for the Contact EC2 Instance Metadata Service From Container and Write below binary dir rules.\n0.117.4\nJune 21, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Remote File Copy Tools in Container\nLaunch Sensitive Mount Container\nLaunch Root User Container Updated the IoCs Ruleset with new findings.\n0.117.3\nJune 19, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Ingress Remote File Copy Tools in Container\nAWS SSM Agent Activity Read Shell Configuration File Write below rpm database Updated the IoCs Ruleset with new findings.\nImproved the falco_privileged_images list.\n0.117.2\nJune 20, 2023\nRule Changes\nReduced false positives for the following rules:\nWrite below etc\nAWS SSM Agent Activity Suspicious Operations with Firewallse Non sudo setuid Updated the IoCs Ruleset with new findings.\nFixed exception value.\nRemoved append fields from rules and macros.\n0.117.1\nJune 09, 2023\nRule Changes\nRemoved duplicate tags in rules.\n0.116.5\nJune 09, 2023\nRule Changes\nReduced false positives for the following rules:\nJava Process Class File Download\nSet Setuid or Setgid bit User mgmt binaries Updated the IoCs Ruleset with new findings.\n0.116.4\nJune 08, 2023\nRule Changes\nReduced false positives for the following rules:\nRedirect STDOUT/STDIN to Network Connection in Container\nWrite below etc Improved output for The docker client is executed in a container rule.\nUpdated the IoCs Ruleset with new findings.\n0.116.3\nJune 07, 2023\nRule Changes\nRemoved the Okta 5 minute rules.\nImproved the output for the Java Process Class File Downloadrule.\nDefault Policy Changes\nRemoved the Okta 5 minute rules.\n0.116.2\nMay 31, 2023\nRule Changes\nUpdated the IoCs Ruleset with new findings.\nAdded exception for the following rules:\nLaunch Privileged Container\nLaunch Excessively Capable Container Launch Sensitive Mount Container 0.115.1\nMay 30, 2023\nRule Changes\nReduced false positives for the Execution from /tm rule.\nAdded the following rules:\nK8s Ingress Deleted\nK8s Ingress Created/Modified AWS EC2 Instance Connect/SSH Public Key Uploaded\nAdmin permission has been assigned to a group in Okta\nUpdated the IoCs Ruleset with new findings.\nImproved condition for the following rules:\nFind AWS Credentials\nOkta CAPTCHA Settings Updated Search Private Keys or Passwords Default Policy Changes\nAdded the following rules:\nK8s Ingress Deleted\nK8s Ingress Created/Modified AWS EC2 Instance Connect/SSH Public Key Uploaded\nAdmin permission has been assigned to a group in Okta\n0.115.0\nMay 18, 2023\nRule Changes\nAdded the Okta CAPTCHA Settings Updated rule.\nReduced false positives for the following rules:\nRead ssh information\nWrite below root Run shell untrusted\nUpdated the IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the Okta CAPTCHA Settings Updated rule.\n0.114.1\nMay 17, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Privileged Container\nRead sensitive file untrusted Read Shell Configuration File eBPF Program Loaded into Kernel\nWrite below etc\nLaunch Root User Container Create files below dev Non sudo setuid Added the following rules:\nDrop and execute new binary in container\nGCP Cloud SQL Data Exfiltration GCP Create Service Account\nGCP Create or Modify Compute SSH Key GCP Default Service Account Activity\nDirectory traversal monitored file read Detection bypass by symlinked files Updated the IoCs Ruleset with new findings.\nIntroduced v16 ruleset.\nImproved condition for the OpenSSL File Read or Write rule.\nImproved detection for the Suspicious System Service Modification rule.\nDefault Policy Changes\nAdded the following rules:\nDrop and execute new binary in container\nGCP Cloud SQL Data Exfiltration GCP Create Service Account\nGCP Create or Modify Compute SSH Key GCP Default Service Account Activity\nDirectory traversal monitored file read Detection bypass by symlinked files 0.114.0\nMay 10, 2023\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel\nUser mgmt binaries Write below etc\nExecution from /tmp\nNon sudo setuid\nUpdated the IoCs Ruleset with new findings.\n0.113.2\nMay 09, 2023\nRule Changes\nReduced false positives for the following rules:\nShell binaries opening connections\nExecution from /tmp 0.113.1\nMay 08, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Remote File Copy Tools in Container\nRead Shell Configuration File Write below etc Set Setuid or Setgid bit\nChange thread namespace\nWrite below rpm database Launch Privileged Container eBPF Program Loaded into Kernel Set Setuid or Setgid bit Updated the IoCs Ruleset with new findings.\nImproved condition for the following rules:\nExecution from /tmp\nRedirect STDOUT/STDIN to Network Connection in Host Added the following rules:\nShell binaries opening connections\nAWS Attach IAM Policy to Role Added exceptions for the Ingress Object without TLS Certificate Created rule.\nDefault Policy Changes\nAdded the following rules:\nShell binaries opening connections\nAWS Attach IAM Policy to Role 0.113.0\nMay 05, 2023\nRule Changes\nReduced false positives for the following rules:\nSet Setuid or Setgid bit\nNon sudo setuid Updated the Sysdig Mitre Attack mapper.\nUpdated the IoCs Ruleset with new findings.\n0.112.3\nMay 04, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Suspicious Network Tool in Container\nWrite below rpm database Launch Remote File Copy Tools in Container\nUpdated the IoCs Ruleset with new findings.\n0.112.2\nMay 01, 2023\nRule Changes\nReduced false positives for the following rules:\nWrite below etc\nRead sensitive file untrusted Kernel startup modules changed Launch Privileged Container\nMount Launched in Privileged Container\nLaunch Ingress Remote File Copy Tools in Container Non sudo setuid Updated the IoCs Ruleset with new findings.\nEnable theJava Process Class File Download rule by default.\nDefault Policy Changes\nEnable the following rules by default:\nJava Process Class File Download Kernel startup modules changed 0.112.0\nApril 26, 2023\nRule Changes\nReduced false positives for the following rules:\nRun shell untrusted\neBPF Program Loaded into Kernel Launch Sensitive Mount Container Launch Package Management Process in Container\nLaunch Root User Container\nUpdated the following tags:\nAWS MITRE ATT\u0026CK\nAzure MITRE ATT\u0026CK GCP MITRE ATT\u0026CK Updated the IoCs Ruleset with new findings.\nImproved the MITRE ATT\u0026CK tags.\nImproved the sysdig_commercial_images list.\nDefault Policy Changes\nUpdated policy for the following rules:\nPacket socket created in container\nCreate Hardlink Over Sensitive Files 0.111.0\nApril 17, 2023\nRule Changes\nReduced false positives for the following rules:\nNon sudo setuid\nWrite below etc Redirect STDOUT/STDIN to Network Connection in Container Read ssh information\nClear Log Activities\nModify Shell Configuration File\nSystem ClusterRole Modified/Deleted Updated policy for the following rules:\nUnprivileged Delegation of Page Faults Handling to a Userspace Process\nDetect release_agent File Container Escapes Updated IoCs Ruleset with new findings.\nImproved output for the Launch Excessively Capable Container rule.\nAdded the Kernel startup modules changed rule.\nDefault Policy Changes\nAdded the Kernel startup modules changed rule.\nUpdated policy for the following rules:\nUnprivileged Delegation of Page Faults Handling to a Userspace Process\nDetect release_agent File Container Escapes Register Domain\nDisable Security Hub 0.110.0\nApril 11, 2023\nRule Changes\nReduced false positives for the following rules:\nLaunch Package Management Process in Container\nRead sensitive file untrusted Write below etc Netcat Remote Code Execution in Container\nContainer Run as Root User\nSet Setuid or Setgid bit\nMount Launched in Privileged Container Launch Root User Container Non sudo setuid\nAdded tags for the following rules:\nDetect release_agent File Container Escapes\nUnprivileged Delegation of Page Faults Handling to a Userspace Process Launch Excessively Capable Container\nUpdated IoCs Ruleset with new findings.\nMoved malicious_download_tools in Suspicious Network tools rules\nImproved list network_tool_binaries rule.\nFixed Set Setuid or Setgid bit tag.\nDefault Policy Changes\nUpdated policy for the following rules:\nSecurity Hub Disassociate From Master Account\nSecurity Hub Delete Members Security Hub Disassociate Members 0.109.0\nApril 07, 2023\nRule Changes\nReduced false positives for the following rules:\nSet Setuid or Setgid bit\nSuspicious Cron Modification Disallowed K8s User The docker client is executed in a container\nLaunch Package Management Process in Container\nClear Log Activities\nLaunch Package Management Process in Container Write below etc Read sensitive file untrusted\nPTRACE attached to process\nLaunch Excessively Capable Container\neBPF Program Loaded into Kernel Read sensitive file untrusted Non sudo setuid\nWrite below root\nRead sensitive file untrusted Write below rpm database\nLaunch Sensitive Mount Container\nLaunch Root User in Container\nAdded the following rules:\nDetect release_agent File Container Escapes\nJava Process Class File Download Launch Excessively Capable Container\nUnprivileged Delegation of Page Faults Handling to a Userspace Process Updated IoCs Ruleset with new findings.\nAdded Falco rules versioning support.\nAdded an exception for the Outbound Connection to C2 Servers rule.\nDefault Policy Changes\nAdded the following rules:\nDetect release_agent File Container Escapes\nJava Process Class File Download Launch Excessively Capable Container\nUnprivileged Delegation of Page Faults Handling to a Userspace Process Updated policy for the following rules:\nGuard Duty Disassociate Members\nGuard Duty Disassociate from Master Account Guard Duty Delete Members Added Falco rules versioning support.\nRemoved the following rules from policies:\nLaunch Disallowed Container\nInterpreted procs inbound network activity Interpreted procs outbound network activity\n0.108.0\nMarch 13, 2023\nRule Changes\nReduced false positives for the following rules:\nClear Log Activities\nLaunch Package Management Process in Container Container Run as Root User Launch Remote File Copy Tools in Container\nLaunch Root User Container\nImproved condition for the following rules:\nLaunch Ingress Remote File Copy Tools in Container\nModify Timestamp attribute in File Updated IoCs Ruleset with new findings.\nDefault Policy Changes\nUpdated policy for the following rules:\nOpenSSL File Read or Write\nCloudTrail Logging Disabled Disable GuardDuty 0.106.0\nMarch 07, 2023\nRule Changes\nAdded the following rules:\nCreate Bucket Delete Bucket Improved the output for the following rules:\nRead Shell Configuration File\nSet Setuid or Setgid bit Launch Root User Container Updated the MITRE, GCP MITRE, and AWS MITRE tags.\nImproved condition for the Tampering with Security Software in Container rule.\nReduced false positives for the following rules:\nThe docker client is executed in a container Launch Privileged Container Write below root Schedule Cron Jobs\nSuspicious Cron Modification Launch Remote File Copy Tools in Container Launch Suspicious Network Tool on Host System procs activity\nModify Shell Configuration File\nWrite below etc\nLaunch Sensitive Mount Container\nMount Launched in Privileged Container\nPTRACE attached to process\nUpdated Kubernetes image registry domains.\nImproved the falco_privileged_imageslist.\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nCreate Bucket Delete Bucket Updated the policy for the following rules:\nDeactivate MFA for Root User\nCloudTrail Trail Deleted 0.105.0\nFebruary 28, 2023\nRule Changes\nAdded the following rules:\nCreate Hardlink Over Sensitive Files Azure Storage Account Created Azure Storage Account Deleted GCP Create Project GCP Create Compute VM Instance GCP Enable API Reduced false positives for the following rules:\nSuspicious Operations with Firewalls Linux Kernel Module Injection Detected PTRACE attached to process Read sensitive file untrusted Improved condition for the following rules:\nExecution of binary using ld-linux Mount Launched in Privileged Container Updated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nCreate Hardlink Over Sensitive Files Azure Storage Account Created Azure Storage Account Deleted GCP Create Project GCP Create Compute VM Instance GCP Enable API 0.104.1\nFebruary 24, 2023\nRule Changes\nImproved output for the Modify Timestamp attribute in File rule. Reduced false positives for the following rules:\nLinux Kernel Module Injection Detected Launch Privileged Container Reconnaissance attempt to find SUID binaries Updated IoCs Ruleset with new findings.\n0.103.1\nFebruary 23, 2023\nRule Changes\nAdded the following rules:\nModify Timestamp attribute in File Launch Code Compiler Tool in Container Put Bucket ACL for AllUsers Reduced false positives for the following rules:\nLaunch Package Management Process in Container PTRACE anti-debug attempt Improved condition for the following rule: Put Bucket Lifecycle\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nModify Timestamp attribute in File Launch Code Compiler Tool in Container Put Bucket ACL for AllUsers Updated policy for the following rules:\nLaunch Code Compiler Tool in Container Connection to IPFS Network Detected Detect outbound connections to Proxy/VPN 0.103.0\nFebruary 14, 2023\nRule Changes\nAdded the following rules:\nUser Management Event Detected Users Group Management Event Detected OpenSSL File Read or Write Reduced false positives for the following rules:\nModify ld.so preload Clear Log Activities Read sensitive file untrusted Read Shell Configuration File Improved condition for the following rules:\nDelete Bash History Delete or rename shell history Detect malicious cmdlines Improved the sensitive_kernel_parameter_fileslist.\nUpdated IoCs Ruleset with new findings.\nAdded an exception for the OpenSSL File Read or Write rule.\nDefault Policy Changes\nAdded the following rules:\nUser Management Event Detected Users Group Management Event Detected OpenSSL File Read or Write Update policies for SuspiciousOpenSSL Shared Object Loaded rule.\n0.102.1\nFebruary 08, 2023\nRule Changes\nAdded the following list: Add list security_processes\nImproved the following list: network_tool_binaries\nReduced false positives for the following rules:\nContact EC2 Instance Metadata Service From Container\nRun shell untrusted System procs network activity Set Setuid or Setgid bit\neBPF Program Loaded into Kernel\nImproved the condition for the following rule: Detect reconnaissance scripts\nUpdated IoCs Ruleset with new findings.\n0.101.1\nJanuary 26, 2023\nRule Changes\nAdded the following rules:\nK8s CronJob Deleted\nK8s CronJob Created/Modified Read Environment Variable from /proc files in Container Suspicious OpenSSL Shared Object Loaded\nReduced false positives for the following rules:\nRun shell untrusted Find AWS Credentials PTRACE attached to process Clear Log Activities\nNon sudo setuid\nRedirect STDOUT/STDIN to Network Connection in Host\nImproved condition for the following rule: GPG Key Reconnaissance\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules:\nK8s CronJob Deleted\nK8s CronJob Created/Modified Read Environment Variable from /proc files in Container Suspicious OpenSSL Shared Object Loaded\n0.100.2\nJanuary 20, 2023\nRule Changes\nAdded the following rules:\nModify Security Group Rule Allowing Ingress Open to the World Connection to IPFS Network Detected Improved condition for the following rules:\nCreate Security Group Rule Allowing Ingress Open to the World Create a Network ACL Entry Allowing Ingress Open to the World Detect reconnaissance scripts Lastlog Files Cleared Launch Remote File Copy Tools in Container Put Bucket Lifecycle Delete or rename shell history Added exception for the following rules:\nPut Bucket Lifecycle Update Assume Role Policy Updated IoCs Ruleset with new findings.\nReduced false positives for the following rule Find AWS Credentials rule.\nDefault Policy Changes\nAdded the following rules:\nModify Security Group Rule Allowing Ingress Open to the World Connection to IPFS Network Detected 0.99.0\nJanuary 09, 2023\nRule Changes\nReduced false positives for the Container Run as Root User rule.\nImproved condition for the Suspicious Operations with Firewalls rule.\nAdded the following rules: K8s Networkpolicy Deleted Modify Security Group K8s Networkpolicy Created/modified AWS SSM Send Command Added tags to the K8s Networkpolicy Deleted rule. Added exceptions for the following: Delete Organization Config Rule Delete Cluster Elasticsearch Domain Creation without Encryption at Rest ECR Image Pushed Put Remediation Configurations Delete Configuration Aggregator Put Organization Config Rule Put Organization Conformance Pack Stop Configuration Recorder Delete Organization Conformance Pack ECS Service Created ECS Service Deleted Terminal Shell in ECS Container ECS Task Run or Started ECS Service Task Definition Updated ECS Task Stopped Create HTTP Target Group without SSL Elasticsearch Domain Creation without VPC Run Instances CloudTrail Trail Created Create Security Group Rule Allowing SSH Ingress Guard Duty Disassociate from Master Account Guard Duty Delete Members Disable GuardDuty Delete Detector Create Access Key for Root User Guard Duty Disassociate Members Stop Monitoring Members Password Recovery Requested Deactivate Hardware MFA for Root User Add AWS User to Group Attach Administrator Policy Attach IAM Policy to User Deactivate MFA for Root User Create Group Create IAM Policy that Allows All Create Access Key for User Deactivate Virtual MFA for Root User Delete Virtual MFA for Root User Create AWS user (SSO) Create AWS user Delete AWS user (SSO) Deactivate MFA for User Access Delete Group Put IAM Inline Policy to User Delete AWS user Remove AWS User from Group Update Account Password Policy Not Expiring Update Account Password Policy Expiring in More Than 90 Days Update Account Password Policy Not Preventing Reuse of Last 24 Passwords Update Account Password Policy Not Preventing Reuse of Last 4 Passwords Update Account Password Policy Not Requiring 14 Characters Update Account Password Policy Not Requiring 7 Characters Update Account Password Policy Not Requiring Lowercase Update Account Password Policy Not Requiring Number Update Account Password Policy Not Requiring Symbol Update Account Password Policy Not Requiring Uppercase Replace Route Modify Image Attribute Modify Snapshot Attribute Revoke Security Group Egress Revoke Security Group Igress Run Instances in Non-approved Region Create Internet-facing AWS Public Facing Load Balancer Delete Listener Modify Listener Disable EBS Encryption by Default Contact EC2 Instance Metadata Service From Container EC2 Serial Console Access Enabled Make EBS Snapshot Public Get Password Data Default Policy Changes\nAdded the following rules: K8s Networkpolicy Deleted Modify Security Group K8s Networkpolicy Created/modified AWS SSM Send Command 0.98.2\nJanuary 04, 2023\nRule Changes\nReduced false positives for the following rules:\naws_latest_runtimes Read sensitive file untrusted Read Shell Configuration File Updated IoCs Ruleset with new findings.\nAdded exception for the DB program spawned process rule.\nImproved output for the Suspicious System Service Modification rule.\n0.98.0\n","url":"https://docs.sysdig.com/en/release-notes/falco-rules-changelog/2023-archive/"},{"id":827,"title":"Vulnerability Management Glossary","content":"Key Vulnerability Management TerminologyA cybersecurity vulnerability is a flaw in a computer system that enables an adversary to gain direct access to a network or system to compromise security and inflict harm.\nCommon Vulnerability Exposures (CVE)Common Vulnerabilities and Exposures (CVE) is the database of such known cybersecurity vulnerabilities and exposures.\nYou can view the following information for all the asset types in all the vulnerability management stages:\nThe severity level reported by National Vulnerability Database The package where vulnerability was found The directory path to the package The version in which the vulnerability was fixed Common Vulnerability Scoring System (CVSS)The Common Vulnerability Scoring System (CVSS) is used to assess the severity of information security vulnerabilities. Each entry in the CVE database is assigned a corresponding CVSS score, which quantifies the severity of the vulnerability.\nYou can view the following information for all the asset types in all the vulnerability management stages:\nThe sources selected for score calculation.\nFor example, National Vulnerability Database\nThe CVSS Score and version\nThe date when the vulnerability was discovered.\nCISA Known Exploited Vulnerabilities (KEV)The Known Exploited Vulnerabilities (KEV) Catalog maintained by CISA (Cybersecurity and infrastructure Security Agency). It is the list of software flaws that have already been exploited in the real-world.\nYou can view the following information for all the asset types in all the vulnerability management stages:\nThe date when the vulnerability was added to the KEV catalog The deadline for when the vulnerability should have a fix If the vulnerability has been used in any Ransomware campaigns ExploitAn exploit is a software program created to identify and exploit security flaws or vulnerabilities present in a system.\nYou can view the following information for all the asset types in all the vulnerability management stages:\nLink to the existing exploit PoC or source code The date when the exploit was disclosed. Exploit Prediction Scoring System (EPSS)EPSS (Exploit Prediction Scoring System) is a data-driven metric developed by FIRST.org that estimates the likelihood of a vulnerability being exploited in the wild. EPSS scoring includes:\nEPSS Score: Represents the probability (from 0 to 1) that a specific vulnerability will be exploited, allowing prioritization based on real-world risk. For example, a vulnerability with an EPSS score of 0.75 has a 75% probability of exploitation based on current threat data.\nPercentile: Shows how the vulnerability ranks relative to others, offering context on its exploitation likelihood compared to the broader vulnerability landscape. For instance, if a vulnerability’s score places it in the 85th percentile, it ranks in the top 15% of vulnerabilities likely to be exploited, signaling it as a higher priority.\nTimestamp: Indicates when the score was last updated, ensuring users are working with the most recent exploitability data for informed decision-making.\nCalculation Context: EPSS Score Calculation: Scores are generated using machine learning models that analyze historical exploitation data, exploit code availability, and other threat intelligence sources. Percentile Calculation: Percentiles are determined by comparing this vulnerability’s score to the distribution of all vulnerability scores, clarifying its rank in the current risk landscape. ","url":"https://docs.sysdig.com/en/sysdig-secure/vulnerability-data/"},{"id":828,"title":"Falco Changelog 2022","content":" Commit Date\nRule Notes\nVersion of the Falco Rules Installer (On-Prem)\nDecember 04, 2022\nRule Changes\nReduced false positives for the following rules:\neBPF Program Loaded into Kernel Non sudo setuid Read SSH information Read Shell Configuration File Write below etc Reconnaissance attempt to find SUID binaries Suspicious Domain Contacted Updated IoCs Ruleset with new findings.\nImproved detection for the Non sudo setuid rule.\nAdded the following rule: Detect cloned process by PRoot Default Policy Changes\nAdded the Detect cloned process by PRoot rule.\n0.96.0\nDecember 01, 2022\nRule Changes\nDisabled the Create Hidden Files or Directories rule.\n0.94.2\nNovember 29, 2022\nRule Changes\nImproved output for the Suspicious Cron Modification rule.\nReduced false positive for the Read SSH information rule. Updated IoCs Ruleset with new findings.\nEnabled the Create Hidden Files or Directoriesrule.\nAdded the Create/modify EKS serviceaccount boundrule to the AWS Identity and Access Management (IAM) role.\nAdded the Suspicious Domain Contactedrule.\nDefault Policy Changes\nAdded the Suspicious Domain Contactedrule.\nAdded the Create/modify EKS serviceaccount boundrule to the AWS IAM role.\n0.94.0\nNovember 22, 2022\nRule Changes\nReduced false positives for the following rules:\nPrivileged Shell Spawned Inside Container\nClear Log Activities Read ssh information Search Private Keys or Passwords Launch Suspicious Network Tool in Container Container Run as Root User Change Thread Namespace Read Shell Configuration File Improved tags for the eBPF Program Loaded into Kernelrule. Updated IoCs Ruleset with new findings.\nImproved detection for the Non sudo setuid rule.\nAdded the following rules: Mutated Pod Detected Configmap aws-auth changed Default Policy Changes\nAdded the following rules: Mutated Pod Detected Configmap aws-auth changed 0.93.0\nNovember 10, 2022\nRule Changes\nReduced false positives for the following rules:\nSuspicious Kernel Parameter Modification The docker client is executed in a container Mount Launched in Privileged Container Reconnaissance attempt to find SUID binaries PTRACE attached to process Linux Kernel Module Injection Detected Updated IoCs Ruleset with new findings.\nImproved detection for the Non sudo setuid rule.\nAdded the following rules: Redirect STDOUT/STDIN to Network Connection in Host Lastlog files cleared Default Policy Changes\nAdded the following rules: Redirect STDOUT/STDIN to Network Connection in Host Lastlog files cleared Move the Unexpected Connection from legitimate Process/Port rule to Default Policy 0.92.0\nOctober 19, 2022\nRule Changes\nRenamed lists, macros, and rules for Falco Cloud.\nAdded the Unexpected Connection from legitimate Process/Port rule. Updated IoCs Ruleset with new findings.\nEdited the output for the Reconnaissance attempt to find SUID binaries rule.\nDefault Policy Changes\nRenamed lists, macros, and rules for Falco Cloud.\nAdded the Unexpected Connection from legitimate Process/Port rule. 0.91.0\nOctober 14, 2022\nRule Changes\nUpdated the sensitive_kernel_parameter_files list to detect changes on the ptrace_scope file.\nAdded the Diamorphine Rootkit Activity rule. Updated IoCs Ruleset with new findings.\nReduced false positives in the Dump memory for credentials rule.\nDefault Policy Changes\nAdded the Diamorphine Rootkit Activity rule. Reduced false positives in the Dump memory for credentials rule.\n0.90.0\nOctober 07, 2022\nRule Changes\nTuning the Dump memory for credentials on rule.\nAdded the following rules:\nkill malicious process detect dump memory for credentials Updated IoCs Ruleset with new findings.\nUpdated Cloud Mitre tags.\nReduced false positives in Falco Rules.\nAdded new ruless:\nDump memory for credentials Kill known malicious process Use glob in the user_ssh_directory macro and remove openat2 from conditions. Added an exception to the AWS Command Executed by Untrusted User rule.\nChanged exception in the Change Resource Record Sets rule.\nChanged the allowed_k8s_users list.\nDefault Policy Changes\nTuned the Dump memory for credentials rule.\nAdded new rules:\nDump memory for credentials Kill known malicious process 0.89.0\nSeptember 27, 2022\nRule Changes\nIncreased IoCs and added additional exceptions.\nDisabled Simple Storage Service (S3) versioning.\nDefault Policy Changes\nDisabled S3 versioning\n0.88.0\nSeptember 23, 2022\nRule Changes\nIncreased IoCs and added additional exceptions.\nAdded exclusions to reduce false positives.\nAdding additional parameters to sensitive_kernel_parameter_files list.\n0.87.0\nSeptember 09, 2022\nRule Changes\nAdded exception to reduce false positives in the sysdig_commercial_imagesmacro.\nUpdated IoCs Ruleset with new findings.\n0.86.0\nSeptember 08, 2022\nRule Changes\nAdded additional exceptions to aid in addressing false positives: Suspicious Kernel Parameter Modification.\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nRemoved the following rules from default policies:Scripting Language Execution below dev.\n0.85.0\nAugust 24, 2022\nRule Changes\nNew rules:Share RDS Snapshot with Foreign Account Rule tuning for the following:\nPTRACE anti-debug attempt\nSuspicious Cron Modification\nSuspicious Java Child Processes\nCreate Symlink Over Sensitive Files\nNetcat Remote Code Execution in Container eBPF Program Loaded into Kernel Updated IoCs Ruleset with new findings. 0.83.0\nAugust 19, 2022\nRule Changes\nFixed the output for two PTRACE rules. Added additional conditions to improve detections for Delete/rename Bash History.\nEnable the do_unexpected_udp_checkmacro.\nAdded the new rule: GCP Firewall Remote Access from Internet. It detects remote access ports allowed through the firewall from the public internet (0.0.0.0/0). Auto-Tuner Exception Updates Added additional exceptions for Privileged Shell Inside Container.\nAdded Azure core image to the exception, Suspicious Cron Modification.\n0.82.0\nAug 11, 2022\nRule Changes\nAdded Azure rule: Azure RDP Access Is Allowed from The Internet\nUpdated auto-tuner exceptions to reduce excessive noise:\nChange Resource Record Sets (AWS)\nCreate Hidden Files or Directories\nDescribe Instances (AWS)\nGCP Delete Compute VM Instance\nGCP Operation by a Non-corporate Account\nList Buckets (AWS)\nNon sudo setuid\nRoot User Executing AWS Command Run shell untrusted The docker client is executed in a container User mgmt binaries Updated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded new rules: Azure RDP Access Is Allowed from The Internet\n0.81.2\nAug 05, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positives:\nLinux Kernel Module Injection Detected eBPF Program Loaded into Kernel Privileged Shell Spawned Inside Container\nAdded the following new rules:\nGPG Key Reconnaissance Create Access Key for User Extended the condition of the following rules:\nBase64-encoded Python Script Execution nsenter Container Escape\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded new rules to default policies.\nnsenter Container Escape\nGPG Key Reconnaissance\nCreate Access Key for User\n0.80.1\nJuly 26, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positives:\nNon sudo setuid\nSet Setuid or Setgid bit eBPF Program Loaded into Kernel\nAdded the following new rules:\nPTRACE anti-debug attempt\nPTRACE attached to process\nDetect reconnaissance scripts\nDetect malicious cmdlines\nGCP Create DNS Record\nGCP Create DNS Zone\nGCP Delete DNS Record\nGCP Update DNS Record\nGCP Update DNS Zone\nGCP Cloud Armor Blocked Connection\nGCP Cloud IDS Alert\nDelete AWS user (SSO)\nUpdated the following rule: Reconnaissance attempt to find SUID binaries Updated the following lists: falco_privileged_images\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded new rules to default policies.\n0.79.2\nJuly 15, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positives:\nNon sudo setuid\nSet Setuid or Setgid bit eBPF Program Loaded into Kernel\nAdded the following new rules:\nDetect curl Using Socks Proxy\nCreate AWS user (SSO)\nGCP Delete VPN\nGCP App Engine Firewall Rule Created\nGCP Compute Firewall Rule Created\nGCP Create VPN\nGCP Sensitive Role Added to User\nAdded additional exceptions to:\nRead sensitive file untrusted\nRun shell untrusted\nNon sudo setuid\nClear Log Activities\nExecution of binary using ld-linux\neBPF Program Loaded into Kernel\nTerminal shell in container\nThe docker client is executed in a container\nAdded the Detect curl Using Socks Proxy rule to IoCs Malware Activity and Sysdig Runtime Threat Detection policies\nAdded Create AWS user (SSO) to the Sysdig AWS Activity Logs policy.\nAdded GCP Delete VPN and GCP Sensitive Role Added to the User rules to Sysdig GCP Notable Events policy.\nAdded the GCP App Engine Firewall Rule Created, GCP Compute Firewall Rule Created, and GCP Create VPN rules to the Sysdig GCP Activity Logs policy.\nSplit AWS rules into individual files and moved lists out of individual files and into its own file at the top of the output aws_cloudtrail.yaml.\nFixed tag in the Delete Cluster rule.\nUpdated IoCs Ruleset with new findings.\n0.78.0\nJuly 08, 2022\nRule Changes\nRestored the following missing rule: nsenter Container Escape Cleaned up the following duplicate macro: falco_sensitive_mount_containers Adjusted the following eBPF rule: eBPF Program Loaded into Kernel\nUpdated IoCs Ruleset with new findings.\nUpdated all the Cloudtrail rules to add ARNs to output. Default Policy Changes\nModified to work with both old default_policies and managed default_policies.\n0.77.0\nJuly 01, 2022\nRule Changes\nAdded Miner IP Pool Threat Intelligence: Detect outbound connections to common miner pool ports\n0.76.1\nJune 30, 2022\nRule Changes\nAdded additional exceptions : Linux Kernel Module Injection Detected Created the following new rules:\nGCP App Engine Firewall Rule Deleted GCP App Engine Firewall Rule Updated\nGCP Create Cloud Function v2 Not Using Latest Runtime GCP Create Cloud Function v2 GCP Compute Firewall Rule Deleted GCP Compute Firewall Rule Updated GCP Delete Compute VM Instance GCP Update Cloud Function v2 Malicious Environment Variable in Spawned Process nsenter Container Escape Updated the following GCP rules:\nGCP Create Cloud Function Not Using Latest Runtime GCP Create Cloud Function GCP Create DLP Job GCP Delete DLP Job GCP Paused DLP Job GCP Suspicious IP Inbound Request GCP Update Cloud Function GCP Updated DLP Job Added CIS tag to the rules related to Center for Internet Security (CIS) Docker Security Benchmark controls:\nContainer Run as Root User Disallowed SSH Connection Launch Privileged Container Launch Root User Container Launch Sensitive Mount Container Mount Launched in Privileged Container Privileged Shell Spawned Inside Container Reconnaissance attempt to find SUID binaries The docker client is executed in a container Write below root\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rules to the default policy:\nGCP App Engine Firewall Rule Deleted GCP Compute Firewall Rule Deleted Malicious Environment Variable in Spawned Process nsenter Container Escape 0.76.0\nJune 24, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positives:\nCreate Symlink Over Sensitive Files Execution of binary using ld-linux Run shell untrusted Modified the following macros:\ntruncate_shell_history\nmodify_shell_history\nExtended the condition of the rule, Detect crypto miners using the Stratum protocol, to improve detection capabilites.\nNew rules created:\nLaunch malicious container image\nGCP Suspicious IP Inbound Request\nGCP Allow Public Access to Bucket\nGCP KMS Schedule Key Deletion\nGCP Create DLP Job\nGCP Delete DLP Job\nGCP Update DLP Job\nGCP Paused DLP Job\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following rule to the default policy, IoCs Malware Activity: Launch malicious container image Added the following rules to the default policy, Sysdig GCP Best Practices:\nGCP Suspicious IP Inbound Request\nGCP Allow Public Access to Bucket\nGCP KMS Schedule Key Deletion\nGCP Delete DLP Job\nGCP Paused DLP Job\n0.75.0\nJune 17, 2022\nRule Changes\nAdded the following new rules:\nAWS Suspicious IP Inbound Request eBPF Program Loaded into Kernel Modified the following rules:\nSymlink over Sensitive Files Container Drift rules (with new exceptions)\nUpdated the macro: sysdig_commercial_images. It now contains two new Kubernetes Security Posture Management (KSPM) images.\nAdded the new macro ti_anon_ips for Tor source IP addresses.\nUpdated IoCs Ruleset with new findings. Default Policy Changes\nAdded the new rule, AWS Suspicious IP Inbound Request to the Sysdig AWS Best Practices policy.\nAdded the new rule, eBPF Program Loaded into Kernel to the Suspicious Container Activity policy. 0.74.3\nJune 03, 2022\nRule Changes\nAdded a new rule: Suspicious Java Child Processes\nUpdated the package_mgmt_procs macro to detect package management processes with Python.\nUpdated some exceptions in the rule,Change thread namespace\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the new rule, Suspicious Java Child Processes,to the IoCs Malware Activity 0.72.0\nMay 26, 2022\nRule Changes\nAdded the following new rules:\nReconnaissance attempt to find SUID binaries Suspicious Home Directory Creation Modified exceptions to reduce noise:\nChange thread namespace Contact cloud metadata service from container DB program spawned process K8s ConfigMap Created K8s ConfigMap Deleted K8s Serviceaccount Created Netcat Remote Code Execution in Container Privileged Shell Spawned Inside Container Set Setuid or Setgid bit System ClusterRole Modified/Deleted Write below monitored dir Write below root Updated IoCs Ruleset with new findings. Default Policy Changes\nAdded the following new policies:\nReconnaissance attempt to find SUID binaries Suspicious Home Directory Creation 0.70.3\nMay 20, 2022\nRule Changes\nAdded additional exceptions to the following rules to aid in addressing false positives:\nSet Setuid or Setgid bit Execution from /tmp Fixed the condition of the following rules:\nExecution from /tmp Execution from /dev/shm Updated IoCs Ruleset with new findings. 0.69.0\nMay 13, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positives: Run shell untrusted Launch Privileged Container\nContainer Run as Root User Write below root Write below rpm database\nDB program spawned process Privileged Shell Spawned Inside Container\nLaunch Suspicious Network Tool in Container\nRemove Bulk Data from Disk Set Setuid or Setgid bit\nPacket socket created in container\nExecution from /tmp Created the new rule, Possible Backdoor using BPF. This rule triggers if a process was seen attaching a Berkeley Packet Filter (BPF) filter on a network socket. This could indicate packet sniffing for use in a backdoor such as BPFDoor. Network diagnostic tools may also trigger this rule.\nCreated the new rule, Execution of binary using ld-linux. This method can be used to execute programs that do not have the exec bit set and may possibly evade detection measures. Fixed the condition of the following rules:\nWrite below binary dir Set Setuid or Setgid bit Updated IoCs Ruleset with new findings Default Policy Changes\nAdded the Possible Backdoor using BPF rule to the Notable Network Activity policy. Added the new rule, Execution of binary using ld-linux to the IoCs Malware Activity policy. 0.68.1\nMay 6, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positives:\nModify binary dirs\nRedirect STDOUT/STDIN to Network Connection in Container\nContainer Run as Root User\nExecution from /tmp\nCreated the new rule Tampering with Security Software in Container. This rule detects common techniques by threat actors to disable runtime security software.\nCreated the new rule Detect outbound connections to TOR Entry Nodes. This rule detects when clients reach the Tor network through its entry nodes. Note that this is an experimental rule and only contains a subset of Tor entry nodes. It will be improved upon in the future.\nFixed the condition of the following rule: Execution from /tmp\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nMoved the Redirect STDOUT/STDIN to Network Connection in Container rule to the Notable Container Activity default policy.\nAdded the Tampering with Security Software in Container rule to the Suspicious Container Activity default policy.\nAdded the Detect outbound connections to TOR Entry Nodes rule to the IoCs Malware Activity default policy.\n0.67.1\nApril 28, 2022\nRule Changes\nAdded a new rule file, threat_intelligence_feed.yaml , with lists and macros directly updated by theSysdig Threat Research Team. Updated the following list: sysdig_commercial_images Updated IoCs Ruleset with new findings.\nUpdated Falco rules conditions:\nExecution from /tmp Execution from /dev/shm Network Connection outside Local Subnet Added additional exceptions to aid in addressing false positives:\nExecution from /tmp\nCreate Symlink Over Sensitive Files Change thread namespace\nDB program spawned process Suspicious Cron Modification\n0.66.1\nApril 21, 2022\nRule Changes\nAdded a new AWS Cloudtrail rule: Create RDS DB Instance with Public Access Added the following Falco rules:\nBase64-encoded Shell Script Execution Execution from /dev/shm Added additional exceptions to aid in addressing false positives:\nService Account Created in Kube Namespace K8s Serviceaccount Created Modified to add a list of malicious IPs: Outbound Connection to C2 Servers\nUpdated IoCs Ruleset with new findings Default Policy Changes Added the following:\nBase64-encoded Shell Script Execution Execution from /dev/shm Moved to enabled policy: Outbound Connection to C2 Servers 0. 65.1\nApril 18, 2022\nRule Changes\nAdded additional exceptions to the following rules to aid in addressing false positives: Change thread namespace Create Symlink Over Sensitive Files\nContainer Run as Root User\nDB program spawned process\nPrivileged Shell Spawned Inside Container Run shell untrusted\nSet Setuid or Setgid bit\nWrite below etc\n0.65.0\nApril 17, 2022\nRule Changes\nAdded additional exceptions to the following rules to aid in addressing false positives: Privileged Shell Spawned Inside Container 0.64.1\nApril 15, 2022\nRule Changes\nAdded additional exceptions to the following rules to aid in addressing false positives:\nPacket socket created in container Change thread namespace\nRun shell untrusted\nContainer Run as Root User\nCreated the new rule Base64-encoded Python Script Execution. This rule detects base64-encoded Python scripts on command line arguments. Base64 can be used to encode binary data for transfer to ASCII-only command lines. Attackers can leverage this technique in various exploits to load shellcode and evade detection. Fixed the output of the following rules:\nK8s Serviceaccount Created K8s Serviceaccount Deleted Updated IoCs Ruleset with new findings Rule Changes\nAdded the Base64-encoded Python Script Execution rule to the IoCs Malware Activity default policy Added the Launch Ingress Remote File Copy Tools in Container rule to the Notable Container Activity default policy Created the new default policy, Known Exploit Detection. This policy embeds the rules that can identify potential exploits of well-known CVEs. 0.64.0\nApril 12, 2022\nRule Changes\nAdded additional exceptions to the following rules to aid in addressing false positives:\nSchedule Cron Jobs Set Setuid or Setgid bit Create Symlink Over Sensitive Files Disabled the Unprivileged Delegation of Page Faults Handling to a Userspace Process rule removing its condition. 0.63.0\nApril 09, 2022\nRule Changes\nUpdated the following rules:\nSimple output changes to the Detect outbound connections to common miner pool ports rule.\nUpdated priority and included additional cron paths for the Create Symlink Over Sensitive Files rule. Updated IoCs Ruleset with new findings The following new rules have been introduced.\nPrivileged Shell Spawned Inside Container. This rule detects a root shell being opened by a compromised process for interaction by the attack.\nDebugfs Launched in Privileged Container. This rule detects file system debugger, debugfs, launched inside a privileged container which might lead to container escape.\nMount Launched in Privileged Container. This rule detects file system mount occurrence inside a privileged container which might lead to container escape.\nUnprivileged Delegation of Page Faults Handling to a Userspace Process. This rule detects a successful unprivileged userfaultfd syscall which might act as an attack primitive to exploit other bugs\nLaunch Ingress Remote File Copy Tools in Container. This rule detects ingress remote file copy tools launched in a container. For example, curl and wget.\nSuspicious Cron Modification. This rule detects direct writes to cron job files. Default Policy Changes\nPolicy: Notable Filesystem Changes\nadded the Suspicious Cron Modification rule.\nPolicy: Suspicious Container Activity\nAdded the Debugfs Launched in Privileged Container rule.\nAdded the Unprivileged Delegation of Page Faults Handling to a Userspace Process rule.\nPolicy: Suspicious Lateral Movement Activity to Cloud\nAdded the Mount Launched in Privileged Container rule. Policy: Unexpected Spawned Processes\nAdded the Privileged Shell Spawned Inside Container rule. 0.62.1\nApril 06, 2022\nRule Changes\nReduced noise for the rulesWrite below monitored dir and write below etc by adding additional exceptions. 0.62.0\nMarch 25, 2022\nRule Changes\nAdded the following new rules: Base64'd ELF file on Command Line Execution from /tmp\nUpdated auto-tuner exceptions for the following:\nLaunch Sensitive Mount Container\nService Account Created in Kube Namespace\nUpdated IoCs Ruleset with new findings.\nDefault Policy Changes\nAdded the following new rules: Base64'd ELF file on Command Line Execution from /tmp\n0.60.0\nMarch 18, 2022\nRule Changes\nUpdated the Launch Root User Container condition rule. Updated the following lists to address false positive:\nminer_domains allowed_k8s_users\nUpdated some exceptions in the Schedule Cron Jobs rule.\nCreated the sssd_writing_krb macro from the new release of OSS Falco. Updated IoCs Ruleset with new findings.\nUpdated the following macros based on the changes in Falco OS:\nmodify_shell_history\ntruncate_shell_history\nwrite_etc_common\nDefault Policy Changes\nUpdated the IoCs Malware Activity policy. Malicious filenames writtenadded.\nMalicious process detected removed.\nRemoved some rules from Notable Filesystem Changes policy:\nWrite below etc\nWrite below root\nWrite below rpm database\nWrite below binary dir\nRemoved one rule from the Notable Container Activity policy: Change thread namespace\n0.59.2\nMarch 10, 2022\nRule Changes\nExcluded ptp and dp from the Change thread namespacerule.\nExcluded self from the K8s Serviceaccount Created rule.\nExcluded known cron writers from the Schedule Cron Jobs rule.\nUpdated the IoCs Ruleset with new findings.\n0.58.1\nMarch 06, 2022\nRule Changes\nAdded additional exceptions to aid in addressing false positive for rules:\nSchedule Cron Jobs\nNon sudo setuid Launch Privileged Container\nK8s Serviceaccount Created Updated the following macros baed on the changes in Falco OS:aws_eks_core_images\nUpdated IoCs Ruleset with new findings. 0.57.2\nMarch 03, 2022\nRule Changes\nFixed exception to aid in addressing false positives for rules: Contact K8S API Server From Container 0.56.5\nMarch 01, 2022\nRule Changes\nUpdate rule: DB program spawned process Create macro:pgbackrest_info_childs 0.56.4\nFebruary 18, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positive for rules:\nModify Shell Configuration File Modify Shell Configuration File Write below etc Write below rpm database DB program spawned process Clear Log Activities\nLaunch Root User Container\nUpdated the following macros based on the changes in Falco OS:\ncontainerd_shell_modify tanium_client_running_python postgres_running_pgbackrest proc_file_suffix known_redirect_procs Updated the following lists to address false positives:\nknown_setuid_binaries known_k8s_api_programs gke_trusted_images_launch_root_list Updated IoCs Ruleset with new findings. 0.55.2\nFebruary 10, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positive for rules:\nChange thread namespace Write below rpm database Write below root Clear Log Activities\nLaunch Root User Container Updated the following macros based on the changes in Falco OS:\nparent_python_running_sdchecks python_running_sdchecks exe_sysdig\ntanium_client_running_python\nsysdig_dragent trusted_logging_images\nUpdated the following lists based on the changes in Falco OS:\nsysdig_commercial_images allowed_dev_files user_known_chmod_applications miner_domains Updated IoCs Ruleset with new findings. 0.54.3\nFebruary 07, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positive for rules: Launch Root User Container 0.53.4\nFebruary 04, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positive for rules:\nModify Shell Configuration File Write below etc Write below root Read sensitive file trusted after startup Change thread namespace Launch Suspicious Network Tool in Container Redirect STDOUT/STDIN to Network Connection in Container Updated the following macros based on the changes in Falco OS:\nspawned_process\nsensitive_mount\nUpdated the following lists based on the changes in Falco OS:\nfalco_hostnetwork_images\ndeb_binaries\nknown_sa_list falco_sensitive_mount_images Updated the following lists to address false positives:\ndb_server_binaries\nuser_known_chmod_applications Updated IoCs Ruleset with new findings.\n0.53.3\nJanuary 29, 2022\nRule Changes\nAdded additional exceptions to older agent versions to aid in addressing false positives for rules:Write below etc.\nUpdated IoCs Ruleset with new findings.\nAdded new rules:\nModify ld.so.preload\nPolkit Local Privilege Escalation Vulnerability(CVE-2021-4034)\n0.52.0\nJanuary 21, 2022\nRule Changes\nUpdated IoCs Ruleset with new findings.\n0.51.1\nJanuary 14, 2022\nRule Changes\nCreated a new AWS Rule: Read Object through AWSSupportServiceRolePolicy Assumed Role.\nUpdated tags for AWS Rule:AWS Command Executed on Unused Region.\nUpdated tags for the following Google Cloud Platform (GCP) Rules:\nGCP Invitation Sent to Non-corporate Account\nGCP Create User-managed Service Account Key\nGCP Create GCP-managed Service Account Key\nGCP Create Cloud Function Not Using Latest Runtime\nGCP Set Bucket IAM Policy\nGCP Create Bucket\n0.50.5\n","url":"https://docs.sysdig.com/en/release-notes/falco-rules-changelog/2022-archive/"},{"id":829,"title":"Vulnerability Feeds","content":"Sysdig Vulnerability Management Data Sources and Feeds Planned change for 22 June 2026. Sysdig is making improvements to Alpine and Ubuntu vulnerability feeds and adding Python PDM support. After this release, customers may see more Alpine findings (Sysdig will report vulnerabilities without an available fix) and severity changes on Ubuntu CVEs (CVSS v3 will replace Ubuntu priority). See the SaaS Sysdig Secure Release Notes for details.\nSysdig Secure continuously checks against a wide range of vulnerability databases. The current database list includes:\nNIST NVD VulnDB NPM Python Ruby Alpine Linux Centos Debian Red Hat Red Hat EUS Rocky ERRATA Ubuntu Amazon Linux Alibaba Linux Oracle Linux Chainguard Wolfi Amazon BottleRocket PHP Advisory Go Vulnerability Database GitHub Advisories GitLab Advisories First.org EPSS Alma Linux SUSE Azure Linux Gentoo GLSA PhotonOS Microsoft Vulnerability Feed Synchronization IntervalSysdig aims to sync vulnerability feeds at least once per day. In general, feeds are synchronized every 8 hours to maintain up-to-date vulnerability data.\nIndividual feeds may experience synchronization issues, prompting manual synchronizations. As a result, the precise timing for synchronization of specific feeds may vary slightly.\nSupported Operating Systems Operating System Versions Source CVSS Score Severity Fix Date Publish Date Disclosure Date Alpine Linux 3.2+ Alpine Linux NVD NVD Alpine Linux \u0026gt; NVD \u0026gt; VulnDB Alpine Linux Alpine Linux CentOS 7\n8‑stream\n9‑stream CentOS NVD NVD CentOS \u0026gt; NVD \u0026gt; VulnDB CentOS CentOS Debian 10 (Buster)\n11 (Bullseye)\n12 (Bookworm)\n13 (Trixie)\n14 (Forky) Debian NVD Debian Urgency Debian \u0026gt; NVD \u0026gt; VulnDB Debian Debian Red Hat 7\n8\n9 RHEL CoreOS Red Hat Red Hat Red Hat Impact Red Hat \u0026gt; NVD \u0026gt; VulnDB Red Hat Red Hat Red Hat EUS 7.x‑EUS\n8.x‑EUS\n9.x‑EUS Red Hat Red Hat Red Hat Impact Red Hat \u0026gt; NVD \u0026gt; VulnDB Red Hat Red Hat Rocky Linux 8\n9 Rocky Linux NVD NVD Rocky Linux \u0026gt; NVD \u0026gt; VulnDB Rocky Linux Rocky Linux Ubuntu 18.04 LTS (Bionic)\n20.04 LTS (Focal)\n22.04 LTS (Jammy)\n23.04 (Lunar)\n23.10 (Mantic)\n24.04 (Noble)\n24.10 (Oracular) Ubuntu NVD Ubuntu Priority Ubuntu \u0026gt; NVD \u0026gt; VulnDB Ubuntu Ubuntu Amazon Linux 2\n2022\n2023 Amazon Linux NVD Amazon Severity Amazon Linux \u0026gt; NVD \u0026gt; VulnDB Amazon Linux Amazon Linux Alibaba Linux 2 Alibaba Linux Alibaba Alibaba Severity Alibaba Linux \u0026gt; NVD \u0026gt; VulnDB Alibaba Linux Alibaba Linux Oracle Linux 7\n8\n9 Oracle Linux Oracle Oracle Severity Oracle Linux \u0026gt; NVD \u0026gt; VulnDB Oracle Linux Oracle Linux Chainguard N/A Chainguard NVD NVD Chainguard \u0026gt; NVD \u0026gt; VulnDB Chainguard Chainguard Wolfi N/A Wolfi NVD NVD Wolfi \u0026gt; NVD \u0026gt; VulnDB Wolfi Wolfi Amazon BottleRocket 1.10\n1.11 Amazon BottleRocket NVD NVD Amazon BottleRocket \u0026gt; NVD \u0026gt; VulnDB Amazon BottleRocket Amazon BottleRocket Google Distroless Tracks Debian 12 (Bookworm) Google Distroless NVD NVD Google Distroless \u0026gt; NVD \u0026gt; VulnDB Google Distroless Google Distroless Flatcar All versions Gentoo GLSA NVD Gentoo Impact Gentoo GLSA \u0026gt; NVD \u0026gt; VulnDB Gentoo GLSA Gentoo GLSA Alma Linux 8\n9 Alma Linux NVD Alma Severity Alma Linux \u0026gt; NVD \u0026gt; VulnDB Alma Linux Alma Linux OpenSuse 15.5\n15.6\ntumbleweed Suse NVD Suse Severity Suse \u0026gt; NVD \u0026gt; VulnDB Suse Suse Azure Linux 3.0 Azure Linux NVD NVD Azure Linux \u0026gt; NVD \u0026gt; VulnDB Azure Linux Azure Linux CBL Mariner 1.0\n2.0 CBL Mariner NVD NVD CBL Mariner \u0026gt; NVD \u0026gt; VulnDB CBL Mariner CBL Mariner Suse Linux Micro 6.0\n6.1 Suse NVD Suse Severity Suse \u0026gt; NVD \u0026gt; VulnDB Suse Suse Suse Enterprise Linux SUSE Linux Enterprise Server 12 SP4 and SP5\nSUSE Linux Enterprise Server 15 SP3, SP4, SP5 and SP6 Suse NVD Suse Severity Suse \u0026gt; NVD \u0026gt; VulnDB Suse Suse PhotonOS 1.0\n2.0\n3.0\n4.0\n5.0 PhotonOS NVD PhotonOS PhotonOS \u0026gt; NVD \u0026gt; VulnDB PhotonOS PhotonOS Windows Server Windows Server 2019, 2022\nWindows Server Core 2019, 2022 Microsoft NVD Microsoft Microsoft \u0026gt; NVD \u0026gt; VulnDB Microsoft Microsoft Non-OS-Based Sources and Supported Package Types Non‑OS‑Based Sources Matched Package Types Source CVSS Score Severity Fix Date Publish Date Disclosure Date NPM (JavaScript) NPM (JavaScript) NPM NVD NVD VulnDB NPM NPM Python (Pypi) Python Python Advisory \u0026gt; GitHub \u0026gt; GitLab NVD NVD VulnDB Python Advisory Python Advisory Ruby Ruby Gems GitHub \u0026gt; GitLab \u0026gt; Ruby Advisory NVD NVD VulnDB GitHub GitHub Rust Cargo (Rust) GitHub NVD NVD VulnDB GitHub GitHub Go Golang (built with Go 1.13+)\nGo Runtime GitHub \u0026gt; GitLab \u0026gt; Go Vulnerability Database NVD NVD VulnDB GitHub GitHub Java Java JAR\nWAR\nEAR GitHub \u0026gt; GitLab NVD NVD VulnDB GitHub GitHub PHP Composer (PHP) PHP Advisory \u0026gt; GitHub \u0026gt; GitLab NVD NVD VulnDB PHP Advisory PHP Advisory C# NuGet (.Net) GitHub NVD NVD VulnDB GitHub GitHub Column Legend Column Description Source The specific database or advisory where Sysdig matches vulnerabilities, whether it’s from a vendor, an operating system, or a non‑OS package. Matched Package Types / Versions The programming languages or operating system versions that are scanned for vulnerabilities, matched against specific sources. For packages, it indicates supported types, and for OS, the supported versions. CVSS Score The primary vulnerability score, such as NVD, displayed in the UX or reports. Additional scores from vendor-specific sources may also be available. Severity The primary severity level derived from the score, shown in the UX or reports. Vendor-specific severities may also be displayed where applicable. Fix Date For OS-based sources, this field indicates the scheduled remediation date determined by a hierarchy: Vendor Fix Date \u0026gt; NVD Fix Date \u0026gt; VulnDB Fix Date. For non‑OS‑based sources—where a dedicated fix date isn’t provided—this field is marked as N/A. Publish Date The date the vulnerability was published, sourced directly from the vendor’s security feed. Disclosure Date The date the vulnerability was publicly disclosed, also sourced directly from the vendor’s security feed. ","url":"https://docs.sysdig.com/en/sysdig-secure/vulnerability-feed/"},{"id":830,"title":"Falco Changelog 2021","content":" Commit Date\nRule Notes\nVersion of the Falco Rules Installer (On-Prem)\nDecember 16, 2021\nRule Changes\nAdd a new rule:Malicious C2 IPs or domains exploiting log4j: detect connections with malicious IPs involved in log4j exploitation.\nUpdated IoCs Ruleset with new findings\n0.49.2\nJanuary 03, 2022\nRule Changes\nCreated a new AWS Rule: Read Object through AWSSupportServiceRolePolicy Assumed Role.\nUpdated tags for AWS Rule:AWS Command Executed on Unused Region.\nUpdated tags for the following GCP Rules:\nGCP Invitation Sent to Non-corporate Account\nGCP Create User-managed Service Account Key\nGCP Create GCP-managed Service Account Key\nGCP Create Cloud Function Not Using Latest Runtime\nGCP Set Bucket IAM Policy\nGCP Create Bucket\n0.48.0\nDecember 06, 2021\nRule Changes\nAdd a new rule:Find AWS Credentials: Find or grep AWS credentials in host or container.\nAdd additional exceptions formats to aid in addressing false positives for rules: K8s ConfigMap Deleted.\nUpdated IoCs Ruleset with new findings\n0.46.2\nNovember 30, 2021\nRule Changes\nAdd additional exceptions formats to aid in addressing false positives for rules: Create Sensitive Mount Pod.\nUpdated IoCs Ruleset with new findings\n0.46.0\nNovember 22, 2021\nRule Changes\nCreated a new GCP Rule: GCP Create Cloud Function\nCreate following Azure Rules:\nAzure Remember MFA for User Access on Devices\nAzure Users Can Consent to Apps Accessing Company Data on Their Behalf\nAzure Deactivate MFA for User Access\nAzure Container ACL Modified\nAdd additional exceptions formats to aid in addressing false positives for rules:\nModify Shell Configuration File\nLaunch Privileged Container\nContainer Run as Root Users\nUpdated IoCs Ruleset with new findings\nUpdated AWS, Azure,and GCP tags\n0.45.1\nNovember 16, 2021\nRule Changes\nUpdated IoCs Ruleset with new findings.\n0.44.1\nNovember 15, 2021\nRule Changes\nAdded new rule for AWS Cloudtrail: Create Lambda Function Using Unsupported Runtime\nModified rule for AWS Cloudtrail:Run Instances with Non-standard Imagenow checks the image ID from aws.ec2.imageID instead of getting this value from respondeElements/instanceSet/items using jevt\n0.44.0\nNovember 11, 2021\nRule Changes\nAdded new tags to the following rules:\nGCP Delete Resources from the PCI Blueprint Environment\nGCP Create KMS Key Without Rotation\nGCP Remove KMS Key Rotation\nGCP Delete DNS Zone\nGCP Delete GKE Node Pool\nGCP Delete Router\nGCP Delete GKE IAM Role\nGCP Delete VPC Network\nGCP Delete GKE Subnetwork\n0.43.2\nNovember 5, 2021\nRule Changes\nAdded new tags to existent rules for MITRE and NIST categories.\n0.43.1\nOctober 29, 2021\nRule Changes\nAdded new tags to the following rules:\nModify RDS Snapshot Attribute\nModify Image Attribute\nModify Snapshot Attribute\nDetect outbound connections to common miner pool ports\nDetect crypto miners using the Stratum protocol\nUpdated Malware IoCs with the new findings.\u003c/ 0.42.0\nOctober 20, 2021\nRule Changes\nAdd additional exceptions formats to aid in addressing false positives for rules:\nModify Shell Configuration File\nRun shell untrusted\nLaunch Sensitive Mount Container\nOutbound or Inbound Traffic not to Authorized Server Process and Port\nCreate Sensitive Mount Pod\nCreate NodePort Service\nAttach/Exec Pod\nService Account Created in Kube Namespace\nSystem ClusterRole Modified/Deleted\nDefault Policy Changes\nLowered Severity to INFO for the following policies:\nAll K8s User Modifications\nAll K8s Object Modifications\n0.41.0\nOctober 11, 2021\nRule Changes\nAdd additional exceptions formats to aid in addressing false positives for rules:\nModify binary dirs\nClear Log Activities\nRemove Bulk Data from Disk\nCreate HostNetwork Pod\nLaunch Suspicious Network Tool in Container\nAdded three new Falco rules to detect Malware:\nMalicious IPs or domains detected on command line\nMalicious binary detected\nMalicious process detected\nDefault Policy Changes\nAdded New Policy IoCs Malware Activity\n0.40.0\nOctober 07, 2021\nRule Changes\nChanged inbound_outbound macro condition.\nAdd additional exceptions formats to aid in addressing false positives for rules:\nWrite below etc\nRead sensitive file untrusted\nSearch Private Keys or Passwords\nDisallowed K8s User\nK8s Deployment Created\nK8s Deployment Deleted\nK8s Service Created\nK8s Service Deleted\nK8s ConfigMap Created\nK8s ConfigMap Deleted\nK8s Namespace Created\nK8s Namespace Deleted\nK8s Serviceaccount Created\nK8s Serviceaccount Deleted\nK8s Role/Clusterrole Created\nK8s Role/Clusterrole Deleted\nK8s Role/Clusterrolebinding Created\nK8s Role/Clusterrolebinding Deleted\n0.39.0\nSeptember 23, 2021\nRule Changes\nChanged net_miner_pool macro used in the Detect outbound connections to common miner pool ports rule.\n0.37.1\nSeptember 21, 2021\nRule Changes\nAdd additional exceptions formats to aid in addressing false positives for rules: Non sudo setuid rule.\n0.37.0\nAugust 26, 2021\nRule Changes\nAdded the following rules:\nConsole Login Through Assume Role\nAWS Command Executed by Untrusted User\nConsole Login Success\nConsole Login Success From Untrusted IP\nDelete AWS user\nRemove AWS User from Group\nPut Object in Watched Bucket\nRead Object in Watched Bucket\nAdded new lists:\ntrusted_aws_users\nwatched_buckets\nUpdated rules:\nConsole Login Without MFA now does not fire on assumed role\nConsole Root Login Without MFA now does not fire on assumed role\nAdd AWS User to Group now outputs the user added to the group\n0.36.0\nPOSTPONED August 20, 2021\nPOSTPONED Rule Changes\nAdded a new rule: Unprivileged Delegation of Page Faults Handling to a Userspace Process\nUpdate the list:\nsysdig_commercial_images\nfalco_hostnetwork_images\nUpdated the macro: interactive macro updated checking the tty state. The interactive session is with proc.tty != 0\nPOSTPONED 0.35.0\nAugust 13, 2021\nRule Changes\nAdded additional exceptions formats to aid in addressing false positive for the rules:\nLaunch Package Management Process in Container\nTerminal shell in container\nThe docker client is executed in a container\nUpdated the list: sysdig_commercial_images Updated the macro: interactive macro updated checking the tty state. The interactive session is with proc.tty != 0\n0.34.0\nAugust 02, 2021\nRules Changes\nAdd additional exceptions formats to aid in addressing false positive for rules:\nDB program spawned process Rule\nChange thread namespace\nThe docker client is executed in a container\nLaunch Suspicious Network Tool in Container Rule\n0.33.0\nJuly 27, 2021\nDefault Policy Changes\nEnable the Sysdig GCP Best Practices policy by default.\n0.32.0\nJuly 25, 2021\nRule Changes\nGCP events were consumed directly from the protoPayload, which removed some fields that are used and are not part of the protoPayload itself. All the rules that use jevt.value are updated now to reference protoPayload in the root path. It is a breaking change for GCP rules, and you are required to use cloud-connector versions above v0.8.0.\nUpdated GCP rules to use protoPayload JSON path. Affected rules:\nGCP Create API Keys for a Project\nGCP Delete Bucket\nGCP Create Bucket\nGCP List Buckets\nGCP List Bucket Objects\nGCP Put Bucket ACL\nGCP Set Bucket IAM Policy\nGCP Update Bucket\nGCP Create Cloud Function Not Using Latest Runtime\nGCP Create Cloud Function\nCloudRun Create Service\nCloudRun Replace Service\nGCP Create a Default VPC Network\nGCP Disable Subnet Flow Logs\nGCP Enable Connecting to Serial Ports for a VM Instance\nGCP Creation of a VM Instance with IP Forwarding Enabled\nGCP Suspected Disable of OS Login in a VM Instance\nGCP Enable Project-wide SSH keys for a VM Instance\nGCP Shield Disabled for a VM Instance\nGCP Create or Patch DNS Zone without DNSSEC\nGCP Describe Instance\nGCP Command Executed on Unused Region\nGCP Create GCP-managed Service Account Key\nGCP Create User-managed Service Account Key\nGCP Invitation Sent to Non-corporate Account\nGCP Operation by a Non-corporate Account\nGCP Super Admin Executing Command\nGCP Update, Disable or Delete Sink\nGCP Monitoring Alert Deleted\nGCP Monitoring Alert Updated\nGCP Disable Automatic Backups for a Cloud SQL Instance\nGCP Disable the Requirement for All Incoming Connections to Use SSL for a Cloud SQL Instance\nAdded a new rule: GCP Set a Public IP for a Cloud SQL Instance\n0.31.0\nJuly 22, 2021\nNo rule changes. No default policy changes.\nFix a defect related to installing rules for older backend versions (Sysdig 4.0.*).\n0.30.0\nJuly 20, 2021\nDefault Policy Changes\nSysdig AWS Best Practices severity is now set to 'medium'\nSysdig GCP Best Practices severity is now set to 'medium'\n0.29.0\nJuly 19, 2021\nRule Changes\nAdd additional exceptions formats to aid in addressing false positive for rules:\nDB program spawned process Rule\nChange thread namespace\nThe docker client is executed in a container\n0.28.0\nJuly 16, 2021\nDefault Policy Changes\nDisabled Access Cryptomining Network Policy by default\n0.27.0\nJuly 15, 2021\nRule Changes\nAdd additional exceptions formats to aid in addressing false positive for rules:\nRun shell untrusted\nDB program spawned process\nChange thread namespace\n0.26.0\nJuly 11, 2021\nDefault Policy Changes\nRule changes have been applied in the following default policies:\nSuspicious Package Management Changes\nNotable Filesystem Changes\nSuspicious Filesystem Reads Policy\nSuspicious Filesystem Changes\nUser Management Changes\nDisallowed Network Activity\nInadvised Container Activity\nDisallowed Container Activity\nSuspicious Container Activity\nNew default policies created:\nSuspicious Lateral Movement Activity to Cloud\nNotable Network Activity\nDefault policies removed:\nSuspicious Package Management Changes\nSuspicious Filesystem Reads Policy\nUser Management Changes\nDisallowed Network Activity\nDisallowed Container Activity\nInadvised Container Activity\nExistent policies status changes:\nAccess AcceCryptomining Network enabled by Default\n0.25.0\nJuly 01, 2021\nRule Changes\nAdd additional exceptions formats to aid in addressing false proofs for rules:\nNetcat Remote Code Execution in Container\nLaunch Sensitive Mount Container\nRedirect STDOUT/STDIN to Network Connection in Container\n0.24.0\nJune 25, 2021\nRule Changes\nAdd additional exceptions formats to aid in addressing false proofs for rules:\nWrite below root\nChange thread namespace\n0.23.0\nJune 22, 2021\nRule Changes\nAdd additional exceptions formats for rules:\nChange thread namespace\nCreate Privileged Pod\nModify Shell Configuration File\nWrite below binary dir\nLaunch Privileged Container\nThe docker client is executed in a container\nClusterRole With Wildcard Created\nCreate HostNetwork Pod\nService Account Created in Kube Namespace\nK8s Role/Clusterrole Created\nK8s Role/Clusterrole Deleted\nK8s Role/Clusterrolebinding Created\nNetcat Remote Code Execution in Container\nDelete Bash History\nClusterRole With Write Privileges Created\nClear Log Activities\nModify binary dirs\nUnexpected outbound connection destination\nUnexpected UDP Traffic\n0.22.0\nJune 19, 2021\nA new policy, Sysdig GCP Best Practices, has been added.\nRule Changes\nNew GCP Rules have been added for AuditLog:\nGCP Create API Keys for a Project\nGCP Create Bucket\nGCP Delete Bucket\nGCP List Buckets\nGCP List Bucket Objects\nGCP Put Bucket ACL\nGCP Set Bucket IAM Policy\nGCP Update Bucket\nGCP Create Cloud Function Not Using Latest Runtime\nGCP Create Cloud Function\nGCP Update Cloud Function\nCloudRun Create Service\nCloudRun Replace Service\nGCP Create a Default VPC Network\nGCP Disable Subnet Flow Logs\nGCP Enable Connecting to Serial Ports for a VM Instance\nGCP Creation of a VM Instance with IP Forwarding Enabled\nGCP Suspected Disable of OS Login in a VM Instance\nGCP Enable Project-wide SSH keys for a VM InstanceGCP Shield Disabled for a VM Instance\nGCP Create or Patch DNS Zone without DNSSEC\nGCP Describe Instance\nGCP Command Executed on Unused Region\nGCP Create GCP-managed Service Account Key\nGCP Create User-managed Service Account Key\nGCP Invitation Sent to Non-corporate Account\nGCP Operation by a Non-corporate Account\nGCP Super Admin Executing Command\nGCP Update, Disable or Delete SinkGCP Monitoring Alert Deleted\nGCP Monitoring Alert Updated\nGCP Disable Automatic Backups for a Cloud SQL Instance\nGCP Disable the Requirement for All Incoming Connections to Use SSL for a Cloud SQL Instance\n0.21.0\nJune 17, 2021\nFixed a defect in v0.20.3. The fix is for the detection of older backend versions when looking for accounts scheduled for deletion.\n0.20.4\nJune 17, 2021\nSkip accounts scheduled for deletion when verifying Falco rules compatibility.\n0.20.3\nJune 16, 2021\nRule Changes\nAdd additional exceptions formats to allow addressing false positives for rules:\nLaunch Package Management Process in Container\nSet Setuid or Setgid bit\nTerminal shell in container\n0.20.2\nJune 11, 2021\nRules Changes\nAdd additional exceptions formats to help address false positives for rules:\nRun shell untrusted\nSet Setuid or Setgid bit\n0.20.1\nJune 03, 2021\nRule Changes\nThe Non sudo setuid rule: Add macmnsvc (mcafee service host) to set of programs that are allowed to setuid.\nThe Launch Suspicious Network Tool in Container rule: Add another zookeeper image pattern that's allowed to run network tools.\nThe Clear Log Activities rule: Add another fluentd image as allowed to clear log files.\nAdd additional exceptions formats to aid in addressing false positives for rules:\nSystem procs network activity\nK8s Serviceaccount Created\nK8s Serviceaccount Deleted\nK8s Role/Clusterrole Created\nK8s Role/Clusterrole Deleted\n0.20.0\nJune 01, 2021\nRule Changes\nThe Read Sensitive File Untrusted rule:\nAllow clamscan to read sensitive files\nAllow db2ckpw (IBM DB2 Credential Checker) to read sensitive files\nThe Launch Suspicious Network Tool in Container rule: Add another zookeeper image that is allowed to run nc inside a container.\nAdd additional exception patterns for the following rules:\nLaunch Package Management Process in Container\nK8s Serviceaccount Created\nK8s Serviceaccount Deleted\nK8s Role/Clusterrole Created\nK8s Role/Clusterrole Deleted\n0.19.0\nMay 26, 2021\nRule Changes\nAdd additional Qualys binaries as exceptions for rules:\nRead sensitive file untrusted\nUser mgmt binaries\nWrite below etc\nThe Write below etc rule:\nAllow newrelic to write below /root/newrelic instead of specific files\nAllow nessuscli write state file\nAllow masvc to write below /etc/ma.d/\nAllow grafana to write state\nThe Write below root rule : Add an additional cmdline writing to exec.fifo.\nThe DB program spawned process rule: Allow sqlplus spawn oracle.\nAdd additional sets of exception fields for rules:\nWrite below monitored dir\nThe docker client is executed in a container\n0.18.0\nMay 25, 2021\nThe Sysdig AWS Best Practices policy no longer includes the Logged in without Using MFA rule.\nRule Changes\nAdd five new rules for AWS Cloudtrail events.\nDisable the AWS Cloudtrail rule, Logged in without Using MFA.\nThe Read Sensitive File Untrusted rule: Let the TaniumEndpoint agent read additional sensitive files.\nThe Write below root rule, docker_writing_state macro: Allow for paths that simply specify a path below an implied / or /root of current working directory.\nThe DB program spawned process rule: Add additional allowed Postgres backup utilities.\nThe Write below root rule:\nUse a more flexible string match against the /exec.fifo paths.\nAllow newrelic CLI to write to CLI log file.\nAllow the docker cleanup image utility to write state files below /.\nThe Write below rpm database rule: Allow tanium endpoint script to write to the rpm database.\nThe Contact K8S API Server From Container rule: Add another fluent-bit program that is allowed to contact the API Server.\n0.17.0\nMay 20, 2021\nRule Changes\nAdded exception to the following to address false positives:\nThe Non sudo setuid rule: Let swiagent read setuid.\nThe Read sensitive file untrusted rule:\nLet refresh-mcollec (tive-metadata), part of puppet, read sensitive files.\nLet puppet directly read sensitive files.\nLet Tanium endpoint read sensitive files.\nLet ir_agent (rapid7 agent) read sensitive files.\nThe Write below root rule:\nAdd an additional command line pattern for Cassandra to allow writes to /root/.cassandra.\nAdd additional exec.fifo path below root for runc.\nLet docker write to certain files below /. It is part of some docker-in-docker setups.\nLet Tanium joval write to /root/.jOVAL/.\nThe Change thread namespace rule:\nAdd an additional weaveworks/kured process name.\nLet avinetworks/se images run programs that can change thread namespaces.\nThe System procs network activity rule : Add an additional exception pattern.\nThe User mgmt binaries: Let refresh-mcollec (tive-metadata), part of puppet, run user management binaries.\nThe Contact K8S API Server From Container rule: Let fluent-bit images run programs to contact the API server.\nThe Launch Suspicious Network Tool in Container rule: Let certain OpenShift images run dig to perform DNS lookups.\nThe Clear Log Activities rule: Let certain Workinggrafana-related images clear log files in the container.\n0.16.0\nMay 19, 2021\nRule Changes\nAdditional exception fields are added to the following rules to aid in customization:\nK8s Secret Created\nK8s Secret Deleted\n0.15.1\nMay 18, 2021\nRule Changes\nThe Detect outbound connections to common miner pool ports rule: Add additional known miner domains.\nAdd additional exception fields to the following rules to aid customization:\nModify Shell Configuration File\nWrite below monitored dir\nWrite below etc\nWrite below root\nWrite below rpm database\nLaunch Privileged Container\nLaunch Sensitive Mount Container\nTerminal shell in container\nSystem procs network activity\nLaunch Suspicious Network Tool in Container\nSet Setuid or Setgid bit\nLaunch Remote File Copy Tools in Container\nThe docker client is executed in a container\nDisallowed K8s User\nCreate Privileged Pod\nCreate Sensitive Mount Pod\nCreate HostNetwork Pod\nAttach/Exec Pod\nPod Created in Kube Namespace\nService Account Created in Kube Namespace\nClusterRole With Wildcard Created\nK8s Secret Created\nK8s Secret Deleted\nThe Change thread namespace rule: Add an additional exception for the Sysdig agent.\nThe Pod created in the Kube Namespace rule: Allow users starting with \"system:\" to create pods in the kube-system/kube-public namespaces.\nThe Read sensitive file untrusted rule: Allow puppet to run scripts that might read sensitive files.\nThe Write below root rule: Add an additional way to detect Cassandra to allow writes to /root/.cassandra.\nThe Change thread namespace rule: Allow Weaveworks Kured (Kubernetes Reboot Daemon) to change thread namespaces.\n0.15.0\nMay 17, 2021\nRule Changes\nAdd rpmdb_verify as an RPM Package Management program. This affects the following rules:\nUpdate Package Repository\nWrite below binary dir\nWrite below monitored dir\nWrite below etc\nRead sensitive file untrusted\nModify binary dirs\nMkdir binary dirs\nRun shell untrusted\nPackage management process ran inside container\nWrite below etc: Add haproxy-ingress as a program that can write below /etc/haproxy.\nChange thread namespace: Allow images ending with /ext-cilium-startup-script to change namespaces.\nLaunch Suspicious Network Tool in Container: Allow images ending with sysdig/cassandra and bitnami/zookeeper to run network tools inside containers.\nSet setuid or setgid bit: Allow the images in the sysdig_commercial_images list to include applications with setuid/setgid binaries.\n0.14.0\nMay 05, 2021\nRule Changes\nAdd a macro to allow backward compatibility for using older pre-exceptions rules content.\n0.13.2\nMay 05, 2021\nRule Changes\nRemove the aws_cloudtrail rule named Create Internet-facing AWS Public Facing Load Balancer without Required Tags from the previous release that uses features yet to be released.\n0.13.1\nMay 04, 2021\nAdded the Launch Root User Container rule to the Notable Container Activity policy.\nRule Changes\nAll Rules with the source, aws_cloudtrail: Switch from using jevt.value[/path] to aws.xxx to extract information out of aws_cloudtrail events.\nA new rule, Launch Root User Container , has been added. It matches when a container is started and is configured to run as root. This works for Docker and CRI-O container runtimes, but not for OpenShift 4.x, which does not make the necessary information available.\nMacro spawned_process: Consider only successful executables. For example, where the return value is 0. This affects the following rules:\nSchedule Cron Jobs\nDB program spawned process\nRun shell untrusted\nSystem user interactive\nTerminal shell in container\nProgram run with disallowed http proxy env\nUser mgmt binaries\nLaunch Package Management Process in Container\nNetcat Remote Code Execution in Container\nLaunch Suspicious Network Tool in Container\nLaunch Suspicious Network Tool on Host\nSearch Private Keys or Passwords\nRemove Bulk Data from Disk\nDelete Bash History\nLaunch Remote File Copy Tools in Container\nDetect crypto miners using the Stratum protocol\nThe docker client is executed in a container\nLinux Kernel Module Injection Detected\nContainer Run as Root User\nThis could affect the following rules if they are triggered based on an exec() process rather than a container-started event.\nLaunch Privileged Container\nLaunch Sensitive Mount Container\nLaunch Disallowed Container\nLaunch Root User Container\n0.13.0\nApril 09, 2021\nRule Changes\nRestore several old macros and lists that are no longer used by any of the default rules, but might be used by some users' local rules.\n0.12.2\nApril 05, 2021\nFixed a defect that could prevent deploying rules to several older Sysdig backend versions.\n0.12.1\nMarch 31, 2021\nRule Changes\nAdded new versions of falco_rules.yaml/k8s_audit_rules.yaml that uses exceptions instead of collections of macros and long condition strings. The rules coverage should be identical to older versions.\n0.12.0\nMarch 19, 2021\nFixed minor problems with the rules installation script.\n0.11.1\nMarch 11, 2021\nRule Changes\nAdded 164 rules that detect suspicious/anomalous/notable behavior from a stream of AWS CloudTrail events. This requires a Sysdig backend that supports policy types and running the Cloud Connector for Secure for cloud..\nFor a full list of rules for different AWS services, see CloudTrail Rules for Secure for Cloud.\nDefault Policy Changes\nThe new policy, Sysdig AWS Best Practices, includes 41 of the above rules that Sysdig recommends using for the AWS environments.\n0.11.0\nFebruary 9, 2021\nRule Changes\nrule Change thread namespace: Let cilium nsenter\nrule Change thread namespace: Let dynatrace setns\nrule Change thread namespace: Let sysdig agent setns (the process name was changed recently)\nrule Clear Log Activities: Allow fluentd to write/access log files in a container\nmacro exe_running_docker_save: Added support for Crio setting up containers. This affects several rules including:\nModify Shell Configuration File\nUpdate Package Repository\nWrite below binary dir\nWrite below monitored dir\nWrite below etc\nWrite below root\nWrite below rpm database\nModify binary dirs\nmkdir binary dirs\nSet Setuid or Setgid bit\nCreate Hidden Files or Directories\nrule Launch Package Management Process in Container: Let sysdig node-image-analyzer run rpm\n0.10.5\n","url":"https://docs.sysdig.com/en/release-notes/falco-rules-changelog/2021-archive/"},{"id":831,"title":"Falco Changelog 2020","content":" Commit Date\nRule Notes\nVersion of the Falco Rules Installer (On-Prem)\nDecember 14, 2020\nRule Changes\nAdd a new rule, Container Run as Root User ,to the Inadvised Container Activity policy.\nAdd crio and multus to the user_known_change_thread_namespace_binaries list\n0.10.4\nDecember 1, 2020\nRule Changes\nEnsure that falco_rules_local.yaml is evaluated against all the default files.\nEnsure that the logs clearly show which files are being evaluated.\n0.10.3\nNovember 16, 2020\nRule Changes\nAdd the new rule, Linux Kernel Module Injection Detected, to the Notable Filesystem Changes policy.\nAdd the multipath_writing_conf macro as an exception in the Write below etc rule.\nAdd the chage_list macro as exception in the User mgmt binaries rule\nUpdate compliance tags.\n0.10.2\nOctober 14, 2020\nAdd CSRF token protection.\nRule Changes\nAdd a new rule, Outbound Connection to C2 Servers, to the Disallowed Network Activity policy.\n0.10.1\nSeptember 30, 2020\nRule Changes\nWrite below root: Similar to the rules that rely on a process name for exceptions, events will not be triggered if the process name is missing. For example, \"\".\nDelete or rename shell history. Ignore docker programs that would prevent modifying shell history, when the path is expressed within the container filesystem (/.bash_history) and host filesystem (/var/lib/docker/overlay/.../.bash_history).\nAll Rules: Changes to the tags to add NIST 800-53 and SOC2 tags:\nRenamed previous NIST 800-190 tags to use the prefix NIST_800-190_.\nFixed rule names for some Kubernetes rules.\n0.10.0\nSeptember 23, 2020\nRule Changes\nLaunch Sensitive Mount Container: Change image matching to correctly identify Sysdig images as compared to names starting with \"sysdig...\"\nDetect shell history deletion: Ignore paths below /var/lib/docker. For example, the container filesystem overlay images that are removed when a container is removed.\nThe Packet socket created in container rule is now enabled by default.\n0.9.1\nSeptember 10, 2020\nRule Changes\nAll Rules: Add user.loginuid as an output field. This uid is generally unchanging across sudo/su commands, and can more reliably identify users.\nLaunch Privileged Container: Add additional images that can run with privileged=true.\nLaunch Sensitive Mount Container: Fix a typo that allows docker.io/sysdig/agent-slim to perform sensitive mounts.\nRead sensitive file untrusted: Allow linux-bench to read sensitive files containing user information.\nUpdate Package Repository: Restrict checks to files below known package management directories.\nWrite below etc: Add exceptions related to calico within containers.\nWrite below root: Allow mysqlsh write to /root/.mysqlsh .\nRead sensitive file untrusted: Allow google_oslogin_{control} read sensitive files.\nChange thread namespace: Trigger only when the process name is known.\nCreate HostNetwork Pod: Allow several images related to GKE + default metrics/routing services run with hostnetwork=true.\nDisallowed Kubernetes User: Add several known Kubernetes users to allowed list.\nPod Created in Kube Namespace: Allow several images related to GKE + default metrics/routing services run in kube-system/kube-public namespaces.\nSystem ClusterRole Modified/Deleted: Allow modifications to the role system:managed-certificate-controller.\n0.9.0\nSeptember 08, 2020\nAdded support for updating Falco rules across multiple accounts in an on-prem setup.\n0.8.3\nAugust 17, 2020\nRule Changes\nCreated a new rule, EphemeralContainers Created for the Suspicious K8s Activity policy.\nReplace the endswith operator when checking with an image repository.\nWhitelisted sysdig/agent and sysdig/agent-slim . They are not available with the open-source Falco Rules.\nWhitelisted dockerd-current and docker-current in the exe_running_docker_save macro.\n0.8.2\nAugust 03, 2020\nRule Changes\nAdd the k8s_image_list list to the trusted_pod macro\n0.8.1\nJuly 27, 2020\nRule Changes\nMove the Write below root rule from the Suspicious Filesystem Changes policy to the Notable Filesystem Changes policy\nDelete the NIST 800-190 Application Container Security Guide policy\nDelete the Payment Card Industry Data Security Standard (PCI DSS) policy\nAdd a new macro, user_read_sensitive_file_containers for the Read sensitive file untrusted rule\nAdd docker.io/falcosecurity/falco to the falco_privileged_images list\nAdd kubernetes-admin to the allowed_k8s_users list\n0.8.0\nJuly 20, 2020\nRule Changes\nDisable Disallowed K8s Activity policy\nAdd placeholder macros for multiple rules\nFix the root_dir macro\nAdd snapd to the package_mgmt_binaries list\nAdd zmap to the network_tool_binaries list\nWhitelist protokube, dockerd, tini, and aws in the change thread namespace rule\nAdd sysdig/agent-slim and sysdig/node-image-analyzer images to the user_trusted_containers macro\nAdd kube-apiserver-healthcheck to the allowed_k8s_users list\n0.7.9\nJuly 7, 2020\nRemove unnecessary logging.\nAdd a new flag, --saas\n0.7.8\nJuly 1, 2020\nHandle an improper error.\n0.7.7\nJune 25, 2020\nDisable rule Container Drift Detected (chmod) by default\n0.7.6\nJune 23, 2020\nUpdate rule Container Drift Detected (open+create) to avoid warning\n0.7.5\nJune 22, 2020\nRule Changes\nAdded two new rules: Container Drift Detected (chmod) and Container Drift Detected (open+create) to policy Suspicious Container Activity\nThe Container Drift Detected (open+create) rule is disabled until an agent is released that supports the new evt.is_open_exec filter.\nUpdated macros bin_dir_mkdir and bin_dir_rename using evt.arg.path instead of evt.arg\nAdded placeholder macro user_known_write_below_binary_dir_activities to rule Write below binary dir\nFixed rule Anonymous Request Allowed to update the auth decision with ka.auth.decision=allow instead of ka.auth.decision!=reject\n0.7.4\nMay 28, 2020\nRule Changes\nWrite below etc: Added lvs as a logical volume writing program that can write below /etc/lvm.\nClear Log Activities: Allowed additional Fluentd images to write to log file directories.\nSet Setuid or Setgid bit: Added macro user_known_set_setuid_or_setgid_bit_conditionsthat makes it easier to add locally provided exceptions.\nLaunch Remote File Copy Tools in Container: Fixed the use of the list remote_file_copy_binaries so the list items are included.\nThe docker client is executed in a container: Now allow hcp-tunnelfront to run kubectl in containers.\nDisallowed K8s User: Added vertical pod autoscaler programs as known Kubernetes users.\n0.7.3\nMay 5, 2020\nRule Changes\nFor a brief time, Falco rules/macros had fields with k8s.* in them. These fields do not work in Sysdig Secure, so the relevant macros have been rewritten to omit them:\ncalico_writing_state\nuser_known_metadata_access\nk8s_containers\nuser_known_k8s_client_container\n0.7.2\nMay 1, 2020\nRule Changes\nAdd new rule Redirect stdout/stdin to network connection in container to policy Suspicious Container Activity\nAdd new rules Network Connection outside Local Subnet and Outbound or Inbound Traffic not to Authorized Server Process and Port to policy Suspicious Network Activity\nAdd new rules K8s Secret Created and K8s Secret Deleted to policy All K8s Object Modifications\nAdd rules Untrusted Node Successfully Joined the Cluster and Untrusted Node Unsuccessfully Tried to Join the Cluster to policy Suspicious K8s Activit\nAdd rule Full K8s Administrative Access to policy Suspicious K8s User Activity\nAdd rule Ingress Object without TLS Certificate Created to policy Inadvised K8s Activity\nCheck dsc_host in macro ms_oms_writing_conf\nAdd macros mcafee_writing_cma_d and avinetworks_supervisor_writing_ssh as exceptions in rule Write below etc\nAdd macro runc_writing_exec_fifo as exception in rule Write below root\nUse \"pmatch\" instead of \"in\" operator to check known files under root directory\nUpdate rule Change thread namespace to check exit event only\nAdd macro known_system_procs_network_activity_binaries for rule System procs network activity\n0.7.1\nApril 9, 2020\nRule Changes\nAdd PCI/NIST tags to the following rules:\nDisallowed SSH Connection\nUnexpected outbound connection destination\nUnexpected inbound connection source\nWrite below binary dir\nWrite below monitored dir\nWrite below etc\nWrite below root\nRead sensitive file untrusted\nDB program spawned process\nModify binary dirs\nMkdir binary dirs\nChange thread namespace\nLaunch Privileged Container\nLaunch Sensitive Mount Container\nLaunch Disallowed Container\nTerminal shell in container\nUnexpected UDP Traffic\nCreate files below dev\nContact K8S API Server From Container\nUnexpected K8s NodePort Connection\nSearch Private Keys or Passwords\nClear Log Activities\nCreate Symlink Over Sensitive Files\nDetect crypto miners using the Stratum protocol\nWrite below etc:\nAdd \"dsc_host\" as a MS OMS program\nLet McAfee write to /etc/cma.d\nLet AVI Networks supervisor write somessh cfg files\nAllow writes to /etc/pki from OpenShift secrets dir\nWrite below root:\nLet runc write to /exec.fifo\nChange thread namespace\nOnly allow Kubernetes/Docker programs to use setns directly on the host\nLet children of kubelet/hyperkube use setns\nRun shell untrusted\nLet Puma reactor spawn shells\nDetect outbound connections to common miner pool ports\nWhen attempting to resolve crypto mining hostnames, exclude hosts that resolve to localhost/rfc1918 ips\nDefault Policy Changes\nRemove the default Policy Launch Privileged Container.\nThe rule it used is also in the existing default policy Inadvised Container Activity, so there's no change in rule coverage.\nNew default policies Payment Card Industry Data Security Standard (PCI DSS) and NIST 800-190 Application Container Security Guide, which are disabled by default, contain rules specifically related to PCI and NIST standards.\n0.7.0\n","url":"https://docs.sysdig.com/en/release-notes/falco-rules-changelog/2020-archive/"},{"id":832,"title":"Falco Changelog 2019","content":" Commit Date\nRule Notes\nVersion of the Falco Rules Installer (On-Prem)\nDec 9, 2019\nExpand allowed_k8s_users list with default users created by Kops\nAdd macro calico_writing_envvars to whitelist of rule Write below etc\nUpdate operators with intersect\nAdd calico/node in the falco_privlieged_image list\nAdd amazon/amazon-ecs-agent in falco_sensitive_mounts_image list\nAdd hyperkube to the whitelist of rule\nSet Setuid or Setgit bit\nAdd docker-runc-cur to container_entrypoint macro\nAdd a rule to detect Kubernetes client tool in container\nAdd rules Contact cloud metadata service from container and Packet socket created in container to policy Suspicious Container Activity\nUpdate macro exe_running_docker_save\nAdd exe_running_docker_save as exception to rules Modify Shell Configuration File, and Update Package Repository\nCreate macro automount_using_mtab and add it as exception to rule Write below etc\nUpdate macro k8s_api_server with Kubernetes headless service name\nAdd placeholder macro user_known_package_manager_in_container to rule Launch Package Management Process in Container\nAdd kubelet to list user_known_chmod_applications\nCreate macro user_known_k8s_client_container and add it as exception to rule The docker client is executed in a container\nAdd more directories to Sensitive mounts rules\n0.6.0\nOct 9, 2019\nAdd rule Delete or rename shell history (a better version of Delete Bash History) to policy Suspicious Filesystem Changes\nAdd rule Detect crypto miners using the Stratum protocol to policy Suspicious Container Activity\nAdd a new policy, Access Cryptomining Network ,with a new rule Detect outbound connections to common miner pool ports associated (disabled by default)\nAdd new macros chmod and modify_repositories\nEnhance rules Update Package Repository, Set Setuid or Setgid bit, and Create Hidden Files or Directories\nAdd imagefluent/fluentd-kubernetes-daemonset to macro trusted_logging_images\n0.5.0\nAug 21, 2019\nUpdate rule Update Package Repository with modify action\nUpdate rule Delete Bash History with more bash history files\nUpdate rule Set Setuid or Setgid bit using system calls instead of process name\nUpdate rule Create Hidden Files or Directories with modify action\n0.4.9\nAug 1, 2019\nAdd /exec.fifo to known_root_files macro (GKE)\nAdd macro amazon_linux_running_python_yum as exception in rule Write below rpm database (Amazon Linux 2)\nAdd docker.io/google/cadvisor and docker.io/prom/node-exporter to list falco_sensitive_mount_images\n0.4.8\nJuly 23, 2019\nAdd image k8s.gcr.io/kube-proxy to list falco_privileged_images\nAdd runc to macro container_entrypoint\nAdd macro trusted_logging_images for rule Clear Log Activities\nAdd image docker.io/netdata/netdata to list falco_sensitive_mount_images\n0.4.7\nJuly 1, 2019\nAdd placeholder for user macro\nAdd rfc 1918 addresses\nAdd image prometheus-node-exporter to macro openshift_image\nAdd weaveworks_scope macro used by rule Change thread namespace\n0.4.6\nJune 20, 2019\nAdd whitelist to rules Change thread namespace and Non sudo setuid\n0.4.5\nJune 17, 2019\nAdd trusted_container macro back\n0.4.4\nJune 13, 2019\nExtend macro mkdir with syscall mkdirat Add placeholder for whitelist in rule Clear Log Activities\nAdd docker.io/ to the trusted images list\nAdd container.id and image in the rule output, except those rules with \"not container\" in condition\n0.4.3\nJune 6, 2019\nRemove image check from rancher_write_conf macro\nRemove healthcheck from rancher_writing_conf\nUpdate nginx_writing_conf macro\n0.3.7\nJune 5, 2019\nUpdated macro container_started\nIBM Cloud Kubernetes Service is a hosted Kubernetes from IBM\nAllow Ansible to run using Python 3\nFix egrep rule and ncat rule\nAdd Sematext Monitoring \u0026amp; Logging agents to trusted Kubernetes containers\n0.3.6\nMay 30, 2019\nAdd rules: remote file copy in container, create symlink over sensitive files\nIn macro prometheus_conf_writing_conf, use startswith instead of =\n0.3.5\nApr 18, 2019\nAdd MITRE tags to existing rules\nAdd new MITRE rules mainly for persistence category\n0.3.4\n","url":"https://docs.sysdig.com/en/release-notes/falco-rules-changelog/2019-archive/"},{"id":833,"title":"Scanning (Legacy)","content":" End of Life Notice: The Sysdig Legacy Scanning Engine will reach its End of Life (EOL) on December 31st, 2024. After this date, it will no longer be supported or maintained. Please upgrade to our New Scanning Engine before December 31st, 2024 to ensure continuous service and support. For assistance, contact our support team or your account representative.\nTwo Types of ScanningAs of May 2021, Sysdig Secure includes two different types of scanning for vulnerabilities:\nImage scanning: This includes all prior scanning tools, policies, alerts, etc. in Sysdig Secure and focuses on scanning the container images in an environment.\nHost scanning: This feature, deployed via the Node Analyzer, scans the host operating system, whether OS (e.g rpm, dpkg) or non-OS (e.g. Java packages, Ruby gems).\nHost scanning documentation is self-contained; the rest of the topics in this Scanning module concern image scanning.\nHow Sysdig Image Scanning WorksThe basic set up for image scanning is simple: provide registry information where your images are stored, trigger a scan, and review the results.\nBehind the scenes:\nImage contents are analyzed.\nThe contents report is evaluated against multiple vulnerability databases.\nIt is then compared against default or user-defined policies.\nResults are reported, both in Sysdig Secure and (if applicable) in a developer\u0026rsquo;s external CI tool.\nPrerequisites Network and port requirements\nImage Scanning requires access to an external vulnerability feed. To ensure proper access to the latest definitions, refer to the Network and Port requirements.\nWhitelisted IP for image scanning requests\nImage scanning requests and Splunk event forwards both originate from 18.209.200.129. To enable Sysdig to scan private repositories, your firewall will need to allow inbound requests from this IP address.\nImage Contents ReportedThe analysis generates a detailed report of the image contents, including:\nOfficial OS packages\nUnofficial OS packages\nConfiguration files\nCredentials files\nLocalization modules and software-specific installers:\nJavaScript with NPM\nPython PiP\nRuby with GEM\nJava/JVM with .jar archives\nImage metadata and configuration attributes\nVulnerability Databases UsedSysdig Secure continuously checks against a wide range of vulnerability databases, updating the Runtime scan results with any newly detected CVEs.\nThe current database list includes:\nCentos Debian Ruby Red Hat Ubuntu Python\nCVE NIST NPM Alpine NVD VulnDB\nSee also: Updating Vulnerability Feed in Airgapped Environments.\nUse CasesAs an organization, you define what is an acceptable, secure, reliable image running in your environment. Image scanning for the development pipeline follows a somewhat different flow than for security personnel.\nScanning During Container Development (DevOps)Use image scanning as part of your development pipeline, to check for best practices, vulnerabilities, and sensitive content.\nTo begin:\nAdd Registry: Add a registry where your images are stored, along with the credentials necessary to access them.\nIntegrate CI Tool: Integrate image scanning with an external CI tool, using the Jenkins plugin or building your own integration from a SysdigLabs solution.\nScan Image(s): The plugin or CLI integration triggers the image scanning process. Failed builds will be stopped, if so configured.\nReview Results (in CI tool): Developers can analyze the results in the integrated CI tool (Jenkins).\n(Optionally: add policies or refine the default policies to suit your needs, assign policies to particular images or tags, and configure alerts and notifications.)\nScanning Running Containers (Security Personnel)Security personnel uses image scanning to monitor which containers are running, what their scan status is, and whether new vulnerabilities are present in their images.\nAdd Registry: Add a registry where your images are stored, along with the credentials necessary to access them.\nScan Image(s): Trigger an image scan with the node image analyzer or manually (one-by-one).\nReview Results (in Sysdig Secure): Security personnel can analyze scan results in the Sysdig Secure image scanning UI.\n(Optionally: add policies or refine the default policies to suit your needs, assign policies to particular images or tags, and configure alerts and notifications.)\nImage Scanning requires access to an external vulnerability feed. To ensure proper access to the latest definitions, refer to the Network and Port requirements.\nAdd Scanning to Container RegistriesIn some cases, it is possible to integrate image scanning directly into a container registry and automatically trigger an event or action every time a new container is pushed into the registry. This feature is currently supported for the following container registry:\nAWS ECR ","url":"https://docs.sysdig.com/en/docs/sysdig-secure/vulnerabilities/scanning/"},{"id":834,"title":"","content":"Custom Registries and SHA256 in GKE AutopilotThis section explains how to work with custom registries, SHA256 digests, and the Google allow list when deploying Sysdig on GKE Autopilot. It also provides a list of approved versions and SHA256 digests.\nWhy This MattersGKE Autopilot allows workloads only from approved images, verified by their SHA256 digest.\nWhen using a custom registry, you must mirror the public image (sysdig/agent-slim) without altering the digest so it matches Google’s allow list.\nMirror public image to custom registryTo mirror the public sysdig/agent-slim to your custom registry without altering the digest, you can use skopeo with the following command:\nskopeo copy --multi-arch all --preserve-digests docker://quay.io/sysdig/agent-slim:14.1.1 docker://company-registry/sysdig/agent-slim:14.1.1 Set custom registry on Shield ChartYou can use the following table or run the command below to retrieve the proper SHA256 Digest\ndocker pull quay.io/sysdig/agent-slim:latest docker inspect quay.io/sysdig/agent-slim:latest --format=\u0026#34;{{index .RepoDigests 0}}\u0026#34; Then update the host.image section in your values.yaml:\nhost: image: registry: your_company_registry repository: sysdig kmodule_name: agent-kmodule shield_name: agent-slim tag: sha256:1111112222233333 List of Approved Versions and SHA256 DigestsThis table is updated when Google adds new SHA256 digests to the allow list. There may be a delay of ~10 business days after a new Sysdig release before its SHA is approved.\nSysdig Shield Version SHA256 Digest Approval Date by Google 13.9.1 sha256:14860d181a8b712c4150bb59e3ba0ff4be08959e2c45376b32c8eb7ff70461f9 2025-07-11 13.9.2 sha256:0dcdb6d70bab60dae4bf5f70c338f2feb9daeba514f1b8ad513ed24724c2a04d 2025-07-11 14.0.0 sha256:9d668dc0d3fc3db783bdf4ce5c4755c355ff7b3b401b7d0ad4c087d05ba270f9 2025-07-11 14.0.1 sha256:b1f5bf4677632c715e9a5cde9af8d36dd66f5e79c80aadfd4b74dc5cc310a570 2025-07-11 14.1.0 sha256:2c6401018cfe3f5fcbd0713b64b096c38d47de1b5cd6c11de4691912752263fc 2025-07-24 14.1.1 sha256:36366b082d8d45dfe44d995830a1c0b0293cb9df9e55c6ab8c389e800596c743 2025-08-07 14.2.0 sha256:cd9f6c5588280cdb60d07264b812f6635c57557020cdd131757e1c986431cd23 2025-09-09 14.2.1 sha256:f945768cbdd0672bb635de49622d24f7eba6b170214f9af8a9c3b0f02538548c 2025-09-11 14.2.2 sha256:8b9768427392315619c9f14a365e7461bb06c0b8b606a9dfee2e87dd32380c4b 2025-10-09 14.2.3 sha256:cb2c437afde546554e04dbc018c125c6ffb60a9878ce6b45a29d769d91782c4b 2025-11-05 14.2.4 sha256:c8e6924999390de58471c2ac82b211a0207a50047a1bd15654a678f2b3d1e26e 2025-12-09 14.2.5 sha256:64b9d77bbd1bb22f97a74198144dcfea62bb5cee7629091252694e9040058035 2025-12-09 14.3.0 sha256:281da13df130813a4f00171756046ac969150d36a9b0dd32a817d41502f19fe4 2025-12-09 14.3.1 sha256:1055002e0e8f88d62d62ea77a7383d44ef33e79ed6d07d3d6431a810421d30b7 2026-01-16 14.3.2 sha256:b6028d17b917e58302a601556546739f0ecec134fbc9ceeab0042f95a9fb9b3e 2026-01-16 14.4.0 sha256:7546019a9fc55650a5d73825b2ebfcd6f49f435102c35b87249ae163cb9cf22f 2026-02-18 14.4.1 sha256:579a0fbc9c32e4263b54444b60689f2c16caa1c4f5518430f9b71566a0870bd5 2026-03-23 14.5.0 sha256:5083e00914894b6425711250bdd38ff359c449c662fa03866c15376e03c558d5 2026-04-28 14.5.1 sha256:5bf984e15b7b4c6f183e2da891dfdfa2364086d40afc9f1dad8db9cb14dce266 2026-04-28 14.5.2 sha256:bd8395584ac718449ac6e68ba62eaff7efa55b1fe68c3e2ce47a358144e5c812 2026-04-28 14.6.0 sha256:83d8a9c31de8737413ede5c262eb4e90bed8122aa3806868bb96d4544e925450 2026-05-21 ","url":"https://docs.sysdig.com/en/docs/_snippets/gke-autopilot/"},{"id":835,"title":"","content":"Host AgentsHost agents entitlement and usage is reported in two sections:\nHost Agents - Current Usage Active host agents deployment type overview Current UsageThe section displays the number of currently connected agents, compared to the entitlement.\nThe bar on the left represents the agents included in the subscription, showing you how many slots you\u0026rsquo;re currently using, compared to those that are available.\nOn the right, the on-demand bar shows you how many additional agents you can connect, on top of the reserved entitlement. If your contract doesn\u0026rsquo;t include on-demand usage, this will be disabled, meaning that you can only fill the reserved available slots, after which, additional connections will be refused.\nActive Host Agents Deployment Type Overview This bar breaks down the currently deployed agents into different types:\nContainerised: The number of agents running in a containerized environment. Non-containerised - The number of agents running in a non-containerised environment. Unspecified - The number of agents running in an unknown environment. Update Sysdig Agent to version 12.18.0 or later to receive environment information. Agent ConnectionsAgents connect on a first-come, first-served basis. In the event of an over-subscription (more agents wanting to communicate than are licensed), they will attempt to reconnect on a periodic basis. Once an existing communicating instance goes down and disconnects, the next agent in the queue will connect.\nWhen shutting down a host for any reason, the agent\u0026rsquo;s license will not be immediately released. This permits the agent to retain its licensing slot for short outages or a reboot. The time-out interval can take up to 20 minutes, and if the connection has not been re-established within the interval the license will be released for use by the next host waiting to connect.\nThe distinction between reserved and on-demand agents is financial, not technical; when on-demand agents are used they perform exactly like reserved agents.\n","url":"https://docs.sysdig.com/en/docs/_snippets/subscription-host-agents/"},{"id":836,"title":"Reference Library for Amazon GuardDuty Falco Threat Detection Rules","content":" FieldsField Class: JSON Name Type Description json.value CHARBUF Extracts a value from a JSON-encoded input. Syntax is json.value[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) json.obj CHARBUF The full json message as a text string. json.rawtime CHARBUF The time of the event, identical to evt.rawtime. jevt.value CHARBUF Alias for json.value, provided for backwards compatibility. jevt.obj CHARBUF Alias for json.obj, provided for backwards compatibility. jevt.rawtime CHARBUF Alias for json.rawtime, provided for backwards compatibility. Field Class: GuardDuty Name Type Description guardduty.accountId CHARBUF GuardDuty account ID guardduty.region CHARBUF GuardDuty region guardduty.time CHARBUF GuardDuty last updated event time guardduty.id CHARBUF GuardDuty ID guardduty.arn CHARBUF GuardDuty ARN guardduty.type CHARBUF GuardDuty type guardduty.resourceType CHARBUF GuardDuty resource type guardduty.actionType CHARBUF GuardDuty action type guardduty.resourceRole CHARBUF GuardDuty resource role guardduty.eventFirstSeen CHARBUF GuardDuty event first seen guardduty.eventLastSeen CHARBUF GuardDuty event last seen guardduty.threatFilesSha256 LIST(CHARBUF) GuardDuty threat files SHA-256 guardduty.archived CHARBUF GuardDuty archived guardduty.count CHARBUF GuardDuty count guardduty.severity CHARBUF GuardDuty severity guardduty.title CHARBUF GuardDuty title guardduty.description CHARBUF GuardDuty description guardduty.EC2.instanceId CHARBUF GuardDuty EC2 instance ID guardduty.EC2.instanceType CHARBUF GuardDuty EC2 instance type guardduty.IAM.principalId CHARBUF GuardDuty IAM principal ID guardduty.IAM.userName CHARBUF GuardDuty IAM user name guardduty.S3.bucketNames LIST(CHARBUF) GuardDuty S3 bucket names guardduty.S3.permissions LIST(CHARBUF) GuardDuty S3 permissions guardduty.EKS.clusterName CHARBUF GuardDuty EKS cluster name guardduty.EKS.workloadName CHARBUF GuardDuty EKS workload name guardduty.EKS.namespace CHARBUF GuardDuty EKS namespace guardduty.EKS.containers LIST(CHARBUF) GuardDuty EKS containers guardduty.EKS.userName CHARBUF GuardDuty EKS user name guardduty.EKS.serviceAccount CHARBUF GuardDuty EKS service account guardduty.ECS.clusterName CHARBUF GuardDuty ECS cluster name guardduty.ECS.clusterStatus CHARBUF GuardDuty ECS cluster status guardduty.ECS.task CHARBUF GuardDuty ECS task guardduty.ECS.containers LIST(CHARBUF) GuardDuty ECS containers guardduty.container.runtime CHARBUF GuardDuty container runtime guardduty.container.name CHARBUF GuardDuty container name guardduty.container.image CHARBUF GuardDuty container image guardduty.container.privileged CHARBUF GuardDuty container privileged guardduty.RDS.dbInstanceId CHARBUF GuardDuty RDS DB instance ID guardduty.RDS.userName CHARBUF GuardDuty RDS user name guardduty.RDS.database CHARBUF GuardDuty RDS database guardduty.RDS.application CHARBUF GuardDuty RDS application guardduty.lambda.functionName CHARBUF GuardDuty Lambda function name guardduty.lambda.role CHARBUF GuardDuty Lambda role guardduty.runtime.exepath CHARBUF GuardDuty runtime executable path guardduty.runtime.procname CHARBUF GuardDuty runtime process name guardduty.runtime.euid CHARBUF GuardDuty runtime effective user ID guardduty.runtime.pid CHARBUF GuardDuty runtime process ID guardduty.runtime.user CHARBUF GuardDuty runtime user guardduty.runtime.cmdline CHARBUF GuardDuty runtime command line guardduty.runtime.scriptPath CHARBUF GuardDuty runtime script path guardduty.runtime.threatFilePath CHARBUF GuardDuty runtime threat file path guardduty.runtime.toolName CHARBUF GuardDuty runtime tool name guardduty.runtime.toolCategory CHARBUF GuardDuty runtime tool category guardduty.EBS.scannedVolumes LIST(CHARBUF) GuardDuty EBS scanned volumes guardduty.EBS.skippedVolumes LIST(CHARBUF) GuardDuty EBS skipped volumes guardduty.EBS.scanId CHARBUF GuardDuty EBS scan ID guardduty.EBS.scanType CHARBUF GuardDuty EBS scan type guardduty.EBS.scanSeverity CHARBUF GuardDuty EBS scan severity guardduty.EBS.highestThreatName CHARBUF GuardDuty EBS highest threat name guardduty.EBS.threats LIST(CHARBUF) GuardDuty EBS threats guardduty.EBS.maliciousFilesCount CHARBUF GuardDuty EBS malicious files count guardduty.awsApiAction.api CHARBUF GuardDuty AWS API action API guardduty.awsApiAction.ip CHARBUF GuardDuty AWS API action IP guardduty.awsApiAction.srcInstance CHARBUF GuardDuty AWS API action source instance guardduty.dnsAction.protocol CHARBUF GuardDuty DNS action protocol guardduty.dnsAction.blocked CHARBUF GuardDuty DNS action blocked guardduty.dnsAction.domain CHARBUF GuardDuty DNS action domain guardduty.k8sApiAction.uri CHARBUF GuardDuty Kubernetes API action URI guardduty.k8sApiAction.resourceName CHARBUF GuardDuty Kubernetes API action resource name guardduty.k8sApiAction.namespace CHARBUF GuardDuty Kubernetes API action namespace guardduty.k8sApiAction.ip CHARBUF GuardDuty Kubernetes API action IP guardduty.networkAction.ip CHARBUF GuardDuty network action IP guardduty.networkAction.port CHARBUF GuardDuty network action port guardduty.networkAction.protocol CHARBUF GuardDuty network action protocol guardduty.networkAction.direction CHARBUF GuardDuty network action direction guardduty.networkAction.blocked CHARBUF GuardDuty network action blocked guardduty.portProbeAction.ports LIST(CHARBUF) GuardDuty port probe action ports guardduty.portProbeAction.srcIPs LIST(CHARBUF) GuardDuty port probe action source IPs guardduty.portProbeAction.blocked CHARBUF GuardDuty port probe action blocked guardduty.rdsLoginAction.apps LIST(CHARBUF) GuardDuty RDS login action applications guardduty.rdsLoginAction.ip CHARBUF GuardDuty RDS login action IP ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/guardduty/"},{"id":837,"title":"Reference Library for AWS Cloudtrail Falco Threat Detection Rules","content":" FieldsField Class: JSON Name Type Description json.value CHARBUF Extracts a value from a JSON-encoded input. Syntax is json.value[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) json.obj CHARBUF The full json message as a text string. json.rawtime CHARBUF The time of the event, identical to evt.rawtime. jevt.value CHARBUF Alias for json.value, provided for backwards compatibility. jevt.obj CHARBUF Alias for json.obj, provided for backwards compatibility. jevt.rawtime CHARBUF Alias for json.rawtime, provided for backwards compatibility. Field Class: AWS CloudTrail Name Type Description ct.id CHARBUF the unique ID of the cloudtrail event (eventID in the json). ct.error CHARBUF The error code from the event. Will be \u0026ldquo;\u0026rdquo; (e.g. the NULL/empty/none value) if there was no error. ct.errormessage CHARBUF The description of an error. Will be \u0026ldquo;\u0026rdquo; (e.g. the NULL/empty/none value) if there was no error. ct.src CHARBUF the source of the cloudtrail event (eventSource in the json). ct.shortsrc CHARBUF the source of the cloudtrail event (eventSource in the json, without the \u0026lsquo;.amazonaws.com\u0026rsquo; trailer). ct.name CHARBUF the name of the cloudtrail event (eventName in the json). ct.user CHARBUF the user of the cloudtrail event (userIdentity.userName in the json). For AssumedRole events, this is the role name from sessionContext.sessionIssuer.userName. ct.originaluser CHARBUF the user name as seen in CloudTrail. For AssumedRole events, this is the session name extracted from userIdentity.arn or userIdentity.principalId. For all other identity types, this is userIdentity.userName. ct.user.accountid CHARBUF the account id of the user of the cloudtrail event. ct.user.identitytype CHARBUF the kind of user identity (e.g. Root, IAMUser,AWSService, etc.) ct.user.principalid CHARBUF A unique identifier for the user that made the request. ct.user.arn CHARBUF the Amazon Resource Name (ARN) of the user that made the request. ct.region CHARBUF the region of the cloudtrail event (awsRegion in the json). ct.response.subnetid CHARBUF the subnet ID included in the response. ct.response.reservationid CHARBUF the reservation ID included in the response. ct.response CHARBUF All response elements. ct.request.availabilityzone CHARBUF the availability zone included in the request. ct.request.cluster CHARBUF the cluster included in the request. ct.request.functionname CHARBUF the function name included in the request. ct.request.groupname CHARBUF the group name included in the request. ct.request.host CHARBUF the host included in the request ct.request.name CHARBUF the name of the entity being acted on in the request. ct.request.policy CHARBUF the policy included in the request ct.request.reason CHARBUF the reason included in the request. ct.request.target CHARBUF the target included in the request. ct.request.documentname CHARBUF the document name included in the request. ct.request.serialnumber CHARBUF the serial number provided in the request. ct.request.servicename CHARBUF the service name provided in the request. ct.request.subnetid CHARBUF the subnet ID provided in the request. ct.request.taskdefinition CHARBUF the task definition prrovided in the request. ct.request.username CHARBUF the username provided in the request. ct.request CHARBUF All request parameters. ct.srcip CHARBUF the IP address generating the event (sourceIPAddress in the json). ct.useragent CHARBUF the user agent generating the event (userAgent in the json). ct.info CHARBUF summary information about the event. This varies depending on the event type and, for some events, it contains event-specific details. ct.managementevent CHARBUF \u0026rsquo;true\u0026rsquo; if the event is a management event (AwsApiCall, AwsConsoleAction, AwsConsoleSignIn, or AwsServiceEvent), \u0026lsquo;false\u0026rsquo; otherwise. ct.readonly CHARBUF \u0026rsquo;true\u0026rsquo; if the event only reads information (e.g. DescribeInstances), \u0026lsquo;false\u0026rsquo; if the event modifies the state (e.g. RunInstances, CreateLoadBalancer\u0026hellip;). ct.requestid CHARBUF The value that identifies the request. ct.eventtype CHARBUF Identifies the type of event that generated the event record. ct.apiversion CHARBUF The API version associated with the AwsApiCall eventType value. ct.resources CHARBUF A list of resources accessed in the event. ct.recipientaccountid CHARBUF The account ID that received this event. ct.serviceeventdetails CHARBUF Identifies the service event, including what triggered the event and the result. ct.sharedeventid CHARBUF GUID generated by CloudTrail to uniquely identify CloudTrail events. ct.vpcendpointid CHARBUF Identifies the VPC endpoint in which requests were made. ct.eventcategory CHARBUF Shows the event category that is used in LookupEvents calls. ct.addendum.reason CHARBUF The reason that the event or some of its contents were missing. ct.addendum.updatedfields CHARBUF The event record fields that are updated by the addendum. ct.addendum.originalrequestid CHARBUF The original unique ID of the request. ct.addendum.originaleventid CHARBUF The original event ID. ct.sessioncredentialfromconsole CHARBUF Shows whether or not an event originated from an AWS Management Console session. ct.edgedevicedetails CHARBUF Information about edge devices that are targets of a request. ct.tlsdetails.tlsversion CHARBUF The TLS version of a request. ct.tlsdetails.ciphersuite CHARBUF The cipher suite (combination of security algorithms used) of a request. ct.tlsdetails.clientprovidedhostheader CHARBUF The client-provided host name used in the service API call. ct.additionaleventdata CHARBUF All additional event data attributes. s3.uri CHARBUF the s3 URI (s3:///). s3.bucket CHARBUF the bucket name for s3 events. s3.key CHARBUF the S3 key name. s3.bytes UINT64 the size of an s3 download or upload, in bytes. ec2.name CHARBUF the name of the ec2 instances, typically stored in the instance tags. ec2.imageid CHARBUF (Deprecated) the ID for the image used to run the ec2 instance in the response. Replace with ec2.imageids[0]. ec2.imageids LIST(CHARBUF) the list of image IDs for the ec2 instances involved. ecr.repository CHARBUF the name of the ecr Repository specified in the request. ecr.imagetag CHARBUF the tag of the image specified in the request. iam.role CHARBUF the IAM role specified in the request. iam.policy CHARBUF the IAM policy specified in the request. ct.request.rolename CHARBUF the role provided in the request. ct.targetaccountid CHARBUF The account ID that is the target of this event. ct.db CHARBUF the database instance identifier included in the request. ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/aws-cloudtrail/"},{"id":838,"title":"Reference Library for Azure Platform Logs Falco Threat Detection Rules","content":" FieldsField Class: JSON Name Type Description json.value CHARBUF Extracts a value from a JSON-encoded input. Syntax is json.value[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) json.obj CHARBUF The full json message as a text string. json.rawtime CHARBUF The time of the event, identical to evt.rawtime. jevt.value CHARBUF Alias for json.value, provided for backwards compatibility. jevt.obj CHARBUF Alias for json.obj, provided for backwards compatibility. jevt.rawtime CHARBUF Alias for json.rawtime, provided for backwards compatibility. Field Class: Azure Platform Logs Name Type Description azure.compute.containerregistry CHARBUF Azure Container Registry name azure.compute.functions CHARBUF Azure Function name azure.databases.sqlserver CHARBUF Azure SQL name azure.networking.virtualnetwork CHARBUF Azure Virtual Network name azure.location CHARBUF Azure location Display Name azure.resourceGroup CHARBUF Azure resource group name azure.resourceType CHARBUF Azure resource type azure.resourceId CHARBUF Azure resource ID azure.storage.blobservices.container CHARBUF Azure Blob Service container name azure.storage.storageaccounts CHARBUF Azure Storage Accounts azure.subscriptionId CHARBUF Azure Subscription ID azure.tenantId CHARBUF Azure Tenant ID azure.user CHARBUF Azure User name azure.requestBody CHARBUF Extracts from requestBody json a value in input. Syntax is azure.requestBody[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) azure.responseBody CHARBUF Extracts from responseBody json a value in input. Syntax is azure.responseBody[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) azure.statusMessage CHARBUF Extracts from statusMessage json a value in input. Syntax is azure.statusMessage[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) azure.time CHARBUF Timestamp of the event in ISO 8601 format ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/azure/"},{"id":839,"title":"Containers","content":"Migrate to the Host ShieldThe Sysdig Agent has evolved to be the Host Shield starting from version 13.6.1.\nPrerequisites Review Installation Requirements Understand Agent Drivers Collect the following: Sysdig Access Key Collector Address and Port for COLLECTOR and PORT API Endpoint to use for SYSDIG_API_ENDPOINT Install Docker. Install the Host ShieldTo install the Host Shield as a container using Docker Compose, create a docker-compose.yml file with the following content:\nIf you are using the eBPF driver, run: version: \u0026#39;3.8\u0026#39; services: sysdig-agent: image: quay.io/sysdig/agent-slim:14.0.0 container_name: sysdig-host-shield restart: always privileged: true network_mode: host pid: host shm_size: 512M environment: ACCESS_KEY: \u0026lt;ACCESS_KEY\u0026gt; COLLECTOR: \u0026lt;COLLECTOR_URL\u0026gt; COLLECTOR_PORT: \u0026lt;COLLECTOR_PORT\u0026gt; SYSDIG_AGENT_DRIVER: # Driver for the host agent (Accepted Values: kmod, legacy_ebpf, universal_ebpf (Linux Kernel ≥ 5. 8)) volumes: - /var/run/docker.sock:/host/var/run/docker.sock - /dev:/host/dev - /proc:/host/proc:ro - /boot:/host/boot:ro - /sys/kernel/debug:/sys/kernel/debug:ro If you are using the Legacy eBPF driver update the volumes section as following: volumes: - /var/run/docker.sock:/host/var/run/docker.sock - /dev:/host/dev - /proc:/host/proc:ro - /boot:/host/boot:ro - /sys/kernel/debug:/sys/kernel/debug:ro - /root/.sysdig:/root/.sysdig If you are using the kernel module driver update the volumes section as following: volumes: - /var/run/docker.sock:/host/var/run/docker.sock - /dev:/host/dev - /proc:/host/proc:ro - /boot:/host/boot:ro Parameter Breakdown: ACCESS_KEY: Your Sysdig Access Key. COLLECTOR: The Sysdig collector URL for your SaaS region. COLLECTOR_PORT: The port used by the Sysdig collector. Deploy the Host Shield Save the docker-compose.yml file in your working directory. Replace the following with your actual Sysdig configuration values: \u0026lt;ACCESS_KEY\u0026gt; \u0026lt;COLLECTOR_URL\u0026gt; \u0026lt;COLLECTOR_PORT\u0026gt; \u0026lt;API_URL\u0026gt; Start the container: docker compose up -d ","url":"https://docs.sysdig.com/en/sysdig-monitor/install-host-containers/"},{"id":840,"title":"Contributor Guidelines","content":"","url":"https://docs.sysdig.com/en/contributor-guidelines/"},{"id":841,"title":"Reference Library for Falco Threat Detection Rules","content":"FieldsIn a Threat Detection rule, a field refers to a specific attribute of an event captured from the raw event. Use fields to define conditions and outputs within the rules, and specify which events should trigger events or actions based on the conditions you specify. Fields help Sysdig Secure identify and respond to suspicious or unauthorized activities within your environment. This topic provides a comprehensive understanding of all the supported fields you can include in a Threat Detection rule. Refer to the source-specific pages linked below for fields available on non-syscall sources:\nLinux workload Windows workload Kubernetes Audit AWS Cloudtrail Amazon GuardDuty Azure Platform Logs Microsoft Entra ID GCP Audit Logs Okta Github ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/"},{"id":842,"title":"Reference Library for GCP Audit Logs Falco Threat Detection Rules","content":" FieldsField Class: JSON Name Type Description json.value CHARBUF Extracts a value from a JSON-encoded input. Syntax is json.value[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) json.obj CHARBUF The full json message as a text string. json.rawtime CHARBUF The time of the event, identical to evt.rawtime. jevt.value CHARBUF Alias for json.value, provided for backwards compatibility. jevt.obj CHARBUF Alias for json.obj, provided for backwards compatibility. jevt.rawtime CHARBUF Alias for json.rawtime, provided for backwards compatibility. Field Class: GCP Audit Logs Name Type Description gcp.user CHARBUF GCP principal, actor of the action gcp.callerIP CHARBUF Actor\u0026rsquo;s IP gcp.userAgent CHARBUF Actor\u0026rsquo;s User Agent gcp.authorizationInfo CHARBUF GCP authorization (JSON) gcp.serviceName CHARBUF GCP API service name gcp.policyDelta CHARBUF GCP service resource access policy delta gcp.request CHARBUF GCP API raw request (JSON) gcp.methodName CHARBUF GCP API service method executed gcp.cloudfunctions.function CHARBUF GCF name gcp.cloudsql.databaseId CHARBUF GCP SQL database ID gcp.compute.instanceId CHARBUF GCE instance ID gcp.compute.networkId CHARBUF GCP network ID gcp.compute.subnetwork CHARBUF GCP subnetwork name gcp.compute.subnetworkId CHARBUF GCP subnetwork ID gcp.dns.zone CHARBUF GCP DNS zone gcp.iam.serviceAccount CHARBUF GCP service account gcp.iam.serviceAccountId CHARBUF GCP IAM unique ID gcp.location CHARBUF GCP region gcp.logging.sink CHARBUF GCP logging sink gcp.projectId CHARBUF GCP project ID gcp.resourceName CHARBUF GCP resource name gcp.resourceType CHARBUF GCP resource type gcp.resourceLabels CHARBUF GCP resource labels (JSON) gcp.storage.bucket CHARBUF GCP bucket name gcp.time CHARBUF Timestamp of the event in RFC3339 format ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/gcp-audit/"},{"id":843,"title":"Reference Library for Github Falco Threat Detection Rules","content":" FieldsField Class: JSON Name Type Description json.value CHARBUF Extracts a value from a JSON-encoded input. Syntax is json.value[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) json.obj CHARBUF The full json message as a text string. json.rawtime CHARBUF The time of the event, identical to evt.rawtime. jevt.value CHARBUF Alias for json.value, provided for backwards compatibility. jevt.obj CHARBUF Alias for json.obj, provided for backwards compatibility. jevt.rawtime CHARBUF Alias for json.rawtime, provided for backwards compatibility. Field Class: Github Name Type Description github.type CHARBUF Message type, e.g. \u0026lsquo;star\u0026rsquo; or \u0026lsquo;repository\u0026rsquo;. github.action CHARBUF The github event action. This field typically qualifies the github.type field. For example, a message of type \u0026lsquo;star\u0026rsquo; can have action \u0026lsquo;created\u0026rsquo; or \u0026lsquo;deleted\u0026rsquo;. github.user CHARBUF Name of the user that triggered the event. github.repo CHARBUF (deprecated) URL of the git repository where the event occurred. Github Webhook payloads contain the repository property when the event occurs from activity in a repository. github.repo.url CHARBUF URL of the git repository where the event occurred. Github Webhook payloads contain the repository property when the event occurs from activity in a repository. github.repo.name CHARBUF Name of the git repository where the event occurred. Github Webhook payloads contain the repository property when the event occurs from activity in a repository. github.repo.description CHARBUF Description of the GitHub repository. github.org CHARBUF Name of the organization the git repository belongs to. github.owner CHARBUF Name of the repository\u0026rsquo;s owner. github.repo.public CHARBUF \u0026rsquo;true\u0026rsquo; if the repository affected by the action is public. \u0026lsquo;false\u0026rsquo; otherwise. github.collaborator.name CHARBUF The member name for message that add or remove users. github.collaborator.role CHARBUF The member name for message that add or remove users. github.webhook.id CHARBUF When a new webhook has been created, the webhook id. github.webhook.type CHARBUF When a new webhook has been created, the webhook type, e.g. \u0026lsquo;repository\u0026rsquo;. github.commit.modified CHARBUF Comma separated list of files that have been modified. ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/github/"},{"id":844,"title":"Reference Library for Kubernetes Audit Falco Threat Detection Rules","content":" FieldsField Class: JSON Name Type Description json.value CHARBUF Extracts a value from a JSON-encoded input. Syntax is json.value[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) json.obj CHARBUF The full json message as a text string. json.rawtime CHARBUF The time of the event, identical to evt.rawtime. jevt.value CHARBUF Alias for json.value, provided for backwards compatibility. jevt.obj CHARBUF Alias for json.obj, provided for backwards compatibility. jevt.rawtime CHARBUF Alias for json.rawtime, provided for backwards compatibility. Field Class: Kubernetes Audit Name Type Description ka.auditid CHARBUF The unique id of the audit event ka.stage CHARBUF Stage of the request (e.g. RequestReceived, ResponseComplete, etc.) ka.auth.decision CHARBUF The authorization decision ka.auth.reason CHARBUF The authorization reason ka.user.name CHARBUF The user name performing the request ka.user.groups LIST(CHARBUF) The groups to which the user belongs ka.impuser.name CHARBUF The impersonated user name ka.verb CHARBUF The action being performed ka.uri CHARBUF The request URI as sent from client to server ka.uri.param CHARBUF The value of a given query parameter in the uri (e.g. when uri=/foo?key=val, ka.uri.param[key] is val). ka.target.name CHARBUF The target object name ka.target.namespace CHARBUF The target object namespace ka.target.resource CHARBUF The target object resource ka.target.subresource CHARBUF The target object subresource ka.req.binding.subjects LIST(CHARBUF) When the request object refers to a cluster role binding, the subject (e.g. account/users) being linked by the binding ka.req.binding.role CHARBUF When the request object refers to a cluster role binding, the role being linked by the binding ka.req.binding.subject.has_name CHARBUF Deprecated, always returns \u0026ldquo;N/A\u0026rdquo;. Only provided for backwards compatibility ka.req.configmap.name CHARBUF If the request object refers to a configmap, the configmap name ka.req.configmap.obj CHARBUF If the request object refers to a configmap, the entire configmap object ka.req.pod.containers.image LIST(CHARBUF) When the request object refers to a pod, the container\u0026rsquo;s images. ka.req.container.image CHARBUF Deprecated by ka.req.pod.containers.image. Returns the image of the first container only ka.req.pod.containers.image.repository LIST(CHARBUF) The same as req.container.image, but only the repository part (e.g. falcosecurity/falco). ka.req.container.image.repository CHARBUF Deprecated by ka.req.pod.containers.image.repository. Returns the repository of the first container only ka.req.pod.host_ipc CHARBUF When the request object refers to a pod, the value of the hostIPC flag. ka.req.pod.host_network CHARBUF When the request object refers to a pod, the value of the hostNetwork flag. ka.req.container.host_network CHARBUF Deprecated alias for ka.req.pod.host_network ka.req.pod.host_pid CHARBUF When the request object refers to a pod, the value of the hostPID flag. ka.req.pod.containers.host_port LIST(CHARBUF) When the request object refers to a pod, all container\u0026rsquo;s hostPort values. ka.req.pod.containers.privileged LIST(CHARBUF) When the request object refers to a pod, the value of the privileged flag for all containers. ka.req.container.privileged CHARBUF Deprecated by ka.req.pod.containers.privileged. Returns true if any container has privileged=true ka.req.pod.containers.allow_privilege_escalation LIST(CHARBUF) When the request object refers to a pod, the value of the allowPrivilegeEscalation flag for all containers ka.req.pod.containers.read_only_fs LIST(CHARBUF) When the request object refers to a pod, the value of the readOnlyRootFilesystem flag for all containers ka.req.pod.run_as_user CHARBUF When the request object refers to a pod, the runAsUser uid specified in the security context for the pod. See \u0026hellip;.containers.run_as_user for the runAsUser for individual containers ka.req.pod.containers.run_as_user LIST(CHARBUF) When the request object refers to a pod, the runAsUser uid for all containers ka.req.pod.containers.eff_run_as_user LIST(CHARBUF) When the request object refers to a pod, the initial uid that will be used for all containers. This combines information from both the pod and container security contexts and uses 0 if no uid is specified ka.req.pod.run_as_group CHARBUF When the request object refers to a pod, the runAsGroup gid specified in the security context for the pod. See \u0026hellip;.containers.run_as_group for the runAsGroup for individual containers ka.req.pod.containers.run_as_group LIST(CHARBUF) When the request object refers to a pod, the runAsGroup gid for all containers ka.req.pod.containers.eff_run_as_group LIST(CHARBUF) When the request object refers to a pod, the initial gid that will be used for all containers. This combines information from both the pod and container security contexts and uses 0 if no gid is specified ka.req.pod.containers.proc_mount LIST(CHARBUF) When the request object refers to a pod, the procMount types for all containers ka.req.role.rules LIST(CHARBUF) When the request object refers to a role/cluster role, the rules associated with the role ka.req.role.rules.apiGroups LIST(CHARBUF) When the request object refers to a role/cluster role, the api groups associated with the role\u0026rsquo;s rules ka.req.role.rules.nonResourceURLs LIST(CHARBUF) When the request object refers to a role/cluster role, the non resource urls associated with the role\u0026rsquo;s rules ka.req.role.rules.verbs LIST(CHARBUF) When the request object refers to a role/cluster role, the verbs associated with the role\u0026rsquo;s rules ka.req.role.rules.resources LIST(CHARBUF) When the request object refers to a role/cluster role, the resources associated with the role\u0026rsquo;s rules ka.req.pod.fs_group CHARBUF When the request object refers to a pod, the fsGroup gid specified by the security context. ka.req.pod.supplemental_groups LIST(CHARBUF) When the request object refers to a pod, the supplementalGroup gids specified by the security context. ka.req.pod.containers.add_capabilities LIST(CHARBUF) When the request object refers to a pod, all capabilities to add when running the container. ka.req.service.type CHARBUF When the request object refers to a service, the service type ka.req.service.ports LIST(CHARBUF) When the request object refers to a service, the service\u0026rsquo;s ports ka.req.pod.volumes.hostpath LIST(CHARBUF) When the request object refers to a pod, all hostPath paths specified for all volumes ka.req.volume.hostpath CHARBUF Deprecated by ka.req.pod.volumes.hostpath. Return true if the provided (host) path prefix is used by any volume ka.req.pod.volumes.flexvolume_driver LIST(CHARBUF) When the request object refers to a pod, all flexvolume drivers specified for all volumes ka.req.pod.volumes.volume_type LIST(CHARBUF) When the request object refers to a pod, all volume types for all volumes ka.resp.name CHARBUF The response object name ka.response.code CHARBUF The response code ka.response.reason CHARBUF The response reason (usually present only for failures) ka.useragent CHARBUF The useragent of the client who made the request to the apiserver ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/kube-audit/"},{"id":845,"title":"Reference Library for Linux workloads Falco Threat Detection Rules","content":" FieldsField Class: evtEvent fields applicable to syscall events. Note that for most events you can access the individual arguments/parameters of each syscall via evt.arg, e.g. evt.arg.filename.\nName Type Description Linux versions Serverless versions evt.num UINT64 event number. all all evt.time CHARBUF event timestamp as a time string that includes the nanosecond part. all all evt.time.s CHARBUF event timestamp as a time string with no nanoseconds. all all evt.time.iso8601 CHARBUF event timestamp in ISO 8601 format, including nanoseconds and time zone offset (in UTC). all all evt.datetime CHARBUF event timestamp as a time string that includes the date. all all evt.datetime.s CHARBUF event timestamp as a datetime string with no nanoseconds. all all evt.rawtime ABSTIME absolute event timestamp, i.e. nanoseconds from epoch. all all evt.rawtime.s ABSTIME integer part of the event timestamp (e.g. seconds since epoch). all all evt.rawtime.ns ABSTIME fractional part of the absolute event timestamp. all all evt.reltime RELTIME number of nanoseconds from the beginning of the capture. all all evt.reltime.s RELTIME number of seconds from the beginning of the capture. all all evt.reltime.ns RELTIME fractional part (in ns) of the time from the beginning of the capture. all all evt.pluginname CHARBUF if the event comes from a plugin-defined event source, the name of the plugin that generated it. The plugin must be currently loaded. all all evt.plugininfo CHARBUF if the event comes from a plugin-defined event source, a summary of the event as formatted by the plugin. The plugin must be currently loaded. all all evt.source CHARBUF the name of the source that produced the event. all all evt.is_async BOOL \u0026rsquo;true\u0026rsquo; for asynchronous events, \u0026lsquo;false\u0026rsquo; otherwise. all all evt.asynctype CHARBUF If the event is asynchronous, the type of the event (e.g. \u0026lsquo;container\u0026rsquo;). all all evt.hostname CHARBUF The hostname of the underlying host can be customized by setting an environment variable (e.g. FALCO_HOSTNAME for the Falco agent). This is valuable in Kubernetes setups, where the hostname can match the pod name particularly in DaemonSet deployments. To achieve this, assign Kubernetes\u0026rsquo; spec.nodeName to the environment variable. Notably, spec.nodeName generally includes the cluster name. all all evt.latency RELTIME delta between an exit event and the correspondent enter event, in nanoseconds. all all evt.latency.s RELTIME integer part of the event latency delta. all all evt.latency.ns RELTIME fractional part of the event latency delta. all all evt.latency.human CHARBUF delta between an exit event and the correspondent enter event, as a human readable string (e.g. 10.3ms). all all evt.deltatime RELTIME delta between this event and the previous event, in nanoseconds. all all evt.deltatime.s RELTIME integer part of the delta between this event and the previous event. all all evt.deltatime.ns RELTIME fractional part of the delta between this event and the previous event. all all evt.dir CHARBUF event direction can be either \u0026lsquo;\u0026gt;\u0026rsquo; for enter events or \u0026lsquo;\u0026lt;\u0026rsquo; for exit events. all all evt.type CHARBUF The name of the event (e.g. \u0026lsquo;open\u0026rsquo;). all all evt.type.is UINT32 allows one to specify an event type, and returns 1 for events that are of that type. For example, evt.type.is.open returns 1 for open events, 0 for any other event. all all syscall.type CHARBUF For system call events, the name of the system call (e.g. \u0026lsquo;open\u0026rsquo;). Unset for other events (e.g. switch or internal events). Use this field instead of evt.type if you need to make sure that the filtered/printed value is actually a system call. all all evt.category CHARBUF The event category. Example values are \u0026lsquo;file\u0026rsquo; (for file operations like open and close), \u0026rsquo;net\u0026rsquo; (for network operations like socket and bind), memory (for things like brk or mmap), and so on. all all evt.cpu INT16 number of the CPU where this event happened. all all evt.args CHARBUF all the event arguments, aggregated into a single string. all all evt.arg CHARBUF one of the event arguments specified by name or by number. Some events (e.g. return codes or FDs) will be converted into a text representation when possible. E.g. \u0026rsquo;evt.arg.fd\u0026rsquo; or \u0026rsquo;evt.arg[0]\u0026rsquo;. all all evt.rawarg DYNAMIC one of the event arguments specified by name. E.g. \u0026rsquo;evt.rawarg.fd\u0026rsquo;. all all evt.info CHARBUF for most events, this field returns the same value as evt.args. However, for some events (like writes to /dev/log) it provides higher level information coming from decoding the arguments. all all evt.buffer BYTEBUF the binary data buffer for events that have one, like read(), recvfrom(), etc. Use this field in filters with \u0026lsquo;contains\u0026rsquo; to search into I/O data buffers. all all evt.buflen UINT64 the length of the binary data buffer for events that have one, like read(), recvfrom(), etc. all all evt.res CHARBUF event return value, as a string. If the event failed, the result is an error code string (e.g. \u0026lsquo;ENOENT\u0026rsquo;), otherwise the result is the string \u0026lsquo;SUCCESS\u0026rsquo;. all all evt.rawres INT64 event return value, as a number (e.g. -2). Useful for range comparisons. all all evt.failed BOOL \u0026rsquo;true\u0026rsquo; for events that returned an error status. all all evt.is_io BOOL \u0026rsquo;true\u0026rsquo; for events that read or write to FDs, like read(), send, recvfrom(), etc. all all evt.is_io_read BOOL \u0026rsquo;true\u0026rsquo; for events that read from FDs, like read(), recv(), recvfrom(), etc. all all evt.is_io_write BOOL \u0026rsquo;true\u0026rsquo; for events that write to FDs, like write(), send(), etc. all all evt.io_dir CHARBUF \u0026lsquo;r\u0026rsquo; for events that read from FDs, like read(); \u0026lsquo;w\u0026rsquo; for events that write to FDs, like write(). all all evt.is_wait BOOL \u0026rsquo;true\u0026rsquo; for events that make the thread wait, e.g. sleep(), select(), poll(). all all evt.wait_latency RELTIME for events that make the thread wait (e.g. sleep(), select(), poll()), this is the time spent waiting for the event to return, in nanoseconds. all all evt.is_syslog BOOL \u0026rsquo;true\u0026rsquo; for events that are writes to /dev/log. all all evt.count UINT32 This filter field always returns 1. all all evt.count.error UINT32 This filter field returns 1 for events that returned with an error. all all evt.count.error.file UINT32 This filter field returns 1 for events that returned with an error and are related to file I/O. all all evt.count.error.net UINT32 This filter field returns 1 for events that returned with an error and are related to network I/O. all all evt.count.error.memory UINT32 This filter field returns 1 for events that returned with an error and are related to memory allocation. all all evt.count.error.other UINT32 This filter field returns 1 for events that returned with an error and are related to none of the previous categories. all all evt.count.exit UINT32 This filter field returns 1 for exit events. all all evt.around UINT64 Accepts the event if it\u0026rsquo;s around the specified time interval. The syntax is evt.around[T]=D, where T is the value returned by %evt.rawtime for the event and D is a delta in milliseconds. For example, evt.around[1404996934793590564]=1000 will return the events with timestamp with one second before the timestamp and one second after it, for a total of two seconds of capture. all all evt.abspath CHARBUF Absolute path calculated from dirfd and name during syscalls like renameat and symlinkat. Use \u0026rsquo;evt.abspath.src\u0026rsquo; or \u0026rsquo;evt.abspath.dst\u0026rsquo; for syscalls that support multiple paths. all all evt.is_open_read BOOL \u0026rsquo;true\u0026rsquo; for open/openat/openat2/open_by_handle_at events where the path was opened for reading all all evt.is_open_write BOOL \u0026rsquo;true\u0026rsquo; for open/openat/openat2/open_by_handle_at events where the path was opened for writing all all evt.is_open_exec BOOL \u0026rsquo;true\u0026rsquo; for open/openat/openat2/open_by_handle_at or creat events where a file is created with execute permissions all all evt.is_open_create BOOL \u0026rsquo;true\u0026rsquo; for for open/openat/openat2/open_by_handle_at events where a file is created. all all Field Class: processAdditional information about the process and thread executing the syscall event.\nName Type Description Linux versions Serverless versions proc.exe CHARBUF The first command-line argument (i.e., argv[0]), typically the executable name or a custom string as specified by the user. It is primarily obtained from syscall arguments, truncated after 4096 bytes, or, as a fallback, by reading /proc/PID/cmdline, in which case it may be truncated after 1024 bytes. This field may differ from the last component of proc.exepath, reflecting how command invocation and execution paths can vary. all all proc.pexe CHARBUF The proc.exe (first command line argument argv[0]) of the parent process. all all proc.aexe CHARBUF The proc.exe (first command line argument argv[0]) for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.aexe[1] retrieves the proc.exe of the parent process, proc.aexe[2] retrieves the proc.exe of the grandparent process, and so on. The current process\u0026rsquo;s proc.exe line can be obtained using proc.aexe[0]. When used without any arguments, proc.aexe is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.aexe endswith java to match any process ancestor whose proc.exe ends with the term java. all all proc.exepath CHARBUF The full executable path of a process, resolving to the canonical path for symlinks. This is primarily obtained from the kernel, or as a fallback, by reading /proc/PID/exe (in the latter case, the path is truncated after 1024 bytes). For eBPF drivers, due to verifier limits, path components may be truncated to 24 for legacy eBPF on kernel \u0026lt;5.2, 48 for legacy eBPF on kernel \u0026gt;=5.2, or 96 for modern eBPF. all all proc.pexepath CHARBUF The proc.exepath (full executable path) of the parent process. all all proc.aexepath CHARBUF The proc.exepath (full executable path) for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.aexepath[1] retrieves the proc.exepath of the parent process, proc.aexepath[2] retrieves the proc.exepath of the grandparent process, and so on. The current process\u0026rsquo;s proc.exepath line can be obtained using proc.aexepath[0]. When used without any arguments, proc.aexepath is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.aexepath endswith java to match any process ancestor whose path ends with the term java. all all proc.name CHARBUF The process name (truncated after 16 characters) generating the event (task-\u0026gt;comm). Truncation is determined by kernel settings and not by Falco. This field is collected from the syscalls args or, as a fallback, extracted from /proc/PID/comm. The name of the process and the name of the executable file on disk (if applicable) can be different if a process is given a custom name which is often the case for example for java applications. all all proc.pname CHARBUF The proc.name (truncated after 16 characters) of the parent process. all all proc.aname CHARBUF The proc.name (truncated after 16 characters) for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.aname[1] retrieves the proc.name of the parent process, proc.aname[2] retrieves the proc.name of the grandparent process, and so on. The current process\u0026rsquo;s proc.name line can be obtained using proc.aname[0]. When used without any arguments, proc.aname is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.aname=bash to match any process ancestor whose name is bash. all all proc.args CHARBUF The arguments passed on the command line when starting the process generating the event excluding argv[0] (truncated after 4096 bytes). This field is collected from the system call arguments, or as a fallback, extracted from /proc/PID/cmdline, can be accessed by specifying proc.args[INDEX], e.g., proc.args[0] or proc.args[1]. The indexing is zero-based, meaning proc.args[0] refers to the first command-line argument passed, rather than argv[0]. all all proc.aargs CHARBUF The arguments passed on the command line when starting the process generating the event for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.aargs[1] retrieves the arguments passed on the command line of the parent process, proc.aargs[2] retrieves the proc.args of the grandparent process, and so on. The current process\u0026rsquo;s arguments passed on the command line can be obtained using proc.aargs[0]. When used without any arguments, proc.aargs is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.aargs contains base64 to match any process ancestor whose arguments passed on the command line contains the term base64. 14.3.0 and above 6.2.0 and above proc.cmdline CHARBUF The concatenation of proc.name + proc.args (truncated after 4096 bytes) when starting the process generating the event. all all proc.pcmdline CHARBUF The proc.cmdline (full command line (proc.name + proc.args)) of the parent process. all all proc.acmdline CHARBUF The full command line (proc.name + proc.args) for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.acmdline[1] retrieves the full command line of the parent process, proc.acmdline[2] retrieves the proc.cmdline of the grandparent process, and so on. The current process\u0026rsquo;s full command line can be obtained using proc.acmdline[0]. When used without any arguments, proc.acmdline is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.acmdline contains base64 to match any process ancestor whose command line contains the term base64. all all proc.cmdnargs UINT64 The number of command line args (proc.args). all all proc.cmdlenargs UINT64 The total count of characters / length of the command line args (proc.args) combined excluding whitespaces between args. all all proc.exeline CHARBUF The full command line, with exe as first argument (proc.exe + proc.args) when starting the process generating the event. all all proc.env CHARBUF The environment variables of the process generating the event as concatenated string \u0026lsquo;ENV_NAME=value ENV_NAME1=value1\u0026rsquo;. Can also be used to extract the value of a known env variable, e.g. proc.env[ENV_NAME]. all all proc.aenv CHARBUF [EXPERIMENTAL] This field can be used in three flavors: (1) as a filter checking all parents, e.g. \u0026lsquo;proc.aenv contains xyz\u0026rsquo;, which is similar to the familiar \u0026lsquo;proc.aname contains xyz\u0026rsquo; approach, (2) checking the proc.env of a specified level of the parent, e.g. \u0026lsquo;proc.aenv[2]\u0026rsquo;, which is similar to the familiar \u0026lsquo;proc.aname[2]\u0026rsquo; approach, or (3) checking the first matched value of a known ENV_NAME in the parent lineage, such as \u0026lsquo;proc.aenv[ENV_NAME]\u0026rsquo; (across a max of 20 ancestor levels). This field may be deprecated or undergo breaking changes in future releases. Please use it with caution. all all proc.cwd CHARBUF The current working directory of the event. all all proc.loginshellid INT64 The pid of the oldest shell among the ancestors of the current process, if there is one. This field can be used to separate different user sessions. all all proc.tty UINT32 The controlling terminal of the process. 0 for processes without a terminal. all all proc.pid INT64 The id of the process generating the event. all all proc.ppid INT64 The pid of the parent of the process generating the event. all all proc.apid INT64 The pid for a specific process ancestor. You can access different levels of ancestors by using indices. For example, proc.apid[1] retrieves the pid of the parent process, proc.apid[2] retrieves the pid of the grandparent process, and so on. The current process\u0026rsquo;s pid can be obtained using proc.apid[0]. When used without any arguments, proc.apid is applicable only in filters and matches any of the process ancestors. For instance, you can use proc.apid=1337 to match any process ancestor whose pid is equal to 1337. all all proc.vpid INT64 The id of the process generating the event as seen from its current PID namespace. all all proc.pvpid INT64 The id of the parent process generating the event as seen from its current PID namespace. all all proc.sid INT64 The session id of the process generating the event. all all proc.sname CHARBUF The name of the current process\u0026rsquo;s session leader. This is either the process with pid=proc.sid or the eldest ancestor that has the same sid as the current process. all all proc.sid.exe CHARBUF The first command line argument argv[0] (usually the executable name or a custom one) of the current process\u0026rsquo;s session leader. This is either the process with pid=proc.sid or the eldest ancestor that has the same sid as the current process. all all proc.sid.exepath CHARBUF The full executable path of the current process\u0026rsquo;s session leader. This is either the process with pid=proc.sid or the eldest ancestor that has the same sid as the current process. all all proc.vpgid INT64 The process group id of the process generating the event, as seen from its current PID namespace. all all proc.vpgid.name CHARBUF The name of the current process\u0026rsquo;s process group leader. This is either the process with proc.vpgid == proc.vpid or the eldest ancestor that has the same vpgid as the current process. The description of proc.is_vpgid_leader offers additional insights. all all proc.vpgid.exe CHARBUF The first command line argument argv[0] (usually the executable name or a custom one) of the current process\u0026rsquo;s process group leader. This is either the process with proc.vpgid == proc.vpid or the eldest ancestor that has the same vpgid as the current process. The description of proc.is_vpgid_leader offers additional insights. all all proc.vpgid.exepath CHARBUF The full executable path of the current process\u0026rsquo;s process group leader. This is either the process with proc.vpgid == proc.vpid or the eldest ancestor that has the same vpgid as the current process. The description of proc.is_vpgid_leader offers additional insights. all all proc.pgid INT64 The process group id of the process generating the event, as seen from host PID namespace. 13.6.0 and above all proc.pgid.name CHARBUF The name of the current process\u0026rsquo;s process group leader. This is either the process with proc.pgid == proc.pid or the eldest ancestor that has the same pgid as the current process. The description of proc.is_pgid_leader offers additional insights. 13.6.0 and above all proc.pgid.exe CHARBUF The first command line argument argv[0] (usually the executable name or a custom one) of the current process\u0026rsquo;s process group leader. This is either the process with proc.pgid == proc.pid or the eldest ancestor that has the same pgid as the current process. The description of proc.is_pgid_leader offers additional insights. 13.6.0 and above all proc.pgid.exepath CHARBUF The full executable path of the current process\u0026rsquo;s process group leader. This is either the process with proc.pgid == proc.pid or the eldest ancestor that has the same pgid as the current process. The description of proc.is_pgid_leader offers additional insights. 13.6.0 and above all proc.duration RELTIME Number of nanoseconds since the process started. all all proc.ppid.duration RELTIME Number of nanoseconds since the parent process started. all all proc.pid.ts RELTIME Start of process as epoch timestamp in nanoseconds. all all proc.ppid.ts RELTIME Start of parent process as epoch timestamp in nanoseconds. all all proc.is_exe_writable BOOL \u0026rsquo;true\u0026rsquo; if this process\u0026rsquo; executable file is writable by the same user that spawned the process. all all proc.is_exe_upper_layer BOOL \u0026rsquo;true\u0026rsquo; if this process\u0026rsquo; executable file is in upper layer in overlayfs. This field value can only be trusted if the underlying kernel version is greater or equal than 3.18.0, since overlayfs was introduced at that time. all all proc.is_exe_lower_layer BOOL \u0026rsquo;true\u0026rsquo; if this process\u0026rsquo; executable file is in lower layer in overlayfs. This field value can only be trusted if the underlying kernel version is greater or equal than 3.18.0, since overlayfs was introduced at that time. 13.5.0 and above all proc.is_exe_from_memfd BOOL \u0026rsquo;true\u0026rsquo; if the executable file of the current process is an anonymous file created using memfd_create() and is being executed by referencing its file descriptor (fd). This type of file exists only in memory and not on disk. Relevant to detect malicious in-memory code injection. Requires kernel version greater or equal to 3.17.0. all all proc.is_sid_leader BOOL \u0026rsquo;true\u0026rsquo; if this process is the leader of the process session, proc.sid == proc.vpid. For host processes vpid reflects pid. all all proc.is_vpgid_leader BOOL \u0026rsquo;true\u0026rsquo; if this process is the leader of the virtual process group, proc.vpgid == proc.vpid. For host processes vpgid and vpid reflect pgid and pid. Can help to distinguish if the process was \u0026lsquo;directly\u0026rsquo; executed for instance in a tty (similar to bash history logging, is_vpgid_leader would be \u0026rsquo;true\u0026rsquo;) or executed as descendent process in the same process group which for example is the case when subprocesses are spawned from a script (is_vpgid_leader would be \u0026lsquo;false\u0026rsquo;). all all proc.is_pgid_leader BOOL \u0026rsquo;true\u0026rsquo; if this process is the leader of the process group, proc.pgid == proc.pid. Can help to distinguish if the process was \u0026lsquo;directly\u0026rsquo; executed for instance in a tty (similar to bash history logging, is_pgid_leader would be \u0026rsquo;true\u0026rsquo;) or executed as descendent process in the same process group which for example is the case when subprocesses are spawned from a script (is_pgid_leader would be \u0026lsquo;false\u0026rsquo;). 13.6.0 and above all proc.exe_ino INT64 The inode number of the executable file on disk. Can be correlated with fd.ino. all all proc.exe_ino.ctime ABSTIME Last status change time of executable file (inode-\u0026gt;ctime) as epoch timestamp in nanoseconds. Time is changed by writing or by setting inode information e.g. owner, group, link count, mode etc. all all proc.exe_ino.mtime ABSTIME Last modification time of executable file (inode-\u0026gt;mtime) as epoch timestamp in nanoseconds. Time is changed by file modifications, e.g. by mknod, truncate, utime, write of more than zero bytes etc. For tracking changes in owner, group, link count or mode, use proc.exe_ino.ctime instead. all all proc.exe_ino.ctime_duration_proc_start ABSTIME Number of nanoseconds between modifying status of executable image and spawning a new process using the changed executable image. all all proc.exe_ino.ctime_duration_pidns_start ABSTIME Number of nanoseconds between PID namespace start ts and ctime exe file if PID namespace start predates ctime. all all proc.pidns_init_start_ts UINT64 Start of PID namespace (container or non container pid namespace) as epoch timestamp in nanoseconds. all all thread.cap_permitted CHARBUF The permitted capabilities set all all thread.cap_inheritable CHARBUF The inheritable capabilities set all all thread.cap_effective CHARBUF The effective capabilities set all all proc.fdopencount UINT64 Number of open FDs for the process all all proc.fdlimit INT64 Maximum number of FDs the process can open. all all proc.fdusage DOUBLE The ratio between open FDs and maximum available FDs for the process. all all proc.vmsize UINT64 Total virtual memory for the process (as kb). all all proc.vmrss UINT64 Resident non-swapped memory for the process (as kb). all all proc.vmswap UINT64 Swapped memory for the process (as kb). all all thread.pfmajor UINT64 Number of major page faults since thread start. all all thread.pfminor UINT64 Number of minor page faults since thread start. all all thread.tid INT64 The id of the thread generating the event. all all thread.ismain BOOL \u0026rsquo;true\u0026rsquo; if the thread generating the event is the main one in the process. all all thread.vtid INT64 The id of the thread generating the event as seen from its current PID namespace. all all thread.exectime RELTIME CPU time spent by the last scheduled thread, in nanoseconds. Exported by switch events only. all all thread.totexectime RELTIME Total CPU time, in nanoseconds since the beginning of the capture, for the current thread. Exported by switch events only. all all thread.cgroups CHARBUF All cgroups the thread belongs to, aggregated into a single string. all all thread.cgroup CHARBUF The cgroup the thread belongs to, for a specific subsystem. e.g. thread.cgroup.cpuacct. all all proc.nthreads UINT64 The number of alive threads that the process generating the event currently has, including the leader thread. Please note that the leader thread may not be here, in that case \u0026lsquo;proc.nthreads\u0026rsquo; and \u0026lsquo;proc.nchilds\u0026rsquo; are equal all all proc.nchilds UINT64 The number of alive not leader threads that the process generating the event currently has. This excludes the leader thread. all all thread.cpu DOUBLE The CPU consumed by the thread in the last second. all all thread.cpu.user DOUBLE The user CPU consumed by the thread in the last second. all all thread.cpu.system DOUBLE The system CPU consumed by the thread in the last second. all all thread.vmsize UINT64 For the process main thread, this is the total virtual memory for the process (as kb). For the other threads, this field is zero. all all thread.vmrss UINT64 For the process main thread, this is the resident non-swapped memory for the process (as kb). For the other threads, this field is zero. all all proc.stdin.type CHARBUF The type of file descriptor 0, corresponding to stdin, of the process generating the event. 13.4.0 and above all proc.stdout.type CHARBUF The type of file descriptor 1, corresponding to stdout, of the process generating the event. 13.4.0 and above all proc.stderr.type CHARBUF The type of file descriptor 2, corresponding to stderr, of the process generating the event. 13.4.0 and above all proc.stdin.name CHARBUF The name of the file descriptor 0, corresponding to stdin, of the process generating the event. 13.4.0 and above all proc.stdout.name CHARBUF The name of the file descriptor 1, corresponding to stdout, of the process generating the event. 13.4.0 and above all proc.stderr.name CHARBUF The name of the file descriptor 2, corresponding to stderr, of the process generating the event. 13.4.0 and above all Field Class: userInformation about the user executing the specific event.\nName Type Description Linux versions Serverless versions user.uid UINT32 user ID. all all user.name CHARBUF user name. all all user.homedir CHARBUF home directory of the user. all all user.shell CHARBUF user\u0026rsquo;s shell. all all user.loginuid INT64 audit user id (auid), internally the loginuid is of type uint32_t. However, if an invalid uid corresponding to UINT32_MAX is encountered, it is returned as -1 to support familiar filtering conditions. all all user.loginname CHARBUF audit user name (auid). all all Field Class: groupInformation about the user group.\nName Type Description Linux versions Serverless versions group.gid UINT32 group ID. all all group.name CHARBUF group name. all all Field Class: fdEvery syscall that has a file descriptor in its arguments has these fields set with information related to the file.\nName Type Description Linux versions Serverless versions fd.num INT64 the unique number identifying the file descriptor. all all fd.type CHARBUF type of FD. Can be \u0026lsquo;file\u0026rsquo;, \u0026lsquo;directory\u0026rsquo;, \u0026lsquo;ipv4\u0026rsquo;, \u0026lsquo;ipv6\u0026rsquo;, \u0026lsquo;unix\u0026rsquo;, \u0026lsquo;pipe\u0026rsquo;, \u0026rsquo;event\u0026rsquo;, \u0026lsquo;signalfd\u0026rsquo;, \u0026rsquo;eventpoll\u0026rsquo;, \u0026lsquo;inotify\u0026rsquo; \u0026lsquo;signalfd\u0026rsquo; or \u0026lsquo;memfd\u0026rsquo;. all all fd.typechar CHARBUF type of FD as a single character. Can be \u0026lsquo;f\u0026rsquo; for file, 4 for IPv4 socket, 6 for IPv6 socket, \u0026lsquo;u\u0026rsquo; for unix socket, p for pipe, \u0026rsquo;e\u0026rsquo; for eventfd, \u0026rsquo;s\u0026rsquo; for signalfd, \u0026rsquo;l\u0026rsquo; for eventpoll, \u0026lsquo;i\u0026rsquo; for inotify, \u0026lsquo;b\u0026rsquo; for bpf, \u0026lsquo;u\u0026rsquo; for userfaultd, \u0026lsquo;r\u0026rsquo; for io_uring, \u0026rsquo;m\u0026rsquo; for memfd ,\u0026lsquo;o\u0026rsquo; for unknown. all all fd.name CHARBUF FD full name. If the fd is a file, this field contains the full path. If the FD is a socket, this field contain the connection tuple. all all fd.directory CHARBUF If the fd is a file, the directory that contains it. all all fd.filename CHARBUF If the fd is a file, the filename without the path. all all fd.ip IPADDR matches the ip address (client or server) of the fd. all all fd.cip IPADDR client IP address. all all fd.sip IPADDR server IP address. all all fd.lip IPADDR local IP address. all all fd.rip IPADDR remote IP address. all all fd.port PORT matches the port (either client or server) of the fd. all all fd.cport PORT for TCP/UDP FDs, the client port. all all fd.sport PORT for TCP/UDP FDs, server port. all all fd.lport PORT for TCP/UDP FDs, the local port. all all fd.rport PORT for TCP/UDP FDs, the remote port. all all fd.l4proto CHARBUF the IP protocol of a socket. Can be \u0026rsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo;, \u0026lsquo;icmp\u0026rsquo; or \u0026lsquo;raw\u0026rsquo;. all all fd.sockfamily CHARBUF the socket family for socket events. Can be \u0026lsquo;ip\u0026rsquo; or \u0026lsquo;unix\u0026rsquo;. all all fd.is_server BOOL \u0026rsquo;true\u0026rsquo; if the process owning this FD is the server endpoint in the connection. all all fd.uid CHARBUF a unique identifier for the FD, created by chaining the FD number and the thread ID. all all fd.containername CHARBUF chaining of the container ID and the FD name. Useful when trying to identify which container an FD belongs to. all all fd.containerdirectory CHARBUF chaining of the container ID and the directory name. Useful when trying to identify which container a directory belongs to. all all fd.proto PORT matches the protocol (either client or server) of the fd. all all fd.cproto CHARBUF for TCP/UDP FDs, the client protocol. all all fd.sproto CHARBUF for TCP/UDP FDs, server protocol. all all fd.lproto CHARBUF for TCP/UDP FDs, the local protocol. all all fd.rproto CHARBUF for TCP/UDP FDs, the remote protocol. all all fd.net IPNET matches the IP network (client or server) of the fd. all all fd.cnet IPNET matches the client IP network of the fd. all all fd.snet IPNET matches the server IP network of the fd. all all fd.lnet IPNET matches the local IP network of the fd. all all fd.rnet IPNET matches the remote IP network of the fd. all all fd.connected BOOL for TCP/UDP FDs, \u0026rsquo;true\u0026rsquo; if the socket is connected. all all fd.name_changed BOOL True when an event changes the name of an fd used by this event. This can occur in some cases such as udp connections where the connection tuple changes. all all fd.cip.name CHARBUF Domain name associated with the client IP address. all all fd.sip.name CHARBUF Domain name associated with the server IP address. all all fd.lip.name CHARBUF Domain name associated with the local IP address. all all fd.rip.name CHARBUF Domain name associated with the remote IP address. all all fd.dev INT32 device number (major/minor) containing the referenced file all all fd.dev.major INT32 major device number containing the referenced file all all fd.dev.minor INT32 minor device number containing the referenced file all all fd.ino INT64 inode number of the referenced file all all fd.nameraw CHARBUF FD full name raw. Just like fd.name, but only used if fd is a file path. File path is kept raw with limited sanitization and without deriving the absolute path. all all fd.types CHARBUF List of FD types in used. Can be passed an fd number e.g. fd.types[0] to get the type of stdout as a single item list. all all fd.is_upper_layer BOOL \u0026rsquo;true\u0026rsquo; if the fd is of a file in the upper layer of an overlayfs. 13.5.0 and above all fd.is_lower_layer BOOL \u0026rsquo;true\u0026rsquo; if the fd is of a file in the lower layer of an overlayfs. 13.5.0 and above all Field Class: fs.pathEvery syscall that has a filesystem path in its arguments has these fields set with information related to the path arguments. This differs from the fd.* fields as it includes syscalls like unlink, rename, etc. that act directly on filesystem paths as compared to opened file descriptors.\nName Type Description Linux versions Serverless versions fs.path.name CHARBUF For any event type that deals with a filesystem path, the path the file syscall is operating on. This path is always fully resolved, prepending the thread cwd when needed. all all fs.path.nameraw CHARBUF For any event type that deals with a filesystem path, the path the file syscall is operating on. This path is always the path provided to the syscall and may not be fully resolved. all all fs.path.source CHARBUF For any event type that deals with a filesystem path, and specifically for a source and target like mv, cp, etc, the source path the file syscall is operating on. This path is always fully resolved, prepending the thread cwd when needed. all all fs.path.sourceraw CHARBUF For any event type that deals with a filesystem path, and specifically for a source and target like mv, cp, etc, the source path the file syscall is operating on. This path is always the path provided to the syscall and may not be fully resolved. all all fs.path.target CHARBUF For any event type that deals with a filesystem path, and specifically for a target and target like mv, cp, etc, the target path the file syscall is operating on. This path is always fully resolved, prepending the thread cwd when needed. all all fs.path.targetraw CHARBUF For any event type that deals with a filesystem path, and specifically for a target and target like mv, cp, etc, the target path the file syscall is operating on. This path is always the path provided to the syscall and may not be fully resolved. all all Field Class: syslogContent of Syslog messages.\nName Type Description Linux versions Serverless versions syslog.facility.str CHARBUF facility as a string. all all syslog.facility UINT32 facility as a number (0-23). all all syslog.severity.str CHARBUF severity as a string. Can have one of these values: emerg, alert, crit, err, warn, notice, info, debug all all syslog.severity UINT32 severity as a number (0-7). all all syslog.message CHARBUF message sent to syslog. all all Field Class: fdlistPoll event related fields.\nName Type Description Linux versions Serverless versions fdlist.nums CHARBUF for poll events, this is a comma-separated list of the FD numbers in the \u0026lsquo;fds\u0026rsquo; argument, returned as a string. all all fdlist.names CHARBUF for poll events, this is a comma-separated list of the FD names in the \u0026lsquo;fds\u0026rsquo; argument, returned as a string. all all fdlist.cips CHARBUF for poll events, this is a comma-separated list of the client IP addresses in the \u0026lsquo;fds\u0026rsquo; argument, returned as a string. all all fdlist.sips CHARBUF for poll events, this is a comma-separated list of the server IP addresses in the \u0026lsquo;fds\u0026rsquo; argument, returned as a string. all all fdlist.cports CHARBUF for TCP/UDP FDs, for poll events, this is a comma-separated list of the client TCP/UDP ports in the \u0026lsquo;fds\u0026rsquo; argument, returned as a string. all all fdlist.sports CHARBUF for poll events, this is a comma-separated list of the server TCP/UDP ports in the \u0026lsquo;fds\u0026rsquo; argument, returned as a string. all all Field Class: container (plugin) Name Type Description Linux versions Serverless versions container.id CHARBUF The truncated container ID (first 12 characters), e.g. 3ad7b26ded6d is extracted from the Linux cgroups by Falco within the kernel. Consequently, this field is reliably available and serves as the lookup key for Falco\u0026rsquo;s synchronous or asynchronous requests against the container runtime socket to retrieve all other \u0026lsquo;container.\u0026rsquo; information. One important aspect to be aware of is that if the process occurs on the host, meaning not in the container PID namespace, this field is set to a string called \u0026lsquo;host\u0026rsquo;. In Kubernetes, pod sandbox container processes can exist where container.id matches k8s.pod.sandbox_id, lacking other \u0026lsquo;container.\u0026rsquo; details. all up to 6.1.0 container.full_id CHARBUF The full container ID, e.g. 3ad7b26ded6d8e7b23da7d48fe889434573036c27ae5a74837233de441c3601e. In contrast to container.id, we enrich this field as part of the container engine enrichment. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.name CHARBUF The container name. In instances of userspace container engine lookup delays, this field may not be available yet. One important aspect to be aware of is that if the process occurs on the host, meaning not in the container PID namespace, this field is set to a string called \u0026lsquo;host\u0026rsquo;. all up to 6.1.0 container.image CHARBUF The container image name (e.g. falcosecurity/falco:latest for docker). In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.image.id CHARBUF The container image id (e.g. 6f7e2741b66b). In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.type CHARBUF The container type, e.g. docker, cri-o, containerd etc. all up to 6.1.0 container.privileged BOOL \u0026rsquo;true\u0026rsquo; for containers running as privileged, \u0026lsquo;false\u0026rsquo; otherwise. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.mounts CHARBUF A space-separated list of mount information. Each item in the list has the format \u0026lsquo;source:dest:mode:rdrw:propagation\u0026rsquo;. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.mount CHARBUF Information about a single mount, specified by number (e.g. container.mount[0]) or mount source (container.mount[/usr/local]). The pathname can be a glob (container.mount[/usr/local/*]), in which case the first matching mount will be returned. The information has the format \u0026lsquo;source:dest:mode:rdrw:propagation\u0026rsquo;. If there is no mount with the specified index or matching the provided source, returns the string \u0026ldquo;none\u0026rdquo; instead of a NULL value. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.mount.source CHARBUF The mount source, specified by number (e.g. container.mount.source[0]) or mount destination (container.mount.source[/host/lib/modules]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.mount.dest CHARBUF The mount destination, specified by number (e.g. container.mount.dest[0]) or mount source (container.mount.dest[/lib/modules]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.mount.mode CHARBUF The mount mode, specified by number (e.g. container.mount.mode[0]) or mount source (container.mount.mode[/usr/local]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.mount.rdwr CHARBUF The mount rdwr value, specified by number (e.g. container.mount.rdwr[0]) or mount source (container.mount.rdwr[/usr/local]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.mount.propagation CHARBUF The mount propagation value, specified by number (e.g. container.mount.propagation[0]) or mount source (container.mount.propagation[/usr/local]). The pathname can be a glob. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.image.repository CHARBUF The container image repository (e.g. falcosecurity/falco). In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.image.tag CHARBUF The container image tag (e.g. stable, latest). In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.image.digest CHARBUF The container image registry digest (e.g. sha256:d977378f890d445c15e51795296e4e5062f109ce6da83e0a355fc4ad8699d27). In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.healthcheck CHARBUF The container\u0026rsquo;s health check. Will be the null value (\u0026ldquo;N/A\u0026rdquo;) if no healthcheck configured, \u0026ldquo;NONE\u0026rdquo; if configured but explicitly not created, and the healthcheck command line otherwise. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.liveness_probe CHARBUF The container\u0026rsquo;s liveness probe. Will be the null value (\u0026ldquo;N/A\u0026rdquo;) if no liveness probe configured, the liveness probe command line otherwise. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.readiness_probe CHARBUF The container\u0026rsquo;s readiness probe. Will be the null value (\u0026ldquo;N/A\u0026rdquo;) if no readiness probe configured, the readiness probe command line otherwise. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.start_ts ABSTIME Container start as epoch timestamp in nanoseconds based on proc.pidns_init_start_ts and extracted in the kernel and not from the container runtime socket / container engine. all up to 6.1.0 container.duration RELTIME Number of nanoseconds since container.start_ts. all up to 6.1.0 container.ip CHARBUF The container\u0026rsquo;s / pod\u0026rsquo;s primary ip address as retrieved from the container engine. Only ipv4 addresses are tracked. Consider container.cni.json (CRI use case) for logging ip addresses for each network interface. In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.cni.json CHARBUF The container\u0026rsquo;s / pod\u0026rsquo;s CNI result field from the respective pod status info. It contains ip addresses for each network interface exposed as unparsed escaped JSON string. Supported for CRI container engine (containerd, cri-o runtimes), optimized for containerd (some non-critical JSON keys removed). Useful for tracking ips (ipv4 and ipv6, dual-stack support) for each network interface (multi-interface support). In instances of userspace container engine lookup delays, this field may not be available yet. all up to 6.1.0 container.host_pid BOOL \u0026rsquo;true\u0026rsquo; if the container is running in the host PID namespace, \u0026lsquo;false\u0026rsquo; otherwise. 13.6.0 and above from 5.3.0 to 6.1.0 container.host_network BOOL \u0026rsquo;true\u0026rsquo; if the container is running in the host network namespace, \u0026lsquo;false\u0026rsquo; otherwise. 13.6.0 and above from 5.3.0 to 6.1.0 container.host_ipc BOOL \u0026rsquo;true\u0026rsquo; if the container is running in the host IPC namespace, \u0026lsquo;false\u0026rsquo; otherwise. 13.6.0 and above from 5.3.0 to 6.1.0 container.label CHARBUF Container label. E.g. \u0026lsquo;container.label.foo\u0026rsquo;. 14.3.0 and above — container.labels CHARBUF Container comma-separated key/value labels. E.g. \u0026lsquo;foo1:bar1,foo2:bar2\u0026rsquo;. 14.3.0 and above — proc.is_container_healthcheck BOOL \u0026rsquo;true\u0026rsquo; if this process is running as a part of the container\u0026rsquo;s health check. 14.3.0 and above — proc.is_container_liveness_probe BOOL \u0026rsquo;true\u0026rsquo; if this process is running as a part of the container\u0026rsquo;s liveness probe. 14.3.0 and above — proc.is_container_readiness_probe BOOL \u0026rsquo;true\u0026rsquo; if this process is running as a part of the container\u0026rsquo;s readiness probe. 14.3.0 and above — k8s.pod.name CHARBUF The Kubernetes pod name. This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.*\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. 14.3.0 and above — k8s.ns.name CHARBUF The Kubernetes namespace name. This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.*\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. 14.3.0 and above — k8s.pod.id CHARBUF [LEGACY] The Kubernetes pod UID, e.g. 3e41dc6b-08a8-44db-bc2a-3724b18ab19a. This legacy field points to k8s.pod.uid; however, the pod ID typically refers to the pod sandbox ID. We recommend using the semantically more accurate k8s.pod.uid field. This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.*\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. 14.3.0 and above — k8s.pod.uid CHARBUF The Kubernetes pod UID, e.g. 3e41dc6b-08a8-44db-bc2a-3724b18ab19a. Note that the pod UID is a unique identifier assigned upon pod creation within Kubernetes, allowing the Kubernetes control plane to manage and track pods reliably. As such, it is fundamentally a different concept compared to the pod sandbox ID. This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.*\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. 14.3.0 and above — k8s.pod.sandbox_id CHARBUF The truncated Kubernetes pod sandbox ID (first 12 characters), e.g 63060edc2d3a. The sandbox ID is specific to the container runtime environment. It is the equivalent of the container ID for the pod / sandbox and extracted from the Linux cgroups. As such, it differs from the pod UID. This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. In Kubernetes, pod sandbox container processes can exist where container.id matches k8s.pod.sandbox_id, lacking other \u0026lsquo;container.\u0026rsquo; details. 14.3.0 and above — k8s.pod.full_sandbox_id CHARBUF The full Kubernetes pod / sandbox ID, e.g 63060edc2d3aa803ab559f2393776b151f99fc5b05035b21db66b3b62246ad6a. This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.*\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. 14.3.0 and above — k8s.pod.label CHARBUF The Kubernetes pod label. The label can be accessed either with the familiar brackets notation, e.g. \u0026lsquo;k8s.pod.label[foo]\u0026rsquo; or by appending a dot followed by the name, e.g. \u0026lsquo;k8s.pod.label.foo\u0026rsquo;. The label name itself can include the original special characters such as \u0026lsquo;.\u0026rsquo;, \u0026lsquo;-\u0026rsquo;, \u0026lsquo;_\u0026rsquo; or \u0026lsquo;/\u0026rsquo; characters. For instance, \u0026lsquo;k8s.pod.label[app.kubernetes.io/name]\u0026rsquo;, \u0026lsquo;k8s.pod.label.app.kubernetes.io/name\u0026rsquo; or \u0026lsquo;k8s.pod.label[custom-label_one]\u0026rsquo; are all valid. This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.*\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. 14.3.0 and above — k8s.pod.labels CHARBUF The Kubernetes pod comma-separated key/value labels. E.g. \u0026lsquo;foo1:bar1,foo2:bar2\u0026rsquo;. This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.*\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. 14.3.0 and above — k8s.pod.ip CHARBUF The Kubernetes pod ip, same as container.ip field as each container in a pod shares the network stack of the sandbox / pod. Only ipv4 addresses are tracked. Consider k8s.pod.cni.json for logging ip addresses for each network interface. This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.*\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. 14.3.0 and above — k8s.pod.cni.json CHARBUF The Kubernetes pod CNI result field from the respective pod status info, same as container.cni.json field. It contains ip addresses for each network interface exposed as unparsed escaped JSON string. Supported for CRI container engine (containerd, cri-o runtimes), optimized for containerd (some non-critical JSON keys removed). Useful for tracking ips (ipv4 and ipv6, dual-stack support) for each network interface (multi-interface support). This field is extracted from the container runtime socket simultaneously as we look up the \u0026lsquo;container.*\u0026rsquo; fields. In cases of lookup delays, it may not be available yet. 14.3.0 and above — Field Class: security-dns (plugin) Name Type Description Linux versions Serverless versions dns.domain CHARBUF The domain being queried (e.g. sysdig.com) as a string. all all dns.query_type CHARBUF The type of lookup (e.g. A, AAAA, CNAME) of the query as a string. all all dns.query_class CHARBUF The class of lookup (e.g. IN) as a string. all all dns.success BOOL Whether the query was successful or not as a boolean value. all all dns.type CHARBUF The type of DNS event as a string, either \u0026ldquo;query\u0026rdquo; or \u0026ldquo;response\u0026rdquo;. all all dns.result UINT64 The result code (RCODE) of the query, 0 on success, see RFC-1035 for other values. all all dns.truncated BOOL Whether or not the query was truncated as a boolean value. all all dns.query.domains CHARBUF A list of all the domains being queried as strings. all all dns.query.domain CHARBUF An indexed field for the domain being queried as a string. all all dns.query.type CHARBUF An indexed field for the type of query (e.g. A, AAAA, CNAME) being queried as a string. all all dns.query.class CHARBUF An indexed field for the class of query (e.g. IN) being queried as a string. all all dns.query.lengths UINT64 The total length of the string of each domain being looked up. all all dns.query.length UINT64 An indexed field for the length of the domain string in each query. all all dns.response.domains CHARBUF A list of all the domains in the response as strings. all all dns.response.domain CHARBUF An indexed field for each domain in the response as a string. all all dns.response.ttl UINT64 An indexed field for The Time To Live of the record as an integer all all dns.response.type CHARBUF An indexed field for the type of respose (e.g. A, AAAA, CNAME) as a string. This can differ from what was originally queried. all all dns.response.class CHARBUF An indexed field for the class of respose (e.g. IN) as a string. all all dns.response.values CHARBUF A list containing the value of each response as a string. all all dns.response.value CHARBUF An indexed field for the class of respose (e.g. IN) as a string. all all dns.response.cnames CHARBUF A list of all the CNAMES in the response as strings. This will be empty if no CNAME records are present. all all dns.response.cname CHARBUF An indexed field for CNAME response records. This will be empty if the given index is not a CNAME. all all dns.response.txts CHARBUF A list of all the TXT records in the response as strings. This will be empty if no TXT records are present. all all dns.response.txt CHARBUF An indexed field for TXT response records. This will be empty if the given index is not a TXT record. all all dns.response.srvs CHARBUF A list of all the SRV records in the response as strings. This will be empty if no SRV records are present. all all dns.response.srv CHARBUF An indexed field for SRV response records. This will be empty if the given index is not an SRV record. all all dns.response.ips IPADDR List of IP addresses in the response. all all dns.response.ip IPADDR An indexed field for ip address (A, AAAA) response records. This will be empty if the given index is not an A or AAAA record. all all dns.server_ip IPADDR The ip address of the DNS server. all all connect.domains CHARBUF Domain names which map to fd.sip in the connect syscall all all Field Class: security-hashing (plugin) Name Type Description Linux versions Serverless versions proc.hash.sha256 CHARBUF The hash of the file executed by this process all all proc.hash.has_match BOOL Whether or not the hash of the file beeing executed by this process has a match in the hash database all all proc.hash.category CHARBUF In case proc.has_match is true, the category of the malware being executed all all fd.hash.sha256 CHARBUF The hash of the file 13.6.0 and above all fd.hash.has_match BOOL Whether or not the hash of the filehas a match in the hash database 13.6.0 and above all fd.hash.category CHARBUF In case fd.has_match is true, the category of the malware 13.6.0 and above all fd.hash.num UINT64 File descriptor number of the hashed file 13.6.0 and above all Field Class: security-fim (plugin) Name Type Description Linux versions Serverless versions fim.path CHARBUF The path of the file that triggered the file integrity monitoring event 14.3.0 and above — fim.filename CHARBUF The name of the file that triggered the file integrity monitoring event 14.3.0 and above — fim.old_hash.sha256 CHARBUF The SHA256 hash value computed from the file contents prior to the modification being detected 14.3.0 and above — fim.new_hash.sha256 CHARBUF The SHA256 hash value computed from the file contents after the modification event was detected 14.3.0 and above — fim.type CHARBUF The type of FIM event that occurred, such as file modification or deletion 14.3.0 and above — EventsSyscall events Default Dir Name Params Linux versions Serverless versions Yes \u0026gt; open FSPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode all all Yes \u0026lt; open FD fd, FSPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode, UINT32 dev, UINT64 ino all all Yes \u0026gt; close FD fd all all Yes \u0026lt; close ERRNO res all all No \u0026gt; read FD fd, UINT32 size all all No \u0026lt; read ERRNO res, BYTEBUF data, FD fd, UINT32 size all all No \u0026gt; write FD fd, UINT32 size all all No \u0026lt; write ERRNO res, BYTEBUF data, FD fd, UINT32 size all all Yes \u0026gt; socket ENUMFLAGS32 domain: AF_NFC, AF_ALG, AF_CAIF, AF_IEEE802154, AF_PHONET, AF_ISDN, AF_RXRPC, AF_IUCV, AF_BLUETOOTH, AF_TIPC, AF_CAN, AF_LLC, AF_WANPIPE, AF_PPPOX, AF_IRDA, AF_SNA, AF_RDS, AF_ATMSVC, AF_ECONET, AF_ASH, AF_PACKET, AF_ROUTE, AF_NETLINK, AF_KEY, AF_SECURITY, AF_NETBEUI, AF_DECnet, AF_ROSE, AF_INET6, AF_X25, AF_ATMPVC, AF_BRIDGE, AF_NETROM, AF_APPLETALK, AF_IPX, AF_AX25, AF_INET, AF_LOCAL, AF_UNIX, AF_UNSPEC, UINT32 type, UINT32 proto all all Yes \u0026lt; socket FD fd, ENUMFLAGS32 domain: AF_NFC, AF_ALG, AF_CAIF, AF_IEEE802154, AF_PHONET, AF_ISDN, AF_RXRPC, AF_IUCV, AF_BLUETOOTH, AF_TIPC, AF_CAN, AF_LLC, AF_WANPIPE, AF_PPPOX, AF_IRDA, AF_SNA, AF_RDS, AF_ATMSVC, AF_ECONET, AF_ASH, AF_PACKET, AF_ROUTE, AF_NETLINK, AF_KEY, AF_SECURITY, AF_NETBEUI, AF_DECnet, AF_ROSE, AF_INET6, AF_X25, AF_ATMPVC, AF_BRIDGE, AF_NETROM, AF_APPLETALK, AF_IPX, AF_AX25, AF_INET, AF_LOCAL, AF_UNIX, AF_UNSPEC, UINT32 type, UINT32 proto all all Yes \u0026gt; bind FD fd all all Yes \u0026lt; bind ERRNO res, SOCKADDR addr, FD fd all all Yes \u0026gt; connect FD fd, SOCKADDR addr all all Yes \u0026lt; connect ERRNO res, SOCKTUPLE tuple, FD fd all all Yes \u0026gt; listen FD fd, INT32 backlog all all Yes \u0026lt; listen ERRNO res, FD fd, INT32 backlog all all No \u0026gt; send FD fd, UINT32 size all all No \u0026lt; send ERRNO res, BYTEBUF data all all Yes \u0026gt; sendto FD fd, UINT32 size, SOCKTUPLE tuple all all Yes \u0026lt; sendto ERRNO res, BYTEBUF data all all No \u0026gt; recv FD fd, UINT32 size all all No \u0026lt; recv ERRNO res, BYTEBUF data all all Yes \u0026gt; recvfrom FD fd, UINT32 size all all Yes \u0026lt; recvfrom ERRNO res, BYTEBUF data, SOCKTUPLE tuple all all Yes \u0026gt; shutdown FD fd, ENUMFLAGS8 how: SHUT_UNKNOWN, SHUT_RDWR, SHUT_WR, SHUT_RD all all Yes \u0026lt; shutdown ERRNO res all all Yes \u0026gt; getsockname all all Yes \u0026lt; getsockname all all Yes \u0026gt; getpeername all all Yes \u0026lt; getpeername all all Yes \u0026gt; socketpair ENUMFLAGS32 domain: AF_NFC, AF_ALG, AF_CAIF, AF_IEEE802154, AF_PHONET, AF_ISDN, AF_RXRPC, AF_IUCV, AF_BLUETOOTH, AF_TIPC, AF_CAN, AF_LLC, AF_WANPIPE, AF_PPPOX, AF_IRDA, AF_SNA, AF_RDS, AF_ATMSVC, AF_ECONET, AF_ASH, AF_PACKET, AF_ROUTE, AF_NETLINK, AF_KEY, AF_SECURITY, AF_NETBEUI, AF_DECnet, AF_ROSE, AF_INET6, AF_X25, AF_ATMPVC, AF_BRIDGE, AF_NETROM, AF_APPLETALK, AF_IPX, AF_AX25, AF_INET, AF_LOCAL, AF_UNIX, AF_UNSPEC, UINT32 type, UINT32 proto all all Yes \u0026lt; socketpair ERRNO res, FD fd1, FD fd2, UINT64 source, UINT64 peer all all Yes \u0026gt; setsockopt all all Yes \u0026lt; setsockopt ERRNO res, FD fd, ENUMFLAGS8 level: SOL_SOCKET, SOL_TCP, UNKNOWN, ENUMFLAGS8 optname: SO_COOKIE, SO_MEMINFO, SO_PEERGROUPS, SO_ATTACH_BPF, SO_INCOMING_CPU, SO_BPF_EXTENSIONS, SO_MAX_PACING_RATE, SO_BUSY_POLL, SO_SELECT_ERR_QUEUE, SO_LOCK_FILTER, SO_NOFCS, SO_PEEK_OFF, SO_WIFI_STATUS, SO_RXQ_OVFL, SO_DOMAIN, SO_PROTOCOL, SO_TIMESTAMPING, SO_MARK, SO_TIMESTAMPNS, SO_PASSSEC, SO_PEERSEC, SO_ACCEPTCONN, SO_TIMESTAMP, SO_PEERNAME, SO_DETACH_FILTER, SO_ATTACH_FILTER, SO_BINDTODEVICE, SO_SECURITY_ENCRYPTION_NETWORK, SO_SECURITY_ENCRYPTION_TRANSPORT, SO_SECURITY_AUTHENTICATION, SO_SNDTIMEO, SO_RCVTIMEO, SO_SNDLOWAT, SO_RCVLOWAT, SO_PEERCRED, SO_PASSCRED, SO_REUSEPORT, SO_BSDCOMPAT, SO_LINGER, SO_PRIORITY, SO_NO_CHECK, SO_OOBINLINE, SO_KEEPALIVE, SO_RCVBUFFORCE, SO_SNDBUFFORCE, SO_RCVBUF, SO_SNDBUF, SO_BROADCAST, SO_DONTROUTE, SO_ERROR, SO_TYPE, SO_REUSEADDR, SO_DEBUG, UNKNOWN, DYNAMIC val, UINT32 optlen all all Yes \u0026gt; getsockopt all all Yes \u0026lt; getsockopt ERRNO res, FD fd, ENUMFLAGS8 level: SOL_SOCKET, SOL_TCP, UNKNOWN, ENUMFLAGS8 optname: SO_COOKIE, SO_MEMINFO, SO_PEERGROUPS, SO_ATTACH_BPF, SO_INCOMING_CPU, SO_BPF_EXTENSIONS, SO_MAX_PACING_RATE, SO_BUSY_POLL, SO_SELECT_ERR_QUEUE, SO_LOCK_FILTER, SO_NOFCS, SO_PEEK_OFF, SO_WIFI_STATUS, SO_RXQ_OVFL, SO_DOMAIN, SO_PROTOCOL, SO_TIMESTAMPING, SO_MARK, SO_TIMESTAMPNS, SO_PASSSEC, SO_PEERSEC, SO_ACCEPTCONN, SO_TIMESTAMP, SO_PEERNAME, SO_DETACH_FILTER, SO_ATTACH_FILTER, SO_BINDTODEVICE, SO_SECURITY_ENCRYPTION_NETWORK, SO_SECURITY_ENCRYPTION_TRANSPORT, SO_SECURITY_AUTHENTICATION, SO_SNDTIMEO, SO_RCVTIMEO, SO_SNDLOWAT, SO_RCVLOWAT, SO_PEERCRED, SO_PASSCRED, SO_REUSEPORT, SO_BSDCOMPAT, SO_LINGER, SO_PRIORITY, SO_NO_CHECK, SO_OOBINLINE, SO_KEEPALIVE, SO_RCVBUFFORCE, SO_SNDBUFFORCE, SO_RCVBUF, SO_SNDBUF, SO_BROADCAST, SO_DONTROUTE, SO_ERROR, SO_TYPE, SO_REUSEADDR, SO_DEBUG, UNKNOWN, DYNAMIC val, UINT32 optlen all all Yes \u0026gt; sendmsg FD fd, UINT32 size, SOCKTUPLE tuple all all Yes \u0026lt; sendmsg ERRNO res, BYTEBUF data all all Yes \u0026gt; sendmmsg all all Yes \u0026lt; sendmmsg ERRNO res, FD fd, UINT32 size, BYTEBUF data, SOCKTUPLE tuple all all Yes \u0026gt; recvmsg FD fd all all Yes \u0026lt; recvmsg ERRNO res, UINT32 size, BYTEBUF data, SOCKTUPLE tuple, BYTEBUF msgcontrol all all Yes \u0026gt; recvmmsg all all Yes \u0026lt; recvmmsg ERRNO res, FD fd, UINT32 size, BYTEBUF data, SOCKTUPLE tuple, BYTEBUF msgcontrol all all Yes \u0026gt; creat FSPATH name, UINT32 mode all all Yes \u0026lt; creat FD fd, FSPATH name, UINT32 mode, UINT32 dev, UINT64 ino, FLAGS16 creat_flags: FD_UPPER_LAYER_CREAT, FD_LOWER_LAYER_CREAT all all Yes \u0026gt; pipe all all Yes \u0026lt; pipe ERRNO res, FD fd1, FD fd2, UINT64 ino all all Yes \u0026gt; eventfd UINT64 initval, UINT32 flags all all Yes \u0026lt; eventfd FD res all all Yes \u0026gt; futex UINT64 addr, FLAGS16 op: FUTEX_CLOCK_REALTIME, FUTEX_PRIVATE_FLAG, FUTEX_CMP_REQUEUE_PI, FUTEX_WAIT_REQUEUE_PI, FUTEX_WAKE_BITSET, FUTEX_WAIT_BITSET, FUTEX_TRYLOCK_PI, FUTEX_UNLOCK_PI, FUTEX_LOCK_PI, FUTEX_WAKE_OP, FUTEX_CMP_REQUEUE, FUTEX_REQUEUE, FUTEX_FD, FUTEX_WAKE, FUTEX_WAIT, UINT64 val all all Yes \u0026lt; futex ERRNO res all all Yes \u0026gt; stat all all Yes \u0026lt; stat ERRNO res, FSPATH path all all Yes \u0026gt; lstat all all Yes \u0026lt; lstat ERRNO res, FSPATH path all all Yes \u0026gt; fstat FD fd all all Yes \u0026lt; fstat ERRNO res all all Yes \u0026gt; stat64 all all Yes \u0026lt; stat64 ERRNO res, FSPATH path all all Yes \u0026gt; lstat64 all all Yes \u0026lt; lstat64 ERRNO res, FSPATH path all all Yes \u0026gt; fstat64 FD fd all all Yes \u0026lt; fstat64 ERRNO res all all Yes \u0026gt; epoll_wait ERRNO maxevents all all Yes \u0026lt; epoll_wait ERRNO res all all Yes \u0026gt; poll FDLIST fds, INT64 timeout all all Yes \u0026lt; poll ERRNO res, FDLIST fds all all Yes \u0026gt; select all all Yes \u0026lt; select ERRNO res all all Yes \u0026gt; lseek FD fd, UINT64 offset, ENUMFLAGS8 whence: SEEK_END, SEEK_CUR, SEEK_SET all all Yes \u0026lt; lseek ERRNO res all all Yes \u0026gt; llseek FD fd, UINT64 offset, ENUMFLAGS8 whence: SEEK_END, SEEK_CUR, SEEK_SET all all Yes \u0026lt; llseek ERRNO res all all Yes \u0026gt; getcwd all all Yes \u0026lt; getcwd ERRNO res, CHARBUF path all all Yes \u0026gt; chdir all all Yes \u0026lt; chdir ERRNO res, CHARBUF path all all Yes \u0026gt; fchdir FD fd all all Yes \u0026lt; fchdir ERRNO res all all No \u0026gt; pread FD fd, UINT32 size, UINT64 pos all all No \u0026lt; pread ERRNO res, BYTEBUF data, FD fd, UINT32 size, UINT64 pos all all No \u0026gt; pwrite FD fd, UINT32 size, UINT64 pos all all No \u0026lt; pwrite ERRNO res, BYTEBUF data, FD fd, UINT32 size, UINT64 pos all all No \u0026gt; readv FD fd all all No \u0026lt; readv ERRNO res, UINT32 size, BYTEBUF data all all No \u0026gt; writev FD fd, UINT32 size all all No \u0026lt; writev ERRNO res, BYTEBUF data all all No \u0026gt; preadv FD fd, UINT64 pos all all No \u0026lt; preadv ERRNO res, UINT32 size, BYTEBUF data all all No \u0026gt; pwritev FD fd, UINT32 size, UINT64 pos all all No \u0026lt; pwritev ERRNO res, BYTEBUF data all all Yes \u0026gt; signalfd FD fd, UINT32 mask, UINT8 flags all all Yes \u0026lt; signalfd FD res all all Yes \u0026gt; kill PID pid, SIGTYPE sig all all Yes \u0026lt; kill ERRNO res all all Yes \u0026gt; tkill PID tid, SIGTYPE sig all all Yes \u0026lt; tkill ERRNO res all all Yes \u0026gt; tgkill PID pid, PID tid, SIGTYPE sig all all Yes \u0026lt; tgkill ERRNO res all all Yes \u0026gt; nanosleep RELTIME interval all all Yes \u0026lt; nanosleep ERRNO res all all Yes \u0026gt; timerfd_create UINT8 clockid, UINT8 flags all all Yes \u0026lt; timerfd_create FD res all all Yes \u0026gt; inotify_init UINT8 flags all all Yes \u0026lt; inotify_init FD res all all Yes \u0026gt; getrlimit ENUMFLAGS8 resource: RLIMIT_UNKNOWN, RLIMIT_RTTIME, RLIMIT_RTPRIO, RLIMIT_NICE, RLIMIT_MSGQUEUE, RLIMIT_SIGPENDING, RLIMIT_LOCKS, RLIMIT_AS, RLIMIT_MEMLOCK, RLIMIT_NOFILE, RLIMIT_NPROC, RLIMIT_RSS, RLIMIT_CORE, RLIMIT_STACK, RLIMIT_DATA, RLIMIT_FSIZE, RLIMIT_CPU all all Yes \u0026lt; getrlimit ERRNO res, INT64 cur, INT64 max all all Yes \u0026gt; setrlimit ENUMFLAGS8 resource: RLIMIT_UNKNOWN, RLIMIT_RTTIME, RLIMIT_RTPRIO, RLIMIT_NICE, RLIMIT_MSGQUEUE, RLIMIT_SIGPENDING, RLIMIT_LOCKS, RLIMIT_AS, RLIMIT_MEMLOCK, RLIMIT_NOFILE, RLIMIT_NPROC, RLIMIT_RSS, RLIMIT_CORE, RLIMIT_STACK, RLIMIT_DATA, RLIMIT_FSIZE, RLIMIT_CPU all all Yes \u0026lt; setrlimit ERRNO res, INT64 cur, INT64 max, ENUMFLAGS8 resource: RLIMIT_UNKNOWN, RLIMIT_RTTIME, RLIMIT_RTPRIO, RLIMIT_NICE, RLIMIT_MSGQUEUE, RLIMIT_SIGPENDING, RLIMIT_LOCKS, RLIMIT_AS, RLIMIT_MEMLOCK, RLIMIT_NOFILE, RLIMIT_NPROC, RLIMIT_RSS, RLIMIT_CORE, RLIMIT_STACK, RLIMIT_DATA, RLIMIT_FSIZE, RLIMIT_CPU all all Yes \u0026gt; prlimit PID pid, ENUMFLAGS8 resource: RLIMIT_UNKNOWN, RLIMIT_RTTIME, RLIMIT_RTPRIO, RLIMIT_NICE, RLIMIT_MSGQUEUE, RLIMIT_SIGPENDING, RLIMIT_LOCKS, RLIMIT_AS, RLIMIT_MEMLOCK, RLIMIT_NOFILE, RLIMIT_NPROC, RLIMIT_RSS, RLIMIT_CORE, RLIMIT_STACK, RLIMIT_DATA, RLIMIT_FSIZE, RLIMIT_CPU all all Yes \u0026lt; prlimit ERRNO res, INT64 newcur, INT64 newmax, INT64 oldcur, INT64 oldmax, INT64 pid, ENUMFLAGS8 resource: RLIMIT_UNKNOWN, RLIMIT_RTTIME, RLIMIT_RTPRIO, RLIMIT_NICE, RLIMIT_MSGQUEUE, RLIMIT_SIGPENDING, RLIMIT_LOCKS, RLIMIT_AS, RLIMIT_MEMLOCK, RLIMIT_NOFILE, RLIMIT_NPROC, RLIMIT_RSS, RLIMIT_CORE, RLIMIT_STACK, RLIMIT_DATA, RLIMIT_FSIZE, RLIMIT_CPU all all Yes \u0026gt; fcntl FD fd, ENUMFLAGS8 cmd: F_GETPIPE_SZ, F_SETPIPE_SZ, F_NOTIFY, F_DUPFD_CLOEXEC, F_CANCELLK, F_GETLEASE, F_SETLEASE, F_GETOWN_EX, F_SETOWN_EX, F_SETLKW64, F_SETLK64, F_GETLK64, F_GETSIG, F_SETSIG, F_GETOWN, F_SETOWN, F_SETLKW, F_SETLK, F_GETLK, F_SETFL, F_GETFL, F_SETFD, F_GETFD, F_DUPFD, F_OFD_GETLK, F_OFD_SETLK, F_OFD_SETLKW, UNKNOWN all all Yes \u0026lt; fcntl FD res, FD fd, ENUMFLAGS8 cmd: F_GETPIPE_SZ, F_SETPIPE_SZ, F_NOTIFY, F_DUPFD_CLOEXEC, F_CANCELLK, F_GETLEASE, F_SETLEASE, F_GETOWN_EX, F_SETOWN_EX, F_SETLKW64, F_SETLK64, F_GETLK64, F_GETSIG, F_SETSIG, F_GETOWN, F_SETOWN, F_SETLKW, F_SETLK, F_GETLK, F_SETFL, F_GETFL, F_SETFD, F_GETFD, F_DUPFD, F_OFD_GETLK, F_OFD_SETLK, F_OFD_SETLKW, UNKNOWN all all Yes \u0026gt; brk UINT64 addr all all Yes \u0026lt; brk UINT64 res, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap all all Yes \u0026gt; mmap UINT64 addr, UINT64 length, FLAGS32 prot: PROT_READ, PROT_WRITE, PROT_EXEC, PROT_SEM, PROT_GROWSDOWN, PROT_GROWSUP, PROT_SAO, PROT_NONE, FLAGS32 flags: MAP_SHARED, MAP_PRIVATE, MAP_FIXED, MAP_ANONYMOUS, MAP_32BIT, MAP_RENAME, MAP_NORESERVE, MAP_POPULATE, MAP_NONBLOCK, MAP_GROWSDOWN, MAP_DENYWRITE, MAP_EXECUTABLE, MAP_INHERIT, MAP_FILE, MAP_LOCKED, FD fd, UINT64 offset all all Yes \u0026lt; mmap ERRNO res, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap all all Yes \u0026gt; mmap2 UINT64 addr, UINT64 length, FLAGS32 prot: PROT_READ, PROT_WRITE, PROT_EXEC, PROT_SEM, PROT_GROWSDOWN, PROT_GROWSUP, PROT_SAO, PROT_NONE, FLAGS32 flags: MAP_SHARED, MAP_PRIVATE, MAP_FIXED, MAP_ANONYMOUS, MAP_32BIT, MAP_RENAME, MAP_NORESERVE, MAP_POPULATE, MAP_NONBLOCK, MAP_GROWSDOWN, MAP_DENYWRITE, MAP_EXECUTABLE, MAP_INHERIT, MAP_FILE, MAP_LOCKED, FD fd, UINT64 pgoffset all all Yes \u0026lt; mmap2 ERRNO res, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap all all Yes \u0026gt; munmap UINT64 addr, UINT64 length all all Yes \u0026lt; munmap ERRNO res, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap all all Yes \u0026gt; splice FD fd_in, FD fd_out, UINT64 size, FLAGS32 flags: SPLICE_F_MOVE, SPLICE_F_NONBLOCK, SPLICE_F_MORE, SPLICE_F_GIFT all all Yes \u0026lt; splice ERRNO res all all Yes \u0026gt; ptrace ENUMFLAGS16 request: PTRACE_SINGLEBLOCK, PTRACE_SYSEMU_SINGLESTEP, PTRACE_SYSEMU, PTRACE_ARCH_PRCTL, PTRACE_SET_THREAD_AREA, PTRACE_GET_THREAD_AREA, PTRACE_OLDSETOPTIONS, PTRACE_SETFPXREGS, PTRACE_GETFPXREGS, PTRACE_SETFPREGS, PTRACE_GETFPREGS, PTRACE_SETREGS, PTRACE_GETREGS, PTRACE_SETSIGMASK, PTRACE_GETSIGMASK, PTRACE_PEEKSIGINFO, PTRACE_LISTEN, PTRACE_INTERRUPT, PTRACE_SEIZE, PTRACE_SETREGSET, PTRACE_GETREGSET, PTRACE_SETSIGINFO, PTRACE_GETSIGINFO, PTRACE_GETEVENTMSG, PTRACE_SETOPTIONS, PTRACE_SYSCALL, PTRACE_DETACH, PTRACE_ATTACH, PTRACE_SINGLESTEP, PTRACE_KILL, PTRACE_CONT, PTRACE_POKEUSR, PTRACE_POKEDATA, PTRACE_POKETEXT, PTRACE_PEEKUSR, PTRACE_PEEKDATA, PTRACE_PEEKTEXT, PTRACE_TRACEME, PTRACE_UNKNOWN, PID pid all all Yes \u0026lt; ptrace ERRNO res, DYNAMIC addr, DYNAMIC data all all Yes \u0026gt; ioctl FD fd, UINT64 request, UINT64 argument all all Yes \u0026lt; ioctl ERRNO res all all Yes \u0026gt; rename all all Yes \u0026lt; rename ERRNO res, FSPATH oldpath, FSPATH newpath all all Yes \u0026gt; renameat all all Yes \u0026lt; renameat ERRNO res, FD olddirfd, FSRELPATH oldpath, FD newdirfd, FSRELPATH newpath all all Yes \u0026gt; symlink all all Yes \u0026lt; symlink ERRNO res, CHARBUF target, FSPATH linkpath all all Yes \u0026gt; symlinkat all all Yes \u0026lt; symlinkat ERRNO res, CHARBUF target, FD linkdirfd, FSRELPATH linkpath all all No \u0026gt; sendfile FD out_fd, FD in_fd, UINT64 offset, UINT64 size all all No \u0026lt; sendfile ERRNO res, UINT64 offset all all Yes \u0026gt; quotactl FLAGS16 cmd: Q_QUOTAON, Q_QUOTAOFF, Q_GETFMT, Q_GETINFO, Q_SETINFO, Q_GETQUOTA, Q_SETQUOTA, Q_SYNC, Q_XQUOTAON, Q_XQUOTAOFF, Q_XGETQUOTA, Q_XSETQLIM, Q_XGETQSTAT, Q_XQUOTARM, Q_XQUOTASYNC, FLAGS8 type: USRQUOTA, GRPQUOTA, UINT32 id, FLAGS8 quota_fmt: QFMT_NOT_USED, QFMT_VFS_OLD, QFMT_VFS_V0, QFMT_VFS_V1 all all Yes \u0026lt; quotactl ERRNO res, CHARBUF special, CHARBUF quotafilepath, UINT64 dqb_bhardlimit, UINT64 dqb_bsoftlimit, UINT64 dqb_curspace, UINT64 dqb_ihardlimit, UINT64 dqb_isoftlimit, RELTIME dqb_btime, RELTIME dqb_itime, RELTIME dqi_bgrace, RELTIME dqi_igrace, FLAGS8 dqi_flags: DQF_NONE, V1_DQF_RSQUASH, FLAGS8 quota_fmt_out: QFMT_NOT_USED, QFMT_VFS_OLD, QFMT_VFS_V0, QFMT_VFS_V1 all all Yes \u0026gt; setresuid UID ruid, UID euid, UID suid all all Yes \u0026lt; setresuid ERRNO res all all Yes \u0026gt; setresgid GID rgid, GID egid, GID sgid all all Yes \u0026lt; setresgid ERRNO res all all Yes \u0026gt; setuid UID uid all all Yes \u0026lt; setuid ERRNO res all all Yes \u0026gt; setgid GID gid all all Yes \u0026lt; setgid ERRNO res all all Yes \u0026gt; getuid all all Yes \u0026lt; getuid UID uid all all Yes \u0026gt; geteuid all all Yes \u0026lt; geteuid UID euid all all Yes \u0026gt; getgid all all Yes \u0026lt; getgid GID gid all all Yes \u0026gt; getegid all all Yes \u0026lt; getegid GID egid all all Yes \u0026gt; getresuid all all Yes \u0026lt; getresuid ERRNO res, UID ruid, UID euid, UID suid all all Yes \u0026gt; getresgid all all Yes \u0026lt; getresgid ERRNO res, GID rgid, GID egid, GID sgid all all Yes \u0026gt; clone all all Yes \u0026lt; clone PID res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, INT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, UINT32 uid, UINT32 gid, PID vtid, PID vpid, UINT64 pidns_init_start_ts all all Yes \u0026gt; fork all all Yes \u0026lt; fork PID res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, INT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, UINT32 uid, UINT32 gid, PID vtid, PID vpid, UINT64 pidns_init_start_ts all all Yes \u0026gt; vfork all all Yes \u0026lt; vfork PID res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, INT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, UINT32 uid, UINT32 gid, PID vtid, PID vpid, UINT64 pidns_init_start_ts all all Yes \u0026gt; getdents FD fd all all Yes \u0026lt; getdents ERRNO res all all Yes \u0026gt; getdents64 FD fd all all Yes \u0026lt; getdents64 ERRNO res all all Yes \u0026gt; setns FD fd, FLAGS32 nstype: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP all all Yes \u0026lt; setns ERRNO res all all Yes \u0026gt; flock FD fd, FLAGS32 operation: LOCK_SH, LOCK_EX, LOCK_NB, LOCK_UN, LOCK_NONE all all Yes \u0026lt; flock ERRNO res all all Yes \u0026gt; accept all all Yes \u0026lt; accept FD fd, SOCKTUPLE tuple, UINT8 queuepct, UINT32 queuelen, UINT32 queuemax all all Yes \u0026gt; semop INT32 semid all all Yes \u0026lt; semop ERRNO res, UINT32 nsops, UINT16 sem_num_0, INT16 sem_op_0, FLAGS16 sem_flg_0: IPC_NOWAIT, SEM_UNDO, UINT16 sem_num_1, INT16 sem_op_1, FLAGS16 sem_flg_1: IPC_NOWAIT, SEM_UNDO all all Yes \u0026gt; semctl INT32 semid, INT32 semnum, FLAGS16 cmd: IPC_STAT, IPC_SET, IPC_RMID, IPC_INFO, SEM_INFO, SEM_STAT, GETALL, GETNCNT, GETPID, GETVAL, GETZCNT, SETALL, SETVAL, INT32 val all all Yes \u0026lt; semctl ERRNO res all all Yes \u0026gt; ppoll FDLIST fds, RELTIME timeout, SIGSET sigmask all all Yes \u0026lt; ppoll ERRNO res, FDLIST fds all all Yes \u0026gt; mount FLAGS32 flags: RDONLY, NOSUID, NODEV, NOEXEC, SYNCHRONOUS, REMOUNT, MANDLOCK, DIRSYNC, NOATIME, NODIRATIME, BIND, MOVE, REC, SILENT, POSIXACL, UNBINDABLE, PRIVATE, SLAVE, SHARED, RELATIME, KERNMOUNT, I_VERSION, STRICTATIME, LAZYTIME, NOSEC, BORN, ACTIVE, NOUSER all all Yes \u0026lt; mount ERRNO res, CHARBUF dev, FSPATH dir, CHARBUF type all all Yes \u0026gt; semget INT32 key, INT32 nsems, FLAGS32 semflg: IPC_EXCL, IPC_CREAT all all Yes \u0026lt; semget ERRNO res all all Yes \u0026gt; access FLAGS32 mode: F_OK, R_OK, W_OK, X_OK all all Yes \u0026lt; access ERRNO res, FSPATH name all all Yes \u0026gt; chroot all all Yes \u0026lt; chroot ERRNO res, FSPATH path all all Yes \u0026gt; setsid all all Yes \u0026lt; setsid PID res all all Yes \u0026gt; mkdir UINT32 mode all all Yes \u0026lt; mkdir ERRNO res, FSPATH path all all Yes \u0026gt; rmdir all all Yes \u0026lt; rmdir ERRNO res, FSPATH path all all Yes \u0026gt; unshare FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP all all Yes \u0026lt; unshare ERRNO res all all Yes \u0026gt; execve FSPATH filename all all Yes \u0026lt; execve ERRNO res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, UINT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, BYTEBUF env, UINT32 tty, PID vpgid, UID loginuid, FLAGS32 flags: EXE_WRITABLE, EXE_UPPER_LAYER, EXE_FROM_MEMFD, EXE_LOWER_LAYER, UINT64 cap_inheritable, UINT64 cap_permitted, UINT64 cap_effective, UINT64 exe_ino, ABSTIME exe_ino_ctime, ABSTIME exe_ino_mtime, UID uid, FSPATH trusted_exepath, PID pgid, GID gid all all Yes \u0026gt; setpgid PID pid, PID pgid all all Yes \u0026lt; setpgid PID res all all Yes \u0026gt; seccomp UINT64 op, UINT64 flags all all Yes \u0026lt; seccomp ERRNO res all all Yes \u0026gt; unlink all all Yes \u0026lt; unlink ERRNO res, FSPATH path all all Yes \u0026gt; unlinkat all all Yes \u0026lt; unlinkat ERRNO res, FD dirfd, FSRELPATH name, FLAGS32 flags: AT_REMOVEDIR all all Yes \u0026gt; mkdirat all all Yes \u0026lt; mkdirat ERRNO res, FD dirfd, FSRELPATH path, UINT32 mode all all Yes \u0026gt; openat FD dirfd, FSRELPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode all all Yes \u0026lt; openat FD fd, FD dirfd, FSRELPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode, UINT32 dev, UINT64 ino all all Yes \u0026gt; link all all Yes \u0026lt; link ERRNO res, FSPATH oldpath, FSPATH newpath all all Yes \u0026gt; linkat all all Yes \u0026lt; linkat ERRNO res, FD olddir, FSRELPATH oldpath, FD newdir, FSRELPATH newpath, FLAGS32 flags: AT_SYMLINK_FOLLOW, AT_EMPTY_PATH all all Yes \u0026gt; fchmodat all all Yes \u0026lt; fchmodat ERRNO res, FD dirfd, FSRELPATH filename, MODE mode all all Yes \u0026gt; chmod all all Yes \u0026lt; chmod ERRNO res, FSPATH filename, MODE mode all all Yes \u0026gt; fchmod all all Yes \u0026lt; fchmod ERRNO res, FD fd, MODE mode all all Yes \u0026gt; renameat2 all all Yes \u0026lt; renameat2 ERRNO res, FD olddirfd, FSRELPATH oldpath, FD newdirfd, FSRELPATH newpath, FLAGS32 flags: RENAME_NOREPLACE, RENAME_EXCHANGE, RENAME_WHITEOUT all all Yes \u0026gt; userfaultfd all all Yes \u0026lt; userfaultfd ERRNO res, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER all all Yes \u0026gt; openat2 FD dirfd, FSRELPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode, FLAGS32 resolve: RESOLVE_BENEATH, RESOLVE_IN_ROOT, RESOLVE_NO_MAGICLINKS, RESOLVE_NO_SYMLINKS, RESOLVE_NO_XDEV, RESOLVE_CACHED all all Yes \u0026lt; openat2 FD fd, FD dirfd, FSRELPATH name, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, UINT32 mode, FLAGS32 resolve: RESOLVE_BENEATH, RESOLVE_IN_ROOT, RESOLVE_NO_MAGICLINKS, RESOLVE_NO_SYMLINKS, RESOLVE_NO_XDEV, RESOLVE_CACHED, UINT32 dev, UINT64 ino all all Yes \u0026gt; mprotect UINT64 addr, UINT64 length, FLAGS32 prot: PROT_READ, PROT_WRITE, PROT_EXEC, PROT_SEM, PROT_GROWSDOWN, PROT_GROWSUP, PROT_SAO, PROT_NONE all all Yes \u0026lt; mprotect ERRNO res all all Yes \u0026gt; execveat FD dirfd, FSRELPATH pathname, FLAGS32 flags: AT_EMPTY_PATH, AT_SYMLINK_NOFOLLOW all all Yes \u0026lt; execveat ERRNO res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, UINT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, BYTEBUF env, UINT32 tty, PID vpgid, UID loginuid, FLAGS32 flags: EXE_WRITABLE, EXE_UPPER_LAYER, EXE_FROM_MEMFD, EXE_LOWER_LAYER, UINT64 cap_inheritable, UINT64 cap_permitted, UINT64 cap_effective, UINT64 exe_ino, ABSTIME exe_ino_ctime, ABSTIME exe_ino_mtime, UID uid, FSPATH trusted_exepath, PID pgid, GID gid all all Yes \u0026gt; copy_file_range FD fdin, UINT64 offin, UINT64 len all all Yes \u0026lt; copy_file_range ERRNO res, FD fdout, UINT64 offout all all Yes \u0026gt; clone3 all all Yes \u0026lt; clone3 PID res, CHARBUF exe, BYTEBUF args, PID tid, PID pid, PID ptid, CHARBUF cwd, INT64 fdlimit, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap, CHARBUF comm, BYTEBUF cgroups, FLAGS32 flags: CLONE_FILES, CLONE_FS, CLONE_IO, CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, CLONE_NEWUTS, CLONE_PARENT, CLONE_PARENT_SETTID, CLONE_PTRACE, CLONE_SIGHAND, CLONE_SYSVSEM, CLONE_THREAD, CLONE_UNTRACED, CLONE_VM, CLONE_INVERTED, NAME_CHANGED, CLOSED, CLONE_NEWUSER, CLONE_CHILD_CLEARTID, CLONE_CHILD_SETTID, CLONE_SETTLS, CLONE_STOPPED, CLONE_VFORK, CLONE_NEWCGROUP, UINT32 uid, UINT32 gid, PID vtid, PID vpid, UINT64 pidns_init_start_ts all all Yes \u0026gt; open_by_handle_at all all Yes \u0026lt; open_by_handle_at FD fd, FD mountfd, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER, FSPATH path, UINT32 dev, UINT64 ino all all Yes \u0026gt; io_uring_setup all all Yes \u0026lt; io_uring_setup ERRNO res, UINT32 entries, UINT32 sq_entries, UINT32 cq_entries, FLAGS32 flags: IORING_SETUP_IOPOLL, IORING_SETUP_SQPOLL, IORING_SQ_NEED_WAKEUP, IORING_SETUP_SQ_AFF, IORING_SETUP_CQSIZE, IORING_SETUP_CLAMP, IORING_SETUP_ATTACH_RW, IORING_SETUP_R_DISABLED, UINT32 sq_thread_cpu, UINT32 sq_thread_idle, FLAGS32 features: IORING_FEAT_SINGLE_MMAP, IORING_FEAT_NODROP, IORING_FEAT_SUBMIT_STABLE, IORING_FEAT_RW_CUR_POS, IORING_FEAT_CUR_PERSONALITY, IORING_FEAT_FAST_POLL, IORING_FEAT_POLL_32BITS, IORING_FEAT_SQPOLL_NONFIXED, IORING_FEAT_ENTER_EXT_ARG, IORING_FEAT_NATIVE_WORKERS, IORING_FEAT_RSRC_TAGS all all Yes \u0026gt; io_uring_enter all all Yes \u0026lt; io_uring_enter ERRNO res, FD fd, UINT32 to_submit, UINT32 min_complete, FLAGS32 flags: IORING_ENTER_GETEVENTS, IORING_ENTER_SQ_WAKEUP, IORING_ENTER_SQ_WAIT, IORING_ENTER_EXT_ARG, SIGSET sig all all Yes \u0026gt; io_uring_register all all Yes \u0026lt; io_uring_register ERRNO res, FD fd, ENUMFLAGS16 opcode: IORING_REGISTER_BUFFERS, IORING_UNREGISTER_BUFFERS, IORING_REGISTER_FILES, IORING_UNREGISTER_FILES, IORING_REGISTER_EVENTFD, IORING_UNREGISTER_EVENTFD, IORING_REGISTER_FILES_UPDATE, IORING_REGISTER_EVENTFD_ASYNC, IORING_REGISTER_PROBE, IORING_REGISTER_PERSONALITY, IORING_UNREGISTER_PERSONALITY, IORING_REGISTER_RESTRICTIONS, IORING_REGISTER_ENABLE_RINGS, IORING_REGISTER_FILES2, IORING_REGISTER_FILES_UPDATE2, IORING_REGISTER_BUFFERS2, IORING_REGISTER_BUFFERS_UPDATE, IORING_REGISTER_IOWQ_AFF, IORING_UNREGISTER_IOWQ_AFF, IORING_REGISTER_IOWQ_MAX_WORKERS, IORING_REGISTER_RING_FDS, IORING_UNREGISTER_RING_FDS, UINT64 arg, UINT32 nr_args all all Yes \u0026gt; mlock all all Yes \u0026lt; mlock ERRNO res, UINT64 addr, UINT64 len all all Yes \u0026gt; munlock all all Yes \u0026lt; munlock ERRNO res, UINT64 addr, UINT64 len all all Yes \u0026gt; mlockall all all Yes \u0026lt; mlockall ERRNO res, FLAGS32 flags: MCL_CURRENT, MCL_FUTURE, MCL_ONFAULT all all Yes \u0026gt; munlockall all all Yes \u0026lt; munlockall ERRNO res all all Yes \u0026gt; capset all all Yes \u0026lt; capset ERRNO res, UINT64 cap_inheritable, UINT64 cap_permitted, UINT64 cap_effective all all Yes \u0026gt; dup2 FD fd all all Yes \u0026lt; dup2 FD res, FD oldfd, FD newfd all all Yes \u0026gt; dup3 FD fd all all Yes \u0026lt; dup3 FD res, FD oldfd, FD newfd, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER all all Yes \u0026gt; dup FD fd all all Yes \u0026lt; dup FD res, FD oldfd all all Yes \u0026gt; bpf INT64 cmd all all Yes \u0026lt; bpf FD fd, ENUMFLAGS32 cmd: BPF_MAP_CREATE, BPF_MAP_LOOKUP_ELEM, BPF_MAP_UPDATE_ELEM, BPF_MAP_DELETE_ELEM, BPF_MAP_GET_NEXT_KEY, BPF_PROG_LOAD, BPF_OBJ_PIN, BPF_OBJ_GET, BPF_PROG_ATTACH, BPF_PROG_DETACH, BPF_PROG_TEST_RUN, BPF_PROG_RUN, BPF_PROG_GET_NEXT_ID, BPF_MAP_GET_NEXT_ID, BPF_PROG_GET_FD_BY_ID, BPF_MAP_GET_FD_BY_ID, BPF_OBJ_GET_INFO_BY_FD, BPF_PROG_QUERY, BPF_RAW_TRACEPOINT_OPEN, BPF_BTF_LOAD, BPF_BTF_GET_FD_BY_ID, BPF_TASK_FD_QUERY, BPF_MAP_LOOKUP_AND_DELETE_ELEM, BPF_MAP_FREEZE, BPF_BTF_GET_NEXT_ID, BPF_MAP_LOOKUP_BATCH, BPF_MAP_LOOKUP_AND_DELETE_BATCH, BPF_MAP_UPDATE_BATCH, BPF_MAP_DELETE_BATCH, BPF_LINK_CREATE, BPF_LINK_UPDATE, BPF_LINK_GET_FD_BY_ID, BPF_LINK_GET_NEXT_ID, BPF_ENABLE_STATS, BPF_ITER_CREATE, BPF_LINK_DETACH, BPF_PROG_BIND_MAP all all Yes \u0026gt; mlock2 all all Yes \u0026lt; mlock2 ERRNO res, UINT64 addr, UINT64 len, FLAGS32 flags: MLOCK_ONFAULT all all Yes \u0026gt; fsconfig all all Yes \u0026lt; fsconfig ERRNO res, FD fd, ENUMFLAGS32 cmd: FSCONFIG_SET_FLAG, FSCONFIG_SET_STRING, FSCONFIG_SET_BINARY, FSCONFIG_SET_PATH, FSCONFIG_SET_PATH_EMPTY, FSCONFIG_SET_FD, FSCONFIG_CMD_CREATE, FSCONFIG_CMD_RECONFIGURE, CHARBUF key, BYTEBUF value_bytebuf, CHARBUF value_charbuf, INT32 aux all all Yes \u0026gt; epoll_create INT32 size all all Yes \u0026lt; epoll_create ERRNO res all all Yes \u0026gt; epoll_create1 FLAGS32 flags: EPOLL_CLOEXEC all all Yes \u0026lt; epoll_create1 ERRNO res all all Yes \u0026gt; chown all all Yes \u0026lt; chown ERRNO res, FSPATH path, UINT32 uid, UINT32 gid all all Yes \u0026gt; lchown all all Yes \u0026lt; lchown ERRNO res, FSPATH path, UINT32 uid, UINT32 gid all all Yes \u0026gt; fchown all all Yes \u0026lt; fchown ERRNO res, FD fd, UINT32 uid, UINT32 gid all all Yes \u0026gt; fchownat all all Yes \u0026lt; fchownat ERRNO res, FD dirfd, FSRELPATH pathname, UINT32 uid, UINT32 gid, FLAGS32 flags: AT_SYMLINK_NOFOLLOW, AT_EMPTY_PATH all all Yes \u0026gt; umount all all Yes \u0026lt; umount ERRNO res, FSPATH name all all Yes \u0026gt; accept4 INT32 flags all all Yes \u0026lt; accept4 FD fd, SOCKTUPLE tuple, UINT8 queuepct, UINT32 queuelen, UINT32 queuemax all all Yes \u0026gt; umount2 FLAGS32 flags: FORCE, DETACH, EXPIRE, NOFOLLOW all all Yes \u0026lt; umount2 ERRNO res, FSPATH name all all Yes \u0026gt; pipe2 all all Yes \u0026lt; pipe2 ERRNO res, FD fd1, FD fd2, UINT64 ino, FLAGS32 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER all all Yes \u0026gt; inotify_init1 all all Yes \u0026lt; inotify_init1 FD res, FLAGS16 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER all all Yes \u0026gt; eventfd2 UINT64 initval all all Yes \u0026lt; eventfd2 FD res, FLAGS16 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER all all Yes \u0026gt; signalfd4 FD fd, UINT32 mask all all Yes \u0026lt; signalfd4 FD res, FLAGS16 flags: O_LARGEFILE, O_DIRECTORY, O_DIRECT, O_TRUNC, O_SYNC, O_NONBLOCK, O_EXCL, O_DSYNC, O_APPEND, O_CREAT, O_RDWR, O_WRONLY, O_RDONLY, O_CLOEXEC, O_NONE, O_TMPFILE, O_F_CREATED, FD_UPPER_LAYER, FD_LOWER_LAYER all all Yes \u0026gt; prctl all all Yes \u0026lt; prctl ERRNO res, ENUMFLAGS32 option: PR_GET_DUMPABLE, PR_SET_DUMPABLE, PR_GET_KEEPCAPS, PR_SET_KEEPCAPS, PR_SET_NAME, PR_GET_NAME, PR_GET_SECCOMP, PR_SET_SECCOMP, PR_CAPBSET_READ, PR_CAPBSET_DROP, PR_GET_SECUREBITS, PR_SET_SECUREBITS, PR_MCE_KILL, PR_MCE_KILL, PR_SET_MM, PR_SET_CHILD_SUBREAPER, PR_GET_CHILD_SUBREAPER, PR_SET_NO_NEW_PRIVS, PR_GET_NO_NEW_PRIVS, PR_GET_TID_ADDRESS, PR_SET_THP_DISABLE, PR_GET_THP_DISABLE, PR_CAP_AMBIENT, CHARBUF arg2_str, INT64 arg2_int all all Yes \u0026gt; memfd_create all all Yes \u0026lt; memfd_create FD fd, CHARBUF name, FLAGS32 flags: MFD_CLOEXEC, MFD_ALLOW_SEALING, MFD_HUGETLB all all Yes \u0026gt; pidfd_getfd all all Yes \u0026lt; pidfd_getfd FD fd, FD pid_fd, FD target_fd, UINT32 flags all all Yes \u0026gt; pidfd_open all all Yes \u0026lt; pidfd_open FD fd, PID pid, FLAGS32 flags: PIDFD_NONBLOCK all all Yes \u0026gt; init_module all all Yes \u0026lt; init_module ERRNO res, BYTEBUF img, UINT64 length, CHARBUF uargs all all Yes \u0026gt; finit_module all all Yes \u0026lt; finit_module ERRNO res, FD fd, CHARBUF uargs, FLAGS32 flags: MODULE_INIT_IGNORE_MODVERSIONS, MODULE_INIT_IGNORE_VERMAGIC, MODULE_INIT_COMPRESSED_FILE all all Yes \u0026gt; mknod all all Yes \u0026lt; mknod ERRNO res, FSPATH path, MODE mode, UINT32 dev all all Yes \u0026gt; mknodat all all Yes \u0026lt; mknodat ERRNO res, FD dirfd, FSRELPATH path, MODE mode, UINT32 dev all all Yes \u0026gt; newfstatat all all Yes \u0026lt; newfstatat ERRNO res, FD dirfd, FSRELPATH path, FLAGS32 flags: AT_EMPTY_PATH, AT_NO_AUTOMOUNT, AT_SYMLINK_NOFOLLOW all all Yes \u0026gt; process_vm_readv all all Yes \u0026lt; process_vm_readv INT64 res, PID pid, BYTEBUF data all all Yes \u0026gt; process_vm_writev all all Yes \u0026lt; process_vm_writev INT64 res, PID pid, BYTEBUF data all all Yes \u0026gt; delete_module all all Yes \u0026lt; delete_module ERRNO res, CHARBUF name, FLAGS32 flags: O_NONBLOCK, O_TRUNC all all Yes \u0026gt; setreuid all all Yes \u0026lt; setreuid ERRNO res, UID ruid, UID euid all all Yes \u0026gt; setregid all all Yes \u0026lt; setregid ERRNO res, UID rgid, UID egid all all Yes \u0026gt; open_tree_attr SYSCALLID ID, UINT16 nativeID 14.3.0 and above 6.2.0 and above Yes \u0026lt; open_tree_attr SYSCALLID ID 14.3.0 and above 6.2.0 and above Yes \u0026gt; setxattrat SYSCALLID ID, UINT16 nativeID 13.8.0 and above 5.4.0 and above Yes \u0026lt; setxattrat SYSCALLID ID 13.8.0 and above 5.4.0 and above Yes \u0026gt; uretprobe SYSCALLID ID, UINT16 nativeID 13.5.0 and above all Yes \u0026lt; uretprobe SYSCALLID ID 13.5.0 and above all Yes \u0026gt; lsm_list_modules SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; lsm_list_modules SYSCALLID ID all all Yes \u0026gt; lsm_get_self_attr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; lsm_get_self_attr SYSCALLID ID all all Yes \u0026gt; statmount SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; statmount SYSCALLID ID all all Yes \u0026gt; listmount SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; listmount SYSCALLID ID all all Yes \u0026gt; capget SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; capget SYSCALLID ID all all Yes \u0026gt; inotify_rm_watch SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; inotify_rm_watch SYSCALLID ID all all Yes \u0026gt; clock_getres SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; clock_getres SYSCALLID ID all all Yes \u0026gt; kexec_load SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; kexec_load SYSCALLID ID all all Yes \u0026gt; mq_notify SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mq_notify SYSCALLID ID all all Yes \u0026gt; utimes SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; utimes SYSCALLID ID all all Yes \u0026gt; set_robust_list SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; set_robust_list SYSCALLID ID all all Yes \u0026gt; shmget SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; shmget SYSCALLID ID all all Yes \u0026gt; fspick SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fspick SYSCALLID ID all all Yes \u0026gt; timer_delete SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; timer_delete SYSCALLID ID all all Yes \u0026gt; sethostname SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sethostname SYSCALLID ID all all Yes \u0026gt; exit_group SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; exit_group SYSCALLID ID all all Yes \u0026gt; fsmount SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fsmount SYSCALLID ID all all Yes \u0026gt; clock_gettime SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; clock_gettime SYSCALLID ID all all Yes \u0026gt; listxattrat SYSCALLID ID, UINT16 nativeID 13.8.0 and above 5.4.0 and above Yes \u0026lt; listxattrat SYSCALLID ID 13.8.0 and above 5.4.0 and above Yes \u0026gt; timerfd_gettime SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; timerfd_gettime SYSCALLID ID all all Yes \u0026gt; timer_getoverrun SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; timer_getoverrun SYSCALLID ID all all Yes \u0026gt; s390_pci_mmio_write SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; s390_pci_mmio_write SYSCALLID ID all all Yes \u0026gt; io_setup SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; io_setup SYSCALLID ID all all Yes \u0026gt; inotify_add_watch SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; inotify_add_watch SYSCALLID ID all all Yes \u0026gt; pidfd_send_signal SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pidfd_send_signal SYSCALLID ID all all Yes \u0026gt; epoll_ctl SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; epoll_ctl SYSCALLID ID all all Yes \u0026gt; get_thread_area SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; get_thread_area SYSCALLID ID all all Yes \u0026gt; switch_endian SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; switch_endian SYSCALLID ID all all Yes \u0026gt; setitimer SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; setitimer SYSCALLID ID all all Yes \u0026gt; io_submit SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; io_submit SYSCALLID ID all all Yes \u0026gt; sched_setaffinity SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_setaffinity SYSCALLID ID all all Yes \u0026gt; request_key SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; request_key SYSCALLID ID all all Yes \u0026gt; fanotify_init SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fanotify_init SYSCALLID ID all all Yes \u0026gt; fsopen SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fsopen SYSCALLID ID all all Yes \u0026gt; sched_setattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_setattr SYSCALLID ID all all Yes \u0026gt; sched_getaffinity SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_getaffinity SYSCALLID ID all all Yes \u0026gt; rt_sigqueueinfo SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rt_sigqueueinfo SYSCALLID ID all all Yes \u0026gt; utimensat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; utimensat SYSCALLID ID all all Yes \u0026gt; fremovexattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fremovexattr SYSCALLID ID all all Yes \u0026gt; getgroups SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getgroups SYSCALLID ID all all Yes \u0026gt; removexattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; removexattr SYSCALLID ID all all Yes \u0026gt; llistxattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; llistxattr SYSCALLID ID all all Yes \u0026gt; waitid SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; waitid SYSCALLID ID all all Yes \u0026gt; arch_prctl SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; arch_prctl SYSCALLID ID all all Yes \u0026gt; sigaction SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sigaction SYSCALLID ID all all Yes \u0026gt; mq_timedsend SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mq_timedsend SYSCALLID ID all all Yes \u0026gt; setxattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; setxattr SYSCALLID ID all all Yes \u0026gt; shmdt SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; shmdt SYSCALLID ID all all Yes \u0026gt; sigpending SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sigpending SYSCALLID ID all all Yes \u0026gt; fgetxattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fgetxattr SYSCALLID ID all all Yes \u0026gt; lgetxattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; lgetxattr SYSCALLID ID all all Yes \u0026gt; fsync SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fsync SYSCALLID ID all all Yes \u0026gt; spu_create SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; spu_create SYSCALLID ID all all Yes \u0026gt; fsetxattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fsetxattr SYSCALLID ID all all Yes \u0026gt; lsetxattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; lsetxattr SYSCALLID ID all all Yes \u0026gt; idle SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; idle SYSCALLID ID all all Yes \u0026gt; shmat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; shmat SYSCALLID ID all all Yes \u0026gt; adjtimex SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; adjtimex SYSCALLID ID all all Yes \u0026gt; query_module SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; query_module SYSCALLID ID all all Yes \u0026gt; timer_create SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; timer_create SYSCALLID ID all all Yes \u0026gt; gettid SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; gettid SYSCALLID ID all all Yes \u0026gt; membarrier SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; membarrier SYSCALLID ID all all Yes \u0026gt; add_key SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; add_key SYSCALLID ID all all Yes \u0026gt; swapoff SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; swapoff SYSCALLID ID all all Yes \u0026gt; madvise SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; madvise SYSCALLID ID all all Yes \u0026gt; s390_pci_mmio_read SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; s390_pci_mmio_read SYSCALLID ID all all Yes \u0026gt; setfsgid SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; setfsgid SYSCALLID ID all all Yes \u0026gt; setfsuid SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; setfsuid SYSCALLID ID all all Yes \u0026gt; getpgrp SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getpgrp SYSCALLID ID all all Yes \u0026gt; personality SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; personality SYSCALLID ID all all Yes \u0026gt; getxattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getxattr SYSCALLID ID all all Yes \u0026gt; move_mount SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; move_mount SYSCALLID ID all all Yes \u0026gt; get_mempolicy SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; get_mempolicy SYSCALLID ID all all Yes \u0026gt; getpriority SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getpriority SYSCALLID ID all all Yes \u0026gt; removexattrat SYSCALLID ID, UINT16 nativeID 13.8.0 and above 5.4.0 and above Yes \u0026lt; removexattrat SYSCALLID ID 13.8.0 and above 5.4.0 and above Yes \u0026gt; readlinkat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; readlinkat SYSCALLID ID all all Yes \u0026gt; mount_setattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mount_setattr SYSCALLID ID all all Yes \u0026gt; clock_settime SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; clock_settime SYSCALLID ID all all Yes \u0026gt; umask SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; umask SYSCALLID ID all all Yes \u0026gt; lookup_dcookie SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; lookup_dcookie SYSCALLID ID all all Yes \u0026gt; quotactl_fd SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; quotactl_fd SYSCALLID ID all all Yes \u0026gt; timer_settime SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; timer_settime SYSCALLID ID all all Yes \u0026gt; truncate SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; truncate SYSCALLID ID all all Yes \u0026gt; mremap SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mremap SYSCALLID ID all all Yes \u0026gt; rtas SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rtas SYSCALLID ID all all Yes \u0026gt; lsm_set_self_attr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; lsm_set_self_attr SYSCALLID ID all all Yes \u0026gt; syslog SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; syslog SYSCALLID ID all all Yes \u0026gt; fstatfs SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fstatfs SYSCALLID ID all all Yes \u0026gt; ioperm SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; ioperm SYSCALLID ID all all Yes \u0026gt; riscv_flush_icache SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; riscv_flush_icache SYSCALLID ID all all Yes \u0026gt; keyctl SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; keyctl SYSCALLID ID all all Yes \u0026gt; uselib SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; uselib SYSCALLID ID all all Yes \u0026gt; reboot SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; reboot SYSCALLID ID all all Yes \u0026gt; futimesat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; futimesat SYSCALLID ID all all Yes \u0026gt; timer_gettime SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; timer_gettime SYSCALLID ID all all Yes \u0026gt; flistxattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; flistxattr SYSCALLID ID all all Yes \u0026gt; setgroups SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; setgroups SYSCALLID ID all all Yes \u0026gt; sched_rr_get_interval SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_rr_get_interval SYSCALLID ID all all Yes \u0026gt; gettimeofday SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; gettimeofday SYSCALLID ID all all Yes \u0026gt; readlink SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; readlink SYSCALLID ID all all Yes \u0026gt; syncfs SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; syncfs SYSCALLID ID all all Yes \u0026gt; get_robust_list SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; get_robust_list SYSCALLID ID all all Yes \u0026gt; listxattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; listxattr SYSCALLID ID all all Yes \u0026gt; set_mempolicy SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; set_mempolicy SYSCALLID ID all all Yes \u0026gt; s390_guarded_storage SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; s390_guarded_storage SYSCALLID ID all all Yes \u0026gt; settimeofday SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; settimeofday SYSCALLID ID all all Yes \u0026gt; mq_unlink SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mq_unlink SYSCALLID ID all all Yes \u0026gt; swapon SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; swapon SYSCALLID ID all all Yes \u0026gt; pselect6 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pselect6 SYSCALLID ID all all Yes \u0026gt; io_cancel SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; io_cancel SYSCALLID ID all all Yes \u0026gt; ioprio_get SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; ioprio_get SYSCALLID ID all all Yes \u0026gt; uname SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; uname SYSCALLID ID all all Yes \u0026gt; shmctl SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; shmctl SYSCALLID ID all all Yes \u0026gt; time SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; time SYSCALLID ID all all Yes \u0026gt; pkey_free SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pkey_free SYSCALLID ID all all Yes \u0026gt; readahead SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; readahead SYSCALLID ID all all Yes \u0026gt; statfs SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; statfs SYSCALLID ID all all Yes \u0026gt; fanotify_mark SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fanotify_mark SYSCALLID ID all all Yes \u0026gt; ioprio_set SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; ioprio_set SYSCALLID ID all all Yes \u0026gt; times SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; times SYSCALLID ID all all Yes \u0026gt; process_madvise SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; process_madvise SYSCALLID ID all all Yes \u0026gt; vmsplice SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; vmsplice SYSCALLID ID all all Yes \u0026gt; rt_sigtimedwait SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rt_sigtimedwait SYSCALLID ID all all Yes \u0026gt; preadv2 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; preadv2 SYSCALLID ID all all Yes \u0026gt; create_module SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; create_module SYSCALLID ID all all Yes \u0026gt; remap_file_pages SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; remap_file_pages SYSCALLID ID all all Yes \u0026gt; lremovexattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; lremovexattr SYSCALLID ID all all Yes \u0026gt; landlock_create_ruleset SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; landlock_create_ruleset SYSCALLID ID all all Yes \u0026gt; timerfd SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; timerfd SYSCALLID ID all all Yes \u0026gt; pause SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pause SYSCALLID ID all all Yes \u0026gt; stime SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; stime SYSCALLID ID all all Yes \u0026gt; sched_setparam SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_setparam SYSCALLID ID all all Yes \u0026gt; name_to_handle_at SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; name_to_handle_at SYSCALLID ID all all Yes \u0026gt; utime SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; utime SYSCALLID ID all all Yes \u0026gt; getpid SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getpid SYSCALLID ID all all Yes \u0026gt; sync SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sync SYSCALLID ID all all Yes \u0026gt; getxattrat SYSCALLID ID, UINT16 nativeID 13.8.0 and above 5.4.0 and above Yes \u0026lt; getxattrat SYSCALLID ID 13.8.0 and above 5.4.0 and above Yes \u0026gt; clock_adjtime SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; clock_adjtime SYSCALLID ID all all Yes \u0026gt; restart_syscall SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; restart_syscall SYSCALLID ID all all Yes \u0026gt; io_getevents SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; io_getevents SYSCALLID ID all all Yes \u0026gt; sysfs SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sysfs SYSCALLID ID all all Yes \u0026gt; get_kernel_syms SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; get_kernel_syms SYSCALLID ID all all Yes \u0026gt; epoll_pwait SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; epoll_pwait SYSCALLID ID all all Yes \u0026gt; futex_wait SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; futex_wait SYSCALLID ID all all Yes \u0026gt; acct SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; acct SYSCALLID ID all all Yes \u0026gt; setdomainname SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; setdomainname SYSCALLID ID all all Yes \u0026gt; sysinfo SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sysinfo SYSCALLID ID all all Yes \u0026gt; msgsnd SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; msgsnd SYSCALLID ID all all Yes \u0026gt; mincore SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mincore SYSCALLID ID all all Yes \u0026gt; cachestat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; cachestat SYSCALLID ID all all Yes \u0026gt; pivot_root SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pivot_root SYSCALLID ID all all Yes \u0026gt; exit SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; exit SYSCALLID ID all all Yes \u0026gt; getppid SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getppid SYSCALLID ID all all Yes \u0026gt; io_destroy SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; io_destroy SYSCALLID ID all all Yes \u0026gt; ustat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; ustat SYSCALLID ID all all Yes \u0026gt; epoll_wait_old SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; epoll_wait_old SYSCALLID ID all all Yes \u0026gt; vhangup SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; vhangup SYSCALLID ID all all Yes \u0026gt; _sysctl SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; _sysctl SYSCALLID ID all all Yes \u0026gt; alarm SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; alarm SYSCALLID ID all all Yes \u0026gt; rt_sigprocmask SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rt_sigprocmask SYSCALLID ID all all Yes \u0026gt; rt_tgsigqueueinfo SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rt_tgsigqueueinfo SYSCALLID ID all all Yes \u0026gt; rt_sigaction SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rt_sigaction SYSCALLID ID all all Yes \u0026gt; fchmodat2 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fchmodat2 SYSCALLID ID all all Yes \u0026gt; wait4 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; wait4 SYSCALLID ID all all Yes \u0026gt; getpgid SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getpgid SYSCALLID ID all all Yes \u0026gt; sched_yield SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_yield SYSCALLID ID all all Yes \u0026gt; signal SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; signal SYSCALLID ID all all Yes \u0026gt; clock_nanosleep SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; clock_nanosleep SYSCALLID ID all all Yes \u0026gt; pkey_mprotect SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pkey_mprotect SYSCALLID ID all all Yes \u0026gt; fdatasync SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fdatasync SYSCALLID ID all all Yes \u0026gt; getrusage SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getrusage SYSCALLID ID all all Yes \u0026gt; futex_wake SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; futex_wake SYSCALLID ID all all Yes \u0026gt; sched_getparam SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_getparam SYSCALLID ID all all Yes \u0026gt; sched_setscheduler SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_setscheduler SYSCALLID ID all all Yes \u0026gt; setpriority SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; setpriority SYSCALLID ID all all Yes \u0026gt; mseal SYSCALLID ID, UINT16 nativeID 13.4.0 and above all Yes \u0026lt; mseal SYSCALLID ID 13.4.0 and above all Yes \u0026gt; open_tree SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; open_tree SYSCALLID ID all all Yes \u0026gt; kcmp SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; kcmp SYSCALLID ID all all Yes \u0026gt; sched_getscheduler SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_getscheduler SYSCALLID ID all all Yes \u0026gt; sched_get_priority_min SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_get_priority_min SYSCALLID ID all all Yes \u0026gt; rt_sigsuspend SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rt_sigsuspend SYSCALLID ID all all Yes \u0026gt; rt_sigpending SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rt_sigpending SYSCALLID ID all all Yes \u0026gt; semtimedop SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; semtimedop SYSCALLID ID all all Yes \u0026gt; getitimer SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getitimer SYSCALLID ID all all Yes \u0026gt; timerfd_settime SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; timerfd_settime SYSCALLID ID all all Yes \u0026gt; sync_file_range2 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sync_file_range2 SYSCALLID ID all all Yes \u0026gt; ipc SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; ipc SYSCALLID ID all all Yes \u0026gt; mq_open SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mq_open SYSCALLID ID all all Yes \u0026gt; getcpu SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getcpu SYSCALLID ID all all Yes \u0026gt; epoll_pwait2 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; epoll_pwait2 SYSCALLID ID all all Yes \u0026gt; perf_event_open SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; perf_event_open SYSCALLID ID all all Yes \u0026gt; msgrcv SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; msgrcv SYSCALLID ID all all Yes \u0026gt; process_mrelease SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; process_mrelease SYSCALLID ID all all Yes \u0026gt; bdflush SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; bdflush SYSCALLID ID all all Yes \u0026gt; msgctl SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; msgctl SYSCALLID ID all all Yes \u0026gt; statfs64 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; statfs64 SYSCALLID ID all all Yes \u0026gt; fstatfs64 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fstatfs64 SYSCALLID ID all all Yes \u0026gt; fstatat64 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fstatat64 SYSCALLID ID all all Yes \u0026gt; sigprocmask SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sigprocmask SYSCALLID ID all all Yes \u0026gt; socketcall SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; socketcall SYSCALLID ID all all Yes \u0026gt; sys_debug_setcontext SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sys_debug_setcontext SYSCALLID ID all all Yes \u0026gt; set_tid_address SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; set_tid_address SYSCALLID ID all all Yes \u0026gt; _newselect SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; _newselect SYSCALLID ID all all Yes \u0026gt; map_shadow_stack SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; map_shadow_stack SYSCALLID ID all all Yes \u0026gt; sgetmask SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sgetmask SYSCALLID ID all all Yes \u0026gt; olduname SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; olduname SYSCALLID ID all all Yes \u0026gt; mq_getsetattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mq_getsetattr SYSCALLID ID all all Yes \u0026gt; nice SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; nice SYSCALLID ID all all Yes \u0026gt; tee SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; tee SYSCALLID ID all all Yes \u0026gt; waitpid SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; waitpid SYSCALLID ID all all Yes \u0026gt; fallocate SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fallocate SYSCALLID ID all all Yes \u0026gt; sigaltstack SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sigaltstack SYSCALLID ID all all Yes \u0026gt; getrandom SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getrandom SYSCALLID ID all all Yes \u0026gt; fadvise64 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; fadvise64 SYSCALLID ID all all Yes \u0026gt; memfd_secret SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; memfd_secret SYSCALLID ID all all Yes \u0026gt; kexec_file_load SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; kexec_file_load SYSCALLID ID all all Yes \u0026gt; close_range SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; close_range SYSCALLID ID all all Yes \u0026gt; pkey_alloc SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pkey_alloc SYSCALLID ID all all Yes \u0026gt; msgget SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; msgget SYSCALLID ID all all Yes \u0026gt; landlock_restrict_self SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; landlock_restrict_self SYSCALLID ID all all Yes \u0026gt; mq_timedreceive SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mq_timedreceive SYSCALLID ID all all Yes \u0026gt; landlock_add_rule SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; landlock_add_rule SYSCALLID ID all all Yes \u0026gt; msync SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; msync SYSCALLID ID all all Yes \u0026gt; modify_ldt SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; modify_ldt SYSCALLID ID all all Yes \u0026gt; migrate_pages SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; migrate_pages SYSCALLID ID all all Yes \u0026gt; futex_waitv SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; futex_waitv SYSCALLID ID all all Yes \u0026gt; move_pages SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; move_pages SYSCALLID ID all all Yes \u0026gt; mbind SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; mbind SYSCALLID ID all all Yes \u0026gt; epoll_ctl_old SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; epoll_ctl_old SYSCALLID ID all all Yes \u0026gt; statx SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; statx SYSCALLID ID all all Yes \u0026gt; io_pgetevents SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; io_pgetevents SYSCALLID ID all all Yes \u0026gt; set_mempolicy_home_node SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; set_mempolicy_home_node SYSCALLID ID all all Yes \u0026gt; getpmsg SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getpmsg SYSCALLID ID all all Yes \u0026gt; sigsuspend SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sigsuspend SYSCALLID ID all all Yes \u0026gt; nfsservctl SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; nfsservctl SYSCALLID ID all all Yes \u0026gt; rseq SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rseq SYSCALLID ID all all Yes \u0026gt; pciconfig_read SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pciconfig_read SYSCALLID ID all all Yes \u0026gt; sched_getattr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_getattr SYSCALLID ID all all Yes \u0026gt; faccessat2 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; faccessat2 SYSCALLID ID all all Yes \u0026gt; sync_file_range SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sync_file_range SYSCALLID ID all all Yes \u0026gt; readdir SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; readdir SYSCALLID ID all all Yes \u0026gt; s390_sthyi SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; s390_sthyi SYSCALLID ID all all Yes \u0026gt; s390_runtime_instr SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; s390_runtime_instr SYSCALLID ID all all Yes \u0026gt; sigreturn SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sigreturn SYSCALLID ID all all Yes \u0026gt; ftruncate SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; ftruncate SYSCALLID ID all all Yes \u0026gt; riscv_hwprobe SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; riscv_hwprobe SYSCALLID ID all all Yes \u0026gt; pwritev2 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pwritev2 SYSCALLID ID all all Yes \u0026gt; futex_requeue SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; futex_requeue SYSCALLID ID all all Yes \u0026gt; oldstat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; oldstat SYSCALLID ID all all Yes \u0026gt; multiplexer SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; multiplexer SYSCALLID ID all all Yes \u0026gt; oldlstat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; oldlstat SYSCALLID ID all all Yes \u0026gt; oldfstat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; oldfstat SYSCALLID ID all all Yes \u0026gt; ssetmask SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; ssetmask SYSCALLID ID all all Yes \u0026gt; spu_run SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; spu_run SYSCALLID ID all all Yes \u0026gt; iopl SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; iopl SYSCALLID ID all all Yes \u0026gt; getsid SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; getsid SYSCALLID ID all all Yes \u0026gt; swapcontext SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; swapcontext SYSCALLID ID all all Yes \u0026gt; pciconfig_write SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pciconfig_write SYSCALLID ID all all Yes \u0026gt; vm86 SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; vm86 SYSCALLID ID all all Yes \u0026gt; sched_get_priority_max SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; sched_get_priority_max SYSCALLID ID all all Yes \u0026gt; oldolduname SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; oldolduname SYSCALLID ID all all Yes \u0026gt; faccessat SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; faccessat SYSCALLID ID all all Yes \u0026gt; set_thread_area SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; set_thread_area SYSCALLID ID all all Yes \u0026gt; subpage_prot SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; subpage_prot SYSCALLID ID all all Yes \u0026gt; rt_sigreturn SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; rt_sigreturn SYSCALLID ID all all Yes \u0026gt; pciconfig_iobase SYSCALLID ID, UINT16 nativeID all all Yes \u0026lt; pciconfig_iobase SYSCALLID ID all all Tracepoint events Default Dir Name Params Linux versions Serverless versions Yes \u0026gt; switch PID next, UINT64 pgft_maj, UINT64 pgft_min, UINT32 vm_size, UINT32 vm_rss, UINT32 vm_swap all all Yes \u0026gt; procexit ERRNO status, ERRNO ret, SIGTYPE sig, UINT8 core, PID reaper_tid all all Yes \u0026gt; signaldeliver PID spid, PID dpid, SIGTYPE sig all all Yes \u0026gt; page_fault UINT64 addr, UINT64 ip, FLAGS32 error: PROTECTION_VIOLATION, PAGE_NOT_PRESENT, WRITE_ACCESS, READ_ACCESS, USER_FAULT, SUPERVISOR_FAULT, RESERVED_PAGE, INSTRUCTION_FETCH all all ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/linux-workload/"},{"id":846,"title":"Reference Library for Microsoft Entra ID Falco Threat Detection Rules","content":" FieldsField Class: JSON Name Type Description json.value CHARBUF Extracts a value from a JSON-encoded input. Syntax is json.value[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) json.obj CHARBUF The full json message as a text string. json.rawtime CHARBUF The time of the event, identical to evt.rawtime. jevt.value CHARBUF Alias for json.value, provided for backwards compatibility. jevt.obj CHARBUF Alias for json.obj, provided for backwards compatibility. jevt.rawtime CHARBUF Alias for json.rawtime, provided for backwards compatibility. Field Class: Microsoft Entra ID Name Type Description entra.tenantId CHARBUF Entra Tenant ID entra.time CHARBUF Entra event time entra.geo.city CHARBUF Entra geo city entra.geo.country_or_region CHARBUF Entra geo country or region entra.geo.lat CHARBUF Entra geo latitude entra.geo.lon CHARBUF Entra geo longitude entra.geo.state CHARBUF Entra geo state entra.operation CHARBUF Entra operation entra.operationType CHARBUF Entra operation type entra.srcip CHARBUF Entra source IP entra.resourceId CHARBUF Entra resource ID entra.correlationId CHARBUF Entra correlation ID entra.logCategory CHARBUF Entra log category entra.eventCategory CHARBUF Entra event category entra.userAgent CHARBUF Entra user agent entra.appId CHARBUF Entra app ID entra.user CHARBUF Entra user entra.userDisplayName CHARBUF Entra user display name entra.userRoles CHARBUF Entra user roles entra.app CHARBUF Entra app entra.service CHARBUF Entra service entra.result CHARBUF Entra result entra.resultReason CHARBUF Entra result reason entra.errorCode CHARBUF Entra error code entra.severity CHARBUF Entra severity entra.clientApp CHARBUF Entra client app entra.device.deviceId CHARBUF Entra device ID entra.device.displayName CHARBUF Entra device display name entra.device.browser CHARBUF Entra device browser entra.device.operatingSystem CHARBUF Entra device operating system entra.condAccess CHARBUF Entra conditional access entra.isInteractive CHARBUF Entra is interactive entra.idProvider CHARBUF Entra ID provider entra.idProviderType CHARBUF Entra ID provider type entra.authProcDetails CHARBUF Entra authentication processing details entra.networkDetails CHARBUF Entra network details entra.risk CHARBUF Entra risk entra.aggrRisk CHARBUF Entra aggregated risk entra.signinRisk CHARBUF Entra sign-in risk entra.riskEvents CHARBUF Entra risk events entra.signinResource CHARBUF Entra sign-in resource entra.homeTenantId CHARBUF Entra home tenant ID entra.authDetails CHARBUF Entra authentication details entra.authReqPolicies CHARBUF Entra authentication requirement policies entra.sessionPolicies CHARBUF Entra session policies entra.authReq CHARBUF Entra authentication requirement entra.servicePrincipalId CHARBUF Entra service principal ID entra.userType CHARBUF Entra user type entra.flaggedFailure CHARBUF Entra flagged failure entra.asn CHARBUF Entra autonomous system number entra.crossTenantType CHARBUF Entra cross tenant type entra.authStrengths CHARBUF Entra authentication strengths entra.tokenType CHARBUF Entra token type entra.authProtocol CHARBUF Entra authentication protocol entra.appServicePrincipalId CHARBUF Entra app service principal ID entra.resServicePrincipalId CHARBUF Entra resource service principal ID entra.tokenProtection CHARBUF Entra token protection entra.transferMethod CHARBUF Entra transfer method entra.targetResourceOfType.displayName CHARBUF Entra target resource display name filtered by type entra.targetResourceOfType.userPrincipalName CHARBUF Entra target resource user principal name filtered by type entra.targetResourceOfType.id CHARBUF Entra target resource ID filtered by type entra.targetResourceOfType.propertyWithDisplayName.oldValue CHARBUF Entra target resource property old value filtered by type and property display name entra.targetResourceOfType.propertyWithDisplayName.newValue CHARBUF Entra target resource property new value filtered by type and property display name entra.targetResourceOfType.propertyWithDisplayName.displayName CHARBUF Entra target resource property display name filtered by type and property display name entra.targetUsers LIST(CHARBUF) Entra target users entra.targetNames LIST(CHARBUF) Entra target names entra.targetTypes LIST(CHARBUF) Entra target types entra.targetIds LIST(CHARBUF) Entra target IDs entra.condAccessPolicies LIST(CHARBUF) Entra conditional access policies entra.additionalDetail CHARBUF Extracts from additionalDetail json a value in input. Syntax is entra.additionalDetail[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) entra.targetResources.propertyOldValue CHARBUF Extracts from properties.targetResources[arg1].modifiedProperties[arg2].oldValue[] entra.targetResources.propertyNewValue CHARBUF Extracts from properties.targetResources[arg1].modifiedProperties[arg2].newValue[] ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/entra/"},{"id":847,"title":"Reference Library for Okta Falco Threat Detection Rules","content":" FieldsField Class: JSON Name Type Description json.value CHARBUF Extracts a value from a JSON-encoded input. Syntax is json.value[], where is a json pointer (see https://datatracker.ietf.org/doc/html/rfc6901) json.obj CHARBUF The full json message as a text string. json.rawtime CHARBUF The time of the event, identical to evt.rawtime. jevt.value CHARBUF Alias for json.value, provided for backwards compatibility. jevt.obj CHARBUF Alias for json.obj, provided for backwards compatibility. jevt.rawtime CHARBUF Alias for json.rawtime, provided for backwards compatibility. Field Class: Okta Name Type Description okta.app CHARBUF Application okta.org CHARBUF Organization okta.evt.type CHARBUF Event Type okta.evt.legacytype CHARBUF Event Legacy Type okta.severity CHARBUF Severity okta.message CHARBUF Message okta.published CHARBUF Event Source Timestamp okta.actor.id CHARBUF Actor ID okta.actor.Type CHARBUF Actor Type okta.actor.alternateid CHARBUF Actor Alternate ID okta.actor.name CHARBUF Actor Display Name okta.client.zone CHARBUF Client Zone okta.client.ip CHARBUF Client IP Address okta.client.device CHARBUF Client Device okta.client.id CHARBUF Client ID okta.client.geo.city CHARBUF Client Geographical City okta.client.geo.state CHARBUF Client Geographical State okta.client.geo.country CHARBUF Client Geographical Country okta.client.geo.postalcode CHARBUF Client Geographical Postal Code okta.client.geo.lat CHARBUF Client Geographical Latitude okta.client.geo.lon CHARBUF Client Geographical Longitude okta.useragent.os CHARBUF Useragent OS okta.useragent.browser CHARBUF Useragent Browser okta.useragent.raw CHARBUF Raw Useragent okta.result CHARBUF Outcome Result okta.reason CHARBUF Outcome Reason okta.transaction.id CHARBUF Transaction ID okta.transaction.type CHARBUF Transaction Type okta.requesturi CHARBUF Request URI okta.principal.id CHARBUF Principal ID okta.principal.alternateid CHARBUF Principal Alternate ID okta.principal.type CHARBUF Principal Type okta.principal.name CHARBUF Principal Name okta.authentication.step CHARBUF Authentication Step okta.authentication.sessionid CHARBUF External Session ID okta.security.asnumber UINT64 Security AS Number okta.security.asorg CHARBUF Security AS Org okta.security.isp CHARBUF Security ISP okta.security.domain CHARBUF Security Domain okta.target.user.id CHARBUF Target User ID okta.target.user.alternateid CHARBUF Target User Alternate ID okta.target.user.name CHARBUF Target User Name okta.target.group.id CHARBUF Target Group ID okta.target.group.alternateid CHARBUF Target Group Alternate ID okta.target.group.name CHARBUF Target Group Name okta.target.app.alternateid CHARBUF Target App Alternate ID ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/okta/"},{"id":848,"title":"Packages","content":"Migrate to the Host ShieldYou can enable additional features such as Host Scanning, Host Security Posture Management, and Rapid Response directly from the package configuration.\nPackage Reference Driver Main Package Dependency Packages kmod (compatibility mode) draios-agent draios-agent-slim, draios-agent-kmodule kmod draios-agent-kmodule draios-agent-slim legacy_ebpf draios-agent-legacy-ebpf draios-agent-slim universal_ebpf draios-agent-slim Debian and Ubuntu Trust the Sysdig GNU Privacy Guard (GPG) key, configure the apt repository, and update the package list by running the following commands:\ncurl -s https://download.sysdig.com/DRAIOS-GPG-KEY.public -o /usr/share/keyrings/sysdig-keyring.asc echo \u0026#39;deb [signed-by=/usr/share/keyrings/sysdig-keyring.asc] https://download.sysdig.com/stable/deb stable-$(ARCH)/\u0026#39; | sudo tee /etc/apt/sources.list.d/sysdig.list \u0026gt; /dev/null apt-get update [kmod/legacy eBPF] Install kernel development files:\nsudo apt-get -y install linux-headers-$(uname -r) Install the Host Shield:\nsudo apt-get -y install draios-agent Specify the agent driver: To select the Universal eBPF driver (Recommended for Linux Kernel 5.8 and above):\ncat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=universal_ebpf\u0026#34; To select the kernel module driver (Recommended for below Linux Kernel 5.8):\ncat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=kmod\u0026#34; Note: On new installations, the kernel module driver is selected by default, and specifying it explicitly in /etc/default/dragent is optional.\nTo select the legacy eBPF driver (Not Recommended):\ncat \u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#39;export SYSDIG_BPF_PROBE=\u0026#34;\u0026#34;\u0026#39; cat \u0026gt;\u0026gt; /etc/default/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=legacy_ebpf\u0026#34; Configure Host Shield dragent.yaml:\nsudo bash -c \u0026#39;cat \u0026gt; /opt/draios/etc/dragent.yaml \u0026lt;\u0026lt;EOF customerid: \u0026lt;ACCESS_KEY\u0026gt; collector: \u0026lt;COLLECTOR_URL\u0026gt; collector_port: \u0026lt;COLLECTOR_PORT\u0026gt; EOF\u0026#39; Restart the Host Shield:\nsudo service dragent restart For CentOS, RHEL, Fedora, Amazon AMI, Amazon Linux 2 Trust the Sysdig GPG key and configure the yum repository:\nsudo rpm --import https://download.sysdig.com/DRAIOS-GPG-KEY.public \u0026amp;\u0026amp; sudo curl -s -o /etc/yum.repos.d/draios.repo https://download.sysdig.com/stable/rpm/draios.repo [kmod/legacy eBPF] Install the EPEL repository:\nsudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm This command is required only if DKMS is not available in the base distribution.\n[kmod/legacy eBPF] Install the kernel development files:\nsudo yum -y install kernel-devel-$(uname -r) Install the Host Shield:\nyum -y install draios-agent Specify the Host Shield driver: To select the Universal eBPF driver (Recommended for Linux Kernel 5.8 and above):\ncat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=universal_ebpf\u0026#34; To select the kernel module driver (Recommended for below Linux Kernel 5.8):\ncat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=kmod\u0026#34; Note: On new installations, the kernel module driver is selected by default, and specifying it explicitly in /etc/sysconfig/dragent is optional.\nTo select the legacy eBPF driver (Not Recommended):\ncat \u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#39;export SYSDIG_BPF_PROBE=\u0026#34;\u0026#34;\u0026#39; cat \u0026gt;\u0026gt; /etc/sysconfig/dragent \u0026lt;\u0026lt;\u0026lt; \u0026#34;SYSDIG_AGENT_DRIVER=legacy_ebpf\u0026#34; Configure Host Shield dragent.yaml:\nsudo bash -c \u0026#39;cat \u0026gt; /opt/draios/etc/dragent.yaml \u0026lt;\u0026lt;EOF customerid: \u0026lt;ACCESS_KEY\u0026gt; collector: \u0026lt;COLLECTOR_URL\u0026gt; collector_port: \u0026lt;COLLECTOR_PORT\u0026gt; EOF\u0026#39; Start the Host Shield:\nsudo systemctl enable dragent sudo systemctl start dragent ","url":"https://docs.sysdig.com/en/sysdig-monitor/install-host-packages/"},{"id":850,"title":"Sysdig Documentation","content":" ","url":"https://docs.sysdig.com/en/"},{"id":851,"title":"Terms of Use","content":" Terms of Use Your access to and use of the documentation located on this site is subject to the following terms and conditions and all applicable laws.\nBy accessing and using this documentation, you accept the following terms and conditions, without limitation or qualification. Unless otherwise stated, the contents of this site including, but not limited to, the text and images contained herein and their arrangement are the property of Sysdig, Inc.. All trademarks used or referred to in this website are the property of their respective owners. Nothing contained in this site shall be construed as conferring, by implication or otherwise, any license or right to any copyright, patent, trademark or other proprietary interest of Sysdig or any third party.\nThis site and the content provided in this site, including, but not limited to, graphic images, audio, video, html code, buttons, and text, may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, without the prior written consent of Sysdig, except that you may download, display, and print one copy of the materials on any single computer solely for your personal, non-commercial use, provided that you do not modify the material in any way and you keep intact all copyright, trademark, and other proprietary notices.\nThe information provided on this site is in most cases free of charge and for informational purposes only, and does not create a business or professional-services relationship between you and Sysdig. Links on this site may lead to services or sites not operated by Sysdig. No judgment or warranty is made with respect to such other services or sites and Sysdig takes no responsibility for such other sites or services. A link to another site or service is not an endorsement of that site or service. Any use you make of the information provided on this site, or any site or service linked to by this site, is at your own risk.\nThis site and its contents are provided \"as is\" and Sysdig makes no representation or warranty of any kind with respect to the documentation, any site or service accessible through this site. Sysdig expressly disclaims all express and implied warranties including, but not limited to, the implied warranties of merchantability, fitness for a particular purpose, title, and non-infringement. In no event will Sysdig be liable to any party for any direct, indirect, incidental, special, exemplary, consequential, or other damages (including, but not limited to, lost profits, business interruption, loss of programs or data) without regard to the form of action and whether in contract, tort, negligence, strict liability, or otherwise, arising out of or in connection with this documentation, any content on or accessed through this documentation or any site service linked to, or any copying, displaying, or use thereof.\nSysdig maintains this site in California, U.S.A. and you agree that these terms of use and any legal action or proceeding relating to this site shall be governed by the laws of the State of California without reference to its choice of law rules. You are responsible for complying with the laws of the jurisdiction from which you are accessing this site and you agree that you will not access or use the information on this site in violation of such laws.\nUnless expressly stated otherwise herein, any information submitted by you through this site shall be deemed non-confidential and non-proprietary. You represent that you have the lawful right to submit such information and agree that you will not submit any information unless you are legally entitled to do so. Because of the open nature of the Internet, we recommend that you not submit information you consider confidential.\nSysdig does not accept unauthorized idea submissions outside of established business relationships. To protect the interests of our current clients and ourselves, we must treat the issue of such submissions with great care. Importantly, without a clear business relationship, Sysdig cannot and does not treat any such submissions in confidence. Accordingly, please do not communicate unauthorized idea submissions to Sysdig through this website. Any ideas disclosed to Sysdig outside a pre-existing and documented confidential business relationship are not confidential and Sysdig may therefore develop, use and freely disclose or publish similar ideas without compensating you or accounting to you. Sysdig will make every reasonable effort to return or destroy any unauthorized idea submissions without detailed review of them. However, if a review is necessary in Sysdig's sole discretion, it will be with the understanding that Sysdig assumes no obligation to protect the confidentiality of your idea or compensate you for its disclosure or use. By submitting an idea or other detailed submission to Sysdig through this website, you agree to be bound by the terms of this stated policy.\n","url":"https://docs.sysdig.com/en/about/"},{"id":852,"title":"Reference Library for Windows workloads Falco Threat Detection Rules","content":" FieldsField Class: windows Name Type Description Versions fd.num UINT64 The unique number identifying the handle object all fd.type CHARBUF Handle type. Can be file, directory, module, key, event, mutex, semaphore, driver, process, thread, section, etc. all fd.typechar CHARBUF Handle type represented as a single character. Can be \u0026lsquo;f\u0026rsquo; for file, 4 for IPv4 socket, 6 for IPv6 socket, \u0026rsquo;e\u0026rsquo; for event object, \u0026rsquo;s\u0026rsquo; for section, etc. all fd.name CHARBUF Full handle name. If the handle is a file, this field contains the full path. If the handle is a registry key, this field represents the root and subkey union. The reasoning is similar with other handle types. all fd.directory CHARBUF If the handle is a file, represents the directory that contains it all fd.filename CHARBUF If the handle is a file, contains the filename without the path all fd.cip IPADDR Client IP address all fd.sip IPADDR Server IP address all fd.lip IPADDR Local IP address all fd.rip IPADDR Remote IP address all fd.cport UINT64 Client port all fd.sport UINT64 Server port all fd.lport UINT64 Local port all fd.rport UINT64 Remote port all fd.l4proto CHARBUF IP protocol. Can be \u0026rsquo;tcp\u0026rsquo;, \u0026lsquo;udp\u0026rsquo; all fd.sockfamily CHARBUF The socket family for network events all fd.is_server BOOL Returns true if the process owning the handle is the server endpoint in the connection all fd.uid CHARBUF Unique identifier for the handle all fd.containername CHARBUF Chaining of the container identifier and the handle name. Useful when trying to identify which container a handle belongs to all fd.containerdirectory CHARBUF Chaining of the container identifier and the directory name. Useful when trying to identify which container a directory belongs to all fd.cproto CHARBUF Client protocol all fd.sproto CHARBUF Server protocol all fd.lproto CHARBUF Local protocol all fd.rproto CHARBUF Remote protocol all fd.cnet IPNET Matches the client IP network all fd.snet IPNET Matches the server IP network all fd.lnet IPNET Matches the local IP network all fd.rnet IPNET Matches the remote IP network all fd.connected BOOL Returns true if the socket is connected all fd.cip.name CHARBUF Domain name associated with the client IP address all fd.sip.name CHARBUF Domain name associated with the server IP address all fd.lip.name CHARBUF Domain name associated with the local IP address all fd.rip.name CHARBUF Domain name associated with the remote IP address all fd.dev CHARBUF Device volume name for file handles all fd.ino CHARBUF File identifier of the referenced file all proc.pid UINT64 Identifier of the process generating the event all proc.exe CHARBUF Full executable path of the process generating the event all proc.name CHARBUF Name of the executable generating the event all proc.args CHARBUF Arguments passed on the command line when starting the process generating the event all proc.env CHARBUF Environment variables of the process generating the event all proc.cmdline CHARBUF Full process command line, i.e. proc.name + proc.args all proc.exeline CHARBUF Full process command line, i.e. proc.exe + proc.args all proc.cwd CHARBUF The current working directory of the process generating the event. all proc.nthreads UINT64 Number of threads that the process generating the event currently has, including the main process thread all proc.nchilds UINT64 Number of threads that the process generating the event currently has, excluding the main process thread all proc.ppid UINT64 Pid of the parent of the process generating the event all proc.pname CHARBUF Name excluding the path of the parent of the process generating the event all proc.pcmdline CHARBUF Full command line (proc.name + proc.args) of the parent of the process generating the event all proc.apid UINT64 Pid of one of the process ancestors. E.g. proc.apid[1] returns the parent pid, proc.apid[2] returns the grandparent pid, and so on. proc.apid[0] is the pid of the current process all proc.aname CHARBUF Name of one of the process ancestors. E.g. proc.aname[1] returns the parent name, proc.aname[2] returns the grandparent name, and so on. proc.aname[0] is the name of the current process all proc.duration UINT64 Number of nanoseconds since the process generating the event started all proc.fdopencount UINT64 Number of open handles for the process all thread.tid UINT64 Identifier of the thread generating the event all thread.ismain BOOL Returns true if the thread generating the event is the main one in the process all proc.sid UINT64 Session id of the process generating the event all proc.sname CHARBUF Name of the process owner of the job object generating the event all proc.tty BOOL Returns true if the process generating the event has attached a terminal all proc.exepath CHARBUF Full executable path of the process generating the event all proc.is_container_healthcheck BOOL Returns true if this process is running as a part of the container\u0026rsquo;s health check all proc.is_container_liveness_probe BOOL Returns true if this process is running as a part of the container\u0026rsquo;s liveness probe all proc.is_container_readiness_probe BOOL Returns true if this process is running as a part of the container\u0026rsquo;s readiness probe all proc.is_exe_writable BOOL Returns true if process\u0026rsquo; executable file is writable by the same user that spawned the process all proc.privileges_permitted CHARBUF Granted process token privileges all proc.privileges_inherited CHARBUF Inherited process token privileges all evt.type CHARBUF The name of the event (e.g. WriteFile) all evt.type.is BOOL Allows one to specify an event type, and returns true for events that are of that type. For example, evt.type.is[ReadFile] returns true for read file events, false for any other event all syscall.type CHARBUF The name of the system call. For example, if CreateHandle event is caputed with the mutex handle type this filed would return the NtCreateMutex syscall name all evt.category CHARBUF The event category. Example values are \u0026lsquo;file\u0026rsquo; for file operations like CreateFile/CloseFile, \u0026rsquo;net\u0026rsquo; for network operations like Accept/Send, \u0026lsquo;registry\u0026rsquo; for things like RegCreateKey, and so on all evt.cpu UINT64 Number of the CPU where the event happened all evt.args CHARBUF All the event arguments aggregated into a single string all evt.arg CHARBUF String representation of the event argument specified by name all evt.rawarg CHARBUF Raw representation of the event argument specified by name all evt.info CHARBUF For most events, this field returns the same value as evt.args all evt.buffer CHARBUF The binary data buffer for events that have one. For example, RegSetValue may write a binary content into registry value all evt.buflen UINT64 The length of the binary data buffer for events that have one all evt.res CHARBUF Event return value as a string. If the event failed, the result is an error code string (e.g. \u0026lsquo;The system cannot find the file specified.\u0026rsquo;). Otherwise, the result is the string \u0026lsquo;Success\u0026rsquo; all evt.rawres UINT64 Event return value as a number (e.g. -2). Useful for range comparisons all evt.failed BOOL Returns true for events that returned an error status all evt.is_io BOOL Returns true for events that produce read or write I/O, like WriteFile or Recv all evt.is_io_read BOOL Returns true for events that produce read I/O, like ReadFile or Recv all evt.io_io_write BOOL Returns true for events that produce write I/O, like WriteFile or Recv all evt.io_dir CHARBUF Returns \u0026lsquo;r\u0026rsquo; for events that produce read I/O like ReadFile or \u0026lsquo;w\u0026rsquo; for events that trigger write I/O like WriteFile all evt.is_wait BOOL Returns true for events that make the thread wait all evt.count UINT64 This filter field always returns 1 and can be used to count events all evt.count.error UINT64 This filter field returns 1 for events that returned with an error all evt.count.error.file UINT64 This filter field returns 1 for events that returned with an error and are related to file I/O all evt.count.error.net UINT64 This filter field returns 1 for events that returned with an error and are related to network I/O all evt.count.error.memory UINT64 This filter field returns 1 for events that returned with an error and are related to memory allocation all evt.count.error.other UINT64 This filter field returns 1 for events that returned with an error and are related to none of the previous categories all evt.around UINT64 Accepts the event if it\u0026rsquo;s around the specified time interval. The syntax is evt.around[T]=D, where T is the value returned by %evt.rawtime for the event and D is a delta in milliseconds. For example, evt.around[1404996934793590564]=1000 will return the events with timestamp with one second before the timestamp and one second after it, for a total of two seconds of capture all evt.abspath UINT64 Absolute path calculated from directory file handle all evt.is_open_read BOOL Returns true for events where the file was opened for reading all evt.is_open_write BOOL Returns true for events where the file was opened for writing all evt.is_open_exec BOOL Returns true for events where the executable file is created all user.uid CHARBUF User SID (Security Identifier) (e.g. S-1-5-18) all user.name CHARBUF User name all user.domain CHARBUF User domain (e.g. NT AUTHORITY) all user.homedir CHARBUF Home directory of the user all user.shell CHARBUF User\u0026rsquo;s shell all user.loginuid UINT64 User\u0026rsquo;s logon session identifier all user.loginname CHARBUF User\u0026rsquo;s logon name all user.logintype CHARBUF Type of the logon session (e.g. INTERACTIVE) all group.uid CHARBUF Group SID (Security Identifier) (e.g. S-1-5-32-544) all group.name CHARBUF Group name (e.g. Administrators) all container.id CHARBUF Unique container short identifier (e.g. 3ad7b26ded6d) all container.full_id CHARBUF Unique container full identifier (e.g. 3ad7b26ded6d8e7b23da7d48fe889434573036c27ae5a74837233de441c3601e) all container.name CHARBUF Container name all container.type CHARBUF Container engine type (e.g. docker) all container.image CHARBUF Container image name (e.g. falcosecurity/falco:latest) all container.image.id CHARBUF Container image identifier (e.g. 6f7e2741b66b) all container.image.repository CHARBUF Container image repository (e.g. falcosecurity/falco) all container.image.tag CHARBUF Container image tag (e.g. stable, latest) all container.image.digest CHARBUF Container image registry digest (e.g. sha256:d977378f890d445c15e51795296e4e5062f109ce6da83e0a355fc4ad8699d27) all container.mounts CHARBUF A space-separated list of mount information all container.mount CHARBUF Information about a single mount, specified by number mount source (e.g. container.mount[C:\\WINDOWS]) all container.mount.source CHARBUF The mount source specified by mount destination (e.g. container.mount.source[C:\\WINDOWS\\System32]) all container.mount.dest CHARBUF The mount dest specified by mount source (e.g. container.mount.source[C:\\WINDOWS\\System32]) all container.mount.mode CHARBUF The mount mode specified by mount source (e.g. container.mount.mode[C:\\WINDOWS]) all container.mount.rdwr CHARBUF The mount the mount rdwr value specified by mount source (e.g. container.mount.rdwr[C:\\WINDOWS]) all container.mount.propagation CHARBUF The mount propagation value specified by mount source (e.g. container.mount.propagation[C:\\WINDOWS]) all container.healthcheck CHARBUF Container\u0026rsquo;s health check. Will be the null value (\u0026lsquo;N/A\u0026rsquo;) if no healthcheck configured, \u0026lsquo;NONE\u0026rsquo; if configured but explicitly not created, and the healthcheck command line otherwise all container.liveness_probe CHARBUF Container\u0026rsquo;s liveness probe. Will be the null value (\u0026lsquo;N/A\u0026rsquo;) if no liveness probe configured, the liveness probe command line otherwise all container.readiness_probe CHARBUF Container\u0026rsquo;s readiness probe. Will be the null value (\u0026lsquo;N/A\u0026rsquo;) if no readiness probe configured, the readiness probe command line otherwise all container.start_ts UINT64 Container start as epoch timestamp in nanoseconds all container.duration UINT64 Number of nanoseconds since container.start_ts all container.ip IPADDR The container\u0026rsquo;s / pod\u0026rsquo;s primary ip address all container.cni.json CHARBUF The container\u0026rsquo;s / pod\u0026rsquo;s CNI result field from the respective pod status info all k8s.ns.name CHARBUF Kubernetes namespace name all k8s.pod.name CHARBUF Kubernetes pod name all k8s.pod.uid CHARBUF Kuberentes pod identifier all k8s.pod.sandbox_id CHARBUF The truncated Kubernetes pod sandbox identifier all k8s.pod.full_sandbox_id CHARBUF The full Kubernetes pod sandbox identifier all k8s.pod.label CHARBUF Kubernetes pod label (e.g. k8s.pod.label[foo]) all k8s.pod.labels CHARBUF Kubernetes pod comma-separated key/value labels (e.g. foo1:bar1,foo2:bar2) all k8s.pod.ip IPADDR The Kubernetes pod IP, same as container.ip as each container in a pod shares the network stack of the sandbox pod all k8s.pod.cni.json CHARBUF Pod CNI result in JSON format all ","url":"https://docs.sysdig.com/en/sysdig-secure/falco-reference-library/windows-workload/"}]