diff --git a/calico-cloud/get-started/cc-arch-diagram.mdx b/calico-cloud/get-started/cc-arch-diagram.mdx index b8986c4bba..9955c7c2ec 100644 --- a/calico-cloud/get-started/cc-arch-diagram.mdx +++ b/calico-cloud/get-started/cc-arch-diagram.mdx @@ -31,13 +31,11 @@ The following diagram shows the major components in a managed cluster, followed | $[prodname] installer | Gets installation resources from the $[prodname] portal, registers a managed cluster, and reports installation or upgrade progress. | • TCP 443 to $[prodname] hosted service
• TCP 6443 to Kubernetes API server | | $[prodname] tunnel server | Communicates with managed clusters by creating secure TLS tunnels. | Port 9000 from managed clusters | | calico-node | Bundles key components that are required for networking containers with $[prodname]:

• Felix
• BIRD
• confd | • TCP 5473 to Typha
• TCP 9900 and 9081 from Prometheus API service | -| Container threat detection | A threat detection engine that analyzes observed file and process activity to detect known malicious and suspicious activity. Monitors the following types of suspicious activity within containers:

• Access to sensitive system files and directories
• Defense evasion
• Discovery
• Execution
• Persistence
• Privilege escalation

Includes these components:

**Runtime Security Operator**
An operator to manage and reconcile container threat defense components.

**Runtime Reporter Pods**
Pods running on each node in the cluster to perform the detection activity outlined above.They send activity reports to Elasticsearch for analysis by $[prodname]. | TCP to Kubernetes API server | | Compliance | Generates compliance reports for the Kubernetes cluster. Reports are based on archived flow and audit logs for Calico Cloud resources, plus any audit logs you’ve configured for Kubernetes resources in the Kubernetes API server. Compliance reports provide the following high-level information:

• Endpoints explicitly protected using ingress or egress policy
• Policies and services
- Policies and services associated with endpoints
- Policy audit logs
• Traffic
- Allowed ingress/egress traffic to/from namespaces, and to/from the internet Compliance includes these components:

**compliance-snapshotter**
Handles listing of required Kubernetes and $[prodname]configuration and pushes snapshots to Elasticsearch. Snapshots give you visibility into configuration changes, and how the cluster-wide configuration has evolved within a reporting interval.

**compliance-reporter**
Handles report generation. Reads configuration history from Elasticsearch and determines time evolution of cluster-wide configuration, including relationships between policies, endpoints, services, and network sets. Data is then passed through a zero-trust aggregator to determine the “worst-case outliers” in the reporting interval.

**compliance-controller**
Reads report configuration and manages creation, deletion, and monitoring of report generation jobs.

**compliance-benchmarker**
A daemonset that runs checks in the CIS Kubernetes Benchmark on each node so you can see if Kubernetes is securely deployed.
| • TCP 8080 to Guardian
• TCP 6443 to Kubernetes API server | | Fluentd | Open-source data collector for unified logging. Collects and forwards $[prodname] logs (flows, DNS, L7) to log storage. | • TCP 8080 to Guardian
• TCP 9080 from Prometheus API service | | Guardian | An agent running in each managed cluster that proxies communication between the $[prodname] tunnel server and your managed cluster. Secured using TLS tunnels.
| • Port 9000 to tunnel server
• TCP 6443 to Kubernetes API server
• TCP 6443 from $[prodname] components | | Installation endpoints | Endpoints at `*.calicocloud.io` and `*.projectcalico.org`. | TCP 443 for both | | Intrusion detection controller | Handles integrations with threat intelligence feeds and $[prodname] custom alerts. | • TCP 8080 to Guardian
• TCP 6443 to Kubernetes API server | -| Image Assurance | Identifies vulnerabilities in container images that you deploy to Kubernetes clusters. Components of interest are:

**Admission controller**
Uses Kubernetes Validating Webhook Configuration to control which images can be used to create pods based on scan results.

**API**
Isolates tenant data and authorizes all external access to Image Assurance data. **Note:** $[prodname] does not store registry credentials in its database and does not pull customer images into the $[prodname] control plane.
| •  TCP 8080 to Guardian
• TCP 6443 to Kubernetes API server | | Kubernetes API server | A Kubernetes component that validates and configures data for the API objects (for example, pods, services, and others).
| TCP 6443 (from all components) | | kube-controllers | Monitors the Kubernetes API and performs actions based on cluster state. $[prodname] kube-controllers container includes these controllers:

• Node
• Service
• Federated services
• Authorization
| • TCP 9094 from Prometheus API service
• TCP 6443 to Kubernetes API server | | Log storage | Storage for logs (flows, L7, DNS, audit). Data for each managed cluster is isolated and protected against unauthorized access. | n/a | @@ -45,4 +43,4 @@ The following diagram shows the major components in a managed cluster, followed | Prometheus API service | Collects metrics from $[prodname] components and makes the metrics available to the web console. | • TCP 6443 to Kubernetes API server
• TCP 9080 to Fluentd
• TCP 9900 and 9081 to Prometheus API service | | Tigera API server | Allows users to manage $[prodname] resources such as policies and tiers through kubectl or the Kubernetes API server. | • TCP 9095 to Prometheus API service
• TCP 8080 from Kubernetes API server | | Typha | Increases scale by reducing each node’s impact on the datastore. | TCP 5473 from calico-node to Typha | -| User access to the web console | Authenticated users can access the browser-based the web console, which provides network traffic visibility and troubleshooting, centralized multi-cluster management, threat-defense, container threat detection, policy lifecycle management, scan images for vulnerabilities, and compliance for multiple roles/stakeholders. | Port 443 to $[prodname] tunnel server | \ No newline at end of file +| User access to the web console | Authenticated users can access the browser-based the web console, which provides network traffic visibility and troubleshooting, centralized multi-cluster management, threat-defense, policy lifecycle management, and compliance for multiple roles/stakeholders. | Port 443 to $[prodname] tunnel server | \ No newline at end of file diff --git a/calico-cloud/get-started/install-automated.mdx b/calico-cloud/get-started/install-automated.mdx index e726d97f8a..b70dfeeae4 100644 --- a/calico-cloud/get-started/install-automated.mdx +++ b/calico-cloud/get-started/install-automated.mdx @@ -91,28 +91,6 @@ If you're upgrading from Calico Cloud 19, the Packet Capture features will remai ::: -
- Use alternate feature keys for legacy features - - The Image Assurance and Container Threat Detection features were removed for new users in Calico Cloud 21.1.0. - Legacy users of those features can continue to use a deprecated version until the features are completely removed in a future release. - - - | Feature | Key | Values | - |---------|-----|--------| - | Image Assurance | `installer.components.imageAssurance.state` | `Enabled`, `Disabled` (default) | - | Container Threat Detection | `installer.components.runtimeSecurity.state` | `Enabled`, `Disabled` (default\*)
* The default for new clusters is `Disabled`. For upgrades for previously connected clusters, the default will retain the previous state. | - | Packet Capture | `installer.components.packetCaptureAPI.state` | `Enabled`, `Disabled` (default\*)
* The default for new clusters is `Disabled`. For upgrades for previously connected clusters, the default will retain the previous state. | - | Compliance Reports | `installer.components.compliance.enabled` | `true`, `false` (default) | - - :::note - - If you're upgrading from Calico Cloud 19, the Container Threat Detection and Packet Capture features will remain enabled unless you explicitly set them to `Disabled`. - - ::: - -
- ### Optional parameters for pod scheduling and resource management For many Calico Cloud components, you can specify node selectors, tolerations, and resource requests and limits. diff --git a/calico-cloud/get-started/install-cluster.mdx b/calico-cloud/get-started/install-cluster.mdx index fb05483bee..cc6484e449 100644 --- a/calico-cloud/get-started/install-cluster.mdx +++ b/calico-cloud/get-started/install-cluster.mdx @@ -23,22 +23,6 @@ You can quickly connect a cluster to Calico Cloud by generating a unique kubectl 1. Optional: If you must install a specific older release, select the Calico Cloud version you want to install. We always recommend the latest version, which is installed by default. 1. Click **Connect** to generate a unique kubectl command. Copy the command. - -
- Use alternate manifest for legacy features - - The Image Assurance and Container Threat Detection features were removed for new users in Calico Cloud 21.1.0. - Legacy users of those features can continue to use a deprecated version until the features are completely removed in a future release. - - To continue using these features, modify the generated command by replacing **two instances** of `deploy.yaml` with `deploy-with-container-security.yaml`. - This change gives you a manifest with all three legacy features enabled. - You cannot enable or disable these features individually. - - ```bash title="Example of generated kubectl command with alternate manifest" - kubectl apply -f https://installer.calicocloud.io/manifests/cc-operator/latest/deploy-with-container-security.yaml && curl -H "Authorization: Bearer ..." "https://www.calicocloud.io/api/managed-cluster/deploy-with-container-security.yaml?version=$[cloudUserVersion]" | kubectl apply -f - - ``` -
- 1. From a terminal, paste and run the command. 1. On the **Managed Clusters** page, you should immediately see your cluster in the list of managed clusters. Monitor the status under **Connection Status**. @@ -70,29 +54,6 @@ You can quickly connect a cluster to Calico Cloud by generating a unique kubectl In this example, the command connects the cluster to Calico Cloud with the Packet Capture feature enabled. -
- Use alternate feature keys for legacy features - - The Image Assurance and Container Threat Detection features were removed for new users in Calico Cloud 21.1.0. - Legacy users of those features can continue to use a deprecated version until the features are completely removed in a future release. - - - | Feature | Key | Values | - |---------|-----|--------| - | Image Assurance | `installer.components.imageAssurance.state` | `Enabled`, `Disabled` (default) | - | Container Threat Detection | `installer.components.runtimeSecurity.state` | `Enabled`, `Disabled` (default\*)
* The default for new clusters is `Disabled`. For upgrades for previously connected clusters, the default will retain the previous state. | - | Packet Capture | `installer.components.packetCaptureAPI.state` | `Enabled`, `Disabled` (default\*)
* The default for new clusters is `Disabled`. For upgrades for previously connected clusters, the default will retain the previous state. | - | Compliance Reports | `installer.components.compliance.enabled` | `true`, `false` (default) | - - ```bash title="Example of generated Helm command with user-added parameters" - helm repo add calico-cloud https://installer.calicocloud.io/charts --force-update && helm upgrade --install calico-cloud-crds calico-cloud/calico-cloud-crds --namespace calico-cloud --create-namespace && helm upgrade --install calico-cloud calico-cloud/calico-cloud --namespace calico-cloud --set apiKey=ryl34elz8:9dav6eoag:ifk1uwruwlgp7vzn7ecijt5zjbf5p9p1il1ag8877ylwjo4muu19wzg2g8x5qa7x --set installer.clusterName=my-cluster --set installer.calicoCloudVersion=v19.1.0 \ - --set installer.components.imageAssurance.state=Enabled \ - --set installer.components.runtimeSecurity.state=Enabled \ - ``` - In this example, the command connects the cluster to Calico Cloud with Image Assurance and Container Threat Detection features enabled. - -
- 1. From a terminal, paste and run the command. 1. On the **Managed Clusters** page, you should immediately see your cluster in the list of managed clusters. Monitor the status under **Connection Status**. diff --git a/calico-cloud/get-started/install-private-registry.mdx b/calico-cloud/get-started/install-private-registry.mdx index 2427cf2851..b0049bd78c 100644 --- a/calico-cloud/get-started/install-private-registry.mdx +++ b/calico-cloud/get-started/install-private-registry.mdx @@ -48,29 +48,6 @@ You can perform a Helm installation from images stored on a private registry. In this example, the command connects the cluster to Calico Cloud with the Packet Capture feature enabled. -
- Use alternate feature keys for legacy features - - The Image Assurance and Container Threat Detection features were removed for new users in Calico Cloud 21.1.0. - Legacy users of those features can continue to use a deprecated version until the features are completely removed in a future release. - - - | Feature | Key | Values | - |---------|-----|--------| - | Image Assurance | `installer.components.imageAssurance.state` | `Enabled`, `Disabled` (default) | - | Container Threat Detection | `installer.components.runtimeSecurity.state` | `Enabled`, `Disabled` (default\*)
* The default for new clusters is `Disabled`. For upgrades for previously connected clusters, the default will retain the previous state. | - | Packet Capture | `installer.components.packetCaptureAPI.state` | `Enabled`, `Disabled` (default\*)
* The default for new clusters is `Disabled`. For upgrades for previously connected clusters, the default will retain the previous state. | - | Compliance Reports | `installer.components.compliance.enabled` | `true`, `false` (default) | - - ```bash title="Example of generated Helm command with user-added parameters" - helm repo add calico-cloud https://installer.calicocloud.io/charts --force-update && helm upgrade --install calico-cloud-crds calico-cloud/calico-cloud-crds --namespace calico-cloud --create-namespace && helm upgrade --install calico-cloud calico-cloud/calico-cloud --namespace calico-cloud --set apiKey=ryl34elz8:9dav6eoag:ifk1uwruwlgp7vzn7ecijt5zjbf5p9p1il1ag8877ylwjo4muu19wzg2g8x5qa7x --set installer.clusterName=my-cluster --set installer.calicoCloudVersion=v19.1.0 \ - --set installer.components.imageAssurance.state=Enabled \ - --set installer.components.runtimeSecurity.state=Enabled \ - ``` - In this example, the command connects the cluster to Calico Cloud with Image Assurance and Container Threat Detection features enabled. - -
- 1. From a terminal, paste and run the command. 1. On the **Managed Clusters** page, you should immediately see your cluster in the list of managed clusters. diff --git a/calico-cloud/get-started/operator-checklist.mdx b/calico-cloud/get-started/operator-checklist.mdx index 4f10fc6a53..c7839b83f3 100644 --- a/calico-cloud/get-started/operator-checklist.mdx +++ b/calico-cloud/get-started/operator-checklist.mdx @@ -53,17 +53,10 @@ intrusion-detection True False False 9m49s log-collector True False False 9m29s management-cluster-connection True False False 9m54s monitor True False False 10m -runtime-security True False False 10m ``` If all components show a status of "Available" = TRUE, $[prodname] is properly installed. -:::note - -The `runtime-security` component is available only if [the container threat detection feature is enabled](../threat/container-threat-detection.mdx#enable-container-threat-detection). - -::: - **Issue: $[prodname] is not installed** If $[prodname] is not installed, you'll get the following error. Install $[prodname] on the node using the `curl` command that you got from Support. @@ -373,21 +366,6 @@ NAME AGE tigera-secure 98m ``` -**Check runtime security ** - -```bash -kubectl get runtimesecurity.operator.tigera.io default -``` - -``` -NAME AGE -default 99m -``` - -:::note -The `runtime-security` custom resource will only be available if the container threat detection feature is enabled. -::: - For more information on operator custom resources see the [Installation API reference](../reference/installation/api.mdx). ### Deep dive into custom resources @@ -408,7 +386,6 @@ kubectl get tigerastatus | 6 | log-collector | TRUE | FALSE | FALSE | 9m29s | | 7 | management-cluster-connection | TRUE | FALSE | FALSE | 9m54s | | 8 | monitor | TRUE | FALSE | FALSE | 11m | -| 9 | runtime-security | TRUE | FALSE | FALSE | 10m | **1 - api server** @@ -572,19 +549,6 @@ calico-prometheus-operator-77bf897c9b-7f88x 1/1 Running 0 125m prometheus-calico-node-prometheus-0 3/3 Running 1 125m ``` -**9 - runtime-security** - -`runtime-security` is responsible for the container threat detection feature. Check the pods and logs in the `calico-cloud` namespace with the label selector `k8s-app=tigera-runtime-security-operator`. - -```bash -$ kubectl get pods -n calico-cloud -l k8s-app=tigera-runtime-security-operator -``` - -``` -NAME READY STATUS RESTARTS AGE -tigera-runtime-security-operator-127b606afc-ap25k 1/1 Running 0 80m -``` - ### Check additional custom resources Check for the presence of other custom resources created by the Tigera Operator: FelixConfiguration, IPPool, Tigera License, and Prometheus for component metrics. diff --git a/calico-cloud/get-started/upgrade-cluster.mdx b/calico-cloud/get-started/upgrade-cluster.mdx index 4a1d578170..4504383550 100644 --- a/calico-cloud/get-started/upgrade-cluster.mdx +++ b/calico-cloud/get-started/upgrade-cluster.mdx @@ -10,21 +10,6 @@ To upgrade a managed cluster to the latest version of $[prodname]: 1. If your organization uses multiple projects to group managed clusters, click the **Project** menu and select the project you want your cluster to be part of. 1. For the cluster you want to upgrade, select **Actions** > **Reinstall**. 1. In the **Reinstall Cluster** dialog, select a newer version of $[prodname] from the list, click **Reinstall**, and copy the generated kubectl command. -
- Use alternate manifest for legacy features - - The Image Assurance and Container Threat Detection features were removed for new users in Calico Cloud 21.1.0. - Legacy users of those features can continue to use a deprecated version until the features are completely removed in a future release. - - To continue using these features, modify the generated command by replacing **two instances** of `deploy.yaml` with `deploy-with-container-security.yaml`. - This change gives you a manifest with all three legacy features enabled. - You cannot enable or disable these features individually. - - ```bash title="Example of generated kubectl command with alternate manifest" - kubectl apply -f https://installer.calicocloud.io/manifests/cc-operator/latest/deploy-with-container-security.yaml && curl -H "Authorization: Bearer ..." "https://www.calicocloud.io/api/managed-cluster/deploy-with-container-security.yaml?version=$[cloudUserVersion]" | kubectl apply -f - - ``` -
- 1. From a terminal, paste and run the command. The cluster's status under **Connection Status** changes to **Disconnected: Installing**. When the upgrade is complete, the status changes to **Connected**. diff --git a/calico-cloud/get-started/windows-limitations.mdx b/calico-cloud/get-started/windows-limitations.mdx index 498113dd97..94703b1a5e 100644 --- a/calico-cloud/get-started/windows-limitations.mdx +++ b/calico-cloud/get-started/windows-limitations.mdx @@ -14,7 +14,6 @@ description: Known limitations for Calico Cloud on Windows worker nodes that you | Policy | - Staged network-policy
- Firewall integrations
- Policy for hosts (host endpoints, including automatic host endpoints)
- Tiered policy: TKG, GKE, AKS
- WAF integration
- AWS firewall integration
- Fortinet integration | | Visibility and troubleshooting | - Packet capture
- DNS logs
- iptables logs
- L7 logs | | Threat defense | - No threat defense features are supported. | -| Image Assurance | - No Image Assurance features are supported. | Multi-cluster management | - Multi-cluster management federated identity endpoints and services
- Federated endpoint identity and services | | Compliance and security | - CIS benchmark and other reports
- WireGuard encryption for pod-to-pod traffic and host-to-host traffic | | Data plane | - eBPF is a Linux-based feature | diff --git a/calico-cloud/image-assurance/creating-jira-issues-for-scan-results.mdx b/calico-cloud/image-assurance/creating-jira-issues-for-scan-results.mdx deleted file mode 100644 index 68c409ff04..0000000000 --- a/calico-cloud/image-assurance/creating-jira-issues-for-scan-results.mdx +++ /dev/null @@ -1,47 +0,0 @@ ---- -description: Create Jira issues from Calico Cloud Image Assurance scan results so security teams can assign and track vulnerability remediation work outside the web console. ---- - -import IconUser from '/img/icons/user-icon.svg'; - -# Create a Jira issue for your image scan results - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -You can create and assign Jira issues with information about vulnerabilities from your Image Assurance scan results. - -![ia-jira-after-creation](/img/calico-cloud/ia-jira-after-creation.png) -*Scan results detail with link to Jira issue.* - -## Add Jira credentials to Calico Cloud - -You must add Jira user credentials to Calico Cloud to create issues for scanned images. - -***Prerequisites*** - -* You have access to a Jira user account with permissions to create issues in a project. -* For the Jira user account, you have: - * An Atlassian site URL. If you access Jira at the URL `https://.atlassian.net/jira`, then your site URL is `.atlassian.net`. - * An API token. - For details on how to get an API token, see [Manage API tokens for your Atlassian account](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/). - -1. In the web console, the user icon **> Settings**. -1. Select the **Jira** tab, complete the fields with information about your Jira user account, and then click **Save**. -1. Select the Jira project you want Calico Cloud to create issues for, and then click **Save**. - -## Create a Jira issue for a scanned image - -You can create and assign a Jira issue directly from the scan results information page for an image. - -1. From the web console, click **Image Assurance >All Scanned Images**. -1. Click an item in the list of scanned images to open a detailed view of the vulnerabilities in that image. -1. In the **Jira** section, click **Add Ticket**. -1. In the **Add Jira issue** dialog, complete the fields and click **Create Jira issue**. - A link to the new Jira issue will be added to the detailed view page. \ No newline at end of file diff --git a/calico-cloud/image-assurance/exclude-vulnerabilities-from-scan-results.mdx b/calico-cloud/image-assurance/exclude-vulnerabilities-from-scan-results.mdx deleted file mode 100644 index cb9e2b85bf..0000000000 --- a/calico-cloud/image-assurance/exclude-vulnerabilities-from-scan-results.mdx +++ /dev/null @@ -1,90 +0,0 @@ ---- -description: Exclude false-positive or low-priority vulnerabilities from Calico Cloud Image Assurance scan results to cut noise and focus on findings that need remediation. ---- - -import UploadIcon from '/img/icons/upload-icon.svg'; - -# Exclude vulnerabilities from scan results - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -This guide shows you how to exclude vulnerabilities from your image scan results. -By excluding vulnerabilities that don't require action, such as false positives, you can reduce the volume of reported vulnerabilities that you need to deal with. -You can set the exclusion for a particular vulnerability to apply to a particular image version, all images in a repository, or all images in the system. - -:::caution -Excluding vulnerabilities from image results can significantly change how Image Assurance determines image health. -You may need to take corrective action to stabilize your workflow. -- **Maximum CVSS score:** An image’s maximum CVSS score may be reduced to a lower score. -An exception could eliminate the vulnerability with the highest CVSS score for an image. -- **Scan assessment:** The assessment value (Pass, Warn, or Fail) could change because it is based on the maximum CVSS score. -For example, Fail could change to Warn, and Warn could change to Pass. -- **Vulnerability global alerts:** Alerts may no longer be triggered. -Alerts are triggered based on scan results or maximum CVSS score values of images. -- **Admission controller policies:** Pods could be created where they were previously blocked. -Admission controller policies are based on vulnerability information (scan result or maximum CVSS score). - -::: - -## Exclude a vulnerability from your scan results - -You can exclude a vulnerability from your scan results page. - -1. From the web console, go to **Image Assurance > All Scan Results**. -1. Select an image from the list. -1. On the scan results panel that appears, expand a package, and then click **Actions > Add Exception**. -1. On the **Add exception** dialog, select a scope, enter an explanation for why you're creating an exception, and then click **Save**. - -## Exclude multiple vulnerabilities at the same time - -To exclude large numbers of vulnerabilities, you can organize the required information as a CSV file and import it directly to Calico Cloud. - -1. Optional: You can start with a preformatted list of all vulnerabilities in your cluster, and then edit the list to include only those vulnerabilities you want to exclude. -1. From the web console, go to **Image Assurance > All Scan Results**. -1. On the **All Scan Results** page, click the **Export** button, and then click **Export data**. -1. On the **Export** dialog that appears, select the **CSV** data type and the **Export a row for each image and CVE IDs** option for the table style. -Click **Export** to download the CSV file. -1. Edit the CSV file - -1. Prepare the CSV file with information about the vulnerabilities you want to exclude. -The file must contain the following information: - -| Column header | Description | Example | - | -- | -- | -- | -| `CVE` | The CVE identifier. Required by the `any`, `repo`, and `image` scopes. | `CVE-2024-1234` | -| `Registry`| The URL path to the container registry. Required by the `repo` and `image` scopes. | `mycontainerregistry.io/my-org` | -| `Repository`| The container image name. Required by the `repo` and `image` scopes.| `my-application` | -| `Tags`| A JSON list of image tags. Required by the `image` scope. | `"[""v1.2.3"",""v2.3.4""]"` | -| `Justification` | Your explanation for why you're excluding this vulnerability. Required by the `any`, `image`, and `image` scopes.| `This one is a false positive.` | -| `Scope` | Determines whether the vulnerability exception applies only to specific tagged images, to any image in a specific repository, or to any image where the vulnerability is found. One of the following values is required:
• `any`: The exception applies to all images.
• `repo`: The exception applies to all versions of an image in a repository.
• `image`: The exception applies to a specific, tagged version of an image. | `image` | - -:::tip -An exported vulnerability list (see step 1) includes many more columns than what is required to import vulnerability exceptions in bulk. -You do not need to remove or reorganize the extraneous information, but you do need to add two new columns for `Justification` and `Scope`. -::: - -Example: a CSV list of vulnerability exclusion definitions - -``` title="example-vulnerability-exclusions.csv" -CVE,Registry,Repository,Tags,Justification,Scope -CVE-2024-1234,mycontainerregistry.io/my-org,my-application,"[""v3.4.5""]",justification,image -CVE-2024-2345,mycontainerregistry.io/my-org,my-application,"[""v1.2.3"",""v2.3.4""]",justification,image -CVE-2024-3456,mycontainerregistry.io/my-org,my-application,,justification,repo -CVE-2024-4567,,,,justification,any - ``` - -1. In the web console, go to **Image Assurance > Vulnerability Exceptions**, and then click  **Upload exceptions**. -1. Select the CSV file you created, and then click **Upload file**. -After the data is validated, you'll see a summary of the exceptions. -If there are errors, modify your CSV file and repeats steps 1 and 2. -1. Review the processed exceptions on the summary page click **Create exceptions**. -The new exceptions are listed on the **Vulnerability Exceptions** page. - - diff --git a/calico-cloud/image-assurance/index.mdx b/calico-cloud/image-assurance/index.mdx deleted file mode 100644 index 5b8c827e2c..0000000000 --- a/calico-cloud/image-assurance/index.mdx +++ /dev/null @@ -1,36 +0,0 @@ ---- -description: Calico Cloud Image Assurance detects vulnerabilities in container images and blocks risky workloads with admission control across cluster, registry, and pipeline scanners. -hide_table_of_contents: true ---- - -import { DocCardLink, DocCardLinkLayout } from '/src/___new___/components'; - -# Image Assurance - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -Detect and block vulnerable images from container workloads. - -## Scanning images for vulnerabilities - - - - - - - - -## Working with scan results - - - - - - \ No newline at end of file diff --git a/calico-cloud/image-assurance/install-the-admission-controller.mdx b/calico-cloud/image-assurance/install-the-admission-controller.mdx deleted file mode 100644 index 758a80db0d..0000000000 --- a/calico-cloud/image-assurance/install-the-admission-controller.mdx +++ /dev/null @@ -1,181 +0,0 @@ ---- -description: Install the Calico Cloud Image Assurance admission controller to block vulnerable images from deploying to a cluster based on CVSS thresholds and exception lists. ---- - -# Create policy to block vulnerable images from your cluster - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -:::note - -This feature is tech preview. Tech preview features may be subject to significant changes before they become GA. - -::: - -## Big picture - -Protecting your cluster from vulnerable images can be very difficult. An image that appears to be secure today could -contain a newly-discovered vulnerability tomorrow, and acting on this new information in real time can be challenging. - -$[prodname]’s Image Assurance Admission Controller automatically blocks resources that would create containers with vulnerable images from entering your cluster using the latest vulnerability data and scan results. - -## Concepts - -### About the $[prodname] Admission Controller - -$[prodname] uses [Kubernetes Validating Webhook Configuration](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) to register the $[prodname] Admission Controller as a callback to accept or reject resources that create pods (such as deployments and daemonsets). - -### How the Admission Controller evaluates admission requests - -The $[prodname] Admission Controller blocks the creation or modification of resources that create pods. If a resource that creates pods is admitted by the Admission Controller, _the pods it creates are not reevaluated_. For example, if you create a deployment, the Admission Controller receives an admission request and either allows or rejects the request. If allowed, the Admission Controller will not evaluate the request for the replica set that Kubernetes creates for the deployment or the pod that is created for the replica set. Why? Because it could destabilize a production cluster if new vulnerabilities are found for deployed images and pods are restarted. - -However, if you _create a pod directly_, the Admission Controller evaluates the admission request for the pod and allows or rejects the request. - -### About container admission policies - -Container admission policies are custom Kubernetes resources that allow you to configure the criteria for the Admission Controller to reject admission requests for resources that create pods. - -## How to - -- [Install the Admission Controller](#install-the-admission-controller) -- [Create container admission policies](#create-container-admission-policies) -- [Troubleshoot](#troubleshoot) - -### Install the Admission Controller - -1. Create a directory to download the manifests/scripts needed for the installation. - - ```bash - mkdir admission-controller-install && cd admission-controller-install - ``` - -1. Generate the certificate key pair. - - For secure TLS communication between the Kubernetes API server and the Admission controller, you must generate a TLS - certificate and key pair. - - You can either generate the TLS key and certificate yourself and move them to the current folder under the names - `admission_controller_key.pem` and `admission_controller_cert.pem`, or use the following command to generate the pair: - - ```bash - export URL="$[clouddownloadurl]/manifests" && curl ${URL}/generate-open-ssl-key-cert-pair.sh | bash - ``` - - :::caution - - If you generate the key and certificate pair yourself, you must set the SANS to `tigera-image-assurance-admission-controller-service.tigera-image-assurance.svc`. - - ::: - -1. Download and configure the Admission Controller manifests. - -As a safety mechanism, we require that you specify the namespaces that the Admission Controller will apply in -the `IN_NAMESPACE_SELECTOR_KEY` and the `IN_NAMESPACE_SELECTOR_VALUES`. These values configure the Kubernetes API server to send admission requests to our Admission Controller only for resources from relevant namespaces. - -For example, to configure the Kubernetes API server to send admission requests for -resources created in any namespace with label key `name`, and label values either `prod` or `staging-test`, set the variables as follows: - - ```bash - export IN_NAMESPACE_SELECTOR_KEY="name" && export IN_NAMESPACE_SELECTOR_VALUES="prod staging-test" - ``` -Here is the namespace manifest with the staging-test label and name key. - - ```yaml - kind: Namespace - apiVersion: v1 - metadata: - name: staging-test - labels: - name: staging-test - ``` -:::caution - -Do not add Kubernetes critical namespaces such as the `kube-system` namespace. This could create a -deadlock situation where you cannot bring up the Admission Controller because a critical Kubernetes pod is not running, but you also cannot bring up the critical Kubernetes pod because the Admission Controller is not running. -::: - - ```bash - export IN_NAMESPACE_SELECTOR_KEY="name" && \ - export IN_NAMESPACE_SELECTOR_VALUES="prod staging-test" && \ - curl ${URL}/install-ia-admission-controller.sh | bash - ``` - -4. Apply the Admission Controller manifests. - - ```bash - kubectl apply -f ./tigera-image-assurance-admission-controller-deploy.yaml - ``` - -## Create container admission policies - -Container admission policies are used to define criteria for the Admission Controller to admit or reject admission for resources that create pods. For details, see [ContainerAdmissionPolicies](../reference/resources/containeradmissionpolicy.mdx). - -**Sample container admission policies** - -This ContainerAdmissionPolicy allows admission requests for pod-creating resources whose image is in the registry/repository `gcr.io/company/production-repository/*`, with a scan status of either `Pass` or `Warn`, and rejects all other admission requests. - -```yaml -apiVersion: containersecurity.tigera.io/v1beta1 -kind: ContainerAdmissionPolicy -metadata: - name: reject-failed-and-non-gcr -spec: - selector: all() - namespaceSelector: all() - order: 10 - rules: - - action: 'Reject' - imagePath: - operator: IsNoneOf - values: - - '^gcr.io/company/production-repository/.*' - - action: Allow - imageScanStatus: - operator: IsOneOf - values: - - Pass - - Warn - - action: Reject -``` - -The following ContainerAdmissionPolicy rejects deploying or updating pod-creating resources with the label, `reject-policy: reject-outdated-scans`, -from any namespace labeled, `apply-container-admission-policies == 'true'`, that would deploy an image that hasn't been scanned in 3 days. - -```yaml -apiVersion: containersecurity.tigera.io/v1beta1 -kind: ContainerAdmissionPolicy -metadata: - name: reject-failed-and-non-gcr -spec: - selector: "reject-policy == 'reject-outdated-scans'" - namespaceSelector: "apply-container-policies == 'true'" - order: 1 - rules: - - action: Allow - imageLastScan: - operator: 'gt' - duration: - days: 3 - - action: Reject -``` - -The first rule (Allow), allows images based on the age of the image scan (in days). In this example, we want to allow -images that have been scanned within the last three days. So, we use the gt operator (greater than), along with Duration, -3 days, to say the image scan time must be greater than 3 days ago but less than now. "Now" is defined as when the -attempt was made to create the Kubernetes resource. If the Allow rule does not match, then the second action rule -(Reject) is evaluated, which denies everything. - -You can also use modify the Allow rule to match an absolute time. For help, see [ContainerAdmissionPolicies](../reference/resources/containeradmissionpolicy.mdx). - -## Troubleshoot - -**My container admission policy is not blocking resources from a namespace, even though the namespaceSelector matches the namespace** - -This indicates that the Kubernetes API server is not sending admission requests for the namespace. Verify that the key and value(s) that you specified for `IN_NAMESPACE_SELECT_KEY` and `IN_NAMESPACE_SELECT_VALUES` in the installation steps, match the policy namespaces. diff --git a/calico-cloud/image-assurance/scanners/cluster-scanner.mdx b/calico-cloud/image-assurance/scanners/cluster-scanner.mdx deleted file mode 100644 index 5fe93b5006..0000000000 --- a/calico-cloud/image-assurance/scanners/cluster-scanner.mdx +++ /dev/null @@ -1,131 +0,0 @@ ---- -description: Scan every image running in a Kubernetes cluster with the Calico Cloud Image Assurance cluster scanner to catch CVEs in deployed and third-party images. ---- - -# Scan images in a Kubernetes cluster - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -Scan all images in a Kubernetes cluster for vulnerabilities to achieve a continuous clean bill of health and defense in depth. - -Common use cases for scanning in a Kubernetes cluster are: - -- Images may pass scanning during the build phase, but they could contain vulnerabilities days or weeks later -- Third-party images that are pulled from public registries are often not scanned in build pipelines and can contain Critical or High vulnerabilities -- Application teams may build one-off images outside of their pipeline to make an emergency patch and fix a critical bug. - -## About Image Assurance scanner - -The Image Assurance scanner that runs in a Kubernetes cluster is out-of-the-box ready to use without configuration. It runs as a daemonset in a managed cluster where images are located, and is installed on all nodes in the cluster. - -Vulnerability detection consists of these steps: - -- **Image Assurance scanner** - generates a dependency list Software Bill of Materials (SBOM) using Syft -- **Vulnerability lookup** - $[prodname] uploads the SBOM where packages are matched with known CVEs in the vulnerability databases based on dependencies using Grype - -![vulnerability-detection](/img/calico-cloud/vulnerability-detection.png) - -$[prodname] checks running images for new vulnerabilities every 24 hours and reports scan results to the Image dashboard in the web console. - -## Before you begin - -**Unsupported** -- OpenShift -- GCP-Kubeadm -- AWS-Kubeadm -- GKE - -**Cluster requirements** -- Containerd is the container runtime -- AKS clusters: if you are using Kubernetes v1.19 or higher, containerd should be your default runtime -- Containerd must be using overlays or native file system snapshotter - -## How to -- [Get latest version of Image Assurance](#get-latest-version-of-image-assurance) -- [Enable scanner](#enable-scanner) -- [Customize scanner settings](#customize-scanner-settings) -- [Disable scanner](#disable-scanner) - -### Get latest version of Image Assurance - -1. On the **Managed Clusters** page, select the cluster from the list, and click **Reinstall**. -1. Copy the updated installation script command and run it against your cluster. - -### Enable scanner - -Complete the following steps for each managed cluster you want enabled with the cluster scanner: - -1. Modify the [Image Assurance](../../reference/installation/ia-api.mdx#image-assurance.operator.tigera.io/v1.ImageAssuranceSpec) installation resource. - - ```bash - kubectl edit imageassurance default - ``` - -2. Set the `clusterScanner` field to `Enabled` and save the file. - -The cluster scanner is deployed as a container inside the `tigera-image-assurance-crawdad` daemonset. - -3. Verify that a new container with name, `cluster-scanner` is created inside the daemonset. - -That’s it. The cluster scanner will start scanning images on running pods in the cluster. For help viewing image events in the web console, see [View scanned and running images](../understanding-scan-results). - -### Customize scanner settings - -To change default settings, modify the [Image Assurance](../../reference/installation/ia-api.mdx#image-assurance.operator.tigera.io/v1.ImageAssuranceSpec) installation resource. - -- Container runtime socket path - - Set the `criSocketPath` field to the path of the container runtime socket. Default: `/run/containerd/containerd.sock` - -- Containerd file system root path - - Set the `containerdVolumeMountPath`. Default: `/var/lib/containerd/`. - -### Configure exclusions for image scanning - -To specify which namespaces should be excluded from future scans, follow the following steps. - -- Modify your [Image Assurance](../../reference/installation/ia-api.mdx#image-assurance.operator.tigera.io/v1.ImageAssuranceSpec) installation resource to include the `exclusions.namespaces` field. List each namespace you want to exclude. - - -```yaml -apiVersion: image-assurance.operator.tigera.io/v1 -kind: ImageAssurance -metadata: - name: default -spec: - clusterScanner: Enabled - exclusions: - namespaces: - - "kube-system" - - "dev-qa" -``` - -In this example, the workloads in the `kube-system` and `dev-qa` namespaces are excluded from future image scans. - -:::note - -Applying or updating namespace exclusions affects only future scans. Results from scans conducted prior to these exclusions will remain unchanged. The exclusions configured will apply to both cluster scanner and runtime view (**Running Images** tab). - -::: - -### Disable scanner - -1. Modify the `imageassurance` installation resource. - -```bash - kubectl edit imageassurance default - ``` - -2. Set the `clusterScanner` field to `Disabled` and save the file. This deletes the cluster scanner container from the daemonset from your cluster. - -## Next step - -[Set up alerts on vulnerabilities ](../set-up-alerts) \ No newline at end of file diff --git a/calico-cloud/image-assurance/scanners/index.mdx b/calico-cloud/image-assurance/scanners/index.mdx deleted file mode 100644 index 936d2eb0dd..0000000000 --- a/calico-cloud/image-assurance/scanners/index.mdx +++ /dev/null @@ -1,20 +0,0 @@ ---- -description: Reference for the Calico Cloud Image Assurance scanners, which detect container image vulnerabilities across build pipelines, registries, and running clusters. -hide_table_of_contents: true ---- - -# Scanners - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - - diff --git a/calico-cloud/image-assurance/scanners/overview.mdx b/calico-cloud/image-assurance/scanners/overview.mdx deleted file mode 100644 index f07cae53c1..0000000000 --- a/calico-cloud/image-assurance/scanners/overview.mdx +++ /dev/null @@ -1,49 +0,0 @@ ---- -description: Compare the Calico Cloud Image Assurance scanner options and pick the right combination of cluster, registry, and pipeline scanning for your environment. ---- - -# Choose an image scanning method - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -## Big picture - -Scan images and Kubernetes workloads for vulnerabilities using $[prodname] Image Assurance. - -## Value - -$[prodname] Image Assurances helps you identify vulnerabilities in container images that you deploy to Kubernetes clusters. Vulnerabilities are known flaws in libraries and packages used by applications that attackers can exploit and cause harm. With Image Assurance you can: - -- Scan an image for vulnerabilities -- Assess the impact of newly-found vulnerabilities and prioritize remediation efforts -- Catch vulnerabilities days or weeks later with continuous image rescanning -- Create exceptions to ignore specific vulnerabilities -- Create alerts on high-severity vulnerabilities so you can delegate remediation efforts to the appropriate team -- Block non-compliant workloads using policy as part of your cloud-native security posture - -## About Image Assurance - -Image Assurance is based on the Common Vulnerabilities and Exposures (CVE) system, which provides a catalog of publicly-known security vulnerabilities and exposures. Known vulnerabilities are identified by a unique CVE ID based on the year it was reported (for example, CVE-2021-44228). - -Scanned image content includes: - -- Libraries and content (for example, python, ruby gems, jars and go) -- Packages (OS and non-OS) -- Image layer - -## Image scanning options - -Image Assurance provides different versions of the scanner to accommodate different use cases as shown in the following table. - -| Scan images in... | Description | Scanner access | Benefits | -| --------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | -| [Kubernetes cluster](./cluster-scanner.mdx) | Scan any running image in the Kubernetes cluster including locally-built first-party images to fix critical bugs. | Runs automatically in the managed cluster in the web console | The Image Assurance dashboard provides an easy way to get started with vulnerability scanning and remediation, and defense-in-depth coverage without building your own scanning solution. | -| [CI/CD pipeline](./pipeline-scanner.mdx) | Integrate the CLI scanner in your application build pipeline and private registries including:
- Customer-built images
- Local images
- Third-party images from public registries (for example Kafka, Redis) | A downloadable binary | Incorporate the scanner as a lightweight runner in your build pipeline. Use the scanner offline and on-demand for ad hoc scanning and emergency patching. | -| [Image registries](./registry-scanner.mdx) | Scan images in registries (for example, Amazon ECR). | A downloadable Docker image | Add a layer of defense for images that were not scanned in your build pipeline, but get published to your registry. | \ No newline at end of file diff --git a/calico-cloud/image-assurance/scanners/pipeline-scanner.mdx b/calico-cloud/image-assurance/scanners/pipeline-scanner.mdx deleted file mode 100644 index ea4071d064..0000000000 --- a/calico-cloud/image-assurance/scanners/pipeline-scanner.mdx +++ /dev/null @@ -1,188 +0,0 @@ ---- -description: Integrate the Calico Cloud Image Assurance CLI scanner into a CI build pipeline to catch container image vulnerabilities before images reach a registry. ---- - -# Integrate the scanner into your build pipeline - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -## Big picture - -Integrate the Image Assurance CLI scanner into your build pipeline to ensure builds are checked by Image Assurance before deployment. - -## Value - -The Image Assurance CLI scanner allows you to manually scan container images locally or remotely for on-demand scanning and emergency scanning. The CLI scanner is ideal for use in a CI/CD pipeline to automatically scan images before pushing them to a registry. - -If the CLI scanner is part of your pipeline, scanning is done before runtime and the results are displayed in the Image Assurance dashboard in the web console. - -## Before you begin - -**Image requirements** - -- Docker container runtime -- Images must be available locally through the Docker container runtime environment where the Image Assurance scanner is running. - -**Scanner requirements** - -- Must have internet access to download and update the vulnerability database -- To see image scan results in the web console, the scanner must communicate with an external API endpoint outside your environment - -## How to - -- [Get the latest version of Image Assurance](#get-the-latest-version-of-image-assurance) -- [Start the scanner](#start-the-scanner) -- [Integrate the scanner in your build pipeline](#integrate-the-scanner-in-your-build-pipeline) -- [Manually scan images](#manually-scan-images) -- [Scan images using a configuration file](#scan-images-using-a-configuration-file) - -### Get the latest version of Image Assurance - -1. On the **Managed Clusters** page, select the cluster from the list, and click **Reinstall**. -1. Copy the updated installation script command and run it against your cluster. - -### Start the scanner - -{/* -If you change the name of above heading, open a ticket to update the hardcoded Candu link in the UI. */} - -1. Download the latest version of the scanner. - - **Linux** - - ```shell - curl -Lo tigera-scanner $[clouddownloadbase]/tigera-scanner/$[cloudversion]/image-assurance-scanner-cli-linux-amd64 - ``` - - **macOS** - - ```shell - curl -Lo tigera-scanner $[clouddownloadbase]/tigera-scanner/$[cloudversion]/image-assurance-scanner-cli-darwin-amd64 - ``` - -2. Set the executable flag on the binary. - - ```shell - chmod +x ./tigera-scanner - ``` - -:::note -You must download and set the executable flag each time you get a new version of the scanner. - -::: - -3. Verify that the scanner works correctly by running the version command. - - ```shell - ./tigera-scanner version - $[imageassuranceversion] - ``` -### Integrate the scanner into your build pipeline - -You can include the CLI scanner in your CI/CD pipelines (for example, Jenkins, GitHub actions). Ensure the following: - -- Download the CLI scanner binary onto your CI runner -- If you are running an ephemeral environment in the pipeline, include the download, and update the executable steps in your pipeline to download the scanner on every execution -- Create a secret containing the API-Token and API URL and make it available in the pipeline (for example, using a SECURE_API_TOKEN environment variable) -- Add a step in your pipeline to run the `image-assurance-scanner` after building the container image, and specify the image name as a parameter. For example: - `./image-assurance-cli-scanner --apiurl ${IMAGE_NAME}` - -If your CI platform supports it, you can also use the containerized version of Image Assurance scanner for integrations with other tools like Harness. To integrate the containerized version of Image Assurance scanner into your CI/CD platform, go to: [Image Assurance containerized scanner](https://quay.io/repository/tigera/image-assurance-scanner-cli) and pull the latest image. For example: - -```bash - docker pull quay.io/tigera/image-assurance-scanner-cli:vx.x.x -``` - -### Manually scan images - -You can scan images and report results back to $[prodname], or scan images locally without reporting results to $[prodname]. - -**Syntax**: - -`tigera-scanner scan [OPTIONS] ` - -**Options**: - -- `--apiurl` - $[prodname] API URL path. You can get this URL in the web console, **Image Assurance**, **Scan settings**. -- `--token` - secure API or authorization token to make requests to $[prodname] API URL. You can get this URL in the web console, **Image Assurance**, **Scan settings**. -- `--warn_threshold` - CVSS threshold for Warn scan results. Range from 0.0 - 10.0. -- `--fail_threshold` - CVSS threshold for Fail scan results. Range from 0.0 - 10.0. -- `--vulnerability_db_path` - path to a folder to store vulnerability data (defaults to `$XDG_CACHE_HOME`; if it is not set, defaults to `$HOME/.cache`). -- `--input_file ` - Path to a JSON file containing image URLs. -- `--output_file ` - File path that will contain scan results in a JSON format. - -**Examples** - -**Scan an image, report results** - -```shell -./tigera-scanner scan ubuntu:latest --apiurl https://.calicocloud.io --token ezBhbGcetc... -``` - -**Scan an image locally, do not report results** - -```shell -./tigera-scanner scan ubuntu:latest -``` - -**Scan an image with a failure and warning threshold** - -```shell -./tigera-scanner scan ubuntu:latest --fail_threshold 7.0 --warn_threshold 3.9 -``` - -**Scan multiple images locally, do not report results** - -```shell -./tigera-scanner scan ubuntu:latest alpine:latest -``` - -**Scan multiple images using an input and output file** - -The input file must have the following JSON structure: - -```json -{ - "images": [ - "ubuntu:latest", - "alpine:latest" - ] -} -``` - -```shell -./tigera-scanner scan --input_file images.json --output_file results.json -``` - -### Scan images using a configuration file - -Create a configuration file in `$HOME/.tigera-scanner.yaml` for the scanner to read. - -:::note - -Key names must match the full name of arguments passed to the scanner. The configuration precedence order is options > environment variables > file configuration. - -::: - -**Options** - -| Options | Shorthand | Environment variable | Description | -| ----------------------- | --------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------- | -| --apiurl | -a | CC_API_URL | $[prodname] API URL path. You can get this URL in the web console, Image Assurance, Scan settings. | -| --token | -t | CC_TOKEN | Secure API or authorization token to make requests to $[prodname] API URL. | -| --warn_threshold | -w | CC_WARN_THRESHOLD | CVSS threshold for Warn scan results. Range from 0.0 - 10.0. | -| --fail_threshold | -f | CC_FAIL_THRESHOLD | CVSS threshold for Fail scan results. Range from 0.0 - 10.0. | -| --vulnerability_db_path | -p | CC_VULNERABILITY_DB_PATH | Path to a folder to store vulnerability data (defaults to `$XDG_CACHE_HOME`; if it is not set, defaults to `$HOME/.cache`). | -| --input_file | -i | CC_INPUT_FILE | Path to the JSON file containing image URLs. | -| --output_file | -o | CC_OUTPUT_FILE | File path that will contain scan results in a JSON format. | - -## Next step - -[Set up alerts](../set-up-alerts) \ No newline at end of file diff --git a/calico-cloud/image-assurance/scanners/registry-scanner.mdx b/calico-cloud/image-assurance/scanners/registry-scanner.mdx deleted file mode 100644 index 78e3d798f9..0000000000 --- a/calico-cloud/image-assurance/scanners/registry-scanner.mdx +++ /dev/null @@ -1,170 +0,0 @@ ---- -description: Run the Calico Cloud Image Assurance registry scanner against container registries to catch CVEs in stored images that never pass through a build pipeline. ---- - -# Scan images in container registries - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -Scan images in container registries at any time, on any infrastructure, including Kubernetes. - -## Value - -Add a layer of defense for images that don’t go through a pipeline (for example, third-party images), but are published to a registry. If CVEs are missed in your build pipeline, you can catch them before they are deployed. - -## Concepts - -You can run the registry scanner wherever there is a container runtime. And it doesn’t have to be for Kubernetes. - -To use registry scanner, all you need to do is: -- Specify the registry paths to the images you want to scan -- Provide permissions for the scanner to access your registries -- Get a token for access to the Image Assurance API - -Based on the paths you specify, the scanner recursively scans all images in the registry once, and sends results to the Image Assurance dashboard in the web console. - -To deploy the registry scanner as a pod in Kubernetes cluster, we recommend that you define a Kubernetes job or cronjob. - -## Before you begin - -**Required** - -- Registry scanner is running where there is a container runtime -- Valid registry credentials - -**Supported registry platforms** - -- Amazon Elastic Container Registry (ECR) -- Azure Container Registry (ACR) -- Google Container Registry (GCR) - -**Limitations** - -- The registry scanner is available as an image (not using Tigera Operator installation) -- You can scan images from only one of the supported registry platforms/account per instance -- If you use the registry scanner with Docker, only tagged images are scanned. However, if you use the scanner with Amazon or Azure, all images (tagged and untagged) are scanned. - -## How to - -- [Download the registry scanner](#download-the-registry-scanner) -- [Set up authentication to registry scanner](#set-up-authentication-to-registry-scanner) -- [Set up registry scanner](#set-up-registry-scanner) -- [Scan images and send results to Calico Cloud](#scan-images-and-send-results-to-calico-cloud) -- [Troubleshoot](#troubleshoot) -- [Get previous registry scanner versions](#get-previous-registry-scanner-versions) - -### Download the registry scanner - -The registry scanner comes in a Docker image. To get the image, run this command: `docker pull quay.io/tigera/image-assurance-registry-scanner:$[imageassuranceversion]`. - -### Set up authentication to registry scanner - -The registry scanner requires authentication to access a registry. Set up credentials for one of the following registry platforms: - -- **Docker/Google** - scans only tagged images; untagged images residing in your image registry are not pulled and scanned. -- **Azure or AWS** - scans tagged and untagged images (all) - -#### Docker/GCR required credentials - -- `DOCKER_USERNAME` -- `DOCKER_PASSWORD` - -If you have a valid /.docker/config.json, you can also mount this config file on the container while running the registry scanner. - -```bash -docker run -e ... -v ~/.docker/config.json:/.docker/config.json quay.io/tigera/image-assurance-registry-scanner:$[imageassuranceversion] -``` -#### Azure required credentials - -Registry instances are scanned one at a time. If Docker credentials are found, they are ignored. - -- `AZURE_CLIENT_ID` -- `AZURE_CLIENT_SECRET` or `AZURE_FEDERATED_TOKEN` -- `AZURE_TENANT_ID` - -#### AWS required credentials - -Registry instances are scanned one at a time. If Docker credentials are found, they are ignored. - -- `AWS_ACCESS_KEY_ID` -- `AWS_SECRET_ACCESS_KEY` -- `AWS_REGION` - -### Set up registry scanner - -**Required** - -- `REGISTRY` - the registry you want to scan. For example, gcr.io. -- `IMAGE_ASSURANCE_API_URL` - Get the URL in the web console -- `IMAGE_ASSURANCE_API_TOKEN` - Get the token in the web console -- Registry credentials: Docker/gcr, acr, or ecr - -**Optional** - -`REGISTRY_FILTER` - limits scanning time when you have thousands of repositories and images. Supports a comma-separated list. - -Example: gcr registry - -```bash -gcr.io/prod-env/api -gcr.io/staging-env/api -gcr.io/dev/api -``` -To filter out images in the dev "sub" registry: - -`-e REGISTRY_FILTER=prod-env,staging-env` - -### Scan images and send results to $[prodname] - -Example: gcr registry with Docker credentials - -```bash -docker run -e REGISTRY=gcr.io -e IMAGE_ASSURANCE_API_URL=https://-management.dev.calicocloud.io/bast -e IMAGE_ASSURANCE_API_TOKEN=$TOKEN -e DOCKER_USERNAME= -e DOCKER_PASSWORD= quay.io/tigera/image-assurance-registry-scanner:$[imageassuranceversion] -``` - -Example: acr registry with Azure credentials - -```bash -docker run -e REGISTRY=your-org.azurecr.io -e IMAGE_ASSURANCE_API_URL=https://-management.dev.calicocloud.io/bast -e IMAGE_ASSURANCE_API_TOKEN=$TOKEN -e AZURE_CLIENT_ID= -e AZURE_CLIENT_SECRET= -e AZURE_TENANT_ID= quay.io/tigera/image-assurance-registry-scanner:$[imageassuranceversion] -``` - -Example: ecr registry with AWS credentials - -```bash -docker run -e REGISTRY=gcr.io -e IMAGE_ASSURANCE_API_URL=https://-management.dev.calicocloud.io/bast -e IMAGE_ASSURANCE_API_TOKEN=$TOKEN -e AWS_ACCESS_KEY_ID= -e AWS_SECRET_ACCESS_KEY= -e AWS_REGION= quay.io/tigera/image-assurance-registry-scanner:$[imageassuranceversion] -``` - -Example: run when mounting the dockerfile - -```bash -docker run -e REGISTRY=gcr.io -e IMAGE_ASSURANCE_API_URL=https://-management.dev.calicocloud.io/bast -e IMAGE_ASSURANCE_API_TOKEN=$TOKEN -v ~/.docker/config.json/:/.docker/config.json quay.io/tigera/image-assurance-registry-scanner:$[imageassuranceversion] -``` - -### Troubleshoot - -**Issues authenticating with registry scanner** - -Verify that the registry credentials are correct. - -**Scan results are not uploading to $[prodname]** - -Image scan results that are uploaded to $[prodname] through the registry scanner require additional processing before appearing in the Image Assurance dashboard. This may result in a time delay before CVE results appear for those images in the UI. You can also verify that the API token and URL are correct. - -**Scanned images do not match what I expect** - -Verify that the credentials on the registry side have the correct permission level. - -### Get previous registry scanner versions - -For previous versions of registry scanner, see [quay repository](https://quay.io/organization/tigera). - -## Next step - -- [Understand scan results in the web console](../understanding-scan-results) \ No newline at end of file diff --git a/calico-cloud/image-assurance/set-up-alerts.mdx b/calico-cloud/image-assurance/set-up-alerts.mdx deleted file mode 100644 index 3c3b60369b..0000000000 --- a/calico-cloud/image-assurance/set-up-alerts.mdx +++ /dev/null @@ -1,97 +0,0 @@ ---- -description: Configure Calico Cloud Image Assurance alerts on high-severity vulnerabilities so security teams are notified and can route remediation to the right owners. ---- - -# Set up alerts on vulnerabilities - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -## Big picture - -Create alerts on high-severity vulnerabilities so you can delegate remediation efforts to the appropriate team. - -## How to - -To create alerts, use the [Global alert resource](../reference/resources/globalalert.mdx). - -### Example 1 - Alert on a failed image - -In this example, an alert is created whenever there is more than one event for an image from the specified registry/repo that has a result value of Fail within the past 30 minutes. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalAlert -metadata: - name: example-1 -spec: - summary: 'Vulnerabilities for a specific repo based on results' - description: 'Vulnerabilities for a specific repo based on results' - severity: 100 - period: 30m - lookback: 30m - dataSet: vulnerability - query: registry="quay.io/tigera" AND repository="node" AND result="Fail" - metric: count - condition: gt - threshold: 1 -``` - -### Example 2 - Alert on a specific repo with maximum CVSS greater than 7.0 - -In this example, an alert is created whenever there is at least one event for an image from the specified registry/ repo that has a max CVSS score greater than 7.0 within the past 30 minutes. Providing control over the exact max CVSS score threshold lets you define a trigger that is different from what the CVSS score threshold is configured for Fail scan result on the Scan Results page in the web console. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalAlert -metadata: - name: example-2 -spec: - summary: 'Vulnerabilities for a specific repo based on max CVSS score' - description: 'Vulnerabilities for a specific repo based on max CVSS score' - severity: 100 - period: 30m - lookback: 30m - dataSet: vulnerability - query: registry="quay.io/tigera" AND repository="node" - field: max_cvss_score - metric: max - condition: gt - threshold: 7.0 -``` - -### Example 3 - Alert on a failed scan result within a pod in a namespace - -In this example, an alert is created whenever there is at least one event for an image that has a scan result of Fail, that is running within a pod in any cluster in the namespace `tigera-elasticsearch`, within the past 30 minutes. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalAlert -metadata: - name: example-3 -spec: - summary: 'Vulnerabilities for namespace tigera-elasticsearch' - description: 'Vulnerabilities for namespace tigera-elasticsearch' - severity: 100 - period: 30m - lookback: 30m - dataSet: vulnerability - query: result="Fail" AND namespace="tigera-elasticsearch" - metric: count - condition: gt - threshold: 1 -``` - -:::note - -You must apply global alerts across all applicable managed clusters. For example, if you have five clusters, you must apply the alerts five times. - -::: - -For a complete list of parameters, see [Global alert resource](../reference/resources/globalalert.mdx). diff --git a/calico-cloud/image-assurance/understanding-scan-results.mdx b/calico-cloud/image-assurance/understanding-scan-results.mdx deleted file mode 100644 index ea1a7b1709..0000000000 --- a/calico-cloud/image-assurance/understanding-scan-results.mdx +++ /dev/null @@ -1,105 +0,0 @@ ---- -description: Interpret scanned and running image results in the Calico Cloud Image Assurance dashboard, including filters, dismissals, and per-image vulnerability detail. ---- - -# View scanned and running images - -:::warning[deprecation and removal notice] - -This feature was deprecated in Calico Cloud version 21.1.0 and will be removed in a future release. Availability depends on when you started using Calico Cloud. - -- For users who started using Calico Cloud in April 2025 or later, this feature is not available. -- Legacy users, who started using Calico Cloud before April 2025, can continue to use this feature until it is removed in a future release. - -::: - -The Images Assurance board in the web console provides lists for scanned images and running images. - -In the left navbar in the web console, click **Image Assurance**, **All Scanned Images**. - -## All Scanned Images tab - -This tab lists scanned images if you have enabled or used one of the [Image Assurance scanners](./scanners/overview). -To manage your scan results, you can filter, dismiss, or delete them: -* **Filter:** Apply different combinations of filters to refine your results, making it easier to focus on relevant vulnerabilities for remediation. -* **Dismiss:** Hide specific results from the scan results list. You can view a list of dismissed scan results by using the **Dismissed** filter. -* **Delete:** Permanently remove specific results from the scan results list. - -## Running Images tab - -The tab lists active container images *for all connected managed clusters*. It provides the CVEs associated with running pods to help you assess pod vulnerability. This tab is disabled by default. - -To enable Running Images, click the **Setting** icon in the top right corner, then select **Enable Runtime View**. - -:::note - -If you are using the CLI scanner and your cluster does not use the default containerd socket path (`/run/containerd/containerd.sock`), you must change the path to allow the Running Images service to collect image information. To update the CRI socket path for a cluster, run the following command: - -```bash -kubectl patch imageassurance default --type='merge' -p '{"spec":{"criSocketPath":""}}' -``` -For details, see the [Image Assurance installation reference](../reference/installation/ia-api.mdx#image-assurance.operator.tigera.io/v1.ImageAssuranceSpec). - -::: - -Other notes: - -- The columns, **Clusters** and **Running Instances**, show the number of running instances in clusters that are connected to $[prodname]. -- The **Unknown** scan result filter reflects images that are not fully scanned. Because they can add noise to the table, they are disabled by default. To enable Unknown results for strategic troubleshooting, click the **Result** drop-down menu and select **Unknown**. -- In the All Scanned Images and Running Images tabs, the **Registry path** field may be blank if $[prodname] cannot access this metadata. For example, images from Docker Hub do not specify the registry in the image metadata. -- Any exceptions configured for image scanning will be applicable to Runtime View as well. - -## Image assessment: Pass, Warn, and Fail - -The Image Assurance image assessment is based on the [Common Vulnerability Scoring System v3 (CVSS Scores)](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator). The following table shows how Image Assurance scores map to CVSS scores. - -| CVSS v3 scores | Image Assurance mapping | Default settings | -| ------------------------------------------- | ----------------------- | -------------------- | -| 0.0 – (None)
0.1 – 3.9 (Low) | Pass = 3.9 | Low | -| 4.0 – 6.9 (Medium) | Warn = 7 | Medium severity – 7 | -| 7.0 – 8.9 (High)
9.0 – 10.0 (Critical) | Fail = 8.0 | Critical or high – 8 | - -CVEs without a CVSS v3 score (too old to have one, or are too new to be assigned one), display a blank score in the UI, and **N/A** in the CLI. - -### Changing the default CVSS threshold values - -The following default threshold values will work for the majority of $[prodname] deployments. However, you may need to change the defaults because of security requirements. - -![scan-settings](/img/calico-cloud/scan-settings.png) - -To change the CVSS threshold values, note the following: - -- Changes to threshold values take effect immediately and alter the scan results for images already in the system -- If you are using admission controller policies, changing a value may allow pods in your Kubernetes cluster that were previously being blocked, to now be deployed or vice versa. - -## Exploit Data - -The scanning process also attaches EPSS and known exploit data onto each image and vulnerability viewable through the UI. - -An EPSS score of 0.1 - or 10% - means a vulnerability has a 10% probability that it will be exploited in the wild within the next 30 days. -Users should use this information alongside CVSS scores to prioritize remediating vulnerabilities. For example, you may not have the time to remediate -all critical vulnerabilities, but you can use the EPSS score to help prioritize. By additionally filtering with an EPSS score of > 90% you can target -the critical vulnerabilities that are most likely to be exploited. - -Note that an EPSS score of > 10% can be considered a high number. -Information about [The EPSS Model](https://www.first.org/epss/model) can be found on the EPSS website created by [FIRST](https://www.first.org/). - -Known exploits are based off of the [CISA KEV Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog), a list of -vulnerabilities that have been exploited in the wild and maintained by CISA. - -## Export results - -From each tab, you can export data or a JSON file with image URLs. Exporting data is based on the images in the list and the current filter selections. CSV table options include: - -- **Export one row per image** - export one row for each image with all associated CVEs condensed into a single column. -- **Export one row for each image and CVE ID** - export a unique image plus CVE combination for each row. For example, if an image has 10 CVEs, 10 rows are created (1 for each CVE). - -:::note - -Images without associated CVEs are not included in the exported data (regardless if they are included by filters). - -::: - -## Next steps - -- [Set up alerts on vulnerabilities](set-up-alerts.mdx) \ No newline at end of file diff --git a/calico-cloud/network-policy/application-layer-policies/alp.mdx b/calico-cloud/network-policy/application-layer-policies/alp.mdx index 246a831698..6955c3d05c 100644 --- a/calico-cloud/network-policy/application-layer-policies/alp.mdx +++ b/calico-cloud/network-policy/application-layer-policies/alp.mdx @@ -25,7 +25,6 @@ Application layer policies let you configure access controls based on L7 attribu * Application layer policies apply to the entire cluster. They can not be namespaced. * Logs for application layer polices are not included with other L7 logs in Service Graph. - To view logs for application layer policies, you must [view them in Kibana](../../observability/elastic/l7/configure.mdx#kibana). * Application layer policy is supported only on Kubernetes 1.29 and later. :::important diff --git a/calico-cloud/network-policy/networksets.mdx b/calico-cloud/network-policy/networksets.mdx index 130f89ee8a..d6378a9dbd 100644 --- a/calico-cloud/network-policy/networksets.mdx +++ b/calico-cloud/network-policy/networksets.mdx @@ -34,7 +34,7 @@ Here are just a few examples of how network sets can be used: - **Troubleshooting** - Network sets appear as additional metadata in flow logs and Kibana, Flow Visualizer, and Service Graph. + Network sets appear as additional metadata in flow logs, Flow Visualizer, and Service Graph. - **Efficiency and scaling** @@ -119,7 +119,7 @@ If we double-click `hipstershop` to drill down, we now see the `google` network ![google-networkset](/img/calico-enterprise/google-networkset.png) -Service Graph provides a view into how services are interconnected in a consumable view, along with easy access to flow logs. However, you can also see traffic associated with network sets in volumetric display with Flow Visualizer, and query flow log data associated with network sets in Kibana. +Service Graph provides a view into how services are interconnected in a consumable view, along with easy access to flow logs. You can also see traffic associated with network sets in volumetric display with Flow Visualizer. ## Tutorial @@ -223,7 +223,7 @@ spec: - Create a network set label and name schema - It is helpful to think: what names would be meaningful and easy to understand when you look in Service Graph? Flow Viz? Kibana? What labels will be easy to understand when used in network policies – especially if you are separating users who manage network sets from those who consume them in network policies. + It is helpful to think: what names would be meaningful and easy to understand when you look in Service Graph or Flow Visualizer? What labels will be easy to understand when used in network policies – especially if you are separating users who manage network sets from those who consume them in network policies. - Do not put large sets of CIDRs and domains directly in policy diff --git a/calico-cloud/observability/alerts.mdx b/calico-cloud/observability/alerts.mdx index 836ffac187..bb5363863c 100644 --- a/calico-cloud/observability/alerts.mdx +++ b/calico-cloud/observability/alerts.mdx @@ -39,7 +39,7 @@ To turn down aggregation on flow logs, go to [FelixConfiguration](../reference/r ### Manage alerts in the web console -You can view alert events in the web console in several places: the **Alerts** page, **Service Graph**, and the **Kibana** dashboard. +You can view alert events in the web console in several places: the **Alerts** page and **Service Graph**. Click **Activity**, **Alerts** to follow along. diff --git a/calico-cloud/observability/elastic/audit-overview.mdx b/calico-cloud/observability/elastic/audit-overview.mdx index b437b63c72..b18bee9c28 100644 --- a/calico-cloud/observability/elastic/audit-overview.mdx +++ b/calico-cloud/observability/elastic/audit-overview.mdx @@ -30,11 +30,7 @@ $[prodname] audit logs are displayed in the Timeline dashboard in the web consol ![audit-logs](/img/calico-enterprise/audit-logs.png) -Audit logs are also visible in the Kibana dashboard (indexed by, `tigera_secure_ee_audit_ee`), and are useful for looking at policy differences. - -![kibana-auditlogs](/img/calico-enterprise/kibana-auditlogs.png) - -Finally, audit logs provide the core data for compliance reports. +Audit logs provide the core data for compliance reports. ![compliance-reports](/img/calico-enterprise/configuration-compliance.png) diff --git a/calico-cloud/observability/elastic/flow/processpath.mdx b/calico-cloud/observability/elastic/flow/processpath.mdx index 0e648b0d34..8d0f9291d0 100644 --- a/calico-cloud/observability/elastic/flow/processpath.mdx +++ b/calico-cloud/observability/elastic/flow/processpath.mdx @@ -44,10 +44,6 @@ using the command: Enabling/Disabling collectProcessPath causes a rolling update of the `$[noderunning] DaemonSet`. -### View process path and arguments in flow logs using Kibana - -Navigate to the Kibana Flow logs dashboard to view process path and arguments associated with a flow log entry. - -The executable path will appear in the `process_name` field and `process_args` will have the executable arguments. Executable path +The executable path appears in the `process_name` field and `process_args` will have the executable arguments. Executable path and arguments cannot be collected under certain circumstances, in that `process_name` will have the task name and `process_args` -will be empty. Information about these fields are described in the [Flow log datatype document](datatypes.mdx) +will be empty. Information about these fields is described in the [Flow log datatype document](datatypes.mdx). diff --git a/calico-cloud/observability/elastic/flow/tcpstats.mdx b/calico-cloud/observability/elastic/flow/tcpstats.mdx index 1060875632..330754463b 100644 --- a/calico-cloud/observability/elastic/flow/tcpstats.mdx +++ b/calico-cloud/observability/elastic/flow/tcpstats.mdx @@ -34,10 +34,6 @@ using the command: kubectl patch felixconfiguration default -p '{"spec":{"flowLogsCollectTcpStats":true}}' ``` -### View tcp stats in flow logs using Kibana. - -Navigate to the Kibana Flow logs dashboard to view tcp stats associated with a flow log entry. - The additional fields collected are `tcp_mean_send_congestion_window`, `tcp_min_send_congestion_window`, `tcp_mean_smooth_rtt`, `tcp_max_smooth_rtt`, `tcp_mean_min_rtt`, `tcp_max_min_rtt`, `tcp_mean_mss`, `tcp_min_mss`, `tcp_total_retransmissions`, `tcp_lost_packets`, `tcp_unrecovered_to`. -Information about these fields are described in the [Flow log datatype document](datatypes.mdx) +Information about these fields is described in the [Flow log datatype document](datatypes.mdx). diff --git a/calico-cloud/observability/elastic/index.mdx b/calico-cloud/observability/elastic/index.mdx index c29eb2e2d8..23350448f2 100644 --- a/calico-cloud/observability/elastic/index.mdx +++ b/calico-cloud/observability/elastic/index.mdx @@ -1,5 +1,5 @@ --- -description: Configure managed Elasticsearch logs for Calico Cloud so the web console and Kibana can surface flow, DNS, audit, and L7 data from connected clusters. +description: Configure managed Elasticsearch logs for Calico Cloud to surface flow, DNS, audit, and L7 data from connected clusters in the web console. hide_table_of_contents: true --- diff --git a/calico-cloud/observability/elastic/l7/configure.mdx b/calico-cloud/observability/elastic/l7/configure.mdx index 419776be27..39a5620c40 100644 --- a/calico-cloud/observability/elastic/l7/configure.mdx +++ b/calico-cloud/observability/elastic/l7/configure.mdx @@ -165,12 +165,3 @@ To view L7 logs in Service Graph: ![l7-logs](/img/calico-enterprise/l7-logs.png) -### Kibana - -To view L7 logs by index pattern in Kibana: - -1. In the web console left navbar, click **Kibana**. - -1. In the new Kibana browser, click the hamburger icon in the top left corner, and select **Analytics**, **Discover**. - -1. Select the index pattern, `tigera_secure_ee_l7`. diff --git a/calico-cloud/observability/elastic/overview.mdx b/calico-cloud/observability/elastic/overview.mdx index be619f8199..3d7812b309 100644 --- a/calico-cloud/observability/elastic/overview.mdx +++ b/calico-cloud/observability/elastic/overview.mdx @@ -1,5 +1,5 @@ --- -description: Calico Cloud uses managed Elasticsearch and Kibana for flow, DNS, audit, BGP, and L7 logs with workload context, RBAC, and archival to external SIEMs. +description: Calico Cloud uses managed Elasticsearch for flow, DNS, audit, BGP, and L7 logs with workload context, RBAC, and archival to external SIEMs. --- # Overview @@ -10,11 +10,11 @@ Use $[prodname] log data for visibility and troubleshooting Kubernetes clusters. ## Value -Workloads and policies are highly dynamic. To troubleshoot Kubernetes clusters, you need logs with workload identity and context. $[prodname] deploys an Elasticsearch cluster and Kibana instance during installation with these features: +Workloads and policies are highly dynamic. To troubleshoot Kubernetes clusters, you need logs with workload identity and context. $[prodname] deploys an Elasticsearch cluster during installation with these features: - Logs with workload context - Centralized log collection for multiple clusters for $[prodname] multi-cluster-management -- View Elasticsearch logs in the $[prodname] web console (Kibana dashboard and Flow Visualizer), and the [Elasticsearch API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search.html) +- View Elasticsearch logs in the $[prodname] web console (Flow Visualizer), and the [Elasticsearch API](https://www.elastic.co/guide/en/elasticsearch/reference/current/search.html) - Standard Kubernetes RBAC for granular access control to logs - Collect/archive logs or subset of logs - Log aggregation for high-volume logs @@ -47,7 +47,7 @@ Because of their high-volume, flow and dns logs support aggregation. $[prodname] automatically installs fluentd on all nodes and collects flow, audit, and DNS logs. You can configure additional destinations like Amazon S3, Syslog, Splunk. -$[prodname] enables user authentication in Elasticsearch, and secures access to Elasticsearch and Kibana instances using network policy. +$[prodname] enables user authentication in Elasticsearch, and secures access to Elasticsearch using network policy. ### RBAC and log access diff --git a/calico-cloud/observability/index.mdx b/calico-cloud/observability/index.mdx index f3b8ce1230..45f021c1f1 100644 --- a/calico-cloud/observability/index.mdx +++ b/calico-cloud/observability/index.mdx @@ -13,7 +13,6 @@ See what's going on in your cluster with network observability tools and detaile - diff --git a/calico-cloud/observability/kibana.mdx b/calico-cloud/observability/kibana.mdx deleted file mode 100644 index 956686c439..0000000000 --- a/calico-cloud/observability/kibana.mdx +++ /dev/null @@ -1,125 +0,0 @@ ---- -description: Use Kibana with Calico Cloud Elasticsearch to explore flow, L7, audit, BGP, DNS, and intrusion detection event logs from connected clusters. ---- - -# Kibana dashboards and logs - -:::warning[deprecation and removal notice] - -Kibana dashboards are deprecated and will be removed in an upcoming release. -During the deprecation period, you will have read-only access to Kibana dashboards. -You can still [create custom dashboards](create-custom-dashboard.mdx) using Calico Cloud's built-in dashboards. - -::: - -## Kibana - -Kibana is the frontend for $[prodname] Elasticsearch, which is the logging infrastructure that centrally stores logs from all managed clusters. Kibana provides an interface to explore Elasticsearch logs and gain insights into workload communication traffic volume, performance, and other key aspects of cluster operations. Log data is also summarized in custom dashboards. - -The following logs are generated by $[prodname]. All logs are enabled by default except **l7 logs**, which must be explicitly enabled. - -| Log type | **Description** | Index in Kibana | -| -------- | ---------------------------------------------------------------------------------------------------- | ------------------------- | -| flow | Layer 3/4 network flows for workloads: source and destination namespaces, pods, labels, and policies | tigera_secure_ee_flows\* | -| l7 | Layer 7 network flows for workloads | tigera_secure_ee_l7\* | -| audit | Audit logs for $[prodname] resources | tigera_secure_ee_audit\* | -| bgp | $[prodname] networking BGP peering and route propagation. | tigera_secure_ee_bgp.\* | -| dns | DNS lookups and responses from $[prodname] domain-based policy. | tigera_secure_ee_dns\* | -| events | $[prodname] intrusion detection events: suspicious IPs, suspicious domains, and global alerts | tigera_secure_ee_events\* | - -## Start Kibana and access dashboards - -In the web console, from the left navbar select, **Kibana**. A new browser tab opens into Kibana. - -In Kibana, click the hamburger icon in the top left corner, and select **Analytics**, **Dashboard**. - -![kibana-dashboard](/img/calico-enterprise/kibana-dashboard.png) - -A list of curated dashboards is displayed. Note that some log types do not have a default dashboard (`bgp` and `events`). - -### DNS dashboard - -![dns-dashboard](/img/calico-enterprise/dns-dashboard.png) - -The DNS dashboard summarizes DNS data and logs into metrics, providing high-level information on the types of DNS lookups made, responses, and overall DNS performance. By default, DNS activity logs are captured only for requests/responses from Kubernetes built-in DNS services (CoreDNS). DNS activity to an external DNS server can be captured by configuring the parameter, `dnsTrustedServers` in [Felix](../reference/resources/felixconfig.mdx). DNS activity to Node local server is not supported. - -The dashboard provides the following metrics/data, which can be edited as required. - -| Metric/data | Description | -| ------------------------------- | ------------------------------------------------------------------- | -| DNS total requests | Cumulative DNS requests over the reporting period. Default: 24hrs. | -| DNS requests | Type of DNS request. | -| DNS responses | DNS response codes which may indicate issues with specific lookups. | -| DNS Top 10 external domains | Count of top domains in lookups. | -| DNS internal query | Lookups within the Kubernetes cluster. | -| DNS external query | Lookups to non-cluster domains. | -| DNS Latency | Measured latency which can indicate DNS issues. | -| DNS internal queries by service | Top types of requests within the cluster per service. | -| DNS external queries by service | Top types of requests external to the cluster per service. | -| DNS response code by service | Top DNS response codes per client. | -| DNS query count by server | Volume of DNS traffic per DNS server. | -| DNS transfer by service | Volume of DNS traffic per service. | -| DNS logs | Raw DNS logs. | - -### L7 HTTP dashboard - -![l7-dashboard](/img/calico-enterprise/l7-dashboard.png) - -The L7 HTTP dashboard provides application performance metrics for in-scope Kubernetes services. The data can assist service owners and platform personnel in assessing the health of cluster workloads without the need for a full service mesh. [L7 logs](elastic/l7/configure.mdx) are not enabled by default, and must be configured. - -The default metrics are: - -- L7 HTTP requests -- L7 all services -- L7 HTTP duration -- L7 HTTP methods -- L7 HTTP response codes -- L7 HTTP request duration -- L7 HTTP requests over time -- L7 HTTP method by service -- L7 HTTP response by service -- L7 HTTP bytes transferred -- L7 Top URLs -- L7-search (raw HTTP logs) - -### Tigera Secure EE audit logs dashboard - -![audit-logs-dashboard](/img/calico-enterprise/audit-logs-dashboard.png) - -The Tigera Secure EE audit logs dashboard provides historical events of changes made to your deployment. These events can be used to understand updates to resources, privileged access and actions, and can also help demonstrate compliance for different regulatory concerns. - -Audit logs listed in the section, `audit-search` can be expanded by clicking on the triangular expand icon, which presents the log in Table format by default. Clicking on JSON in the Expanded document displays the same log in JSON format. The logs can be filtered in the Audit Filtering Controls. - -### Tigera Secure EE flow logs dashboard - -![flow-logs-dashboard](/img/calico-enterprise/flow-logs-dashboard.png) - -The Tigera Secure EE flow Logs dashboard lets you analyze flow logs using the filter options in the Flow Filtering window. The flow logs matching the applied filter are displayed below in the flow logs window. To review a specific flow log in detail, click the triangular expand icon to the left of the flow. - -The full flow log is now displayed in Tabular format by default. To view the log in JSON format click the JSON header. - -![flow-logs-dashboard](/img/calico-enterprise/flow-logs-json.png) - -### Tigera Secure EE Tor-VPN logs - -![tor-vpn-dashboard](/img/calico-enterprise/tor-vpn-dashboard.png) - -Tor and VPN-based traffic indicate the use of anonymization techniques in an attempt to mask the origins and destination of network traffic. $[prodname] has built-in capabilities to assist with detecting such traffic and requires minimal [configuration](../threat/tor-vpn-feed-and-dashboard.mdx) to activate. - -Once enabled, the Tigera Secure EE Tor-VPN logs dashboard can provide a view into any traffic to/from Tor and VPN gateways. The information quickly provides InfoSec teams and operators a focused view on anonymization-based traffic patterns. The reported flows can be filtered in the Tor-VPN controls window and the flow logs for in-scope traffic can be reviewed in the Tor-VPN-search window. - -## Create custom filters and queries - -Each dashboard has advanced filtering options if pre-built dashboards are insufficient. For example: - -- To build a query from all fields available in the logs, click **Add Filter** - -- To create a manual query, click **Search** (next to the disk icon on the left). The following example shows a query `process_name :*curl*` for the `process_name field` matching glob pattern, _curl_. Only logs where `field process_name` contains the string `curl` are filtered. - -![custom-search](/img/calico-enterprise/custom-search.png) - -## View logs by indices - -To view logs by indices, click the hamburger menu, select **Analytics**, and click **Discover**. - -![all-flow-logs](/img/calico-enterprise/all-flow-logs.png) diff --git a/calico-cloud/observability/kube-audit.mdx b/calico-cloud/observability/kube-audit.mdx index 0c46e65921..87ee4998fb 100644 --- a/calico-cloud/observability/kube-audit.mdx +++ b/calico-cloud/observability/kube-audit.mdx @@ -27,7 +27,7 @@ You must enable the following Kubernetes resources for each cluster: ### Audit logs in the web console -Like $[prodname] audit logs, Kubernetes audit logs are displayed in the web console in the Timeline dashboard, Kibana dashboard (indexed by, `tigera_secure_ee_audit_kube`), and provide the core data for compliance reports. +Like $[prodname] audit logs, Kubernetes audit logs are displayed in the web console in the Timeline dashboard, and provide the core data for compliance reports. ## Before you begin diff --git a/calico-cloud/operations/cluster-management.mdx b/calico-cloud/operations/cluster-management.mdx index 97548f1558..f85dc243b7 100644 --- a/calico-cloud/operations/cluster-management.mdx +++ b/calico-cloud/operations/cluster-management.mdx @@ -44,7 +44,7 @@ Use this menu to move between your clusters. You can connect as many managed clu ### Managed cluster views When you select a different cluster from the cluster menu, the entire web console view changes to reflect the selected cluster. -For example, each managed cluster has unique indexes for Elasticsearch clusters, a separate instance of Kibana, and the dashboard reflects only the selected managed cluster. +For example, each managed cluster has unique indexes for Elasticsearch clusters, and the dashboard reflects only the selected managed cluster. ### Manage policies in multiple clusters diff --git a/calico-cloud/reference/index.mdx b/calico-cloud/reference/index.mdx index 973c1bc0ce..96baeba785 100644 --- a/calico-cloud/reference/index.mdx +++ b/calico-cloud/reference/index.mdx @@ -13,7 +13,6 @@ APIs, CLI, architecture and design, and FAQ. - @@ -27,7 +26,6 @@ APIs, CLI, architecture and design, and FAQ. - @@ -53,7 +51,6 @@ APIs, CLI, architecture and design, and FAQ. - diff --git a/calico-cloud/reference/installation/_ia-api.mdx b/calico-cloud/reference/installation/_ia-api.mdx deleted file mode 100644 index 636d940eb4..0000000000 --- a/calico-cloud/reference/installation/_ia-api.mdx +++ /dev/null @@ -1,719 +0,0 @@ -

-Packages: -

- -

image-assurance.operator.tigera.io/v1

-
-

-API Schema definitions for configuring the installation of Image Assurance -

-
-Resource Types: -
    -

    ClusterScannerStatusType(string alias)

    -

    - -(Appears on: -ImageAssuranceSpec) - -

    -

    CrawdadDaemonSet

    -

    - -(Appears on: -ImageAssuranceSpec) - -

    - - - - - - - - - - - - - - - - - -
    FieldDescription
    - -metadata
    - -github.com/tigera/operator/api/v1.Metadata - - -    		 - -(Optional) -

    -Metadata is a subset of a Kubernetes object’s metadata that is added to the DaemonSet. -

    - -
    - -spec
    - - -CrawdadDaemonSetSpec - - - -    		 - -(Optional) -

    -Spec is the specification of the crawdad DaemonSet. -

    -
    -
    - -
    - -
    -

    CrawdadDaemonSetContainer

    -

    - -(Appears on: -CrawdadDaemonSetPodSpec) - -

    -

    -CrawdadDaemonSetContainer is a crawdad DaemonSet container. -

    - - - - - - - - - - - - - - - - - -
    FieldDescription
    - -name
    - -string - - -    		 - -

    -Name is an enum which identifies the crawdad DaemonSet container by name. -

    - -
    - -resources
    - - -Kubernetes core/v1.ResourceRequirements - - - -    		 - -(Optional) -

    -Resources allows customization of limits and requests for compute resources such as cpu and memory. -If specified, this overrides the named crawdad DaemonSet container’s resources. -If omitted, the crawdad DaemonSet will use its default value for this container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. -

    - -
    -

    CrawdadDaemonSetPodSpec

    -

    - -(Appears on: -CrawdadDaemonSetPodTemplateSpec) - -

    -

    -CrawdadDaemonSetPodSpec is the crawdad DaemonSet’s PodSpec. -

    - - - - - - - - - - - - - - - - - - - - - - - - - -
    FieldDescription
    - -containers
    - - -[]CrawdadDaemonSetContainer - - - -    		 - -(Optional) -

    -Containers is a list of crawdad containers. -If specified, this overrides the specified crawdad DaemonSet cluster-scanner containers. -If omitted, the crawdad DaemonSet will use its default values for its containers. -

    - -
    - -affinity
    - - -Kubernetes core/v1.Affinity - - - -    		 - -(Optional) -

    -Affinity is a group of affinity scheduling rules for the crawdad pods. -If specified, this overrides any affinity that may be set on the crawdad DaemonSet. -If omitted, the crawdad DaemonSet will use its default value for affinity. -WARNING: Please note that this field will override the default crawdad DaemonSet affinity. -

    - -
    - -nodeSelector
    - -map[string]string - - -    		 - -

    -NodeSelector is the crawdad pod’s scheduling constraints. -If specified, each of the key/value pairs are added to the crawdad DaemonSet nodeSelector provided -the key does not already exist in the object’s nodeSelector. -If used in conjunction with ControlPlaneNodeSelector, that nodeSelector is set on the crawdad DaemonSet -and each of this field’s key/value pairs are added to the crawdad DaemonSet nodeSelector provided -the key does not already exist in the object’s nodeSelector. -If omitted, the crawdad DaemonSet will use its default value for nodeSelector. -WARNING: Please note that this field will modify the default crawdad DaemonSet nodeSelector. -

    - -
    - -tolerations
    - - -[]Kubernetes core/v1.Toleration - - - -    		 - -(Optional) -

    -Tolerations is the crawdad pod’s tolerations. -If specified, this overrides any tolerations that may be set on the crawdad DaemonSet. -If omitted, the crawdad DaemonSet will use its default value for tolerations. -WARNING: Please note that this field will override the default crawdad DaemonSet tolerations. -

    - -
    -

    CrawdadDaemonSetPodTemplateSpec

    -

    - -(Appears on: -CrawdadDaemonSetSpec) - -

    -

    -CrawdadDaemonSetPodTemplateSpec is the crawdad DaemonSet’s PodTemplateSpec -

    - - - - - - - - - - - - - - - - - -
    FieldDescription
    - -metadata
    - -github.com/tigera/operator/api/v1.Metadata - - -    		 - -(Optional) -

    -Metadata is a subset of a Kubernetes object’s metadata that is added to -the pod’s metadata. -

    - -
    - -spec
    - - -CrawdadDaemonSetPodSpec - - - -    		 - -(Optional) -

    -Spec is the crawdad DaemonSet’s PodSpec. -

    -
    -
    - -
    - -
    -

    CrawdadDaemonSetSpec

    -

    - -(Appears on: -CrawdadDaemonSet) - -

    -

    -CrawdadDaemonSetSpec defines configuration for the crawdad DaemonSet. -

    - - - - - - - - - - - - - - - - - -
    FieldDescription
    - -minReadySeconds
    - -int32 - - -    		 - -(Optional) -

    -MinReadySeconds is the minimum number of seconds for which a newly created DaemonSet pod should -be ready without any of its container crashing, for it to be considered available. -If specified, this overrides any minReadySeconds value that may be set on the crawdad DaemonSet. -If omitted, the crawdad DaemonSet will use its default value for minReadySeconds. -

    - -
    - -template
    - - -CrawdadDaemonSetPodTemplateSpec - - - -    		 - -(Optional) -

    -Template describes the crawdad DaemonSet pod that will be created. -

    - -
    -

    ExcludedNamespace(string alias)

    -

    - -(Appears on: -Exclusions) - -

    -

    -ExcludedNamespace is a namespace name to be excluded from image scanning. -

    -

    Exclusions

    -

    - -(Appears on: -ImageAssuranceSpec) - -

    -

    -Exclusions specifies the criteria for what to exclude from image scanning. -

    - - - - - - - - - - - - - -
    FieldDescription
    - -namespaces
    - - -[]ExcludedNamespace - - - -    		 - -(Optional) -

    -Namespaces is an array of namespace names to be excluded from image scanning. -

    - -
    -

    ImageAssurance

    -

    -ImageAssurance is the Schema for the imageassurances API -

    - - - - - - - - - - - - - - - - - - - - - -
    FieldDescription
    - -metadata
    - - -Kubernetes meta/v1.ObjectMeta - - - -    		 - -Refer to the Kubernetes API documentation for the fields of the -metadata field. - -
    - -spec
    - - -ImageAssuranceSpec - - - -    		 - -
    -
    - - - - - - - - - - - - - - - - - - - - - -
    -criSocketPath
    - -string - - -    		 - -

    -CRISocketPath is the path to the CRI socket on the nodes. Defaults to /run/containerd/containerd.sock. -

    - -
    - -containerdVolumeMountPath
    - -string - - -    		 - -(Optional) -

    -ContainerdVolumeMountPath is the path to the root of containerd file system. Defaults to /var/lib/containerd/. -

    - -
    - -clusterScanner
    - - -ClusterScannerStatusType - - - -    		 - -(Optional) -

    -This setting enables or disables the cluster scanner. -Allowed values are Enabled or Disabled. Defaults to Disabled. -

    - -
    - -crawdadDaemonset
    - - -CrawdadDaemonSet - - - -    		 - -(Optional) -

    -CrawdadDaemonSet is the specification of the Crawdad Daemonset. -

    - -
    - -exclusions
    - - -Exclusions - - - -    		 - -(Optional) -

    -Exclusions define the exclusion criteria for image scanning. -Note: Exclusions are applied to future scans and do not affect past scan results. -

    - -
    -
    - -status
    - - -ImageAssuranceStatus - - - -    		 - - -
    -

    ImageAssuranceSpec

    -

    - -(Appears on: -ImageAssurance) - -

    -

    -ImageAssuranceSpec configures Image Assurance monitoring and tooling in a kubernetes cluster. -

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    FieldDescription
    - -criSocketPath
    - -string - - -    		 - -

    -CRISocketPath is the path to the CRI socket on the nodes. Defaults to /run/containerd/containerd.sock. -

    - -
    - -containerdVolumeMountPath
    - -string - - -    		 - -(Optional) -

    -ContainerdVolumeMountPath is the path to the root of containerd file system. Defaults to /var/lib/containerd/. -

    - -
    - -clusterScanner
    - - -ClusterScannerStatusType - - - -    		 - -(Optional) -

    -This setting enables or disables the cluster scanner. -Allowed values are Enabled or Disabled. Defaults to Disabled. -

    - -
    - -crawdadDaemonset
    - - -CrawdadDaemonSet - - - -    		 - -(Optional) -

    -CrawdadDaemonSet is the specification of the Crawdad Daemonset. -

    - -
    - -exclusions
    - - -Exclusions - - - -    		 - -(Optional) -

    -Exclusions define the exclusion criteria for image scanning. -Note: Exclusions are applied to future scans and do not affect past scan results. -

    - -
    -

    ImageAssuranceStatus

    -

    - -(Appears on: -ImageAssurance) - -

    -

    -ImageAssuranceStatus defines the observed state of ImageAssurance -

    -
    diff --git a/calico-cloud/reference/installation/ia-api.mdx b/calico-cloud/reference/installation/ia-api.mdx deleted file mode 100644 index 77947656c0..0000000000 --- a/calico-cloud/reference/installation/ia-api.mdx +++ /dev/null @@ -1,13 +0,0 @@ ---- -description: Image Assurance installation API reference for Calico Cloud listing operator-managed custom resources that configure the Image Assurance subsystem. ---- - -# Image Assurance Installation reference - -import IAAPI from '@site/calico-cloud/reference/installation/_ia-api.mdx'; - -## Image Assurance installation reference - -The Kubernetes resources below configure $[prodname] Image Assurance installation when using the operator. Each resource is responsible for installing and configuring a different subsystem of $[prodname] Image Assurance during installation. Most options can be modified on a running cluster using `kubectl`. - - \ No newline at end of file diff --git a/calico-cloud/reference/resources/containeradmissionpolicy.mdx b/calico-cloud/reference/resources/containeradmissionpolicy.mdx deleted file mode 100644 index e540583c4e..0000000000 --- a/calico-cloud/reference/resources/containeradmissionpolicy.mdx +++ /dev/null @@ -1,194 +0,0 @@ ---- -description: Reference for the ContainerAdmissionPolicy resource in Calico Cloud that admits or rejects pod creation based on container image scan results. ---- - -# Container admission policy - -A container admission policy (`ContainerAdmissionPolicy`) represents an ordered set of rules which are applied to a -collection of containers that match a [label selector](#selector). - -`ContainerAdmissionPolicy` is a cluster resource. `ContainerAdmissionPolicy` can be restricted to a set of namespaces -using a [namespace selector](#selector). - -## Sample YAML - -This sample policy allows admission requests for pod creating resources whose image is in the registry / repository -`gcr.io/company/production-repository/*` with a scan status of either `Pass` or `Warn`, and rejects all other admission -requests. - -```yaml -apiVersion: containersecurity.tigera.io/v1beta1 -kind: ContainerAdmissionPolicy -metadata: - name: reject-failed-and-non-gcr -spec: - selector: all() - namespaceSelector: all() - order: 10 - rules: - - action: "Reject" - imagePath: - operator: IsNoneOf - values: - - "^gcr.io/company/production-repository/.*" - - action: Allow - imageScanStatus: - operator: IsOneOf - values: - - Pass - - Warn - - action: Reject -``` - -## Container admission policy definition - -### Metadata - -| Field | Description | Accepted Values | Schema | Default | -|-----------|--------------------------------------------------------------------|-----------------------------------------------------|--------|-----------| -| name | The name of the network policy. Required. | Alphanumeric string with optional `.`, `_`, or `-`. | string | | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -|-------------------|-----------------------------------------------------------------------------------------------------|-----------------|-----------------------|---------| -| order | Controls the order of precedence. $[prodname] applies the policy with the lowest value first. | | float | | -| selector | Selects the resources to which this policy applies. | | [selector](#selector) | all() | -| namespaceSelector | Selects the namespace to which this policy applies. | | [selector](#selector) | all() | -| rules | Ordered list of rules applied by this policy. | | List of [Rule](#rule) | | - -### Rule - -A single rule matches a set of pod creating resources and applies some action to them. Multiple rules are executed in order. - -| Field | Description | Accepted Values | Schema | Default | -|-------------------|---------------------------------------------------------------------|------------------------------------------|--------------------------------------------|------------| -| action | Action to perform when matching this rule. | `Allow`, `Reject` | string | | -| imagePath | Image path matching criteria. | | [String Values Match](#stringvaluematch) | | -| imageScanStatus | Vulnerability scan status criteria. | | [String Values Match](#stringvaluematch) | | -| imageLastScan | Criteria for the last time the containers image was scanned. | | [Time Match](#timematch) | | - -### Selector - -A label selector is an expression which either matches or does not match a resource based on its labels. - -$[prodname] label selectors support a number of operators, which can be combined into larger expressions -using the boolean operators and parentheses. - -| Expression | Meaning | -|---------------------------|-----------------------------| -| **Logical operators** | -| `( )` | Matches if and only if `` matches. (Parentheses are used for grouping expressions.) -| `! ` | Matches if and only if `` does not match. **Tip:** `!` is a special character at the start of a YAML string, if you need to use `!` at the start of a YAML string, enclose the string in quotes. -| ` && ` | "And": matches if and only if both ``, and, `` matches -| \ || \ | "Or": matches if and only if either ``, or, `` matches. -| **Match operators** | -| `all()` | Match all in-scope resources. To match _no_ resources, combine this operator with `!` to form `!all()`. -| `global()` | Match all non-namespaced resources. Useful in a `namespaceSelector` to select global resources such as global network sets. -| `k == 'v'` | Matches resources with the label 'k' and value 'v'. -| `k != 'v'` | Matches resources without label 'k' or with label 'k' and value _not_ equal to `v` -| `has(k)` | Matches resources with label 'k', independent of value. To match pods that do not have label `k`, combine this operator with `!` to form `!has(k)` -| `k in { 'v1', 'v2' }` | Matches resources with label 'k' and value in the given set -| `k not in { 'v1', 'v2' }` | Matches resources without label 'k' or with label 'k' and value _not_ in the given set -| `k contains 's'` | Matches resources with label 'k' and value containing the substring 's' -| `k starts with 's'` | Matches resources with label 'k' and value starting with the substring 's' -| `k ends with 's'` | Matches resources with label 'k' and value ending with the substring 's' - -Operators have the following precedence: - -* **Highest**: all the match operators -* Parentheses `( ... )` -* Negation with `!` -* Conjunction with `&&` -* **Lowest**: Disjunction with `||` - -For example, the expression - -``` -! has(my-label) || my-label starts with 'prod' && role in {'frontend','business'} -``` - -Would be "bracketed" like this: - -``` -((!(has(my-label)) || ((my-label starts with 'prod') && (role in {'frontend','business'})) -``` - -It would match: -* Any resource that did not have label "my-label". -* Any resource that both: -* Has a value for `my-label` that starts with "prod", and, -* Has a role label with value either "frontend", or "business". - -Understanding scopes and the `all()` and `global()` operators: selectors have a scope of resources -that they are matched against, which depends on the context in which they are used. For example: - -* The `nodeSelector` in an `IPPool` selects over `Node` resources. - -* The top-level selector in a `NetworkPolicy` selects over the workloads _in the same namespace_ as the -`NetworkPolicy`. - -* The top-level selector in a `GlobalNetworkPolicy` doesn't have the same restriction, it selects over all endpoints -including namespaced `WorkloadEndpoint`s and non-namespaced `HostEndpoint`s. - -* The `namespaceSelector` in a `NetworkPolicy` (or `GlobalNetworkPolicy`) _rule_ selects over the labels on namespaces -rather than workloads. - -* The `namespaceSelector` determines the scope of the accompanying `selector` in the entity rule. If no `namespaceSelector` -is present then the rule's `selector` matches the default scope for that type of policy. (This is the same namespace -for `NetworkPolicy` and all endpoints/network sets for `GlobalNetworkPolicy`) - -* The `global()` operator can be used (only) in a `namespaceSelector` to change the scope of the main `selector` to -include non-namespaced resources such as [GlobalNetworkSet](globalnetworkset.mdx). -This allows namespaced `NetworkPolicy` resources to refer to global non-namespaced resources, which would otherwise -be impossible. - -### StringValueMatch -A string values match does a match or negative match on a target against a set of values. - -| Field | Description | Accepted Values | Schema | Default | -|-----------|---------------------------------------------------|-----------------------|-------------------|------------| -| operator | Match operator to use against the list of values | `IsOneOf`, `IsNoneOf` | string | | -| values | List of values to match against. | | list of strings | | - -### TimeMatch -A time match does a match or negative match against a time or duration. - -Duration is the length of time into the past from the current time to match against. As an example, - -```yaml - operator: "gt" - duration: - days: 3 -``` - -is false for 4 days prior to the current date time, and true for 2 days prior to current date time. - -Time is the absolute time to match a given time against. As an example, - -```yaml - operator: "gt" - time: "2022-01-02T0:00:00Z" -``` - -is false for "2022-01-01T0:00:00Z", and true for "2022-01-03T0:00:00Z". - -| Field | Description | Accepted Values | Schema | Default | -|-----------|-------------------------------------------------------|-----------------------|---------------------------------------------------|------------| -| operator | Match operator to use against the duration or time. | `gt`, `lt` | string | | -| duration | The duration that this operator matches within. | | [Duration](#duration) | | -| time | List of values to match against. | | String of the format "2006-01-02T15:04:05Z07:00" | | - -### Duration - -| Field | Description | Accepted Values | Schema | Default | -|-----------|-----------------------------------------------|-------------------|-----------|------------| -| days | Number of days past from the current time. | | integer | | -| months | Number of months past from the current time. | | integer | | -| years | Number of years past from the current time. | | integer | | - -## Supported operations - -| Datastore type | Create/Delete | Update | Get/List | Notes -|--------------------------|---------------|--------|----------|------ -| Kubernetes API datastore | Yes | Yes | Yes | diff --git a/calico-cloud/reference/resources/runtimesecurity.mdx b/calico-cloud/reference/resources/runtimesecurity.mdx deleted file mode 100644 index e4d4138559..0000000000 --- a/calico-cloud/reference/resources/runtimesecurity.mdx +++ /dev/null @@ -1,72 +0,0 @@ ---- -description: Reference for the RuntimeSecurity resource in Calico Cloud that configures Container Threat Detection in a connected cluster. ---- - -# RuntimeSecurity - -The **RuntimeSecurity** custom resource (CR) is used to enable and configure Container Threat Detection in a Calico Cloud managed cluster. - -### Resource Definition - -```yaml -apiVersion: operator.tigera.io/v1 -kind: RuntimeSecurity -metadata: - name: default -spec: - detectorConfig: - - id: execution-container_deployment_command - disabled: true - - id: discovery-enumeration_of_linux_capabilities - disabled: true - runtimeExceptionList: - - matching: regex - processInvocation: "/bin/ls*" - pod: "not-evil-pod" - namespace: "default" - - matching: exact - pod: "nginx" - namespace: default - - matching: regex - namespace: "company-operations" -``` - -## Runtime Security Definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ------ | --------------------------------------------- | ---------------- | ------ | -| name | The name of the runtime security resource. | default | string | -| labels | A set of labels to apply to this resource. | | map | - - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ------------------------ | -------------------------------------------------------------------------------------------- | ---------------- | ----------------------------------------------------- | ------- | -| detectorConfig | Configuration that allows particular threat detectors to be disabled | | [DetectorConfig](#detectorconfig) | | -| runtimeExceptionList | List of entries of processes that are allowed to run that won't generate an event | | [runtimeExceptionList](#runtimeexceptionlist) | Enabled | - -### DetectorConfig - -The `DetectorConfig` by default is not present but can be used to disable particular threat detectors in the Calico Cloud Managed cluster. -One entry per detector - -| Field | Description | Accepted Values | Schema | -| -------- | ----------------------------------------------------------------- | --------------- | ------- | -| id | The ID of the detector this entry applies too | | string | -| disabled | Boolean represents weather the detector should be disabled or not | True, False | boolean | - - -### RuntimeExceptionList - -This `RuntimeExceptionList` holds a list of entries that contain a list of supported fields by which a user can negate the -generation of runtime reports. - -| Field | Description | Accepted Values | Schema | -| -------- | ---------------------------------------------------------------------------------------------------------------------- | --------------- | ------- | -| matching | Whether the entries are exact matches to fields or considered a regular expression | Exact, Regex | string | -| processInvocation | The exact name or regex of the process to which a user wants to negate the generation of runtime logs | | string | -| pod | The exact name or regex of the pod(s) to which a user wants to negate the generation of runtime logs | | string | -| namespace | The exact name or regex of the namespace(s) for which a user wants to negate the generation of runtime logs | | string | diff --git a/calico-cloud/release-notes/index.mdx b/calico-cloud/release-notes/index.mdx index e91044df60..c3b276dceb 100644 --- a/calico-cloud/release-notes/index.mdx +++ b/calico-cloud/release-notes/index.mdx @@ -98,14 +98,14 @@ We've provided better access to the detectors we use as part of our Container Th You can now view the complete list of detectors and turn them on or off as you see fit. Detectors can also be configured as part of a new RuntimeSecurity custom resource. -For more information, see [Update detector settings](../threat/container-threat-detection.mdx#update-detectors-settings). +For more information, see Update detector settings. #### Create Security Event exceptions for known processes We added a way to create Security Event exceptions for processes in your cluster that you know to be safe. This can be a helpful way to eliminate noise and false positives in your alerts. -For more information, see [Exclude a process from Security Events alerts](../threat/container-threat-detection.mdx#exclude-process). +For more information, see Exclude a process from Security Events alerts. #### Added EPSS data to Image Assurance results @@ -184,7 +184,7 @@ For information about upgrading, see [Upgrade Calico Cloud](../get-started/upgra We added a way to efficiently add large numbers of vulnerability exceptions to your Image Assurance scan results. Instead of creating exceptions one by one, you can add them all at once by uploading a CSV file with the vulnerability definitions. -For more information, see [Exclude vulnerabilities from scan results](../image-assurance/exclude-vulnerabilities-from-scan-results.mdx). +For more information, see Exclude vulnerabilities from scan results. ### Bug fixes @@ -202,7 +202,7 @@ We added a way to create and assign Jira issues directly from your Image Assuran You can filter and prioritize vulnerabilities, and then assign the remediation work to members of your team. Calico Cloud populates the information you need, including a CSV file with detailed information about the vulnerabilities in your packages. -For more information, see [Creating Jira issues for scan results](../image-assurance/creating-jira-issues-for-scan-results.mdx) +For more information, see Creating Jira issues for scan results. #### Security events dashboard @@ -272,7 +272,7 @@ For more information, see [Connect a cluster to Calico Cloud](../get-started/ins We added the ability to exclude namespaces from image scanning and runtime view. By excluding certain namespaces, you can reduce noise in your scan results and focus attention on higher priority workloads. -For more information, see [Configure exclusions for image scanning](../image-assurance/scanners/cluster-scanner.mdx#configure-exclusions-for-image-scanning). +For more information, see Configure exclusions for image scanning. ## April 2, 2024 (version 19.1.0) @@ -417,7 +417,7 @@ This failed installation message can be disregarded. The Image Assurance feature adds the ability to scan images in container registries at any time, on any infrastructure, including Kubernetes. This is ideal protection for images that don’t go through a pipeline (for example, third-party images), but are published to a registry. If CVEs are missed in your build pipeline, you can catch them before they are deployed. -For more information, see [Scan images in container registries](../image-assurance/scanners/registry-scanner.mdx). +For more information, see Scan images in container registries. #### Security event management @@ -723,7 +723,7 @@ Release of Container Threat Detection With Container Threat Detection, you can monitor container activity using eBPF. Enable this feature to receive alerts based on file and process activity for known malicious and suspicious behavior. Alert events can be viewed on the Alerts page in the web console. -To get started, see [Container Threat Detection](../threat/container-threat-detection.mdx) +To get started, see Container Threat Detection. ## September 26, 2022 @@ -763,7 +763,7 @@ We've made it easier for platform operators to share Image Assurance scan result * Export one row per image or one row per image and CVE. * Export CSV or JSON files. -To get started, see [Image Assurance](../image-assurance). +To get started, see Image Assurance. ### Malware detection is GA @@ -774,7 +774,7 @@ Calico Cloud uses eBPF-based monitoring to log file hashes of programs running i If there's a match to known malware from our threat intelligence library, you receive an alert. You can view your alerts on the _Alerts_ page on the web console. -To get started, see [Malware Detection](../threat/container-threat-detection.mdx)) +To get started, see Malware Detection. ## July 27, 2022 @@ -858,4 +858,4 @@ The $[prodname] installation process will now require running a `kubectl apply` $[prodname] introduces Image Assurance in tech preview, enabling DevOps and platform teams to scan images in public and private registries, and images that are automatically discovered in connected clusters. Image Assurance provides a runtime view into risk, based on discovered vulnerabilities. It also offers admission controller policies to enforce how vulnerable images are used to create resources within Kubernetes. -To get started, see [Image Assurance](../image-assurance). +To get started, see Image Assurance. diff --git a/calico-cloud/threat/container-threat-detection.mdx b/calico-cloud/threat/container-threat-detection.mdx deleted file mode 100644 index ce1a17eba0..0000000000 --- a/calico-cloud/threat/container-threat-detection.mdx +++ /dev/null @@ -1,153 +0,0 @@ ---- -description: Detect malware hashes and suspicious container activity such as privilege escalation and command-and-control in Calico Cloud connected clusters with the managed eBPF threat detection engine. -redirect_from: - - /threat/malware-detection ---- - -# Container threat detection - -:::warning[deprecation and removal notice] - -Compliance reports are deprecated and will be removed in a future release. -We're building a new compliance reporting system that will eventually replace the current one. - -::: - -## Big picture - -Get alerts when security threats, such as malware and other suspicious processes, are detected in your cluster. - -## Value - -$[prodname] provides a threat detection engine that analyzes observed file and process activity to detect known malicious and suspicious activity. - -As part of these threat detection capabilities, $[prodname] maintains a database of malware file -hashes. This database consists of SHA256, SHA1, and MD5 hashes of executable file contents that are -known to be malicious. Whenever a program is launched in a $[prodname] cluster, malware -detection generates an alert in the **Security Events Dashboard** if the program's hash matches one that is known -to be malicious. - -Our threat detection engine also monitors activity within the containers running in your clusters to detect suspicious behavior and generate corresponding alerts. The threat detection engine monitors the following types of suspicious activity within containers: - -- Access to sensitive system files and directories -- Command and control -- Defense evasion -- Discovery -- Execution -- Impact -- Persistence -- Privilege escalation - -## Before you begin... - -### Required - -$[prodname] Container threat detection uses eBPF to monitor container activity, and it runs on Linux-based -nodes in a Kubernetes cluster. - -Nodes require amd64 (x86_64) architecture CPUs and one of the following distributions: - -- Ubuntu Bionic with kernel version 4.15.0 or 5.4.0 -- Ubuntu Focal with kernel version 5.4.0, 5.8.0 or 5.11.0 -- CentOS 7 or 8 -- Fedora 29, 30, 31, 32, 33 or 34 -- Amazon Linux 2 -- Debian Stretch or later -- Any other distribution with a Linux kernel 5.0 or later that provides BPF Type Format (BTF) for that kernel at the standard place (/sys/kernel/btf/vmlinux) - -:::note - -If your nodes are running a variant kernel, or a similarly-modern kernel but with another platform, -please open a [Support ticket](https://support.tigera.io/) -so we can bundle the BTF data to precisely match the version of the kernel running on your cluster nodes. - -::: - -## How to - -- [Enable Container threat detection in the managed cluster](#enable-container-threat-detection) -- [Monitor the Security Events page for malicious programs](#monitor-alerts-page-for-malicious-programs) -- [Exclude a process from Security Events alerts](#exclude-a-process-from-Security-Events-alerts) -- [Update detectors settings](#update-detectors-settings) - - [Configure detectors via RuntimeSecurity Custom Resource](#configure-detectors-via-runtimesecurity-custom-resource) - -### Enable Container Threat Detection - -Container threat detection is disabled by default. - -To enable Container threat detection on your managed cluster, go to the **Threat Defense** section in the $[prodname] UI, and select **Enable Container Threat Detection**. -This will result in Container threat detection running on all nodes in the managed cluster to detect malware and suspicious processes. - -Alternatively, Container threat detection can be enabled using kubectl: - -```bash -kubectl apply -f - <Exclude a process from Security Events alerts - -You can turn off Security Events alerts for processes in your cluster that you know to be safe. - -To create an exception, add the process to the Runtime Security resource with kubectl: - -```bash title="Example RuntimeSecurity CR with exceptions" -kubectl apply -f - < - diff --git a/calico-cloud/threat/security-event-management.mdx b/calico-cloud/threat/security-event-management.mdx index 340c96b74a..d9372972c4 100644 --- a/calico-cloud/threat/security-event-management.mdx +++ b/calico-cloud/threat/security-event-management.mdx @@ -119,4 +119,4 @@ Security events generated from older managed clusters will not have values for t **Where can I view security event logs?** -Go to: **Logs**, Kibana index, `tigera_secure_ee_events`. +Go to **Logs** and select the `tigera_secure_ee_events` index. diff --git a/calico-cloud/threat/tor-vpn-feed-and-dashboard.mdx b/calico-cloud/threat/tor-vpn-feed-and-dashboard.mdx index b95692af09..3fd4dcfd87 100644 --- a/calico-cloud/threat/tor-vpn-feed-and-dashboard.mdx +++ b/calico-cloud/threat/tor-vpn-feed-and-dashboard.mdx @@ -30,9 +30,6 @@ In recent times it became a trend to use multiple anonymization networks to hide ### The $[prodname] Tor-VPN dashboard The Tor-VPN dashboard helps network security teams to monitor and respond to any detected activity by Tor and VPN feeds. It provides a cluster context to the detection and shows multiple artifacts e.g. flow logs, filtering controls, a tag cloud and line graph to analyze the activity and respond faster. -The Tor-VPN dashboard may be accessed as below: - -- Log in to the $[prodname] web console, and go to **kibana**, select **dashboard**, and select **Tor-VPN Dashboard**. ## Before you begin... @@ -57,8 +54,7 @@ In this section we will look at how to add Tor and VPN feeds to $[prodname]. Ins ```shell kubectl apply -f $[filesUrl_CE]/manifests/threatdef/tor-exit-feed.yaml ``` -2. Now, you can monitor the Dashboard for any malicious activity. The dashboard can be found at the $[prodname] web console, go to "kibana" and then go to "Dashboard". Select "Tor-VPN Dashboard". -3. Additionally, feeds can be checked using following command: +2. Feeds can be checked using following command: ```shell kubectl get globalthreatfeeds ``` diff --git a/calico-cloud/threat/web-application-firewall.mdx b/calico-cloud/threat/web-application-firewall.mdx index b92f5e6b5a..8d4d50a108 100644 --- a/calico-cloud/threat/web-application-firewall.mdx +++ b/calico-cloud/threat/web-application-firewall.mdx @@ -327,10 +327,6 @@ Read more about the order of execution for plugins here: https://coreruleset.org To view WAF events in a centralized security events dashboard, go to: **Threat defense**, **Security Events**. For help, see [Security Event Management](../threat/security-event-management). -### Kibana - -To view WAF events In Kibana, select the `tigera_secure_ee_waf*` index pattern. - ### Disable WAF for a deployment To disable WAF on a deployment, use the Actions menu on the WAF board, or use the following command: diff --git a/calico-cloud/tutorials/calico-cloud-features/networksets.mdx b/calico-cloud/tutorials/calico-cloud-features/networksets.mdx index 93913689a2..1aed8972f4 100644 --- a/calico-cloud/tutorials/calico-cloud-features/networksets.mdx +++ b/calico-cloud/tutorials/calico-cloud-features/networksets.mdx @@ -34,7 +34,7 @@ Here are just a few examples of how network sets can be used: - **Troubleshooting** - Network sets appear as additional metadata in flow logs and Kibana, Flow Visualizer, and Service Graph. + Network sets appear as additional metadata in flow logs, Flow Visualizer, and Service Graph. - **Efficiency and scaling** @@ -119,7 +119,7 @@ If we double-click `hipstershop` to drill down, we now see the `google` network ![google-networkset](/img/calico-cloud/google-networkset.png) -Service Graph provides a view into how services are interconnected in a consumable view, along with easy access to flow logs. However, you can also see traffic associated with network sets in volumetric display with Flow Visualizer, and query flow log data associated with network sets in Kibana. +Service Graph provides a view into how services are interconnected in a consumable view, along with easy access to flow logs. You can also see traffic associated with network sets in volumetric display with Flow Visualizer. ## Tutorial @@ -223,7 +223,7 @@ spec: - Create a network set label and name schema - It is helpful to think: what names would be meaningful and easy to understand when you look in Service Graph? Flow Viz? Kibana? What labels will be easy to understand when used in network policies – especially if you are separating users who manage network sets from those who consume them in network policies. + It is helpful to think: what names would be meaningful and easy to understand when you look in Service Graph or Flow Visualizer? What labels will be easy to understand when used in network policies – especially if you are separating users who manage network sets from those who consume them in network policies. - Do not put large sets of CIDRs and domains directly in policy diff --git a/calico-cloud/tutorials/calico-cloud-features/tour.mdx b/calico-cloud/tutorials/calico-cloud-features/tour.mdx index 4bb25a4195..2f440e642d 100644 --- a/calico-cloud/tutorials/calico-cloud-features/tour.mdx +++ b/calico-cloud/tutorials/calico-cloud-features/tour.mdx @@ -205,22 +205,10 @@ How do you know if you have an infected workload? A possible threat? $[prodname] ## Logs -$[prodname] includes a fully-integrated deployment of Elastic to collect flow log data that drives key features like the Flow Visualizer, metrics in the Dashboard and Policy Board, policy automation, and testing features and security. $[prodname] also embeds Kibana so you can view raw log data for the traffic within your cluster. +$[prodname] includes a fully-integrated deployment of Elastic to collect flow log data that drives key features like the Flow Visualizer, metrics in the Dashboard and Policy Board, policy automation, and testing features and security. > From the left navbar, click **Logs**. -**Dashboards** - -$[prodname] comes with built-in dashboards. - -![kibana-dashboards](/img/calico-cloud/kibana-dashboards.png) - -**Log data** - -Kibana provides its own set of filtering capabilities to drill down into log data. For example, use filters to drill into flow log data for specific namespaces and pods. Or view details and metadata for a single flow log entry. - -![kibana](/img/calico-cloud/kibana.png) - ## Threat feeds You can add threat intelligence feeds to $[prodname] to trace network flows of suspicious IP addresses and domains. Then, you can use network policy to block pods from contacting IPs or domains. diff --git a/calico-cloud/users/user-management.mdx b/calico-cloud/users/user-management.mdx index ce6a923334..69e3d93827 100644 --- a/calico-cloud/users/user-management.mdx +++ b/calico-cloud/users/user-management.mdx @@ -30,13 +30,10 @@ The Owner role cannot be assigned to new users. The only Owner is the user who c | Compliance Reports | view | | Timeline | view | | Alerts | view, edit | -| Kibana | view, edit | -| Image Assurance | view, edit | | Manage Team | view, edit | | Usage Metrics | view | | Threat Feeds | view, edit | | Web Application Firewall | view, edit | -| Container Threat Detection | view, edit | | Dashboards | view, edit | ### Admin @@ -53,13 +50,10 @@ The Admin role provides broad administrative access for day-to-day configuration | Compliance Reports | view | | Timeline | view | | Alerts | view, edit | -| Kibana | view, edit | -| Image Assurance | view, edit | | Manage Team | view, edit | | Usage Metrics | - | | Threat Feeds | view, edit | | Web Application Firewall | view, edit | -| Container Threat Detection | view, edit | | Dashboards | view, edit | ### User Admin @@ -76,13 +70,10 @@ The User Admin role has the ability to manage team members and their assigned ro | Compliance Reports | - | | Timeline | - | | Alerts | - | -| Kibana | - | -| Image Assurance | - | | Manage Team | view, edit | | Usage Metrics | - | | Threat Feeds | - | | Web Application Firewall | - | -| Container Threat Detection | - | | Dashboards | - | ### Cluster Connection Admin @@ -99,13 +90,10 @@ The Cluster Connection Admin role has administrative capabilities of managed clu | Compliance Reports | - | | Timeline | - | | Alerts | - | -| Kibana | - | -| Image Assurance | - | | Manage Team | - | | Usage Metrics | - | | Threat Feeds | - | | Web Application Firewall | - | -| Container Threat Detection | - | | Dashboards | - | ### Viewer @@ -122,13 +110,10 @@ The Viewer role provides read-only access to most operational and configuration | Compliance Reports | view | | Timeline | view | | Alerts | view | -| Kibana | view | -| Image Assurance | - | | Manage Team | view | | Usage Metrics | - | | Threat Feeds | view | | Web Application Firewall | view | -| Container Threat Detection | view | | Dashboards | view | ### DevOps @@ -145,18 +130,15 @@ The DevOps role is designed for users responsible for application deployment, CI | Compliance Reports | - | | Timeline | view | | Alerts | view, edit | -| Kibana | view, edit | -| Image Assurance | view, edit | | Manage Team | view | | Usage Metrics | - | | Threat Feeds | view, edit | | Web Application Firewall | view | -| Container Threat Detection | view | | Dashboards | view | ### Security -The Security role focuses on security posture management, including policy definition, threat monitoring, vulnerability management (Image Assurance), and incident response. +The Security role focuses on security posture management, including policy definition, threat monitoring, and incident response. | Feature | Permission Level | | :------------------------------ | :--------------- | @@ -168,13 +150,10 @@ The Security role focuses on security posture management, including policy defin | Compliance Reports | view | | Timeline | view | | Alerts | view, edit | -| Kibana | view, edit | -| Image Assurance | view, edit | | Manage Team | view | | Usage Metrics | - | | Threat Feeds | view, edit | | Web Application Firewall | view, edit | -| Container Threat Detection | view, edit | | Dashboards | view | ### Compliance @@ -191,13 +170,10 @@ The Compliance role provides focused access to compliance reporting and related | Compliance Reports | view | | Timeline | - | | Alerts | - | -| Kibana | - | -| Image Assurance | - | | Manage Team | - | | Usage Metrics | - | | Threat Feeds | - | | Web Application Firewall | - | -| Container Threat Detection | - | | Dashboards | - | ### Usage Metrics @@ -214,36 +190,10 @@ This role grants specific access to view usage metrics for the $[prodname] accou | Compliance Reports | - | | Timeline | - | | Alerts | - | -| Kibana | - | -| Image Assurance | - | | Manage Team | - | | Usage Metrics | view | | Threat Feeds | - | | Web Application Firewall | - | -| Container Threat Detection | - | -| Dashboards | - | - -### Image Assurance Admin - -This role provides administrative control specifically over the Image Assurance feature, including configuring registries, policies, and viewing scan results. - -| Feature | Permission Level | -| :------------------------------ | :--------------- | -| Service Graph and Flow Visualizer | - | -| Policies | - | -| Nodes and Endpoints | - | -| Network Sets | - | -| Managed Clusters | - | -| Compliance Reports | - | -| Timeline | - | -| Alerts | - | -| Kibana | - | -| Image Assurance | view, edit | -| Manage Team | - | -| Usage Metrics | - | -| Threat Feeds | - | -| Web Application Firewall | - | -| Container Threat Detection | - | | Dashboards | - | ### Dashboards Admin @@ -260,13 +210,10 @@ This role grants administrative permissions specifically for creating, managing, | Compliance Reports | - | | Timeline | - | | Alerts | - | -| Kibana | - | -| Image Assurance | - | | Manage Team | - | | Usage Metrics | - | | Threat Feeds | - | | Web Application Firewall | - | -| Container Threat Detection | - | | Dashboards | view, edit | ## Add your own identity provider diff --git a/sidebars-calico-cloud.js b/sidebars-calico-cloud.js index 2cb1959016..86073c9dd9 100644 --- a/sidebars-calico-cloud.js +++ b/sidebars-calico-cloud.js @@ -220,7 +220,6 @@ module.exports = { 'observability/alerts', 'observability/dashboards', 'observability/create-custom-dashboard', - 'observability/kibana', 'observability/packetcapture', 'observability/visualize-traffic', { @@ -274,32 +273,8 @@ module.exports = { 'threat/suspicious-domains', 'threat/tor-vpn-feed-and-dashboard', 'threat/deeppacketinspection', - 'threat/container-threat-detection', 'threat/web-application-firewall', 'threat/deploying-waf-ingress-gateway', - { - type: 'category', - label: 'Image Assurance (deprecated)', - link: { type: 'doc', id: 'image-assurance/index' }, - items: [ - { - type: 'category', - label: 'Scan images for vulnerabilities', - link: { type: 'doc', id: 'image-assurance/scanners/index' }, - items: [ - 'image-assurance/scanners/overview', - 'image-assurance/scanners/cluster-scanner', - 'image-assurance/scanners/pipeline-scanner', - 'image-assurance/scanners/registry-scanner', - ], - }, - 'image-assurance/understanding-scan-results', - 'image-assurance/exclude-vulnerabilities-from-scan-results', - 'image-assurance/set-up-alerts', - 'image-assurance/install-the-admission-controller', - 'image-assurance/creating-jira-issues-for-scan-results', - ], - }, ], }, { @@ -473,7 +448,6 @@ module.exports = { items: [ 'reference/api', 'reference/installation/api', - 'reference/installation/ia-api', { type: 'category', label: 'Resource definitions', @@ -486,7 +460,6 @@ module.exports = { 'reference/resources/bgpfilter', 'reference/resources/blockaffinity', 'reference/resources/caliconodestatus', - 'reference/resources/containeradmissionpolicy', { type: 'category', label: 'Compliance reports', @@ -519,7 +492,6 @@ module.exports = { 'reference/resources/node', 'reference/resources/packetcapture', 'reference/resources/remoteclusterconfiguration', - 'reference/resources/runtimesecurity', 'reference/resources/securityeventwebhook', 'reference/resources/stagedglobalnetworkpolicy', 'reference/resources/stagedkubernetesnetworkpolicy', diff --git a/static/_redirects b/static/_redirects index b0e0230b0e..f9f5daa342 100644 --- a/static/_redirects +++ b/static/_redirects @@ -135,6 +135,14 @@ # Mylo AI assistant removed (DOCS-2957) /calico-cloud/tutorials/calico-cloud-features/mylo-ai /calico-cloud/about 301 +# Container security removal (PMREQ-905 / DOCS-2925): Image Assurance, Container Threat Detection, Kibana +/calico-cloud/image-assurance/* /calico-cloud/about 301 +/calico-cloud/threat/container-threat-detection /calico-cloud/threat 301 +/calico-cloud/reference/installation/ia-api /calico-cloud/reference/installation/api 301 +/calico-cloud/reference/resources/runtimesecurity /calico-cloud/reference/resources 301 +/calico-cloud/reference/resources/containeradmissionpolicy /calico-cloud/reference/resources 301 +/calico-cloud/observability/kibana /calico-cloud/observability 301 + # Redirect rules for old permalinks. # Specific 301 redirects. From former CE unversioned URLS.